[Sis-dtn] [dtn] Re: Bundle Transfer Protocol - Unidirectional

[Felix Flentge]

Well,

Before complaining (😉) I have a few questions/comments (in particular, looking at this from a CCSDS point of view):


  1.  Regarding the use case of ‘unidirectional transfer of large binary objects, typically Bundle Protocol version 7 bundles, between two nodes connected by a unidirectional, unreliable, frame-based link-layer protocol, without requiring IP services’:
     *   This already seems to be addressed by Encapsulation Packet Protocol (https://public.ccsds.org/Pubs/133x1b3e1.pdf) and Space Packet Protocol (https://public.ccsds.org/Pubs/133x0b2e2.pdf); both work perfectly fine on uni-directional links and are fully compatible with all CCSDS Space Data Link Protocols and Space Data Link Security Protocol. Use of SPP over uni-directional links for payload downlink is common practice for all ESA Earth Observation missions (though, no BP yet). Reliability is typically addressed closer to the physical layer (coding & modulation) or at a higher layer (CFDP, LTP).
     *   High-Performance Reliability Protocol does also include an unreliable mode for uni-directional links and is fully compatible with CCSDS Packet and Frame layers.

So, my questions is why these protocols are not adequate for this use case?

  1.  Regarding ‘...supports data repetition as a mechanism to protect against data loss’:
In space communication we typically try to address reliability at coding and modulation layer (where we can better adapt to the specific link characteristics). Simple repetition does not seem to be a very efficient way. It is sometimes done in spacecraft emergencies (‘hammering mode’) but for routine operations, I believe we can do better (increased coding or re-transmission protocol).
  2.  Regarding ‘... supports the disaggregation of flows of bundles of different priority, preventing head-of-line blocking impacting performance.’
Priorities can be implemented on different levels; for me it makes definitely sense to have it at BP level as this can be universal across convergence layers; for CCSDS Space Data Links, it can be based on Virtual Channels; not sure if there is something required in addition but if so, we should try to describe the relation between these priorities at different layers.
  3.  EPP/SPP provide the functionality to go from variable-size large data structure to fixed length data structures (HPRP/LTP as well). In addition to padding (via insertion of idle packets), they also allow for aggregation in case there is ‘space left’ in a frame. This is much more efficient then padding. I would assume that the same mechanism (packet service) could be used with BTPU when running over CCSDS Space Data Link Protocols.
  4.  Sequence numbering is provided on CCSDS Space Data Link layer (and I would think also for other frame layer protocols); I am not sure whether an additional segment level sequence numbering is required.
  5.  Cancelling of transfer seems possible for EPP/SPP over CCSDS SDLP by just starting with the next packet (the previous packet is just incomplete but as re-assembly is based on First Header pointer and not length information this is fine).
  6.  BPTU-FEC extension: the topic of Forward Error Correction at higher protocol layers comes up from time-to-time; I currently fail to see the advantages compared to FEC we do at coding & modulation close to the physical layer which seems much more targeted to the specific link. To me, it seems also violating the layering principle a bit (I assume for defining a FEC at a higher level you need to make some assumptions on the lower layer).
  7.  What may be missing at CCSDS (TBC) may be the ‘interleaving’ of transfers. However, I am not sure whether this would justify an additional protocol. I don’t see strong use cases (I think this can typically be addressed by sizing the data blocks to be transmitted to sizes adequate for the available data rates + maybe  VC multiplexing).The distinction between emission and transmission is very useful. However, this whole topic could be quite complex as we would need to consider different on-board architectures (Mass-memory units, on-board busses, buffers in terminals).
  8.  Overall, EPP seems to cover at least some of the functionality, it is well specified, fully compatible with the CCSDS stack, baselined for LunaNet and seems less complex then BTPU. EPP does not require the management of multiple transfers or different message types, so seems to be quite straight-forward to be implemented in hardware at high data rates.
  9.  Summary (sorry, I may have ended up complaining): I currently don’t see a clear use case (at CCSDS) for another protocol doing partially what we can already do with EPP (or SPP for smaller bundles and HPRP in the future if we also want to have a re-transmission option in case we have a bi-directional link). I would propose more of an ‘Adopt – Adapt – Improve’ approach. I am also slightly concerned about the mixing of functions (segmentation, data repetition, priorisation, maybe FEC) which might be better addressed separately (or are also addressed at other layers).

Regards,
Felix

From: Rick Taylor <rick at tropicalstormsoftware.com>
Sent: 12 March 2025 10:12
To: sburleig.sb at gmail.com; dtn at ietf.org; ''Robert C Durst'' <durst at mitre.org>
Subject: [dtn] Re: Bundle Transfer Protocol - Unidirectional

Hi Scott,

Thank you so much for the thorough review!  Comments inline marked with [RT] because Outlook is dumb.

________________________________
From: sburleig.sb at gmail.com<mailto:sburleig.sb at gmail.com> [sburleig.sb at gmail.com]
Sent: 11 March 2025 18:55
To: Rick Taylor; dtn at ietf.org<mailto:dtn at ietf.org>; ''Robert C Durst''
Subject: RE: [dtn] Bundle Transfer Protocol - Unidirectional
Hi, Rick.  I think this is draft is terrific, filling what we are now recognizing as a gaping hole in the DTN architecture.

[RT]. Thanks, that was my considered opinion.  I believe the ability to move bundles without the need of a full IP stack is particularly useful in 'space relay' use-cases.

 I have a few comments:

·       It dawns on me that BTPU is functionally a replacement for the “green” procedures that were built into LTP, only much more capable.  In that sense, it seems to me arguable that BTPU should be taken up in CCSDS rather than in IETF; I am very glad to see it here, but I can imagine somebody might complain.

[RT]. Yes, if you squint it can look a lot like 'green LTP' and also UDPCL without some of the bidirectional features.  I'm not claiming original thought here, just a distillation of all the good work that has gone before.  I've pushed the draft to IETF first, because: a) I'm more familiar with the process in IETF; and b) It directly links to RFC9171 and friends.  However, I can see BTPU-AOS or BTPU-TM being CCSDS docs, much like BTPU-Ethernet and BTPU-DVB might be better in IEEE, and BTPU-5G might be better in 3GPP.  But I only have so much SDO conference attendance budget ;)


·       In the context of DTN, BTPU is – again, like LTP – a convergence-layer protocol.  A brief rant on DTN terminology:

o   We call protocols like TCP, LTP, UDP, etc. “convergence-layer protocols” and we recognize that these protocols have independent existence.

o   So we have to define “convergence-layer adapters” (CLAs) that have specifications of their own, explaining how bundles are encapsulated in the protocol data units of these convergence-layer protocols.  (In reality, I would say that when we use the term “convergence layer” we really mean the entire stack of protocols underneath a given CLA.  The CLA only interacts directly with the topmost protocol in that stack, but if we want to say that the convergence layer enables transmission of bundles then we have got to mean that whole underlying stack.)

o   This implies that we are going to need a CLA specification for BTPU, in addition to the BTPU specification itself.  A very simple one, I think.

[RT] Agreed.  BTPU is a convergence layer protocol, not an adaptor, and there is a missing interface specification for a CLA.  I've had similar conversations with Brian Sipos on this omission.  The IETF doesn't usually standardise interfaces or APIs (unlike 3GPP or CCSDS) but if/when we update RFC4838, I think it is worth adding some text about the role and responsibilities of a CL Adaptor would help clarify the architecture as a whole.  I will rework the introduction sections to be more obvious on the difference.


·       Why is it necessary to use the term “bundle” to refer to the large binary objects transferred by this protocol?  “Bundle” has been formally defined in RFCs for many years; I don’t see any advantage in discarding that definition.  Why not instead say something like “parcel” (apologies to Fred Templin) or maybe “blob” (less elegant, but precise and with a long history of prior use)?

[RT]. Bundle is here simply because I was thinking bundles when I started typing, and 'Bundle' is in the title.  You are of course correct, the transfer payload is just a Blob.  I will avoid 'parcel' as it is a whole new term that needs introducing.  I need to rework the whole section around "The protocol transfers blobs, and the protocol is designed for bundles as blobs, but the distinction is technically unnecessary".  I also have a personal dislike of 'ADU' as it implies some contract with the 'application' which isn't necessary.


·       For me, maybe the most exciting aspect of the draft is the prospect of using BTPU to enable interoperation between BPv6 and BPv7 (more precisely, between a node that speaks both BPv6 and BPv7 and another node that speaks only one or the other).  I think this solves one of the most vexing problems that DTNWG has to grapple with – much better than trying to use BIBE (yet another convergence-layer protocol) for this purpose.

[RT] I'm so pleased you agree.  If you look through the history of my wandering correspondence on this list, you might spot a trend highlighting my vexation with this problem, and I hope this goes towards addressing it.


·       Just to amplify the note on BTPU segmentation versus BP fragmentation in section 3: the advantage of BP fragmentation is that it enables different fragments of a bundle to be forwarded on different paths.  That feature is orthogonal to what BTPU does (there’s no path multiplicity), so I see the two mechanisms as nicely complementary.

[RT]. Absolutely agree.  The concepts are intentionally orthogonal, and are designed to solve entirely different problems.  Segmentation is purely to address 'head-of-line blocking' and one-hop MTU restrictions.  The counter is also true: I have long felt that using Bundle Fragmentation to solve MTU issues is the wrong tool for the job.


·       I like the prioritization discussed in section 3, but can Transfer prioritization safely be left up to the application?  Transfers with different sources and/or destinations can be multiplexed on the same BTPU channel, correct?  As I recall, the reason Class of Service was omitted from BPv7 was that there was no defense against greedy applications that could assert that all of their bundles were high-priority.  Would it be better to have some sort of traffic label that BTPU senders could map to priority according to managed rules in configuration?

[RT] I see prioritisation as a BPA-layer function, beyond the scope of the protocol.  However, CL protocols should support transferring bundles of different priority efficiently.  I can imagine a simple `send(const uint8_t* blob, unsigned int priority)` API function being exposed to the BPA.  How the BPA chooses the priority value is up to the BPA layer.  Thinking about the BPA-layer: how application bundles are assigned priorities is a policy function of the BPA and deployment, not an application or CL responsibility in my opinion.


·       Excellent introduction of the clarifying term “emit” here.

[RT] Thank academia for this.  I strongly believe in cases like this that there is a difference between creating byte sequences and transmitting the created sequence, and clarity is vital.  In the same way there is a difference between sequence reception and content delivery.


·       I think the padding mechanism is also excellent, avoiding potentially very messy padding within message contents.

[RT] The best padding mechanism is simple.  I've used the messages and padding construction many times before, and it just works well.  You can skip the padding early in the parsing pipeline, and just concentrate on processing a series of messages deeper in the ingress logic.


·       The Transfer Window discussed in section 5 is similar to LTP’s limit on the number of concurrent sessions (i.e., blocks in transit).  I would note that it similarly imposes a measure of coarse-grained flow control on the channel, potentially helpful.

[RT]. Thank you - this took the most work of the whole document.  I have tried to follow best practice of the many protocols out there, trimming it back to the absolute minimum required.  There is a subtlety here as well:  if there is a period of no reception, the windowing processes will allow a receiver to 'spin ahead' and resynchronise when data starts to arrive again, without requiring an explicit synchronisation mechanism.  This would allow receive-only nodes to dip into a fountain of bundle transmissions as they want, and still collect bundles.  When this is combined with retransmission, one could imagine scenarios where a sender broadcasts the same 10 bundles endlessly for 24 hours, knowing there is a high enough probability of all listeners receiving the data.


·       In section 6, why message duplicate transmission instead of erasure coding?  Certainly it’s simpler, but getting the configuration right seems tricky to me; I would worry about bandwidth utilization.  Is it just a matter of amenability to implementation in hardware?  You mention the possibility of redundancy and erasure coding in the underlying link-layer protocol; do we expect hardware implementation of those link-layer protocol features to be easier?  And if so, why bother with duplicate transmission in BTPU?  Maybe this backstop is the right solution but it seems hazardous to me.

[RT] Aaaah... because this is only Part 1.  I had a whole section on FEC in the document, but I have lifted it out into a second draft.  There was no efficient universal way of including FEC, and hence I will introduce a BTPU-FEC extension (hopefully before IETF-122).  It's active work in progress.   'Dumb' duplication is in there, because there is no reason to exclude it, so I considered it better to be explicit about how to handle duplicates, and steer implementations to consider it fully, rather than leave it only hinted at.  Also, see my previous comment on duplication and 'bundle fountains'.


·       A final nit: in the definition of Message, why not define Length as simply the length of the message’s Content?

[RT]. My thought was: for an FPGA implementation, having the Length being the 'total message length' might mean parsing the message could involve less arithmetic, but I'm open to discussion here.  I'm not sure it makes a great deal of difference.

Anyway, great work.  I’m glad this is on the table.

[RT] Glad you like it!  For such a slim document, it took a surprising amount of work!

<snip>

Thanks again
Rick
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/20250312/40485740/attachment-0001.htm>