[Sis-dtn] LTPv2 Draft Blue Book for Review

Wed May 17 12:07:30 UTC 2023

All,

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:

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

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

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

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

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

  1.  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)
  2.  Suspension of individual sessions (+ we might want to distinguish between stopping to send data segments and pausing timers)

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

  1.  Data Reception Interface: I think the proposed interface meets all the wishes expressed in the emails (block level data delivery and data segment delivery):

     *   ReceptionCompleted.Indication can provide reception map and received data
     *   The optional RangeReceived.indication can provide data from individual segments (I think even chunks of data of continuous segments)

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

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

  2.  I don’t like Simplified Link Reliability Protocol too much (there are other protocols that claim to simple --> see SNMP 😉 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 …).

Regards,
Felix

From: 구철회 <chkoo at kari.re.kr>
Sent: Wednesday, May 17, 2023 6:26 AM
To: Jeremy.Mayer at dlr.de; Felix Flentge <Felix.Flentge at esa.int>
Cc: sis-dtn at mailman.ccsds.org
Subject: RE: [Sis-dtn] LTPv2 Draft Blue Book for Review

Hi, Jeremy.

Yes, that note somewhere in the draft doc would be helpful!!

I have another questions. Please find below questions and comments.

1. Speaking of handling serial number, will the following practices from RFC-5326 be considered in the LTPv2 draft?
From “Checkpoint serial number (SDNV)” part in 3.2.1. Data Segment (DS) of RFC-5326
1) Any subsequent checkpoints issued by the sender MUST have the serial number value found by incrementing the prior checkpoint serial number by 1.
2) The checkpoint serial number MUST NOT be zero.

===================================================

2. How new LTPv2 will treat if it encounters below situations?
* Acronym and Abbreviations
DS : Data Segments
DAR : Data Acknowledgement Request
MA : Metadata Acknowledgement
DA : Data Acknowledgement

1) A sending engine sends DS to a receiving engine. After the sending engine transmits final data segments, it sends an DAR.
Then the receiving engine replies to that request with an MA and an DA. Let’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.
  *Question* How the sending engine will treat this? Retransmit the same DAR?
The sending engine CAN’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.
*TO PREVENT THIS* 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’s serial number as a reference just in case.

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.

Best,
Cheol

From: Jeremy.Mayer at dlr.de<mailto:Jeremy.Mayer at dlr.de> <Jeremy.Mayer at dlr.de<mailto:Jeremy.Mayer at dlr.de>>
Sent: Tuesday, May 16, 2023 5:37 PM
To: 구철회 <chkoo at kari.re.kr<mailto:chkoo at kari.re.kr>>; Felix.Flentge at esa.int<mailto:Felix.Flentge at esa.int>
Cc: sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>
Subject: RE: [Sis-dtn] LTPv2 Draft Blue Book for Review

Hi Cheol,
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.

I’ll add a section describing the “rules” for lengths, since presently it’s sort of non-normative and in an annex.

Thanks,
Jeremy

From: 구철회 <chkoo at kari.re.kr<mailto:chkoo at kari.re.kr>>
Sent: Tuesday, May 16, 2023 10:14 AM
To: Mayer, Jeremy <Jeremy.Mayer at dlr.de<mailto:Jeremy.Mayer at dlr.de>>; Felix.Flentge at esa.int<mailto:Felix.Flentge at esa.int>; ccorsten at gmv.com<mailto:ccorsten at gmv.com>
Cc: sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>
Subject: RE: [Sis-dtn] LTPv2 Draft Blue Book for Review

Hi, Jeremy & Felix.

I have a question about the Serial number in the Extensions header.

During configuration of an extension field, we refer below section for identifying appropriate serial number.
4.2.8.4.3.6     Extension Serial Number
4.2.8.4.3.6.1   The second field within a single entry must be the extension serial number
4.2.8.4.3.6.2   The length of this field (in octets) must be represented by the value of the serial number length field within the extension header.
4.2.8.4.3.6.3   The extension serial number field must be set to the value of a previously-received serial number.

By assuming followings:
1) the serial number will be randomly generated in [1, 2^64-1].
2) and the length of the serial number is variable and in range 1 ~ 8 bytes.

Now, questions
1) Can the length of extension's serial number each LTPv2 segment be different? (It seems current draft says it Yes)
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.

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.

Best,
Cheol

-----Original Message-----
From: 구철회
Sent: Monday, May 15, 2023 4:10 PM
To: 'Jeremy.Mayer at dlr.de' <Jeremy.Mayer at dlr.de<mailto:Jeremy.Mayer at dlr.de>>; 'Felix.Flentge at esa.int' <Felix.Flentge at esa.int<mailto:Felix.Flentge at esa.int>>; 'ccorsten at gmv.com' <ccorsten at gmv.com<mailto:ccorsten at gmv.com>>
Cc: 'sis-dtn at mailman.ccsds.org' <sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>>
Subject: [Sis-dtn] LTPv2 Draft Blue Book for Review

Hi, Jeremy & Felix.

I am reading the draft of LTPv2.
I have found some typos and wrong numbering. Please find the attached document commented by me until Section 5.
And I put some thoughts from me.
Hope this be useful for finalizing the draft document.

Best,
Cheol

----------------------------------------------------------------------

Message: 1
Date: Tue, 9 May 2023 21:47:52 +0000
From: <Jeremy.Mayer at dlr.de<mailto:Jeremy.Mayer at dlr.de>>
To: <sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>>
Cc: <Felix.Flentge at esa.int<mailto:Felix.Flentge at esa.int>>, <ccorsten at gmv.com<mailto:ccorsten at gmv.com>>
Subject: [Sis-dtn] LTPv2 Draft Blue Book for Review
Message-ID: <ce39808e8d454bc6a1b9492a9c3601d6 at dlr.de<mailto:ce39808e8d454bc6a1b9492a9c3601d6 at dlr.de>>
Content-Type: text/plain; charset="utf-8"

Hi everyone,
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.

Thanks,
Jeremy & Felix
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <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<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>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: LTPv2 Blue Book Draft 28.04.2023_for CCSDS Review.doc
Type: application/msword
Size: 446976 bytes
Desc: LTPv2 Blue Book Draft 28.04.2023_for CCSDS Review.doc
URL: <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<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>>

------------------------------

Subject: Digest Footer

_______________________________________________
SIS-DTN mailing list
SIS-DTN at mailman.ccsds.org<mailto:SIS-DTN at mailman.ccsds.org>
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<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>

------------------------------

End of SIS-DTN Digest, Vol 143, Issue 4
***************************************

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/20230517/61719a8f/attachment-0001.htm>