<span style=" font-size:10pt;font-family:sans-serif">Yes, I do think there
is a need for reliability mechanisms above the CLA Layer. BIBE as a generic
reliable CLA allows to address the case of reliability for uni-directional
links (although in this case the setting of the timers may already get
difficult) but it is currently not addressing:</span>
<br><span style=" font-size:10pt;font-family:sans-serif">- non-timer based
re-transmission (which might be very specific to a certain node and deployment
and therefore might be better addressed as part of the BPA / AA)</span>
<br><span style=" font-size:10pt;font-family:sans-serif">- forwarding a
bundle without explicitly addressing a (singleton) next hop (eg, an opportunistic
downlink where some signal about reception or delivery is uplinked at some
later time).</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">I agree that we
somehow can consider all received bundles as 'custodial' as a node should
attempt to store and forward them. I also think that the typical use of
custody transfer for BPv6 has been probably more to be informed about the
reception (or deletion) of a bundle then whatever (additional ???) responsibility
would be taken by the receiving node. So, maybe we should abandon the term
'custody' altogether. However, there are certainly situations where a sending
node would like to get information about reception/delivery/deletion/forwarding
of a bundle at another node in an operationally viable and efficient way
(so, not using the current Bundle Status Reports).</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><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">From:
</span><span style=" font-size:9pt;font-family:sans-serif">"Dr.
Keith L Scott" <kscott@mitre.org></span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">To:
</span><span style=" font-size:9pt;font-family:sans-serif">"Mehmet
Adalier" <madalier@antarateknik.com>, "sburleig.sb@gmail.com"
<sburleig.sb@gmail.com>, "'Sipos, Brian J.'" <Brian.Sipos@jhuapl.edu>,
"Felix.Flentge@esa.int" <Felix.Flentge@esa.int>, "dtn@ietf.org"
<dtn@ietf.org>, "sis-dtn@mailman.ccsds.org" <sis-dtn@mailman.ccsds.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">28/03/2022
15:11</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:
[Sis-dtn] [dtn] [EXT] Re: Bundle custody transfer and reliable CLs</span>
<br>
<hr noshade>
<br>
<br>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">The
question remains: do we need some form of reliability above the CLA layer?
As Scott points out, BIBE is ¡¥just¡¦ a reliable CLA that uses bundles
as its transport mechanism. That allows BIBE to function as a reliable
CLA in environments where other CLAs that require bidirectional connectivity
cannot, but viewed from the standpoint of the sending and receiving BIBE
endpoints, it¡¦s just another reliable CLA.</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
not-often-stated assumption here is that bundle nodes that receive bundles
via reliable CLAs do in fact take on the responsibilities of what was traditionally
referred to as ¡¥custody transfer¡¦ ¡V i.e. following whatever procedures
are necessary to ensure that the received bundle reaches its destination
(e.g. store it until a forward path becomes available, attempt retransmission
to the next hop until there¡¦s an indication that the next hop has (via
a reliable CLA in this context) received the bundle, etc.). I.e.
this approach assumes that receipt of a bundle </span><span style=" font-size:11pt;font-family:Wingdings">„»</span><span style=" font-size:11pt;font-family:Calibri">
accepting ¡¥custody¡¦ of it. Without this assumption, the service
provided by BP is essentially the same best-effort service that IP provides,
which I think is less than what we want, particularly for space missions.
So I think that in the BPv7 context, all bundles are considered ¡¥custodial¡¦.</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"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">If
we consider cases where there may be congestion (contention for storage
space at nodes), this means that when congestion happens at a node, the
only course of action available to the node will be to refuse new incoming
bundles (presumably because the receiving CLAs stop accepting them). </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">There
are at least two things to consider here:</span></p>
<br><span style=" font-size:10pt;font-family:sans-serif">1.
</span><span style=" font-size:11pt;font-family:Calibri">What
if I have a bundle node that is capable of forwarding but that has quite
minimal storage? By receiving a bundle, this node is committing to
storing that bundle until it can be reliably forwarded. It seems
like there could be cases where this is really inefficient, especially
if the reliable forwarding is over something like BIBE where the RTT to
get an acknowledgement could be high. In BPv6, such a node could
simply forward a custody-requesting bundle without actually taking custody,
sort of like a ¡¥transit node¡¦ in a BIBE tunnel. In this case, it
might be able to achieve a higher throughput at the expense of NOT accepting
the storage requirements from the current custodians.</span>
<br><span style=" font-size:10pt;font-family:sans-serif">2.
</span><span style=" font-size:11pt;font-family:Calibri">Even
if a congested node has a lot of storage (but still becomes congested),
in BPv6 there was the notion that the node could drop (probably lower-priority)
non-custodial bundles in favor of (probably higher-priority) custodial
bundles. We don¡¦t currently have any notion of priority in BPv7,
but if we ever want to admit the possibility that a bundle node might drop
a bundle due to congestion, it seems like the assumption that receipt </span><span style=" font-size:11pt;font-family:Wingdings">„³</span><span style=" font-size:11pt;font-family:Calibri">
¡¥custodial¡¦ acceptance constrains us. In the BPv7 ¡¥receipt is
(custody) acceptance¡¦ model, the node would have to refuse new bundles.</span>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">This
might be right thing for some CONOPS. It would impose backpressure
(at DTN timescales) on the network, eventually to the bundle sources. The
same thing would happen with BPv6 and custodial bundles, the difference
being that a BPv6 node would have the option of dropping non-custodial
bundles to accommodate newer (again, presumably higher-priority) bundles.</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">I¡¦ll
readily admit that calculating a (good) retransmission timer value in the
case where a node does NOT know if the proximate (or even which) downstream
node will take custody is difficult or impossible for some networks. BIBE
still has a bit of this problem, especially if the path to the BIBE destination
is long, as the sender won¡¦t necessarily know the path the BIBE bundles
will take, but it is at least more constrained than the completely open
case.</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"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">If
we want to have the option of dropping lower-priority bundles that have
already been received and are being stored at a node, we¡¦ll need an extension
block to mark priority, fine. We could then create rules that operate
at the BP layer to drop bundles when congestion occurs according to their
priority markings and address #2 above. I suppose in this case the ¡¥reliability¡¦
is still at the CLA layer and the decision-making process on whether or
not to drop an incoming bundle is at the BP layer. </span></p>
<ul>
<li><span style=" font-size:11pt;font-family:Calibri">That might not address
#1 above but maybe #1 is sufficiently rare (or non-existent) that we decide
to ignore it.</span>
<li><span style=" font-size:11pt;font-family:Calibri">Regardless, this
has the disadvantage that the transmitting node would believe that the
bundle was accepted (because it would have been, by the receiving CLA)
event though it then got dropped by the BP layer at the receiving node.</span></ul><span style=" font-size:11pt;font-family:Calibri"> </span>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">
--keith</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"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri"><b>From:
</b>"sis-dtn-bounces@mailman.ccsds.org" <sis-dtn-bounces@mailman.ccsds.org>
on behalf of "sis-dtn@mailman.ccsds.org" <sis-dtn@mailman.ccsds.org><b><br>
Reply-To: </b>Mehmet Adalier <madalier@antarateknik.com><b><br>
Date: </b>Friday, March 25, 2022 at 1:21 PM<b><br>
To: </b>"sburleig.sb@gmail.com" <sburleig.sb@gmail.com>,
"'Sipos, Brian J.'" <Brian.Sipos@jhuapl.edu>, Felix Flentge
<Felix.Flentge@esa.int>, "dtn@ietf.org" <dtn@ietf.org>,
"sis-dtn@mailman.ccsds.org" <sis-dtn@mailman.ccsds.org><b><br>
Subject: </b>Re: [Sis-dtn] [dtn] [EXT] Re: 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">I
believe Scott¡¦s analysis below succinctly articulates the difference between
the two approaches and I agree that they should be kept separate. For my
intended use cases, approach 1 (BIBE/BPARQ?) is what I would need to use.
I¡¦ll be happy to contribute to this approach and prototype.</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">Best</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">mehmet</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>SIS-DTN <sis-dtn-bounces@mailman.ccsds.org> on behalf of "sburleig.sb---
via SIS-DTN" <sis-dtn@mailman.ccsds.org><b><br>
Reply-To: </b><sburleig.sb@gmail.com><b><br>
Date: </b>Friday, March 25, 2022 at 10:07 AM<b><br>
To: </b>"'Sipos, Brian J.'" <Brian.Sipos@jhuapl.edu>, <Felix.Flentge@esa.int>,
<dtn@ietf.org>, <sis-dtn@mailman.ccsds.org><b><br>
Subject: </b>Re: [Sis-dtn] [dtn] [EXT] Re: 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">Hi,
Brian. Actually I think Felix¡¦s analysis is pretty much spot-on.
We really are talking about two different behaviors, which respond
to two different sets of requirements.</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
¡§custody transfer¡¨ procedures that I proposed in the BIBE draft are very
specifically aimed at defining a reliable convergence-layer adapter that
happens to use BP as its underlying convergence-layer protocol. There
is a requirement for this capability: Keith Scott has often pointed out
that there are scenarios in which reliable transmission between nodes is
required but no reliable transmission protocol is available, e.g., when
the sender¡¦s communication capability is temporarily unidirectional. These
are not hypothetical; MITRE¡¦s customers must at times operate in such
environments, and some space flight missions and other IoT systems could
be similarly constrained. Under these conditions, the mechanism by
which NAKs and ACKs are returned to the sender may function at a later
time and/or be unrelated to the mechanism by which the sender transmitted
the data. There might be better standardized protocols than BP for
supporting these kinds of scenarios, but none leap to mind.</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
¡¨custody transfer¡¨ procedures for which Felix proposes requirements are
different. Since there is no need for timeout-triggered retransmission
(retransmission is instead triggered by command or by negative acknowledgment),
there is no need for accurate estimation of the round-trip time; therefore
there is no need for the sender to know which node will issue the responding
(positive) custody acknowledgment, exactly as required. I think of
it as a resource management system rather than an ARQ system. A mechanism
very much like BPv6 custody transfer will work fine.</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">I
would propose that we term the latter procedures ¡§custody transfer¡¨ and
proceed to standardize them, while renaming the former something like ¡§BPARQ¡¨.</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">I
don¡¦t think there¡¦s any need to impose any additional requirements on
CL protocols, TCPCL or other, to satisfy the requirements. These
are separate things. Let¡¦s keep them separate and support them separately
and clearly.</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> Friday, March 25, 2022 4:46 AM<b><br>
To:</b> Felix.Flentge@esa.int; dtn@ietf.org; sis-dtn@mailman.ccsds.org<b><br>
Subject:</b> Re: [dtn] [EXT] Re: Bundle custody transfer and reliable CLs</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Times New Roman"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri">Felix,</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri">Thank
you for this feedback. There is a misinterpretation of what I (and maybe
also Scott via BIBE) am suggesting about what happens during reliable reception.
The idea isn¡¦t that two different things happen, it¡¦s that it¡¦s the
same BP agent custody acceptance criteria just that some CLs can provide
intrinsic signaling of that acceptance while other CLs have no means to
signal that specific feedback.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri">While
IETF doesn¡¦t (normally) specify internal APIs, the CCSDS documents do
and this can help here. Currently 734.2-B-1 does not actually define a
BPA¡XCLA interface API, but it seems like the rough interface looks like:</span></p>
<ul>
<li><span style=" font-size:11pt;color:#004080;font-family:Calibri">Send.request
to the CLA</span>
<li><span style=" font-size:11pt;color:#004080;font-family:Calibri">Send.response
from the CLA</span>
<li><span style=" font-size:11pt;color:#004080;font-family:Calibri">Receive.indication
from the CLA</span></ul><span style=" font-size:11pt;color:#004080;font-family:Calibri"> </span>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri">What
I am suggesting is that the Receive side could be changed from the asynchronous
¡§I just got this transfer. Here it is, thanks.¡¨ to a synchronous ¡§I
just got this transfer. Will you accept it?¡¨ similar to:</span></p>
<ul>
<li><span style=" font-size:11pt;color:#004080;font-family:Calibri">Receive.indication
from the CLA</span>
<li><span style=" font-size:11pt;color:#004080;font-family:Calibri">Receive.response
to the CLA</span></ul><span style=" font-size:11pt;color:#004080;font-family:Calibri"> </span>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri">The
TCPCL and LTPCL already provide the negative response over-the-wire (TCPCL
reception can send XFER_REFUSE at any time before the END ACK, and LTPCL
can send ¡§Cancel from the block receiver¡¨ similarly) there is currently
just no specific formal definition of what, from the BPA side, the positive
acknowledgement is required to mean. For example ¡§If the transfer is not
canceled by the receiver and the final ACK is sent, the transferred bundle
SHALL be completely and positively received within the BP agent¡¦s forwarding
or delivery queue.¡¨ </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri">As
Scott mentioned earlier, custody isn¡¦t an anthropomorphization of the
BPA, it¡¦s a specific behavior, and it seems like by acknowledging that
the bundle was received into the queue for delivery/forwarding the agent
has ¡§accepted¡¨ it. If the intent of custody is that it¡¦s a more restricted/reserved
resource pool (e.g. my forwarding queue is size X but of that only Y (with
Y<X) is reserved for bundles over which I have custody) then that¡¦s
a local agent management issue, not an over-the-wire signaling issue. The
BPA has still positively accepted the bundle and some CLAs can communicate
this back to the sending agent synchronously.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri">Thanks
for any further clarification,</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri">Brian
S.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;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 <</span><a href="mailto:dtn-bounces@ietf.org"><span style=" font-size:11pt;color:blue;font-family:Calibri"><u>dtn-bounces@ietf.org</u></span></a><span style=" font-size:11pt;font-family:Calibri">>
<b>On Behalf Of </b></span><a href=mailto:Felix.Flentge@esa.int><span style=" font-size:11pt;color:blue;font-family:Calibri"><u>Felix.Flentge@esa.int</u></span></a><span style=" font-size:11pt;font-family:Calibri"><b><br>
Sent:</b> Friday, March 25, 2022 6:11 AM<b><br>
To:</b> </span><a href=mailto:dtn@ietf.org><span style=" font-size:11pt;color:blue;font-family:Calibri"><u>dtn@ietf.org</u></span></a><span style=" font-size:11pt;font-family:Calibri">;
</span><a href="mailto:sis-dtn@mailman.ccsds.org"><span style=" font-size:11pt;color:blue;font-family:Calibri"><u>sis-dtn@mailman.ccsds.org</u></span></a><span style=" font-size:11pt;font-family:Calibri"><b><br>
Subject:</b> [EXT] Re: [dtn] Bundle custody transfer and reliable CLs</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Times New Roman"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:Arial">(cross-posting
to CCSDS DTN mailinglist as it seems to be of high relevance to the on-going
discussions in the DTN WG).</span><span style=" font-size:12pt;font-family:Times New Roman">
<br>
</span><span style=" font-size:10pt;font-family:Arial"><br>
I think we clearly need to distinguish between (at least) two different
types of 'custody transfer' according to where it is implemented:</span><span style=" font-size:12pt;font-family:Times New Roman">
<br>
</span><span style=" font-size:10pt;font-family:Arial"><br>
(a) BPv6 - like custody transfer which has been a function of the BPA /
AA Administrative element</span><span style=" font-size:12pt;font-family:Times New Roman">
</span><span style=" font-size:10pt;font-family:Arial"><br>
(b) BIBE-like custody transfer which is implemented in the CLA</span><span style=" font-size:12pt;font-family:Times New Roman">
<br>
</span><span style=" font-size:10pt;font-family:Arial"><br>
The main differences I see are:</span><span style=" font-size:12pt;font-family:Times New Roman">
</span><span style=" font-size:10pt;font-family:Arial"><br>
- 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><span style=" font-size:12pt;font-family:Times New Roman">
</span><span style=" font-size:10pt;font-family:Arial"><br>
- 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><span style=" font-size:12pt;font-family:Times New Roman">
<br>
</span><span style=" font-size:10pt;font-family:Arial"><br>
Requirements regarding custody transfer I would see for space missions
are:</span><span style=" font-size:12pt;font-family:Times New Roman"> <br>
</span><span style=" font-size:10pt;font-family:Arial"><br>
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><span style=" font-size:12pt;font-family:Times New Roman">
</span><span style=" font-size:10pt;font-family:Arial"><br>
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><span style=" font-size:12pt;font-family:Times New Roman">
<br>
</span><span style=" font-size:10pt;font-family:Arial"><br>
2) Forwarding bundles without knowing which node will take custody.</span><span style=" font-size:12pt;font-family:Times New Roman">
</span><span style=" font-size:10pt;font-family:Arial"><br>
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><span style=" font-size:12pt;font-family:Times New Roman">
<br>
</span><span style=" font-size:10pt;font-family:Arial"><br>
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><span style=" font-size:12pt;font-family:Times New Roman">
<br>
</span><span style=" font-size:10pt;font-family:Arial"><br>
Finally, 'custody transfer' seems to be always related to timer-base re-transmission.
However, I think there are other options as well, like:</span><span style=" font-size:12pt;font-family:Times New Roman">
</span><span style=" font-size:10pt;font-family:Arial"><br>
- 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><span style=" font-size:12pt;font-family:Times New Roman">
</span><span style=" font-size:10pt;font-family:Arial"><br>
- 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><span style=" font-size:12pt;font-family:Times New Roman">
</span><span style=" font-size:10pt;font-family:Arial"><br>
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><span style=" font-size:12pt;font-family:Times New Roman"><br>
</span><span style=" font-size:10pt;font-family:Arial"><br>
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><span style=" font-size:12pt;font-family:Times New Roman">
<br>
</span><span style=" font-size:10pt;font-family:Arial"><br>
Regards,</span><span style=" font-size:12pt;font-family:Times New Roman">
</span><span style=" font-size:10pt;font-family:Arial"><br>
Felix</span><span style=" font-size:12pt;font-family:Times New Roman">
<br>
<br>
<br>
<br>
</span><span style=" font-size:9pt;color:#5f5f5f;font-family:Arial"><br>
From: </span><span style=" font-size:9pt;font-family:Arial">"William
Ivancic" <</span><a href=mailto:ivancic@syzygyengineering.com><span style=" font-size:9pt;color:blue;font-family:Arial"><u>ivancic@syzygyengineering.com</u></span></a><span style=" font-size:9pt;font-family:Arial">></span><span style=" font-size:12pt;font-family:Times New Roman">
</span><span style=" font-size:9pt;color:#5f5f5f;font-family:Arial"><br>
To: </span><span style=" font-size:9pt;font-family:Arial"><</span><a href=mailto:sburleig.sb@gmail.com><span style=" font-size:9pt;color:blue;font-family:Arial"><u>sburleig.sb@gmail.com</u></span></a><span style=" font-size:9pt;font-family:Arial">>,
"'Sipos, Brian J.'" <</span><a href=mailto:Brian.Sipos@jhuapl.edu><span style=" font-size:9pt;color:blue;font-family:Arial"><u>Brian.Sipos@jhuapl.edu</u></span></a><span style=" font-size:9pt;font-family:Arial">>,
<</span><a href=mailto:dtn@ietf.org><span style=" font-size:9pt;color:blue;font-family:Arial"><u>dtn@ietf.org</u></span></a><span style=" font-size:9pt;font-family:Arial">></span><span style=" font-size:12pt;font-family:Times New Roman">
</span><span style=" font-size:9pt;color:#5f5f5f;font-family:Arial"><br>
Date: </span><span style=" font-size:9pt;font-family:Arial">25/03/2022
01:16</span><span style=" font-size:12pt;font-family:Times New Roman">
</span><span style=" font-size:9pt;color:#5f5f5f;font-family:Arial"><br>
Subject: </span><span style=" font-size:9pt;font-family:Arial">Re:
[dtn] Bundle custody transfer and reliable CLs</span><span style=" font-size:12pt;font-family:Times New Roman">
</span><span style=" font-size:9pt;color:#5f5f5f;font-family:Arial"><br>
Sent by: </span><span style=" font-size:9pt;font-family:Arial">"dtn"
<</span><a href="mailto:dtn-bounces@ietf.org"><span style=" font-size:9pt;color:blue;font-family:Arial"><u>dtn-bounces@ietf.org</u></span></a><span style=" font-size:9pt;font-family:Arial">></span><span style=" font-size:12pt;font-family:Times New Roman">
</span></p>
<div align=center>
<hr noshade></div>
<p style="margin-top:0px;margin-Bottom:240px"><span style=" font-size:12pt;font-family:Times New Roman"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">¡§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:12pt"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">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:12pt"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">//Will</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"><b>From:
</b>dtn <</span><a href="mailto:dtn-bounces@ietf.org"><span style=" font-size:12pt;color:blue"><u>dtn-bounces@ietf.org</u></span></a><span style=" font-size:12pt">>
on behalf of <</span><a href=mailto:sburleig.sb@gmail.com><span style=" font-size:12pt;color:blue"><u>sburleig.sb@gmail.com</u></span></a><span style=" font-size:12pt">><b><br>
Date: </b>Thursday, March 24, 2022 at 6:04 PM<b><br>
To: </b>"'Sipos, Brian J.'" <</span><a href=mailto:Brian.Sipos@jhuapl.edu><span style=" font-size:12pt;color:blue"><u>Brian.Sipos@jhuapl.edu</u></span></a><span style=" font-size:12pt">>,
<</span><a href=mailto:dtn@ietf.org><span style=" font-size:12pt;color:blue"><u>dtn@ietf.org</u></span></a><span style=" font-size:12pt">><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:12pt"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">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:12pt"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">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:12pt"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">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:12pt"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">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:12pt"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">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:12pt"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">Scott</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"><b>From:</b>
dtn <</span><a href="mailto:dtn-bounces@ietf.org"><span style=" font-size:12pt;color:blue"><u>dtn-bounces@ietf.org</u></span></a><span style=" font-size:12pt">>
<b>On Behalf Of </b>Sipos, Brian J.<b><br>
Sent:</b> Thursday, March 24, 2022 1:39 PM<b><br>
To:</b> </span><a href=mailto:dtn@ietf.org><span style=" font-size:12pt;color:blue"><u>dtn@ietf.org</u></span></a><span style=" font-size:12pt"><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:12pt"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">All,</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">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:12pt"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">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:12pt"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">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:12pt"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">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:12pt">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:12pt">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:12pt">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:12pt"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">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:12pt;font-family:Symbol">¡P
</span><span style=" font-size:12pt"> </span><span style=" font-size:12pt;font-family:Symbol">
</span><span style=" font-size:12pt"> </span><span style=" font-size:12pt;font-family:Symbol">
</span><span style=" font-size:12pt"> </span><span style=" font-size:12pt;font-family:Symbol">
</span><span style=" font-size:12pt"> </span><span style=" font-size:12pt;font-family:Symbol">
</span><span style=" font-size:12pt">Custody is not taken at END ACK</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Symbol">¡P
</span><span style=" font-size:12pt"> </span><span style=" font-size:12pt;font-family:Symbol">
</span><span style=" font-size:12pt"> </span><span style=" font-size:12pt;font-family:Symbol">
</span><span style=" font-size:12pt"> </span><span style=" font-size:12pt;font-family:Symbol">
</span><span style=" font-size:12pt"> </span><span style=" font-size:12pt;font-family:Symbol">
</span><span style=" font-size:12pt">Custody is taken at END ACK</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">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:12pt;font-family:Symbol">¡P
</span><span style=" font-size:12pt"> </span><span style=" font-size:12pt;font-family:Symbol">
</span><span style=" font-size:12pt"> </span><span style=" font-size:12pt;font-family:Symbol">
</span><span style=" font-size:12pt"> </span><span style=" font-size:12pt;font-family:Symbol">
</span><span style=" font-size:12pt"> </span><span style=" font-size:12pt;font-family:Symbol">
</span><span style=" font-size:12pt">Reception behavior is unconditional</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Symbol">¡P
</span><span style=" font-size:12pt"> </span><span style=" font-size:12pt;font-family:Symbol">
</span><span style=" font-size:12pt"> </span><span style=" font-size:12pt;font-family:Symbol">
</span><span style=" font-size:12pt"> </span><span style=" font-size:12pt;font-family:Symbol">
</span><span style=" font-size:12pt"> </span><span style=" font-size:12pt;font-family:Symbol">
</span><span style=" font-size:12pt">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:12pt">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:12pt"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">Trying
to make almost-there-already capabilities more obvious,</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">Brian
S.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">_______________________________________________
dtn mailing list </span><a href=mailto:dtn@ietf.org><span style=" font-size:12pt;color:blue"><u>dtn@ietf.org</u></span></a><span style=" font-size:12pt">
</span><a href=https://www.ietf.org/mailman/listinfo/dtn><span style=" font-size:12pt;color:blue"><u>https://www.ietf.org/mailman/listinfo/dtn</u></span></a><span style=" font-size:12pt">
</span><span style=" font-size:10pt;font-family:Courier New">_______________________________________________<br>
dtn mailing list</span><span style=" font-size:12pt;color:blue"><u><br>
</u></span><a href=mailto:dtn@ietf.org><span style=" font-size:10pt;color:blue;font-family:Courier New"><u>dtn@ietf.org</u></span></a><span style=" font-size:12pt;color:blue"><u><br>
</u></span><a href=https://www.ietf.org/mailman/listinfo/dtn><span style=" font-size:10pt;color:blue;font-family:Courier New"><u>https://www.ietf.org/mailman/listinfo/dtn</u></span></a></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">_______________________________________________
SIS-DTN mailing list SIS-DTN@mailman.ccsds.org </span><a href="https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn"><span style=" font-size:11pt;font-family:Calibri">https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn</span></a><span style=" font-size:11pt;font-family:Calibri">
</span></p>
<p style="margin-top:0px;margin-Bottom:0px"></p>
<p style="margin-top:0px;margin-Bottom:0px"></p>