<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:0in;
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;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></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-US link="#0563C1" vlink="#954F72" style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal>I like all of these. A note on (4): I don’t recall when this first came up, but it is a real issue. I think it falls in the category of implementation advice rather than protocol specification, though, as I don’t think it’s an interoperability concern. ION has got a compile-time option (CLOSED_EXPORTS_ENABLED) that addresses it, but that option is turned off by default.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Scott<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b>From:</b> SIS-DTN <sis-dtn-bounces@mailman.ccsds.org> <b>On Behalf Of </b>Keith Scott via SIS-DTN<br><b>Sent:</b> Thursday, May 11, 2023 1:41 AM<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></p></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>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></body></html>