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

From: Jim Wright <[email-masked]>
Date: Wed, 18 Apr 2012 13:58:16 -0600

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
[email-masked]
303-492-1579

---

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Wed, 18 Apr 2012 15:22:42 -0500

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:

Thanks,
Jim

--
Jim Wright
BioServe Space Technologies
[email-masked]<mailto:[email-masked]>
303-492-1579

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

---

From: Jim Wright <[email-masked]>
Date: Wed, 18 Apr 2012 14:43:20 -0600

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:

>> [email-masked]

---

From: "Burleigh, Scott C (313B)" <[email-masked]>
Date: Wed, 18 Apr 2012 20:57:40 +0000

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: [email-masked] [[email-masked]] on behalf of Jim Wright [[email-masked]]
Sent: Wednesday, April 18, 2012 1:43 PM
To: Ivancic, William D. (GRC-RHN0)
Cc: [email-masked]
Subject: Re: [dtn-interest] Custody transfer specification in RFC5050

Jim

- Will

Thanks,
Jim

---

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Wed, 18 Apr 2012 16:10:51 -0500

> 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…

I reiterate:   

if  node accepts a bundle, isn't it going to do its best to forward it - custody accepted or not? 

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?

If C cannot contact A with Custody Accepted, but forwards A's bundle on and the bundle reaches its final destination, A either re-forwards to another node; or the bundle times out on A and A does not release storage.  Or, A can release storage if needed because it knows B at least got the bundle and "hopefully" forwarded it on. 

Think "Disconnected Networks."  Think beyond Space Networks.

- Will

---

From: "Scott, Keith L." <[email-masked]>
Date: Thu, 19 Apr 2012 11:43:21 +0000

Will,

Answers to your questions inline below.

    --keith
________________________________________
From: [email-masked] [[email-masked]] on behalf of Ivancic, William D. (GRC-RHN0) [[email-masked]]
Sent: Wednesday, April 18, 2012 5:10 PM
To: Jim Wright
Cc: [email-masked]
Subject: Re: [dtn-interest] Custody transfer specification in RFC5050

I reiterate:

if  node accepts a bundle, isn't it going to do its best to forward it - custody accepted or not?
        ** Certainly the node should do its best to forward the bundle, regardless of whether or not it takes custody.  There's no problem here, since if the node runs out of resources and discards the bundle (of which it does not have custody) OK.

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?
        ** This is a question about forwarding, not custody transfer, but a valid question.  First I would think that the priorities of the bundles should be taken into consideration, then (possibly) their remaining lifetimes, sizes, etc.  I can think of several heuristics that might be good, but a thorough theoretic treatment has not (to my knowledge) been done.

If C cannot contact A with Custody Accepted, but forwards A's bundle on and the bundle reaches its final destination, A either re-forwards to another node; or the bundle times out on A and A does not release storage.  Or, A can release storage if needed because it knows B at least got the bundle and "hopefully" forwarded it on.
        ** If I understand your example correctly, A has custody of a bundle which it forwarded to B and B then forwarded to C; C took custody of the bundle and then forwarded it on to the destination, which informed node C that C no longer needed to maintain custody.  In the meantime, there is no way for C to communicate with A so C cannot inform A that C has taken custody.  Correct?
        ** If this is the case then yes, A is stuck with custody until 1) it gets a custody acknowledgement from C   2) the bundle times out   3) A retransmits the bundle and somebody successfully takes custody of it from A.

- Will

---

From: "Durst, Robert C." <[email-masked]>
Date: Thu, 19 Apr 2012 12:09:39 +0000

Jim,

Adding to what Scott said, I'd like to follow up on the point about bundle storage management.  First, you may be interested in the following, by Fall, Hong, and Madden:  http://www.dtnrg.org/docs/papers/custody-xfer-tr.pdf

Unless custody transfer is requested and has been accepted, a bundle node is free to recover the storage associated with a bundle at essentially any time.  In practice, that usually happens after it's been forwarded :).  In DTN2, there's a run-time configuration option that permits bundles to be retained in storage until they time out.  This is usually not set and was put in for diagnostic purposes.  However, for multicast distribution in time-disjoint networks, it has the beneficial effect of allowing late-joiners to a group to acquire bundle content that is already in storage.

(In the paper "Multicasting in Delay Tolerant Networks: Semantic Models and Routing Algorithms" by Zhao, Ammar, and Zegura, ref. http://chants.cs.ucsb.edu/2005/papers/paper-ZhaAmm.pdf, this roughly corresponds to the "Temporal Membership Model." In that model, the intended receivers of a multicast message are those who are members of the multicast endpoint at any time during the period [t1, t2], where the bounds of the membership interval are t1=the time of bundle generation and t2=the time of bundle expiration.  I don't believe that the DTN2 implementation fully implements this model, because I believe it only delivers to current members at the time of bundle receipt or future members at the time of late joining.  It doesn't go back and deliver to members whose time of departure from the multicast endpoint is later than t1.  There are several options that a DTN presents in multicasting that are different from traditional multicasting in a connected network; this paper is worth a read to either confirm existing notions or open new avenues of thought.)

Back to bundle storage management:  If custody transfer is either not requested on a bundle or not accepted by the forwarder, then (for bundles destined to a singleton endpoint) typically the bundle storage is recovered after the bundle is forwarded.  If custody transfer is accepted by the forwarder, then it promises to treat that bundle's storage more favorably than that of non-custodial bundles.  If it gets horribly congested, the forwarder is going to dump non-custodial bundles (meaning those for which it has not accepted custody, irrespective of whether custody was requested on those bundles) before it dumps ones for which it has accepted custody.  That's really the main difference in custody transfer as far as bundle storage goes.  In your example below, B would be under no obligation to show preferential treatment to the bundle, because it hadn't accepted custody, while C is expected to try really, really hard not to delete the bundle before  it receives a signal from some node downstream accepting custody of it.  (If node C gets blown up or crashes and loses its persistent state, there's little that can be done, hence the "really, really hard."  The expectation is roughly the same as your mortgage payment...)  Once custody has been accepted, the node is free to recover the storage.

(There isn't really a custodial model for multicast DTN traffic.  Susan Symington, Keith Scott, and I explored some of the issues in http://www.mitre.org/work/tech_papers/tech_papers_07/06_1000/06_1000.pdf, but it really hasn't moved forward yet.  We're just not there yet...)

Regards,
Bob Durst

From: [email-masked] [mailto:[email-masked]] On Behalf Of Burleigh, Scott C (313B)
Sent: Wednesday, April 18, 2012 4:58 PM
To: Jim Wright; Ivancic, William D. (GRC-RHN0)
Cc: [email-masked]
Subject: Re: [dtn-interest] Custody transfer specification in RFC5050

Scott
________________________________
From: [email-masked]<mailto:[email-masked]> [[email-masked]] on behalf of Jim Wright [[email-masked]]
Sent: Wednesday, April 18, 2012 1:43 PM
To: Ivancic, William D. (GRC-RHN0)
Cc: [email-masked]<mailto:[email-masked]>
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.

Jim

- Will

Thanks,
Jim

---

From: Elwyn Davies <[email-masked]>
Date: Thu, 19 Apr 2012 14:59:28 +0200

Hi.

I have to admit that RFC 5050 can be read as saying that if a bundle has 
the flag requesting custody transfer set, then a receiving node MUST 
take custody or reject the bundle.  However:
- I think that it could be that this could be read as the *initial* node 
having to accept custody... it isn't going to work too good if an 
application injects a bundle which specifies custody transfer if the 
initial node refuses to take custody.  If nothing else this would mean 
that there was no initial custodian and a later node wouldn't know what 
to do with a custody report. Doh!
- My interpretation has (more or less always) been that it is a policy 
decision for an intermediate node to decide whether it should accept 
custody, and the node could act as a forwarder *without* needing to 
accept custody.  I have to say that I did think quite hard about this at 
one stage and discussed it with others.
- DTN2 has a global (policy) flag that determines whether the node does 
custody acceptance.  If this is not set, bundles will be received and 
stored for forwarding but without indicating that custody has been 
accepted.  Consequently if the bundle is forwarded again to a node that 
*does* do custody acceptance, then that node will send a custody report 
back to the node that previously had custody in the way that seems 
natural. In line with the previous comment, it strikes me that a node 
should *always* offer custody to bundles that come from the client API  
if they have the custody transfer flag set initially.  Otherwise you 
can't get the custody transfer process started.  I don't think DTN2 
handles this at the moment.   However DTN2 *does* handle the case that a 
bundle is delivered in a node that doesn't do custody acceptance - a 
successful delivery sends a custody report if the bundle had requested 
custody transfer.

Regards,
Elwyn

On 19/04/12 14:09, Durst, Robert C. wrote:
>
> Jim,
>
> Adding to what Scott said, I'd like to follow up on the point about 
> bundle storage management.  First, you may be interested in the 
> following, by Fall, Hong, and Madden: 
> http://www.dtnrg.org/docs/papers/custody-xfer-tr.pdf
>
> Unless custody transfer is requested and /has been accepted/, a bundle 
> node is free to recover the storage associated with a bundle at 
> essentially any time.  In practice, that usually happens /after/ it's 
> been forwarded J.  In DTN2, there's a run-time configuration option 
> that permits bundles to be /retained/ in storage until they time out.  
> This is usually not set and was put in for diagnostic purposes.  
> However, for multicast distribution in time-disjoint networks, it has 
> the beneficial effect of allowing late-joiners to a group to acquire 
> bundle content that is already in storage.
>
> (In the paper "Multicasting in Delay Tolerant Networks: Semantic 
> Models and Routing Algorithms" by Zhao, Ammar, and Zegura, ref. 
> http://chants.cs.ucsb.edu/2005/papers/paper-ZhaAmm.pdf, this roughly 
> corresponds to the "Temporal Membership Model." In that model, the 
> intended receivers of a multicast message are those who are members of 
> the multicast endpoint at /any /time during the period [/t1/, /t2/], 
> where the bounds of the membership interval are /t1/=the time of 
> bundle generation and /t2/=the time of bundle expiration.  I don't 
> believe that the DTN2 implementation fully implements this model, 
> because I believe it only delivers to current members at the time of 
> bundle receipt or future members at the time of late joining.  It 
> doesn't go back and deliver to members whose time of departure from 
> the multicast endpoint is later than /t1./  There are several options 
> that a DTN presents in multicasting that are different from 
> traditional multicasting in a connected network; this paper is worth a 
> read to either confirm existing notions or open new avenues of thought.)
>
> Back to bundle storage management:  If custody transfer is either not 
> requested on a bundle or not accepted by the forwarder, then (for 
> bundles destined to a singleton endpoint) typically the bundle storage 
> is recovered after the bundle is forwarded.  If custody transfer /is/ 
> accepted by the forwarder, then it promises to treat that bundle's 
> storage more favorably than that of non-custodial bundles.  If it gets 
> horribly congested, the forwarder is going to dump non-custodial 
> bundles (meaning those for which it has not /accepted/ custody, 
> irrespective of whether custody was requested on those bundles) before 
> it dumps ones for which it /has/ accepted custody.  That's really the 
> main difference in custody transfer as far as bundle storage goes.  In 
> your example below, B would be under no obligation to show 
> preferential treatment to the bundle, because it hadn't accepted 
> custody, while C is expected to try really, really hard not to delete 
> the bundle before  it receives a signal from some node downstream 
> accepting custody of it.  (If node C gets blown up or crashes and 
> loses its persistent state, there's little that can be done, hence the 
> "really, really hard."  The expectation is roughly the same as your 
> mortgage payment...)  Once custody has been accepted, the node is free 
> to recover the storage.
>
> (There isn't really a custodial model for multicast DTN traffic.  
> Susan Symington, Keith Scott, and I explored some of the issues in 
> http://www.mitre.org/work/tech_papers/tech_papers_07/06_1000/06_1000.pdf, 
> but it really hasn't moved forward yet.  We're just not there yet...)
>
> Regards,
> Bob Durst
>
> *From:[email-masked] 
> [mailto:[email-masked]] *On Behalf Of *Burleigh, Scott 
> C (313B)
> *Sent:* Wednesday, April 18, 2012 4:58 PM
> *To:* Jim Wright; Ivancic, William D. (GRC-RHN0)
> *Cc:* [email-masked]
> *Subject:* Re: [dtn-interest] Custody transfer specification in RFC5050
>
> 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:[email-masked] 
> <mailto:[email-masked]> [[email-masked]] 
> on behalf of Jim Wright [[email-masked]]
> *Sent:* Wednesday, April 18, 2012 1:43 PM
> *To:* Ivancic, William D. (GRC-RHN0)
> *Cc:* [email-masked] <mailto:[email-masked]>
> *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.
>
> 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
>
> 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
>
> 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
>
> [email-masked] <mailto:[email-masked]>
>
> 303-492-1579
>
> [email-masked] <mailto:[email-masked]>

---

From: "Fall, Kevin" <[email-masked]>
Date: Thu, 19 Apr 2012 14:26:44 +0000

I've also generally assumed that when a bundle indicates custody transfer that its selected routed may be different than routes for bundles for which custody has not been requested… although I'm not sure anyone has actually implemented this.
- K

---

From: "Burleigh, Scott C (313B)" <[email-masked]>
Date: Fri, 20 Apr 2012 16:48:32 +0000

Jim, the storage management issues Bob brings up might be worth a few more words of discussion:

*         It's not quite the case that the storage associated with a bundle can be recovered at any time unless custody has been accepted.  Acceptance of custody is one of the constraints that inhibit the discarding of a bundle (section 5.14 of the BP spec), but there are others.  The bundle can't be discarded while dispatch is pending (i.e., while a forwarding decision is still in progress) or while forwarding is pending (i.e., while the selected convergence layer adapters have not yet informed the bundle protocol agent that they have concluded their data sending procedures - successfully or unsuccessfully - with regard to this bundle) or while bundle reassembly from this (fragmentary) bundle is pending.  The first and third of these are pretty obvious, but the second may be less so: retention of the bundle until after it has been forwarded - or forwarding failure has been reported - isn't just a good idea, it's actually required.

*         Extending more favorable retention treatment to a bundle for which custody has been accepted is certainly consistent with the concept of custody transfer as understood by DTNRG, but not as an RFC 5050 requirement.  That is, not only is retention of a bundle after all retention constraints have been removed a discretionary feature that is implemented in DTN2, but also the policy for selecting which of these retained bundles (retained at the discretion of the implementation, fully in conformance with RFC 5050 but not required by RFC 5050) to discard during periods of congestion is likewise a DTN2 implementation feature.

*         On the other hand, discarding a bundle for which custody has been accepted (prior to its lifetime expiration) really isn't RFC5050-compliant unless transmission is explicitly canceled by the application or some operational anomaly is encountered.  I think you can define extreme congestion to be such an anomaly, but RFC5050 doesn't do so; this is an implementation decision.  So yes, if node C gets blown up or crashes and loses persistent state then the bundles for which it has accepted - and not yet released - custody will get discarded.  But otherwise they may well be there for the duration; a conformant implementation might simply stop receiving any more bundles until storage is recovered by bundle lifetime expirations and/or explicit cancellation of bundle transmissions.

Scott

From: Durst, Robert C. [mailto:[email-masked]]
Sent: Thursday, April 19, 2012 5:10 AM
To: Burleigh, Scott C (313B); Jim Wright; Ivancic, William D. (GRC-RHN0)
Cc: [email-masked]
Subject: RE: [dtn-interest] Custody transfer specification in RFC5050

Jim,

Regards,
Bob Durst

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Burleigh, Scott C (313B)

Scott

Jim

- Will

Thanks,
Jim

---

From: Bill Immerman <[email-masked]>
Date: Fri, 20 Apr 2012 14:36:57 -0400

I'm sure I'm missing something, and the discussion of storage
management in custody transfer is very interesting wrt implementation
issues, but in terms of the original comment about custody transfer
being about getting a "warm and fuzzy" and whether the node will "do
its best to forward anyway" isn't connection opportunity at least as
significant a resource in DTN as storage, and isn't the point of
custody transfer to move the chains forward when that opportunity
exists? I would think that at least as significant a reason to
transfer custody would be the reverse (acknowledgement) traffic: if I
transfer custody when an opportunity exists, downstream the receiving
node should only have to acknowledge to a node that is closer and more
likely to be available than the node that transferred custody. I would
guess that typically the node granting custody might be more likely to
be able to receive acknowledgement shortly after transmitting the
bundle, but in the worst case might be unable for some substantial
time after becoming disconnected to be reached for acknowledgement.
Maybe forever.

Am I misunderstanding what a correctly implemented custody transfer
would accomplish?

Thanks,
Bill Immerman

On 4/20/12, Burleigh, Scott C (313B) <[email-masked]> wrote:
> *         It's not quite the case that the storage associated with a bundle
> can be recovered at any time unless custody has been accepted.  Acceptance
> of custody is one of the constraints that inhibit the discarding of a bundle
> (section 5.14 of the BP spec), but there are others.  The bundle can't be
> discarded while dispatch is pending (i.e., while a forwarding decision is
> still in progress) or while forwarding is pending (i.e., while the selected
> convergence layer adapters have not yet informed the bundle protocol agent
> that they have concluded their data sending procedures - successfully or
> unsuccessfully - with regard to this bundle) or while bundle reassembly from
> this (fragmentary) bundle is pending.  The first and third of these are
> pretty obvious, but the second may be less so: retention of the bundle until
> after it has been forwarded - or forwarding failure has been reported -
> isn't just a good idea, it's actually required.
>
> *         Extending more favorable retention treatment to a bundle for which
> custody has been accepted is certainly consistent with the concept of
> custody transfer as understood by DTNRG, but not as an RFC 5050 requirement.
>  That is, not only is retention of a bundle after all retention constraints
> have been removed a discretionary feature that is implemented in DTN2, but
> also the policy for selecting which of these retained bundles (retained at
> the discretion of the implementation, fully in conformance with RFC 5050 but
> not required by RFC 5050) to discard during periods of congestion is
> likewise a DTN2 implementation feature.
>
> *         On the other hand, discarding a bundle for which custody has been
> accepted (prior to its lifetime expiration) really isn't RFC5050-compliant
> unless transmission is explicitly canceled by the application or some
> operational anomaly is encountered.  I think you can define extreme
> congestion to be such an anomaly, but RFC5050 doesn't do so; this is an
> implementation decision.  So yes, if node C gets blown up or crashes and
> loses persistent state then the bundles for which it has accepted - and not
> yet released - custody will get discarded.  But otherwise they may well be
> there for the duration; a conformant implementation might simply stop
> receiving any more bundles until storage is recovered by bundle lifetime
> expirations and/or explicit cancellation of bundle transmissions.
>
> Scott
>
> Adding to what Scott said, I'd like to follow up on the point about bundle
> storage management.  First, you may be interested in the following, by Fall,
> Hong, and Madden:  http://www.dtnrg.org/docs/papers/custody-xfer-tr.pdf
>
> Unless custody transfer is requested and has been accepted, a bundle node is
> free to recover the storage associated with a bundle at essentially any
> time.  In practice, that usually happens after it's been forwarded :).  In
> DTN2, there's a run-time configuration option that permits bundles to be
> retained in storage until they time out.  This is usually not set and was
> put in for diagnostic purposes.  However, for multicast distribution in
> time-disjoint networks, it has the beneficial effect of allowing
> late-joiners to a group to acquire bundle content that is already in
> storage.
>
> (In the paper "Multicasting in Delay Tolerant Networks: Semantic Models and
> Routing Algorithms" by Zhao, Ammar, and Zegura, ref.
> corresponds to the "Temporal Membership Model." In that model, the intended
> receivers of a multicast message are those who are members of the multicast
> endpoint at any time during the period [t1, t2], where the bounds of the
> membership interval are t1=the time of bundle generation and t2=the time of
> bundle expiration.  I don't believe that the DTN2 implementation fully
> implements this model, because I believe it only delivers to current members
> at the time of bundle receipt or future members at the time of late joining.
>  It doesn't go back and deliver to members whose time of departure from the
> multicast endpoint is later than t1.  There are several options that a DTN
> presents in multicasting that are different from traditional multicasting in
> a connected network; this paper is worth a read to either confirm existing
> notions or open new avenues of thought.)
>
> requested on a bundle or not accepted by the forwarder, then (for bundles
> destined to a singleton endpoint) typically the bundle storage is recovered
> after the bundle is forwarded.  If custody transfer is accepted by the
> forwarder, then it promises to treat that bundle's storage more favorably
> than that of non-custodial bundles.  If it gets horribly congested, the
> forwarder is going to dump non-custodial bundles (meaning those for which it
> has not accepted custody, irrespective of whether custody was requested on
> those bundles) before it dumps ones for which it has accepted custody.
> That's really the main difference in custody transfer as far as bundle
> storage goes.  In your example below, B would be under no obligation to show
> preferential treatment to the bundle, because it hadn't accepted custody,
> while C is expected to try really, really hard not to delete the bundle
> before  it receives a signal from some node downstream accepting custody of
> it.  (If node C gets blown up or crashes and loses its persistent state,
> there's little that can be done, hence the "really, really hard."  The
> expectation is roughly the same as your mortgage payment...)  Once custody
> has been accepted, the node is free to recover the storage.
>
> (There isn't really a custodial model for multicast DTN traffic.  Susan
> Symington, Keith Scott, and I explored some of the issues in
> From: [email-masked]<mailto:[email-masked]>
> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
> On Behalf Of Burleigh, Scott C (313B)
> 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: [email-masked]<mailto:[email-masked]>
> [[email-masked]] on behalf of Jim Wright
> [[email-masked]]
> 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.
>
> 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
>
>
> 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
>
>
>
> 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

---

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Fri, 20 Apr 2012 14:29:22 -0500

On Apr 20, 2012, at 2:36 PM, Bill Immerman wrote:

> issues,

> but in terms of the original comment about custody transfer
> its best to forward anyway"

Yes that was sort of my question.  Actually, all the implementations I have seen WILL do its best to forward a bundle if received.  Custody just provides a priority of some sort (implementation dependent) - not that  it has been fully tested in any or all implementations.

> isn't connection opportunity at least as
> significant a resource in DTN as storage,

Most likely depends on the deployment scenario. But, yes, connection opportunity is something to consider.  You may know it a-priori as with contract graph routing (as least you sort of know), or you may not have much clue as with opportunistic totally random, or you may have some clue via past history build up (Prophet)

> and isn't the point of
> exists?

Sort of, but maybe not when the first opportunity exists.  For example, what if I have a bundle with no custody but has 1 day to live and I have another bundle with custody that has 1 YEAR to live?  You may decide to forward the custody bundle first and then the Non-custody bundle dies.  Hence my original question.  Does custody transfer really help? Or perhaps hurt? or perhaps a wash (in which case you have expended a lot of energy for no gain)?

> I would think that at least as significant a reason to
> transfer custody would be the reverse (acknowledgement) traffic:

I think in CCSDS CFDP, custody sort of was as much an Ack that the File was receive by Node B from Node A and Node A could release if from memory.  With DTN it is a little more abstracted.  The interface between the Bundling Agent and convergence layer Ack that the bundle was fully or partially received (DTN2 does reactive fragmentation in the TCP convergence layer).  This Ack is NOT tthe same a accepting custody.  Node B can the forward to Node C which accepts Custody and (if at all possible) notifies A  (and perhaps that notification goes through a different path entirely).

http://public.ccsds.org/publications/archive/727x0b4.pdf
See section 2.3.4 and 2.4
Remember DTN RFC5050 has heritage in CFDP with Liklider Transport very closely matching the transport part of CFDP.
(Interestingly, if I read it correctly, CFDP allows one to receive part of a file and begin moving it forward.  DTN, particularly with security or CRC checks does not really lend itself to such.)

> if I
> likely to be available than the node that transferred custody.

Careful - "closer" assumes a particular topology, and/or what does "closer" mean?

The node that accepted custody has to notify the node that requested release of custody (granted custody).  Otherwise, the requesting release of custody has no clue that the bundle was successfully transmitted AND received AND accepted.  I'm not sure that is what you stated above.

> I would

Correct.

- Will

---

From: "Burleigh, Scott C (313B)" <[email-masked]>
Date: Fri, 20 Apr 2012 19:31:31 +0000

There are a few cases in which a node cannot arbitrarily ignore a request to take custody:
-	If the attempt to forward a bundle fails, and custody transfer was requested for the bundle, then transmission of a Failed custody signal back to the current custodian is mandatory.
-	If custody of a previously received copy of the same bundle has already been taken, then transmission of a Failed custody signal back to the current custodian is mandatory.
-	When a bundle for which custody transfer is requested is delivered to its destination endpoint, transmission of a Succeeded custody signal back to the current custodian is mandatory.

But otherwise the node is free to decide whether or not to attempt to take custody.

Deciding not to attempt to take custody does not cause any signal to go back to the current custodian.  There is no signal for actively "rejecting" custody at whim; instead, the node just silently proceeds with forwarding the bundle.  This leaves the current custodian in the dark, forced to retain its copy of the bundle at least until the bundle reaches the next node in the path.

If the node decides that it will attempt to take custody, then a custody signal is always going to be returned, indicating either that the attempt Succeeded or that it Failed for some reason such as insufficient storage space.  This gives the current custodian an opportunity to act, potentially enabling recovery of storage one way or another.

So I think you've got it right, Bill: when a node decides not to attempt to take custody of a bundle for which custody transfer is requested, it always does the current custodian a small disservice.  There may be good reasons to make such a decision, but there are also consequences.

Scott

-----Original Message-----
From: Bill Immerman [mailto:[email-masked]] 
Sent: Friday, April 20, 2012 11:37 AM
To: Burleigh, Scott C (313B)
Cc: Durst, Robert C.; Jim Wright; Ivancic, William D. (GRC-RHN0); [email-masked]
Subject: Re: [dtn-interest] Custody transfer specification in RFC5050

I'm sure I'm missing something, and the discussion of storage management in custody transfer is very interesting wrt implementation issues, but in terms of the original comment about custody transfer being about getting a "warm and fuzzy" and whether the node will "do its best to forward anyway" isn't connection opportunity at least as significant a resource in DTN as storage, and isn't the point of custody transfer to move the chains forward when that opportunity exists? I would think that at least as significant a reason to transfer custody would be the reverse (acknowledgement) traffic: if I transfer custody when an opportunity exists, downstream the receiving node should only have to acknowledge to a node that is closer and more likely to be available than the node that transferred custody. I would guess that typically the node granting custody might be more likely to be able to receive acknowledgement shortly after transmitting the bundle, but in the worst case might be unable for some substantial time after becoming disconnected to be reached for acknowledgement.
Maybe forever.

Am I misunderstanding what a correctly implemented custody transfer would accomplish?

Thanks,
Bill Immerman

On 4/20/12, Burleigh, Scott C (313B) <[email-masked]> wrote:
> can be recovered at any time unless custody has been accepted.  
> Acceptance of custody is one of the constraints that inhibit the 
> discarding of a bundle (section 5.14 of the BP spec), but there are 
> others.  The bundle can't be discarded while dispatch is pending 
> (i.e., while a forwarding decision is still in progress) or while 
> forwarding is pending (i.e., while the selected convergence layer 
> adapters have not yet informed the bundle protocol agent that they 
> have concluded their data sending procedures - successfully or 
> unsuccessfully - with regard to this bundle) or while bundle 
> reassembly from this (fragmentary) bundle is pending.  The first and 
> third of these are pretty obvious, but the second may be less so: 
> retention of the bundle until after it has been forwarded - or forwarding failure has been reported - isn't just a good idea, it's actually required.
>
>  That is, not only is retention of a bundle after all retention 
> constraints have been removed a discretionary feature that is 
> implemented in DTN2, but also the policy for selecting which of these 
> retained bundles (retained at the discretion of the implementation, 
> fully in conformance with RFC 5050 but not required by RFC 5050) to 
> discard during periods of congestion is likewise a DTN2 implementation feature.
>
> accepted (prior to its lifetime expiration) really isn't 
> RFC5050-compliant unless transmission is explicitly canceled by the 
> application or some operational anomaly is encountered.  I think you 
> can define extreme congestion to be such an anomaly, but RFC5050 
> doesn't do so; this is an implementation decision.  So yes, if node C 
> gets blown up or crashes and loses persistent state then the bundles 
> for which it has accepted - and not yet released - custody will get 
> discarded.  But otherwise they may well be there for the duration; a 
> conformant implementation might simply stop receiving any more bundles 
> until storage is recovered by bundle lifetime expirations and/or explicit cancellation of bundle transmissions.
>
> Scott
>
> Unless custody transfer is requested and has been accepted, a bundle 
> essentially any time.  In practice, that usually happens after it's 
> been forwarded :).  In DTN2, there's a run-time configuration option 
> that permits bundles to be retained in storage until they time out.  
> the multicast endpoint at any time during the period [t1, t2], where 
> the bounds of the membership interval are t1=the time of bundle 
> generation and t2=the time of bundle expiration.  I don't believe that 
> the DTN2 implementation fully implements this model, because I believe 
> it only delivers to current members at the time of bundle receipt or future members at the time of late joining.
>  It doesn't go back and deliver to members whose time of departure 
> from the multicast endpoint is later than t1.  There are several 
> options that a DTN presents in multicasting that are different from 
> is recovered after the bundle is forwarded.  If custody transfer is 
> bundles (meaning those for which it has not accepted custody, 
> irrespective of whether custody was requested on those bundles) before it dumps ones for which it has accepted custody.
> storage goes.  In your example below, B would be under no obligation 
> to show preferential treatment to the bundle, because it hadn't 
> accepted custody, while C is expected to try really, really hard not 
> to delete the bundle before  it receives a signal from some node 
> downstream accepting custody of it.  (If node C gets blown up or 
> crashes and loses its persistent state, there's little that can be 
> done, hence the "really, really hard."  The expectation is roughly the 
> same as your mortgage payment...)  Once custody has been accepted, the node is free to recover the storage.
>
> http://www.mitre.org/work/tech_papers/tech_papers_07/06_1000/06_1000.p
> df, but it really hasn't moved forward yet.  We're just not there 
> yet...)
>
> Regards,
> Bob Durst
>
> From: 
> [email-masked]<mailto:[email-masked]>
> 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: 
> [email-masked]<mailto:[email-masked]>
> the only way to flush bundles from a node's storage would be through timeout.
>
> but node B does not take custody of the bundle. Node C receives the bundle and accepts custody.
> being a required step for forwarding of bundles in the network. So does this make sense and answer my question?
>
> Jim
>
>
> 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.
>
>
> different destinations, what is the proper algorithm to decide which to forward first?
>
> taking custody of the bundle. It seems every Bundle Node MUST implement custody transfer.
>

---

From: Eric Travis <[email-masked]>
Date: Fri, 20 Apr 2012 23:39:36 -0400

Will,

An interesting discussion.

I have some notes/comments that included inline below:

Eric

> Yes that was sort of my question.  Actually, all the implementations I
have
> seen WILL do its best to forward a bundle if received.  Custody just
> provides a priority of some sort (implementation dependent) - not that  it
> has been fully tested in any or all implementations.

*Your judgement of the utility of custody seems to be predicated on the
following assumptions:

  1.  All the implementations you have seen reflect the *minimum*
functionality specified in RFC 5050. (The implementations are an accurate
reflection of *all* possible compliant implementations)

  2.  No convergence layer implementation will *ever* indicate a forwarding
failure because it will keep trying over multiple contact opportunities
until it is successful (a bad assumption for multitude reasons)

  3. Should the convergence layer actually report a forwarding failure, a
non-custodial bundle *will* be forwarded again at a later time.

I trust your experience here but my concerns are based on the current
specification (only the contents of the RFC)…

I'm confident that the implementations you are familiar with implement a
*superset* of RFC 5050;  That's not a bad thing, but it should not shape
your expectations of the behavior of *all* RFC-compliant implementations.
 You should only depend on the (minimum) functionality and policies
identified in the RFC.

I don't believe that (2) is - or can be - a requirement of all convergence
layers.
Similarly, I don't believe that (3) is required by RFC 5050.

In fact from my interpretation of RFC 5050, (5.4.2, Step 2) dictates that a
non-custodial bundle MUST be *deleted* in response to a forwarding failure
indication.  I suppose the "get out of jail" card for this would be an
implementation policy invoked in (5.4.1, Step 1) that maps a convergence
layer failure to "try again" rather than "forwarding failure".  Or, I can
be misinterpreting the text.  Regardless:

At best, RFC 5050 allows for a forwarding node to be *arbitrarily*
persistent in forwarding non-custodial bundles.

It is custodial service that *will* get you the persistence in delivery
service that you are implying/expecting above.*

> Most likely depends on the deployment scenario. But, yes, connection
> opportunity is something to consider.  You may know it a-priori as with
> contract graph routing (as least you sort of know), or you may not have
much
> clue as with opportunistic totally random, or you may have some clue via
> past history build up (Prophet)
>
>
>> and isn't the point of
> Sort of, but maybe not when the first opportunity exists.  For example,
what
> if I have a bundle with no custody but has 1 day to live and I have
another
> bundle with custody that has 1 YEAR to live?  You may decide to forward
the
> custody bundle first and then the Non-custody bundle dies.  Hence my
> original question.  Does custody transfer really help? Or perhaps hurt? or
> perhaps a wash (in which case you have expended a lot of energy for no
> gain)?

*It all depends on policy, but if I risk making an assumption, it would be
that bundles marked for custodial handling are considered to be more
valuable/higher priority than non-custodial bundles. For example, an
unremarkable hourly temperature sample could be sourced as non-custodial
and an indication that somebody just stole the rover's hubcaps would likely
be sent custodial.

Custodial operation has the same potential downsides as a priority
mechanism, it can be abused to the point of being harmful - but that is a
failure of policy rather than mechanism.

I can't help but think you are generally skeptical about the utility of a
custody transfer mechanism for bundle operations.  I'd like to try and help
you to change your mind...

Consider the strawman A->B->C->D network with the following mapping:

    A == rover or sensor located on a distant rock
    B == polar orbiter in proximity of same distant rock
    C == dedicated communications relay satellite for distant rock
activities
    D == terrestrial Deep Space Network (aggregate node)

Here, for at least some of the bundles sourced on the distant rock, custody
transfer makes perfect sense.  The custody of the bundle is transferred to
successively more capable, less vulnerable entities.  Retransmission of the
bundle (should it be necessary) is off-loaded from the most "expensive"
hops and also closes the reliability feedback look more quickly.

Custody transfer also makes sense for bundles flowing in the reverse
direction for the same reasons.

Custody transfer decisions will always be policy decisions.  To me, the
scenario above is a gimmee.  For more arbitrary cases, I'd have to fall
back to using terminology and concepts that didn't make the leap from IPN
-> DTN - but the original idea was custody would transfer to more capable
and/or advantaged intermediate nodes.  "Capable" and "advantaged" are terms
defined according to the network and its value system (read: it is all
about the policy).*

> I think in CCSDS CFDP, custody sort of was as much an Ack that the File
was
> receive by Node B from Node A and Node A could release if from memory.
 With
> DTN it is a little more abstracted.  The interface between the Bundling
> Agent and convergence layer Ack that the bundle was fully or partially
> received (DTN2 does reactive fragmentation in the TCP convergence layer).
> This Ack is NOT tthe same a accepting custody.  Node B can the forward to
> Node C which accepts Custody and (if at all possible) notifies A  (and
> perhaps that notification goes through a different path entirely).
>
> Remember DTN RFC5050 has heritage in CFDP with Liklider Transport very
> closely matching the transport part of CFDP.
> (Interestingly, if I read it correctly, CFDP allows one to receive part
of a
> file and begin moving it forward.  DTN, particularly with security or CRC
> checks does not really lend itself to such.)
>
>
>> if I
> Careful - "closer" assumes a particular topology, and/or what does
"closer"
> mean?

*Substitute "closer" for "more advantaged" and see above :)

Note, at least for space networks of the foreseeable future I believe the
concept of "closer" used above will be easy to handle in policy definition.*

> The node that accepted custody has to notify the node that requested
release
> of custody (granted custody).  Otherwise, the requesting release of
custody
> has no clue that the bundle was successfully transmitted AND received AND
> accepted.  I'm not sure that is what you stated above.

*Assuming (I know, I know...) there exists a rational mechanism for
determining an expected custody transfer time (countdown?), this should not
present any real issue - especially in networks where connectivity episodes
(even N-hops from the source/custodian) are highly predictable.
*

---

From: "Burleigh, Scott C (313B)" <[email-masked]>
Date: Sun, 22 Apr 2012 15:11:14 +0000

Will, a couple more thoughts along the lines of Eric's comments.

Scott

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ivancic, William D. (GRC-RHN0)
Sent: Friday, April 20, 2012 12:29 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dtn-interest] Custody transfer specification in RFC5050

On Apr 20, 2012, at 2:36 PM, Bill Immerman wrote:

> issues, but in terms of the original comment about custody transfer being 
> about getting a "warm and fuzzy" and whether the node will "do its 
> best to forward anyway"

----- Not priority, really; the custody procedures are mainly rules restricting the node's authorization to discard a bundle for which custody has been accepted (leaving up to the implementation the decision on just how those rules will be accommodated).  And actually I think those procedures have been fully tested in several implementations.

> isn't connection opportunity at least as significant a resource in DTN 
> as storage,

----- I don't think it's really so dependent on the deployment scenario: if a node under-utilizes its transmission and reception opportunities then it is simply underperforming, regardless of how it becomes aware of those opportunities.

----- This is a fair question, worth studying.  Custody transfer is an operational option like any other; it's not magic, it doesn't guarantee delivery success, but it forces some behavior that can confer some advantage.  On the other hand, it imposes some cost and there are other ways to obtain some of the advantage it confers.  It might be good to see some serious research here, starting with a definition of the exact metrics on which we'd measure the degree to which custody transfer "helps" or "hurts".

> I would think that at least as significant a reason to transfer 
> custody would be the reverse (acknowledgement) traffic:

----- Not really a problem, I think.  Basic "class 2" CFDP doesn't support this incremental forwarding, only the rarely implemented Extended Procedures do.  But DTN provides this capability quite easily: if you use DTN as the "UT layer" underlying CFDP then you wrap each CFDP file data PDU in its own Bundle, and from that point on all of these different portions of the file travel independently through the network until the file is reassembled at the final destination.

----- I think "closer" has a clear topology-independent meaning here, though: it simply means fewer hops along the path, right?

----- Which I think is the cost that Bill was alluding to: the less promptly some downstream node formally accepts custody of the bundle, the longer the custodian has to devote resources to it.

Correct.

- Will

---

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Mon, 23 Apr 2012 07:55:08 -0500

> ----- Not really a problem, I think.  Basic "class 2" CFDP doesn't support this incremental forwarding, only the rarely implemented Extended Procedures do.  But DTN provides this capability quite e…

Care must be taken that bundle forward tables don't explode.  Consider 3 multi-Gbyte files from 3 going from 3 different sources to 3 different destinations.  If you break those down into small bundles - say 64 Kbtyes - and then add stuff like BAB, you may find your bundle tables are unmanagable.  Also, you will be ACKing each small bundle which may congest the back channel.  - No free lunch.

> ----- I think "closer" has a clear topology-independent meaning here, though: it simply means fewer hops along the path, right?

I think so. But in a DTN, less hops may not be better.  

- Will

---

From: "Burleigh, Scott C (313B)" <[email-masked]>
Date: Mon, 23 Apr 2012 14:50:48 +0000

Will, of course you're right, resource management is one of the most challenging aspects of DTN, maybe in some ways the most challenging.  But you can design for it, and if you are careful about configuration you can do quite a lot even with limited memory and storage.

In the specific case of CFDP over DTN, you're again correct that splitting multi-gigabyte files into 64-Kbyte file data segments will result in a whole lot of bundles to manage and -- if you're using custody transfer -- a whole lot of acknowledgment traffic.  Nobody was thinking about multi-gigabyte files back when CFDP was designed, and CCSDS is now beginning the process of revisiting and upgrading CFDP to address this requirement and several others that have emerged over the past few years.  The limit on CFDP file data segment size will likely increase by many binary orders of magnitude.

Scott

-----Original Message-----
From: Ivancic, William D. (GRC-RHN0) [mailto:[email-masked]] 
Sent: Monday, April 23, 2012 5:55 AM
To: Burleigh, Scott C (313B)
Cc: [email-masked]; [email-masked]
Subject: Re: [dtn-interest] Custody transfer specification in RFC5050

> (Interestingly, if I read it correctly, CFDP allows one to receive 
> part of a file and begin moving it forward.  DTN, particularly with 
> security or CRC checks does not really lend itself to such.)
>