[Sis-dtn] [EXT] Re: [dtn] Bundle custody transfer and reliable CLs
Sipos, Brian J.
Brian.Sipos at jhuapl.edu
Fri Mar 25 11:45:55 UTC 2022
Felix,
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.
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-CLA interface API, but it seems like the rough interface looks like:
. Send.request to the CLA
. Send.response from the CLA
. Receive.indication from the CLA
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:
. Receive.indication from the CLA
. Receive.response to the CLA
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."
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.
Thanks for any further clarification,
Brian S.
From: dtn <dtn-bounces at ietf.org> On Behalf Of Felix.Flentge at esa.int
Sent: Friday, March 25, 2022 6:11 AM
To: dtn at ietf.org; sis-dtn at mailman.ccsds.org
Subject: [EXT] Re: [dtn] Bundle custody transfer and reliable CLs
(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" < <mailto:ivancic at syzygyengineering.com>
ivancic at syzygyengineering.com>
To: < <mailto:sburleig.sb at gmail.com> sburleig.sb at gmail.com>, "'Sipos,
Brian J.'" < <mailto:Brian.Sipos at jhuapl.edu> Brian.Sipos at jhuapl.edu>, <
<mailto:dtn at ietf.org> dtn at ietf.org>
Date: 25/03/2022 01:16
Subject: Re: [dtn] Bundle custody transfer and reliable CLs
Sent by: "dtn" < <mailto:dtn-bounces at ietf.org> 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 < <mailto:dtn-bounces at ietf.org> dtn-bounces at ietf.org> on behalf of
< <mailto:sburleig.sb at gmail.com> sburleig.sb at gmail.com>
Date: Thursday, March 24, 2022 at 6:04 PM
To: "'Sipos, Brian J.'" < <mailto:Brian.Sipos at jhuapl.edu>
Brian.Sipos at jhuapl.edu>, < <mailto:dtn at ietf.org> 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 < <mailto:dtn-bounces at ietf.org> dtn-bounces at ietf.org> On Behalf Of
Sipos, Brian J.
Sent: Thursday, March 24, 2022 1:39 PM
To: <mailto:dtn at ietf.org> 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
<mailto:dtn at ietf.org> dtn at ietf.org
<https://www.ietf.org/mailman/listinfo/dtn>
https://www.ietf.org/mailman/listinfo/dtn
_______________________________________________
dtn mailing list
<mailto:dtn at ietf.org> dtn at ietf.org
<https://www.ietf.org/mailman/listinfo/dtn>
https://www.ietf.org/mailman/listinfo/dtn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20220325/0e1f2ed4/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6603 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20220325/0e1f2ed4/attachment-0001.bin>
More information about the SIS-DTN
mailing list