[Sis-dtn] Notes from the NASA DTN F2F Meeting

[sburleig.sb at gmail.com]

Marc, thanks for sending this on.  A couple of thoughts in-line below.

 

Scott

 

From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org> On Behalf Of Sanchez Net,
Marc (US 332H) via SIS-DTN
Sent: Monday, February 13, 2023 9:10 AM
To: sis-dtn at mailman.ccsds.org
Subject: [Sis-dtn] Notes from the NASA DTN F2F Meeting

 

Hi All,

 

Here are the notes/questions for the SIS-DTN WG that I recorded at the NASA
DTN face-to-face meeting.

 

*	BPv7

*	Leigh Torgerson pointed out that in the assumptions of the proposed
RTP book there is the following statement: "arbitrary bundle sizes-the
multicast mechanism must not impose arbitrary limits that are less than the
maximum bundle size on the size of bundles.". The question then becomes
whether having a bundle size (10 MB) in the spec restricts other
specifications in any way.
*	Should we add a requirement (maybe a "should" rather than a "shall")
for CLAs to notify BP when transmission with that CLA is possible? This
would provide minimal indication of whether transmission via a CLA is
possible.

*	Would this be a requirement that implementations would have to
satisfy in order to be considered BPv7 compliant?  Isn't it strictly an
implementation consideration?  How would it contribute to interoperability?

*	Compressed Bundle Reporting:

*	How that CBR handle bundle fragmentation?

*	I would think that fragmentary bundles are simply bundles; they
should be reported to the nodes that created them, that is, the nodes that
generated the fragments.

*	Why do we need CBR to define a new extension block with the FSN and
flow sequence? PACE is using the service numbers in the transmit EID as the
FSN, so they are able to uniquely identify flows and bundles within the flow
without having an extension block.
*	Should we have a dedicated reporting mechanism for bundle
expiration?
*	Can we make bundle reporting extensible so that missions have the
ability to have their reporting reasons?

*	LTPv2

*	Will LTPv2 have a way to signal to the receiver the size of the LTP
block? This would facilitate memory allocation at the receiver.
*	Will LTPv2 have a "hook" to get notified when the underlying link is
down. This can be used to pause timers, etc.
*	Will LTPv2 have a way to aggregate report segments and report
segment acknowledgements to reduce overhead?
*	Will LTPv2 have a ping mechanism for the tx/rx engines to assess
whether the link is running?
*	Will LTPv2 have a concept of transmission deadline, which causes the
tx to stop sending a block if it is not available at the destination by a
certain moment? This could be used in conjunction with the bundle lifetime
to cancel LTPv2 sessions proactively.
*	APL has reported the following issues related to LTP that we way
want to consider in LTPv2

*	Unspecified behavior that allows a memory leak and provide a method
of denial-of-service attack. See https://github.com/nasa/HDTN/issues/19
*	LTP should guarantee that a reception report is sent when all data
is received, not necessarily in response to a checkpoint. See
https://github.com/nasa/HDTN/issues/23 
*	LTP should allow the transmit engine to delay sending data segments
or reports long enough to receive out-of-order segments that would affect
the retransmission behavior. See https://github.com/nasa/HDTN/issues/22 and
https://github.com/nasa/HDTN/issues/24. 

*	Others wishes from the community

*	DTN multicast
*	Provide mechanisms for in-order delivery, lack of gaps, and lack of
duplicates (similar to DTPC, but more modular, any possibly not end-to-end)

*	Having more options on the DTPC feature menu has been an open item
for many years.  DTPC is just a prototocol that ought to be stackable like
any other protocol.  If the DTPC spec says that the layer above it can only
be the end-to-end user application, then the spec should be revised.

*	Standard CCSDS format for contact plans
*	DNS-like service to avoid having to manually rely on IANA/SANA
registries.
*	Stream of video/voice via DTN. KPLO used a non-standard version of
BSSP and yet SIS-MIA might be working on RTP over DTN.

 

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/20230213/1a087c88/attachment-0001.htm>