[Sis-dtn] [dtn] Bundle custody transfer and reliable CLs

Fri Mar 25 10:11:12 UTC 2022

(cross-posting to CCSDS DTN mailinglist as it seems to be of high 
relevance to the on-going discussions in the DTN WG).

I think we clearly need to distinguish between (at least) two different 
types of 'custody transfer' according to where it is implemented:

(a) BPv6 - like custody transfer which has been a function of the BPA / AA 
Administrative element
(b) BIBE-like custody transfer which is implemented in the CLA

The main differences I see are:
- In (a) the decision whether to take custody or not can be taken on more 
available information, eg timely availability of a route toward a next 
hop, available storage, policies (eg, checking Bundle Integrity Blocks), 
... In (b), the CLA may accept custody and the BPA would just decide to 
discard the bundle for whatever reason (of course, there could be 
interfaces to make such information available to the CLA but this would 
somehow 'blur' the architecture.
- In (b), the node to take custody needs to be explicitly addressed (it's 
the BIBE destination) while in (a) any node could take custody.

Requirements regarding custody transfer I would see for space missions 
are:

1) Assertion of a high probability that a bundle will reach its 
destination once a hop has accepted custody (which would allow the 
forwarding node to release storage).
The meaning of 'high probability' does really depend on the mission data 
return requirements. While for some missions it may be close to 100%, 
other mission may be ready to accept higher data loss in favour of 
timeliness (eg, certain types of Earth Observation missions).

2) Forwarding bundles without knowing which node will take custody.
In particular with high data rates and optical direct-to-Earth downlinks 
we may have situations where the spacecraft may not know the actual next 
hop is sending to but may want to get a confirmation that the bundle has 
been received on ground. With high-data rates, bundles might already be 
prepared and encoded in frames and be sitting in some buffers within 
optical terminal because the data rates on the on-board buses would not 
allow to generate and send in real time. Use of optical direct-to-Earth 
links may be opportunistic and we may not know in advance how much data 
will go down. So, addressing a specific DTN node in a ground station 
becomes unpractical (if DTN nodes in ground station would share the same 
anycast eID it may be possible but BIBE is currently limited to singleton 
endpoints).

It is clear that these requirements cannot be solved by protocol 
specification as Scott pointed out below but will also require that 
implementing nodes conform to certain behaviours. This will not be 
possible for an open, Internet-like DTN network (where we can only try to 
take defensive actions). For space missions I would still expect limited, 
tightly-controlled network for some time to come (maybe becoming 'trusted 
zones' in a larger network). For these, we should have protocol mechanism 
which can support above requirements (while being aware that some of these 
mechanisms will not work in a fully open DTN).

Finally, 'custody transfer' seems to be always related to timer-base 
re-transmission. However, I think there are other options as well, like:
- command-based re-transmission: an explicit command is sent to a DTN node 
to re-transmit all bundles for which custody has been requested but no 
signal has been received
- sequence-based re-transmission: in some situations it might be possible 
(using additional extension blocks) to detect which bundles have not been 
received by inspecting the received custody signals and re-send the ones 
for which no custody signal have been received
Again, this would likely not work in an open DTN but only in (very) 
limited, controlled networks. But this doesn't make such mechanisms less 
useful (although I would prefer to have something more generic if 
possible) and we should address it in the IETF (if there is general 
interest) and/or the CCSDS (if it is for near-to-medium term space mission 
use cases only). 

Regarding reliable CLs: I currently don't see the point of a reliable CL 
taking custody because it would be (only) type (b) custody which is 
basically just a confirmation that the bundle has been received and this 
can already be assumed by the fact that it is a reliable CL.

Regards,
Felix

From:   "William Ivancic" <ivancic at syzygyengineering.com>
To:     <sburleig.sb at gmail.com>, "'Sipos, Brian J.'" 
<Brian.Sipos at jhuapl.edu>, <dtn at ietf.org>
Date:   25/03/2022 01:16
Subject:        Re: [dtn] Bundle custody transfer and reliable CLs
Sent by:        "dtn" <dtn-bounces at ietf.org>

?Custody? is  a bundle level concept, not transport.  Way back when, 
?Custody? meant that the node taking ?Custody? would try it?s best to 
ensure the bundle was forwarded either to another ?Custody? node or to 
eventually the destination node.  The idea, as I recall, was this would 
allow the original bundle source to clear its memory of that bundle.  

For space operations, I don?t think the operations people were ever 
comfortable with this concept.

//Will

From: dtn <dtn-bounces at ietf.org> on behalf of <sburleig.sb at gmail.com>
Date: Thursday, March 24, 2022 at 6:04 PM
To: "'Sipos, Brian J.'" <Brian.Sipos at jhuapl.edu>, <dtn at ietf.org>
Subject: Re: [dtn] Bundle custody transfer and reliable CLs

Brian, there was some further discussion of custody transfer in this 
morning?s meeting of the CCSDS Space Internetworking Systems DTN Working 
Group as well.  A couple of notes:

It?s important to remember that we are talking about state machines here, 
not people.  Anthropomorphizing the DTN architecture is tempting but 
treacherous.  BP nodes have no will; they cannot take responsibility; they 
cannot promise to do anything.  All they do is behave, ideally in a 
fashion that conforms to the protocol specifications to which they were 
allegedly developed.

Also, any given node may have been designed with malign intent or 
implemented with errors.  Stating a requirement in a protocol 
specification does not ensure its satisfaction; what it does is give a 
node?s human (maybe eventually AI) network operators a means of assessing 
the behavior of another node and possibly taking some sort of out-of-band 
administrative action in defense against that behavior as needed.

You?re right, the term ?custody? is not defined for BPv7.  It is still 
widely used to refer to some behavior that future users of DTN for space 
flight operations state will be very important, but for which the 
requirements are not yet clearly established.  It is starting to look like 
the BP-based ARQ in the most recent BIBE draft, while needed (I think), is 
not exactly what people mean by ?custody transfer.?  So it may become 
useful to define an additional BP extension (TBD) that we label with this 
term.

TCPCL enhancements along the lines you propose here may very well be 
valuable; I don?t know, need to think about them some more.  But I would 
say the BPv7 specification already contains language (in 5.4, Step 5 and 
the following two paragraphs, and in 7.2, second bullet point) 
constraining the sort of convergence-layer reliability that I think is 
indispensable, regardless of what we call it.

Scott

From: dtn <dtn-bounces at ietf.org> On Behalf Of Sipos, Brian J.
Sent: Thursday, March 24, 2022 1:39 PM
To: dtn at ietf.org
Subject: [dtn] Bundle custody transfer and reliable CLs

All,
There was some brief discussion during the BIBE presentation about custody 
transfer concept and CL mechanisms. This is also an open topic in the 
CCSDS drafting of BPv7 standardization. I would like to add some 
additional points for thought in how a reliable convergence layer can 
relate to the concept of custody transfer for agents on either side of the 
transfer.

Overall, there still seems to be some vagueness about what ?custody? means 
(in the sense of a service level agreement) between peers exchanging 
bundles. My understanding is that ?custody? means the custodial node is 
willing to make some kind of effort to keep the bundle moving toward its 
destination until the bundle lifetime expires.

The current RFC 9174 document is silent about what exactly an XFER_ACK 
segment with END flag set (an END ACK) means from the perspective of the 
BP agent and what is guaranteed about the transferred bundle. This 
provides an opportunity for a follow-on clarification of END ACK semantics 
for the TCPCL entity and for the BP agent. Two potential ways of making 
the behavior more well-defined:

1.       A network-specific profile of TCPCL could simply mandate that any 
node accepts custody by sending an END ACK. This would simply be a 
condition of conformance to the profile in a controlled network. This 
could be done immediately without any change elsewhere, but needs 
out-of-band coordination.
2.       One or more (quite simple) extension types can be defined for 
TCPCL to allow an entity to expose its END ACK behavior (RX) and desire 
(TX):
a.       A session extension can allow an entity to assert what its sent 
END ACK means for received transfers. The value in this is to allow the 
peer entity to adjust behavior depending on the capability (e.g. use BIBE 
if the next-hop doesn?t take END ACK custody), including possibly refusing 
to establish a session with (or refusing to send bundles to) a peer that 
does not take custody via END ACK.
b.      Additionally, a transfer extension can allow a sender to assert 
its custody desire on a per-bundle basis (signaling that some bundles need 
custody transfer while others do not). The value in this is to allow the 
receiving entity to optimize its behavior based on whether or not custody 
is needed for a bundle; though I don?t know how much benefit this would 
be.

The possible values enumerated by the session extension would be something 
like:
·         Custody is not taken at END ACK
·         Custody is taken at END ACK
And if there is a transfer extension defined, a the session extension 
could indicate:
·         Reception behavior is unconditional
·         Reception behavior can be overridden per-transfer based on the 
sender?s desire
These changes would all be backward compatible in the sense that a default 
policy would be in place in the absence of this extension item. And all of 
this is an independent mechanism from BIBE for a custody transfer to take 
place; both this mechanism and BIBE have their own costs, benefits, and 
side effects of such a transfer.

Trying to make almost-there-already capabilities more obvious,
Brian S.
_______________________________________________ dtn mailing list 
dtn at ietf.org https://www.ietf.org/mailman/listinfo/dtn 
_______________________________________________
dtn mailing list
dtn at ietf.org
https://www.ietf.org/mailman/listinfo/dtn

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20220325/47124a8c/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 11926 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20220325/47124a8c/attachment-0001.bin>