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

Mon Apr 4 11:21:39 UTC 2022

Hi,

yes, I also assume that for typical space links they would be quite 
similar in terms of efficiency. I think the question is also about 
implementation complexity: is it 'easier' to implement NAK-based 
re-transmission at high-data rates in hardware with maybe limited 
resources?

Regards,
Felix

From:   <Tomaso.deCola at dlr.de>
To:     <Jeremy.Mayer at dlr.de>, <Felix.Flentge at esa.int>, <chkoo at kari.re.kr>
Cc:     <sis-dtn at mailman.ccsds.org>
Date:   04/04/2022 12:35
Subject:        RE: [Sis-dtn] Positive reception claim vs. Negative 
reception claim in LTP Report Segment preparation and processing

Hi All,

I tend to agree with Jeremy, from a pure ARQ effectiveness view point, 
using ACK or NACK for signalling (or detecting) losses pretty much depends 
on the channel model you are assuming underneath. I’m quite sure in the 
scientific literature you can find many papers about using either 
approach. For typical space links, probably using ACK or NAK does not 
bring significant differences from a performance standpoint. As to the 
optical and Ka-band communication links, again, I’d say it depends on the 
channel model and more concretely on how packet losses are distributed 
after channel coding and CRC control at frame level. In particular, it may 
depend on the specific reliability measures implemented at the physical 
layer (e.g., long interleavers, long codewords, etc…), hence possibly 
resulting in an almost error-free channel (with some sporadic erasures) or 
in a more correlated loss pattern. At the end, I don’t think we can come 
up with an ideal ARQ solution that works at best for all possible channels
…

My 0.02 cents,

Tomaso

From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org> On Behalf Of Jeremy 
Pierce-Mayer via SIS-DTN
Sent: Montag, 4. April 2022 12:09
To: Felix.Flentge at esa.int; chkoo at kari.re.kr
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

Hi Cheol, Felix,
The efficiency of positive vs. negative claims is highly dependent upon 
the behaviour of the underlying link. If a link has long periods of 
successful communication punctuated by brief (complete) fading events, 
then NACK may be better. If a link is more erratic, then the calculations 
become a bit harder and are highly dependent on the ratio and duration of 
successful vs lost packets/frames. 

In most “reliable” space links, fading is pretty intermittent (until 
your elevation reduces), so ACK/NACK should be pretty similar. I think 
Ka/optical might upset this balance though… We’ll see.

Thanks,
Jeremy

From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org> On Behalf Of Felix 
Flentge via SIS-DTN
Sent: Monday, April 4, 2022 12:08 PM
To: 구철회 <chkoo at kari.re.kr>
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

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> 
To:        <Felix.Flentge at esa.int> 
Cc:        "sis-dtn at mailman.ccsds.org" <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 

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>
받는사람 : "구철회" <chkoo at kari.re.kr>
참조 : "sis-dtn at mailman.ccsds.org" <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> 
To:        "sis-dtn at mailman.ccsds.org" <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> 

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
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/54d92ebc/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 11926 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20220404/54d92ebc/attachment-0001.bin>