<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:"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;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:14354178;
mso-list-type:hybrid;
mso-list-template-ids:-771062294 134807569 134807577 134807579 134807567 134807577 134807579 134807567 134807577 134807579;}
@list l0:level1
{mso-level-text:"%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0: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="#0563C1" vlink="#954F72" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Looks good to me.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Two remarks:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="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-list:l0 level1 lfo1"><span style="mso-fareast-language:EN-US">I would add something about the service data aggregation:<o:p></o:p></span></li></ol>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="mso-fareast-language:EN-US">LTP Service Data Aggregation allows to concatenate several LTP blocks into a single LTP block by concatenating SDA Client Data Capsule. These consist of a single SDNV contain
the LTP client service ID and the complete client data unit as passed to SDA. However, no generic way to determine the length of the client data unit at the receiving side is specified, this mechanism is not interoperable unless additional agreements on the
structure or the exact types of client data and their respective client service IDs are agreed. It is expected that Service Data Aggregation will be removed from LTPv2 and that eventual aggregation shall be performed by upper layers if deemed necessary.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="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-list:l0 level1 lfo1"><span style="mso-fareast-language:EN-US">We need to discuss the service interface for unreliable data delivery. We currently propose to have block-level granularity for unreliable
sessions as well and I see advantages in certain scenario (and it would harmonise unreliable / reliable service data delivery). I understand there is a concern regarding keeping state information for unreliable session. However, I am not sure whether I fully
understand the use case for unreliable LTP with only segment delivery.<br>
One thing we could also consider, is to have optional segment delivery indications for reliable and unreliable sessions (similar to CFDP File Segment Received indications).<o:p></o:p></span></li></ol>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal">Regards,<o:p></o:p></p>
<p class="MsoNormal">Felix<o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><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" style="margin-left:36.0pt"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> SIS-DTN <sis-dtn-bounces@mailman.ccsds.org>
<b>On Behalf Of </b>Keith Scott via SIS-DTN<br>
<b>Sent:</b> 11 May 2023 10:41<br>
<b>To:</b> sis-dtn@mailman.ccsds.org<br>
<b>Cc:</b> Leigh Torgerson <Jordan.L.Torgerson@jpl.nasa.gov><br>
<b>Subject:</b> [Sis-dtn] Draft text for an LTP corrigendum<o:p></o:p></span></p>
</div>
<p class="MsoNormal" style="margin-left:36.0pt"><o:p> </o:p></p>
<div>
<p class="MsoNormal" style="margin-left:36.0pt">Possible items for an LTP corrigendum.<br>
<br>
<br>
1. LTPv2 (LTP-Next-Generation (LTP-ng))<br>
<br>
LTP was designed to be highly bit-efficient; part of the design includes the use of self-delimiting numeric values (SDNVs) in some of the protocol fields. While this allows LTP to maintain bit efficiency over a wide range of operational environments (e.g.
when sending different sized LTP blocks), it results in headers where the size MAY vary from segment to segment and that require parsing multiple SDNVs. This makes it difficult to implement LTP in high-speed environments where the LTP processing is moved
to field programmable gate arrays (FPGAs).<br>
<br>
To address the performance issues at high rates, CCSDS is developing another optionally-reliable link layer shim that provides many of the same features as LTP but using a header format that allows for the determination of all of the field sizes by reading
a single byte in the header. This implementation facilitates high-speed implementations by allowing receivers to quickly identify the size of the LTP header and the offsets of *all* fields within it. The new protocol also simplifies the original LTP in a
number of ways, such as:<br>
- reducing the number of block types and moving much of the link signaling to extensions<br>
- the removal of mixed-color blocks (blocks that contain a mix of reliable and unreliable data in a single block);<br>
- the removal of LTP security (with missions recommended to use some combination of link-layer and network security instead)<br>
- the removal of trailer extensions<br>
<br>
The new protocol, while well-suited to high-rate operations, is also as applicable as the existing LTP protocol to bandwidth-constrained missions (1), and new missions are encouraged to consider the newer protocol when it becomes available.<br>
<br>
<br>
2. Note on Session Closure and Removal of Session Information<br>
The state associated with an LTP session should be removed by the receiver when the report confirming reception of the red-part has been acknowledged. In particular, if the block also contains green-part data, no persistent state information should be kept
once the report reporting reception of the red part has been acknowledged. This is necessary because the End-of-Block (EOB) marker will fall on a Green segment and hence will be unreliable. If the EOB marker is lost and the receiver still has reception state
for the session, there will be no protocol mechanisms to clear that state.<br>
<br>
<br>
3. Clarification on Reception of Green-Part Data<br>
Green-part data reception should be stateless at the receiver. Green-part segments should be delivered to the LTP client at the earliest opportunity and in particular there should be no persistent state associated with a Green LTP session (or the Green part
of a mixed-color session, as above).<br>
<br>
<br>
4. Kiyo had a description of a session closure issue with the state machine. We should say something about that. I think it was that once the sender sent the report acknowledgement for the report covering the entire block that the sender would then close
the session. If the report acknowledgement is lost, the receiver will retransmit the report but the sender, on receiving the report segment, will not have an extant session to match it to and will ignore it. The receiver will thus continue to emit report
segments until it runs out of retransmission attempts. [Kiyo: was it this or something else?] I don't think we can propose a normative fix for this without reopening the book and doing interoperability testing (which I don't think we want), but we might
suggest that implementations do something like keep enough information from terminated sessions (for a while) to respond to such events.<br>
<br>
<br>
-------------------------<br>
(1) It'd be nice to have some data about the total amount of overhead to send blocks of sizes (100, 1000, ...) to throw in here.<o:p></o:p></p>
</div>
</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>