[Sis-dtn] Draft text for an LTP corrigendum

[Keith Scott]

Possible items for an LTP corrigendum.


1. LTPv2 (LTP-Next-Generation (LTP-ng))

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

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:
    - reducing the number of block types and moving much of the link
signaling to extensions
    - the removal of mixed-color blocks (blocks that contain a mix of
reliable and unreliable data in a single block);
    - the removal of LTP security (with missions recommended to use some
combination of link-layer and network security instead)
    - the removal of trailer extensions

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.


2. Note on Session Closure and Removal of Session Information
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.


3. Clarification on Reception of Green-Part Data
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).


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.


-------------------------
(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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20230511/0b8b69a1/attachment.htm>