[Sis-dtn] New version of LTP Corrigendum

[sburleig.sb at gmail.com]

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> 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>
Cc: Torgerson, J. Leigh (US 332C) <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://github.com/nasa/HDTN/issues/22>  and here
<https://github.com/nasa/HDTN/issues/24> ), 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://github.com/nasa/HDTN/issues/24> 

 <https://github.com/nasa/HDTN/issues/24> Defer data retransmission with
out-of-order report segments . Issue #24 . nasa/HDTN

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://github.com/nasa/HDTN/issues/22> 

 <https://github.com/nasa/HDTN/issues/22> Defer synchronous reception report
with out-of-order data segments . Issue #22 . nasa/HDTN

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:
<mailto:marc.sanchez.net at jpl.nasa.gov> marc.sanchez.net at jpl.nasa.gov

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

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20230517/68c99d47/attachment.htm>