<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=iso-8859-1">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:"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:0cm;
margin-bottom:.0001pt;
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;}
tt
{mso-style-priority:99;
font-family:"Courier New";}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 2.0cm 70.85pt;}
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-GB" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Hi both,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">I also concur that the use of intermediate checkpoints vs. final one only is a tricky point of the LTP specification. It is allowed, but probably not much used. It can certainly make sense as Felix
points our when for instance you have a very large LTP block being set, with lossy channels, and limited resources so that it can be problematic to store segments until the end. The mechanism of intermediate and final CPs is somehow based on what still happens
in CFDP-Class 2 with immediate and deferred retransmissions. Some comparison between these two schemes is available here:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><a href="https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=1468744">https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=1468744</a><o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">There you can see that depending on the scenario, sometimes deferred works better, sometimes immediate is better. Useless to say, however, that the immediate mechanism is much more complex.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Coming back to the original point (i.e., the retransmission cycle limit), I have the same understanding as Carlo’s. The retransmission cycle is comprising the data segments being retransmitted (as
a consequence of received RS claiming something was missed) and the corresponding RS. What I find a bit weird in my opinion is that the specification already defined an error-code for handling excessive retransmission, but then later the specification states
that it’s implementation specific. The setting of such a value is certainly implementations specific, the fact to have such a limit is in my view necessary to avoid that retransmission cycles will last forever (if the network conditions are bad, there might
be an excessive number of retransmissions). I remember that a similar mechanism is also in place in TCP.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Tomaso<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><b>From:</b> Felix.Flentge@esa.int <Felix.Flentge@esa.int> <br>
<b>Sent:</b> Freitag, 26. <span lang="EN-US">Februar 2021 10:05<br>
<b>To:</b> Carlo Caini <carlo.caini@unibo.it><br>
<b>Cc:</b> sis-dtn@mailman.ccsds.org; Cola, Tomaso de <Tomaso.deCola@dlr.de><br>
<b>Subject:</b> RE: [Sis-dtn] Telecon Notes 20210224<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">Hi Carlo,</span>
<br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">I assume there could be advantages of intermediate checkpoints in cases where the duration of the session >> RTT (could reduce overall latency, on-board memory could be freed).</span>
<br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">I certainly like the idea of a blocklifetime. It could maybe even be an optional parameter of the Transmission.request (which might need some changes anyway because of the removal of mixed sessions).</span>
<br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">Regards,</span> <br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">Felix</span> <br>
<br>
<br>
<br>
<span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F">From: </span><span style="font-size:9.0pt;font-family:"Arial",sans-serif">"Carlo Caini" <<a href="mailto:carlo.caini@unibo.it">carlo.caini@unibo.it</a>></span>
<br>
<span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F">To: </span><span style="font-size:9.0pt;font-family:"Arial",sans-serif">"<a href="mailto:Felix.Flentge@esa.int">Felix.Flentge@esa.int</a>" <<a href="mailto:Felix.Flentge@esa.int">Felix.Flentge@esa.int</a>>,
"<a href="mailto:Tomaso.deCola@dlr.de">Tomaso.deCola@dlr.de</a>" <<a href="mailto:Tomaso.deCola@dlr.de">Tomaso.deCola@dlr.de</a>></span>
<br>
<span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F">Cc: </span><span style="font-size:9.0pt;font-family:"Arial",sans-serif">"<a href="mailto:sis-dtn@mailman.ccsds.org">sis-dtn@mailman.ccsds.org</a>" <<a href="mailto:sis-dtn@mailman.ccsds.org">sis-dtn@mailman.ccsds.org</a>></span>
<br>
<span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F">Date: </span><span style="font-size:9.0pt;font-family:"Arial",sans-serif">26/02/2021 09:01</span>
<br>
<span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F">Subject: </span><span style="font-size:9.0pt;font-family:"Arial",sans-serif">RE: [Sis-dtn] Telecon Notes 20210224</span>
<o:p></o:p></p>
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="3" width="100%" noshade="" style="color:#A0A0A0" align="center">
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
<br>
<br>
<tt><span style="font-size:10.0pt">Dear Felix,</span></tt><span style="font-size:10.0pt;font-family:"Courier New""><br>
<tt> I agree with you that the text is difficult to understand, but I would ascribe the problem to the protocol, which is maybe too complex. In particular, 1) the possibility of inserting CP before of the final segment of a block and 2) the possibility of
sending multiple RS in response to the same CP, make the the protocol most likely more complex than necessary, and in turn, also difficult to describe.</tt><br>
<tt>My interpretation of the text (I am not sue too) is that at the first Tx attempt, the oustanding CPs are 1) the compulsory CP that flags the latest segment; 2) any other gratuitous CP that may be inserted before the latest segment. Each of these CP triggers
one or more RS, depending on the number of claims; these RSs, one recived, trigger data ReTx and new CPs, belonging to the first Re-Tx cycle and so on. It is diffiucult to explain and to implement.</tt><br>
<tt>Now, if you remove the possibility of inserting intermediate CPs (actually, they are never inserted by ION), things start to improve. By the way, with a propagation delay that is dominant on the "radiation time", in my opinion there is not any advantage
in using intermediate CPs. Let us assume that the RTT is 6 minutes and that the radiationtime is 1s. What is the advantage of receiving an intermediate CP at, say 500ms before the last segment flagged as CP? It would just generate an RS 500ms before the last,
thus reTx could start 500ms before, which seems of little help, considering the 3600 s RTT.</tt><br>
<tt>The possibility of spreading claims on multiple RS is manageable (ION does), but it makes once again maybe more complex than necesary the algorithm, as multiple RSs means multiple CPs (the "oustanding ones" in my interpretation) for each Re-Tx cycle.</tt><br>
<tt>Last comment, I agree once again with you that many conditions could suggest the closing of an ongoing sessions. To those you mentioned I would add the duration of a session. I mean that in my opinion a session should have a time limit. Suppose that an
RS is followed by an RAS (RS ACK), but not by any retranmissions for whatever reason (the Tx is lazy or worse...). On the Rx side a buffer plenty of data would be kept forever as the RS was confirmed by the RAS...</tt><br>
<tt>A second reson for a time limit, is that a block should have a lifetime, as bundles. Otherwise is pefectly possible, in the presence of a scheduled intermittent link, that a session stay frozen for hours and that during this time the content of the block,
i.e. a bundle, expires. Is a non-sense that, at the next, contact LTP carry on a session whose content is to be discarded as soon as passed to BP. This could be easily avoided by associating a blocklifetime (<=bundle_lifetime) to every session.</tt><br>
<tt>Yours,</tt><br>
<tt> carlo </tt><br>
<br>
<br>
<br>
<tt>________________________________________</tt><br>
<tt>Da: SIS-DTN [sis-dtn-bounces@mailman.ccsds.org] per conto di <a href="mailto:Felix.Flentge@esa.int">
Felix.Flentge@esa.int</a> [Felix.Flentge@esa.int]</tt><br>
<tt>Inviato: venerd́ 26 febbraio 2021 08:08</tt><br>
<tt>A: <a href="mailto:Tomaso.deCola@dlr.de">Tomaso.deCola@dlr.de</a></tt><br>
<tt>Cc: <a href="mailto:sis-dtn@mailman.ccsds.org">sis-dtn@mailman.ccsds.org</a></tt><br>
<tt>Oggetto: Re: [Sis-dtn] Telecon Notes 20210224</tt><br>
<br>
<tt>Hi Tomaso,</tt><br>
<br>
<tt>maybe I am just confused but I have some difficulties to understand what this text actually means (in particular, what is meant by all outstanding CP segments?). It also seems dependent on the sender's strategy when to send CPs.</tt><br>
<br>
<tt>Actually, looking at 6.13 I am wondering whether we need this at all. 6.13 allows to cancel a session with RLEXC if the number of transmission problems exceeds an established limit. Maybe this could also cover re-transmission cycle limits?</tt><br>
<br>
<tt>Thinking about this, I believe we need to leave some room for implementation-specific limits which could come in a lot of different flavours (absolute re-transmitted amount of data, relative re-transmitted amount of data, number of queued segments for re-transmission,
....). It just seems strange that for one of these 'implementation-specific' limits we have a specific error code (RXMTCYCEXC).</tt><br>
<br>
<tt>Regards,</tt><br>
<tt>Felix</tt><br>
<br>
<br>
<br>
<tt>From: <<a href="mailto:Tomaso.deCola@dlr.de">Tomaso.deCola@dlr.de</a>></tt><br>
<tt>To: <<a href="mailto:kscott@mitre.org">kscott@mitre.org</a>>, <<a href="mailto:sis-dtn@mailman.ccsds.org">sis-dtn@mailman.ccsds.org</a>>, <<a href="mailto:Felix.Flentge@esa.int">Felix.Flentge@esa.int</a>></tt><br>
<tt>Date: 25/02/2021 14:17</tt><br>
<tt>Subject: RE: Telecon Notes 20210224</tt><br>
<tt>________________________________</tt><br>
<br>
<br>
<br>
<tt>Hi All,</tt><br>
<br>
<br>
<br>
<tt>Concerning the point on the retransmission cycle limit, this is first appearing on RFC 5326 at the end of section 6.2.2 (beginning of page 34) and copied here below for your convenience:</tt><br>
<br>
<br>
<br>
<tt>There may be other implementation-specific limits that may cause an</tt><br>
<br>
<tt> LTP implementation to initiate session-cancellation procedures. One</tt><br>
<br>
<tt> such limit is the maximum number of retransmission-cycles seen. A</tt><br>
<br>
<tt> retransmission cycle at the LTP Sender comprises the two related</tt><br>
<br>
<tt> events: the transmission of all outstanding CP segments from the</tt><br>
<br>
<tt> sender, and the reception of all RS segments issued from the receiver</tt><br>
<br>
<tt> in response to those CP segments. A similar definition would apply</tt><br>
<br>
<tt> at the LTP Receiver but relate to the reception of the CP segments</tt><br>
<br>
<tt> and transmission of all RS segments in response. Note that the</tt><br>
<br>
<tt> retransmitted CP and RS segments remain part of their original</tt><br>
<br>
<tt> retransmission-cycle. Also, a single CP segment may cause multiple</tt><br>
<br>
<tt> RS segments to be generated if a reception report would not fit in a</tt><br>
<br>
<tt> single data link-MTU-sized RS segment; all RS segments that are part</tt><br>
<br>
<tt> of a reception report belong to the same retransmission cycle to</tt><br>
<br>
<tt> which the CP segment belongs. In the presence of severe channel</tt><br>
<br>
<tt> error conditions, many retransmission cycles may elapse before red-</tt><br>
<br>
<tt> part transmission is deemed successful; an implementation may</tt><br>
<br>
<tt> therefore impose a retransmission-cycle limit to shield itself from a</tt><br>
<br>
<tt> resource-crunch situation. If an LTP sender notices the</tt><br>
<br>
<tt> retransmission-cycle limit being exceeded, it SHOULD initiate the</tt><br>
<br>
<tt> Cancel Session procedure (Section 6.19<</tt></span><a href="https://tools.ietf.org/html/rfc5326#section-6.19"><tt><span style="font-size:10.0pt">https://tools.ietf.org/html/rfc5326#section-6.19</span></tt></a><tt><span style="font-size:10.0pt">>), queuing
a CS segment with</span></tt><span style="font-size:10.0pt;font-family:"Courier New""><br>
<br>
<tt> reason-code RXMTCYCEXC and sending a transmission-session</tt><br>
<br>
<tt> cancellation notice (Section 7.5<</tt></span><a href="https://tools.ietf.org/html/rfc5326#section-7.5"><tt><span style="font-size:10.0pt">https://tools.ietf.org/html/rfc5326#section-7.5</span></tt></a><tt><span style="font-size:10.0pt">>) to the client
service.</span></tt><span style="font-size:10.0pt;font-family:"Courier New""><br>
<br>
<br>
<br>
<tt>@Felix.Flentge@esa.int<</tt></span><a href="mailto:Felix.Flentge@esa.int"><tt><span style="font-size:10.0pt">mailto:Felix.Flentge@esa.int</span></tt></a><tt><span style="font-size:10.0pt">>: which aspects did you want to make normative?</span></tt><span style="font-size:10.0pt;font-family:"Courier New""><br>
<tt>Best Regards,</tt><br>
<br>
<tt>Tomaso</tt><br>
<br>
<br>
<br>
<br>
<br>
<tt>From: SIS-DTN <<a href="mailto:sis-dtn-bounces@mailman.ccsds.org">sis-dtn-bounces@mailman.ccsds.org</a>> On Behalf Of Dr. Keith L Scott</tt><br>
<tt>Sent: Mittwoch, 24. Februar 2021 17:52</tt><br>
<tt>To: <a href="mailto:sis-dtn@mailman.ccsds.org">sis-dtn@mailman.ccsds.org</a></tt><br>
<tt>Subject: [Sis-dtn] Telecon Notes 20210224</tt><br>
<br>
<br>
<br>
<tt>SIS-DTN Telecon</tt><br>
<br>
<br>
<br>
<tt>LTP</tt><br>
<br>
<tt>Took some notes in the SharePoint List here:</tt><br>
<br>
</span><a href="https://cwe.ccsds.org/fm/wiki/Lists/SISDTN%20LTP%20Update%202021/AllItems.aspx"><tt><span style="font-size:10.0pt">https://cwe.ccsds.org/fm/wiki/Lists/SISDTN%20LTP%20Update%202021/AllItems.aspx</span></tt></a><span style="font-size:10.0pt;font-family:"Courier New""><br>
<br>
<tt>What testing / experimentation to drive out issues?</tt><br>
<br>
<tt>• LTP Extension Header vs. small Green Blocks to signal adaptive coding and modulation.</tt><br>
<br>
<tt>• ESA looking to use LTP for optical; no experimentation expected for 8-12 months</tt><br>
<br>
<tt>ReTx cycle limit & Discretionary Checkpoints</tt><br>
<br>
<tt>People to come up with draft clarifying language and we’ll review. Consult the RFC5326 text to see if we want to ‘normativeize’ it. Keith to collect text from RFC5326 to provide context.</tt><br>
<br>
<tt>BPv7</tt><br>
<br>
<tt>Keith to build a list of items like the LTP list for discussion at next meeting.</tt><br>
<br>
<tt>BPSec</tt><br>
<br>
<tt>In Security WG processing; we need to notify them of status of BPSec doc in IETF.</tt><br>
<br>
<br>
<br>
<tt>People need to review current draft and we’ll work any proposed changes to the SEA-SEC WG ASAP:</tt><br>
<br>
</span><a href="https://tools.ietf.org/html/draft-ietf-dtn-bpsec-27"><tt><span style="font-size:10.0pt">https://tools.ietf.org/html/draft-ietf-dtn-bpsec-27</span></tt></a><span style="font-size:10.0pt;font-family:"Courier New""><br>
<br>
<br>
<br>
<tt>Default security context from IETF is probably not what we want in CCSDS; we might need to define our own set.</tt><br>
<br>
<br>
<br>
<tt>ESA to start an activity on security.</tt><br>
<br>
<tt>NM Books</tt><br>
<br>
<tt>Links to I-Ds</tt><br>
<br>
<tt>NM books going through IETF, about to become WG documents, changes as a result of reviews may be coming over the next 8-12 months.</tt><br>
<br>
<br>
<br>
<tt>ICPA Need Dates for NM updated to 2028, we can prioritize the other efforts above these.</tt><br>
<br>
<br>
<br>
<br>
</span><o:p></o:p></p>
</div>
</body>
</html>