[Sis-dtn] BPv7 QOS reliability

[Jonathan W]

Felix,

     Thank you for the thoughtful reply. We should discuss the topic at 
one or more upcoming Thursday DTN WG meetings.

    The concept of using policy to enforce a nodes bandwidth and storage 
allocation per the SLA is something we were thinking about as well. 
Within that allocation a source node could set QoS as they see fit as 
you state below. The concerns about security and performance need 
further discussion. Having intermediate nodes authenticate and parse 
another extension in each bundle may be significant.  In the near term 
where link layer security is used and there are only a few nodes network 
layer security may not be an issue, but we should always be mindful of 
the potential to abuse in the future.

It's also important to consider that QoS is not just the bundle layer 
function but is affected by the network stack configuration. Delivery 
reliability and latency are affected by use of TCP, LTP, UDP, and even 
the encoding used in the radios. When discussing QoS we should also 
consider how it is affected by contact scheduling, link bandwidth, and 
convergence layers.

A combination of extension header and policy is a reasonable approach. 
Finding the correct balance considering performance, management, 
scalability, security, traffic shaping, and network stack configuration 
is the discussion we want to have.

     Kind regards,

             Jonathan

On 5/14/2024 8:50 AM, Felix Flentge wrote:

> Thanks Jonathan and Brian,
>
> Sorry for taking some time to respond. We really appreciate feedback and discussion on the QoS (and all the other) extension.
>
> Please see my comments below.
>
> As Teresa anyway has to update a few things based on the feedback from the CCSDS meetings (eg, how to implement the queuing), I would suggest to take one of the Thursday meetings in a few weeks to have a dedicated discussion on QoS (and we should ensure that Brian and Jonathan are available; it seems there are still some misunderstandings regrading the proposed User QoS extension).
>
> Regards,
> Felix
>
> From: SIS-DTN<sis-dtn-bounces at mailman.ccsds.org>  On Behalf Of Jonathan W via SIS-DTN
> Sent: Friday, May 10, 2024 7:19 PM
> To: Sipos, Brian J.<Brian.Sipos at jhuapl.edu>;sis-dtn at mailman.ccsds.org
> Cc: teresa.algarra.ulierte<teresa.algarra.ulierte at tuhh.de>; Jain, Peyush (GSFC-4502)<peyush.jain at nasa.gov>; Wilmot, Jonathan J. (GSFC-5800)<jonathan.j.wilmot at nasa.gov>
> Subject: Re: [Sis-dtn] BPv7 QOS reliability
>
>
> All,
>
>      With regard to network security, network predictability/modeling and the constrained flight domain there is a general concern about embedding the QoS in the bundle.
>
>    Allowing a source or any intermediate node to set these extension header fields without policy constraints would lead to unpredictable network utilization and potentially a denial of service (whether accidental or malicious) to other network users.
>
> No
>
>    1.  User QoS block is only inserted by the source node and can be protected by BIB (together with primary block) if needed
>    2.  User QoS blocks can be subject to network SLAs; the requirement is that user QoS are respected within the respective SLA not absolutely
>    3.  There are 100s of ways I can imagine DoS attacks on BP networks; yes, can be a problem and we would need corresponding monitoring mechanisms but it is nothing I see particularly linked to QoS extension (just think about all the ways you could potentially overload policy engines ...)
>
>
>
>     Even if the extension header approach is part of the DTN protocol suite any QoS flags would still need to be checked against policy to ensure source nodes or intermediate nodes were staying within their Service Level Agreements. This adds the overhead of doing both.
>
> Depends on the way SLA are implemented / enforced. I think a typical way would be to guarantee a user under an SLA a certain amount of data / per time. Requested QoS within that share would be up to the user (but should be respected).
>
>     It has been proposed that QoS is a network management and routing function as it relates to Service Level Agreements and the associated traffic shaping functions. This approach supports predictable network behaviors, reduces the potential for denial of service, and reduces bundle processing overhead.  An approach that applies QoS to the immutable and potentially authenticated primary header source node service number allows implementations to avoid parsing and checking yet another extension header on each individual bundle at egress. Having QoS as a function of network management, routing and network stack configuration removes processing overhead on individual nodes.
>
>    *   We don't have an interoperable network management yet and I think it is still a very long way to have this implemented across agencies; even then, some 'simple' nodes might no support network management in its whole complexity
>    *   In my mind it seems much simpler to execute some fixed policies based on an extension block then to execute rules within a policy engine
>    *   Policies can change dynamically which reduces predictability
>    *   QoS based on policies does not scale
>    *   Users wanting to change priorities for certain traffic will need to ask all involved nodes to update their policies
>
> So, why I agree that policies can be a suitable mean for managing QoS within a part of a network under the same administrative domain, I don't think it is a suitable approach for a multi-domain network. (For managing QoS within an administrative domain, we also propose to use a network QoS block which can be used in whatever way it is useful within that part of the network; we don't aim at standardising that).
>
>     It is agreed that the extension header approach may be useful within a fully trusted network where a service provider may create the extension header on ingress to the provider network and then remove on egress. This would reduce the need to distribute policy to all internal provider nodes. For this use case, no standard needs to exist as users and already add custom extension headers.
>
> I believe that initial networks will be (almost) fully trusted. I believe that the User QoS block provides a relatively simple and useful extension for these (early) networks. If it is applicable to large, open, DTN networks needs to be analysed but is not my main concern currently. Of course, everybody can add custom extension header but I believe that QoS is an important topic for interoperability and that we should seek to have something interoperable. I believe it is required for LunaNet scenarios.
>
>    Kind regard,
>
>        Jonathan W.
>
>
> On 5/10/2024 11:54 AM, Sipos, Brian J. via SIS-DTN wrote:
> All,
> After thinking over the last presentation on BP QOS extension block content, specifically the discussion about the reliability code points proposed, I think there may be a more consistent way to name and think about the proposed values.
> The last proposal had values of (from what I remember, in no specific order):
>
> 1.      Required reliable
>
> 2.      Preferred reliable
>
> 3.      Preferred unreliable
>
> 4.      Required unreliable
>
> There was contention about what "required" meant and if they are meaningful values, but I think these can be augmented slightly with the knowledge that BP nodes are expected to store-and-forward as needed, so the code points could be shifted slightly to have these names and definitions which I think are more compatible with both what nodes should do with them and how people can think about them.
>
> 5.      Wait for reliable - Wait (up to the bundle lifetime) for a reliable CL, if one is expected to become available, otherwise use an unreliable CL now.
>
> 6.      Immediate reliable - Forward with a reliable CL if one is available immediately, otherwise use an unreliable CL now.
>
> 7.      Immediate unreliable - Forward with an unreliable CL if one is available immediately, otherwise use a reliable CL now.
>
> 8.      Wait for unreliable - Wait for an unreliable CL, otherwise use a reliable CL now.
>
> I like the idea to allow taking information about upcoming contacts into account (we should say what expected to become available actually means - maybe during the lifetime of the bundle?). We should have a clear definition that 'reliable' means a CL which applies re-transmission if needed and 'un-reliable' a CL which does not re-transmit (ie, data is available in 1 OWLT or never). I would still have the Strictly reliable and Strictly unreliable options (I don't whether all of them make sense but it IMHO it does not harm to include those options).
>
> The key difference here is that nodes have future information about local contact plans and CL availability, and the first and last values allow that information to be used differently. So rather than saying "it has to be reliable or nothing" it's allowing a node to take into account future expected behavior (within the specific bundle's lifetime) to inform its short-term logic.
>
> Not sure if this is helpful, but that kind of distinction might clarify the intent of those code points and make them each more actionable by a node.
> Brian S.
>
>
>
> _______________________________________________
>
> SIS-DTN mailing list
>
> SIS-DTN at mailman.ccsds.org<mailto:SIS-DTN at mailman.ccsds.org>
>
> https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn
>
> This message is intended only for the recipient(s) named above. It may contain proprietary information and/or protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo at esa.int).
>