<span style=" font-size:10pt;font-family:sans-serif">(cross-posting to
CCSDS DTN mailinglist as it seems to be of high relevance to the on-going
discussions in the DTN WG).</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">I think we clearly
need to distinguish between (at least) two different types of 'custody
transfer' according to where it is implemented:</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">(a) BPv6 - like
custody transfer which has been a function of the BPA / AA Administrative
element</span>
<br><span style=" font-size:10pt;font-family:sans-serif">(b) BIBE-like
custody transfer which is implemented in the CLA</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">The main differences
I see are:</span>
<br><span style=" font-size:10pt;font-family:sans-serif">- 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.</span>
<br><span style=" font-size:10pt;font-family:sans-serif">- 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.</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">Requirements regarding
custody transfer I would see for space missions are:</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">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).</span>
<br><span style=" font-size:10pt;font-family:sans-serif">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).</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">2) Forwarding
bundles without knowing which node will take custody.</span>
<br><span style=" font-size:10pt;font-family:sans-serif">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).</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">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).</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">Finally, 'custody
transfer' seems to be always related to timer-base re-transmission. However,
I think there are other options as well, like:</span>
<br><span style=" font-size:10pt;font-family:sans-serif">- 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</span>
<br><span style=" font-size:10pt;font-family:sans-serif">- 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</span>
<br><span style=" font-size:10pt;font-family:sans-serif">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). </span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">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.</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">Regards,</span>
<br><span style=" font-size:10pt;font-family:sans-serif">Felix</span>
<br>
<br>
<br>
<br>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">From:
</span><span style=" font-size:9pt;font-family:sans-serif">"William
Ivancic" <ivancic@syzygyengineering.com></span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">To:
</span><span style=" font-size:9pt;font-family:sans-serif"><sburleig.sb@gmail.com>,
"'Sipos, Brian J.'" <Brian.Sipos@jhuapl.edu>, <dtn@ietf.org></span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Date:
</span><span style=" font-size:9pt;font-family:sans-serif">25/03/2022
01:16</span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Subject:
</span><span style=" font-size:9pt;font-family:sans-serif">Re:
[dtn] Bundle custody transfer and reliable CLs</span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Sent
by: </span><span style=" font-size:9pt;font-family:sans-serif">"dtn"
<dtn-bounces@ietf.org></span>
<br>
<hr noshade>
<br>
<br>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">“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. </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">For
space operations, I don’t think the operations people were ever comfortable
with this concept.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">//Will</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri"><b>From:
</b>dtn <dtn-bounces@ietf.org> on behalf of <sburleig.sb@gmail.com><b><br>
Date: </b>Thursday, March 24, 2022 at 6:04 PM<b><br>
To: </b>"'Sipos, Brian J.'" <Brian.Sipos@jhuapl.edu>, <dtn@ietf.org><b><br>
Subject: </b>Re: [dtn] Bundle custody transfer and reliable CLs</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">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:</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">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.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">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.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">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.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">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.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">Scott</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"><b>From:</b>
dtn <dtn-bounces@ietf.org> <b>On Behalf Of </b>Sipos, Brian J.<b><br>
Sent:</b> Thursday, March 24, 2022 1:39 PM<b><br>
To:</b> dtn@ietf.org<b><br>
Subject:</b> [dtn] Bundle custody transfer and reliable CLs</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">All,</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">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.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">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.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">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:</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">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.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">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):</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">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.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">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.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">The
possible values enumerated by the session extension would be something
like:</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Symbol">·
</span><span style=" font-size:11pt;font-family:Calibri">Custody
is not taken at END ACK</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Symbol">·
</span><span style=" font-size:11pt;font-family:Calibri">Custody
is taken at END ACK</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">And
if there is a transfer extension defined, a the session extension could
indicate:</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Symbol">·
</span><span style=" font-size:11pt;font-family:Calibri">Reception
behavior is unconditional</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Symbol">·
</span><span style=" font-size:11pt;font-family:Calibri">Reception
behavior can be overridden per-transfer based on the sender’s desire</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">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.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">Trying
to make almost-there-already capabilities more obvious,</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">Brian
S.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">_______________________________________________
dtn mailing list dtn@ietf.org </span><a href=https://www.ietf.org/mailman/listinfo/dtn><span style=" font-size:11pt;font-family:Calibri">https://www.ietf.org/mailman/listinfo/dtn</span></a><span style=" font-size:11pt;font-family:Calibri">
</span><tt><span style=" font-size:10pt">_______________________________________________<br>
dtn mailing list<br>
dtn@ietf.org<br>
</span></tt><a href=https://www.ietf.org/mailman/listinfo/dtn><tt><span style=" font-size:10pt">https://www.ietf.org/mailman/listinfo/dtn</span></tt></a><tt><span style=" font-size:10pt"><br>
</span></tt></p>
<p style="margin-top:0px;margin-Bottom:0px"></p>
<p style="margin-top:0px;margin-Bottom:0px"></p>