<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)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><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:"Segoe UI";
panose-1:2 11 5 2 4 2 4 2 2 3;}
@font-face
{font-family:"Segoe UI Light";
panose-1:2 11 5 2 4 2 4 2 2 3;}
/* 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;}
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.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@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:93482794;
mso-list-type:hybrid;
mso-list-template-ids:989070718 127304250 134807577 134807579 134807567 134807577 134807579 134807567 134807577 134807579;}
@list l0:level1
{mso-level-number-format:alpha-upper;
mso-level-text:"%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ascii-font-family:Calibri;
mso-fareast-font-family:Calibri;
mso-hansi-font-family:Calibri;
mso-bidi-font-family:"Times New Roman";}
@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:1014377284;
mso-list-type:hybrid;
mso-list-template-ids:1267123150 244080046 134807577 134807579 134807567 134807577 134807579 134807567 134807577 134807579;}
@list l1:level1
{mso-level-number-format:alpha-upper;
mso-level-text:"%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:32.2pt;
text-indent:-18.0pt;}
@list l1:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:68.2pt;
text-indent:-18.0pt;}
@list l1:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
margin-left:104.2pt;
text-indent:-9.0pt;}
@list l1:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:140.2pt;
text-indent:-18.0pt;}
@list l1:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:176.2pt;
text-indent:-18.0pt;}
@list l1:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
margin-left:212.2pt;
text-indent:-9.0pt;}
@list l1:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:248.2pt;
text-indent:-18.0pt;}
@list l1:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:284.2pt;
text-indent:-18.0pt;}
@list l1:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
margin-left:320.2pt;
text-indent:-9.0pt;}
@list l2
{mso-list-id:1308709527;
mso-list-template-ids:1234979662;}
@list l2: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 l2:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:72.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l2:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:108.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l2:level4
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:144.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l2:level5
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:180.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l2:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:216.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l2:level7
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:252.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l2:level8
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:288.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l2:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:324.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l3
{mso-list-id:1492407021;
mso-list-type:hybrid;
mso-list-template-ids:583201910 134807553 134807555 134807557 134807553 134807555 134807557 134807553 134807555 134807557;}
@list l3:level1
{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 l3: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 l3: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 l3: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 l3: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 l3: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 l3: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 l3: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 l3: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;}
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">Hi,<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">I would like to share what I have already sent to smaller audience (sorry for the repetition; it seems that part of the email thread did not go the mailing list).<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">What is important to me is that<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<ol style="margin-top:0cm" start="1" type="A">
<li class="MsoListParagraph" style="margin-left:0cm;mso-list:l0 level1 lfo6"><span style="mso-fareast-language:EN-US">Not-LTPv2 does not impose any restrictions on block sizes and does provide the same service interface for reliable and unreliable sessions:<br>
“</span><span style="mso-fareast-language:EN-US">In my view, for the new protocol, the main use for unreliable ‘not-LTP’ is not minimized delay:<o:p></o:p></span></li><ol style="margin-top:0cm" start="1" type="a">
<li class="MsoListParagraph" style="margin-left:0cm;mso-list:l0 level2 lfo6"><span style="mso-fareast-language:EN-US">Reliable or unreliable not-LTP with rangeReceived.indication can be used to minimize delay (and with small blocks to fit a segment if you like)<o:p></o:p></span></li><li class="MsoListParagraph" style="margin-left:0cm;mso-list:l0 level2 lfo6"><span style="mso-fareast-language:EN-US">Use cases for unreliable LTP include situations where you don’t have a return link available. This can be cases where you have a very re-liable
forward link. This is why we have the same service interface for reliable and un-reliable not-LTP.”</span><span style="mso-fareast-language:EN-US"><br>
<br>
</span><span style="mso-fareast-language:EN-US"><o:p></o:p></span></li></ol>
<li class="MsoListParagraph" style="margin-left:0cm;mso-list:l0 level1 lfo6"><span style="mso-fareast-language:EN-US">Not-LTPv2 does not need to have access to a contact plan:<o:p></o:p></span></li></ol>
<p class="MsoListParagraph"><span style="mso-fareast-language:EN-US">“</span><span style="mso-fareast-language:EN-US">The decision when to consider an unreliable (non-LTP) session closed may also be implementation-specific (but we should require that something
is implemented): it may be based on a timer, an external event (end of a communication session) or the arrival of a segment for a new session (un-reliable or maybe even reliable). However, we should avoid to put any constraints regarding the number of parallel
sessions or how segments of different sessions are multi-plexed as this depends on various factors (conops, resource constraints, link characteristics, …).”<br>
I think this could be solved in the same way as the link state procedures in CFDP (notifications of link state via MIB). They way / events how these link states are changed in the MIB is outside the protocol.</span><span style="mso-fareast-language:EN-US"><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"> Sanchez Net, Marc (US 332H) <marc.sanchez.net@jpl.nasa.gov>
<br>
<b>Sent:</b> Wednesday, May 31, 2023 2:55 PM<br>
<b>To:</b> Jeremy.Mayer@dlr.de; sburleig.sb@gmail.com; Torgerson, J. Leigh (US 332C) <jordan.l.torgerson@jpl.nasa.gov>; Felix Flentge <Felix.Flentge@esa.int>; sis-dtn@mailman.ccsds.org; keithlscott@gmail.com<br>
<b>Subject:</b> RE: [Sis-dtn] [EXTERNAL] RE: New version of LTP Corrigendum<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal" style="margin-left:36.0pt"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-US">I am unconvinced either way, to be honest. I agree with Jeremy forcing the LTP engine to know the contact plan is not great, but having another “stale session timeout” seems an equally non-ideal
solution. Would all these problems “go away” if we force in the spec that a green block always be transmitted as a single green segment? But then the block size must be matched to the underlying link MTU (or transmission size used by the mission) which is
<=65 kB for transfer frames, I believe. Would that be too restrictive if we sent streaming video over LTP green?<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-US">-----------------------------------------------------------------------------------------------------------------------<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-US">Marc Sanchez Net (332H)<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-US" style="font-size:10.0pt;color:gray">Telecommunications Engineer</span><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt;background:white"><span lang="EN-US" style="font-size:10.0pt;color:gray">Jet Propulsion Laboratory<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt;background:white"><span lang="EN-US" style="font-size:10.0pt;color:gray">Cell:</span><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#222222"> </span><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black"><a href="mailto:(617)%20953-7977"><span style="color:#0563C1">(617)
953-7977</span></a></span><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#0070C0">
</span><span lang="EN-US" style="font-size:10.0pt;color:gray">|</span><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#0070C0">
</span><span lang="EN-US" style="font-size:10.0pt;color:gray">Email:</span><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#222222"> </span><span lang="EN-US" style="color:black"><a href="mailto:marc.sanchez.net@jpl.nasa.gov"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">marc.sanchez.net@jpl.nasa.gov</span></a></span><span lang="EN-US" style="font-size:9.5pt;font-family:"Arial",sans-serif;color:#222222"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-US">-----------------------------------------------------------------------------------------------------------------------<o:p></o:p></span></p>
</div>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="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">
<a href="mailto:Jeremy.Mayer@dlr.de">Jeremy.Mayer@dlr.de</a> <<a href="mailto:Jeremy.Mayer@dlr.de">Jeremy.Mayer@dlr.de</a>>
<br>
<b>Sent:</b> Wednesday, May 31, 2023 1:05 AM<br>
<b>To:</b> <a href="mailto:sburleig.sb@gmail.com">sburleig.sb@gmail.com</a>; Sanchez Net, Marc (US 332H) <<a href="mailto:marc.sanchez.net@jpl.nasa.gov">marc.sanchez.net@jpl.nasa.gov</a>>; Torgerson, J. Leigh (US 332C) <<a href="mailto:jordan.l.torgerson@jpl.nasa.gov">jordan.l.torgerson@jpl.nasa.gov</a>>;
<a href="mailto:Felix.Flentge@esa.int">Felix.Flentge@esa.int</a>; <a href="mailto:sis-dtn@mailman.ccsds.org">
sis-dtn@mailman.ccsds.org</a>; <a href="mailto:keithlscott@gmail.com">keithlscott@gmail.com</a><br>
<b>Subject:</b> RE: [Sis-dtn] [EXTERNAL] RE: New version of LTP Corrigendum<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt">Hi,<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">Realistically, I agree, the LTP engine should probably be aware of either the contact plan OR the status of the downlink. That being said, I don’t think that’s a dependency which we want to force, due to the “perpetual
downlink” use-case (ISS). There’s nothing stopping me from running a single LTP link from now until the end of time, unaware of the status of the underlying link. Of course, there’s the caveat that green sessions may be transmitted into the void, never to
be seen again.<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">That being said, the “last green block” problem is insidious: In a nominal downlink (e.g. with minimal out-of-order arrival and loss), we can use the EOB as a signal that the block should be delivered. However,
if the EOB is out-of-order, there’s a problem: the application shouldn’t have to expect that data from the same session may arrive twice. The only way to really deal with this in the face of out-of-order/missing arrivals is to track the completeness of a green
session. If the EOB block is delivered while data is still missing, we ignore it and “hold” the session until a user-specified timeout. In LTPv2, we called this the “stale session timeout”. If more data is delivered into one of these pending sessions, it can
still be enqueued and delivered upon timeout. This allows us to treat out of order sessions and those where the EOB is missed in the same way.<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">Thanks,<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">Jeremy<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt"><o:p> </o:p></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 <<a href="mailto:sis-dtn-bounces@mailman.ccsds.org">sis-dtn-bounces@mailman.ccsds.org</a>>
<b>On Behalf Of </b>sburleig.sb--- via SIS-DTN<br>
<b>Sent:</b> Tuesday, May 30, 2023 11:55 PM<br>
<b>To:</b> 'Sanchez Net, Marc (US 332H)' <<a href="mailto:marc.sanchez.net@jpl.nasa.gov">marc.sanchez.net@jpl.nasa.gov</a>>; 'Torgerson, J. Leigh (US 332C)' <<a href="mailto:jordan.l.torgerson@jpl.nasa.gov">jordan.l.torgerson@jpl.nasa.gov</a>>; 'Felix Flentge'
<<a href="mailto:Felix.Flentge@esa.int">Felix.Flentge@esa.int</a>>; 'Dr. Keith L Scott via SIS-DTN' <<a href="mailto:sis-dtn@mailman.ccsds.org">sis-dtn@mailman.ccsds.org</a>>;
<a href="mailto:keithlscott@gmail.com">keithlscott@gmail.com</a><br>
<b>Subject:</b> Re: [Sis-dtn] [EXTERNAL] RE: New version of LTP Corrigendum<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-US">Marc, good question. My thought on this is that LTP needs to be aware of the “contact plan” in order to know when to pause and resume the “red” timers. Given this, the LTP engine should be
able to infer that cessation of green block segment reception is due to the termination of the pass. At that point we have a matter of policy. If it’s known that green block transmission is always supposed to happen far enough before the end of the pass
to enable complete reception, then the end of the pass signifies that any currently incomplete block is not going to be completed and the block’s current incomplete contents can be delivered. If not, then maybe the current state of that incomplete final block
should be sustained until the start of the next pass enables further reception of that block’s segments.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-US">Of course, sticking to small green blocks that are transmitted in single green segments makes the whole issue go away.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-US">Scott<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="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"> Sanchez Net, Marc (US 332H) <<a href="mailto:marc.sanchez.net@jpl.nasa.gov">marc.sanchez.net@jpl.nasa.gov</a>>
<br>
<b>Sent:</b> Tuesday, May 30, 2023 1:18 PM<br>
<b>To:</b> <a href="mailto:sburleig.sb@gmail.com">sburleig.sb@gmail.com</a>; Torgerson, J. Leigh (US 332C) <<a href="mailto:jordan.l.torgerson@jpl.nasa.gov">jordan.l.torgerson@jpl.nasa.gov</a>>; 'Felix Flentge' <<a href="mailto:Felix.Flentge@esa.int">Felix.Flentge@esa.int</a>>;
'Dr. Keith L Scott via SIS-DTN' <<a href="mailto:sis-dtn@mailman.ccsds.org">sis-dtn@mailman.ccsds.org</a>>;
<a href="mailto:keithlscott@gmail.com">keithlscott@gmail.com</a><br>
<b>Cc:</b> Gao, Jay L (US 332C) <<a href="mailto:jay.l.gao@jpl.nasa.gov">jay.l.gao@jpl.nasa.gov</a>>; Richard, Nate J (US 332C) <<a href="mailto:nathaniel.j.richard@jpl.nasa.gov">nathaniel.j.richard@jpl.nasa.gov</a>><br>
<b>Subject:</b> RE: [EXTERNAL] RE: [Sis-dtn] New version of LTP Corrigendum<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-US">All,<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-US">A quick update to the draft LTP corrigendum with a few more items to make sure some of the issues being brought up in this email chain don’t fall through the cracks.
<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-US">Also, a minor note on Scott’s comment that “<i>the arrival of the first segment of the next “green” block is a simpler and perhaps more accurate (configuration-free) means of determining that
it is time to deliver the current block</i>”: How does the receiving LTP engine handle the very last LTP block of a pass? Without a timer, would it ever be released to the application? I hate to add new timers, but I do not see how to get around it in this
this corner case.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-US">-----------------------------------------------------------------------------------------------------------------------<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-US">Marc Sanchez Net (332H)<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-US" style="font-size:10.0pt;color:gray">Telecommunications Engineer</span><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt;background:white"><span lang="EN-US" style="font-size:10.0pt;color:gray">Jet Propulsion Laboratory<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt;background:white"><span lang="EN-US" style="font-size:10.0pt;color:gray">Cell:</span><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#222222"> </span><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black"><a href="mailto:(617)%20953-7977"><span style="color:#0563C1">(617)
953-7977</span></a></span><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#0070C0">
</span><span lang="EN-US" style="font-size:10.0pt;color:gray">|</span><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#0070C0">
</span><span lang="EN-US" style="font-size:10.0pt;color:gray">Email:</span><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#222222"> </span><span lang="EN-US" style="color:black"><a href="mailto:marc.sanchez.net@jpl.nasa.gov"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">marc.sanchez.net@jpl.nasa.gov</span></a></span><span lang="EN-US" style="font-size:9.5pt;font-family:"Arial",sans-serif;color:#222222"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-US">-----------------------------------------------------------------------------------------------------------------------<o:p></o:p></span></p>
</div>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="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">
<a href="mailto:sburleig.sb@gmail.com">sburleig.sb@gmail.com</a> <<a href="mailto:sburleig.sb@gmail.com">sburleig.sb@gmail.com</a>>
<br>
<b>Sent:</b> Tuesday, May 30, 2023 8:13 AM<br>
<b>To:</b> Torgerson, J. Leigh (US 332C) <<a href="mailto:jordan.l.torgerson@jpl.nasa.gov">jordan.l.torgerson@jpl.nasa.gov</a>>; 'Felix Flentge' <<a href="mailto:Felix.Flentge@esa.int">Felix.Flentge@esa.int</a>>; Sanchez Net, Marc (US 332H) <<a href="mailto:marc.sanchez.net@jpl.nasa.gov">marc.sanchez.net@jpl.nasa.gov</a>>;
'Dr. Keith L Scott via SIS-DTN' <<a href="mailto:sis-dtn@mailman.ccsds.org">sis-dtn@mailman.ccsds.org</a>><br>
<b>Cc:</b> Gao, Jay L (US 332C) <<a href="mailto:jay.l.gao@jpl.nasa.gov">jay.l.gao@jpl.nasa.gov</a>>; Richard, Nate J (US 332C) <<a href="mailto:nathaniel.j.richard@jpl.nasa.gov">nathaniel.j.richard@jpl.nasa.gov</a>><br>
<b>Subject:</b> RE: [EXTERNAL] RE: [Sis-dtn] New version of LTP Corrigendum<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-US">Guys, a thought on this.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-US">In “red” transmission you expect out-of-order segment arrival on a routine basis, because every retransmitted bundle will arrive out of order. There are timers in the protocol to support the
operation of the retransmission procedures.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-US">In “green” transmission you cannot have out-of-order segment arrival if you size your blocks in such a way that each block is transmitted in a single segment. I believe users will typically
adopt this model, as “green” data will normally be data for which minimized delay is more important than reliability (otherwise they would use “red” transmission).<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-US">In “green” transmission where the blocks are large enough to require transmission in multiple segments you have to wait for an entire block to arrive – or until you are confident that any missing
segments were actually lost rather than simply forwarded out of order – before delivering the contents of the block. But there’s no re-transmission to avoid, because the transmission is “green”, right? If you wanted retransmission you would have used “red”.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-US">So in that event I would suggest that the arrival of the first segment of the next “green” block is a simpler and perhaps more accurate (configuration-free) means of determining that it is time
to deliver the current block – complete or incomplete – and let the application figure out what to do about the missing data.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-US">Scott<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="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"> Torgerson, J. Leigh (US 332C) <<a href="mailto:jordan.l.torgerson@jpl.nasa.gov">jordan.l.torgerson@jpl.nasa.gov</a>>
<br>
<b>Sent:</b> Tuesday, May 30, 2023 7:54 AM<br>
<b>To:</b> Felix Flentge <<a href="mailto:Felix.Flentge@esa.int">Felix.Flentge@esa.int</a>>;
<a href="mailto:sburleig.sb@gmail.com">sburleig.sb@gmail.com</a>; Sanchez Net, Marc (US 332H) <<a href="mailto:marc.sanchez.net@jpl.nasa.gov">marc.sanchez.net@jpl.nasa.gov</a>>; 'Dr. Keith L Scott via SIS-DTN' <<a href="mailto:sis-dtn@mailman.ccsds.org">sis-dtn@mailman.ccsds.org</a>><br>
<b>Cc:</b> Gao, Jay L (US 332C) <<a href="mailto:jay.l.gao@jpl.nasa.gov">jay.l.gao@jpl.nasa.gov</a>>; Richard, Nate J (US 332C) <<a href="mailto:nathaniel.j.richard@jpl.nasa.gov">nathaniel.j.richard@jpl.nasa.gov</a>><br>
<b>Subject:</b> Re: [EXTERNAL] RE: [Sis-dtn] New version of LTP Corrigendum<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-US">Thanks Felix –
<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-US">Agreed - A statement warning about how implementations should be wary of out-of-order deliveries would be useful in the corrigendum..<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-US">regards,<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-US">Leigh<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal" style="margin-left:36.0pt"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">Felix Flentge <<a href="mailto:Felix.Flentge@esa.int">Felix.Flentge@esa.int</a>><br>
<b>Date: </b>Monday, May 29, 2023 at 11:47 PM<br>
<b>To: </b>"Torgerson, Jordan L (332M)" <<a href="mailto:jordan.l.torgerson@jpl.nasa.gov">jordan.l.torgerson@jpl.nasa.gov</a>>, "<a href="mailto:sburleig.sb@gmail.com">sburleig.sb@gmail.com</a>" <<a href="mailto:sburleig.sb@gmail.com">sburleig.sb@gmail.com</a>>,
"Sanchez Net, Marc (US 332H)" <<a href="mailto:marc.sanchez.net@jpl.nasa.gov">marc.sanchez.net@jpl.nasa.gov</a>>, "'Dr. Keith L Scott via SIS-DTN'" <<a href="mailto:sis-dtn@mailman.ccsds.org">sis-dtn@mailman.ccsds.org</a>><br>
<b>Cc: </b>"Gao, Jay L (US 332C)" <<a href="mailto:jay.l.gao@jpl.nasa.gov">jay.l.gao@jpl.nasa.gov</a>>, "Richard, Nate J (US 332C)" <<a href="mailto:nathaniel.j.richard@jpl.nasa.gov">nathaniel.j.richard@jpl.nasa.gov</a>><br>
<b>Subject: </b>RE: [EXTERNAL] RE: [Sis-dtn] New version of LTP Corrigendum<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><o:p> </o:p></p>
</div>
<p class="MsoNormal" style="margin-left:36.0pt">Hi Leigh,<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">Yes, we also have systematic out-of-order in EO or L2 missions as different physical channels may be used (with maybe different rates and different PDU sizes). With ‘implementation issue’ I don’t mean that it
is not important but I would like to avoid making it normative as we want to avoid ‘changing the standard’ which would require interop testing.<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">By any means, we should have a statement that in case you may have out-of-order delivery it is recommended to implement timer to wait for out-of-order segments to avoid re-transmission (we will add a similar statement
to CFDP for the next release).<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt"><o:p> </o:p></p>
<div>
<p class="MsoNormal" style="margin-left:36.0pt">Regards,<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">Felix<o:p></o:p></p>
</div>
<p class="MsoNormal" style="margin-left:36.0pt"><o:p> </o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal" style="margin-left:72.0pt"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> Torgerson, J. Leigh (US 332C) <<a href="mailto:jordan.l.torgerson@jpl.nasa.gov">jordan.l.torgerson@jpl.nasa.gov</a>>
<br>
<b>Sent:</b> Thursday, May 25, 2023 6:22 PM<br>
<b>To:</b> Felix Flentge <<a href="mailto:Felix.Flentge@esa.int">Felix.Flentge@esa.int</a>>;
<a href="mailto:sburleig.sb@gmail.com">sburleig.sb@gmail.com</a>; Sanchez Net, Marc (US 332H) <<a href="mailto:marc.sanchez.net@jpl.nasa.gov">marc.sanchez.net@jpl.nasa.gov</a>>; 'Dr. Keith L Scott via SIS-DTN' <<a href="mailto:sis-dtn@mailman.ccsds.org">sis-dtn@mailman.ccsds.org</a>><br>
<b>Cc:</b> Gao, Jay L (US 332C) <<a href="mailto:jay.l.gao@jpl.nasa.gov">jay.l.gao@jpl.nasa.gov</a>>; Richard, Nate J (US 332C) <<a href="mailto:nathaniel.j.richard@jpl.nasa.gov">nathaniel.j.richard@jpl.nasa.gov</a>><br>
<b>Subject:</b> Re: [EXTERNAL] RE: [Sis-dtn] New version of LTP Corrigendum<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal" style="margin-left:72.0pt"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:72.0pt"><span lang="EN-US">Thanks Felix –
<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:72.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:72.0pt"><span lang="EN-US">One comment is that in deep space use of DTN, we would expect that out-of-order delivery would be the rule, rather than the exception – if it takes 40 min RTT to recover a missing segment from
Mars, waiting for it to ensure in-order delivery to some application would make ops impossible. (One must design one’s applications to be “aware” of the operational environment of course..)<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:72.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:72.0pt"><span lang="EN-US">We haven’t used both LTP red/green at the same time in our testing and real-world ops as far as I know, but I suspect that recommending that red and green be in different sessions would be a
good idea, if nothing else but to make troubleshooting easier! (Nate and Jay may have some thoughts based on our lunar ops with KPLO so I cc:d them..)<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:72.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:72.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:72.0pt"><span lang="EN-US">regards<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:72.0pt"><span lang="EN-US">Leigh<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:72.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal" style="margin-left:72.0pt"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">Felix Flentge <<a href="mailto:Felix.Flentge@esa.int">Felix.Flentge@esa.int</a>><br>
<b>Date: </b>Thursday, May 25, 2023 at 4:56 AM<br>
<b>To: </b>"<a href="mailto:sburleig.sb@gmail.com">sburleig.sb@gmail.com</a>" <<a href="mailto:sburleig.sb@gmail.com">sburleig.sb@gmail.com</a>>, "Sanchez Net, Marc (US 332H)" <<a href="mailto:marc.sanchez.net@jpl.nasa.gov">marc.sanchez.net@jpl.nasa.gov</a>>,
"'Dr. Keith L Scott via SIS-DTN'" <<a href="mailto:sis-dtn@mailman.ccsds.org">sis-dtn@mailman.ccsds.org</a>><br>
<b>Cc: </b>"Torgerson, Jordan L (332M)" <<a href="mailto:jordan.l.torgerson@jpl.nasa.gov">jordan.l.torgerson@jpl.nasa.gov</a>><br>
<b>Subject: </b>[EXTERNAL] RE: [Sis-dtn] New version of LTP Corrigendum<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:72.0pt"><o:p> </o:p></p>
</div>
<p class="MsoNormal" style="margin-left:72.0pt">Hi,<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:72.0pt"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:72.0pt">I agree with the modifications below.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:72.0pt"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:72.0pt">Some additional points:<o:p></o:p></p>
<p class="MsoListParagraph" style="margin-left:108.0pt;text-indent:-18.0pt;mso-list:l3 level1 lfo2">
<![if !supportLists]><span style="font-family:Symbol"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]>I would propose to also deprecate Service Data Aggregation (it is currently mandatory). Unless, I am overlooking something, it is not an interoperable mechanism as there is no generic way to determine the length of a client data
capsule. Also, for BP/LTP the updated BP standard will describe an aggregation mechanism (CBOR length information + bundle IIRC).<o:p></o:p></p>
<p class="MsoListParagraph" style="margin-left:108.0pt;text-indent:-18.0pt;mso-list:l3 level1 lfo2">
<![if !supportLists]><span style="font-family:Symbol"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]>Should we discourage use of mixed sessions (on the other hand LTP green is optional anyway)?<o:p></o:p></p>
<p class="MsoListParagraph" style="margin-left:108.0pt;text-indent:-18.0pt;mso-list:l3 level1 lfo2">
<![if !supportLists]><span style="font-family:Symbol"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]>For the two additional issues, we could add that this is an implementation issue and that implementation may want to introduce these additional timers in case they (routinely) expect out-of-order delivery<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:72.0pt"><o:p> </o:p></p>
<div>
<p class="MsoNormal" style="margin-left:72.0pt">Regards,<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:72.0pt">Felix<o:p></o:p></p>
</div>
<p class="MsoNormal" style="margin-left:72.0pt"><o:p> </o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal" style="margin-left:108.0pt"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> SIS-DTN <<a href="mailto:sis-dtn-bounces@mailman.ccsds.org">sis-dtn-bounces@mailman.ccsds.org</a>>
<b>On Behalf Of </b>sburleig.sb--- via SIS-DTN<br>
<b>Sent:</b> Thursday, May 18, 2023 1:23 AM<br>
<b>To:</b> 'Sanchez Net, Marc (US 332H)' <<a href="mailto:marc.sanchez.net@jpl.nasa.gov">marc.sanchez.net@jpl.nasa.gov</a>>; 'Dr. Keith L Scott via SIS-DTN' <<a href="mailto:sis-dtn@mailman.ccsds.org">sis-dtn@mailman.ccsds.org</a>><br>
<b>Cc:</b> 'Torgerson, J. Leigh (US 332C)' <<a href="mailto:jordan.l.torgerson@jpl.nasa.gov">jordan.l.torgerson@jpl.nasa.gov</a>><br>
<b>Subject:</b> Re: [Sis-dtn] New version of LTP Corrigendum<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal" style="margin-left:108.0pt"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:108.0pt"><span lang="EN-US">Marc, FWIW, I agree about deprecating LTP security and I am likewise skeptical that adding more timers is a good idea; that sounds like a way to work around a design element that hasn’t been
thought through completely.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:108.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:108.0pt"><span lang="EN-US">Scott<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:108.0pt"><span lang="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:108.0pt"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> SIS-DTN <<a href="mailto:sis-dtn-bounces@mailman.ccsds.org">sis-dtn-bounces@mailman.ccsds.org</a>>
<b>On Behalf Of </b>Sanchez Net, Marc (US 332H) via SIS-DTN<br>
<b>Sent:</b> Tuesday, May 16, 2023 7:05 PM<br>
<b>To:</b> Dr. Keith L Scott via SIS-DTN <<a href="mailto:sis-dtn@mailman.ccsds.org">sis-dtn@mailman.ccsds.org</a>><br>
<b>Cc:</b> Torgerson, J. Leigh (US 332C) <<a href="mailto:jordan.l.torgerson@jpl.nasa.gov">jordan.l.torgerson@jpl.nasa.gov</a>><br>
<b>Subject:</b> [Sis-dtn] New version of LTP Corrigendum<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal" style="margin-left:108.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal" style="margin-left:108.0pt"><span lang="EN-US" style="color:black">All,<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:108.0pt"><span lang="EN-US" style="color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:108.0pt"><span lang="EN-US" style="color:black">Please find attached a new version of the LTP corrigendum with some modifications including:<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:144.0pt;text-indent:-18.0pt;mso-list:l2 level1 lfo4">
<![if !supportLists]><span lang="EN-US" style="font-size:10.0pt;font-family:Symbol;color:black"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span lang="EN-US" style="color:black">Comparison between LTP and "the new protocol" has been reduced. This in part motivated by the fact that we have demonstrated ~4 Gbps rates with ION's LTP implementation, which is more than
sufficient for deep space links (e.g., even in future trunk lines between Earth and Mars, data rates of 4 Gbps are never exceeded).<o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:144.0pt;text-indent:-18.0pt;mso-list:l2 level1 lfo4">
<![if !supportLists]><span lang="EN-US" style="font-size:10.0pt;font-family:Symbol;color:black"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span lang="EN-US" style="color:black">I have added two possible additions to the technical corrigendum based on work done by Brian and people at GRC. They are all optional (MAY) statements and I believe can be implemented without
additional managed parameters (and timers).<o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:144.0pt;text-indent:-18.0pt;mso-list:l2 level1 lfo4">
<![if !supportLists]><span lang="EN-US" style="font-size:10.0pt;font-family:Symbol;color:black"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span lang="EN-US" style="color:black">Brian has commented on two additional issues (see
<a href="https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/22__;!!PvBDto6Hs4WbVuu7!J3wEpyPHlAiGcXO0VDc8uO1zb9BOrpYLw3dw6BHPigpmcy0Q4f8gxX6hHLnQOqg_AVxEg_MYrByNRr1urhAp-KViTuP33vk9LEw4$" title="https://github.com/nasa/HDTN/issues/22">
here</a> and <a href="https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/24__;!!PvBDto6Hs4WbVuu7!J3wEpyPHlAiGcXO0VDc8uO1zb9BOrpYLw3dw6BHPigpmcy0Q4f8gxX6hHLnQOqg_AVxEg_MYrByNRr1urhAp-KViTuP33uBoiHHY$" title="https://github.com/nasa/HDTN/issues/24">
here</a>), but those seem to require additional timers that would need to be managed, so I am unconvinced it is worth the extra complexity. Brian, please correct me if I am wrong.<o:p></o:p></span></p>
<div>
<p class="MsoNormal" style="margin-left:108.0pt"><span lang="EN-US" style="color:black">Finally, I think the note at the beginning of Section 3.9 of the current CCSDS LTP spec should be modified to explicitly state that LTP security should not be used and,
instead, implementers should rely on security mechanisms provided by other parts of the CCSDS protocol stack, be it SDLS or BPSec. Thoughts on this point? <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:108.0pt"><span lang="EN-US" style="color:black"><o:p> </o:p></span></p>
</div>
<div>
<div>
<div style="margin-top:12.0pt;margin-bottom:12.0pt;min-width: 424px" id="LPBorder_GTaHR0cHM6Ly9naXRodWIuY29tL25hc2EvSERUTi9pc3N1ZXMvMjQ.">
<table class="MsoNormalTable" border="1" cellspacing="4" cellpadding="0" width="100%" style="width:100.0%;margin-left:108.0pt;border:solid #C8C8C8 1.0pt">
<tbody>
<tr>
<td valign="top" style="border:none;padding:9.0pt 27.0pt 9.0pt 9.0pt">
<div style="margin-right:9.0pt;overflow:hidden" id="LPImageContainer765850">
<p class="MsoNormal"><a href="https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/24__;!!PvBDto6Hs4WbVuu7!J3wEpyPHlAiGcXO0VDc8uO1zb9BOrpYLw3dw6BHPigpmcy0Q4f8gxX6hHLnQOqg_AVxEg_MYrByNRr1urhAp-KViTuP33uBoiHHY$" target="_blank"><span style="border:solid windowtext 1.0pt;padding:0cm;text-decoration:none"><img border="0" width="240" height="120" style="width:2.5in;height:1.25in" id="_x0000_i1026" src="cid:~WRD0000.jpg" alt="Image removed by sender."></span></a><o:p></o:p></p>
</div>
</td>
<td width="49%" valign="top" style="width:49.82%;border:none;padding:9.0pt 27.0pt 9.0pt 9.0pt">
<div style="margin-right:6.0pt;margin-bottom:9.0pt" id="LPTitle765850">
<p class="MsoNormal"><span style="font-size:16.0pt;font-family:"Segoe UI Light",sans-serif"><a href="https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/24__;!!PvBDto6Hs4WbVuu7!J3wEpyPHlAiGcXO0VDc8uO1zb9BOrpYLw3dw6BHPigpmcy0Q4f8gxX6hHLnQOqg_AVxEg_MYrByNRr1urhAp-KViTuP33uBoiHHY$" target="_blank"><span style="text-decoration:none">Defer
data retransmission with out-of-order report segments · Issue #24 · nasa/HDTN</span></a><o:p></o:p></span></p>
</div>
<div style="margin-right:6.0pt;margin-bottom:9.0pt;max-height: 100px;overflow:hidden" id="LPDescription765850">
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:#666666">When the network is causing out-of-order segment reception it is possible that one or more synchronous reception reports are received either out-of-order or
within a short time window, possibly fol...<o:p></o:p></span></p>
</div>
<div id="LPMetadata765850">
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:#A6A6A6">github.com<o:p></o:p></span></p>
</div>
</td>
</tr>
</tbody>
</table>
</div>
</div>
<table class="MsoNormalTable" border="1" cellspacing="4" cellpadding="0" width="100%" style="width:100.0%;margin-left:108.0pt;border:solid #C8C8C8 1.0pt">
<tbody>
<tr>
<td valign="top" style="border:none;padding:9.0pt 27.0pt 9.0pt 9.0pt">
<div style="margin-right:9.0pt;overflow:hidden" id="LPImageContainer694819">
<p class="MsoNormal"><a href="https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/22__;!!PvBDto6Hs4WbVuu7!J3wEpyPHlAiGcXO0VDc8uO1zb9BOrpYLw3dw6BHPigpmcy0Q4f8gxX6hHLnQOqg_AVxEg_MYrByNRr1urhAp-KViTuP33vk9LEw4$" target="_blank"><span style="border:solid windowtext 1.0pt;padding:0cm;text-decoration:none"><img border="0" width="240" height="120" style="width:2.5in;height:1.25in" id="_x0000_i1025" src="cid:~WRD0000.jpg" alt="Image removed by sender."></span></a><o:p></o:p></p>
</div>
</td>
<td width="49%" valign="top" style="width:49.82%;border:none;padding:9.0pt 27.0pt 9.0pt 9.0pt">
<div style="margin-right:6.0pt;margin-bottom:9.0pt" id="LPTitle694819">
<p class="MsoNormal"><span style="font-size:16.0pt;font-family:"Segoe UI Light",sans-serif"><a href="https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/22__;!!PvBDto6Hs4WbVuu7!J3wEpyPHlAiGcXO0VDc8uO1zb9BOrpYLw3dw6BHPigpmcy0Q4f8gxX6hHLnQOqg_AVxEg_MYrByNRr1urhAp-KViTuP33vk9LEw4$" target="_blank"><span style="text-decoration:none">Defer
synchronous reception report with out-of-order data segments · Issue #22 · nasa/HDTN</span></a><o:p></o:p></span></p>
</div>
<div style="margin-right:6.0pt;margin-bottom:9.0pt;max-height: 100px;overflow:hidden" id="LPDescription694819">
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:#666666">When red part data is segmented and delivered to the receiving engine out-of-order, the checkpoint(s) and EORP can be received before the earlier-in-block data
segments. If a synchronous report is ...<o:p></o:p></span></p>
</div>
<div id="LPMetadata694819">
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:#A6A6A6">github.com<o:p></o:p></span></p>
</div>
</td>
</tr>
</tbody>
</table>
</div>
<div>
<p class="MsoNormal" style="margin-left:108.0pt"><span lang="EN-US" style="color:black"><o:p> </o:p></span></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal" style="margin-left:108.0pt"><span lang="EN-US" style="color:black">Thanks,<o:p></o:p></span></p>
</div>
<div id="Signature">
<div>
<p class="MsoNormal" style="margin-left:108.0pt"><span lang="EN-US">-----------------------------------------------------------------------------------------------------------------------<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:108.0pt"><span lang="EN-US">Marc Sanchez Net (332H)<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:108.0pt"><span lang="EN-US" style="font-size:10.0pt;color:gray">Telecommunications Engineer</span><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:108.0pt;background:white"><span lang="EN-US" style="font-size:10.0pt;color:gray">Jet Propulsion Laboratory</span><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:108.0pt;background:white"><span lang="EN-US" style="font-size:10.0pt;color:gray">Cell:</span><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#222222"> </span><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black"><a href="mailto:(617)%20953-7977">(617)
953-7977</a></span><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#0070C0">
</span><span lang="EN-US" style="font-size:10.0pt;color:gray">|</span><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#0070C0">
</span><span lang="EN-US" style="font-size:10.0pt;color:gray">Email:</span><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#222222"> </span><span lang="EN-US" style="color:black"><a href="mailto:marc.sanchez.net@jpl.nasa.gov"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">marc.sanchez.net@jpl.nasa.gov</span></a></span><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:108.0pt"><span lang="EN-US">-----------------------------------------------------------------------------------------------------------------------<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:108.0pt"><span lang="EN-US"> <o:p></o:p></span></p>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-left:72.0pt">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 (<a href="mailto:dpo@esa.int">dpo@esa.int</a>).
<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">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 (<a href="mailto:dpo@esa.int">dpo@esa.int</a>).
<o:p></o:p></p>
</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>