[Sis-dtn] BPv7 QOS reliability

[Jonathan W]

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.

    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.

    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.

    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.


   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):
>
>   * Required reliable
>   * Preferred reliable
>   * Preferred unreliable
>   * 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.
>
>   * 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.
>   * Immediate reliable – Forward with a reliable CL if one is
>     available immediately, otherwise use an unreliable CL now.
>   * Immediate unreliable – Forward with an unreliable CL if one is
>     available immediately, otherwise use a reliable CL now.
>   * Wait for unreliable – Wait for an unreliable CL, otherwise use a
>     reliable CL now.
>
> 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
> https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20240510/4676c886/attachment-0001.htm>