[Sis-dtn] [EXT] Re: Positive reception claim vs. Negative reception claim in LTP Report Segment preparation and processing

Tue Apr 5 09:23:16 UTC 2022

For your interest, this is the paper Carlo, Scott and I wrote a couple of years ago about the replication of signalling segments:

N. Alessi, S. Burleigh, C. Caini and T. De Cola, "LTP robustness enhancements to cope with high losses on space channels," 2016 8th Advanced Satellite Multimedia Systems Conference and the 14th Signal Processing for Space Communications Workshop (ASMS/SPSC), 2016, pp. 1-6, doi: 10.1109/ASMS-SPSC.2016.7601535.

As to the point of checking which scenario is more appropriate for considering the benefits of proactive NAK, as pointed out by Carlo the situation is clear for deep-space.
For near-Earth, I don't see it much different. If we assume EO missions with an altitude of about 700km, the RTT is about 4ms. The data rate in EO missions can be assumed in the order of hundreds of Mbit/s and supposed to exceed Gbit/s in the near future. If we take a conservative estimation, we can put data rate of 450 Mbit/s. If we assume TM with 1 LTP segment mapped onto 1 TM segment (max 2048 bytes), then the radiation time would be much less than 1 ms, i.e. still significantly less than the RTT. Obviously the difference between radiation time and RTT in much smaller than in the case of deep space, but the data rate is much higher so that the retransmission rounds will be very short.

Tomaso

-----Original Message-----
From: Carlo Caini <carlo.caini at unibo.it> 
Sent: Dienstag, 5. April 2022 09:50
To: Cola, Tomaso de <Tomaso.deCola at dlr.de>; Felix.Flentge at esa.int; sburleig.sb at gmail.com
Cc: chkoo at kari.re.kr; dstanton at keltik.co.uk; kscott at mitre.org; sis-dtn at mailman.ccsds.org; sis-dtn-bounces at mailman.ccsds.org
Subject: RE: [Sis-dtn] [EXT] Re: Positive reception claim vs. Negative reception claim in LTP Report Segment preparation and processing

Dear all,
  as recalled by Tomaso, RFC 5326 states:
(14) Checkpoint

   A data segment soliciting a reception report from the receiving LTP
   engine.  The EORP segment must be flagged as a checkpoint, as must
   the last segment of any retransmission; these are "mandatory
   checkpoints".  All other checkpoints are "discretionary checkpoints".

   (15) Reception Report

   A sequence of one or more report segments reporting on all block data
   reception within some scope.

   (16) Synchronous Reception Report

   A reception report that is issued in response to a checkpoint.

   (17) Asynchronous Reception Report

   A reception report that is issued in response to some implementation-
   defined event other than the arrival of a checkpoint.

Thus it is clear that an implementation already can insert both discretionary CPs (not at the end of a block) and Asynchronous RSs. To the best of my knowledge these are not implemented in ION and, in my opinion, this is the most sensible choice for space applications. In fact, when RTT>>radiation time, as in space (except LEOs), they are useless for the reasons already mentioned (I will not rfepeat myself or Scott's considerations not to bore the readers).

On the contrary, to replicate signaling segments (i.e. a CP or an RS already sent) can be advantageous if the loss probability is high, as the loss of signaling segment is worse than that of pure datra segment (1RTO+1RTT to recopver, instead of 1 RTT).. We propsed this optional replication a few years ago and this is implemented in ION.

Yours,
   Carlo

________________________________________
Da: Tomaso.deCola at dlr.de [Tomaso.deCola at dlr.de]
Inviato: martedì 5 aprile 2022 09:09
A: Felix.Flentge at esa.int; sburleig.sb at gmail.com
Cc: Carlo Caini; chkoo at kari.re.kr; dstanton at keltik.co.uk; kscott at mitre.org; sis-dtn at mailman.ccsds.org; sis-dtn-bounces at mailman.ccsds.org
Oggetto: RE: [Sis-dtn] [EXT] Re: Positive reception claim vs. Negative reception claim in LTP Report Segment preparation and processing

Yes I agree. RFC 5326 clearly specifies the possibility of issuing asynchronous reception reports, although being an asynchronous event (i.e. externally triggered, non CP-driven) it’s implementation specific.
I think this is pretty much in line with what was reminding Scott, i.e. that LTP reliability mechanisms for red parts have been somehow derived from those available with CFDP-class 2. I don’t recall however if the existing implementations of LTP (e.g., in ION) support the generation of these asynchronous reception reports.

Regards,

Tomaso

From: Felix.Flentge at esa.int <Felix.Flentge at esa.int>
Sent: Dienstag, 5. April 2022 08:10
To: sburleig.sb at gmail.com
Cc: 'Carlo Caini' <carlo.caini at unibo.it>; '구철회' <chkoo at kari.re.kr>; dstanton at keltik.co.uk; 'Dr. Keith L Scott' <kscott at mitre.org>; sis-dtn at mailman.ccsds.org; SIS-DTN <sis-dtn-bounces at mailman.ccsds.org>; Cola, Tomaso de <Tomaso.deCola at dlr.de>
Subject: Re: [Sis-dtn] [EXT] Re: Positive reception claim vs. Negative reception claim in LTP Report Segment preparation and processing

Hi,

maybe I am overlooking something: LTP already provides asynchronous reception reports. Whether these are reporting gaps (NAK) or confirm received parts (ACK) seems largely equivalent (the entries may just vary by one depending on where we have gaps). When to send these asynchronous reports is and shall be completely up to the receiver.

Regards,
Felix

From:        "sburleig.sb--- via SIS-DTN" <sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>>
To:        "'구철회'" <chkoo at kari.re.kr<mailto:chkoo at kari.re.kr>>, "'Dr. Keith L Scott'" <kscott at mitre.org<mailto:kscott at mitre.org>>, "'Carlo Caini'" <carlo.caini at unibo.it<mailto:carlo.caini at unibo.it>>, <tomaso.decola at dlr.de<mailto:tomaso.decola at dlr.de>>, <dstanton at keltik.co.uk<mailto:dstanton at keltik.co.uk>>
Cc:        sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>
Date:        05/04/2022 02:49
Subject:        Re: [Sis-dtn] [EXT] Re: 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>>
________________________________

Some notes in-line below:

From: 구철회 <chkoo at kari.re.kr<mailto:chkoo at kari.re.kr>>
Sent: Monday, April 4, 2022 4:59 PM
To: sburleig.sb at gmail.com<mailto:sburleig.sb at gmail.com>; Dr. Keith L Scott <kscott at mitre.org<mailto:kscott at mitre.org>>; Carlo Caini <carlo.caini at unibo.it<mailto:carlo.caini at unibo.it>>; tomaso.decola at dlr.de<mailto:tomaso.decola at dlr.de>; dstanton at keltik.co.uk<mailto:dstanton at keltik.co.uk>
Cc: sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>
Subject: RE: [Sis-dtn] [EXT] Re: Positive reception claim vs. Negative reception claim in LTP Report Segment preparation and processing

I think Keith thought it as if the last CP was missing.

That’s not how I read “will send the whole block and then a CP, which will elicit a RS” but I may have misunderstood.

Immediately NACK RS can save time as amount of the difference between current time and the last CP’s arrival time. I think the effect can be negligible when bandwidth is very high and a session block length is relatively small, so saving time is order of ms. Of course this effect signifies as big as an RTT when the last CP from a sender is lost during transmission.

Yes, in my example 9.96 seconds, about 2% of a round trip.  I think this is what Carlo was saying.

But I do like the way of “immediately RS”. However the immediately discretionary RS NACK can quickly burn out the return link bandwidth when continuous segment losses are happening while for independent segment loss it will be reasonable. There should be some optimization and I think this concept make LTP be expandable in various space environment.

I worry that this would introduce some additional configuration complexity in a protocol that is already very complex to configure.

Cheol

From: sburleig.sb at gmail.com<mailto:sburleig.sb at gmail.com> <sburleig.sb at gmail.com<mailto:sburleig.sb at gmail.com>>
Sent: Tuesday, April 5, 2022 4:10 AM
To: Dr. Keith L Scott <kscott at mitre.org<mailto:kscott at mitre.org>>; Carlo Caini <carlo.caini at unibo.it<mailto:carlo.caini at unibo.it>>; tomaso.decola at dlr.de<mailto:tomaso.decola at dlr.de>; 구철회 <chkoo at kari.re.kr<mailto:chkoo at kari.re.kr>>; dstanton at keltik.co.uk<mailto:dstanton at keltik.co.uk>
Cc: sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>
Subject: RE: [Sis-dtn] [EXT] Re: Positive reception claim vs. Negative reception claim in LTP Report Segment preparation and processing

Keith, I think this isn’t quite right.

Suppose we’re sending a block that is 1 Megabyte in size, split into 10,000 segments of 100 bytes each.  Suppose the OWLT is 240 seconds and the transmission rate is 800 kbps (so 100,000 bytes per second).

Suppose the 3rd segment is lost.  The receiver will detect this loss when the 4th segment is received.  That segment will have left the antenna .04 seconds after transmission began, and it will arrive at the receiver 240 seconds later.  The receiver will transmit a report segment immediately; let’s ignore the processing and radiation time for issuing the report and say that the report is received at the sender 240 seconds after the arrival of the 4th segment ? so 480.04 seconds after transmission began.  That’s the time at which retransmission can be initiated, right?

Now suppose there is no further data loss.  The EOB CP leaves the antenna 10 seconds after transmission began and arrives at the receiver 240 seconds later.  The earlier report is still en route to the sender, so the lost segment has not yet been retransmitted.  The receiver transmits the CP-triggered report immediately, at 250 seconds after transmission began.  That report is received at the sender 240 seconds after arrival of the last segment, so 490 seconds after transmission began; that’s the earliest time at which retransmission can be initiated.

So it seems to me that the gap-triggered RS has reduced closure latency by 9.96 seconds, not by 1 RTT.  What have I got wrong?

Scott

From: Dr. Keith L Scott <kscott at mitre.org<mailto:kscott at mitre.org>>
Sent: Monday, April 4, 2022 11:50 AM
To: Carlo Caini <carlo.caini at unibo.it<mailto:carlo.caini at unibo.it>>; tomaso.decola at dlr.de<mailto:tomaso.decola at dlr.de>; sburleig.sb at gmail.com<mailto:sburleig.sb at gmail.com>; chkoo at kari.re.kr<mailto:chkoo at kari.re.kr>; dstanton at keltik.co.uk<mailto:dstanton at keltik.co.uk>
Cc: sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>
Subject: Re: [Sis-dtn] [EXT] Re: Positive reception claim vs. Negative reception claim in LTP Report Segment preparation and processing

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):

If there are 10,000 LTP segments and the 3rd segment is lost:

  *   The NACK system will nack it “immediately” and elicit a retransmission.  Increased latency: about 1 segment.
  *   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.

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).

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

N = 10,000

P = 0.1

# rounds: 5

N = 10,000

P = 0.01

# rounds: 3

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).

                                v/r,

                                --keith

On 4/4/22, 1:57 PM, "Carlo Caini" <carlo.caini at unibo.it<mailto:carlo.caini at unibo.it>> wrote:

    Dear all,

       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).

    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...

    Yours,

       Carlo

    ________________________________________

    Da: Tomaso.deCola at dlr.de<mailto:Tomaso.deCola at dlr.de> [Tomaso.deCola at dlr.de]

    Inviato: lunedi 4 aprile 2022 17:54

    A: kscott at mitre.org<mailto:kscott at mitre.org>; sburleig.sb at gmail.com<mailto:sburleig.sb at gmail.com>; Carlo Caini; chkoo at kari.re.kr<mailto:chkoo at kari.re.kr>; dstanton at keltik.co.uk<mailto:dstanton at keltik.co.uk>

    Cc: sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>

    Oggetto: RE: [Sis-dtn] [EXT] Re: Positive reception claim vs. Negative reception claim in LTP Report Segment preparation and processing

    (I cc again the whole SIS-DTN mailinglist that apparently disappeared from my initial message)

    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.

    Tomaso

    From: Dr. Keith L Scott <kscott at mitre.org<mailto:kscott at mitre.org>>

    Sent: Montag, 4. April 2022 17:43

    To: sburleig.sb at gmail.com<mailto:sburleig.sb at gmail.com>; Cola, Tomaso de <Tomaso.deCola at dlr.de<mailto:Tomaso.deCola at dlr.de>>; carlo.caini at unibo.it<mailto:carlo.caini at unibo.it>; chkoo at kari.re.kr<mailto:chkoo at kari.re.kr>; dstanton at keltik.co.uk<mailto:dstanton at keltik.co.uk>

    Subject: Re: [Sis-dtn] [EXT] Re: Positive reception claim vs. Negative reception claim in LTP Report Segment preparation and processing

    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)?

                    --keith

    From: "sburleig.sb at gmail.com<mailto:sburleig.sb at gmail.com><mailto:sburleig.sb at gmail.com%3cmailto:sburleig.sb at gmail.com%3e>" <sburleig.sb at gmail.com<mailto:sburleig.sb at gmail.com<mailto:sburleig.sb at gmail.com%3cmailto:sburleig.sb at gmail.com>>>

    Date: Monday, April 4, 2022 at 11:39 AM

    To: Tomaso de Cola <Tomaso.deCola at dlr.de<mailto:Tomaso.deCola at dlr.de<mailto:Tomaso.deCola at dlr.de%3cmailto:Tomaso.deCola at dlr.de>>>, Keith Scott <kscott at mitre.org<mailto:kscott at mitre.org<mailto:kscott at mitre.org%3cmailto:kscott at mitre.org>>>, "carlo.caini at unibo.it<mailto:carlo.caini at unibo.it><mailto:carlo.caini at unibo.it%3cmailto:carlo.caini at unibo.it%3e>" <carlo.caini at unibo.it<mailto:carlo.caini at unibo.it<mailto:carlo.caini at unibo.it%3cmailto:carlo.caini at unibo.it>>>, Cheol Koo <chkoo at kari.re.kr<mailto:chkoo at kari.re.kr<mailto:chkoo at kari.re.kr%3cmailto:chkoo at kari.re.kr>>>, Dai Stanton <dstanton at keltik.co.uk<mailto:dstanton at keltik.co.uk<mailto:dstanton at keltik.co.uk%3cmailto:dstanton at keltik.co.uk>>>

    Subject: RE: [Sis-dtn] [EXT] Re: Positive reception claim vs. Negative reception claim in LTP Report Segment preparation and processing

    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.

    Scott

    From: Tomaso.deCola at dlr.de<mailto:Tomaso.deCola at dlr.de<mailto:Tomaso.deCola at dlr.de%3cmailto:Tomaso.deCola at dlr.de>> <Tomaso.deCola at dlr.de<mailto:Tomaso.deCola at dlr.de<mailto:Tomaso.deCola at dlr.de%3cmailto:Tomaso.deCola at dlr.de>>>

    Sent: Monday, April 4, 2022 8:31 AM

    To: kscott at mitre.org<mailto:kscott at mitre.org<mailto:kscott at mitre.org%3cmailto:kscott at mitre.org>>; sburleig.sb at gmail.com<mailto:sburleig.sb at gmail.com<mailto:sburleig.sb at gmail.com%3cmailto:sburleig.sb at gmail.com>>; carlo.caini at unibo.it<mailto:carlo.caini at unibo.it<mailto:carlo.caini at unibo.it%3cmailto:carlo.caini at unibo.it>>; chkoo at kari.re.kr<mailto:chkoo at kari.re.kr<mailto:chkoo at kari.re.kr%3cmailto:chkoo at kari.re.kr>>; dstanton at keltik.co.uk<mailto:dstanton at keltik.co.uk<mailto:dstanton at keltik.co.uk%3cmailto:dstanton at keltik.co.uk>>

    Subject: RE: [Sis-dtn] [EXT] Re: Positive reception claim vs. Negative reception claim in LTP Report Segment preparation and processing

    This looks similar to CFDP-class 2 with retransmission happening in asynchronous mode, isn’t it?

    Regards,

    Tomaso

    From: 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>>> On Behalf Of Dr. Keith L Scott via SIS-DTN

    Sent: Montag, 4. April 2022 17:28

    To: sburleig.sb at gmail.com<mailto:sburleig.sb at gmail.com<mailto:sburleig.sb at gmail.com%3cmailto:sburleig.sb at gmail.com>>; 'Carlo Caini' <carlo.caini at unibo.it<mailto:carlo.caini at unibo.it<mailto:carlo.caini at unibo.it%3cmailto:carlo.caini at unibo.it>>>; '"구철회"' <chkoo at kari.re.kr<mailto:chkoo at kari.re.kr<mailto:chkoo at kari.re.kr%3cmailto:chkoo at kari.re.kr>>>; 'Keltik' <dstanton at keltik.co.uk<mailto:dstanton at keltik.co.uk<mailto:dstanton at keltik.co.uk%3cmailto:dstanton at keltik.co.uk>>>

    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>>

    Subject: Re: [Sis-dtn] [EXT] Re: Positive reception claim vs. Negative reception claim in LTP Report Segment preparation and processing

    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<mailto:sis-dtn-bounces at mailman.ccsds.org><mailto:sis-dtn-bounces at mailman.ccsds.org%3cmailto:sis-dtn-bounces at mailman.ccsds.org%3e>" <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>>> on behalf of "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>>>

    Reply-To: "sburleig.sb at gmail.com<mailto:sburleig.sb at gmail.com><mailto:sburleig.sb at gmail.com%3cmailto:sburleig.sb at gmail.com%3e>" <sburleig.sb at gmail.com<mailto:sburleig.sb at gmail.com<mailto:sburleig.sb at gmail.com%3cmailto:sburleig.sb at gmail.com>>>

    Date: Monday, April 4, 2022 at 11:21 AM

    To: 'Carlo Caini' <carlo.caini at unibo.it<mailto:carlo.caini at unibo.it<mailto:carlo.caini at unibo.it%3cmailto:carlo.caini at unibo.it>>>, Cheol Koo <chkoo at kari.re.kr<mailto:chkoo at kari.re.kr<mailto:chkoo at kari.re.kr%3cmailto:chkoo at kari.re.kr>>>, Dai Stanton <dstanton at keltik.co.uk<mailto:dstanton at keltik.co.uk<mailto:dstanton at keltik.co.uk%3cmailto:dstanton at keltik.co.uk>>>

    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>>>

    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<mailto:sis-dtn-bounces at mailman.ccsds.org<mailto:sis-dtn-bounces at mailman.ccsds.org%3cmailto: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<mailto:chkoo at kari.re.kr<mailto:chkoo at kari.re.kr%3cmailto:chkoo at kari.re.kr>>>; Keltik <dstanton at keltik.co.uk<mailto:dstanton at keltik.co.uk<mailto:dstanton at keltik.co.uk%3cmailto:dstanton at keltik.co.uk>>>

    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>>

    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: lunedi 4 aprile 2022 14:20

    A: Keltik

    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>>

    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<mailto:dstanton at keltik.co.uk%3cmailto:dstanton at keltik.co.uk>>>

    받는사람 : Vint Cerf <vint at google.com<mailto:vint at google.com<mailto:vint at google.com%3cmailto:vint at google.com>>>

    참조 : <Felix.Flentge at esa.int<mailto:Felix.Flentge at esa.int<mailto:Felix.Flentge at esa.int%3cmailto:Felix.Flentge at esa.int>>>, <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>>>, "구철회" <chkoo at kari.re.kr<mailto:chkoo at kari.re.kr<mailto:chkoo at kari.re.kr%3cmailto: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<mailto:sis-dtn at mailman.ccsds.org%3cmailto: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<mailto:sis-dtn at mailman.ccsds.org%3cmailto:sis-dtn at mailman.ccsds.org%3cmailto: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<mailto:chkoo at kari.re.kr%3cmailto:chkoo at kari.re.kr%3cmailto: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<mailto:Felix.Flentge at esa.int%3cmailto:Felix.Flentge at esa.int%3cmailto: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><mailto:sis-dtn at mailman.ccsds.org%3cmailto:sis-dtn at mailman.ccsds.org%3e%3cmailto:sis-dtn at mailman.ccsds.org%3cmailto:sis-dtn at mailman.ccsds.org%3e%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<mailto:sis-dtn at mailman.ccsds.org%3cmailto:sis-dtn at mailman.ccsds.org%3cmailto: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<mailto:chkoo at kari.re.kr%3cmailto:chkoo at kari.re.kr%3cmailto: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<mailto:Felix.Flentge at esa.int%3cmailto:Felix.Flentge at esa.int%3cmailto: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<mailto:chkoo at kari.re.kr%3cmailto:chkoo at kari.re.kr%3cmailto: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><mailto:sis-dtn at mailman.ccsds.org%3cmailto:sis-dtn at mailman.ccsds.org%3e%3cmailto:sis-dtn at mailman.ccsds.org%3cmailto:sis-dtn at mailman.ccsds.org%3e%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<mailto:sis-dtn at mailman.ccsds.org%3cmailto:sis-dtn at mailman.ccsds.org%3cmailto: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<mailto:sis-dtn at mailman.ccsds.org%3cmailto:sis-dtn at mailman.ccsds.org%3cmailto: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><mailto:sis-dtn at mailman.ccsds.org%3cmailto:sis-dtn at mailman.ccsds.org%3e%3cmailto:sis-dtn at mailman.ccsds.org%3cmailto:sis-dtn at mailman.ccsds.org%3e%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<mailto:sis-dtn at mailman.ccsds.org%3cmailto:sis-dtn at mailman.ccsds.org%3cmailto: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<mailto:sis-dtn-bounces at mailman.ccsds.org%3cmailto:sis-dtn-bounces at mailman.ccsds.org%3cmailto: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<mailto:SIS-DTN at mailman.ccsds.org%3cmailto:SIS-DTN at mailman.ccsds.org%3cmailto: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<https://protect2.fireeye.com/v1/url?k=7094fbf6-2f0f91fe-70918a78-ac1f6bdccbcc-0d3d8ac66f4934b2&q=1&e=42cf6e42-dd3d-47b5-ab7c-ec8488c70286&u=https%3A%2F%2Fmailman.ccsds.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fsis-dtn%253chttps%3A%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D933edf14-cca5b51c-933bae9a-ac1f6bdccbcc-93bc8ad36316533d%26q%3D1%26e%3D24a03daf-8e73-4317-a689-3216c529ea83%26u%3Dhttps%253A%252F%252Fmailman.ccsds.org%252Fcgi-bin%252Fmailman%252Flistinfo%252Fsis-dtn%253chttps%3A%2F%2Fmailman.ccsds.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fsis-dtn%253chttps%3A%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D933edf14-cca5b51c-933bae9a-ac1f6bdccbcc-93bc8ad36316533d%26q%3D1%26e%3D24a03daf-8e73-4317-a689-3216c529ea83%26u%3Dhttps%253A%252F%252Fmailman.ccsds.org%252Fcgi-bin%252Fmailman%252Flistinfo%252Fsis-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<mailto:SIS-DTN at mailman.ccsds.org%3cmailto:SIS-DTN at mailman.ccsds.org%3cmailto: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<https://protect2.fireeye.com/v1/url?k=ef21fc5e-b0ba9656-ef248dd0-ac1f6bdccbcc-64b6674f7e819d0e&q=1&e=42cf6e42-dd3d-47b5-ab7c-ec8488c70286&u=https%3A%2F%2Fmailman.ccsds.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fsis-dtn%253chttps%3A%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D60e1ef17-3f7a851f-60e49e99-ac1f6bdccbcc-0dfe5136ab6b73dc%26q%3D1%26e%3Dcce8b1e1-1ec2-4cdd-855b-994c9a3f58c9%26u%3Dhttps%253A%252F%252Fmailman.ccsds.org%252Fcgi-bin%252Fmailman%252Flistinfo%252Fsis-dtn%253chttps%3A%2F%2Fmailman.ccsds.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fsis-dtn%253chttps%3A%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D60e1ef17-3f7a851f-60e49e99-ac1f6bdccbcc-0dfe5136ab6b73dc%26q%3D1%26e%3Dcce8b1e1-1ec2-4cdd-855b-994c9a3f58c9%26u%3Dhttps%253A%252F%252Fmailman.ccsds.org%252Fcgi-bin%252Fmailman%252Flistinfo%252Fsis-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<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=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<https://protect2.fireeye.com/v1/url?k=12719fd8-4deaf5d0-1274ee56-ac1f6bdccbcc-05a7930b38352e56&q=1&e=42cf6e42-dd3d-47b5-ab7c-ec8488c70286&u=https%3A%2F%2Fmailman.ccsds.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fsis-dtn%253chttps%3A%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D9ac1f10e-c55a9b06-9ac48080-ac1f6bdccbcc-60db088d278d85f7%26q%3D1%26e%3Dcce8b1e1-1ec2-4cdd-855b-994c9a3f58c9%26u%3Dhttps%253A%252F%252Fmailman.ccsds.org%252Fcgi-bin%252Fmailman%252Flistinfo%252Fsis-dtn%253chttps%3A%2F%2Fmailman.ccsds.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fsis-dtn%253chttps%3A%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D9ac1f10e-c55a9b06-9ac48080-ac1f6bdccbcc-60db088d278d85f7%26q%3D1%26e%3Dcce8b1e1-1ec2-4cdd-855b-994c9a3f58c9%26u%3Dhttps%253A%252F%252Fmailman.ccsds.org%252Fcgi-bin%252Fmailman%252Flistinfo%252Fsis-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=cad01285-954b788d-cad5630b-ac1f6bdccbcc-4b400b0669265909&q=1&e=42cf6e42-dd3d-47b5-ab7c-ec8488c70286&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