[Sis-dtn] BPv7 QOS reliability

Tue May 14 12:50:03 UTC 2024

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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20240514/0a9e95e5/attachment-0001.htm>