[Sis-dtn] LTPv2 Draft Blue Book for Review

Wed May 17 04:26:14 UTC 2023

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 <Jeremy.Mayer at dlr.de>
Sent: Tuesday, May 16, 2023 5:37 PM
To: 구철회 <chkoo at kari.re.kr>; Felix.Flentge at esa.int
Cc: 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
***************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20230517/d083b593/attachment-0001.htm>