<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=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Courier;
panose-1:2 7 4 9 2 2 5 2 4 4;}
@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;}
@font-face
{font-family:NotoSerif-Regular;
panose-1:0 0 0 0 0 0 0 0 0 0;}
/* 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;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p.m-5360493418966220258msolistparagraph, li.m-5360493418966220258msolistparagraph, div.m-5360493418966220258msolistparagraph
{mso-style-name:m_-5360493418966220258msolistparagraph;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.gmailsignatureprefix
{mso-style-name:gmail_signature_prefix;}
span.EmailStyle20
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle21
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle22
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle25
{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;}
--></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>Good people have written good stuff. Glad to have it available!<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> sburleig.sb@gmail.com <sburleig.sb@gmail.com> <br><b>Sent:</b> Wednesday, May 31, 2023 1:57 PM<br><b>To:</b> Robert C Durst <durst@mitre.org>; Cerf, Vinton <vint@google.com><br><b>Cc:</b> 'Sipos, Brian J.' <Brian.Sipos@jhuapl.edu>; 'Sanchez Net, Marc (US 332H)' <marc.sanchez.net@jpl.nasa.gov>; Jeremy.Mayer@dlr.de; 'Torgerson, J. Leigh (US 332C)' <jordan.l.torgerson@jpl.nasa.gov>; Felix.Flentge@esa.int; keithlscott@gmail.com; sis-dtn@mailman.ccsds.org<br><b>Subject:</b> RE: [Sis-dtn] [EXTERNAL] RE: New version of LTP Corrigendum<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Excellent digging, Bob.<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> Robert C Durst <<a href="mailto:durst@mitre.org">durst@mitre.org</a>> <br><b>Sent:</b> Wednesday, May 31, 2023 10:54 AM<br><b>To:</b> <a href="mailto:sburleig.sb@gmail.com">sburleig.sb@gmail.com</a>; Cerf, Vinton <<a href="mailto:vint@google.com">vint@google.com</a>><br><b>Cc:</b> 'Sipos, Brian J.' <<a href="mailto:Brian.Sipos@jhuapl.edu">Brian.Sipos@jhuapl.edu</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:Jeremy.Mayer@dlr.de">Jeremy.Mayer@dlr.de</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:keithlscott@gmail.com">keithlscott@gmail.com</a>; <a href="mailto:sis-dtn@mailman.ccsds.org">sis-dtn@mailman.ccsds.org</a><br><b>Subject:</b> RE: [Sis-dtn] [EXTERNAL] RE: New version of LTP Corrigendum<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Thanks, Scott!<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Indeed, fragmentation and reassembly are (and have always been) challenging, sometimes necessary, and the source of many bad words.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>For the near-ish term future, it’s reasonable to assume that BPAs know or can be informed of the limitations of the CLAs in the system. And still, design matters. These two excerpts from RFC 7122 are relevant, and perhaps the RID response should point to this section of RFC7122: <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.0pt;font-family:Courier'>3.1. How and Where to Deal with Fragmentation<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.0pt;font-family:Courier'><o:p> </o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.0pt;font-family:Courier'>The Bundle Protocol allows bundles with sizes limited only by node<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.0pt;font-family:Courier'>resource constraints. In IPv4, the maximum size of a UDP datagram is<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.0pt;font-family:Courier'>nearly 64 KB. In IPv6, when using jumbograms [RFC2675], UDP<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.0pt;font-family:Courier'>datagrams can technically be up to 4 GB in size [RFC2147], although<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.0pt;font-family:Courier'>this option is rarely used. (Note: RFC 2147 was obsoleted by RFC<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.0pt;font-family:Courier'>2675.) It is well understood that sending large IP datagrams that<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.0pt;font-family:Courier'>must be fragmented by the network has enormous efficiency penalties<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.0pt;font-family:Courier'>[Kent87]. The Bundle Protocol specification provides a bundle<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.0pt;font-family:Courier'>fragmentation concept [RFC5050] that allows a large bundle to be<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.0pt;font-family:Courier'>divided into bundle fragments. <span style='background:yellow;mso-highlight:yellow'>If the Bundle Protocol is being<o:p></o:p></span></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.0pt;font-family:Courier;background:yellow;mso-highlight:yellow'>encapsulated in DCCP or UDP, it therefore SHOULD create each fragment<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.0pt;font-family:Courier;background:yellow;mso-highlight:yellow'>of sufficiently small size that it can then be encapsulated into a<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.0pt;font-family:Courier;background:yellow;mso-highlight:yellow'>datagram that will not need to be fragmented at the IP layer.</span><span style='font-size:10.0pt;font-family:Courier'><o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.0pt;font-family:Courier'><o:p> </o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.0pt;font-family:Courier'>IP fragmentation can be avoided by using IP Path MTU Discovery<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.0pt;font-family:Courier'>[RFC1191] [RFC1981], which depends on the deterministic delivery of<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.0pt;font-family:Courier'>ICMP Packet Too Big (PTB) messages from routers in the network. To<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.0pt;font-family:Courier'>bypass a condition referred to as a black hole [RFC2923], a newer<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.0pt;font-family:Courier'>specification is available in [RFC4821] to determine the IP Path MTU<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.0pt;font-family:Courier'>without the use of PTB messages. This document does not attempt to<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.0pt;font-family:Courier'>recommend one fragmentation avoidance mechanism over another; the<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.0pt;font-family:Courier'>information in this section is included for the benefit of<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:Courier'>implementers.</span><o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>And<o:p></o:p></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.0pt;font-family:Courier'><o:p> </o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.0pt;font-family:Courier'>3.1.2. UDP<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.0pt;font-family:Courier'><o:p> </o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.0pt;font-family:Courier'>When an LTP CL is using UDP for datagram delivery, it SHOULD NOT<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.0pt;font-family:Courier'>create segments that will result in UDP datagrams that will need to<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.0pt;font-family:Courier'>be fragmented, as discussed above.<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.0pt;font-family:Courier'><o:p> </o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.0pt;font-family:Courier'>3.2. Bundle Protocol over a Datagram Convergence Layer<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.0pt;font-family:Courier'><o:p> </o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.0pt;font-family:Courier;background:yellow;mso-highlight:yellow'>In general, the use of the Bundle Protocol over a datagram CL is<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.0pt;font-family:Courier;background:yellow;mso-highlight:yellow'>discouraged in IP networks.</span><span style='font-size:10.0pt;font-family:Courier'> Bundles can be of (almost) arbitrary<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.0pt;font-family:Courier'>length, and the Bundle Protocol does not include an effective<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:Courier'>retransmission mechanism. Whenever possible, the Bundle Protocol<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:Courier'>SHOULD be operated over the TCP Convergence Layer or over LTP.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:Courier'><o:p> </o:p></span></p><p class=MsoNormal>Best,<o:p></o:p></p><p class=MsoNormal>Bob<o:p></o:p></p><p class=MsoNormal><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> <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> Wednesday, May 31, 2023 1:35 PM<br><b>To:</b> Cerf, Vinton <<a href="mailto:vint@google.com">vint@google.com</a>>; Robert C Durst <<a href="mailto:durst@mitre.org">durst@mitre.org</a>><br><b>Cc:</b> 'Sipos, Brian J.' <<a href="mailto:Brian.Sipos@jhuapl.edu">Brian.Sipos@jhuapl.edu</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:Jeremy.Mayer@dlr.de">Jeremy.Mayer@dlr.de</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:keithlscott@gmail.com">keithlscott@gmail.com</a>; <a href="mailto:sis-dtn@mailman.ccsds.org">sis-dtn@mailman.ccsds.org</a><br><b>Subject:</b> RE: [Sis-dtn] [EXTERNAL] RE: New version of LTP Corrigendum<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>The convergence layer adapter is expected (7.2 of RFC 9171) to notify the BPA when it fails to forward the bundle, for whatever reason; among those reasons might well be “bundle is too big for this CL protocol”. Depending on implementation, the BPA might respond to this notice by fragmenting the bundle; ION currently does this for the UDP CLA. But certainly another implementation expedient might be for the BPA to know in advance the limitations of all available CLAs and choose the CLA for a given bundle on that basis.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Reassembly of a bundle from fragments, at the destination endpoint node, is certainly somewhat complicated. But we discussed the alternatives at length, and what’s in the RFC is what we agreed on. Reassembly of segmented LTP blocks and reassembly of fragmented IP packets is likewise complicated. Ideally you always want this to be Somebody Else’s Problem.<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 style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b>From:</b> Vint Cerf <<a href="mailto:vint@google.com">vint@google.com</a>> <br><b>Sent:</b> Wednesday, May 31, 2023 9:55 AM<br><b>To:</b> Robert C Durst <<a href="mailto:durst@mitre.org">durst@mitre.org</a>><br><b>Cc:</b> Sipos, Brian J. <<a href="mailto:Brian.Sipos@jhuapl.edu">Brian.Sipos@jhuapl.edu</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:Jeremy.Mayer@dlr.de">Jeremy.Mayer@dlr.de</a>; <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>>; <a href="mailto:Felix.Flentge@esa.int">Felix.Flentge@esa.int</a>; <a href="mailto:keithlscott@gmail.com">keithlscott@gmail.com</a>; <a href="mailto:sis-dtn@mailman.ccsds.org">sis-dtn@mailman.ccsds.org</a><br><b>Subject:</b> Re: [Sis-dtn] [EXTERNAL] RE: New version of LTP Corrigendum<o:p></o:p></p></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>briefly, fragmentation, re-transmission, alternative convergence layers can result in non-uniform and overlapping receipt of fragmented bundles. That can make for a pretty messy reassembly at bundle layer. Of course, alternative routing through different CLAs can also result in partially reassembled bundles or bundle fragments at the receiving end of a CLA. We've encountered a lot of that in the Internet in its various incarnations. <o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Is is a good assumption that the bundle maker layer knows about limitations of the CLA with regard to maximum bundle size to avoid fragmentation?<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>v<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>On Wed, May 31, 2023 at 12:39 PM Robert C Durst via SIS-DTN <<a href="mailto:sis-dtn@mailman.ccsds.org">sis-dtn@mailman.ccsds.org</a>> wrote:<o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'><div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Folks, on a note that’s somewhat related to Brian’s message below, so far I’ve received precisely one Agency RID on BPv7, which is attached, FYI. It deals with the BPv7 Minimum Supported Bundle Size (sec 3.6):<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in;line-height:11.75pt'><b><span style='font-family:"Times New Roman",serif;color:#0F0F0F'>3.6 MINIMUM SUPPORTED BUNDLE SIZE</span></b><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;margin-left:30.7pt'><b><span style='font-size:10.0pt;font-family:"Times New Roman",serif'> </span></b><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;margin-right:15.95pt;margin-left:35.8pt;text-indent:.15pt'><span style='font-family:"Times New Roman",serif;color:#0F0F0F'>Conformant CCSDS implementations shall be able to forward and</span><span style='font-family:"Times New Roman",serif;color:#313131'>/</span><span style='font-family:"Times New Roman",serif;color:#0F0F0F'>or deliver bundles whose total size, including all extension blocks, is less than or equal to 10*2<sup>20</sup> bytes (10 MB).</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;margin-left:35.85pt'><span style='font-family:"Times New Roman",serif;color:#0F0F0F'>NOTE - Disposition of larger bundles is implementation-specific.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>The RID says: <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>“Add details that show considerations for minimum size have been considered for network implementation. <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>The Note that disposition of larger bundles is implementation-specific needs to be augmented to show that <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>the impacts of this large bundle size have been considered for the various ways that networks could meet <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>this requirement with the convergence layers. It’s difficult to understand how an UDP or SPP Convergence-Layer<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>would satisfy this requirement. It would be helpful to provide examples based on the CLAs specified in this document.”<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>In Normative Annex B, we specify 5 CLAs, and assert that a compliant BP implementation shall implement at least one of them. As a result, a compliant implementation need implement <i>no more</i> than one of them. By implication, since any of the CLAs specified might be the <i>only</i> CLA available, the requirement from Section 3.6 must be able to be met by any of the CLAs.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>B2.1.2: TCP CL – stream-oriented CL; no inherent limitations on Bundle Size.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>B2.1.3: UDP CL – Note on B2.1.3.2 says “<span style='color:#0F0F0F'>It is desirable that BP agents endeavor to send bundles of such a size as not to require fragmentation by the IP (Internet Protocol) layer. In practice this generally means keeping the size of the IP datagram (including the IP and UDP headers, plus the bundle) to no more than 1500 bytes.” </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#0F0F0F'>Probably not the answer he wants, particularly in the context of a 10MB bundle. How does a UDP CL meet the requirement specified in 3.6? If the UDP CL *<b>cannot</b>* meet the requirement specified in 3.6, how should we proceed? Must the Bundle be fragmented into some number of fragmentary bundles that fit into a sequence of 150+ 65507-byte UDP payloads (or 6700+ 1472-byte UDP payloads)? </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#0F0F0F'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#0F0F0F'>B2.1.4: LTP CL – is there a length limitation on LTP ADUs (Blocks)? I didn’t see one in the RFC or the Blue Book</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#0F0F0F'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#0F0F0F'>B2.1.5: SPP – B2.1.5.1 notes that the maximum size of a bundle is <= 65535. Is Bundle fragmentation therefore the only way to accommodate the requirement of section 3.6?</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#0F0F0F'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#0F0F0F'>B2.1.6: EPP – 4GB MTU meets the section 3.6 requirement.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#0F0F0F'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#0F0F0F'>So, for TCP, LTP, and EPP there’s no issue with the requirement in 3.6. For UDP and SPP, is Bundle Fragmentation the only feasible approach? </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#0F0F0F'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#0F0F0F'>RFC 9171 section 5.9 permits in-transit reassembly (“</span><span style='font-size:10.0pt;font-family:"NotoSerif-Regular",sans-serif;color:#222222'>an ADU also be reassembled at some other node on the path to the destination.”). </span><span style='color:#0F0F0F'>The motivator for that might be to remove redundant bundle headers in order to reduce overhead before forwarding a large bundle over a (potentially not-yet-available) constrained link.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#0F0F0F'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#0F0F0F'>Is it the sense of this group that this is correct? Would an appropriate response to the RID be to add to the note on 3.6 a sentence to the effect of the following: “…</span><span style='font-family:"Times New Roman",serif;color:#0F0F0F'>is implementation-specific. For CLAs that have maximum size limits that are less than this 10MB requirement (e.g., UDP, B2.1.3 and SPP, B2.1.5), Bundle Fragmentation and Reassembly (refer to RFC 9171 sections 5.8 and 5.9) are available to mitigate the limitation.” </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#0F0F0F'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#0F0F0F'>Any sense of the reaction to this not-so-satisfying response?</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#0F0F0F'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#0F0F0F'>Thanks,<br>Bob </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <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='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b>From:</b> SIS-DTN <<a href="mailto:sis-dtn-bounces@mailman.ccsds.org" target="_blank">sis-dtn-bounces@mailman.ccsds.org</a>> <b>On Behalf Of </b>Sipos, Brian J. via SIS-DTN<br><b>Sent:</b> Wednesday, May 31, 2023 11:04 AM<br><b>To:</b> Sanchez Net, Marc (US 332H) <<a href="mailto:marc.sanchez.net@jpl.nasa.gov" target="_blank">marc.sanchez.net@jpl.nasa.gov</a>>; <a href="mailto:Jeremy.Mayer@dlr.de" target="_blank">Jeremy.Mayer@dlr.de</a>; <a href="mailto:sburleig.sb@gmail.com" target="_blank">sburleig.sb@gmail.com</a>; Torgerson, J. Leigh (US 332C) <<a href="mailto:jordan.l.torgerson@jpl.nasa.gov" target="_blank">jordan.l.torgerson@jpl.nasa.gov</a>>; <a href="mailto:Felix.Flentge@esa.int" target="_blank">Felix.Flentge@esa.int</a>; <a href="mailto:keithlscott@gmail.com" target="_blank">keithlscott@gmail.com</a><br><b>Cc:</b> <a href="mailto:sis-dtn@mailman.ccsds.org" target="_blank">sis-dtn@mailman.ccsds.org</a><br><b>Subject:</b> Re: [Sis-dtn] [EXTERNAL] RE: New version of LTP Corrigendum<o:p></o:p></p></div></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'>Marc, for my own purposes the one reason for using unreliable LTP is to take advantage of the segmentation of larger-than-MTU blocks. It’s a useful thing on its own separate from other capabilities of LTP. Similar to some of these other recommendations, it would be helpful for implementations to know “if you are able to choose block sizes then here is a recommendation … Otherwise if you are using green block segmentation then here are some considerations (about timing and resource leaks) …”</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'>I think it’s better for an designer/implementer to be aware of potential issues and head them off than to try to ignore or impose restrictions on the service which would prohibit existing use cases.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'> </span><o:p></o:p></p><div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b>From:</b> SIS-DTN <<a href="mailto:sis-dtn-bounces@mailman.ccsds.org" target="_blank">sis-dtn-bounces@mailman.ccsds.org</a>> <b>On Behalf Of </b>Sanchez Net, Marc (US 332H) via SIS-DTN<br><b>Sent:</b> Wednesday, May 31, 2023 8:55 AM<br><b>To:</b> <a href="mailto:Jeremy.Mayer@dlr.de" target="_blank">Jeremy.Mayer@dlr.de</a>; <a href="mailto:sburleig.sb@gmail.com" target="_blank">sburleig.sb@gmail.com</a>; Torgerson, J. Leigh (US 332C) <<a href="mailto:jordan.l.torgerson@jpl.nasa.gov" target="_blank">jordan.l.torgerson@jpl.nasa.gov</a>>; <a href="mailto:Felix.Flentge@esa.int" target="_blank">Felix.Flentge@esa.int</a>; <a href="mailto:sis-dtn@mailman.ccsds.org" target="_blank">sis-dtn@mailman.ccsds.org</a>; <a href="mailto:keithlscott@gmail.com" target="_blank">keithlscott@gmail.com</a><br><b>Subject:</b> [EXT] Re: [Sis-dtn] [EXTERNAL] RE: New version of LTP Corrigendum<o:p></o:p></p></div></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><div id="m_-5360493418966220258APLWarningText"><table class=MsoNormalTable border=0 cellspacing=0 cellpadding=0 align=left><tr><td width="100%" style='width:100.0%;background:#E0E0E0;padding:0in 0in 0in 0in'><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-element:frame;mso-element-frame-hspace:2.25pt;mso-element-wrap:around;mso-element-anchor-vertical:paragraph;mso-element-anchor-horizontal:column;mso-height-rule:exactly'><b><span style='font-size:12.0pt;font-family:"Times New Roman",serif;color:red'>APL external email warning: </span></b><span style='font-size:12.0pt;font-family:"Times New Roman",serif;color:black'>Verify sender </span><span style='color:black'><a href="mailto:sis-dtn-bounces@mailman.ccsds.org" target="_blank"><span style='font-size:12.0pt;font-family:"Times New Roman",serif'>sis-dtn-bounces@mailman.ccsds.org</span></a></span><span style='font-size:12.0pt;font-family:"Times New Roman",serif;color:black'> before clicking links or attachments</span><o:p></o:p></p></td></tr></table><p> <o:p></o:p></p></div></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>-----------------------------------------------------------------------------------------------------------------------<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Marc Sanchez Net (332H)<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:10.0pt;color:gray'>Telecommunications Engineer</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;background:white'><span style='font-size:10.0pt;color:gray'>Jet Propulsion Laboratory</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;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='color:black'><a href="mailto:(617)%20953-7977" target="_blank"><span style='font-size:10.0pt;font-family:"Arial",sans-serif;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" target="_blank"><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='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>-----------------------------------------------------------------------------------------------------------------------<o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <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='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b>From:</b> <a href="mailto:Jeremy.Mayer@dlr.de" target="_blank">Jeremy.Mayer@dlr.de</a> <<a href="mailto:Jeremy.Mayer@dlr.de" target="_blank">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" target="_blank">sburleig.sb@gmail.com</a>; Sanchez Net, Marc (US 332H) <<a href="mailto:marc.sanchez.net@jpl.nasa.gov" target="_blank">marc.sanchez.net@jpl.nasa.gov</a>>; Torgerson, J. Leigh (US 332C) <<a href="mailto:jordan.l.torgerson@jpl.nasa.gov" target="_blank">jordan.l.torgerson@jpl.nasa.gov</a>>; <a href="mailto:Felix.Flentge@esa.int" target="_blank">Felix.Flentge@esa.int</a>; <a href="mailto:sis-dtn@mailman.ccsds.org" target="_blank">sis-dtn@mailman.ccsds.org</a>; <a href="mailto:keithlscott@gmail.com" target="_blank">keithlscott@gmail.com</a><br><b>Subject:</b> RE: [Sis-dtn] [EXTERNAL] RE: New version of LTP Corrigendum<o:p></o:p></p></div></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-GB>Hi,</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-GB>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.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-GB> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-GB>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.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-GB> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-GB>Thanks,</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-GB>Jeremy</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-GB> </span><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='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b>From:</b> SIS-DTN <<a href="mailto:sis-dtn-bounces@mailman.ccsds.org" target="_blank">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" target="_blank">marc.sanchez.net@jpl.nasa.gov</a>>; 'Torgerson, J. Leigh (US 332C)' <<a href="mailto:jordan.l.torgerson@jpl.nasa.gov" target="_blank">jordan.l.torgerson@jpl.nasa.gov</a>>; 'Felix Flentge' <<a href="mailto:Felix.Flentge@esa.int" target="_blank">Felix.Flentge@esa.int</a>>; 'Dr. Keith L Scott via SIS-DTN' <<a href="mailto:sis-dtn@mailman.ccsds.org" target="_blank">sis-dtn@mailman.ccsds.org</a>>; <a href="mailto:keithlscott@gmail.com" target="_blank">keithlscott@gmail.com</a><br><b>Subject:</b> Re: [Sis-dtn] [EXTERNAL] RE: New version of LTP Corrigendum<o:p></o:p></p></div></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Of course, sticking to small green blocks that are transmitted in single green segments makes the whole issue go away.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Scott<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <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='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b>From:</b> Sanchez Net, Marc (US 332H) <<a href="mailto:marc.sanchez.net@jpl.nasa.gov" target="_blank">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" target="_blank">sburleig.sb@gmail.com</a>; Torgerson, J. Leigh (US 332C) <<a href="mailto:jordan.l.torgerson@jpl.nasa.gov" target="_blank">jordan.l.torgerson@jpl.nasa.gov</a>>; 'Felix Flentge' <<a href="mailto:Felix.Flentge@esa.int" target="_blank">Felix.Flentge@esa.int</a>>; 'Dr. Keith L Scott via SIS-DTN' <<a href="mailto:sis-dtn@mailman.ccsds.org" target="_blank">sis-dtn@mailman.ccsds.org</a>>; <a href="mailto:keithlscott@gmail.com" target="_blank">keithlscott@gmail.com</a><br><b>Cc:</b> Gao, Jay L (US 332C) <<a href="mailto:jay.l.gao@jpl.nasa.gov" target="_blank">jay.l.gao@jpl.nasa.gov</a>>; Richard, Nate J (US 332C) <<a href="mailto:nathaniel.j.richard@jpl.nasa.gov" target="_blank">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='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>All,<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>-----------------------------------------------------------------------------------------------------------------------<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Marc Sanchez Net (332H)<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:10.0pt;color:gray'>Telecommunications Engineer</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;background:white'><span style='font-size:10.0pt;color:gray'>Jet Propulsion Laboratory</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;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='color:black'><a href="mailto:(617)%20953-7977" target="_blank"><span style='font-size:10.0pt;font-family:"Arial",sans-serif;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" target="_blank"><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='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>-----------------------------------------------------------------------------------------------------------------------<o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <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='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b>From:</b> <a href="mailto:sburleig.sb@gmail.com" target="_blank">sburleig.sb@gmail.com</a> <<a href="mailto:sburleig.sb@gmail.com" target="_blank">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" target="_blank">jordan.l.torgerson@jpl.nasa.gov</a>>; 'Felix Flentge' <<a href="mailto:Felix.Flentge@esa.int" target="_blank">Felix.Flentge@esa.int</a>>; Sanchez Net, Marc (US 332H) <<a href="mailto:marc.sanchez.net@jpl.nasa.gov" target="_blank">marc.sanchez.net@jpl.nasa.gov</a>>; 'Dr. Keith L Scott via SIS-DTN' <<a href="mailto:sis-dtn@mailman.ccsds.org" target="_blank">sis-dtn@mailman.ccsds.org</a>><br><b>Cc:</b> Gao, Jay L (US 332C) <<a href="mailto:jay.l.gao@jpl.nasa.gov" target="_blank">jay.l.gao@jpl.nasa.gov</a>>; Richard, Nate J (US 332C) <<a href="mailto:nathaniel.j.richard@jpl.nasa.gov" target="_blank">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='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Guys, a thought on this.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Scott<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <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='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b>From:</b> Torgerson, J. Leigh (US 332C) <<a href="mailto:jordan.l.torgerson@jpl.nasa.gov" target="_blank">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" target="_blank">Felix.Flentge@esa.int</a>>; <a href="mailto:sburleig.sb@gmail.com" target="_blank">sburleig.sb@gmail.com</a>; Sanchez Net, Marc (US 332H) <<a href="mailto:marc.sanchez.net@jpl.nasa.gov" target="_blank">marc.sanchez.net@jpl.nasa.gov</a>>; 'Dr. Keith L Scott via SIS-DTN' <<a href="mailto:sis-dtn@mailman.ccsds.org" target="_blank">sis-dtn@mailman.ccsds.org</a>><br><b>Cc:</b> Gao, Jay L (US 332C) <<a href="mailto:jay.l.gao@jpl.nasa.gov" target="_blank">jay.l.gao@jpl.nasa.gov</a>>; Richard, Nate J (US 332C) <<a href="mailto:nathaniel.j.richard@jpl.nasa.gov" target="_blank">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='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Thanks Felix – <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>regards,<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Leigh<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <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='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><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 <</span><a href="mailto:Felix.Flentge@esa.int" target="_blank"><span lang=EN-GB style='font-size:12.0pt'>Felix.Flentge@esa.int</span></a><span lang=EN-GB style='font-size:12.0pt;color:black'>><br><b>Date: </b>Monday, May 29, 2023 at 11:47 PM<br><b>To: </b>"Torgerson, Jordan L (332M)" <</span><a href="mailto:jordan.l.torgerson@jpl.nasa.gov" target="_blank"><span lang=EN-GB style='font-size:12.0pt'>jordan.l.torgerson@jpl.nasa.gov</span></a><span lang=EN-GB style='font-size:12.0pt;color:black'>>, "</span><a href="mailto:sburleig.sb@gmail.com" target="_blank"><span lang=EN-GB style='font-size:12.0pt'>sburleig.sb@gmail.com</span></a><span lang=EN-GB style='font-size:12.0pt;color:black'>" <</span><a href="mailto:sburleig.sb@gmail.com" target="_blank"><span lang=EN-GB style='font-size:12.0pt'>sburleig.sb@gmail.com</span></a><span lang=EN-GB style='font-size:12.0pt;color:black'>>, "Sanchez Net, Marc (US 332H)" <</span><a href="mailto:marc.sanchez.net@jpl.nasa.gov" target="_blank"><span lang=EN-GB style='font-size:12.0pt'>marc.sanchez.net@jpl.nasa.gov</span></a><span lang=EN-GB style='font-size:12.0pt;color:black'>>, "'Dr. Keith L Scott via SIS-DTN'" <</span><a href="mailto:sis-dtn@mailman.ccsds.org" target="_blank"><span lang=EN-GB style='font-size:12.0pt'>sis-dtn@mailman.ccsds.org</span></a><span lang=EN-GB style='font-size:12.0pt;color:black'>><br><b>Cc: </b>"Gao, Jay L (US 332C)" <</span><a href="mailto:jay.l.gao@jpl.nasa.gov" target="_blank"><span lang=EN-GB style='font-size:12.0pt'>jay.l.gao@jpl.nasa.gov</span></a><span lang=EN-GB style='font-size:12.0pt;color:black'>>, "Richard, Nate J (US 332C)" <</span><a href="mailto:nathaniel.j.richard@jpl.nasa.gov" target="_blank"><span lang=EN-GB style='font-size:12.0pt'>nathaniel.j.richard@jpl.nasa.gov</span></a><span lang=EN-GB style='font-size:12.0pt;color:black'>><br><b>Subject: </b>RE: [EXTERNAL] RE: [Sis-dtn] New version of LTP Corrigendum</span><o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-GB> </span><o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-GB>Hi Leigh,</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-GB> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><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.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-GB> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><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).</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-GB> </span><o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-GB>Regards,</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-GB>Felix</span><o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-GB> </span><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='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'><b>From:</b> Torgerson, J. Leigh (US 332C) <<a href="mailto:jordan.l.torgerson@jpl.nasa.gov" target="_blank">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" target="_blank">Felix.Flentge@esa.int</a>>; <a href="mailto:sburleig.sb@gmail.com" target="_blank">sburleig.sb@gmail.com</a>; Sanchez Net, Marc (US 332H) <<a href="mailto:marc.sanchez.net@jpl.nasa.gov" target="_blank">marc.sanchez.net@jpl.nasa.gov</a>>; 'Dr. Keith L Scott via SIS-DTN' <<a href="mailto:sis-dtn@mailman.ccsds.org" target="_blank">sis-dtn@mailman.ccsds.org</a>><br><b>Cc:</b> Gao, Jay L (US 332C) <<a href="mailto:jay.l.gao@jpl.nasa.gov" target="_blank">jay.l.gao@jpl.nasa.gov</a>>; Richard, Nate J (US 332C) <<a href="mailto:nathaniel.j.richard@jpl.nasa.gov" target="_blank">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='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'><span lang=EN-GB> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'>Thanks Felix – <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.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='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.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='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'>regards<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'>Leigh<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.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='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.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 <</span><a href="mailto:Felix.Flentge@esa.int" target="_blank"><span lang=EN-GB style='font-size:12.0pt'>Felix.Flentge@esa.int</span></a><span lang=EN-GB style='font-size:12.0pt;color:black'>><br><b>Date: </b>Thursday, May 25, 2023 at 4:56 AM<br><b>To: </b>"</span><a href="mailto:sburleig.sb@gmail.com" target="_blank"><span lang=EN-GB style='font-size:12.0pt'>sburleig.sb@gmail.com</span></a><span lang=EN-GB style='font-size:12.0pt;color:black'>" <</span><a href="mailto:sburleig.sb@gmail.com" target="_blank"><span lang=EN-GB style='font-size:12.0pt'>sburleig.sb@gmail.com</span></a><span lang=EN-GB style='font-size:12.0pt;color:black'>>, "Sanchez Net, Marc (US 332H)" <</span><a href="mailto:marc.sanchez.net@jpl.nasa.gov" target="_blank"><span lang=EN-GB style='font-size:12.0pt'>marc.sanchez.net@jpl.nasa.gov</span></a><span lang=EN-GB style='font-size:12.0pt;color:black'>>, "'Dr. Keith L Scott via SIS-DTN'" <</span><a href="mailto:sis-dtn@mailman.ccsds.org" target="_blank"><span lang=EN-GB style='font-size:12.0pt'>sis-dtn@mailman.ccsds.org</span></a><span lang=EN-GB style='font-size:12.0pt;color:black'>><br><b>Cc: </b>"Torgerson, Jordan L (332M)" <</span><a href="mailto:jordan.l.torgerson@jpl.nasa.gov" target="_blank"><span lang=EN-GB style='font-size:12.0pt'>jordan.l.torgerson@jpl.nasa.gov</span></a><span lang=EN-GB style='font-size:12.0pt;color:black'>><br><b>Subject: </b>[EXTERNAL] RE: [Sis-dtn] New version of LTP Corrigendum</span><o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'><span lang=EN-GB> </span><o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'><span lang=EN-GB>Hi,</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'><span lang=EN-GB> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'><span lang=EN-GB>I agree with the modifications below.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'><span lang=EN-GB> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'><span lang=EN-GB>Some additional points:</span><o:p></o:p></p><p class=m-5360493418966220258msolistparagraph style='margin-left:1.0in'><span lang=EN-GB style='font-family:Symbol'>·</span><span lang=EN-GB style='font-size:7.0pt;font-family:"Times New Roman",serif'> </span><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).</span><o:p></o:p></p><p class=m-5360493418966220258msolistparagraph style='margin-left:1.0in'><span lang=EN-GB style='font-family:Symbol'>·</span><span lang=EN-GB style='font-size:7.0pt;font-family:"Times New Roman",serif'> </span><span lang=EN-GB>Should we discourage use of mixed sessions (on the other hand LTP green is optional anyway)?</span><o:p></o:p></p><p class=m-5360493418966220258msolistparagraph style='margin-left:1.0in'><span lang=EN-GB style='font-family:Symbol'>·</span><span lang=EN-GB style='font-size:7.0pt;font-family:"Times New Roman",serif'> </span><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</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'><span lang=EN-GB> </span><o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'><span lang=EN-GB>Regards,</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'><span lang=EN-GB>Felix</span><o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'><span lang=EN-GB> </span><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='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><b>From:</b> SIS-DTN <<a href="mailto:sis-dtn-bounces@mailman.ccsds.org" target="_blank">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" target="_blank">marc.sanchez.net@jpl.nasa.gov</a>>; 'Dr. Keith L Scott via SIS-DTN' <<a href="mailto:sis-dtn@mailman.ccsds.org" target="_blank">sis-dtn@mailman.ccsds.org</a>><br><b>Cc:</b> 'Torgerson, J. Leigh (US 332C)' <<a href="mailto:jordan.l.torgerson@jpl.nasa.gov" target="_blank">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='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><span lang=EN-GB> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.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='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'>Scott<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;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='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><b>From:</b> SIS-DTN <<a href="mailto:sis-dtn-bounces@mailman.ccsds.org" target="_blank">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" target="_blank">sis-dtn@mailman.ccsds.org</a>><br><b>Cc:</b> Torgerson, J. Leigh (US 332C) <<a href="mailto:jordan.l.torgerson@jpl.nasa.gov" target="_blank">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='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'> <o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><span style='color:black'>All,</span><o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><span style='color:black'> </span><o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><span style='color:black'>Please find attached a new version of the LTP corrigendum with some modifications including:</span><o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.5in'><span style='font-size:10.0pt;font-family:Symbol;color:black'>·</span><span style='font-size:7.0pt;font-family:"Times New Roman",serif;color:black'> </span><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).</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.5in'><span style='font-size:10.0pt;font-family:Symbol;color:black'>·</span><span style='font-size:7.0pt;font-family:"Times New Roman",serif;color:black'> </span><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).</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.5in'><span style='font-size:10.0pt;font-family:Symbol;color:black'>·</span><span style='font-size:7.0pt;font-family:"Times New Roman",serif;color:black'> </span><span style='color:black'>Brian has commented on two additional issues (see </span><a href="https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/22__;!!PvBDto6Hs4WbVuu7!J3wEpyPHlAiGcXO0VDc8uO1zb9BOrpYLw3dw6BHPigpmcy0Q4f8gxX6hHLnQOqg_AVxEg_MYrByNRr1urhAp-KViTuP33vk9LEw4$" target="_blank" title="https://github.com/nasa/HDTN/issues/22">here</a><span style='color:black'> and </span><a href="https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/24__;!!PvBDto6Hs4WbVuu7!J3wEpyPHlAiGcXO0VDc8uO1zb9BOrpYLw3dw6BHPigpmcy0Q4f8gxX6hHLnQOqg_AVxEg_MYrByNRr1urhAp-KViTuP33uBoiHHY$" target="_blank" title="https://github.com/nasa/HDTN/issues/24">here</a><span style='color:black'>), 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.</span><o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.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? </span><o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><span style='color:black'> </span><o:p></o:p></p></div><div><div><div style='margin-top:12.0pt;margin-bottom:12.0pt;min-width:424px' id="m_-5360493418966220258LPBorder_GTaHR0cHM6Ly9naXRodWIuY29tL25hc2EvSERUTi9pc3N1ZXMvMjQ."><table class=MsoNormalTable border=1 cellspacing=4 cellpadding=0 width="100%" style='width:100.0%;margin-left:1.0in;border:solid #C8C8C8 1.0pt'><tr><td valign=top style='border:none;padding:9.0pt 27.0pt 9.0pt 9.0pt'></td><td width="50%" valign=top style='width:50.48%;border:none;padding:9.0pt 27.0pt 9.0pt 9.0pt'><div style='margin-right:6.0pt;margin-bottom:9.0pt' id="m_-5360493418966220258LPTitle765850"><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><a href="https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/24__;!!PvBDto6Hs4WbVuu7!J3wEpyPHlAiGcXO0VDc8uO1zb9BOrpYLw3dw6BHPigpmcy0Q4f8gxX6hHLnQOqg_AVxEg_MYrByNRr1urhAp-KViTuP33uBoiHHY$" target="_blank"><span style='font-size:16.0pt;font-family:"Segoe UI Light",sans-serif;text-decoration:none'>Defer data retransmission with out-of-order report segments · Issue #24 · nasa/HDTN</span></a><span class=MsoHyperlink><span style='color:windowtext;text-decoration:none'><o:p></o:p></span></span></p></div><div style='margin-right:6.0pt;margin-bottom:9.0pt;max-height:100px;overflow:hidden' id="m_-5360493418966220258LPDescription765850"><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:#666666'><a href="https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/24__;!!PvBDto6Hs4WbVuu7!J3wEpyPHlAiGcXO0VDc8uO1zb9BOrpYLw3dw6BHPigpmcy0Q4f8gxX6hHLnQOqg_AVxEg_MYrByNRr1urhAp-KViTuP33uBoiHHY$" target="_blank"><span style='color:#666666;text-decoration:none'>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...</span></a></span><span class=MsoHyperlink><span style='color:windowtext;text-decoration:none'><o:p></o:p></span></span></p></div><div id="m_-5360493418966220258LPMetadata765850"><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:#A6A6A6'><a href="https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/24__;!!PvBDto6Hs4WbVuu7!J3wEpyPHlAiGcXO0VDc8uO1zb9BOrpYLw3dw6BHPigpmcy0Q4f8gxX6hHLnQOqg_AVxEg_MYrByNRr1urhAp-KViTuP33uBoiHHY$" target="_blank">github.com</a></span><span class=MsoHyperlink><span style='color:windowtext;text-decoration:none'><o:p></o:p></span></span></p></div></td></tr></table></div></div><table class=MsoNormalTable border=1 cellspacing=4 cellpadding=0 width="100%" style='width:100.0%;margin-left:1.0in;border:solid #C8C8C8 1.0pt'><tr><td valign=top style='border:none;padding:9.0pt 27.0pt 9.0pt 9.0pt'></td><td width="50%" valign=top style='width:50.48%;border:none;padding:9.0pt 27.0pt 9.0pt 9.0pt'><div style='margin-right:6.0pt;margin-bottom:9.0pt' id="m_-5360493418966220258LPTitle694819"><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><a href="https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/24__;!!PvBDto6Hs4WbVuu7!J3wEpyPHlAiGcXO0VDc8uO1zb9BOrpYLw3dw6BHPigpmcy0Q4f8gxX6hHLnQOqg_AVxEg_MYrByNRr1urhAp-KViTuP33uBoiHHY$" target="_blank"><span style='font-size:16.0pt;font-family:"Segoe UI Light",sans-serif;text-decoration:none'>Defer synchronous reception report with out-of-order data segments · Issue #22 · nasa/HDTN</span></a><span class=MsoHyperlink><span style='color:windowtext;text-decoration:none'><o:p></o:p></span></span></p></div><div style='margin-right:6.0pt;margin-bottom:9.0pt;max-height:100px;overflow:hidden' id="m_-5360493418966220258LPDescription694819"><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:#666666'><a href="https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/24__;!!PvBDto6Hs4WbVuu7!J3wEpyPHlAiGcXO0VDc8uO1zb9BOrpYLw3dw6BHPigpmcy0Q4f8gxX6hHLnQOqg_AVxEg_MYrByNRr1urhAp-KViTuP33uBoiHHY$" target="_blank"><span style='color:#666666;text-decoration:none'>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 ...</span></a></span><span class=MsoHyperlink><span style='color:windowtext;text-decoration:none'><o:p></o:p></span></span></p></div><div id="m_-5360493418966220258LPMetadata694819"><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:#A6A6A6'><a href="https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/24__;!!PvBDto6Hs4WbVuu7!J3wEpyPHlAiGcXO0VDc8uO1zb9BOrpYLw3dw6BHPigpmcy0Q4f8gxX6hHLnQOqg_AVxEg_MYrByNRr1urhAp-KViTuP33uBoiHHY$" target="_blank">github.com</a></span><span class=MsoHyperlink><span style='color:windowtext;text-decoration:none'><o:p></o:p></span></span></p></div></td></tr></table><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><span style='color:black'><a href="https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/24__;!!PvBDto6Hs4WbVuu7!J3wEpyPHlAiGcXO0VDc8uO1zb9BOrpYLw3dw6BHPigpmcy0Q4f8gxX6hHLnQOqg_AVxEg_MYrByNRr1urhAp-KViTuP33uBoiHHY$" target="_blank"><span style='color:black;text-decoration:none'> </span></a></span><span class=MsoHyperlink><span style='color:windowtext;text-decoration:none'><o:p></o:p></span></span></p></div></div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><span style='color:black'><a href="https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/24__;!!PvBDto6Hs4WbVuu7!J3wEpyPHlAiGcXO0VDc8uO1zb9BOrpYLw3dw6BHPigpmcy0Q4f8gxX6hHLnQOqg_AVxEg_MYrByNRr1urhAp-KViTuP33uBoiHHY$" target="_blank"><span style='color:black;text-decoration:none'>Thanks,</span></a></span><span class=MsoHyperlink><span style='color:windowtext;text-decoration:none'><o:p></o:p></span></span></p></div><div id="m_-5360493418966220258Signature"><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><a href="https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/24__;!!PvBDto6Hs4WbVuu7!J3wEpyPHlAiGcXO0VDc8uO1zb9BOrpYLw3dw6BHPigpmcy0Q4f8gxX6hHLnQOqg_AVxEg_MYrByNRr1urhAp-KViTuP33uBoiHHY$" target="_blank"><span style='color:windowtext;text-decoration:none'>-----------------------------------------------------------------------------------------------------------------------</span></a><span class=MsoHyperlink><span style='color:windowtext;text-decoration:none'><o:p></o:p></span></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><a href="https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/24__;!!PvBDto6Hs4WbVuu7!J3wEpyPHlAiGcXO0VDc8uO1zb9BOrpYLw3dw6BHPigpmcy0Q4f8gxX6hHLnQOqg_AVxEg_MYrByNRr1urhAp-KViTuP33uBoiHHY$" target="_blank"><span style='color:windowtext;text-decoration:none'>Marc Sanchez Net (332H)</span></a><span class=MsoHyperlink><span style='color:windowtext;text-decoration:none'><o:p></o:p></span></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><span style='font-size:10.0pt;color:gray'><a href="https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/24__;!!PvBDto6Hs4WbVuu7!J3wEpyPHlAiGcXO0VDc8uO1zb9BOrpYLw3dw6BHPigpmcy0Q4f8gxX6hHLnQOqg_AVxEg_MYrByNRr1urhAp-KViTuP33uBoiHHY$" target="_blank"><span style='color:gray;text-decoration:none'>Telecommunications Engineer</span></a></span><span class=MsoHyperlink><span style='color:windowtext;text-decoration:none'><o:p></o:p></span></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in;background:white'><span style='font-size:10.0pt;color:gray'><a href="https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/24__;!!PvBDto6Hs4WbVuu7!J3wEpyPHlAiGcXO0VDc8uO1zb9BOrpYLw3dw6BHPigpmcy0Q4f8gxX6hHLnQOqg_AVxEg_MYrByNRr1urhAp-KViTuP33uBoiHHY$" target="_blank"><span style='color:gray;text-decoration:none'>Jet Propulsion Laboratory</span></a></span><span class=MsoHyperlink><span style='color:windowtext;text-decoration:none'><o:p></o:p></span></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in;background:white'><span style='font-size:10.0pt;color:gray'><a href="https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/24__;!!PvBDto6Hs4WbVuu7!J3wEpyPHlAiGcXO0VDc8uO1zb9BOrpYLw3dw6BHPigpmcy0Q4f8gxX6hHLnQOqg_AVxEg_MYrByNRr1urhAp-KViTuP33uBoiHHY$" target="_blank"><span style='color:gray;text-decoration:none'>Cell:</span><span style='font-family:"Arial",sans-serif;color:#222222;text-decoration:none'> </span><span style='font-family:"Arial",sans-serif'>(617) 953-7977</span><span style='font-family:"Arial",sans-serif;color:#0070C0;text-decoration:none'> </span><span style='color:gray;text-decoration:none'>|</span><span style='font-family:"Arial",sans-serif;color:#0070C0;text-decoration:none'> </span><span style='color:gray;text-decoration:none'>Email:</span><span style='font-family:"Arial",sans-serif;color:#222222;text-decoration:none'> </span><span style='font-family:"Arial",sans-serif'>marc.sanchez.net@jpl.nasa.gov</span></a></span><span class=MsoHyperlink><span style='color:windowtext;text-decoration:none'><o:p></o:p></span></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><a href="https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/24__;!!PvBDto6Hs4WbVuu7!J3wEpyPHlAiGcXO0VDc8uO1zb9BOrpYLw3dw6BHPigpmcy0Q4f8gxX6hHLnQOqg_AVxEg_MYrByNRr1urhAp-KViTuP33uBoiHHY$" target="_blank"><span style='color:windowtext;text-decoration:none'>-----------------------------------------------------------------------------------------------------------------------</span></a><span class=MsoHyperlink><span style='color:windowtext;text-decoration:none'><o:p></o:p></span></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><a href="https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/24__;!!PvBDto6Hs4WbVuu7!J3wEpyPHlAiGcXO0VDc8uO1zb9BOrpYLw3dw6BHPigpmcy0Q4f8gxX6hHLnQOqg_AVxEg_MYrByNRr1urhAp-KViTuP33uBoiHHY$" target="_blank"><span style='color:windowtext;text-decoration:none'> </span></a><span class=MsoHyperlink><span style='color:windowtext;text-decoration:none'><o:p></o:p></span></span></p></div></div></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'><span lang=EN-GB><a href="https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/24__;!!PvBDto6Hs4WbVuu7!J3wEpyPHlAiGcXO0VDc8uO1zb9BOrpYLw3dw6BHPigpmcy0Q4f8gxX6hHLnQOqg_AVxEg_MYrByNRr1urhAp-KViTuP33uBoiHHY$" target="_blank"><span style='color:windowtext;text-decoration:none'>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 (</span>dpo@esa.int<span style='color:windowtext;text-decoration:none'>). </span></a></span><span class=MsoHyperlink><span style='color:windowtext;text-decoration:none'><o:p></o:p></span></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-GB><a href="https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/24__;!!PvBDto6Hs4WbVuu7!J3wEpyPHlAiGcXO0VDc8uO1zb9BOrpYLw3dw6BHPigpmcy0Q4f8gxX6hHLnQOqg_AVxEg_MYrByNRr1urhAp-KViTuP33uBoiHHY$" target="_blank"><span style='color:windowtext;text-decoration:none'>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 (</span>dpo@esa.int<span style='color:windowtext;text-decoration:none'>). </span></a></span><span class=MsoHyperlink><span style='color:windowtext;text-decoration:none'><o:p></o:p></span></span></p></div></div></div><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='color:windowtext;text-decoration:none'>_______________________________________________<br>SIS-DTN mailing list<br></span>SIS-DTN@mailman.ccsds.org<span style='color:windowtext;text-decoration:none'><br></span>https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn</a><span class=MsoHyperlink><span style='color:windowtext;text-decoration:none'><o:p></o:p></span></span></p></div></div></blockquote><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='color:windowtext;text-decoration:none'><br clear=all></span></a><span class=MsoHyperlink><span style='color:windowtext;text-decoration:none'><o:p></o:p></span></span></p><p class=MsoNormal><span class=gmailsignatureprefix><a href="https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/24__;!!PvBDto6Hs4WbVuu7!J3wEpyPHlAiGcXO0VDc8uO1zb9BOrpYLw3dw6BHPigpmcy0Q4f8gxX6hHLnQOqg_AVxEg_MYrByNRr1urhAp-KViTuP33uBoiHHY$" target="_blank"><span style='color:windowtext;text-decoration:none'>-- </span></a></span><span class=MsoHyperlink><span style='color:windowtext;text-decoration:none'><o:p></o:p></span></span></p><div><div><div><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='color:windowtext;text-decoration:none'>Please send any postal/overnight deliveries to:</span></a><span class=MsoHyperlink><span style='color:windowtext;text-decoration:none'><o:p></o:p></span></span></p></div><div><div><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='color:windowtext;text-decoration:none'>Vint Cerf</span></a><span class=MsoHyperlink><span style='color:windowtext;text-decoration:none'><o:p></o:p></span></span></p></div><div><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='color:windowtext;text-decoration:none'>Google, LLC</span></a><span class=MsoHyperlink><span style='color:windowtext;text-decoration:none'><o:p></o:p></span></span></p></div><div><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='color:windowtext;text-decoration:none'>1900 Reston Metro Plaza, 16th Floor</span></a><span class=MsoHyperlink><span style='color:windowtext;text-decoration:none'><o:p></o:p></span></span></p></div><div><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='color:windowtext;text-decoration:none'>Reston, VA 20190</span></a><span class=MsoHyperlink><span style='color:windowtext;text-decoration:none'><o:p></o:p></span></span></p></div><div><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='color:windowtext;text-decoration:none'>+1 (571) 213 1346</span></a><span class=MsoHyperlink><span style='color:windowtext;text-decoration:none'><o:p></o:p></span></span></p></div></div><div><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='color:windowtext;text-decoration:none'>until further notice</span></a><span class=MsoHyperlink><span style='color:windowtext;text-decoration:none'><o:p></o:p></span></span></p></div></div></div></div></div></body></html>