<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@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;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0cm;
font-size:10.0pt;
font-family:"Courier New";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}
span.EmailStyle23
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
mso-ligatures:none;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:390423130;
mso-list-type:hybrid;
mso-list-template-ids:802733624 134807575 134807577 134807579 134807567 134807577 134807579 134807567 134807577 134807579;}
@list l0:level1
{mso-level-number-format:alpha-lower;
mso-level-text:"%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1
{mso-list-id:448548763;
mso-list-template-ids:1661270420;}
@list l1:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level2
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:72.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level3
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:108.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:144.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level5
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:180.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level6
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:216.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:252.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level8
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:288.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level9
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:324.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2
{mso-list-id:716243753;
mso-list-type:hybrid;
mso-list-template-ids:-2104080514 -251265016 134807555 134807557 134807553 134807555 134807557 134807553 134807555 134807557;}
@list l2:level1
{mso-level-number-format:bullet;
mso-level-text:-;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Calibri",sans-serif;
mso-fareast-font-family:Calibri;}
@list l2:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l2:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l2:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l2:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l2:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l2:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l2:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l2:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l3
{mso-list-id:954991156;
mso-list-template-ids:1401577450;}
@list l3:level1
{mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l3:level2
{mso-level-tab-stop:72.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l3:level3
{mso-level-tab-stop:108.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l3:level4
{mso-level-tab-stop:144.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l3:level5
{mso-level-tab-stop:180.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l3:level6
{mso-level-tab-stop:216.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l3:level7
{mso-level-tab-stop:252.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l3:level8
{mso-level-tab-stop:288.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l3:level9
{mso-level-tab-stop:324.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l4
{mso-list-id:1772165823;
mso-list-template-ids:-1836962002;}
@list l4:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l4:level2
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:72.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l4:level3
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:108.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l4:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:144.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l4:level5
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:180.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l4:level6
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:216.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l4:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:252.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l4:level8
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:288.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l4:level9
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:324.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></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]-->
</head>
<body lang="EN-GB" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Thanks Jonathan and Brian,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Sorry for taking some time to respond. We really appreciate feedback and discussion on the QoS (and all the other) extension.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Please see my comments below.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">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).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal">Regards,<o:p></o:p></p>
<p class="MsoNormal">Felix<o:p></o:p></p>
</div>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal" style="margin-left:36.0pt"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> SIS-DTN <sis-dtn-bounces@mailman.ccsds.org>
<b>On Behalf Of </b>Jonathan W via SIS-DTN<br>
<b>Sent:</b> Friday, May 10, 2024 7:19 PM<br>
<b>To:</b> Sipos, Brian J. <Brian.Sipos@jhuapl.edu>; sis-dtn@mailman.ccsds.org<br>
<b>Cc:</b> teresa.algarra.ulierte <teresa.algarra.ulierte@tuhh.de>; Jain, Peyush (GSFC-4502) <peyush.jain@nasa.gov>; Wilmot, Jonathan J. (GSFC-5800) <jonathan.j.wilmot@nasa.gov><br>
<b>Subject:</b> Re: [Sis-dtn] BPv7 QOS reliability<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal" style="margin-left:36.0pt"><o:p> </o:p></p>
<p style="margin-left:36.0pt">All,<o:p></o:p></p>
<p style="margin-left:36.0pt"> 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.<o:p></o:p></p>
<p style="margin-left:36.0pt"> 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.<o:p></o:p></p>
<p><b><span style="color:#548235;mso-style-textfill-fill-color:#548235;mso-style-textfill-fill-alpha:100.0%">No<o:p></o:p></span></b></p>
<ol start="1" type="a">
<li style="color:#70AD47;mso-list:l0 level1 lfo5"><b><span style="color:#548235;mso-style-textfill-fill-color:#548235;mso-style-textfill-fill-alpha:100.0%"><span style="color:windowtext">User QoS block is only inserted by the source node and can be protected
by BIB (together with primary block) if needed<o:p></o:p></span></span></b></li><li style="color:#70AD47;mso-list:l0 level1 lfo5"><b><span style="color:#548235;mso-style-textfill-fill-color:#548235;mso-style-textfill-fill-alpha:100.0%"><span style="color:windowtext">User QoS blocks can be subject to network SLAs; the requirement is that
user QoS are respected within the respective SLA not absolutely<o:p></o:p></span></span></b></li><li style="color:#70AD47;mso-list:l0 level1 lfo5"><b><span style="color:#548235;mso-style-textfill-fill-color:#548235;mso-style-textfill-fill-alpha:100.0%"><span style="color:windowtext">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 …)<o:p></o:p></span></span></b></li></ol>
<p><o:p> </o:p></p>
<p style="margin-left:36.0pt"> 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.<o:p></o:p></p>
<p><b><span style="color:#548235;mso-style-textfill-fill-color:#548235;mso-style-textfill-fill-alpha:100.0%">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).<o:p></o:p></span></b></p>
<p style="margin-left:36.0pt"> 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.<o:p></o:p></p>
<ul type="disc">
<li style="color:#70AD47;mso-list:l2 level1 lfo6"><b><span style="color:#548235;mso-style-textfill-fill-color:#548235;mso-style-textfill-fill-alpha:100.0%"><span style="color:windowtext">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<o:p></o:p></span></span></b></li><li style="color:#70AD47;mso-list:l2 level1 lfo6"><b><span style="color:#548235;mso-style-textfill-fill-color:#548235;mso-style-textfill-fill-alpha:100.0%"><span style="color:windowtext">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<o:p></o:p></span></span></b></li><li style="color:#70AD47;mso-list:l2 level1 lfo6"><b><span style="color:#548235;mso-style-textfill-fill-color:#548235;mso-style-textfill-fill-alpha:100.0%"><span style="color:windowtext">Policies can change dynamically which reduces predictability<o:p></o:p></span></span></b></li><li style="color:#70AD47;mso-list:l2 level1 lfo6"><b><span style="color:#548235;mso-style-textfill-fill-color:#548235;mso-style-textfill-fill-alpha:100.0%"><span style="color:windowtext">QoS based on policies does not scale<o:p></o:p></span></span></b></li><li style="color:#70AD47;mso-list:l2 level1 lfo6"><b><span style="color:#548235;mso-style-textfill-fill-color:#548235;mso-style-textfill-fill-alpha:100.0%"><span style="color:windowtext">Users wanting to change priorities for certain traffic will need to ask
all involved nodes to update their policies<o:p></o:p></span></span></b></li></ul>
<p><b><span style="color:#548235;mso-style-textfill-fill-color:#548235;mso-style-textfill-fill-alpha:100.0%">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).<o:p></o:p></span></b></p>
<p style="margin-left:36.0pt"> 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.<o:p></o:p></p>
<p><b><span style="color:#548235;mso-style-textfill-fill-color:#548235;mso-style-textfill-fill-alpha:100.0%">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.<o:p></o:p></span></b></p>
<p style="margin-left:36.0pt"> Kind regard,<o:p></o:p></p>
<p style="margin-left:36.0pt"> Jonathan W.<o:p></o:p></p>
<p style="margin-left:36.0pt"><o:p> </o:p></p>
<div>
<p class="MsoNormal" style="margin-left:36.0pt">On 5/10/2024 11:54 AM, Sipos, Brian J. via SIS-DTN wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal" style="margin-left:36.0pt">All,<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">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" style="margin-left:36.0pt">The last proposal had values of (from what I remember, in no specific order):<o:p></o:p></p>
<p class="MsoListParagraph" style="margin-left:72.0pt;text-indent:-18.0pt;mso-list:l3 level1 lfo3">
<![if !supportLists]><span style="mso-list:Ignore">1.<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>Required reliable<o:p></o:p></p>
<p class="MsoListParagraph" style="margin-left:72.0pt;text-indent:-18.0pt;mso-list:l3 level1 lfo3">
<![if !supportLists]><span style="mso-list:Ignore">2.<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>Preferred reliable<o:p></o:p></p>
<p class="MsoListParagraph" style="margin-left:72.0pt;text-indent:-18.0pt;mso-list:l3 level1 lfo3">
<![if !supportLists]><span style="mso-list:Ignore">3.<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>Preferred unreliable<o:p></o:p></p>
<p class="MsoListParagraph" style="margin-left:72.0pt;text-indent:-18.0pt;mso-list:l3 level1 lfo3">
<![if !supportLists]><span style="mso-list:Ignore">4.<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>Required unreliable<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt"> <o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">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>
<p class="MsoListParagraph" style="margin-left:72.0pt;text-indent:-18.0pt;mso-list:l3 level1 lfo3">
<![if !supportLists]><span style="mso-list:Ignore">5.<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>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></p>
<p class="MsoListParagraph" style="margin-left:72.0pt;text-indent:-18.0pt;mso-list:l3 level1 lfo3">
<![if !supportLists]><span style="mso-list:Ignore">6.<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>Immediate reliable – Forward with a reliable CL if one is available immediately, otherwise use an unreliable CL now.<o:p></o:p></p>
<p class="MsoListParagraph" style="margin-left:72.0pt;text-indent:-18.0pt;mso-list:l3 level1 lfo3">
<![if !supportLists]><span style="mso-list:Ignore">7.<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>Immediate unreliable – Forward with an unreliable CL if one is available immediately, otherwise use a reliable CL now.<o:p></o:p></p>
<p class="MsoListParagraph" style="margin-left:72.0pt;text-indent:-18.0pt;mso-list:l3 level1 lfo3">
<![if !supportLists]><span style="mso-list:Ignore">8.<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>Wait for unreliable – Wait for an unreliable CL, otherwise use a reliable CL now.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:5.0pt;margin-right:36.0pt;margin-bottom:5.0pt;margin-left:0cm">
<o:p> </o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:5.0pt;margin-right:36.0pt;margin-bottom:5.0pt;margin-left:0cm">
<b><span style="color:#548235;mso-style-textfill-fill-color:#548235;mso-style-textfill-fill-alpha:100.0%">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).<o:p></o:p></span></b></p>
<p class="MsoNormal" style="margin-left:36.0pt"> <o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">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" style="margin-left:36.0pt"> <o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">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" style="margin-left:36.0pt">Brian S.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt"><br>
<br>
<o:p></o:p></p>
<pre style="margin-left:36.0pt">_______________________________________________<o:p></o:p></pre>
<pre style="margin-left:36.0pt">SIS-DTN mailing list<o:p></o:p></pre>
<pre style="margin-left:36.0pt"><a href="mailto:SIS-DTN@mailman.ccsds.org">SIS-DTN@mailman.ccsds.org</a><o:p></o:p></pre>
<pre style="margin-left:36.0pt"><a href="https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn">https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn</a><o:p></o:p></pre>
</blockquote>
</div>
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@esa.int).
</body>
</html>