[Sis-dtn] [EXTERNAL] RE: New version of LTP Corrigendum

Tue May 30 06:47:08 UTC 2023

Hi Leigh,

Yes, we also have systematic out-of-order in EO or L2 missions as different physical channels may be used (with maybe different rates and different PDU sizes). With 'implementation issue' I don't mean that it is not important but I would like to avoid making it normative as we want to avoid 'changing the standard' which would require interop testing.

By any means, we should have a statement that in case you may have out-of-order delivery it is recommended to implement timer to wait for out-of-order segments to avoid re-transmission (we will add a similar statement to CFDP for the next release).

Regards,
Felix

From: Torgerson, J. Leigh (US 332C) <jordan.l.torgerson at jpl.nasa.gov>
Sent: Thursday, May 25, 2023 6:22 PM
To: Felix Flentge <Felix.Flentge at esa.int>; sburleig.sb at gmail.com; Sanchez Net, Marc (US 332H) <marc.sanchez.net at jpl.nasa.gov>; 'Dr. Keith L Scott via SIS-DTN' <sis-dtn at mailman.ccsds.org>
Cc: Gao, Jay L (US 332C) <jay.l.gao at jpl.nasa.gov>; Richard, Nate J (US 332C) <nathaniel.j.richard at jpl.nasa.gov>
Subject: Re: [EXTERNAL] RE: [Sis-dtn] New version of LTP Corrigendum

Thanks Felix -

One comment is that in deep space use of DTN, we would expect that out-of-order delivery would be the rule, rather than the exception - if it takes 40 min RTT to recover a missing segment from Mars, waiting for it to ensure in-order delivery to some application would make ops impossible. (One must design one's applications to be "aware" of the operational environment of course..)

We haven't used both LTP red/green at the same time in our testing and real-world ops as far as I know, but I suspect that recommending that red and green be in different sessions would be a good idea, if nothing else but to make troubleshooting easier!  (Nate and Jay may have some thoughts based on our lunar ops with KPLO so I cc:d them..)

regards
Leigh

From: Felix Flentge <Felix.Flentge at esa.int<mailto:Felix.Flentge at esa.int>>
Date: Thursday, May 25, 2023 at 4:56 AM
To: "sburleig.sb at gmail.com<mailto:sburleig.sb at gmail.com>" <sburleig.sb at gmail.com<mailto:sburleig.sb at gmail.com>>, "Sanchez Net, Marc (US 332H)" <marc.sanchez.net at jpl.nasa.gov<mailto:marc.sanchez.net at jpl.nasa.gov>>, "'Dr. Keith L Scott via SIS-DTN'" <sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>>
Cc: "Torgerson, Jordan L (332M)" <jordan.l.torgerson at jpl.nasa.gov<mailto:jordan.l.torgerson at jpl.nasa.gov>>
Subject: [EXTERNAL] RE: [Sis-dtn] New version of LTP Corrigendum

Hi,

I agree with the modifications below.

Some additional points:

*         I would propose to also deprecate Service Data Aggregation (it is currently mandatory). Unless, I am overlooking something, it is not an interoperable mechanism as there is no generic way to determine the length of a client data capsule. Also, for BP/LTP the updated BP standard will describe an aggregation mechanism (CBOR length information + bundle IIRC).

*         Should we discourage use of mixed sessions (on the other hand LTP green is optional anyway)?

*         For the two additional issues, we could add that this is an implementation issue and that implementation may want to introduce these additional timers in case they (routinely) expect out-of-order delivery

Regards,
Felix

From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org<mailto:sis-dtn-bounces at mailman.ccsds.org>> On Behalf Of sburleig.sb--- via SIS-DTN
Sent: Thursday, May 18, 2023 1:23 AM
To: 'Sanchez Net, Marc (US 332H)' <marc.sanchez.net at jpl.nasa.gov<mailto:marc.sanchez.net at jpl.nasa.gov>>; 'Dr. Keith L Scott via SIS-DTN' <sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>>
Cc: 'Torgerson, J. Leigh (US 332C)' <jordan.l.torgerson at jpl.nasa.gov<mailto:jordan.l.torgerson at jpl.nasa.gov>>
Subject: Re: [Sis-dtn] New version of LTP Corrigendum

Marc, FWIW, I agree about deprecating LTP security and I am likewise skeptical that adding more timers is a good idea; that sounds like a way to work around a design element that hasn't been thought through completely.

Scott

From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org<mailto:sis-dtn-bounces at mailman.ccsds.org>> On Behalf Of Sanchez Net, Marc (US 332H) via SIS-DTN
Sent: Tuesday, May 16, 2023 7:05 PM
To: Dr. Keith L Scott via SIS-DTN <sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>>
Cc: Torgerson, J. Leigh (US 332C) <jordan.l.torgerson at jpl.nasa.gov<mailto:jordan.l.torgerson at jpl.nasa.gov>>
Subject: [Sis-dtn] New version of LTP Corrigendum

All,

Please find attached a new version of the LTP corrigendum with some modifications including:
*         Comparison between LTP and "the new protocol" has been reduced. This in part motivated by the fact that we have demonstrated ~4 Gbps rates with ION's LTP implementation, which is more than sufficient for deep space links (e.g., even in future trunk lines between Earth and Mars, data rates of 4 Gbps are never exceeded).
*         I have added two possible additions to the technical corrigendum based on work done by Brian and people at GRC. They are all optional (MAY) statements and I believe can be implemented without additional managed parameters (and timers).
*         Brian has commented on two additional issues (see here<https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/22__;!!PvBDto6Hs4WbVuu7!J3wEpyPHlAiGcXO0VDc8uO1zb9BOrpYLw3dw6BHPigpmcy0Q4f8gxX6hHLnQOqg_AVxEg_MYrByNRr1urhAp-KViTuP33vk9LEw4$> and here<https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/24__;!!PvBDto6Hs4WbVuu7!J3wEpyPHlAiGcXO0VDc8uO1zb9BOrpYLw3dw6BHPigpmcy0Q4f8gxX6hHLnQOqg_AVxEg_MYrByNRr1urhAp-KViTuP33uBoiHHY$>), but those seem to require additional timers that would need to be managed, so I am unconvinced it is worth the extra complexity. Brian, please correct me if I am wrong.
Finally, I think the note at the beginning of Section 3.9 of the current CCSDS LTP spec should be modified to explicitly state that LTP security should not be used and, instead, implementers should rely on security mechanisms provided by other parts of the CCSDS protocol stack, be it SDLS or BPSec. Thoughts on this point?

[https://opengraph.githubassets.com/20650d8341084e048ce0b347834a0c8d441c40acab81b1ef4c075e8770078d33/nasa/HDTN/issues/24]<https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/24__;!!PvBDto6Hs4WbVuu7!J3wEpyPHlAiGcXO0VDc8uO1zb9BOrpYLw3dw6BHPigpmcy0Q4f8gxX6hHLnQOqg_AVxEg_MYrByNRr1urhAp-KViTuP33uBoiHHY$>
Defer data retransmission with out-of-order report segments * Issue #24 * nasa/HDTN<https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/24__;!!PvBDto6Hs4WbVuu7!J3wEpyPHlAiGcXO0VDc8uO1zb9BOrpYLw3dw6BHPigpmcy0Q4f8gxX6hHLnQOqg_AVxEg_MYrByNRr1urhAp-KViTuP33uBoiHHY$>
When the network is causing out-of-order segment reception it is possible that one or more synchronous reception reports are received either out-of-order or within a short time window, possibly fol...
github.com
[https://opengraph.githubassets.com/557790465f865a493213b66289d08ffd17c4b98d48ae91ec6ef62866fa1ceac9/nasa/HDTN/issues/22]<https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/22__;!!PvBDto6Hs4WbVuu7!J3wEpyPHlAiGcXO0VDc8uO1zb9BOrpYLw3dw6BHPigpmcy0Q4f8gxX6hHLnQOqg_AVxEg_MYrByNRr1urhAp-KViTuP33vk9LEw4$>
Defer synchronous reception report with out-of-order data segments * Issue #22 * nasa/HDTN<https://urldefense.us/v3/__https:/github.com/nasa/HDTN/issues/22__;!!PvBDto6Hs4WbVuu7!J3wEpyPHlAiGcXO0VDc8uO1zb9BOrpYLw3dw6BHPigpmcy0Q4f8gxX6hHLnQOqg_AVxEg_MYrByNRr1urhAp-KViTuP33vk9LEw4$>
When red part data is segmented and delivered to the receiving engine out-of-order, the checkpoint(s) and EORP can be received before the earlier-in-block data segments. If a synchronous report is ...
github.com

Thanks,
-----------------------------------------------------------------------------------------------------------------------
Marc Sanchez Net (332H)
Telecommunications Engineer
Jet Propulsion Laboratory
Cell: (617) 953-7977<mailto:(617)%20953-7977> | Email: marc.sanchez.net at jpl.nasa.gov<mailto:marc.sanchez.net at jpl.nasa.gov>
-----------------------------------------------------------------------------------------------------------------------

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<mailto:dpo at esa.int>).
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/20230530/02832d0e/attachment-0001.htm>