[Sis-dtn] [EXT] Re: Positive reception claim vs. Negative reception claim in LTP Report Segment preparation and processing
Dr. Keith L Scott
kscott at mitre.org
Mon Apr 4 15:28:13 UTC 2022
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.
--keith
From: "sis-dtn-bounces at mailman.ccsds.org" <sis-dtn-bounces at mailman.ccsds.org> on behalf of "sis-dtn at mailman.ccsds.org" <sis-dtn at mailman.ccsds.org>
Reply-To: "sburleig.sb at gmail.com" <sburleig.sb at gmail.com>
Date: Monday, April 4, 2022 at 11:21 AM
To: 'Carlo Caini' <carlo.caini at unibo.it>, Cheol Koo <chkoo at kari.re.kr>, Dai Stanton <dstanton at keltik.co.uk>
Cc: "sis-dtn at mailman.ccsds.org" <sis-dtn at mailman.ccsds.org>
Subject: [EXT] Re: [Sis-dtn] Positive reception claim vs. Negative reception claim in LTP Report Segment preparation and processing
Hi, guys. I believe we are actually talking about two distinct things here.
It is true that positive ACKs are required. Positive acknowledgments turn off the retransmission timers for checkpoints, report segments, and cancellation segments.
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:
• 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.
• 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.
• 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.
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.
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.
Scott
-----Original Message-----
From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org> On Behalf Of Carlo Caini via SIS-DTN
Sent: Monday, April 4, 2022 5:47 AM
To: "구철회" <chkoo at kari.re.kr>; Keltik <dstanton at keltik.co.uk>
Cc: sis-dtn at mailman.ccsds.org
Subject: Re: [Sis-dtn] Positive reception claim vs. Negative reception claim in LTP Report Segment preparation and processing
Dear Cheol,
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.
With NAK claim you would need 20 megative claims. Is that so different?
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.
Yours,
Carlo
________________________________________
Da: SIS-DTN [sis-dtn-bounces at mailman.ccsds.org] per conto di "구철회" via SIS-DTN [sis-dtn at mailman.ccsds.org]
Inviato: lunedì 4 aprile 2022 14:20
A: Keltik
Cc: sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>
Oggetto: Re: [Sis-dtn] Positive reception claim vs. Negative reception claim in LTP Report Segment preparation and processing
I think current LTP spec has positive ACK and negative ACK both. So if it is reversed the result will be the same.
Let me bring below example again. To provide claim inforamtion for retransmission of block 1000-2999,
<<original-positive ACK>>
lower bound = 0
upper bound = 7000
negative reception claim count = 2
offset = 0 <-- Positive ACK
length = 1000 <-- Positive ACK
offset = 3000 <-- Positive ACK
length = 4000 <-- Positive ACK
* Negative ACKs are hidden in separated Positive ACKs.
<<negative ACK>>
lower bound = 0 <-- Positive ACK
upper bound = 7000 <-- Positive ACK
negative reception claim count = 1
offset = 1000 <-- Negative ACK
length = 2000 <-- Negative ACK
I think the latter case can work too! Or am I missing something?
Cheol
--------- 원본 메일 ---------
보낸사람 : Keltik <dstanton at keltik.co.uk<mailto:dstanton at keltik.co.uk>>
받는사람 : Vint Cerf <vint at google.com<mailto:vint at google.com>>
참조 : <Felix.Flentge at esa.int<mailto:Felix.Flentge at esa.int>>, <sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>>, "구철회" <chkoo at kari.re.kr<mailto:chkoo at kari.re.kr>> 받은날짜 : 2022-04-04 (월) 19:53:46 제목 : 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.
Dai
Sent from my iPhone
On 4 Apr 2022, at 11:09, Vint Cerf via SIS-DTN <sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>> wrote:
a system based solely on negative acks will not work.
v
On Mon, Apr 4, 2022 at 6:08 AM Felix Flentge via SIS-DTN <sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org%3cmailto:sis-dtn at mailman.ccsds.org>>> wrote:
Ah, yes, of course you are right.
We will look into the negative ACK as part of our LTPv2 prototyping activity.
Regards,
Felix
From: "구철회" <chkoo at kari.re.kr<mailto:chkoo at kari.re.kr<mailto:chkoo at kari.re.kr%3cmailto:chkoo at kari.re.kr>>>
To: <Felix.Flentge at esa.int<mailto:Felix.Flentge at esa.int<mailto:Felix.Flentge at esa.int%3cmailto:Felix.Flentge at esa.int>>>
Cc: "sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org><mailto:sis-dtn at mailman.ccsds.org%3cmailto:sis-dtn at mailman.ccsds.org%3e>" <sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org%3cmailto:sis-dtn at mailman.ccsds.org>>>
Date: 04/04/2022 11:58
Subject: RE: Re: [Sis-dtn] Positive reception claim vs. Negative reception claim in LTP Report Segment preparation and processing
Sent by: chkoo at kari.re.kr<mailto:chkoo at kari.re.kr<mailto:chkoo at kari.re.kr%3cmailto:chkoo at kari.re.kr>>
________________________________
Hi Felix,
I think current LTP spec quite works well with negative claim also. Consider below reception claim according to the LTP spec but negative claim.
lower bound = 0
upper bound = 7000
negative reception claim count = 1
offset = 1000
length = 2000
it means a receiver is requesting block of segements which starts at 1000 and length is 2000, i.e., 1000 ~ 2999, for retransmission.
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).
Cheol
--------- 원본 메일 ---------
보낸사람 : <Felix.Flentge at esa.int<mailto:Felix.Flentge at esa.int<mailto:Felix.Flentge at esa.int%3cmailto:Felix.Flentge at esa.int>>>
받는사람 : "구철회" <chkoo at kari.re.kr<mailto:chkoo at kari.re.kr<mailto:chkoo at kari.re.kr%3cmailto:chkoo at kari.re.kr>>>
참조 : "sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org><mailto:sis-dtn at mailman.ccsds.org%3cmailto:sis-dtn at mailman.ccsds.org%3e>" <sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org%3cmailto:sis-dtn at mailman.ccsds.org>>>
받은날짜 : 2022-04-04 (월) 17:40:24
제목 : Re: [Sis-dtn] Positive reception claim vs. Negative reception claim in LTP Report Segment preparation and processing Hi Cheol,
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.
Regards,
Felix
From: "구철회 via SIS-DTN" <sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org%3cmailto:sis-dtn at mailman.ccsds.org>>>
To: "sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org><mailto:sis-dtn at mailman.ccsds.org%3cmailto:sis-dtn at mailman.ccsds.org%3e>" <sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org%3cmailto:sis-dtn at mailman.ccsds.org>>>
Date: 04/04/2022 10:15
Subject: [Sis-dtn] Positive reception claim vs. Negative reception claim in LTP Report Segment preparation and processing
Sent by: "SIS-DTN" <sis-dtn-bounces at mailman.ccsds.org<mailto:sis-dtn-bounces at mailman.ccsds.org<mailto:sis-dtn-bounces at mailman.ccsds.org%3cmailto:sis-dtn-bounces at mailman.ccsds.org>>>
________________________________
Greetings,
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).
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?
I think negative claim is simpler and more efficient in terms of overhead for sender and receiver both.
I like to listen experts’ opinion on LTP operation and honestly hope it to be changed in newly coming LTP spec.
Cheol
_______________________________________________
SIS-DTN mailing list
SIS-DTN at mailman.ccsds.org<mailto:SIS-DTN at mailman.ccsds.org<mailto:SIS-DTN at mailman.ccsds.org%3cmailto:SIS-DTN at mailman.ccsds.org>>
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>>
_______________________________________________
SIS-DTN mailing list
SIS-DTN at mailman.ccsds.org<mailto:SIS-DTN at mailman.ccsds.org<mailto:SIS-DTN at mailman.ccsds.org%3cmailto:SIS-DTN at mailman.ccsds.org>>
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>>
--
Please send any postal/overnight deliveries to:
Vint Cerf
1435 Woodhurst Blvd
McLean, VA 22102
703-448-0965
until further notice
_______________________________________________
SIS-DTN mailing list
SIS-DTN at mailman.ccsds.org<mailto:SIS-DTN at mailman.ccsds.org>
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>>
_______________________________________________
SIS-DTN mailing list
SIS-DTN at mailman.ccsds.org<mailto:SIS-DTN at mailman.ccsds.org>
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20220404/c66ddfb2/attachment-0001.htm>
More information about the SIS-DTN
mailing list