[Sis-dtn] Draft text for an LTP corrigendum

[Felix Flentge]

Looks good to me.

Two remarks:


  1.  I would add something about the service data aggregation:
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.


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


Regards,
Felix

From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org> On Behalf Of Keith Scott via SIS-DTN
Sent: 11 May 2023 10:41
To: sis-dtn at mailman.ccsds.org
Cc: Leigh Torgerson <Jordan.L.Torgerson at jpl.nasa.gov>
Subject: [Sis-dtn] Draft text for an LTP corrigendum

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.
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 at esa.int).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20230511/7c6d8bf1/attachment-0001.htm>