<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">

<head>

<meta http-equiv="Content-Type" content="text/html; charset=ks_c_5601-1987">

<meta name="Generator" content="Microsoft Word 15 (filtered medium)">

<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}

o\:* {behavior:url(#default#VML);}

w\:* {behavior:url(#default#VML);}

.shape {behavior:url(#default#VML);}

</style><![endif]--><style><!--

/* Font Definitions */

@font-face

        {font-family:굴림;

        panose-1:2 11 6 0 0 1 1 1 1 1;}

@font-face

        {font-family:"Cambria Math";

        panose-1:2 4 5 3 5 4 6 3 2 4;}

@font-face

        {font-family:Calibri;

        panose-1:2 15 5 2 2 2 4 3 2 4;}

@font-face

        {font-family:"맑은 고딕";

        panose-1:2 11 5 3 2 0 0 2 0 4;}

@font-face

        {font-family:"\@맑은 고딕";}

@font-face

        {font-family:"\@굴림";

        panose-1:2 11 6 0 0 1 1 1 1 1;}

/* Style Definitions */

p.MsoNormal, li.MsoNormal, div.MsoNormal

        {margin:0cm;

        font-size:12.0pt;

        font-family:굴림;}

a:link, span.MsoHyperlink

        {mso-style-priority:99;

        color:blue;

        text-decoration:underline;}

p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph

        {mso-style-priority:34;

        margin-top:0cm;

        margin-right:0cm;

        margin-bottom:0cm;

        margin-left:40.0pt;

        mso-para-margin-top:0cm;

        mso-para-margin-right:0cm;

        mso-para-margin-bottom:0cm;

        mso-para-margin-left:4.0gd;

        font-size:12.0pt;

        font-family:굴림;}

span.EmailStyle22

        {mso-style-type:personal-compose;

        font-family:"맑은 고딕";

        color:windowtext;}

.MsoChpDefault

        {mso-style-type:export-only;

        font-family:"맑은 고딕";}

@page WordSection1

        {size:612.0pt 792.0pt;

        margin:3.0cm 72.0pt 72.0pt 72.0pt;}

div.WordSection1

        {page:WordSection1;}

/* List Definitions */

@list l0

        {mso-list-id:14230077;

        mso-list-type:hybrid;

        mso-list-template-ids:1497237142 -1655280756 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}

@list l0:level1

        {mso-level-start-at:0;

        mso-level-text:"\(%1\)";

        mso-level-tab-stop:none;

        mso-level-number-position:left;

        margin-left:102.0pt;

        text-indent:-18.0pt;}

@list l0:level2

        {mso-level-number-format:alpha-upper;

        mso-level-tab-stop:none;

        mso-level-number-position:left;

        margin-left:124.0pt;

        text-indent:-20.0pt;}

@list l0:level3

        {mso-level-number-format:roman-lower;

        mso-level-tab-stop:none;

        mso-level-number-position:right;

        margin-left:144.0pt;

        text-indent:-20.0pt;}

@list l0:level4

        {mso-level-tab-stop:none;

        mso-level-number-position:left;

        margin-left:164.0pt;

        text-indent:-20.0pt;}

@list l0:level5

        {mso-level-number-format:alpha-upper;

        mso-level-tab-stop:none;

        mso-level-number-position:left;

        margin-left:184.0pt;

        text-indent:-20.0pt;}

@list l0:level6

        {mso-level-number-format:roman-lower;

        mso-level-tab-stop:none;

        mso-level-number-position:right;

        margin-left:204.0pt;

        text-indent:-20.0pt;}

@list l0:level7

        {mso-level-tab-stop:none;

        mso-level-number-position:left;

        margin-left:224.0pt;

        text-indent:-20.0pt;}

@list l0:level8

        {mso-level-number-format:alpha-upper;

        mso-level-tab-stop:none;

        mso-level-number-position:left;

        margin-left:244.0pt;

        text-indent:-20.0pt;}

@list l0:level9

        {mso-level-number-format:roman-lower;

        mso-level-tab-stop:none;

        mso-level-number-position:right;

        margin-left:264.0pt;

        text-indent:-20.0pt;}

ol

        {margin-bottom:0cm;}

ul

        {margin-bottom:0cm;}

--></style><!--[if gte mso 9]><xml>

<o:shapedefaults v:ext="edit" spidmax="1026" />

</xml><![endif]--><!--[if gte mso 9]><xml>

<o:shapelayout v:ext="edit">

<o:idmap v:ext="edit" data="1" />

</o:shapelayout></xml><![endif]-->

</head>

<body lang="KO" link="blue" vlink="purple" style="word-wrap:break-word">

<div class="WordSection1">

<p class="MsoNormal" style="word-break:break-hangul"><span lang="EN-US" style="font-size:10.0pt;font-family:"맑은 고딕"">Let me guess.<o:p></o:p></span></p>

<p class="MsoNormal" style="word-break:break-hangul"><span lang="EN-US" style="font-size:10.0pt;font-family:"맑은 고딕""><o:p> </o:p></span></p>

<p class="MsoNormal" style="word-break:break-hangul"><span lang="EN-US" style="font-size:10.0pt;font-family:"맑은 고딕"">I think populating the ACK/NACK reception claim information at the first time in which segmentation is lost is not quite different between them.

 Some differences can be observed during processing retransmitted data segments. I suppose there will be some differences in internal processing on a hardware (or similarly for software).<o:p></o:p></span></p>

<p class="MsoNormal" style="word-break:break-hangul"><span lang="EN-US" style="font-size:10.0pt;font-family:"맑은 고딕"">Consider below structure differences each ACK and NACK. When it encounters discontinuity of segment streams, i.e., loss of segmentation, by

 N times, (1) requires N+1 information set to hold the positive claims, and (2) requires N information set.<o:p></o:p></span></p>

<p class="MsoNormal" style="word-break:break-hangul"><span lang="EN-US" style="font-size:10.0pt;font-family:"맑은 고딕""><o:p> </o:p></span></p>

<p class="MsoNormal" style="text-indent:45.0pt;word-break:break-hangul"><span lang="EN-US" style="font-size:10.0pt;font-family:"맑은 고딕""><<(1) normal ACK>>                     <<(2) NACK>><o:p></o:p></span></p>

<p class="MsoNormal" style="word-break:break-hangul"><span lang="EN-US" style="font-size:10.0pt;font-family:"맑은 고딕""><o:p> </o:p></span></p>

<p class="MsoNormal" style="word-break:break-hangul"><span lang="EN-US" style="font-size:10.0pt;font-family:"맑은 고딕"">           +-- upper bound --+                  +-- upper bound --+<o:p></o:p></span></p>

<p class="MsoNormal" style="word-break:break-hangul"><span lang="EN-US" style="font-size:10.0pt;font-family:"맑은 고딕"">                    (7000)                                      (7000)<o:p></o:p></span></p>

<p class="MsoNormal" style="text-indent:40.0pt;word-break:break-hangul"><span lang="EN-US" style="font-size:10.0pt;font-family:"맑은 고딕"">+---------------------+<o:p></o:p></span></p>

<p class="MsoNormal" style="word-break:break-hangul"><span lang="EN-US" style="font-size:10.0pt;font-family:"맑은 고딕"">positive  |      offset (3000)    |<o:p></o:p></span></p>

<p class="MsoNormal" style="word-break:break-hangul"><span lang="EN-US" style="font-size:10.0pt;font-family:"맑은 고딕"">claim     |     length (4000)    |<o:p></o:p></span></p>

<p class="MsoNormal" style="word-break:break-hangul"><span lang="EN-US" style="font-size:10.0pt;font-family:"맑은 고딕"">          +----------------------+<o:p></o:p></span></p>

<p class="MsoNormal" style="word-break:break-hangul"><span lang="EN-US" style="font-size:10.0pt;font-family:"맑은 고딕"">                                                           +---------------------+<o:p></o:p></span></p>

<p class="MsoNormal" style="word-break:break-hangul"><span lang="EN-US" style="font-size:10.0pt;font-family:"맑은 고딕"">           -- missing segments –      negative   |     offset (1000)     |<o:p></o:p></span></p>

<p class="MsoNormal" style="text-indent:170.0pt;word-break:break-hangul"><span lang="EN-US" style="font-size:10.0pt;font-family:"맑은 고딕"">claim    |     length (2000)     |<o:p></o:p></span></p>

<p class="MsoNormal" style="text-indent:205.0pt;word-break:break-hangul"><span lang="EN-US" style="font-size:10.0pt;font-family:"맑은 고딕"">+----------------------+<o:p></o:p></span></p>

<p class="MsoNormal" style="text-indent:40.0pt;word-break:break-hangul"><span lang="EN-US" style="font-size:10.0pt;font-family:"맑은 고딕"">+---------------------+<o:p></o:p></span></p>

<p class="MsoNormal" style="word-break:break-hangul"><span lang="EN-US" style="font-size:10.0pt;font-family:"맑은 고딕"">positive  |       offset (0)        | 

<o:p></o:p></span></p>

<p class="MsoNormal" style="word-break:break-hangul"><span lang="EN-US" style="font-size:10.0pt;font-family:"맑은 고딕"">claim     |    length (1000)      |<o:p></o:p></span></p>

<p class="MsoNormal" style="word-break:break-hangul"><span lang="EN-US" style="font-size:10.0pt;font-family:"맑은 고딕"">          +----------------------+<o:p></o:p></span></p>

<ol style="margin-top:0cm" start="0" type="1">

<li class="MsoListParagraph" style="margin-left:66.0pt;mso-para-margin-left:0gd;mso-list:l0 level1 lfo1;word-break:break-hangul">

<span lang="EN-US" style="font-size:10.0pt;font-family:"맑은 고딕"">                                          (0)<o:p></o:p></span></li></ol>

<p class="MsoNormal" style="text-indent:40.0pt;word-break:break-hangul"><span lang="EN-US" style="font-size:10.0pt;font-family:"맑은 고딕"">+--  lower bound  --+                   +--  lower bound  --+<o:p></o:p></span></p>

<p class="MsoNormal" style="word-break:break-hangul"><span lang="EN-US" style="font-size:10.0pt;font-family:"맑은 고딕""><o:p> </o:p></span></p>

<p class="MsoNormal" style="word-break:break-hangul"><span lang="EN-US" style="font-size:10.0pt;font-family:"맑은 고딕"">We can just get exactly the same information of positive claims and negative claims from these two different structures. Consider a retransmitted

 segmentation (e.g., {1000, 1000}) is arrived,<o:p></o:p></span></p>

<p class="MsoNormal" style="word-break:break-hangul"><span lang="EN-US" style="font-size:10.0pt;font-family:"맑은 고딕""><o:p> </o:p></span></p>

<p class="MsoNormal" style="word-break:break-hangul"><span lang="EN-US" style="font-size:10.0pt;font-family:"맑은 고딕"">(1)’s logic has to load two information set into memory for comparison, e.g., {0, 1000}, {3000, 7000}, and then start comparing two value of

 (0+1000) and (3000) to check if the newly accepted segment is located in the missing segment area. So, (1)’s logic will require 1) memory access cycles to bring two information set into registers, 2) ALU cycles to sum-up 0+1000, 3) and comparison cycles to

 compare it {1000, 3000} with the segment size of 1000~2000.<o:p></o:p></span></p>

<p class="MsoNormal" style="word-break:break-hangul"><span lang="EN-US" style="font-size:10.0pt;font-family:"맑은 고딕""><o:p> </o:p></span></p>

<p class="MsoNormal" style="word-break:break-hangul"><span lang="EN-US" style="font-size:10.0pt;font-family:"맑은 고딕"">(2)’s logic only has to load one information set for the comparison, i.e., {1000, 2000}. So, (2)’s logic will require 1) memory access cycles

 to bring one information set into registers, 2) ALU cycles to sum-up 1000+2000, 3) comparison cycles to compare it {1000, 3000} with the segment size of 1000~2000.<o:p></o:p></span></p>

<p class="MsoNormal" style="word-break:break-hangul"><span lang="EN-US" style="font-size:10.0pt;font-family:"맑은 고딕""><o:p> </o:p></span></p>

<p class="MsoNormal" style="word-break:break-hangul"><span lang="EN-US" style="font-size:10.0pt;font-family:"맑은 고딕"">If there are N positive/negative claims stored in memory, the process will iterate until it finds a matched area. So in localizing the segment

 area to be updated (2) requires shorter cycles than (1).<o:p></o:p></span></p>

<p class="MsoNormal" style="word-break:break-hangul"><span lang="EN-US" style="font-size:10.0pt;font-family:"맑은 고딕""><o:p> </o:p></span></p>

<p class="MsoNormal" style="word-break:break-hangul"><span lang="EN-US" style="font-size:10.0pt;font-family:"맑은 고딕"">If a missing segment are fully filled by retransmitted segments, the current positive claims and negative claims have to be adjusted; (1) requires

 cycles for deleting one information set and updating another one and (2) requires cycles for just deleting current information set only. On the contrary, if the received retransmitted segment is located just mid of the missing segments area so that one additional

 information set has to be created, e.g., {1500, 500} is received, (1)’s logic requires cycles only for creating two register block and adjusting linked-list structure, but (2)’s logic requires additional cycles for updating old information set over cycles

 for creating one additional information set, but it happens just one time.<o:p></o:p></span></p>

<p class="MsoNormal" style="word-break:break-hangul"><span lang="EN-US" style="font-size:10.0pt;font-family:"맑은 고딕""><o:p> </o:p></span></p>

<p class="MsoNormal" style="word-break:break-hangul"><span lang="EN-US" style="font-size:10.0pt;font-family:"맑은 고딕"">For a conclusion, I think (2) has benefits when the reception claims are very fragmented. Of course that’s just quick thoughts and more detail

 analysis is necessary for future.<o:p></o:p></span></p>

<p class="MsoNormal" style="word-break:break-hangul"><span lang="EN-US" style="font-size:10.0pt;font-family:"맑은 고딕""><o:p> </o:p></span></p>

<p class="MsoNormal" style="word-break:break-hangul"><span lang="EN-US" style="font-size:10.0pt;font-family:"맑은 고딕"">Cheol<o:p></o:p></span></p>

<p class="MsoNormal" style="word-break:break-hangul"><span lang="EN-US" style="font-size:10.0pt;font-family:"맑은 고딕""><o:p> </o:p></span></p>

<p class="MsoNormal" style="word-break:break-hangul"><span lang="EN-US" style="font-size:10.0pt;font-family:"맑은 고딕""><o:p> </o:p></span></p>

<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">

<p class="MsoNormal"><b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Felix.Flentge@esa.int <Felix.Flentge@esa.int>

<br>

<b>Sent:</b> Monday, April 4, 2022 8:22 PM<br>

<b>To:</b> Tomaso.deCola@dlr.de<br>

<b>Cc:</b> </span><span style="font-size:11.0pt">구철회</span><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> <chkoo@kari.re.kr>; Jeremy.Mayer@dlr.de; sis-dtn@mailman.ccsds.org<br>

<b>Subject:</b> RE: [Sis-dtn] Positive reception claim vs. Negative reception claim in LTP Report Segment preparation and processing<o:p></o:p></span></p>

</div>

<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>

<p class="MsoNormal"><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif">Hi,</span><span lang="EN-US">

<br>

<br>

</span><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif">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?</span><span lang="EN-US">

<br>

<br>

</span><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif">Regards,<br>

Felix</span><span lang="EN-US"> <br>

<br>

<br>

<br>

</span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F">From:        </span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif"><<a href="mailto:Tomaso.deCola@dlr.de">Tomaso.deCola@dlr.de</a>></span><span lang="EN-US">

<br>

</span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F">To:        </span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif"><<a href="mailto:Jeremy.Mayer@dlr.de">Jeremy.Mayer@dlr.de</a>>, <<a href="mailto:Felix.Flentge@esa.int">Felix.Flentge@esa.int</a>>,

 <<a href="mailto:chkoo@kari.re.kr">chkoo@kari.re.kr</a>></span><span lang="EN-US">

<br>

</span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F">Cc:        </span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif"><<a href="mailto:sis-dtn@mailman.ccsds.org">sis-dtn@mailman.ccsds.org</a>></span><span lang="EN-US">

<br>

</span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F">Date:        </span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif">04/04/2022 12:35</span><span lang="EN-US">

<br>

</span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F">Subject:        </span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif">RE: [Sis-dtn] Positive reception claim vs. Negative reception claim

 in LTP Report Segment preparation and processing</span><span lang="EN-US"> <o:p>

</o:p></span></p>

<div class="MsoNormal" align="center" style="text-align:center"><span lang="EN-US">

<hr size="2" width="100%" noshade="" style="color:#A0A0A0" align="center">

</span></div>

<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US"><o:p> </o:p></span></p>

<p style="margin:0cm"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">Hi All,</span><span lang="EN-US"><o:p></o:p></span></p>

<p style="margin:0cm"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><span lang="EN-US"><o:p></o:p></span></p>

<p style="margin:0cm"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">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…</span><span lang="EN-US"><o:p></o:p></span></p>

<p style="margin:0cm"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><span lang="EN-US"><o:p></o:p></span></p>

<p style="margin:0cm"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">My 0.02 cents,</span><span lang="EN-US"><o:p></o:p></span></p>

<p style="margin:0cm"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><span lang="EN-US"><o:p></o:p></span></p>

<p style="margin:0cm"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">Tomaso</span><span lang="EN-US"><o:p></o:p></span></p>

<p style="margin:0cm"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><span lang="EN-US"><o:p></o:p></span></p>

<p style="margin:0cm"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><span lang="EN-US"><o:p></o:p></span></p>

<p style="margin:0cm"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><span lang="EN-US"><o:p></o:p></span></p>

<p style="margin:0cm"><span lang="EN-US" style="font-family:"Arial",sans-serif"> </span><span lang="EN-US"><o:p></o:p></span></p>

<p style="margin:0cm"><b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> SIS-DTN <<a href="mailto:sis-dtn-bounces@mailman.ccsds.org">sis-dtn-bounces@mailman.ccsds.org</a>>

<b>On Behalf Of </b>Jeremy Pierce-Mayer via SIS-DTN<b><br>

Sent:</b> Montag, 4. April 2022 12:09<b><br>

To:</b> <a href="mailto:Felix.Flentge@esa.int">Felix.Flentge@esa.int</a>; <a href="mailto:chkoo@kari.re.kr">

chkoo@kari.re.kr</a><b><br>

Cc:</b> <a href="mailto:sis-dtn@mailman.ccsds.org">sis-dtn@mailman.ccsds.org</a><b><br>

Subject:</b> Re: [Sis-dtn] Positive reception claim vs. Negative reception claim in LTP Report Segment preparation and processing</span><span lang="EN-US"><o:p></o:p></span></p>

<p style="margin:0cm"><span lang="EN-US" style="font-family:"Arial",sans-serif"> </span><span lang="EN-US"><o:p></o:p></span></p>

<p style="margin:0cm"><span lang="EN-US" style="font-family:"Calibri",sans-serif">Hi Cheol, Felix,</span><span lang="EN-US"><o:p></o:p></span></p>

<p style="margin:0cm"><span lang="EN-US" style="font-family:"Calibri",sans-serif">The efficiency of positive vs. negative claims is

<b>highly</b> 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.

</span><span lang="EN-US"><o:p></o:p></span></p>

<p style="margin:0cm"><span lang="EN-US" style="font-family:"Calibri",sans-serif"> </span><span lang="EN-US"><o:p></o:p></span></p>

<p style="margin:0cm"><span lang="EN-US" style="font-family:"Calibri",sans-serif">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.</span><span lang="EN-US"><o:p></o:p></span></p>

<p style="margin:0cm"><span lang="EN-US" style="font-family:"Calibri",sans-serif"> </span><span lang="EN-US"><o:p></o:p></span></p>

<p style="margin:0cm"><span lang="EN-US" style="font-family:"Calibri",sans-serif">Thanks,</span><span lang="EN-US"><o:p></o:p></span></p>

<p style="margin:0cm"><span lang="EN-US" style="font-family:"Calibri",sans-serif">Jeremy</span><span lang="EN-US"><o:p></o:p></span></p>

<p style="margin:0cm"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><span lang="EN-US"><o:p></o:p></span></p>

<p style="margin:0cm"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><span lang="EN-US"><o:p></o:p></span></p>

<p style="margin:0cm"><b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> SIS-DTN <</span><span lang="EN-US"><a href="mailto:sis-dtn-bounces@mailman.ccsds.org"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">sis-dtn-bounces@mailman.ccsds.org</span></a></span><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">>

<b>On Behalf Of </b>Felix Flentge via SIS-DTN<b><br>

Sent:</b> Monday, April 4, 2022 12:08 PM<b><br>

To:</b> </span><span style="font-size:11.0pt">구철회</span><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> <</span><span lang="EN-US"><a href="mailto:chkoo@kari.re.kr"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">chkoo@kari.re.kr</span></a></span><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">><b><br>

Cc:</b> </span><span lang="EN-US"><a href="mailto:sis-dtn@mailman.ccsds.org"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">sis-dtn@mailman.ccsds.org</span></a></span><b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"><br>

Subject:</span></b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Re: [Sis-dtn] Positive reception claim vs. Negative reception claim in LTP Report Segment preparation and processing</span><span lang="EN-US"><o:p></o:p></span></p>

<p style="margin:0cm"><span lang="EN-US" style="font-family:"Arial",sans-serif"> </span><span lang="EN-US"><o:p></o:p></span></p>

<p style="margin:0cm"><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif">Ah, yes, of course you are right.</span><span lang="EN-US" style="font-family:"Arial",sans-serif">

<br>

</span><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif"><br>

We will look into the negative ACK as part of our LTPv2 prototyping activity.</span><span lang="EN-US" style="font-family:"Arial",sans-serif">

<br>

</span><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif"><br>

Regards,</span><span lang="EN-US" style="font-family:"Arial",sans-serif"> </span>

<span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif"><br>

Felix</span><span lang="EN-US" style="font-family:"Arial",sans-serif"> <br>

<br>

<br>

</span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F"><br>

From:        </span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif">"</span><span style="font-size:9.0pt">구철회</span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif">" <</span><span lang="EN-US"><a href="mailto:chkoo@kari.re.kr"><span style="font-size:9.0pt;font-family:"Arial",sans-serif">chkoo@kari.re.kr</span></a></span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif">></span><span lang="EN-US" style="font-family:"Arial",sans-serif">

</span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F"><br>

To:        </span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif"><</span><span lang="EN-US"><a href="mailto:Felix.Flentge@esa.int"><span style="font-size:9.0pt;font-family:"Arial",sans-serif">Felix.Flentge@esa.int</span></a></span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif">></span><span lang="EN-US" style="font-family:"Arial",sans-serif">

</span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F"><br>

Cc:        </span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif">"</span><span lang="EN-US"><a href="mailto:sis-dtn@mailman.ccsds.org"><span style="font-size:9.0pt;font-family:"Arial",sans-serif">sis-dtn@mailman.ccsds.org</span></a></span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif">"

 <</span><span lang="EN-US"><a href="mailto:sis-dtn@mailman.ccsds.org"><span style="font-size:9.0pt;font-family:"Arial",sans-serif">sis-dtn@mailman.ccsds.org</span></a></span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif">></span><span lang="EN-US" style="font-family:"Arial",sans-serif">

</span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F"><br>

Date:        </span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif">04/04/2022 11:58</span><span lang="EN-US" style="font-family:"Arial",sans-serif">

</span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F"><br>

Subject:        </span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif">RE: Re: [Sis-dtn] Positive reception claim vs. Negative reception claim in LTP Report Segment preparation and processing</span><span lang="EN-US" style="font-family:"Arial",sans-serif">

</span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F"><br>

Sent by:        </span><span lang="EN-US"><a href="mailto:chkoo@kari.re.kr"><span style="font-size:9.0pt;font-family:"Arial",sans-serif">chkoo@kari.re.kr</span></a></span><span lang="EN-US" style="font-family:"Arial",sans-serif">

</span><span lang="EN-US"><o:p></o:p></span></p>

<div class="MsoNormal" align="center" style="text-align:center"><span lang="EN-US">

<hr size="2" width="100%" noshade="" style="color:#A0A0A0" align="center">

</span></div>

<p style="margin:0cm"><span lang="EN-US" style="font-family:"Arial",sans-serif"><br>

<br>

<br>

Hi Felix, <br>

<br>

I think current LTP spec quite works well with negative claim also. Consider below reception claim according to the LTP spec but negative claim.

<br>

<br>

lower bound = 0 <br>

upper bound = 7000 <br>

negative reception claim count = 1 <br>

offset = 1000 <br>

length = 2000 <br>

<br>

it means a receiver is requesting block of segements which starts at 1000 and length is 2000, i.e., 1000 ~ 2999, for retransmission.

<br>

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

<br>

<br>

Cheol </span><span lang="EN-US"><o:p></o:p></span></p>

<p style="margin-top:450.0pt;?Ø

ⓒO

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 po</span>">

<b><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#0062E1">---------

</span></b><b><span style="font-size:9.0pt;color:#0062E1">원본</span></b><b><span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#0062E1">

</span></b><b><span style="font-size:9.0pt;color:#0062E1">메일</span></b><b><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#0062E1"> ---------</span></b><span lang="EN-US"><o:p></o:p></span></p>

<p style="margin:0cm"><b><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif"><br>

</span></b><b><span style="font-size:9.0pt">보낸사람</span></b><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif"> : <</span><span lang="EN-US"><a href="mailto:Felix.Flentge@esa.int"><span style="font-size:9.0pt;font-family:"Arial",sans-serif">Felix.Flentge@esa.int</span></a></span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif">><b><br>

</b></span><b><span style="font-size:9.0pt">받는사람</span></b><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif"> : "</span><span style="font-size:9.0pt">구철회</span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif">"

 <</span><span lang="EN-US"><a href="mailto:chkoo@kari.re.kr"><span style="font-size:9.0pt;font-family:"Arial",sans-serif">chkoo@kari.re.kr</span></a></span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif">><b><br>

</b></span><b><span style="font-size:9.0pt">참조</span></b><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif"> : "</span><span lang="EN-US"><a href="mailto:sis-dtn@mailman.ccsds.org"><span style="font-size:9.0pt;font-family:"Arial",sans-serif">sis-dtn@mailman.ccsds.org</span></a></span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif">"

 <</span><span lang="EN-US"><a href="mailto:sis-dtn@mailman.ccsds.org"><span style="font-size:9.0pt;font-family:"Arial",sans-serif">sis-dtn@mailman.ccsds.org</span></a></span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif">><b><br>

</b></span><b><span style="font-size:9.0pt">받은날짜</span></b><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif"> : 2022-04-04 (</span><span style="font-size:9.0pt">월</span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif">)

 17:40:24<b><br>

</b></span><b><span style="font-size:9.0pt">제목</span></b><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif"> : Re: [Sis-dtn] Positive reception claim vs. Negative reception claim in LTP Report Segment preparation and processing</span><span lang="EN-US" style="font-family:"Arial",sans-serif">

</span><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif"><br>

Hi Cheol,</span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif">

</span><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif"><br>

<br>

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.</span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif">

</span><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif"><br>

<br>

Regards,</span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif">

</span><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif"><br>

Felix</span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif">

<br>

<br>

<span style="color:#5F5F5F"><br>

<br>

From:        </span>"</span><span style="font-size:9.0pt">구철회</span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif"> via SIS-DTN" <</span><span lang="EN-US"><a href="mailto:sis-dtn@mailman.ccsds.org"><span style="font-size:9.0pt;font-family:"Arial",sans-serif">sis-dtn@mailman.ccsds.org</span></a></span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif">>

<span style="color:#5F5F5F"><br>

To:        </span>"</span><span lang="EN-US"><a href="mailto:sis-dtn@mailman.ccsds.org"><span style="font-size:9.0pt;font-family:"Arial",sans-serif">sis-dtn@mailman.ccsds.org</span></a></span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif">"

 <</span><span lang="EN-US"><a href="mailto:sis-dtn@mailman.ccsds.org"><span style="font-size:9.0pt;font-family:"Arial",sans-serif">sis-dtn@mailman.ccsds.org</span></a></span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif">>

<span style="color:#5F5F5F"><br>

Date:        </span>04/04/2022 10:15 <span style="color:#5F5F5F"><br>

Subject:        </span>[Sis-dtn] Positive reception claim vs. Negative reception claim in LTP Report Segment preparation and processing

<span style="color:#5F5F5F"><br>

Sent by:        </span>"SIS-DTN" <</span><span lang="EN-US"><a href="mailto:sis-dtn-bounces@mailman.ccsds.org"><span style="font-size:9.0pt;font-family:"Arial",sans-serif">sis-dtn-bounces@mailman.ccsds.org</span></a></span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif">>

</span><span lang="EN-US"><o:p></o:p></span></p>

<div class="MsoNormal" align="center" style="text-align:center"><span lang="EN-US">

<hr size="2" width="100%" noshade="" style="color:#A0A0A0" align="center">

</span></div>

<p style="margin:0cm"><span lang="EN-US" style="font-family:"Arial",sans-serif"><br>

</span><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif"><br>

Greetings,</span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif">

</span><span lang="EN-US"><o:p></o:p></span></p>

<p style="margin:0cm"><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif"> </span><span lang="EN-US"><o:p></o:p></span></p>

<p style="margin:0cm"><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif">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).</span><span lang="EN-US"><o:p></o:p></span></p>

<p style="margin:0cm"><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif"> </span><span lang="EN-US"><o:p></o:p></span></p>

<p style="margin:0cm"><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif">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?</span><span lang="EN-US"><o:p></o:p></span></p>

<p style="margin:0cm"><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif">I think negative claim is simpler and more efficient in terms of overhead for sender and receiver both.</span><span lang="EN-US"><o:p></o:p></span></p>

<p style="margin:0cm"><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif">I like to listen experts’ opinion on LTP operation and honestly hope it to be changed in newly coming LTP spec.</span><span lang="EN-US"><o:p></o:p></span></p>

<p style="margin:0cm"><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif"> </span><span lang="EN-US"><o:p></o:p></span></p>

<p style="margin:0cm"><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif">Cheol</span><span lang="EN-US"><o:p></o:p></span></p>

<p style="mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:12.0pt;margin-left:0cm">

<span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif"><br>

<br>

_______________________________________________<br>

SIS-DTN mailing list<u><span style="color:blue"><br>

</span></u></span><span lang="EN-US"><a href="mailto:SIS-DTN@mailman.ccsds.org"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">SIS-DTN@mailman.ccsds.org</span></a></span><u><span lang="EN-US" style="font-family:"Arial",sans-serif;color:blue"><br>

</span></u><span lang="EN-US"><a href="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"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn</span></a></span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif"><br>

<br>

</span><span lang="EN-US"><o:p></o:p></span></p>

</div>

</body>

</html>