<html 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:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"Malgun Gothic";
panose-1:2 11 5 3 2 0 0 2 0 4;}
@font-face
{font-family:"\@Malgun Gothic";}
/* Style Definitions */
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Plain Text Char";
margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:"Calibri",sans-serif;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:221910549;
mso-list-type:hybrid;
mso-list-template-ids:-1041974462 67698689 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:;
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:;
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:;
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:;
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:;
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:;
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>
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoPlainText">I think the 'win' would be (comparing a system that generated proactive NACKs vs. a system that generated a CP only at the end of the block):<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">If there are 10,000 LTP segments and the 3rd segment is lost:<o:p></o:p></p>
<ul style="margin-top:0in" type="disc">
<li class="MsoPlainText" style="mso-list:l0 level1 lfo1">The NACK system will nack it “immediately” and elicit a retransmission. Increased latency: about 1 segment.<o:p></o:p></li><li class="MsoPlainText" style="mso-list:l0 level1 lfo1">The non-NACK (call it CP-only) system will send the whole block and then a CP, which will elicit a RS and cause the hole to be filled. Adds 1 RTT (and 1 retransmitted segment) to the block.<o:p></o:p></li></ul>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">So the NACK system can save an RTT. If the loss rate is small (say, the probability of filling all holes in one CP/RS/ReTX event is high) then that’s really all it saves, regardless of the number of losses in the block. If the loss
rate is high enough that the expected number of CP/RS/ReTX cycles is higher, the benefit is greater).<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">So in general if there are N segments and p(segment loss) is p, the number of retransmission rounds should be about -log(N)/log(p) + 1<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText" style="margin-left:.5in">N = 10,000<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:.5in">P = 0.1<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:.5in"># rounds: 5<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoPlainText" style="margin-left:.5in">N = 10,000<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:.5in">P = 0.01<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:.5in"># rounds: 3<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">So a proactive-NACK implementation could potentially save about 5 RTTs over a CP-only implementation (sort of a blatent assumption that none of the losses are ‘too close’ to the end, but hey).<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> v/r,<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> --keith<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">On 4/4/22, 1:57 PM, "Carlo Caini" <carlo.caini@unibo.it> wrote:<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> Dear all,<o:p></o:p></p>
<p class="MsoPlainText"> on terrestrial applications LTP segment may arrive out of order, thus NACK could result in unecessary retranmissions; maybe this is not a problem as it is the same in TCP (fast retransmit cannot tolerate more than a disorder of
3 TCP segments).<o:p></o:p></p>
<p class="MsoPlainText"> In space, maybe we can assume ordered delivery of LTP segment, thus is true that the LTP receiver could immediately send a NACK as soon as a gap is found (i.e. at the first non contigous claim rfeceived), instead of waiting for the
CP, thus saving some time; however, the advantage is limited. If we call radiation time the time necessary to tranmit "on air" a block, we could say that the NACK time gain should be on the evarage of about a half of the radiatrion time. This saved time should
however be compared with the RTT, wich is the minimum time necessary for loss recovery. RTT in space is usually >> radiation time, thus the advantage would be negligible. Maybe it could be useful on LEO, where the RTT is small, but we should also have large
blocks and slow links...<o:p></o:p></p>
<p class="MsoPlainText"> Yours,<o:p></o:p></p>
<p class="MsoPlainText"> Carlo<o:p></o:p></p>
<p class="MsoPlainText"> ________________________________________<o:p></o:p></p>
<p class="MsoPlainText"> Da: Tomaso.deCola@dlr.de [Tomaso.deCola@dlr.de]<o:p></o:p></p>
<p class="MsoPlainText"> Inviato: lunedì 4 aprile 2022 17:54<o:p></o:p></p>
<p class="MsoPlainText"> A: kscott@mitre.org; sburleig.sb@gmail.com; Carlo Caini; chkoo@kari.re.kr; dstanton@keltik.co.uk<o:p></o:p></p>
<p class="MsoPlainText"> Cc: sis-dtn@mailman.ccsds.org<o:p></o:p></p>
<p class="MsoPlainText"> Oggetto: RE: [Sis-dtn] [EXT] Re: Positive reception claim vs. Negative reception claim in LTP Report Segment preparation and processing<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> (I cc again the whole SIS-DTN mailinglist that apparently disappeared from my initial message)<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> 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></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> Tomaso<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> From: Dr. Keith L Scott <kscott@mitre.org><o:p></o:p></p>
<p class="MsoPlainText"> Sent: Montag, 4. April 2022 17:43<o:p></o:p></p>
<p class="MsoPlainText"> To: sburleig.sb@gmail.com; Cola, Tomaso de <Tomaso.deCola@dlr.de>; carlo.caini@unibo.it; chkoo@kari.re.kr; dstanton@keltik.co.uk<o:p></o:p></p>
<p class="MsoPlainText"> Subject: Re: [Sis-dtn] [EXT] Re: Positive reception claim vs. Negative reception claim in LTP Report Segment preparation and processing<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> 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></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> --keith<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> From: "sburleig.sb@gmail.com<mailto:sburleig.sb@gmail.com>" <sburleig.sb@gmail.com<mailto:sburleig.sb@gmail.com>><o:p></o:p></p>
<p class="MsoPlainText"> Date: Monday, April 4, 2022 at 11:39 AM<o:p></o:p></p>
<p class="MsoPlainText"> To: Tomaso de Cola <Tomaso.deCola@dlr.de<mailto:Tomaso.deCola@dlr.de>>, Keith Scott <kscott@mitre.org<mailto:kscott@mitre.org>>, "carlo.caini@unibo.it<mailto:carlo.caini@unibo.it>" <carlo.caini@unibo.it<mailto:carlo.caini@unibo.it>>,
Cheol Koo <chkoo@kari.re.kr<mailto:chkoo@kari.re.kr>>, Dai Stanton <dstanton@keltik.co.uk<mailto:dstanton@keltik.co.uk>><o:p></o:p></p>
<p class="MsoPlainText"> Subject: RE: [Sis-dtn] [EXT] Re: Positive reception claim vs. Negative reception claim in LTP Report Segment preparation and processing<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> 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></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> Scott<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> From: Tomaso.deCola@dlr.de<mailto:Tomaso.deCola@dlr.de> <Tomaso.deCola@dlr.de<mailto:Tomaso.deCola@dlr.de>><o:p></o:p></p>
<p class="MsoPlainText"> Sent: Monday, April 4, 2022 8:31 AM<o:p></o:p></p>
<p class="MsoPlainText"> To: kscott@mitre.org<mailto:kscott@mitre.org>; sburleig.sb@gmail.com<mailto:sburleig.sb@gmail.com>; carlo.caini@unibo.it<mailto:carlo.caini@unibo.it>; chkoo@kari.re.kr<mailto:chkoo@kari.re.kr>; dstanton@keltik.co.uk<mailto:dstanton@keltik.co.uk><o:p></o:p></p>
<p class="MsoPlainText"> Subject: RE: [Sis-dtn] [EXT] Re: Positive reception claim vs. Negative reception claim in LTP Report Segment preparation and processing<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> This looks similar to CFDP-class 2 with retransmission happening in asynchronous mode, isn’t it?<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> Regards,<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> Tomaso<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> From: SIS-DTN <sis-dtn-bounces@mailman.ccsds.org<mailto:sis-dtn-bounces@mailman.ccsds.org>> On Behalf Of Dr. Keith L Scott via SIS-DTN<o:p></o:p></p>
<p class="MsoPlainText"> Sent: Montag, 4. April 2022 17:28<o:p></o:p></p>
<p class="MsoPlainText"> To: sburleig.sb@gmail.com<mailto:sburleig.sb@gmail.com>; 'Carlo Caini' <carlo.caini@unibo.it<mailto:carlo.caini@unibo.it>>; '"<span style="font-family:"Malgun Gothic",sans-serif">구철회</span>"' <chkoo@kari.re.kr<mailto:chkoo@kari.re.kr>>;
'Keltik' <dstanton@keltik.co.uk<mailto:dstanton@keltik.co.uk>><o:p></o:p></p>
<p class="MsoPlainText"> Cc: sis-dtn@mailman.ccsds.org<mailto:sis-dtn@mailman.ccsds.org><o:p></o:p></p>
<p class="MsoPlainText"> Subject: Re: [Sis-dtn] [EXT] Re: Positive reception claim vs. Negative reception claim in LTP Report Segment preparation and processing<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> 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></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> --keith<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> From: "sis-dtn-bounces@mailman.ccsds.org<mailto:sis-dtn-bounces@mailman.ccsds.org>" <sis-dtn-bounces@mailman.ccsds.org<mailto:sis-dtn-bounces@mailman.ccsds.org>> on behalf of "sis-dtn@mailman.ccsds.org<mailto:sis-dtn@mailman.ccsds.org>"
<sis-dtn@mailman.ccsds.org<mailto:sis-dtn@mailman.ccsds.org>><o:p></o:p></p>
<p class="MsoPlainText"> Reply-To: "sburleig.sb@gmail.com<mailto:sburleig.sb@gmail.com>" <sburleig.sb@gmail.com<mailto:sburleig.sb@gmail.com>><o:p></o:p></p>
<p class="MsoPlainText"> Date: Monday, April 4, 2022 at 11:21 AM<o:p></o:p></p>
<p class="MsoPlainText"> To: 'Carlo Caini' <carlo.caini@unibo.it<mailto:carlo.caini@unibo.it>>, Cheol Koo <chkoo@kari.re.kr<mailto:chkoo@kari.re.kr>>, Dai Stanton <dstanton@keltik.co.uk<mailto:dstanton@keltik.co.uk>><o:p></o:p></p>
<p class="MsoPlainText"> Cc: "sis-dtn@mailman.ccsds.org<mailto:sis-dtn@mailman.ccsds.org>" <sis-dtn@mailman.ccsds.org<mailto:sis-dtn@mailman.ccsds.org>><o:p></o:p></p>
<p class="MsoPlainText"> Subject: [EXT] Re: [Sis-dtn] Positive reception claim vs. Negative reception claim in LTP Report Segment preparation and processing<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> Hi, guys. I believe we are actually talking about two distinct things here.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> 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></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> 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></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> • 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></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> • 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></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> • 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></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> 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></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> 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></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> Scott<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> -----Original Message-----<o:p></o:p></p>
<p class="MsoPlainText"> From: SIS-DTN <sis-dtn-bounces@mailman.ccsds.org<mailto:sis-dtn-bounces@mailman.ccsds.org>> On Behalf Of Carlo Caini via SIS-DTN<o:p></o:p></p>
<p class="MsoPlainText"> Sent: Monday, April 4, 2022 5:47 AM<o:p></o:p></p>
<p class="MsoPlainText"> To: "<span style="font-family:"Malgun Gothic",sans-serif">구철회</span>" <chkoo@kari.re.kr<mailto:chkoo@kari.re.kr>>; Keltik <dstanton@keltik.co.uk<mailto:dstanton@keltik.co.uk>><o:p></o:p></p>
<p class="MsoPlainText"> Cc: sis-dtn@mailman.ccsds.org<mailto:sis-dtn@mailman.ccsds.org><o:p></o:p></p>
<p class="MsoPlainText"> Subject: Re: [Sis-dtn] Positive reception claim vs. Negative reception claim in LTP Report Segment preparation and processing<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> Dear Cheol,<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> 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></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> With NAK claim you would need 20 megative claims. Is that so different?<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> 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></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> Yours,<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> Carlo<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> ________________________________________<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> Da: SIS-DTN [sis-dtn-bounces@mailman.ccsds.org] per conto di "<span style="font-family:"Malgun Gothic",sans-serif">구철회</span>" via SIS-DTN [sis-dtn@mailman.ccsds.org]<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> Inviato: lunedì 4 aprile 2022 14:20<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> A: Keltik<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> Cc: sis-dtn@mailman.ccsds.org<mailto:sis-dtn@mailman.ccsds.org><o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> Oggetto: Re: [Sis-dtn] Positive reception claim vs. Negative reception claim in LTP Report Segment preparation and processing<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> 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></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> Let me bring below example again. To provide claim inforamtion for retransmission of block 1000-2999,<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> <<original-positive ACK>><o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> lower bound = 0<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> upper bound = 7000<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> negative reception claim count = 2<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> offset = 0 <-- Positive ACK<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> length = 1000 <-- Positive ACK<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> offset = 3000 <-- Positive ACK<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> length = 4000 <-- Positive ACK<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> * Negative ACKs are hidden in separated Positive ACKs.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> <<negative ACK>><o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> lower bound = 0 <-- Positive ACK<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> upper bound = 7000 <-- Positive ACK<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> negative reception claim count = 1<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> offset = 1000 <-- Negative ACK<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> length = 2000 <-- Negative ACK<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> I think the latter case can work too! Or am I missing something?<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> Cheol<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> --------- <span style="font-family:"Malgun Gothic",sans-serif">
원본</span> <span style="font-family:"Malgun Gothic",sans-serif">메일</span> ---------<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> <span style="font-family:"Malgun Gothic",sans-serif">
보낸사람</span> : Keltik <dstanton@keltik.co.uk<mailto:dstanton@keltik.co.uk>><o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> <span style="font-family:"Malgun Gothic",sans-serif">
받는사람</span> : Vint Cerf <vint@google.com<mailto:vint@google.com>><o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> <span style="font-family:"Malgun Gothic",sans-serif">
참조</span> : <Felix.Flentge@esa.int<mailto:Felix.Flentge@esa.int>>, <sis-dtn@mailman.ccsds.org<mailto:sis-dtn@mailman.ccsds.org>>, "<span style="font-family:"Malgun Gothic",sans-serif">구철회</span>" <chkoo@kari.re.kr<mailto:chkoo@kari.re.kr>>
<span style="font-family:"Malgun Gothic",sans-serif">받은날짜</span> : 2022-04-04 (<span style="font-family:"Malgun Gothic",sans-serif">월</span>) 19:53:46
<span style="font-family:"Malgun Gothic",sans-serif">제목</span> : 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></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> Dai<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> Sent from my iPhone<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> On 4 Apr 2022, at 11:09, Vint Cerf via SIS-DTN <sis-dtn@mailman.ccsds.org<mailto:sis-dtn@mailman.ccsds.org>> wrote:<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> a system based solely on negative acks will not work.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> v<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> On Mon, Apr 4, 2022 at 6:08 AM Felix Flentge via SIS-DTN <sis-dtn@mailman.ccsds.org<mailto:sis-dtn@mailman.ccsds.org<mailto:sis-dtn@mailman.ccsds.org%3cmailto:sis-dtn@mailman.ccsds.org>>> wrote:<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> Ah, yes, of course you are right.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> We will look into the negative ACK as part of our LTPv2 prototyping activity.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> Regards,<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> Felix<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> From: "<span style="font-family:"Malgun Gothic",sans-serif">구철회</span>" <chkoo@kari.re.kr<mailto:chkoo@kari.re.kr<mailto:chkoo@kari.re.kr%3cmailto:chkoo@kari.re.kr>>><o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> To: <Felix.Flentge@esa.int<mailto:Felix.Flentge@esa.int<mailto:Felix.Flentge@esa.int%3cmailto:Felix.Flentge@esa.int>>><o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> Cc: "sis-dtn@mailman.ccsds.org<mailto:sis-dtn@mailman.ccsds.org><mailto:sis-dtn@mailman.ccsds.org%3cmailto:sis-dtn@mailman.ccsds.org%3e>" <sis-dtn@mailman.ccsds.org<mailto:sis-dtn@mailman.ccsds.org<mailto:sis-dtn@mailman.ccsds.org%3cmailto:sis-dtn@mailman.ccsds.org>>><o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> Date: 04/04/2022 11:58<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> Subject: RE: Re: [Sis-dtn] Positive reception claim vs. Negative reception claim in LTP Report Segment preparation and processing<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> Sent by: chkoo@kari.re.kr<mailto:chkoo@kari.re.kr<mailto:chkoo@kari.re.kr%3cmailto:chkoo@kari.re.kr>><o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> ________________________________<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> Hi Felix,<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> 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></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> lower bound = 0<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> upper bound = 7000<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> negative reception claim count = 1<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> offset = 1000<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> length = 2000<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> 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></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> 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></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> Cheol<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> --------- <span style="font-family:"Malgun Gothic",sans-serif">
원본</span> <span style="font-family:"Malgun Gothic",sans-serif">메일</span> ---------<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> <span style="font-family:"Malgun Gothic",sans-serif">
보낸사람</span> : <Felix.Flentge@esa.int<mailto:Felix.Flentge@esa.int<mailto:Felix.Flentge@esa.int%3cmailto:Felix.Flentge@esa.int>>><o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> <span style="font-family:"Malgun Gothic",sans-serif">
받는사람</span> : "<span style="font-family:"Malgun Gothic",sans-serif">구철회</span>" <chkoo@kari.re.kr<mailto:chkoo@kari.re.kr<mailto:chkoo@kari.re.kr%3cmailto:chkoo@kari.re.kr>>><o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> <span style="font-family:"Malgun Gothic",sans-serif">
참조</span> : "sis-dtn@mailman.ccsds.org<mailto:sis-dtn@mailman.ccsds.org><mailto:sis-dtn@mailman.ccsds.org%3cmailto:sis-dtn@mailman.ccsds.org%3e>" <sis-dtn@mailman.ccsds.org<mailto:sis-dtn@mailman.ccsds.org<mailto:sis-dtn@mailman.ccsds.org%3cmailto:sis-dtn@mailman.ccsds.org>>><o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> <span style="font-family:"Malgun Gothic",sans-serif">
받은날짜</span> : 2022-04-04 (<span style="font-family:"Malgun Gothic",sans-serif">월</span>) 17:40:24<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> <span style="font-family:"Malgun Gothic",sans-serif">
제목</span> : Re: [Sis-dtn] Positive reception claim vs. Negative reception claim in LTP Report Segment preparation and processing Hi Cheol,<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> 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></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> Regards,<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> Felix<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> From: "<span style="font-family:"Malgun Gothic",sans-serif">구철회</span> via SIS-DTN" <sis-dtn@mailman.ccsds.org<mailto:sis-dtn@mailman.ccsds.org<mailto:sis-dtn@mailman.ccsds.org%3cmailto:sis-dtn@mailman.ccsds.org>>><o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> To: "sis-dtn@mailman.ccsds.org<mailto:sis-dtn@mailman.ccsds.org><mailto:sis-dtn@mailman.ccsds.org%3cmailto:sis-dtn@mailman.ccsds.org%3e>" <sis-dtn@mailman.ccsds.org<mailto:sis-dtn@mailman.ccsds.org<mailto:sis-dtn@mailman.ccsds.org%3cmailto:sis-dtn@mailman.ccsds.org>>><o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> Date: 04/04/2022 10:15<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> Subject: [Sis-dtn] Positive reception claim vs. Negative reception claim in LTP Report Segment preparation and processing<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> Sent by: "SIS-DTN" <sis-dtn-bounces@mailman.ccsds.org<mailto:sis-dtn-bounces@mailman.ccsds.org<mailto:sis-dtn-bounces@mailman.ccsds.org%3cmailto:sis-dtn-bounces@mailman.ccsds.org>>><o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> ________________________________<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> Greetings,<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> 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></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> 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></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> I think negative claim is simpler and more efficient in terms of overhead for sender and receiver both.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> 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></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> Cheol<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> _______________________________________________<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> SIS-DTN mailing list<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> SIS-DTN@mailman.ccsds.org<mailto:SIS-DTN@mailman.ccsds.org<mailto:SIS-DTN@mailman.ccsds.org%3cmailto:SIS-DTN@mailman.ccsds.org>><o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> 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<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>><o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> _______________________________________________<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> SIS-DTN mailing list<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> SIS-DTN@mailman.ccsds.org<mailto:SIS-DTN@mailman.ccsds.org<mailto:SIS-DTN@mailman.ccsds.org%3cmailto:SIS-DTN@mailman.ccsds.org>><o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> 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<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>><o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> --<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> Please send any postal/overnight deliveries to:<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> Vint Cerf<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> 1435 Woodhurst Blvd<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> McLean, VA 22102<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> 703-448-0965<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> until further notice<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> _______________________________________________<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> SIS-DTN mailing list<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> SIS-DTN@mailman.ccsds.org<mailto:SIS-DTN@mailman.ccsds.org><o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> 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<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>><o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> _______________________________________________<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> SIS-DTN mailing list<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> SIS-DTN@mailman.ccsds.org<mailto:SIS-DTN@mailman.ccsds.org><o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
</div>
</body>
</html>