<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=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Gulim;
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:"Malgun Gothic";
panose-1:2 11 5 3 2 0 0 2 0 4;}
@font-face
{font-family:"\@Malgun Gothic";}
@font-face
{font-family:"\@Gulim";
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:"Gulim",sans-serif;
mso-fareast-language:KO;}
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:"Gulim",sans-serif;
mso-fareast-language:KO;}
span.EmailStyle24
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@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:712122743;
mso-list-type:hybrid;
mso-list-template-ids:-601557234 -526329744 134807577 134807579 134807567 134807577 134807579 134807567 134807577 134807579;}
@list l0:level1
{mso-level-number-format:alpha-lower;
mso-level-text:"%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:90.0pt;
text-indent:-18.0pt;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:126.0pt;
text-indent:-18.0pt;}
@list l0:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
margin-left:162.0pt;
text-indent:-9.0pt;}
@list l0:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:198.0pt;
text-indent:-18.0pt;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:234.0pt;
text-indent:-18.0pt;}
@list l0:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
margin-left:270.0pt;
text-indent:-9.0pt;}
@list l0:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:306.0pt;
text-indent:-18.0pt;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:342.0pt;
text-indent:-18.0pt;}
@list l0:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
margin-left:378.0pt;
text-indent:-9.0pt;}
@list l1
{mso-list-id:1643923469;
mso-list-type:hybrid;
mso-list-template-ids:-125683654 134807569 134807577 134807579 134807567 134807577 134807579 134807567 134807577 134807579;}
@list l1:level1
{mso-level-text:"%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.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="EN-GB" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US">All,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US">Great to get all this feedback on the proposed protocol and we will work to respect all your valuable comments. Although I have not looked in all
the details, I would like to provide a couple of answers/comments/ideas:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<ol style="margin-top:0cm" start="1" type="1">
<li class="MsoListParagraph" style="margin-left:0cm;mso-para-margin-left:0gd;mso-list:l1 level1 lfo1">
<span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US">Yes, we should describe the session invariants (actually, clearly identify which parameters are associated with a given session) and need to improve the protocol behaviour
description (‘terse style’).<o:p></o:p></span></li></ol>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<ol style="margin-top:0cm" start="2" type="1">
<li class="MsoListParagraph" style="margin-left:0cm;mso-para-margin-left:0gd;mso-list:l1 level1 lfo1">
<span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US">Yes, we need to document the requirements / assumption on the underlying transport layer (we are trying to be as flexible as possible regarding the transport)<o:p></o:p></span></li></ol>
<p class="MsoListParagraph" style="margin-left:48.0pt"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<ol style="margin-top:0cm" start="3" type="1">
<li class="MsoListParagraph" style="margin-left:0cm;mso-para-margin-left:0gd;mso-list:l1 level1 lfo1">
<span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US">We should discuss whether we should include length information for (data) segments. I am mainly thinking about the case where we would run over fixed-length frames without
a service providing delimited N+1 layer service units (or running over stream-oriented protocols). In this case, we should have the option to determine the complete length of a segment. This could be done by adding something to the data segment (data length
after the block length) or we could add something to the header (e.g., overall length of the full segment or just data segment length).<o:p></o:p></span></li></ol>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<ol style="margin-top:0cm" start="4" type="1">
<li class="MsoListParagraph" style="margin-left:0cm;mso-para-margin-left:0gd;mso-list:l1 level1 lfo1">
<span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US">In particular for out-of-order delivery there may be some tweaks required (e.g., delay sending a data acknowledgment, asynchronous data acknowledgment requests after
re-transmission of segments, …). I think these ‘tweaks’ should not be part of the standard but an implementation matter (this is how it’s handled with CFDP). Of course, it makes a lot of sense to add corresponding notes to explain that it could be a good idea
to implement these ‘tweaks’.<o:p></o:p></span></li></ol>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<ol style="margin-top:0cm" start="5" type="1">
<li class="MsoListParagraph" style="margin-left:0cm;mso-para-margin-left:0gd;mso-list:l1 level1 lfo1">
<span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US">Suspend & Resume: I have looked in the draft which mentions a suspend as part of the session management extensions but this is not exposed via the service interface.
I think, in general we can distinguish between<o:p></o:p></span></li></ol>
<p class="MsoListParagraph" style="margin-left:48.0pt"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<ol style="margin-top:0cm" start="1" type="a">
<li class="MsoListParagraph" style="margin-left:54.0pt;mso-para-margin-left:0gd;mso-list:l0 level1 lfo2">
<span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US">Suspension of all sessions to a specific remote entity (e.g., in case we don’t have a link – for reliable we even might want to distinguish between forward and return
link)<o:p></o:p></span></li><li class="MsoListParagraph" style="margin-left:54.0pt;mso-para-margin-left:0gd;mso-list:l0 level1 lfo2">
<span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US">Suspension of individual sessions (+ we might want to distinguish between stopping to send data segments and pausing timers)<o:p></o:p></span></li></ol>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US">My preference would be to only allow a) or b) (or say a) will cause b) for all sessions to a remote entity) but not end
up with a mixture like CFDP (sorry, I am biased) has. We also need to think about the suspension signalling (like it is currently in the session management extension).<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:48.0pt"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<ol style="margin-top:0cm" start="6" type="1">
<li class="MsoListParagraph" style="margin-left:0cm;mso-para-margin-left:0gd;mso-list:l1 level1 lfo1">
<span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US">Data Reception Interface: I think the proposed interface meets all the wishes expressed in the emails (block level data delivery and data segment delivery):<o:p></o:p></span></li></ol>
<p class="MsoListParagraph" style="margin-left:48.0pt"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<ol style="margin-top:0cm" start="6" type="1">
<ol style="margin-top:0cm" start="1" type="a">
<li class="MsoListParagraph" style="margin-left:0cm;mso-para-margin-left:0gd;mso-list:l1 level2 lfo1">
<span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US">ReceptionCompleted.Indication can provide reception map and received data<o:p></o:p></span></li><li class="MsoListParagraph" style="margin-left:0cm;mso-para-margin-left:0gd;mso-list:l1 level2 lfo1">
<span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US">The optional RangeReceived.indication can provide data from individual segments (I think even chunks of data of continuous segments)<o:p></o:p></span></li></ol>
</ol>
<p class="MsoListParagraph" style="margin-left:36.0pt;mso-para-margin-left:0gd"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US"><br>
In addition, we have the same indications for reliable and unreliable transmission which is great for cases where you sometimes have an uplink available which you can use for re-transmission requests and sometimes you don’t (and may not even need one as you
have a very reliable link, e.g different frequencies or more coding).<br>
<br>
<o:p></o:p></span></p>
<ol style="margin-top:0cm" start="7" type="1">
<li class="MsoListParagraph" style="margin-left:0cm;mso-para-margin-left:0gd;mso-list:l1 level1 lfo1">
<span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US">I think we need to clarify sending of Metadata Acknowledgment and use of serial numbers better. I think Cheol’s proposal 2. 1) to require MA & DA in the same segment
might be a good idea.<br>
<br>
<o:p></o:p></span></li><li class="MsoListParagraph" style="margin-left:0cm;mso-para-margin-left:0gd;mso-list:l1 level1 lfo1">
<span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US">I don’t like Simplified Link Reliability Protocol too much (there are other protocols that claim to simple
</span><span style="font-size:11.0pt;font-family:Wingdings;mso-fareast-language:EN-US">à</span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US"> see SNMP
</span><span style="font-size:11.0pt;font-family:"Segoe UI Emoji",sans-serif;mso-fareast-language:EN-US">😉</span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US"> and we also offer unreliable service with block level
semantics). The working title we have used has been HRLTP (High-rate LTP) but I also understand the wish to make clear that it is different from current LTP and not use LTP in the name). Maybe something like Streamlined (or Space) Block Transmission Protocol
– SBTP (it seems difficult to come up with 3-letter acronyms which are not taken by any other protocol already …).<o:p></o:p></span></li></ol>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-GB">Regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-GB">Felix<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal" style="margin-left:36.0pt"><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">
</span><span lang="KO" style="font-size:11.0pt">구철회</span><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> <chkoo@kari.re.kr>
<br>
<b>Sent:</b> Wednesday, May 17, 2023 6:26 AM<br>
<b>To:</b> Jeremy.Mayer@dlr.de; Felix Flentge <Felix.Flentge@esa.int><br>
<b>Cc:</b> sis-dtn@mailman.ccsds.org<br>
<b>Subject:</b> RE: [Sis-dtn] LTPv2 Draft Blue Book for Review<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal" style="margin-left:36.0pt"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt;word-break:break-all"><span lang="EN-US" style="font-size:10.0pt;font-family:"Malgun Gothic",sans-serif">Hi, Jeremy.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt;word-break:break-all"><span lang="EN-US" style="font-size:10.0pt;font-family:"Malgun Gothic",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt;word-break:break-all"><span lang="EN-US" style="font-size:10.0pt;font-family:"Malgun Gothic",sans-serif">Yes, that note somewhere in the draft doc would be helpful!!<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt;word-break:break-all"><span lang="EN-US" style="font-size:10.0pt;font-family:"Malgun Gothic",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt;word-break:break-all"><span lang="EN-US" style="font-size:10.0pt;font-family:"Malgun Gothic",sans-serif">I have another questions. Please find below questions and comments.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt;word-break:break-all"><span lang="EN-US" style="font-size:10.0pt;font-family:"Malgun Gothic",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt;word-break:break-all"><span lang="EN-US" style="font-size:10.0pt;font-family:"Malgun Gothic",sans-serif">1. Speaking of handling serial number, will the following practices from RFC-5326 be considered in the LTPv2
draft?<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt;word-break:break-all"><span lang="EN-US" style="font-size:10.0pt;font-family:"Malgun Gothic",sans-serif">From
</span><span lang="KO" style="font-size:10.0pt;font-family:"Malgun Gothic",sans-serif">“</span><span lang="EN-US" style="font-size:10.0pt;font-family:"Malgun Gothic",sans-serif">Checkpoint serial number (SDNV)</span><span lang="KO" style="font-size:10.0pt;font-family:"Malgun Gothic",sans-serif">”</span><span lang="EN-US" style="font-size:10.0pt;font-family:"Malgun Gothic",sans-serif">
part in 3.2.1. Data Segment (DS) of RFC-5326<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt;word-break:break-all"><span lang="EN-US" style="font-size:10.0pt;font-family:"Malgun Gothic",sans-serif">1) Any subsequent checkpoints issued by the sender MUST have the serial number value found by incrementing
the prior checkpoint serial number by 1.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt;word-break:break-all"><span lang="EN-US" style="font-size:10.0pt;font-family:"Malgun Gothic",sans-serif">2) The checkpoint serial number MUST NOT be zero.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt;word-break:break-all"><span lang="EN-US" style="font-size:10.0pt;font-family:"Malgun Gothic",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt;word-break:break-all"><span lang="EN-US" style="font-size:10.0pt;font-family:"Malgun Gothic",sans-serif">===================================================<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt;word-break:break-all"><span lang="EN-US" style="font-size:10.0pt;font-family:"Malgun Gothic",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt;word-break:break-all"><span lang="EN-US" style="font-size:10.0pt;font-family:"Malgun Gothic",sans-serif">2. How new LTPv2 will treat if it encounters below situations?<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt;word-break:break-all"><span lang="EN-US" style="font-size:10.0pt;font-family:"Malgun Gothic",sans-serif">* Acronym and Abbreviations<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt;word-break:break-all"><span lang="EN-US" style="font-size:10.0pt;font-family:"Malgun Gothic",sans-serif">DS : Data Segments<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt;word-break:break-all"><span lang="EN-US" style="font-size:10.0pt;font-family:"Malgun Gothic",sans-serif">DAR : Data Acknowledgement Request<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt;word-break:break-all"><span lang="EN-US" style="font-size:10.0pt;font-family:"Malgun Gothic",sans-serif">MA : Metadata Acknowledgement<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt;word-break:break-all"><span lang="EN-US" style="font-size:10.0pt;font-family:"Malgun Gothic",sans-serif">DA : Data Acknowledgement<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt;word-break:break-all"><span lang="EN-US" style="font-size:10.0pt;font-family:"Malgun Gothic",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt;word-break:break-all"><span lang="EN-US" style="font-size:10.0pt;font-family:"Malgun Gothic",sans-serif">1) A sending engine sends DS to a receiving engine. After the sending engine transmits final data segments,
it sends an DAR.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt;word-break:break-all"><span lang="EN-US" style="font-size:10.0pt;font-family:"Malgun Gothic",sans-serif">Then the receiving engine replies to that request with an MA and an DA. Let</span><span lang="KO" style="font-size:10.0pt;font-family:"Malgun Gothic",sans-serif">’</span><span lang="EN-US" style="font-size:10.0pt;font-family:"Malgun Gothic",sans-serif">s
consider that the MA is lost during transaction but the DA are successfully transmitted. Then the sending engine does not receive the MA but DOES receive the DA.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt;word-break:break-all"><span lang="EN-US" style="font-size:10.0pt;font-family:"Malgun Gothic",sans-serif"> *<b>Question</b>* How the sending engine will treat this? Retransmit the same DAR?<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt;word-break:break-all"><span lang="EN-US" style="font-size:10.0pt;font-family:"Malgun Gothic",sans-serif">The sending engine CAN</span><span lang="KO" style="font-size:10.0pt;font-family:"Malgun Gothic",sans-serif">’</span><span lang="EN-US" style="font-size:10.0pt;font-family:"Malgun Gothic",sans-serif">T
infer explicitly (*NOTE* can be implicitly possible) that just received DA are related to the DAR because the DA field has no information about the serial number accompanied with the DAR, the MA DOES have that information but it is lost during transaction.
If the sending engine retransmits the DAR again, the receiving engine has to retransmit MA and all DA again, possibly causing retransmission of DS by the sending engine.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt;text-indent:7.2pt;word-break:break-all">
<span lang="EN-US" style="font-size:10.0pt;font-family:"Malgun Gothic",sans-serif">*<b>TO PREVENT THIS</b>* I think, an MA and DA shall be mandated to be included together within a LTP block. Alternatively, the DA can have an additional field indicating the
relevant DAR</span><span lang="KO" style="font-size:10.0pt;font-family:"Malgun Gothic",sans-serif">’</span><span lang="EN-US" style="font-size:10.0pt;font-family:"Malgun Gothic",sans-serif">s serial number as a reference just in case.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt;word-break:break-all"><span lang="EN-US" style="font-size:10.0pt;font-family:"Malgun Gothic",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt;word-break:break-all"><span lang="EN-US" style="font-size:10.0pt;font-family:"Malgun Gothic",sans-serif">2) DA on a receiving engine can be triggered by an DAR from a sending engine(Type 0x00) or implementation-specific
heuristics (Type 0x01). In some circumstances, multiple occurrences of DS and DAR followed by DS can be possible. Or a malicious attacker can send an DA to a sending engine. A sending engine needs a way how to deal with it appropriately.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt;word-break:break-all"><span lang="EN-US" style="font-size:10.0pt;font-family:"Malgun Gothic",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt;word-break:break-all"><span lang="EN-US" style="font-size:10.0pt;font-family:"Malgun Gothic",sans-serif">Best,<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt;word-break:break-all"><span lang="EN-US" style="font-size:10.0pt;font-family:"Malgun Gothic",sans-serif">Cheol<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt;word-break:break-all"><span lang="EN-US" style="font-size:10.0pt;font-family:"Malgun Gothic",sans-serif"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal" style="margin-left:36.0pt"><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">
<a href="mailto:Jeremy.Mayer@dlr.de">Jeremy.Mayer@dlr.de</a> <<a href="mailto:Jeremy.Mayer@dlr.de">Jeremy.Mayer@dlr.de</a>>
<br>
<b>Sent:</b> Tuesday, May 16, 2023 5:37 PM<br>
<b>To:</b> </span><span lang="KO" style="font-size:11.0pt">구철회</span><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> <<a href="mailto:chkoo@kari.re.kr">chkoo@kari.re.kr</a>>;
<a href="mailto:Felix.Flentge@esa.int">Felix.Flentge@esa.int</a><br>
<b>Cc:</b> <a href="mailto:sis-dtn@mailman.ccsds.org">sis-dtn@mailman.ccsds.org</a><br>
<b>Subject:</b> RE: [Sis-dtn] LTPv2 Draft Blue Book for Review<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US">Hi Cheol,<br>
The length of any field within the headers are fixed per-session, so if you chose a (for example) 4-byte serial number, you’re stuck with it until the transmission has completed. That’s why we can always infer the SN length from the extension header. Since
we only support session-level interleaving (e.g. extensions/metadata cannot span across multiple session numbers), we can simplify the length finding logic.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US">I’ll add a section describing the “rules” for lengths, since presently it’s sort of non-normative and in an annex.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US">Thanks,<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US">Jeremy<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal" style="margin-left:36.0pt"><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">
</span><span lang="KO" style="font-size:11.0pt">구철회</span><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> <<a href="mailto:chkoo@kari.re.kr">chkoo@kari.re.kr</a>>
<br>
<b>Sent:</b> Tuesday, May 16, 2023 10:14 AM<br>
<b>To:</b> Mayer, Jeremy <<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:ccorsten@gmv.com">
ccorsten@gmv.com</a><br>
<b>Cc:</b> <a href="mailto:sis-dtn@mailman.ccsds.org">sis-dtn@mailman.ccsds.org</a><br>
<b>Subject:</b> RE: [Sis-dtn] LTPv2 Draft Blue Book for Review<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p style="margin-left:36.0pt"><span lang="EN-US" style="font-size:10.0pt">Hi, Jeremy & Felix.<br>
<br>
I have a question about the Serial number in the Extensions header.<br>
<br>
During configuration of an extension field, we refer below section for identifying appropriate serial number.<br>
4.2.8.4.3.6</span><span lang="EN-US" style="font-size:10.0pt;font-family:"Times New Roman",serif"> </span><span lang="EN-US" style="font-size:10.0pt"> Extension Serial Number<br>
4.2.8.4.3.6.1</span><span lang="EN-US" style="font-size:10.0pt;font-family:"Times New Roman",serif"> </span><span lang="EN-US" style="font-size:10.0pt"> The second field within a single entry must be the extension serial number<br>
4.2.8.4.3.6.2</span><span lang="EN-US" style="font-size:10.0pt;font-family:"Times New Roman",serif"> </span><span lang="EN-US" style="font-size:10.0pt"> The length of this field (in octets) must be represented by the value of the serial number length field
within the extension header.<br>
4.2.8.4.3.6.3</span><span lang="EN-US" style="font-size:10.0pt;font-family:"Times New Roman",serif"> </span><span lang="EN-US" style="font-size:10.0pt"> The extension serial number field must be set to the value of a previously-received serial number.<br>
<br>
By assuming followings:<br>
1) the serial number will be randomly generated in [1, 2^64-1].<br>
2) and the length of the serial number is variable and in range 1 ~ 8 bytes.<br>
<br>
Now, questions<br>
1) Can the length of extension's serial number each LTPv2 segment be different? (It seems current draft says it Yes)<br>
If above question's answer is Yes, members of the Extension Serial Number(s) in the metadata Acknowledgement Extension can be different in their size. If this is correct assumption, then a consideration for inferring the length of each Serial Number(s) is needed.
See Section 4.2.8.4.3.6.<br>
<br>
For short, "the value of the serial number length field within the extension header" can't be useful for understanding the multiple "Extension Serial Number" field in every elements of the Metadata Acknowledgement Extension.<br>
<br>
<br>
Best,<br>
Cheol<br>
<br>
<br>
-----Original Message-----<br>
From: </span><span lang="KO" style="font-size:10.0pt">구철회</span><span lang="EN-US" style="font-size:10.0pt"><br>
Sent: Monday, May 15, 2023 4:10 PM<br>
To: 'Jeremy.Mayer@dlr.de' <<a href="mailto:Jeremy.Mayer@dlr.de">Jeremy.Mayer@dlr.de</a>>; 'Felix.Flentge@esa.int' <<a href="mailto:Felix.Flentge@esa.int">Felix.Flentge@esa.int</a>>; 'ccorsten@gmv.com' <<a href="mailto:ccorsten@gmv.com">ccorsten@gmv.com</a>><br>
Cc: 'sis-dtn@mailman.ccsds.org' <<a href="mailto:sis-dtn@mailman.ccsds.org">sis-dtn@mailman.ccsds.org</a>><br>
Subject: [Sis-dtn] LTPv2 Draft Blue Book for Review<br>
<br>
Hi, Jeremy & Felix.<br>
<br>
I am reading the draft of LTPv2.<br>
I have found some typos and wrong numbering. Please find the attached document commented by me until Section 5.<br>
And I put some thoughts from me.<br>
Hope this be useful for finalizing the draft document.<br>
<br>
Best,<br>
Cheol<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Tue, 9 May 2023 21:47:52 +0000<br>
From: <<a href="mailto:Jeremy.Mayer@dlr.de">Jeremy.Mayer@dlr.de</a>><br>
To: <<a href="mailto:sis-dtn@mailman.ccsds.org">sis-dtn@mailman.ccsds.org</a>><br>
Cc: <<a href="mailto:Felix.Flentge@esa.int">Felix.Flentge@esa.int</a>>, <<a href="mailto:ccorsten@gmv.com">ccorsten@gmv.com</a>><br>
Subject: [Sis-dtn] LTPv2 Draft Blue Book for Review<br>
Message-ID: <<a href="mailto:ce39808e8d454bc6a1b9492a9c3601d6@dlr.de">ce39808e8d454bc6a1b9492a9c3601d6@dlr.de</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi everyone,<br>
In order to provide a baseline for tomorrows discussion of the proposed LTPv2 protocol, I've attached the draft blue book for the standard. After showcasing the proposed approach and rational, we're intending to go through the document, focusing on the underlying
protocol.<br>
<br>
Thanks,<br>
Jeremy & Felix<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://protect2.fireeye.com/v1/url?k=49654323-16fe292b-496032ad-ac1f6bdccbcc-9f3a4573ad06235c&q=1&e=e8df1ab1-ca9a-403e-8725-23603284ec27&u=http%3A%2F%2Fmailman.ccsds.org%2Fpipermail%2Fsis-dtn%2Fattachments%2F20230509%2Fa4acfc78%2Fattachment.htm">https://protect2.fireeye.com/v1/url?k=d594e974-8a0f837c-d59198fa-ac1f6bdccbcc-1bc9b51193935a08&q=1&e=240c812c-b72b-4c10-a8ce-bbd260da108e&u=http%3A%2F%2Fmailman.ccsds.org%2Fpipermail%2Fsis-dtn%2Fattachments%2F20230509%2Fa4acfc78%2Fattachment.htm</a>><br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: LTPv2 Blue Book Draft 28.04.2023_for CCSDS Review.doc<br>
Type: application/msword<br>
Size: 446976 bytes<br>
Desc: LTPv2 Blue Book Draft 28.04.2023_for CCSDS Review.doc<br>
URL: <<a href="https://protect2.fireeye.com/v1/url?k=e73cb4fe-b8a7def6-e739c570-ac1f6bdccbcc-ae0de84bd02f3bcf&q=1&e=e8df1ab1-ca9a-403e-8725-23603284ec27&u=http%3A%2F%2Fmailman.ccsds.org%2Fpipermail%2Fsis-dtn%2Fattachments%2F20230509%2Fa4acfc78%2Fattachment.doc">https://protect2.fireeye.com/v1/url?k=dfc4f39a-805f9992-dfc18214-ac1f6bdccbcc-1eea1efeeb0ae6a7&q=1&e=240c812c-b72b-4c10-a8ce-bbd260da108e&u=http%3A%2F%2Fmailman.ccsds.org%2Fpipermail%2Fsis-dtn%2Fattachments%2F20230509%2Fa4acfc78%2Fattachment.doc</a>><br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
_______________________________________________<br>
SIS-DTN mailing list<br>
<a href="mailto:SIS-DTN@mailman.ccsds.org">SIS-DTN@mailman.ccsds.org</a><br>
<a href="https://protect2.fireeye.com/v1/url?k=62de3d02-3d45570a-62db4c8c-ac1f6bdccbcc-cd7a61e7db81d855&q=1&e=e8df1ab1-ca9a-403e-8725-23603284ec27&u=https%3A%2F%2Fmailman.ccsds.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fsis-dtn">https://protect2.fireeye.com/v1/url?k=ba7eab5f-e5e5c157-ba7bdad1-ac1f6bdccbcc-e5e5ee1302fcc2a6&q=1&e=240c812c-b72b-4c10-a8ce-bbd260da108e&u=https%3A%2F%2Fmailman.ccsds.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fsis-dtn</a><br>
<br>
<br>
------------------------------<br>
<br>
End of SIS-DTN Digest, Vol 143, Issue 4<br>
***************************************</span><span lang="EN-US"><o:p></o:p></span></p>
</div>
This message is intended only for the recipient(s) named above. It may contain proprietary information and/or protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received this e-mail in error, please notify
the sender immediately. ESA applies appropriate organisational measures to protect personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo@esa.int).
</body>
</html>