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

[ccaini <[e-mail]>]

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".



On Wed, 14 May 2014 12:56:08 -0300, Martin Galvan <[e-mail]>
wrote:
> 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?
> 
> 
> 2014-05-14 12:20 GMT-03:00 Martin Galvan <[e-mail]>:
> 
>> 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!
>>