[Sis-dtn] LTPv2 Draft Blue Book for Review

[Sipos, Brian J.]

Jeremy, Felix,

I think there is a lot of improvement in both encoding and state machine for
this new protocol draft, while keeping with the capabilities and rough
service interface of earlier LTP. I'm attaching a document with inline
comments for specific sections and paragraphs. Two areas that I think are
underspecified currently are session invariants/state and the underlying
transport requirements/assumptions.

 

An explanation of session invariants would be redundant, but I think helpful
to an implementer to understand which parameters are associated with an
individual session, are unchanging between all segments within a session,
and for a receiver are memorized when first received. As a follow-on it
would be good to indicate how a receiver should respond if a segment comes
in that violates that invariant; does that session get ignored from that
point on, canceled with in-band messaging, or something more severe like
stop processing all segments from that sender (I don't recommend this but
some specific guidance would bound an engine behavior). 

Also in earlier LTP implementations there is the possibility of pausing a
session (by simply pausing all timers associated with the session and
stopping any transmit of new/queued segments for that session); is this
behavior useful enough to include in the official LTP engine service
interface? It seems straightforward enough to be an optional indication to
the engine to pause/un-pause a session.

 

The parts missing from specification of the underlying transport interface
are comments in the document, but generally it is good to be explicit about
what is required and what is assumed about the transport. This helps in two
ways: it makes it more obvious to an implementer about what must be added as
glue between what the upper protocol requires and the lower transport
provides, and it also makes it obvious when a specific transport is just
inappropriate and to not try to use it. For example, earlier LTP had a few
assumptions about in-order segment delivery (some workarounds are possible
within the protocol requirements) which would make it unsuitable or
vulnerable DoS if used over IP. These kinds of things are not necessarily
bad, just need to be known to the implementer rather than assumed and
unstated.

 

Earlier issues reported to HDTN project related to out-of-order reception
are linked below. Issue #22 and #24 are both optimizations to allow an
engine to delay sending report or data retransmit segments long enough to
receive any out-of-order segments that would affect the report claims or
avoid the retransmit entirely. Issue #23 is about when to send an
"asynchronous reception report" which is defined by LTP but never specified
when an engine would actually send one. Issue #19 is another unspecified
behavior that (could, and in HDTN case did) allow a memory leak and provide
a method of denial-of-service attack.

https://github.com/nasa/HDTN/issues/24

https://github.com/nasa/HDTN/issues/23

https://github.com/nasa/HDTN/issues/22

https://github.com/nasa/HDTN/issues/19

 

On the topic of the overlayer service interface for unreliable data, I am
strongly in favor of the current interface where the LTP engine provides the
entire block data with a reception map. It is much more useful from an
overlayer/BPA perspective to have both TX and RX interfaces operate at the
scale of entire blocks (i.e. "block goes in to TX, block comes out of RX").
Since any overlayer will need to reassemble segments and include a reception
timeout anyway, it's better for that logic to be as close to the segment
processing as possible (in the LTP engine) and not need to be re-implemented
with every use of the engine. This is especially true as unreliable timeout
presents a possible DoS attack vector.

 

Finally, regardless of whatever name applies to this new protocol it would
be helpful to explicitly state that it is on-the-wire unique from earlier
LTP and can be used over the same transport as LTP and segments can be
handled unambiguously from LTP segments. This will allow re-use of existing
allocation such as the LTP UDP Port
<https://www.iana.org/assignments/service-names-port-numbers/service-names-p
ort-numbers.xhtml?search=1113>  and similar service identifiers.

 

Thanks for all of the effort in designing and documenting this.

Brian S.

 

From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org> On Behalf Of Jeremy Mayer
via SIS-DTN
Sent: Tuesday, May 9, 2023 5:48 PM
To: sis-dtn at mailman.ccsds.org
Cc: ccorsten at gmv.com
Subject: [EXT] [Sis-dtn] LTPv2 Draft Blue Book for Review

 


APL external email warning: Verify sender sis-dtn-bounces at mailman.ccsds.org
<mailto:sis-dtn-bounces at mailman.ccsds.org>  before clicking links or
attachments

 

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: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20230515/b15f0cf6/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: LTPv2 Blue Book Draft 28.04.2023 Sipos comments.doc
Type: application/msword
Size: 435200 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20230515/b15f0cf6/attachment-0001.doc>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6603 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20230515/b15f0cf6/attachment-0001.bin>