<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)">
<title>RE: [Sis-dtn] Positive reception claim vs. Negative reception claim in LTP Report Segment preparation and processing</title>
<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;}
@font-face
{font-family:"Malgun Gothic";
panose-1:2 11 5 3 2 0 0 2 0 4;}
@font-face
{font-family:"\@Malgun Gothic";
panose-1:2 11 5 3 2 0 0 2 0 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;}
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.EmailStyle18
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></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">(I cc again the whole SIS-DTN mailinglist that apparently disappeared from my initial message)<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">At first glance I don’t see a space network configuration in which the LTP segments belonging to a given LTP block could arrived misordered. Perhaps if LTP is operated over UDP also in space (the
current spec does not prohibit it to the best of my memory) this could happen but I’d say it is an unlikely configuration.<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>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> Dr. Keith L Scott <kscott@mitre.org>
<br>
<b>Sent:</b> Montag, 4. April 2022 17:43<br>
<b>To:</b> sburleig.sb@gmail.com; Cola, Tomaso de <Tomaso.deCola@dlr.de>; carlo.caini@unibo.it; chkoo@kari.re.kr; dstanton@keltik.co.uk<br>
<b>Subject:</b> Re: [Sis-dtn] [EXT] Re: Positive reception claim vs. Negative reception claim in LTP Report Segment preparation and processing<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span lang="EN-US">But for CCSDS applications (and LTPv2 is a CCSDS thing not an IETF thing) maybe we make the assumption that segments are not misordered? Or that the misordering is ‘small’ so that some sort of timer / couter at the receiver
could filter out small anomalies? (e.g. hold off sending a NACK for 1,000 segments)?<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"> --keith<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:12.0pt;color:black">From:
</span></b><span lang="EN-US" style="font-size:12.0pt;color:black">"<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>Date: </b>Monday, April 4, 2022 at 11:39 AM<br>
<b>To: </b>Tomaso de Cola <<a href="mailto:Tomaso.deCola@dlr.de">Tomaso.deCola@dlr.de</a>>, Keith Scott <<a href="mailto:kscott@mitre.org">kscott@mitre.org</a>>, "<a href="mailto:carlo.caini@unibo.it">carlo.caini@unibo.it</a>" <<a href="mailto:carlo.caini@unibo.it">carlo.caini@unibo.it</a>>,
Cheol Koo <<a href="mailto:chkoo@kari.re.kr">chkoo@kari.re.kr</a>>, Dai Stanton <<a href="mailto:dstanton@keltik.co.uk">dstanton@keltik.co.uk</a>><br>
<b>Subject: </b>RE: [Sis-dtn] [EXT] Re: Positive reception claim vs. Negative reception claim in LTP Report Segment preparation and processing<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<p class="MsoNormal"><span lang="EN-US">Yes, and for good reason: the design of LTP was originally lifted directly from the CFDP Acknowledged Procedures (and thereupon tweaked a bit). I think the argument against proactively reporting negative DS reception
claims was that the missing segments might be already en route but slightly delayed due to transmission over a longer path. In space flight communications this won’t happen because LTP will be running directly over the link; when we test LTP on Earth it is
somewhat more likely, as LTP is running directly over UDP/IP and in theory those packets might travel over multiple different routes.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Scott <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> <a href="mailto:Tomaso.deCola@dlr.de">
Tomaso.deCola@dlr.de</a> <<a href="mailto:Tomaso.deCola@dlr.de">Tomaso.deCola@dlr.de</a>>
<br>
<b>Sent:</b> Monday, April 4, 2022 8:31 AM<br>
<b>To:</b> <a href="mailto:kscott@mitre.org">kscott@mitre.org</a>; <a href="mailto:sburleig.sb@gmail.com">
sburleig.sb@gmail.com</a>; <a href="mailto:carlo.caini@unibo.it">carlo.caini@unibo.it</a>;
<a href="mailto:chkoo@kari.re.kr">chkoo@kari.re.kr</a>; <a href="mailto:dstanton@keltik.co.uk">
dstanton@keltik.co.uk</a><br>
<b>Subject:</b> RE: [Sis-dtn] [EXT] Re: Positive reception claim vs. Negative reception claim in LTP Report Segment preparation and processing<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal">This looks similar to CFDP-class 2 with retransmission happening in asynchronous mode, isn’t it?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Regards,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Tomaso<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 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> SIS-DTN <<a href="mailto:sis-dtn-bounces@mailman.ccsds.org">sis-dtn-bounces@mailman.ccsds.org</a>>
<b>On Behalf Of </b>Dr. Keith L Scott via SIS-DTN<br>
<b>Sent:</b> Montag, 4. April 2022 17:28<br>
<b>To:</b> <a href="mailto:sburleig.sb@gmail.com">sburleig.sb@gmail.com</a>; 'Carlo Caini' <<a href="mailto:carlo.caini@unibo.it">carlo.caini@unibo.it</a>>; '"</span><span style="font-family:"Malgun Gothic",sans-serif">구철회</span><span lang="EN-US">"' <<a href="mailto:chkoo@kari.re.kr">chkoo@kari.re.kr</a>>;
'Keltik' <<a href="mailto:dstanton@keltik.co.uk">dstanton@keltik.co.uk</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] [EXT] Re: Positive reception claim vs. Negative reception claim in LTP Report Segment preparation and processing<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span lang="EN-US">I think maybe a larger opportunity for improvement would be to have a capability for a receiver to proactively NACK segments WITHOUT having to receive a checkpoint first. That would allow autonomously sending NACKs during
the block transmission (thereby filling holes quickly as they are detected) and then relying on the CP/RS/RA exchange to close out the session.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"> --keith<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:12.0pt;color:black">From:
</span></b><span lang="EN-US" style="font-size:12.0pt;color:black">"<a href="mailto:sis-dtn-bounces@mailman.ccsds.org">sis-dtn-bounces@mailman.ccsds.org</a>" <<a href="mailto:sis-dtn-bounces@mailman.ccsds.org">sis-dtn-bounces@mailman.ccsds.org</a>> on behalf
of "<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>><br>
<b>Reply-To: </b>"<a href="mailto:sburleig.sb@gmail.com">sburleig.sb@gmail.com</a>" <<a href="mailto:sburleig.sb@gmail.com">sburleig.sb@gmail.com</a>><br>
<b>Date: </b>Monday, April 4, 2022 at 11:21 AM<br>
<b>To: </b>'Carlo Caini' <<a href="mailto:carlo.caini@unibo.it">carlo.caini@unibo.it</a>>, Cheol Koo <<a href="mailto:chkoo@kari.re.kr">chkoo@kari.re.kr</a>>, Dai Stanton <<a href="mailto:dstanton@keltik.co.uk">dstanton@keltik.co.uk</a>><br>
<b>Cc: </b>"<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>><br>
<b>Subject: </b>[EXT] Re: [Sis-dtn] Positive reception claim vs. Negative reception claim in LTP Report Segment preparation and processing<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<p><span lang="EN-US">Hi, guys. I believe we are actually talking about two distinct things here.<o:p></o:p></span></p>
<p><span lang="EN-US">It is true that positive ACKs are required. Positive acknowledgments turn off the retransmission timers for checkpoints, report segments, and cancellation segments.<o:p></o:p></span></p>
<p><span lang="EN-US">Separately, the individual "claims" within a report segment might be either positive or negative. I agree with Carlo, but think Cheol is correct that negative claims can yield a small overhead advantage. For any LTP transmission whose
scope is from block offset P to Q in which there are N gaps:<o:p></o:p></span></p>
<p><span lang="EN-US" style="font-family:Symbol">·</span><span lang="EN-US" style="font-family:"Courier New""> </span><span lang="EN-US"> If one of the gaps begins at P and another of the gaps ends at Q, then the report must contain either N negative claims
or N - 1 positive claims.<o:p></o:p></span></p>
<p><span lang="EN-US" style="font-family:Symbol">·</span><span lang="EN-US" style="font-family:"Courier New""> </span><span lang="EN-US"> If no gap begins at P and no gap ends at Q, then the report must contain either N negative claims or N + 1 positive
claims.<o:p></o:p></span></p>
<p><span lang="EN-US" style="font-family:Symbol">·</span><span lang="EN-US" style="font-family:"Courier New""> </span><span lang="EN-US"> If one of the gaps begins at P or one of the gaps ends at Q, but not both, then the report must contain either N negative
claims or N positive claims.<o:p></o:p></span></p>
<p><span lang="EN-US">I would expect the second of these cases to occur more frequently than the other two, assuming AOS/LOS events don't occur during the transmission.<o:p></o:p></span></p>
<p><span lang="EN-US">I don't see how either negative or positive claims processing is simpler or easier, though; the representations are equivalent. Ease of implementation would depend strictly on the manner in which segment information is stored and accessed
at the sending and receiving ends of the transmission. I personally found positive claims to be simpler to work with.<o:p></o:p></span></p>
<p><span lang="EN-US">Scott<o:p></o:p></span></p>
<p><span lang="EN-US">-----Original Message-----<br>
From: SIS-DTN <<a href="mailto:sis-dtn-bounces@mailman.ccsds.org">sis-dtn-bounces@mailman.ccsds.org</a>> On Behalf Of Carlo Caini via SIS-DTN<br>
Sent: Monday, April 4, 2022 5:47 AM<br>
To: "</span><span style="font-family:"Malgun Gothic",sans-serif">구철회</span><span lang="EN-US">" <<a href="mailto:chkoo@kari.re.kr">chkoo@kari.re.kr</a>>; Keltik <<a href="mailto:dstanton@keltik.co.uk">dstanton@keltik.co.uk</a>><br>
Cc: <a href="mailto:sis-dtn@mailman.ccsds.org">sis-dtn@mailman.ccsds.org</a><br>
Subject: Re: [Sis-dtn] Positive reception claim vs. Negative reception claim in LTP Report Segment preparation and processing<o:p></o:p></span></p>
<p><span lang="EN-US">Dear Cheol,<o:p></o:p></span></p>
<p><span lang="EN-US"> let me consider an LTP block with for example 20 non contigous losses, i.e. 20 gaps. The corresponding RS would include either 20 positive claims (if you have a gap at the start or at the end of the block) or 21 cl;aims otherwise.<o:p></o:p></span></p>
<p><span lang="EN-US">With NAK claim you would need 20 megative claims. Is that so different?<o:p></o:p></span></p>
<p><span lang="EN-US">You can say that it is easier to resend what has been explicietely said is missing, true; however, on the rx side it is easier to say what has been received than what is missing; all things considered, I cannot see any signifiocant advantage
by excplicietely declaring gaps instead of received chunks.<o:p></o:p></span></p>
<p><span lang="EN-US">Yours,<o:p></o:p></span></p>
<p><span lang="EN-US"> Carlo<o:p></o:p></span></p>
<p><span lang="EN-US">________________________________________<o:p></o:p></span></p>
<p><span lang="EN-US">Da: SIS-DTN [sis-dtn-bounces@mailman.ccsds.org] per conto di "</span><span style="font-family:"Malgun Gothic",sans-serif">구철회</span><span lang="EN-US">" via SIS-DTN [sis-dtn@mailman.ccsds.org]<o:p></o:p></span></p>
<p><span lang="EN-US">Inviato: lunedì 4 aprile 2022 14:20<o:p></o:p></span></p>
<p><span lang="EN-US">A: Keltik<o:p></o:p></span></p>
<p><span lang="EN-US">Cc: <a href="mailto:sis-dtn@mailman.ccsds.org">sis-dtn@mailman.ccsds.org</a><o:p></o:p></span></p>
<p><span lang="EN-US">Oggetto: Re: [Sis-dtn] Positive reception claim vs. Negative reception claim in LTP Report Segment preparation and processing<o:p></o:p></span></p>
<p><span lang="EN-US">I think current LTP spec has positive ACK and negative ACK both. So if it is reversed the result will be the same.<o:p></o:p></span></p>
<p><span lang="EN-US">Let me bring below example again. To provide claim inforamtion for retransmission of block 1000-2999,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p><span lang="EN-US"><<original-positive ACK>><o:p></o:p></span></p>
<p><span lang="EN-US">lower bound = 0<o:p></o:p></span></p>
<p><span lang="EN-US">upper bound = 7000<o:p></o:p></span></p>
<p><span lang="EN-US">negative reception claim count = 2<o:p></o:p></span></p>
<p><span lang="EN-US">offset = 0 <-- Positive ACK<o:p></o:p></span></p>
<p><span lang="EN-US">length = 1000 <-- Positive ACK<o:p></o:p></span></p>
<p><span lang="EN-US">offset = 3000 <-- Positive ACK<o:p></o:p></span></p>
<p><span lang="EN-US">length = 4000 <-- Positive ACK<o:p></o:p></span></p>
<p><span lang="EN-US">* Negative ACKs are hidden in separated Positive ACKs.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p><span lang="EN-US"><<negative ACK>><o:p></o:p></span></p>
<p><span lang="EN-US">lower bound = 0 <-- Positive ACK<o:p></o:p></span></p>
<p><span lang="EN-US">upper bound = 7000 <-- Positive ACK<o:p></o:p></span></p>
<p><span lang="EN-US">negative reception claim count = 1<o:p></o:p></span></p>
<p><span lang="EN-US">offset = 1000 <-- Negative ACK<o:p></o:p></span></p>
<p><span lang="EN-US">length = 2000 <-- Negative ACK<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p><span lang="EN-US">I think the latter case can work too! Or am I missing something?<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p><span lang="EN-US">Cheol<o:p></o:p></span></p>
<p><span lang="EN-US">--------- </span><span style="font-family:"Malgun Gothic",sans-serif">원본</span>
<span style="font-family:"Malgun Gothic",sans-serif">메일</span><span lang="EN-US"> ---------<o:p></o:p></span></p>
<p><span style="font-family:"Malgun Gothic",sans-serif">보낸사람</span><span lang="EN-US"> : Keltik <<a href="mailto:dstanton@keltik.co.uk">dstanton@keltik.co.uk</a>><o:p></o:p></span></p>
<p><span style="font-family:"Malgun Gothic",sans-serif">받는사람</span><span lang="EN-US"> : Vint Cerf <<a href="mailto:vint@google.com">vint@google.com</a>><o:p></o:p></span></p>
<p><span style="font-family:"Malgun Gothic",sans-serif">참조</span><span lang="EN-US"> : <<a href="mailto:Felix.Flentge@esa.int">Felix.Flentge@esa.int</a>>, <<a href="mailto:sis-dtn@mailman.ccsds.org">sis-dtn@mailman.ccsds.org</a>>, "</span><span style="font-family:"Malgun Gothic",sans-serif">구철회</span><span lang="EN-US">"
<<a href="mailto:chkoo@kari.re.kr">chkoo@kari.re.kr</a>> </span><span style="font-family:"Malgun Gothic",sans-serif">받은날짜</span><span lang="EN-US"> : 2022-04-04 (</span><span style="font-family:"Malgun Gothic",sans-serif">월</span><span lang="EN-US">) 19:53:46
</span><span style="font-family:"Malgun Gothic",sans-serif">제목</span><span lang="EN-US"> : Re: [Sis-dtn] Positive reception claim vs. Negative reception claim in LTP Report Segment preparation and processing Scott Burleigh and I went through this developing
CFDP/LTP three decades ago. Whilst Negative ACKs can be very efficient for bulk data in the delay/disruption environment, protocol directives such as initiation, metadata exchange, end of data, end of transaction, pause, resume etc require positive ACKs. Otherwise
the state machines will never close.<o:p></o:p></span></p>
<p><span lang="EN-US">Dai<o:p></o:p></span></p>
<p><span lang="EN-US">Sent from my iPhone<o:p></o:p></span></p>
<p><span lang="EN-US">On 4 Apr 2022, at 11:09, Vint Cerf via SIS-DTN <<a href="mailto:sis-dtn@mailman.ccsds.org">sis-dtn@mailman.ccsds.org</a>> wrote:<o:p></o:p></span></p>
<p><span lang="EN-US">a system based solely on negative acks will not work.<o:p></o:p></span></p>
<p><span lang="EN-US">v<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p><span lang="EN-US">On Mon, Apr 4, 2022 at 6:08 AM Felix Flentge via SIS-DTN <<a href="mailto:sis-dtn@mailman.ccsds.org%3cmailto:sis-dtn@mailman.ccsds.org">sis-dtn@mailman.ccsds.org<mailto:sis-dtn@mailman.ccsds.org</a>>> wrote:<o:p></o:p></span></p>
<p><span lang="EN-US">Ah, yes, of course you are right.<o:p></o:p></span></p>
<p><span lang="EN-US">We will look into the negative ACK as part of our LTPv2 prototyping activity.<o:p></o:p></span></p>
<p><span lang="EN-US">Regards,<o:p></o:p></span></p>
<p><span lang="EN-US">Felix<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p><span lang="EN-US">From: "</span><span style="font-family:"Malgun Gothic",sans-serif">구철회</span><span lang="EN-US">" <<a href="mailto:chkoo@kari.re.kr%3cmailto:chkoo@kari.re.kr">chkoo@kari.re.kr<mailto:chkoo@kari.re.kr</a>>><o:p></o:p></span></p>
<p><span lang="EN-US">To: <<a href="mailto:Felix.Flentge@esa.int%3cmailto:Felix.Flentge@esa.int">Felix.Flentge@esa.int<mailto:Felix.Flentge@esa.int</a>>><o:p></o:p></span></p>
<p><span lang="EN-US">Cc: "<a href="mailto:sis-dtn@mailman.ccsds.org%3cmailto:sis-dtn@mailman.ccsds.org%3e">sis-dtn@mailman.ccsds.org<mailto:sis-dtn@mailman.ccsds.org></a>" <<a href="mailto:sis-dtn@mailman.ccsds.org%3cmailto:sis-dtn@mailman.ccsds.org">sis-dtn@mailman.ccsds.org<mailto:sis-dtn@mailman.ccsds.org</a>>><o:p></o:p></span></p>
<p><span lang="EN-US">Date: 04/04/2022 11:58<o:p></o:p></span></p>
<p><span lang="EN-US">Subject: RE: Re: [Sis-dtn] Positive reception claim vs. Negative reception claim in LTP Report Segment preparation and processing<o:p></o:p></span></p>
<p><span lang="EN-US">Sent by: <a href="mailto:chkoo@kari.re.kr%3cmailto:chkoo@kari.re.kr">
chkoo@kari.re.kr<mailto:chkoo@kari.re.kr</a>><o:p></o:p></span></p>
<p><span lang="EN-US">________________________________<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p><span lang="EN-US">Hi Felix,<o:p></o:p></span></p>
<p><span lang="EN-US">I think current LTP spec quite works well with negative claim also. Consider below reception claim according to the LTP spec but negative claim.<o:p></o:p></span></p>
<p><span lang="EN-US">lower bound = 0<o:p></o:p></span></p>
<p><span lang="EN-US">upper bound = 7000<o:p></o:p></span></p>
<p><span lang="EN-US">negative reception claim count = 1<o:p></o:p></span></p>
<p><span lang="EN-US">offset = 1000<o:p></o:p></span></p>
<p><span lang="EN-US">length = 2000<o:p></o:p></span></p>
<p><span lang="EN-US">it means a receiver is requesting block of segements which starts at 1000 and length is 2000, i.e., 1000 ~ 2999, for retransmission.<o:p></o:p></span></p>
<p><span lang="EN-US">A sender can safely remove 2 blocks, i.e., 0 - 999 and 3000 - 7000. I think it is simpler, lower overhead and *importantly* easier to calculate (acutally no painful for localizing the target segment position).<o:p></o:p></span></p>
<p><span lang="EN-US">Cheol<o:p></o:p></span></p>
<p><span lang="EN-US">--------- </span><span style="font-family:"Malgun Gothic",sans-serif">원본</span>
<span style="font-family:"Malgun Gothic",sans-serif">메일</span><span lang="EN-US"> ---------<o:p></o:p></span></p>
<p><span style="font-family:"Malgun Gothic",sans-serif">보낸사람</span><span lang="EN-US"> : <<a href="mailto:Felix.Flentge@esa.int%3cmailto:Felix.Flentge@esa.int">Felix.Flentge@esa.int<mailto:Felix.Flentge@esa.int</a>>><o:p></o:p></span></p>
<p><span style="font-family:"Malgun Gothic",sans-serif">받는사람</span><span lang="EN-US"> : "</span><span style="font-family:"Malgun Gothic",sans-serif">구철회</span><span lang="EN-US">" <<a href="mailto:chkoo@kari.re.kr%3cmailto:chkoo@kari.re.kr">chkoo@kari.re.kr<mailto:chkoo@kari.re.kr</a>>><o:p></o:p></span></p>
<p><span style="font-family:"Malgun Gothic",sans-serif">참조</span><span lang="EN-US"> : "<a href="mailto:sis-dtn@mailman.ccsds.org%3cmailto:sis-dtn@mailman.ccsds.org%3e">sis-dtn@mailman.ccsds.org<mailto:sis-dtn@mailman.ccsds.org></a>" <<a href="mailto:sis-dtn@mailman.ccsds.org%3cmailto:sis-dtn@mailman.ccsds.org">sis-dtn@mailman.ccsds.org<mailto:sis-dtn@mailman.ccsds.org</a>>><o:p></o:p></span></p>
<p><span style="font-family:"Malgun Gothic",sans-serif">받은날짜</span><span lang="EN-US"> : 2022-04-04 (</span><span style="font-family:"Malgun Gothic",sans-serif">월</span><span lang="EN-US">) 17:40:24<o:p></o:p></span></p>
<p><span style="font-family:"Malgun Gothic",sans-serif">제목</span><span lang="EN-US"> : Re: [Sis-dtn] Positive reception claim vs. Negative reception claim in LTP Report Segment preparation and processing Hi Cheol,<o:p></o:p></span></p>
<p><span lang="EN-US">interesting question. One thing I can think of is that the positive claims would allow you to free memory earlier while for negative claims you need to wait until the end of a session.<o:p></o:p></span></p>
<p><span lang="EN-US">Regards,<o:p></o:p></span></p>
<p><span lang="EN-US">Felix<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p><span lang="EN-US">From: "</span><span style="font-family:"Malgun Gothic",sans-serif">구철회</span><span lang="EN-US"> via SIS-DTN" <<a href="mailto:sis-dtn@mailman.ccsds.org%3cmailto:sis-dtn@mailman.ccsds.org">sis-dtn@mailman.ccsds.org<mailto:sis-dtn@mailman.ccsds.org</a>>><o:p></o:p></span></p>
<p><span lang="EN-US">To: "<a href="mailto:sis-dtn@mailman.ccsds.org%3cmailto:sis-dtn@mailman.ccsds.org%3e">sis-dtn@mailman.ccsds.org<mailto:sis-dtn@mailman.ccsds.org></a>" <<a href="mailto:sis-dtn@mailman.ccsds.org%3cmailto:sis-dtn@mailman.ccsds.org">sis-dtn@mailman.ccsds.org<mailto:sis-dtn@mailman.ccsds.org</a>>><o:p></o:p></span></p>
<p><span lang="EN-US">Date: 04/04/2022 10:15<o:p></o:p></span></p>
<p><span lang="EN-US">Subject: [Sis-dtn] Positive reception claim vs. Negative reception claim in LTP Report Segment preparation and processing<o:p></o:p></span></p>
<p><span lang="EN-US">Sent by: "SIS-DTN" <<a href="mailto:sis-dtn-bounces@mailman.ccsds.org%3cmailto:sis-dtn-bounces@mailman.ccsds.org">sis-dtn-bounces@mailman.ccsds.org<mailto:sis-dtn-bounces@mailman.ccsds.org</a>>><o:p></o:p></span></p>
<p><span lang="EN-US">________________________________<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p><span lang="EN-US">Greetings,<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p><span lang="EN-US">This is Cheol. I am developing an LTP reference implementation. During reading the LTP specification (RFC-5326), the preparation of reception claim in Report Segment makes me confusing about why it is positive claim not negative claim
for segments that were not received successfully (i.e., NAK).<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p><span lang="EN-US">For reference, CFDP’s NAK PDU has the negative claim structure when it is requested to report missing PDUs. Does anyone know about the background of choosing the positive claim for NAK operation in LTP?<o:p></o:p></span></p>
<p><span lang="EN-US">I think negative claim is simpler and more efficient in terms of overhead for sender and receiver both.<o:p></o:p></span></p>
<p><span lang="EN-US">I like to listen experts’ opinion on LTP operation and honestly hope it to be changed in newly coming LTP spec.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p><span lang="EN-US">Cheol<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p><span lang="EN-US">_______________________________________________<o:p></o:p></span></p>
<p><span lang="EN-US">SIS-DTN mailing list<o:p></o:p></span></p>
<p><span lang="EN-US"><a href="mailto:SIS-DTN@mailman.ccsds.org%3cmailto:SIS-DTN@mailman.ccsds.org">SIS-DTN@mailman.ccsds.org<mailto:SIS-DTN@mailman.ccsds.org</a>><o:p></o:p></span></p>
<p><span lang="EN-US"><a href="https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn%3chttps:/protect2.fireeye.com/v1/url?k=933edf14-cca5b51c-933bae9a-ac1f6bdccbcc-93bc8ad36316533d&q=1&e=24a03daf-8e73-4317-a689-3216c529ea83&u=https%3A%2F%2Fmailman.ccsds.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fsis-dtn">https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn<https://protect2.fireeye.com/v1/url?k=933edf14-cca5b51c-933bae9a-ac1f6bdccbcc-93bc8ad36316533d&q=1&e=24a03daf-8e73-4317-a689-3216c529ea83&u=https%3A%2F%2Fmailman.ccsds.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fsis-dtn</a>><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p><span lang="EN-US">_______________________________________________<o:p></o:p></span></p>
<p><span lang="EN-US">SIS-DTN mailing list<o:p></o:p></span></p>
<p><span lang="EN-US"><a href="mailto:SIS-DTN@mailman.ccsds.org%3cmailto:SIS-DTN@mailman.ccsds.org">SIS-DTN@mailman.ccsds.org<mailto:SIS-DTN@mailman.ccsds.org</a>><o:p></o:p></span></p>
<p><span lang="EN-US"><a href="https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn%3chttps:/protect2.fireeye.com/v1/url?k=60e1ef17-3f7a851f-60e49e99-ac1f6bdccbcc-0dfe5136ab6b73dc&q=1&e=cce8b1e1-1ec2-4cdd-855b-994c9a3f58c9&u=https%3A%2F%2Fmailman.ccsds.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fsis-dtn">https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn<https://protect2.fireeye.com/v1/url?k=60e1ef17-3f7a851f-60e49e99-ac1f6bdccbcc-0dfe5136ab6b73dc&q=1&e=cce8b1e1-1ec2-4cdd-855b-994c9a3f58c9&u=https%3A%2F%2Fmailman.ccsds.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fsis-dtn</a>><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p><span lang="EN-US">--<o:p></o:p></span></p>
<p><span lang="EN-US">Please send any postal/overnight deliveries to:<o:p></o:p></span></p>
<p><span lang="EN-US">Vint Cerf<o:p></o:p></span></p>
<p><span lang="EN-US">1435 Woodhurst Blvd<o:p></o:p></span></p>
<p><span lang="EN-US">McLean, VA 22102<o:p></o:p></span></p>
<p><span lang="EN-US">703-448-0965<o:p></o:p></span></p>
<p><span lang="EN-US">until further notice<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p><span lang="EN-US">_______________________________________________<o:p></o:p></span></p>
<p><span lang="EN-US">SIS-DTN mailing list<o:p></o:p></span></p>
<p><span lang="EN-US"><a href="mailto:SIS-DTN@mailman.ccsds.org">SIS-DTN@mailman.ccsds.org</a><o:p></o:p></span></p>
<p><span lang="EN-US"><a href="https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn%3chttps:/protect2.fireeye.com/v1/url?k=9ac1f10e-c55a9b06-9ac48080-ac1f6bdccbcc-60db088d278d85f7&q=1&e=cce8b1e1-1ec2-4cdd-855b-994c9a3f58c9&u=https%3A%2F%2Fmailman.ccsds.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fsis-dtn">https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn<https://protect2.fireeye.com/v1/url?k=9ac1f10e-c55a9b06-9ac48080-ac1f6bdccbcc-60db088d278d85f7&q=1&e=cce8b1e1-1ec2-4cdd-855b-994c9a3f58c9&u=https%3A%2F%2Fmailman.ccsds.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fsis-dtn</a>><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p><span lang="EN-US">_______________________________________________<o:p></o:p></span></p>
<p><span lang="EN-US">SIS-DTN mailing list<o:p></o:p></span></p>
<p><span lang="EN-US"><a href="mailto:SIS-DTN@mailman.ccsds.org">SIS-DTN@mailman.ccsds.org</a><o:p></o:p></span></p>
<p><span lang="EN-US"><a href="https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn">https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn</a><o:p></o:p></span></p>
</div>
</body>
</html>