[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 18:15:58 UTC 2022
Right. The concept I’m proposing exploring I the use of proactive NAKs (i.e. not necessarily elicited by checkpoints) to quickly identify (and elicit filling of) holes and then use the regular ACK-based CP/RS/RSA to ensure completion.
v/r,
--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: Vint Cerf <vint at google.com>
Date: Monday, April 4, 2022 at 2:05 PM
To: "jeremy.mayer at dlr.de" <jeremy.mayer at dlr.de>
Cc: "sis-dtn at mailman.ccsds.org" <sis-dtn at mailman.ccsds.org>, Cheol Koo <chkoo at kari.re.kr>
Subject: [EXT] Re: [Sis-dtn] Positive reception claim vs. Negative reception claim in LTP Report Segment preparation and processing
if you use only NAK, you won't be able to figure out whether the last packet made it.
Somewhere you need an ACK. Nacks can improve efficiency to avoid unneeded re-transmission but somewhere in the protocol you do need positive ACK.
v
On Mon, Apr 4, 2022 at 6:46 AM <Jeremy.Mayer at dlr.de<mailto:Jeremy.Mayer at dlr.de>> wrote:
Vint,
In this use-case, or generally? Since that sort of depends on stream vs message semantics. In the strictest possible sense, NORM can run in NACK-only mode.
Thanks,
Jeremy
From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org<mailto:sis-dtn-bounces at mailman.ccsds.org>> On Behalf Of Vint Cerf via SIS-DTN
Sent: Monday, April 4, 2022 12:09 PM
To: Felix.Flentge at esa.int<mailto:Felix.Flentge at esa.int>
Cc: sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>; 구철회 <chkoo at kari.re.kr<mailto:chkoo at kari.re.kr>>
Subject: Re: [Sis-dtn] Positive reception claim vs. Negative reception claim in LTP Report Segment preparation and processing
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>> 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>>
To: <Felix.Flentge at esa.int<mailto:Felix.Flentge at esa.int>>
Cc: "sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>" <sis-dtn at mailman.ccsds.org<mailto: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>
________________________________
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>>
받는사람 : "구철회" <chkoo at kari.re.kr<mailto:chkoo at kari.re.kr>>
참조 : "sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>" <sis-dtn at mailman.ccsds.org<mailto: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>>
To: "sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>" <sis-dtn at mailman.ccsds.org<mailto: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>>
________________________________
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>
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>
_______________________________________________
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
--
Please send any postal/overnight deliveries to:
Vint Cerf
1435 Woodhurst Blvd
McLean, VA 22102
703-448-0965<tel:(703)%20448-0965>
until further notice
--
Please send any postal/overnight deliveries to:
Vint Cerf
1435 Woodhurst Blvd
McLean, VA 22102
703-448-0965
until further notice
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20220404/ab696351/attachment-0001.htm>
More information about the SIS-DTN
mailing list