Subject: [dtn-interest] What's the actual effect of using custody transfer?

From: Martin Galvan <[email-masked]>
Date: Wed, 14 May 2014 12:20:10 -0300

Hi everybody! I'm reading a bit on DTN and I have a doubt about what
custody transfer actually does. From what I've read, a node that accepts
custody of a bundle promises it won't delete the bundle until it can
forward the bundle to either its destination or another node that accepts
its custody. However, I don't see what would be the difference between
doing that and not using custody transfer. Isn't the whole purpose of a
store-and-forward mechanism to do just that?

For example, let's assume we have three nodes, A, B and C. There's no
end-to-end path from A to C, and A is directly connected to B.

A----->B     C

If I understood custody transfer right, if A wants to send C a bundle using
custody transfer, it will request B to accept custody of the bundle; if B
accepts it will store the bundle until a link to C can be established. Once
that happens, B will then forward the bundle to C and delete it once it's
reached its destination.

What would happen if A didn't want to use custody transfer?

Thanks a lot!

---

From: Vint Cerf <[email-masked]>
Date: Wed, 14 May 2014 11:47:28 -0400

assuming A is trying to get something to C, it will have to await a
confirmation from C before it removes its own copy of the bundle,
regardless of what B is doing or says. Even if B acknowledges receipt, it
if does not acknowledge custody, A has to keep its copy.

v

On Wed, May 14, 2014 at 11:20 AM, Martin Galvan <[email-masked]>wrote:

> If I understood custody transfer right, if A wants to send C a bundle
> using custody transfer, it will request B to accept custody of the bundle;
> if B accepts it will store the bundle until a link to C can be established.
> Once that happens, B will then forward the bundle to C and delete it once
> it's reached its destination.
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/dtn-interest
>
>

---

From: Martin Galvan <[email-masked]>
Date: Wed, 14 May 2014 12:56:08 -0300

Thanks a lot guys! So basically, the difference is that the sender has to
keep its copy of the bundle until it receives an acknowledgement from the
destination node, while in custody transfer it's the custodian node that
has to keep its copy? What if C receives the bundle, but there's no link
for it to send its acknowledgement back to A? Will A (or B, if it accepted
custody) have to keep its copy of the bundle indefinitely in storage?

---

From: ccaini <[email-masked]>
Date: Wed, 14 May 2014 20:15:54 +0200

Dear Martin,
     Let me highlight out a few points regarding custody:
1) A does not ask B or any other specific node in the path to destination
to accept the custody; the DTN application on the node A (not the BP on A)
sets a flag in the bundle primary block (a sort of bundle header); then
all
BP in the path to destination (including the BP of the source itself) may
(or may not) accept the custody. This is to say that nodes are free to
accept or not the request. E.g. in the A-B-C-D-E path, B could just
forward
the bundle, while C could accept the custody and become the new custodian.
2) If the BP of the current custodian does not receive a custody
acceptance by another node on the path to destination it will resend the
bundle after a time out expires. E.g. C will resend the bundle to
destination if it will not receive in time any custody acceptance signal.
3) The custodian is basically the node that is in charge of retransmitting
(at BP layer) the bundle. In the example, the advantage is that
retransmission is performed by C which is closer to destination than A.
4) Let me stress oncer again that the custody transfer is a retransmission
at BP layer, i.e. performed by BP voluntarily. Vice versa, without the
custody the bundle has to be retransmitted by the node A at application
layer, if necessary. I.e. it is the application on A, and not the BP on A
that has the burden to retransmit. If A is willing to leave the DTN
network, or to delete the bundle just sent as soon as possible, the
custody
mechanism allows it to do that.
5) Concerning your question on unidirectional links, it is a very good
question. You could have an unidirectional link along the path, e.g.
between B and C in your example, and thus C could have difficulty in
informing B that it has accepted the custody. More precisely, the custody
acceptance signal is a bundle. As that it could reach B through a
different
path (e.g. C-E-B) and this could resolve the problem if the additional
delay is not too large. If there are not alternate paths, there will be
spurious retransmissions from B to C. They will finish either when the
bundle expires (remember that bundles have a limited time to live), or
maybe when the retransmissions have reached a given number (I am not sure
on this point, which I suppose is implementation dependent). 
Note that there is a mechanism to inform the "report to:" node that the
bundle has been transmitted on an unidirectional link (see below). As the
"report to:" could be whatever node, and not necessarily the source, this
mechanism seems to me weak.
I will report below what is stated in RFC 4838 concerning unidirectional
links for the sake of completeness. By the way, all custody mechanism is
very well explained in details in RFC4838. I would suggest that you read
it: implications of custody are interesting and subtle at the same time.
Yours,
   Carlo Caini

>From RFC4838

In a DTN network where one or more custodian-to-custodian hops are
   strictly one directional (and cannot be reversed), the DTN custody
   transfer mechanism will be affected over such hops due to the lack of
   any way to receive a custody signal (or any other information) back
   across the path, resulting in the expiration of the bundle at the
   ingress to the one-way hop.  This situation does not necessarily mean
   the bundle has been lost; nodes on the other side of the hop may
   continue to transfer custody, and the bundle may be delivered
   successfully to its destination(s).  However, in this circumstance a
   source that has requested to receive expiration BSRs for this bundle
   will receive an expiration report for the bundle, and possibly
   conclude (incorrectly) that the bundle has been discarded and not
   delivered.  Although this problem cannot be fully solved in this
   situation, a mechanism is provided to help ameliorate the seemingly
   incorrect information that may be reported when the bundle expires
   after having been transferred over a one-way hop.  This is
   accomplished by the node at the ingress to the one-way hop reporting
   the existence of a known one-way path using a variant of a bundle
   status report.  These types of reports are provided if the subject
   bundle requests the report using the 'Report When Bundle Forwarded'
   delivery option.

>From RFC 5050
If the "request reporting of bundle forwarding" flag in the
         bundle's status report request field is set to 1, then a bundle
         forwarding status report should be generated, destined for the
         bundle's report-to endpoint ID.  If the bundle has the
         retention constraint "custody accepted" and all of the nodes in
         the minimum reception group of the endpoint selected for
         forwarding are known to be unable to send bundles back to this
         node, then the reason code on this bundle forwarding status
         report must be "forwarded over unidirectional link"; otherwise,
         the reason code must be "no additional information".

---

From: "Moore, Brad" <[email-masked]>
Date: Wed, 14 May 2014 09:58:52 -0600

Isn’t that what delivery receipts are for?

I thought custody transfers meant an extra level of handshake between a node and its next hop, whereby the next hop notifies the previous hop that it accepted the bundle. A convergence layer might reliably (with acknowledgement)  transfer a bundle from one hop to the next with , but that doesn’t mean the bundle agent at the next hop accepted the bundle. It might decide for example that it doesn’t have enough storage to store the bundle, and deletes the bundle. I thought the custody transfer was an extra acknowledgement sent back to the previous hop indicating that the bundle was accepted, and that the next hop bundle agent would honor the intent to attempt to forward the bundle agent towards the destination, if possible.

Brad

From: dtn-interest [mailto:[email-masked]] On Behalf Of Vint Cerf
Sent: Wednesday, May 14, 2014 9:47 AM
To: Martin Galvan
Cc: dtn-interest
Subject: Re: [dtn-interest] What's the actual effect of using custodytransfer?

assuming A is trying to get something to C, it will have to await a confirmation from C before it removes its own copy of the bundle, regardless of what B is doing or says. Even if B acknowledges receipt, it if does not acknowledge custody, A has to keep its copy.

v

On Wed, May 14, 2014 at 11:20 AM, Martin Galvan <[email-masked]> wrote:

Hi everybody! I'm reading a bit on DTN and I have a doubt about what custody transfer actually does. From what I've read, a node that accepts custody of a bundle promises it won't delete the bundle until it can forward the bundle to either its destination or another node that accepts its custody. However, I don't see what would be the difference between doing that and not using custody transfer. Isn't the whole purpose of a store-and-forward mechanism to do just that?

For example, let's assume we have three nodes, A, B and C. There's no end-to-end path from A to C, and A is directly connected to B. 

A----->B     C

If I understood custody transfer right, if A wants to send C a bundle using custody transfer, it will request B to accept custody of the bundle; if B accepts it will store the bundle until a link to C can be established. Once that happens, B will then forward the bundle to C and delete it once it's reached its destination.

Thanks a lot!

The information contained in this e-mail message is PRIVATE. It may contain confidential information and may be legally privileged. It is intended for the exclusive use of the addressee(s). If you are not the intended recipient, you are hereby notified that any dissemination, distribution or reproduction of this communication is strictly prohibited. If the intended recipient(s) cannot be reached or if a transmission problem has occurred, please notify the sender immediately by return e-mail and destroy all copies of this message. 
Thank you.

---

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Thu, 15 May 2014 19:20:18 +0000

If you read the CCSDS CFDP Blue Book, I think you get a feel for Custody Transfer.  I suspect this may be the original operational concept.
http://public.ccsds.org/publications/archive/720x1g3.pdf

Or better yet
http://public.ccsds.org/publications/archive/727x0b4.pdf
See section 6.7 Store and Forward Overlay Operations

One of the items missing from DTN Bundling is what is expected of a Bundle Forwarding Agent.  So, to the best of my knowledge, there is nothing that states that a node will do its best to forward a bundle whether or not custody transfer is requested.  Furthermore, it is probably deployment and policy specific as to whether or not a source node clears its buffer once the bundle is forwarded.  I seem to recall that DTN2 cleared the bundle as soon as it know the forwarding node received the bundle regardless of custody transfer settings.

Remember, taking custody does not guarantee delivery.  It is still a leap of faith without end-to-end confirmation.

Also, I doubt you would want to do custody transfer if you are flooding.

Personally, I suspect custody transfer does little more than give you a warm fuzzy feeling.  Either the forwarding node is going to do it's best to forward the bundle or not.  Also, I do not believe there is anything documented that indicates the a custody bundle has higher priority than a non-custody bundle.

This paper shows some tests related to custody vs non-custody transfer.
http://arc.aiaa.org/doi/pdf/10.2514/6.2012-15228

Will

From: Martin Galvan <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, May 14, 2014 11:20 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [dtn-interest] What's the actual effect of using custody transfer?

A----->B     C

Thanks a lot!