[Sis-dtn] SIS-DTN Telecon Today: LTP Discussion

[Tomaso.deCola at dlr.de]

Hi Keith, DTNers,

Just some additional considerations after digesting yesterday meeting considerations:

  *   Wish to keep green standalone blocks (i.e., by removing the mixed colour way currently supported in LTP spec). Apart from specific mission requirements that agencies may want to provide here, I see the following points of some value:
     *   Space unidirectional links prone to error could benefit from erasure coding implementation. In this case, erasure codes could be combined to green blocks. Applying erasure coding directly to encap packets might theoretically still also be possible, but in my view a bit less effective since encap packets might have to merged together to have the minimum encoding block size and splitting it into segments for the encoding part. These latter functions are already in my opinion intrinsically available with LTP.
     *   If we prefer to “replace” green blocks operation with BP running directly on top of encap, we have to pay attention on the case of large bundle (say few MB) which would be mapped directly into encap packets. In the case some of the transfer frames in which encap packets are transmitted got lost, it can be that an entire encap packet will be also dropped. When the same happens in the case of green block, we may lose a single LTP segment, with limited degradation to overall reception of info at application (provided that the application is still able to take advantage of what received even when some data is missing)
  *   Green block segments “interleaving”. Agreed the fact that the term interleaving is misleading and that we don’t need to specify this in the book, I’m wondering whether this is something really needed also at implementation level given the fact that different priorities could be directly managed at datalink level by means of different VCs (for example).
  *   Extension header. As already recorded during the Fall meetings, I agree that whatever additional information of use from consumers external to the LTP core could simply transported in dedicated (maybe small) LTP blocks. But what if someone wants to develop (e.g., for some specific missions or experimentation) some LTP protocol updates requiring some signalling (i.e., transported somehow in the header)? In that case I think having an extension header could be of value. Moreover if we want to retain the security extensions (RFC5327), the extension header must be there.

My 0.02 cents to the discussion

Best Regards,

Tomaso

From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org> On Behalf Of Dr. Keith L Scott
Sent: Mittwoch, 10. Februar 2021 16:13
To: sis-dtn at mailman.ccsds.org
Subject: [Sis-dtn] SIS-DTN Telecon Today: LTP Discussion

All,

I’d like to continue our LTP discussion from the Fall meetings and start working towards nailing down the set of changes we’d like to make.  To that end, I’ve collected the proposed changes from October into the attached spreadsheet.  What I’d like to do today is to run through this, figure out what I’ve left out, and start building consensus around particular choices.  We can iterate these discussions over email, and I’d LIKE to get most / all of them nailed down by the next meetings in May.

                        v/r,

                        --keith

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20210211/3edf7a64/attachment.htm>