Re: [dtn-interest] Custody transfer specification in RFC5050

["Burleigh, Scott C (313B)" <[e-mail]>]

Jim, yes, section 5.2 does pertain only to initial issuance of a bundle, but 5.4 applies on every transmission of a bundle including the first.  I think the more general answer to your question is in the second paragraph of 5.10: each node makes its own decision as to whether or not to take custody of each bundle for which custodial transmission was requested.

Scott
________________________________
From: [e-mail] [[e-mail]] on behalf of Jim Wright [[e-mail]]
Sent: Wednesday, April 18, 2012 1:43 PM
To: Ivancic, William D. (GRC-RHN0)
Cc: [e-mail]
Subject: Re: [dtn-interest] Custody transfer specification in RFC5050

I think custody transfer is more than a warm fuzzy, it is an important part of the store-and-forward routing in DTN. Custody transfer acknowledgement allows a node to clear a stored bundle. Without that the only way to flush bundles from a node's storage would be through timeout.

Regarding your example, I believe this happens:

Node A sends a bundle with the Custody Transfer Requested bit set, and the Request Reporting of Custody Acceptance bit set. The bundle is sent to node B. Node B receives the bundle and forwards it to node C, but node B does not take custody of the bundle. Node C receives the bundle and accepts custody. Node C looks in the dictionary to find the Custodian EID, and sends an administrative record bundle to node A to signal custody acceptance.


Hmm, maybe I've found my problem. If section 5.2 Bundle Transmission deals only with initial transmission from an application agent (getting a bundle into the DTN), and if section 5.4 Bundle Forwarding deals with bundles already in the DTN, then my confusion is cleared up. If an application wants custody transfer, and the originating node does not support that, then fail immediately. I was reading 5.2 as being a required step for forwarding of bundles in the network. So does this make sense and answer my question?

Jim


On Apr 18, 2012, at 2:22 PM, Ivancic, William D. (GRC-RHN0) wrote:

I was just discussing custody transfer with a few colleagues.  I haven't gone into RFC5050 to confirm you confusion.  However, my understanding of  custody transfer is that if a node B accepts custody from node A, node A may decide to clear its storage.  Node B is suppose to then do its best to forward the bundle.  I believe node B can accept a bundle from node A without accepting custody and forward on to node C which accepts custody.  However, how does node C let node A know it has custody in a meaningful way if they are disconnected for long periods of time?  In the mean time, node A would likely NOT clear its storage until receiving an acknowledgement of custody acceptance from some node.


In reality, I think custody transfer is just a warm fuzzy good feeling for the space operations community.  In reality, if  node accepts a bundle, isn't it going to do its best to forward it?  If bundles are different sizes with different lifetimes and different priorities to different destinations, what is the proper algorithm to decide which to forward first?

I would like to see an analysis regarding custody transfer.  I would not be surprised to find out that custody transfer actually results in worse performance in complex networks.  If you are string network (A to B to C to D), it is likely to be a wash.  Furthermore, much depends on the routing algorithms used as well if if your system is multi-homed.

- Will



On Apr 18, 2012, at 3:58 PM, Jim Wright wrote:

I have been reading RFC5050 and specifically trying to understand the custody transfer mechanism. In my reading of RFC5050, I see no provision to allow for a Bundle Node to receive a bundle with the Custody Transfer Request bit set and simply forward it on, without taking custody of the bundle. It seems every Bundle Node MUST implement custody transfer.

Is this correct? If it is not correct, and it is allowed to have a Bundle Node that receives and forwards bundles without taking custody, then where in RFC5050 is this specified?

Thanks,
Jim



--
Jim Wright
BioServe Space Technologies
[e-mail]<mailto:[e-mail]>
303-492-1579

_______________________________________________
dtn-interest mailing list
[e-mail]<mailto:[e-mail]>
https://www.irtf.org/mailman/listinfo/dtn-interest