<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>All,</p>
<p> 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.</p>
<p> 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.</p>
<p> 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.<br>
</p>
<p> 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.</p>
<p> 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.</p>
<p><br>
</p>
<p> Kind regard,</p>
<p> Jonathan W.<br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 5/10/2024 11:54 AM, Sipos, Brian J.
via SIS-DTN wrote:<br>
</div>
<blockquote type="cite"
cite="mid:7e7567594cf04b4d8732bd68ddf4de14@jhuapl.edu">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="Generator"
content="Microsoft Word 15 (filtered medium)">
<style>@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}div.WordSection1
{page:WordSection1;}ol
{margin-bottom:0in;}ul
{margin-bottom:0in;}</style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal">All,<o:p></o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal">The last proposal had values of (from what
I remember, in no specific order):<o:p></o:p></p>
<ul style="margin-top:0in" type="disc">
<li class="MsoListParagraph"
style="margin-left:0in;mso-list:l0 level1 lfo1">Required
reliable<o:p></o:p></li>
<li class="MsoListParagraph"
style="margin-left:0in;mso-list:l0 level1 lfo1">Preferred
reliable<o:p></o:p></li>
<li class="MsoListParagraph"
style="margin-left:0in;mso-list:l0 level1 lfo1">Preferred
unreliable<o:p></o:p></li>
<li class="MsoListParagraph"
style="margin-left:0in;mso-list:l0 level1 lfo1">Required
unreliable<o:p></o:p></li>
</ul>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p>
<ul style="margin-top:0in" type="disc">
<li class="MsoListParagraph"
style="margin-left:0in;mso-list:l0 level1 lfo1">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.<o:p></o:p></li>
<li class="MsoListParagraph"
style="margin-left:0in;mso-list:l0 level1 lfo1">Immediate
reliable – Forward with a reliable CL if one is available
immediately, otherwise use an unreliable CL now.<o:p></o:p></li>
<li class="MsoListParagraph"
style="margin-left:0in;mso-list:l0 level1 lfo1">Immediate
unreliable – Forward with an unreliable CL if one is
available immediately, otherwise use a reliable CL now.<o:p></o:p></li>
<li class="MsoListParagraph"
style="margin-left:0in;mso-list:l0 level1 lfo1">Wait for
unreliable – Wait for an unreliable CL, otherwise use a
reliable CL now.<o:p></o:p></li>
</ul>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal">Brian S.<o:p></o:p></p>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
SIS-DTN mailing list
<a class="moz-txt-link-abbreviated" href="mailto:SIS-DTN@mailman.ccsds.org">SIS-DTN@mailman.ccsds.org</a>
<a class="moz-txt-link-freetext" href="https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn">https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn</a>
</pre>
</blockquote>
</body>
</html>