<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* 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:#0563C1;
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;}
@page WordSection1
{size:8.5in 11.0in;
margin:70.85pt 70.85pt 56.7pt 70.85pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:78211529;
mso-list-type:hybrid;
mso-list-template-ids:142395850 67698689 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0: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 l0: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 l0: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 l0: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 l0: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 l0: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 l0: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 l0: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 l0: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="#0563C1" vlink="#954F72" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal">Hi,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">A couple of additional thoughts on the email thread :<o:p></o:p></p>
<ul style="margin-top:0in" type="disc">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1">Even though LTP and the “new protocol” provide selective ARQ capabilities that are similar in that they allow efficient operation over high bandwidth-delay products, actual operations
of a high-latency-low-rate link is quite different from a low-latency-high-rate link. The need to pause/resume sessions is one example of such differences. This makes me think that the “new protocol” may not be an LTP replacement now or necessarily in the
mid-term future but rather a complement (hence the need for a completely separate name).<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1">My vote is for the “new protocol” to have a single interface both for reliable and unreliable services, which should be just blocks, not segments. The proposed wording by Scott seems
very reasonable and should be added as a note to the specification to clarify that point that in most cases you want to have a block be equal to a segment when operating in unreliable mode.<o:p></o:p></li></ul>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thanks,<o:p></o:p></p>
<div>
<p class="MsoNormal">-----------------------------------------------------------------------------------------------------------------------<o:p></o:p></p>
<p class="MsoNormal">Marc Sanchez Net (332H)<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:10.0pt;color:gray">Telecommunications Engineer</span><o:p></o:p></p>
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;color:gray">Jet Propulsion Laboratory<o:p></o:p></span></p>
<p class="MsoNormal" style="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;color:blue">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">-----------------------------------------------------------------------------------------------------------------------<o:p></o:p></p>
</div>
<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> SIS-DTN <sis-dtn-bounces@mailman.ccsds.org> <b>
On Behalf Of </b>sburleig.sb--- via SIS-DTN<br>
<b>Sent:</b> Monday, May 15, 2023 10:20 AM<br>
<b>To:</b> EXTERNAL-Sipos, Brian J (US 9300-Affiliate) <brian.sipos@jhuapl.edu>; Jeremy.Mayer@dlr.de; Felix.Flentge@esa.int<br>
<b>Cc:</b> sis-dtn@mailman.ccsds.org<br>
<b>Subject:</b> [EXTERNAL] Re: [Sis-dtn] LTPv2 Draft Blue Book for Review<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Hi. Very thoughtful comments, on which I will offer two remarks.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Pausing and resuming sessions would be critical to the successful operation of this protocol over interplanetary links characterized by long signal propagation latencies and punctuated transmission opportunities. For continuous connectivity
in LEO, probably no problem.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I can appreciate the appeal of symmetry between input and output, blocks in / blocks out. In my experience, though, the operators of some space flight missions will find any delay in the delivery of unreliable data segments (while waiting
for a block to be reassembled or a timer to expire) functionally unacceptable. Maybe the way to reconcile these concerns is to make it clear that the block size for unreliable data is variable, so that the source entity can freely transmit small, independently
significant client service data units in individual blocks such that each one is sent in a single segment.<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> SIS-DTN <<a href="mailto:sis-dtn-bounces@mailman.ccsds.org">sis-dtn-bounces@mailman.ccsds.org</a>>
<b>On Behalf Of </b>Sipos, Brian J. via SIS-DTN<br>
<b>Sent:</b> Monday, May 15, 2023 8:54 AM<br>
<b>To:</b> <a href="mailto:Jeremy.Mayer@dlr.de">Jeremy.Mayer@dlr.de</a>; <a href="mailto:Felix.Flentge@esa.int">
Felix.Flentge@esa.int</a><br>
<b>Cc:</b> <a href="mailto:sis-dtn@mailman.ccsds.org">sis-dtn@mailman.ccsds.org</a><br>
<b>Subject:</b> Re: [Sis-dtn] LTPv2 Draft Blue Book for Review<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">Jeremy, Felix,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">I think there is a lot of improvement in both encoding and state machine for this new protocol draft, while keeping with the capabilities and rough service interface of earlier LTP. I’m attaching a document with
inline comments for specific sections and paragraphs. Two areas that I think are underspecified currently are session invariants/state and the underlying transport requirements/assumptions.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">An explanation of session invariants would be redundant, but I think helpful to an implementer to understand which parameters are associated with an individual session, are unchanging between all segments within
a session, and for a receiver are memorized when first received. As a follow-on it would be good to indicate how a receiver should respond if a segment comes in that violates that invariant; does that session get ignored from that point on, canceled with in-band
messaging, or something more severe like stop processing all segments from that sender (I don’t recommend this but some specific guidance would bound an engine behavior).
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Also in earlier LTP implementations there is the possibility of pausing a session (by simply pausing all timers associated with the session and stopping any transmit of new/queued segments for that session);
is this behavior useful enough to include in the official LTP engine service interface? It seems straightforward enough to be an optional indication to the engine to pause/un-pause a session.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">The parts missing from specification of the underlying transport interface are comments in the document, but generally it is good to be explicit about what is required and what is assumed about the transport.
This helps in two ways: it makes it more obvious to an implementer about what must be added as glue between what the upper protocol requires and the lower transport provides, and it also makes it obvious when a specific transport is just inappropriate and
to not try to use it. For example, earlier LTP had a few assumptions about in-order segment delivery (some workarounds are possible within the protocol requirements) which would make it unsuitable or vulnerable DoS if used over IP. These kinds of things are
not necessarily bad, just need to be known to the implementer rather than assumed and unstated.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal">E<span style="color:#1F497D">arlier issues reported to HDTN project related to out-of-order reception are linked below. Issue #22 and #24 are both optimizations to allow an engine to delay sending report or data retransmit segments long
enough to receive any out-of-order segments that would affect the report claims or avoid the retransmit entirely. Issue #23 is about when to send an "asynchronous reception report" which is defined by LTP but never specified when an engine would actually send
one. Issue #19 is another unspecified behavior that (could, and in HDTN case did) allow a memory leak and provide a method of denial-of-service attack.<o:p></o:p></span></p>
<p class="MsoNormal"><a href="https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/24__;!!PvBDto6Hs4WbVuu7!IdxrQuas46fJyetQhQ-Fjc4VI9ZRy2iJCXUuYXhxpXjRKqbtkHGRADEAFh7_q3Sjsv0RiTjq6GgB-TZi_dp53Gz8Rhifr_Q$">https://github.com/nasa/HDTN/issues/24</a><span style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><a href="https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/23__;!!PvBDto6Hs4WbVuu7!IdxrQuas46fJyetQhQ-Fjc4VI9ZRy2iJCXUuYXhxpXjRKqbtkHGRADEAFh7_q3Sjsv0RiTjq6GgB-TZi_dp53Gz8Bxhutag$">https://github.com/nasa/HDTN/issues/23</a><span style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><a href="https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/22__;!!PvBDto6Hs4WbVuu7!IdxrQuas46fJyetQhQ-Fjc4VI9ZRy2iJCXUuYXhxpXjRKqbtkHGRADEAFh7_q3Sjsv0RiTjq6GgB-TZi_dp53Gz8FXOGgek$">https://github.com/nasa/HDTN/issues/22</a><span style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><a href="https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/19__;!!PvBDto6Hs4WbVuu7!IdxrQuas46fJyetQhQ-Fjc4VI9ZRy2iJCXUuYXhxpXjRKqbtkHGRADEAFh7_q3Sjsv0RiTjq6GgB-TZi_dp53Gz8YbOumO8$">https://github.com/nasa/HDTN/issues/19</a><span style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">On the topic of the overlayer service interface for unreliable data, I am strongly in favor of the current interface where the LTP engine provides the entire block data with a reception map. It is much more useful
from an overlayer/BPA perspective to have both TX and RX interfaces operate at the scale of entire blocks (i.e. “block goes in to TX, block comes out of RX”). Since any overlayer will need to reassemble segments and include a reception timeout anyway, it’s
better for that logic to be as close to the segment processing as possible (in the LTP engine) and not need to be re-implemented with every use of the engine. This is especially true as unreliable timeout presents a possible DoS attack vector.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Finally, regardless of whatever name applies to this new protocol it would be helpful to explicitly state that it is on-the-wire unique from earlier LTP and can be used over the same transport as LTP and segments
can be handled unambiguously from LTP segments. This will allow re-use of existing allocation such as the
</span><a href="https://urldefense.us/v3/__https:/www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=1113__;!!PvBDto6Hs4WbVuu7!IdxrQuas46fJyetQhQ-Fjc4VI9ZRy2iJCXUuYXhxpXjRKqbtkHGRADEAFh7_q3Sjsv0RiTjq6GgB-TZi_dp53Gz8Y0QOz1c$">LTP
UDP Port</a><span style="color:#1F497D"> and similar service identifiers.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Thanks for all of the effort in designing and documenting this.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Brian S.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><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"><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>Jeremy Mayer via SIS-DTN<br>
<b>Sent:</b> Tuesday, May 9, 2023 5:48 PM<br>
<b>To:</b> <a href="mailto:sis-dtn@mailman.ccsds.org">sis-dtn@mailman.ccsds.org</a><br>
<b>Cc:</b> <a href="mailto:ccorsten@gmv.com">ccorsten@gmv.com</a><br>
<b>Subject:</b> [EXT] [Sis-dtn] LTPv2 Draft Blue Book for Review<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div id="APLWarningText">
<table class="MsoNormalTable" border="0" cellspacing="0" cellpadding="0" align="left">
<tbody>
<tr>
<td width="100%" style="width:100.0%;background:#E0E0E0;padding:0in 0in 0in 0in">
<p class="MsoNormal" style="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"><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><span style="font-size:12.0pt;font-family:"Times New Roman",serif"><o:p></o:p></span></p>
</td>
</tr>
</tbody>
</table>
<p> <o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><span lang="EN-GB">Hi everyone,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB">In order to provide a baseline for tomorrows discussion of the proposed LTPv2 protocol, I’ve attached the draft blue book for the standard. After showcasing the proposed approach and rational, we’re intending to go through
the document, focusing on the underlying protocol. <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">Thanks,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB">Jeremy & Felix<o:p></o:p></span></p>
</div>
</body>
</html>