[Sis-dtn] BPv7 QOS reliability

Thu May 23 07:01:57 UTC 2024

Hi Jonathan,

Yes, I fully agree that all these aspects need to be considered (security, performance, management, scalability, security, traffic shaping, and network stack configuration). And it will not be sufficient to discuss but to analyse and research all these topics in much more detail (and Theresa's PhD thesis would be part of this but probably not the end ...). So, I think it is a process which will take years.

All we want to do now for the Orange Book is to come up with a proposal for a User QoS block (which can be combined with policies) which should be sufficient for scenarios we expect in the next few years. We are currently working on defining reference scenarios for EO, lunar and Mars and want to discuss those as well in one of the next meetings. We should aim at something for QoS which is demonstrated to work in those scenarios. We aim to use the same scenarios for the work on Compressed Status Reporting / Custody and BPSEC / Key Management and I assume that they could be useful for most of the other DTN work being done at CCSDS.

Regards,
Felix

-----Original Message-----
From: Jonathan W <joe.nathan.wilmot at gmail.com>
Sent: Wednesday, May 15, 2024 7:23 PM
To: Felix Flentge <Felix.Flentge at esa.int>; 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

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://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
> man.ccsds.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fsis-dtn&data=05%7C02%7C
> Felix.Flentge%40esa.int%7C43311d1388f9486a3d2508dc7503ae28%7C9a5cacd02
> bef4dd7ac5c7ebe1f54f495%7C0%7C0%7C638513905880792319%7CUnknown%7CTWFpb
> GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
> %3D%7C0%7C%7C%7C&sdata=OrWwLqGOLKv0WrZnsFc3yykPkI5GZwcWidr%2BXCONGuo%3
> D&reserved=0
>
> 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).
>
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).