<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:0in;
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:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
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;
mso-ligatures:none;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1308709527;
mso-list-template-ids:1234979662;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1
{mso-list-id:1492407021;
mso-list-type:hybrid;
mso-list-template-ids:583201910 134807553 134807555 134807557 134807553 134807555 134807557 134807553 134807555 134807557;}
@list l1:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l1:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l1:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l1:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l1:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l1:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l1:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l1:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l1:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
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]--></head><body lang=EN-US link=blue vlink=purple style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal>Ah, good point. Thanks, Felix, this makes plenty of sense; no problem if every client data unit is a bundle, but of course the spec does not require this.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Scott<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b>From:</b> Felix Flentge <Felix.Flentge@esa.int> <br><b>Sent:</b> Thursday, June 1, 2023 8:26 AM<br><b>To:</b> sburleig.sb@gmail.com; 'Torgerson, J. Leigh (US 332C)' <jordan.l.torgerson@jpl.nasa.gov>; 'Sanchez Net, Marc (US 332H)' <marc.sanchez.net@jpl.nasa.gov>; 'Dr. Keith L Scott via SIS-DTN' <sis-dtn@mailman.ccsds.org>; keithlscott@gmail.com<br><b>Cc:</b> 'Gao, Jay L (US 332C)' <jay.l.gao@jpl.nasa.gov>; 'Richard, Nate J (US 332C)' <nathaniel.j.richard@jpl.nasa.gov><br><b>Subject:</b> RE: [EXTERNAL] RE: [Sis-dtn] New version of LTP Corrigendum<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span lang=EN-GB>No,<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-GB>The issue is that there is no generic way to determine the length of an SDA client data capsule (or I am overlooking something).<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-GB>Of course, it works for a lot of specific client data units if the client data units themselves allow to determine the lengths (as it is the case for bundles) and the receiver knows the format of each client data.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB><o:p> </o:p></span></p><div><p class=MsoNormal><span lang=EN-GB>Regards,<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>Felix<o:p></o:p></span></p></div><p class=MsoNormal><span lang=EN-GB><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal style='margin-left:.5in'><b>From:</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>> <br><b>Sent:</b> Thursday, June 1, 2023 5:18 PM<br><b>To:</b> Felix Flentge <<a href="mailto:Felix.Flentge@esa.int">Felix.Flentge@esa.int</a>>; 'Torgerson, J. Leigh (US 332C)' <<a href="mailto:jordan.l.torgerson@jpl.nasa.gov">jordan.l.torgerson@jpl.nasa.gov</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>>; <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></p></div></div><p class=MsoNormal style='margin-left:.5in'><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:.5in'>Felix, I am neutral on the utility of service data aggregation, but can you say a little bit about what makes it non-interoperable? It’s formally defined in the current LTP blue book, in normative language (7.2), right? Are you just saying that existing implementations of LTP don’t all implement this element of the specification and therefore do not interoperate?<o:p></o:p></p><p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p><p class=MsoNormal style='margin-left:.5in'>Scott<o:p></o:p></p><p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal style='margin-left:.5in'><b>From:</b> Felix Flentge <<a href="mailto:Felix.Flentge@esa.int">Felix.Flentge@esa.int</a>> <br><b>Sent:</b> Thursday, June 1, 2023 7:38 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>>; Sanchez Net, Marc (US 332H) <<a href="mailto:marc.sanchez.net@jpl.nasa.gov">marc.sanchez.net@jpl.nasa.gov</a>>; <a href="mailto:sburleig.sb@gmail.com">sburleig.sb@gmail.com</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></p></div></div><p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p><p class=MsoNormal style='margin-left:.5in'><span lang=EN-GB>I think the point is that Service Data Aggregation is that it is not-interoperable. As such it should not be used (at least in interoperability scenarios). We don’t need to hint at the new protocol. [I would think that this is a true corrigendum].<o:p></o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span lang=EN-GB><o:p> </o:p></span></p><div><p class=MsoNormal style='margin-left:.5in'><span lang=EN-GB>Regards,<o:p></o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span lang=EN-GB>Felix<o:p></o:p></span></p></div><p class=MsoNormal style='margin-left:.5in'><span lang=EN-GB><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal style='margin-left:1.0in'><b>From:</b> 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> Wednesday, May 31, 2023 6:01 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>>; <a href="mailto:sburleig.sb@gmail.com">sburleig.sb@gmail.com</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></p></div></div><p class=MsoNormal style='margin-left:1.0in'><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:1.0in'>Looks OK but at the end it says “<span lang=EN-GB>service IDs are agreed. It is expected that Service Data Aggregation will be removed from<span style='color:red'> LTPv2 </span>and that eventual aggregation shall be performed by upper layers if deemed necessary.</span>”<o:p></o:p></p><p class=MsoNormal style='margin-left:1.0in'><o:p> </o:p></p><p class=MsoNormal style='margin-left:1.0in'>If the fpga/asic version isn’t going to be called LTP2, this will have to be revised.<o:p></o:p></p><p class=MsoNormal style='margin-left:1.0in'><o:p> </o:p></p><p class=MsoNormal style='margin-left:1.0in'>Leigh<o:p></o:p></p><p class=MsoNormal style='margin-left:1.0in'><o:p> </o:p></p><p class=MsoNormal style='margin-left:1.0in'><o:p> </o:p></p><p class=MsoNormal style='margin-left:1.0in'><o:p> </o:p></p><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal style='margin-left:1.0in'><b><span style='font-size:12.0pt;color:black'>From: </span></b><span style='font-size:12.0pt;color:black'>"Sanchez Net, Marc (US 332H)" <<a href="mailto:marc.sanchez.net@jpl.nasa.gov">marc.sanchez.net@jpl.nasa.gov</a>><br><b>Date: </b>Tuesday, May 30, 2023 at 1:18 PM<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>>, "Torgerson, Jordan L (332M)" <<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>" <<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:1.0in'><o:p> </o:p></p></div><p class=MsoNormal style='margin-left:1.0in'>All,<o:p></o:p></p><p class=MsoNormal style='margin-left:1.0in'><o:p> </o:p></p><p class=MsoNormal style='margin-left:1.0in'>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></p><p class=MsoNormal style='margin-left:1.0in'><o:p> </o:p></p><p class=MsoNormal style='margin-left:1.0in'>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></p><p class=MsoNormal style='margin-left:1.0in'><o:p> </o:p></p><div><p class=MsoNormal style='margin-left:1.0in'>-----------------------------------------------------------------------------------------------------------------------<o:p></o:p></p><p class=MsoNormal style='margin-left:1.0in'>Marc Sanchez Net (332H)<o:p></o:p></p><p class=MsoNormal style='margin-left:1.0in'><span style='font-size:10.0pt;color:gray'>Telecommunications Engineer</span><o:p></o:p></p><p class=MsoNormal style='margin-left:1.0in;background:white'><span style='font-size:10.0pt;color:gray'>Jet Propulsion Laboratory<o:p></o:p></span></p><p class=MsoNormal style='margin-left:1.0in;background:white'><span style='font-size:10.0pt;color:gray'>Cell:</span><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#222222'> </span><span 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 style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#0070C0'> </span><span style='font-size:10.0pt;color:gray'>|</span><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#0070C0'> </span><span style='font-size:10.0pt;color:gray'>Email:</span><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#222222'> </span><span 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 style='font-size:9.5pt;font-family:"Arial",sans-serif;color:#222222'><o:p></o:p></span></p><p class=MsoNormal style='margin-left:1.0in'>-----------------------------------------------------------------------------------------------------------------------<o:p></o:p></p></div><p class=MsoNormal style='margin-left:1.0in'><o:p> </o:p></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal style='margin-left:1.0in'><b>From:</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>> <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></p></div></div><p class=MsoNormal style='margin-left:1.0in'><o:p> </o:p></p><p class=MsoNormal style='margin-left:1.0in'>Guys, a thought on this.<o:p></o:p></p><p class=MsoNormal style='margin-left:1.0in'><o:p> </o:p></p><p class=MsoNormal style='margin-left:1.0in'>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></p><p class=MsoNormal style='margin-left:1.0in'><o:p> </o:p></p><p class=MsoNormal style='margin-left:1.0in'>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></p><p class=MsoNormal style='margin-left:1.0in'><o:p> </o:p></p><p class=MsoNormal style='margin-left:1.0in'>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></p><p class=MsoNormal style='margin-left:1.0in'><o:p> </o:p></p><p class=MsoNormal style='margin-left:1.0in'>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></p><p class=MsoNormal style='margin-left:1.0in'><o:p> </o:p></p><p class=MsoNormal style='margin-left:1.0in'>Scott<o:p></o:p></p><p class=MsoNormal style='margin-left:1.0in'><o:p> </o:p></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal style='margin-left:1.0in'><b>From:</b> 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></p></div></div><p class=MsoNormal style='margin-left:1.0in'><o:p> </o:p></p><p class=MsoNormal style='margin-left:1.0in'>Thanks Felix – <o:p></o:p></p><p class=MsoNormal style='margin-left:1.0in'><o:p> </o:p></p><p class=MsoNormal style='margin-left:1.0in'>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></p><p class=MsoNormal style='margin-left:1.0in'><o:p> </o:p></p><p class=MsoNormal style='margin-left:1.0in'>regards,<o:p></o:p></p><p class=MsoNormal style='margin-left:1.0in'>Leigh<o:p></o:p></p><p class=MsoNormal style='margin-left:1.0in'><o:p> </o:p></p><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal style='margin-left:1.0in'><b><span lang=EN-GB style='font-size:12.0pt;color:black'>From: </span></b><span lang=EN-GB 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:1.0in'><span lang=EN-GB><o:p> </o:p></span></p></div><p class=MsoNormal style='margin-left:1.0in'><span lang=EN-GB>Hi Leigh,<o:p></o:p></span></p><p class=MsoNormal style='margin-left:1.0in'><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:1.0in'><span lang=EN-GB>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></span></p><p class=MsoNormal style='margin-left:1.0in'><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:1.0in'><span lang=EN-GB>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></span></p><p class=MsoNormal style='margin-left:1.0in'><span lang=EN-GB><o:p> </o:p></span></p><div><p class=MsoNormal style='margin-left:1.0in'><span lang=EN-GB>Regards,<o:p></o:p></span></p><p class=MsoNormal style='margin-left:1.0in'><span lang=EN-GB>Felix<o:p></o:p></span></p></div><p class=MsoNormal style='margin-left:1.0in'><span lang=EN-GB><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal style='margin-left:1.5in'><b>From:</b> 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></p></div></div><p class=MsoNormal style='margin-left:1.5in'><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:1.5in'>Thanks Felix – <o:p></o:p></p><p class=MsoNormal style='margin-left:1.5in'><o:p> </o:p></p><p class=MsoNormal style='margin-left:1.5in'>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></p><p class=MsoNormal style='margin-left:1.5in'><o:p> </o:p></p><p class=MsoNormal style='margin-left:1.5in'>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></p><p class=MsoNormal style='margin-left:1.5in'><o:p> </o:p></p><p class=MsoNormal style='margin-left:1.5in'><o:p> </o:p></p><p class=MsoNormal style='margin-left:1.5in'>regards<o:p></o:p></p><p class=MsoNormal style='margin-left:1.5in'>Leigh<o:p></o:p></p><p class=MsoNormal style='margin-left:1.5in'><o:p> </o:p></p><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal style='margin-left:1.5in'><b><span lang=EN-GB style='font-size:12.0pt;color:black'>From: </span></b><span lang=EN-GB 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:1.5in'><span lang=EN-GB><o:p> </o:p></span></p></div><p class=MsoNormal style='margin-left:1.5in'><span lang=EN-GB>Hi,<o:p></o:p></span></p><p class=MsoNormal style='margin-left:1.5in'><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:1.5in'><span lang=EN-GB>I agree with the modifications below.<o:p></o:p></span></p><p class=MsoNormal style='margin-left:1.5in'><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:1.5in'><span lang=EN-GB>Some additional points:<o:p></o:p></span></p><p class=MsoListParagraph style='margin-left:2.0in;text-indent:-.25in;mso-list:l1 level1 lfo2'><![if !supportLists]><span lang=EN-GB style='font-family:Symbol'><span style='mso-list:Ignore'>·<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span lang=EN-GB>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></span></p><p class=MsoListParagraph style='margin-left:2.0in;text-indent:-.25in;mso-list:l1 level1 lfo2'><![if !supportLists]><span lang=EN-GB style='font-family:Symbol'><span style='mso-list:Ignore'>·<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span lang=EN-GB>Should we discourage use of mixed sessions (on the other hand LTP green is optional anyway)?<o:p></o:p></span></p><p class=MsoListParagraph style='margin-left:2.0in;text-indent:-.25in;mso-list:l1 level1 lfo2'><![if !supportLists]><span lang=EN-GB style='font-family:Symbol'><span style='mso-list:Ignore'>·<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span lang=EN-GB>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></span></p><p class=MsoNormal style='margin-left:1.5in'><span lang=EN-GB><o:p> </o:p></span></p><div><p class=MsoNormal style='margin-left:1.5in'><span lang=EN-GB>Regards,<o:p></o:p></span></p><p class=MsoNormal style='margin-left:1.5in'><span lang=EN-GB>Felix<o:p></o:p></span></p></div><p class=MsoNormal style='margin-left:1.5in'><span lang=EN-GB><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal style='margin-left:2.0in'><b>From:</b> 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></p></div></div><p class=MsoNormal style='margin-left:2.0in'><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:2.0in'>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></p><p class=MsoNormal style='margin-left:2.0in'><o:p> </o:p></p><p class=MsoNormal style='margin-left:2.0in'>Scott<o:p></o:p></p><p class=MsoNormal style='margin-left:2.0in'><o:p> </o:p></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal style='margin-left:2.0in'><b>From:</b> 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></p></div></div><p class=MsoNormal style='margin-left:2.0in'><o:p> </o:p></p><div><p class=MsoNormal style='margin-left:2.0in'><span style='color:black'>All,<o:p></o:p></span></p></div><div><p class=MsoNormal style='margin-left:2.0in'><span style='color:black'><o:p> </o:p></span></p></div><div><p class=MsoNormal style='margin-left:2.0in'><span 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:2.5in;text-indent:-.25in;mso-list:l0 level1 lfo4'><![if !supportLists]><span 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 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:2.5in;text-indent:-.25in;mso-list:l0 level1 lfo4'><![if !supportLists]><span 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 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:2.5in;text-indent:-.25in;mso-list:l0 level1 lfo4'><![if !supportLists]><span 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 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:2.0in'><span 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:2.0in'><span 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=3 cellpadding=0 width="100%" style='width:100.0%;margin-left:2.0in;border:solid #C8C8C8 1.0pt'><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:0in;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.5%;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></table></div></div><table class=MsoNormalTable border=1 cellspacing=3 cellpadding=0 width="100%" style='width:100.0%;margin-left:2.0in;border:solid #C8C8C8 1.0pt'><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:0in;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.5%;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></table></div><div><p class=MsoNormal style='margin-left:2.0in'><span style='color:black'><o:p> </o:p></span></p></div></div><div><div><p class=MsoNormal style='margin-left:2.0in'><span style='color:black'>Thanks,<o:p></o:p></span></p></div><div id=Signature><div><p class=MsoNormal style='margin-left:2.0in'>-----------------------------------------------------------------------------------------------------------------------<o:p></o:p></p><p class=MsoNormal style='margin-left:2.0in'>Marc Sanchez Net (332H)<o:p></o:p></p><p class=MsoNormal style='margin-left:2.0in'><span style='font-size:10.0pt;color:gray'>Telecommunications Engineer</span><o:p></o:p></p><p class=MsoNormal style='margin-left:2.0in;background:white'><span style='font-size:10.0pt;color:gray'>Jet Propulsion Laboratory</span><o:p></o:p></p><p class=MsoNormal style='margin-left:2.0in;background:white'><span style='font-size:10.0pt;color:gray'>Cell:</span><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#222222'> </span><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:black'><a href="mailto:(617)%20953-7977">(617) 953-7977</a></span><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#0070C0'> </span><span style='font-size:10.0pt;color:gray'>|</span><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#0070C0'> </span><span style='font-size:10.0pt;color:gray'>Email:</span><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#222222'> </span><span 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><o:p></o:p></p><p class=MsoNormal style='margin-left:2.0in'>-----------------------------------------------------------------------------------------------------------------------<o:p></o:p></p><p class=MsoNormal style='margin-left:2.0in'> <o:p></o:p></p></div></div></div><p class=MsoNormal style='margin-left:1.5in'><span lang=EN-GB>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></span></p><p class=MsoNormal style='margin-left:1.0in'><span lang=EN-GB>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></span></p><p class=MsoNormal style='margin-left:.5in'><span lang=EN-GB>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></span></p><p class=MsoNormal><span lang=EN-GB>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></span></p></div></body></html>