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

[Vint Cerf]

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

until further notice
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20220404/e5ae7e87/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3995 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20220404/e5ae7e87/attachment-0001.bin>