Subject: [dtn] custody transfer I-D

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Fri, 23 Jun 2017 00:04:41 +0000

Hi.  A few minutes ago I posted an Internet Draft (https://datatracker.ietf.org/doc/draft-burleigh-dtn-bibect/) presenting an idea I had a couple of months ago for cleanly breaking the Custody Transfer procedures out of BP and into a separate document.

In a nutshell, I suggest that we standardize the Bundle-in-Bundle Encapsulation (BIBE) convergence-layer protocol and build Custody Transfer into it, making BIBE a reliable CL.

I am confident that this sounds insane to most people who are reading this email.  But I think I can actually make a fairly strong case for it.

I've been claiming for some time that reliable convergence-layer protocols (TCP, LTP) are the best way to provide end-to-end delivery reliability in DTN.  Custody transfer is not as good because (a) there are no partial NAKs, so the only option on any data loss, no matter how small, is to re-send the entire bundle (which may be hundreds of megabytes); (b) there are no negative ACKs that indicate data loss (custody refusal actually indicates successful data arrival, just at an incapable forwarding point), so recovery from data loss happens only when a timer expires at the current custodian; (c) but it is in the general case impossible to set the timeout value for that timer because no node is ever required to take custody.  You never know (in the general case) who the next custodian will be, so you have no idea what the round-trip time to the next custodian is.

At the same time, Keith Scott has been saying that some important use cases need custody transfer instead of reliable CLAs because no suitable reliable convergence-layer protocol exists: the forward path is unidirectional, the return path is very different, and delay-tolerant hop-by-hop forwarding is needed in one or both.

Suppose we are both exactly right.  Let's make custodial retransmission a property of a (now reliable) convergence-layer protocol that performs delay-tolerant hop-by-hop forwarding, because the CL's protocol data units are bundles.  Like BIBE.

In the specification I just posted, BIBE CT works in much the same way that CT works in RFC 5050, only a little simpler.  The outbound bundle forms the payload of an encapsulating bundle destined for the next custodian, which might - but would not have to - be the next BP node on the end-to-end path.  On arrival of the encapsulating bundle at the destination node, the CLA at that node extracts the payload (the original bundle) and decides whether or not to accept custody.  It sends a custody signal back to the sending CLA, either accepting or refusing custody, and on acceptance it passes the payload bundle up to the BPA for processing as usual (forwarding, delivery, etc.).  The sending CLA receives and processes custody signals, destroys its copy of the cited original bundle upon custody acceptance, and re-encapsulates and re-transmits the original bundle upon either custody refusal or timer expiration prior to receipt of a responding custody signal.

I think this formulation offers a lot of advantages:

*        The problem of custodial bundle fragmentation by a non-custodial forwarding node goes away: no node other than the next custodian ever sees the encapsulated bundle, therefore cannot fragment it.  The encapsulating (BIBE) bundle might get fragmented, absolutely, but it gets reassembled at the destination (the next custodian) before any CT processing occurs.  So all of the complexity of fragmentary custody transfer disappears.

*        Custody transfer suddenly becomes compatible with multi-point delivery.  If you use bundle multicast as prototyped in ION, then each copy of the bundle that is forwarded through the multicast tree is (naturally) conveyed using a point-to-point convergence-layer transfer - which could easily be a BIBE transfer with CT requested.

*        Looking out a little further, knowing the identity of the next custodian means that CT can take advantage of bundle delivery time estimation mechanisms (which we prototyped a few years ago) to compute custodial retransmission timeout intervals.  So CT becomes more accurate and efficient as well.

*        The relationship of CT to the rest of BP becomes an extremely clean and simple interface, which can easily be added on to any BP implementation.  Implementation of CT becomes simple and self-contained.

*        Building CT into BIBE gives us a single CL protocol that can provide cross-domain security solutions, provide reliable disruption-tolerant forwarding over unidirectional links, or both.  And yet the protocol is extremely simple, only 13 pages.

It's radical, but I don't think it's wrong.

Scott

---

From: Lloyd Wood <[email-masked]>
Date: Fri, 23 Jun 2017 00:22:01 +0000 (UTC)

Hi Scott,

You've just reinvented source routing, with added tunnelling overhead for each specified relay/custodian.

https://en.wikipedia.org/wiki/Source_routing

Congratulations! 
Lloyd Wood
http://sat-net.com/L.Wood/dtn

________________________________
From: "Burleigh, Scott C (312B)" <[email-masked]>
To: "[email-masked]" <[email-masked]> 
Sent: Friday, 23 June 2017, 10:05
Subject: [dtn] custody transfer I-D

 
 
I’ve been claiming for some time that reliable convergence-layer protocols (TCP, LTP) are the best way to provide end-to-end delivery reliability in DTN.  Custody transfer is not as good because (a) there are no partial NAKs, so the only option on any data loss, no matter how small, is to re-send the entire bundle (which may be hundreds of megabytes); (b) there are no negative ACKs that indicate data loss (custody refusal actually indicates successful data arrival, just at an incapable forwarding point), so recovery from data loss happens only when a timer expires at the current custodian; (c) but it is in the general case impossible to set the timeout value for that timer because no node is ever required to take custody.  You never know (in the general case) who the next custodian will be, so you have no idea what the round-trip time to the next custodian is.

Suppose we are both exactly right.  Let’s make custodial retransmission a property of a (now reliable) convergence-layer protocol that performs delay-tolerant hop-by-hop forwarding, because the CL’s protocol data units are bundles.  Like BIBE.
 
In the specification I just posted, BIBE CT works in much the same way that CT works in RFC 5050, only a little simpler.  The outbound bundle forms the payload of an encapsulating bundle destined for the next custodian, which might – but would not have to – be the next BP node on the end-to-end path.  On arrival of the encapsulating bundle at the destination node, the CLA at that node extracts the payload (the original bundle) and decides whether or not to accept custody.  It sends a custody signal back to the sending CLA, either accepting or refusing custody, and on acceptance it passes the payload bundle up to the BPA for processing as usual (forwarding, delivery, etc.).  The sending CLA receives and processes custody signals, destroys its copy of the cited original bundle upon custody acceptance, and re-encapsulates and re-transmits the original bundle upon either custody refusal or timer expiration prior to receipt of a responding custody signal.
 
I think this formulation offers a lot of advantages:
·        The problem of custodial bundle fragmentation by a non-custodial forwarding node goes away: no node other than the next custodian ever sees the encapsulated bundle, therefore cannot fragment it.  The encapsulating (BIBE) bundle might get fragmented, absolutely, but it gets reassembled at the destination (the next custodian) before any CT processing occurs.  So all of the complexity of fragmentary custody transfer disappears.
·        Custody transfer suddenly becomes compatible with multi-point delivery.  If you use bundle multicast as prototyped in ION, then each copy of the bundle that is forwarded through the multicast tree is (naturally) conveyed using a point-to-point convergence-layer transfer – which could easily be a BIBE transfer with CT requested.
·        Looking out a little further, knowing the identity of the next custodian means that CT can take advantage of bundle delivery time estimation mechanisms (which we prototyped a few years ago) to compute custodial retransmission timeout intervals.  So CT becomes more accurate and efficient as well.
·        The relationship of CT to the rest of BP becomes an extremely clean and simple interface, which can easily be added on to any BP implementation.  Implementation of CT becomes simple and self-contained.
·        Building CT into BIBE gives us a single CL protocol that can provide cross-domain security solutions, provide reliable disruption-tolerant forwarding over unidirectional links, or both.  And yet the protocol is extremely simple, only 13 pages.
 
It’s radical, but I don’t think it’s wrong.
 
Scott

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Fri, 23 Jun 2017 00:38:12 +0000

Thanks for crediting me with such a useful invention!  But actually no I haven't, since the sender doesn't specify the route that the bundle takes through the network -- it only specifies the next-hop proximate destination node, just as with any convergence-layer protocol.

-----Original Message-----
From: Lloyd Wood [mailto:[email-masked]] 
Sent: Thursday, June 22, 2017 5:22 PM
To: Burleigh, Scott C (312B) <[email-masked]>; [email-masked]
Subject: Re: [dtn] custody transfer I-D

Hi Scott,

Congratulations! 
Lloyd Wood

 

 

 

Scott

---

From: "Marc Blanchet" <[email-masked]>
Date: Thu, 22 Jun 2017 21:09:28 -0400

On 22 Jun 2017, at 20:04, Burleigh, Scott C (312B) wrote:

> Hi.  A few minutes ago I posted an Internet Draft 
> (https://datatracker.ietf.org/doc/draft-burleigh-dtn-bibect/) 
> presenting an idea I had a couple of months ago for cleanly breaking 
> the Custody Transfer procedures out of BP and into a separate 
> document.
>
> In a nutshell, I suggest that we standardize the Bundle-in-Bundle 
> Encapsulation (BIBE) convergence-layer protocol and build Custody 
> Transfer into it, making BIBE a reliable CL.
>
> I am confident that this sounds insane to most people who are reading 
> this email.  But I think I can actually make a fairly strong case for 
> it.
>
> I've been claiming for some time that reliable convergence-layer 
> protocols (TCP, LTP) are the best way to provide end-to-end delivery 
> reliability in DTN.  Custody transfer is not as good because (a) there 
> are no partial NAKs, so the only option on any data loss, no matter 
> how small, is to re-send the entire bundle (which may be hundreds of 
> megabytes); (b) there are no negative ACKs that indicate data loss 
> (custody refusal actually indicates successful data arrival, just at 
> an incapable forwarding point), so recovery from data loss happens 
> only when a timer expires at the current custodian; (c) but it is in 
> the general case impossible to set the timeout value for that timer 
> because no node is ever required to take custody.  You never know (in 
> the general case) who the next custodian will be, so you have no idea 
> what the round-trip time to the next custodian is.
>
> At the same time, Keith Scott has been saying that some important use 
> cases need custody transfer instead of reliable CLAs because no 
> suitable reliable convergence-layer protocol exists: the forward path 
> is unidirectional, the return path is very different, and 
> delay-tolerant hop-by-hop forwarding is needed in one or both.

I’ll drop again my own perspective. There are other ways to manage 
reliable end-to-end: it is to do it at an upper layer. Again, IP is 
datagram, reliability is managed at a higher layer, at end points. 
Current Internet deployment has shown that almost every hop-by-hop 
« feature » failed to be deployed. Instead, e2e is the only way to 
deliver it. Therefore, I’m questioning the need for custody transfer.

Marc.

>
> Suppose we are both exactly right.  Let's make custodial 
> retransmission a property of a (now reliable) convergence-layer 
> protocol that performs delay-tolerant hop-by-hop forwarding, because 
> the CL's protocol data units are bundles.  Like BIBE.
>
> In the specification I just posted, BIBE CT works in much the same way 
> that CT works in RFC 5050, only a little simpler.  The outbound bundle 
> forms the payload of an encapsulating bundle destined for the next 
> custodian, which might - but would not have to - be the next BP node 
> on the end-to-end path.  On arrival of the encapsulating bundle at the 
> destination node, the CLA at that node extracts the payload (the 
> original bundle) and decides whether or not to accept custody.  It 
> sends a custody signal back to the sending CLA, either accepting or 
> refusing custody, and on acceptance it passes the payload bundle up to 
> the BPA for processing as usual (forwarding, delivery, etc.).  The 
> sending CLA receives and processes custody signals, destroys its copy 
> of the cited original bundle upon custody acceptance, and 
> re-encapsulates and re-transmits the original bundle upon either 
> custody refusal or timer expiration prior to receipt of a responding 
> custody signal.
>
> *        The problem of custodial bundle fragmentation by a 
> non-custodial forwarding node goes away: no node other than the next 
> custodian ever sees the encapsulated bundle, therefore cannot fragment 
> it.  The encapsulating (BIBE) bundle might get fragmented, absolutely, 
> but it gets reassembled at the destination (the next custodian) before 
> any CT processing occurs.  So all of the complexity of fragmentary 
> custody transfer disappears.
>
> *        Custody transfer suddenly becomes compatible with multi-point 
> delivery.  If you use bundle multicast as prototyped in ION, then each 
> copy of the bundle that is forwarded through the multicast tree is 
> (naturally) conveyed using a point-to-point convergence-layer transfer 
> - which could easily be a BIBE transfer with CT requested.
>
> *        Looking out a little further, knowing the identity of the 
> next custodian means that CT can take advantage of bundle delivery 
> time estimation mechanisms (which we prototyped a few years ago) to 
> compute custodial retransmission timeout intervals.  So CT becomes 
> more accurate and efficient as well.
>
> *        The relationship of CT to the rest of BP becomes an extremely 
> clean and simple interface, which can easily be added on to any BP 
> implementation.  Implementation of CT becomes simple and 
> self-contained.
>
> *        Building CT into BIBE gives us a single CL protocol that can 
> provide cross-domain security solutions, provide reliable 
> disruption-tolerant forwarding over unidirectional links, or both.  
> And yet the protocol is extremely simple, only 13 pages.
>

> _______________________________________________
> dtn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtn

---

From: Lloyd Wood <[email-masked]>
Date: Fri, 23 Jun 2017 01:13:35 +0000 (UTC)

Scott,

you can nest encapsulations recursively, not just once. BIBE in BE in BE... at each hop, a decap leads to a bundle specifying the next immediate custody destination. A route is, after all, just a concatenated series of next hops, or in this case of decapped bundles specifying new custody destinations, which the sender can specify by building bundle headers.

Incidentally, being able to do this kind of thing is a massive security concern, which is why source routing keeps getting rediscovered and then abandoned really quickly. Added fun with multicast destinations, too - see e.g. RFC5095 or RFC6554 section 5.

Are you going to say 'we can only tunnel once' or something, and actually expect people to obey that? Do try to think this through.

regards 

Lloyd Wood

the perpetual motion machine is still broken, I see.
________________________________
From: "Burleigh, Scott C (312B)" <[email-masked]>
To: Lloyd Wood <[email-masked]>; "[email-masked]" <[email-masked]> 
Sent: Friday, 23 June 2017, 10:38
Subject: Re: [dtn] custody transfer I-D

-----Original Message-----
From: Lloyd Wood [mailto:[email-masked]] 
Sent: Thursday, June 22, 2017 5:22 PM
To: Burleigh, Scott C (312B) <[email-masked]>; [email-masked]
Subject: Re: [dtn] custody transfer I-D

Hi Scott,

Congratulations! 
Lloyd Wood

Scott

---

From: Marius Feldmann <[email-masked]>
Date: Fri, 23 Jun 2017 10:02:04 +0200

Hi Scott,

with your approach we can state that a specific node on the path should
take the custody for a specific bundle (not just fragments created from
it). Thus, it renders it possible to define well-known nodes that
guarantee to take the original bundle (even if it has been fragmented
between the sender and this well-known node) and confirm custody for it.
As far as I get it, that is the basic point.

Let us assume we only have the proposed option available. How do we
transfer custody to an unknown node on the path? Thus, to transmit a
bundle with the requirement "Please, anybody on the path, take custody
for this bundle." or maybe even an extended variant: "Please, anybody on
the path, take custody for the whole or partial data encapsulated in
this bundle.".

I guess we need - at least additionally to the approach proposed by you
- protocol support to cover this case.

Marius

On 23.06.2017 02:04, Burleigh, Scott C (312B) wrote:
> the Custody Transfer procedures out of BP and into a separate document.
>
>  
>
> this email.  But I think I can actually make a fairly strong case for it.
>
>  
>
> I’ve been claiming for some time that reliable convergence-layer
> Suppose we are both exactly right.  Let’s make custodial
> the CL’s protocol data units are bundles.  Like BIBE.
>
>  
>
> custodian, which might – but would not have to – be the next BP node
> ·        The problem of custodial bundle fragmentation by a
> ·        Custody transfer suddenly becomes compatible with multi-point
> – which could easily be a BIBE transfer with CT requested.
>
> ·        Looking out a little further, knowing the identity of the
> ·        The relationship of CT to the rest of BP becomes an extremely
> implementation.  Implementation of CT becomes simple and self-contained.
>
> ·        Building CT into BIBE gives us a single CL protocol that can

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Fri, 23 Jun 2017 13:55:23 +0000

Nope, nested encapsulation is definitely part of the concept, as noted in Section 1.  You make a good point, Lloyd.  In general I think I would rather rely on authentication than routing to ensure network security, but certainly this sort of thing has been an attack vector in the Internet.

-----Original Message-----
From: Lloyd Wood [mailto:[email-masked]] 
Sent: Thursday, June 22, 2017 6:14 PM
To: Burleigh, Scott C (312B) <[email-masked]>; [email-masked]
Subject: Re: [dtn] custody transfer I-D

Scott,

regards 

Lloyd Wood

-----Original Message-----
From: Lloyd Wood [mailto:[email-masked]] 
Sent: Thursday, June 22, 2017 5:22 PM
To: Burleigh, Scott C (312B) <[email-masked]>; [email-masked]
Subject: Re: [dtn] custody transfer I-D

Hi Scott,

Congratulations! 
Lloyd Wood

Scott

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Fri, 23 Jun 2017 14:03:33 +0000

A valid perspective, Marc, but I think the fact that features like retransmission and rate control are performed hop-by-hop rather than end-to-end is part of what makes DTN a better fit for delay-afflicted networks than TCP/IP.  It works well; it's what's being deployed on ISS.

Scott

-----Original Message-----
From: Marc Blanchet [mailto:[email-masked]] 
Sent: Thursday, June 22, 2017 6:09 PM
To: Burleigh, Scott C (312B) <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn] custody transfer I-D

> delay-tolerant hop-by-hop forwarding is needed in one or both.

I’ll drop again my own perspective. There are other ways to manage reliable end-to-end: it is to do it at an upper layer. Again, IP is datagram, reliability is managed at a higher layer, at end points. 
Current Internet deployment has shown that almost every hop-by-hop « feature » failed to be deployed. Instead, e2e is the only way to deliver it. Therefore, I’m questioning the need for custody transfer.

Marc.

---

From: "Marc Blanchet" <[email-masked]>
Date: Fri, 23 Jun 2017 10:09:22 -0400

On 23 Jun 2017, at 10:03, Burleigh, Scott C (312B) wrote:

> A valid perspective, Marc, but I think the fact that features like 
> retransmission and rate control are performed hop-by-hop rather than 
> end-to-end is part of what makes DTN a better fit for delay-afflicted 
> networks than TCP/IP. It works well; it's what's being deployed on 
> ISS.

sure. rewriting my point: I’m ok with custody transfer, as long as it 
is not mandatory to implement and use for implementations, since some 
use other means (upper layers) to cover the same needs.

Marc (no hat)

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Fri, 23 Jun 2017 14:18:53 +0000

You're right, Marius, this approach excludes the option of saying "Please, anybody on the path, take custody of part or all of this bundle."  If we need that capability, then we would need a different - or additional - protocol to make that happen.

That is by design, though.  If you don't know who's going to take custody then you don't know when custody will be taken, and in that case you don't have any way of knowing that custody has not been taken, so there is no efficient way of triggering retransmission of the bundle from the current custodian.  So I think requiring that capability excludes the efficient discharge of custodial responsibility.

I have not yet heard of use cases that require custody transfer - including custodial retransmission - in operational scenarios where the current custodian forwards the bundle without knowing who the next custodian should be.  Are there any?

Scott

From: dtn [mailto:[email-masked]] On Behalf Of Marius Feldmann
Sent: Friday, June 23, 2017 1:02 AM
To: [email-masked]
Subject: Re: [dtn] custody transfer I-D

Hi Scott,

with your approach we can state that a specific node on the path should take the custody for a specific bundle (not just fragments created from it). Thus, it renders it possible to define well-known nodes that guarantee to take the original bundle (even if it has been fragmented between the sender and this well-known node) and confirm custody for it. As far as I get it, that is the basic point.

Let us assume we only have the proposed option available. How do we transfer custody to an unknown node on the path? Thus, to transmit a bundle with the requirement "Please, anybody on the path, take custody for this bundle." or maybe even an extended variant: "Please, anybody on the path, take custody for the whole or partial data encapsulated in this bundle.".

I guess we need - at least additionally to the approach proposed by you - protocol support to cover this case.

Marius

Scott

dtn mailing list

[email-masked]<mailto:[email-masked]>

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Fri, 23 Jun 2017 14:20:31 +0000

Marc, I totally agree.  I see that as one attractive aspect of breaking custody transfer out of BP and into a separate protocol specification.

Scott

-----Original Message-----
From: Marc Blanchet [mailto:[email-masked]] 
Sent: Friday, June 23, 2017 7:09 AM
To: Burleigh, Scott C (312B) <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn] custody transfer I-D

> networks than TCP/IP. It works well; it's what's being deployed on 

sure. rewriting my point: I’m ok with custody transfer, as long as it is not mandatory to implement and use for implementations, since some use other means (upper layers) to cover the same needs.

Marc (no hat)

>> reliability in DTN.  Custody transfer is not as good because (a) 
>> there are no partial NAKs, so the only option on any data loss, no 
>> matter how small, is to re-send the entire bundle (which may be 
>> hundreds of megabytes); (b) there are no negative ACKs that indicate 
>> data loss (custody refusal actually indicates successful data 
>> arrival, just at an incapable forwarding point), so recovery from 
>> data loss happens only when a timer expires at the current custodian; 
>> (c) but it is in the general case impossible to set the timeout value 
>> for that timer because no node is ever required to take custody.  You 
>> never know (in the general case) who the next custodian will be, so 
>> you have no idea what the round-trip time to the next custodian is.
>>
> Current Internet deployment has shown that almost every hop-by-hop « 
> feature » failed to be deployed. Instead, e2e is the only way to 
>> In the specification I just posted, BIBE CT works in much the same 
>> way that CT works in RFC 5050, only a little simpler.  The outbound 
>> bundle forms the payload of an encapsulating bundle destined for the 
>> next custodian, which might - but would not have to - be the next BP 
>> node on the end-to-end path.  On arrival of the encapsulating bundle 
>> at the destination node, the CLA at that node extracts the payload 
>> (the original bundle) and decides whether or not to accept custody.  
>> It sends a custody signal back to the sending CLA, either accepting 
>> or refusing custody, and on acceptance it passes the payload bundle 
>> up to the BPA for processing as usual (forwarding, delivery, etc.).  
>> The sending CLA receives and processes custody signals, destroys its 
>> copy of the cited original bundle upon custody acceptance, and 
>> custodian ever sees the encapsulated bundle, therefore cannot 
>> fragment it.  The encapsulating (BIBE) bundle might get fragmented, 
>> absolutely, but it gets reassembled at the destination (the next 
>> custodian) before any CT processing occurs.  So all of the complexity 
>> of fragmentary custody transfer disappears.
>>
>> delivery.  If you use bundle multicast as prototyped in ION, then 
>> each copy of the bundle that is forwarded through the multicast tree 
>> is

---

From: William Ivancic <[email-masked]>
Date: Fri, 23 Jun 2017 10:43:54 -0400

Marc.

BINGO!  You win Marc.  

https://upload.wikimedia.org/wikipedia/commons/thumb/1/14/German_Kewpie_with_Heart_Sticker.png/220px-German_Kewpie_with_Heart_Sticker.png

If a node gets a bundle.  Isn’t it supposed to do its best to forward it?  I know there is discussion on this on the mail list – probably multiple times.  Custody adds a warm fuzzy, but, in reality, does little to help and only creates complexity.  I suspect it is there from a “Space” perspective because of the history of how those systems operate.  Remember, DTN bundling has its origins in CFDP.

http://public.ccsds.org/Pubs/727x0b4.pdf

------------
Will

---

From: Marius Feldmann <[email-masked]>
Date: Fri, 23 Jun 2017 16:46:29 +0200

Yes, for sure this could be also realized as a separate mechanism (e.g.
extension block described in a separate document). To keep things
simple, in my opinion that should be the way to go.

The sketched scenario should be quite popular in opportunistic ad-hoc
networks in which the topology is not known in advance.

If we do not go for a solution, custody transfer is removed from all use
cases mentioned in [1] lacking apriori topological knowledge (e.g.
Vehicular Delay Tolerant Network, Disaster Response, ...).

Marius

[1] https://trac.ietf.org/trac/dtn/wiki/DtnUseCases

On 23.06.2017 16:18, Burleigh, Scott C (312B) wrote:
>
> You’re right, Marius, this approach excludes the option of saying
> “Please, anybody on the path, take custody of part or all of this
> bundle.”  If we need that capability, then we would need a different –
> or additional – protocol to make that happen.
>
>  
>
> That is by design, though.  If you don’t know who’s going to take
> custody then you don’t know when custody will be taken, and in that
> case you don’t have any way of knowing that custody has not been
> taken, so there is no efficient way of triggering retransmission of
> the bundle from the current custodian.  So I think requiring that
> capability excludes the efficient discharge of custodial responsibility.
>
>  
>
> I have not yet heard of use cases that require custody transfer –
> including custodial retransmission – in operational scenarios where
> the current custodian forwards the bundle without knowing who the next
> custodian should be.  Are there any?
>
>  
>
> Scott
>
>  
>
> *From:*dtn [mailto:[email-masked]] *On Behalf Of *Marius Feldmann
> *Sent:* Friday, June 23, 2017 1:02 AM
> *To:* [email-masked]
> *Subject:* Re: [dtn] custody transfer I-D
>
>  
>
> Hi Scott,
>
> with your approach we can state that a specific node on the path
> should take the custody for a specific bundle (not just fragments
> created from it). Thus, it renders it possible to define well-known
> nodes that guarantee to take the original bundle (even if it has been
> fragmented between the sender and this well-known node) and confirm
> custody for it. As far as I get it, that is the basic point.
>
> for this bundle." or maybe even an extended variant: "Please, anybody
> on the path, take custody for the whole or partial data encapsulated
> in this bundle.".
>
> I guess we need - at least additionally to the approach proposed by
> you - protocol support to cover this case.
>
> Marius
>
>  
>
>     presenting an idea I had a couple of months ago for cleanly
>     breaking the Custody Transfer procedures out of BP and into a
>     separate document.
>
>      
>
>     I am confident that this sounds insane to most people who are
>     reading this email.  But I think I can actually make a fairly
>     strong case for it.
>
>      
>
>     protocols (TCP, LTP) are the best way to provide end-to-end
>     delivery reliability in DTN.  Custody transfer is not as good
>     because (a) there are no partial NAKs, so the only option on any
>     data loss, no matter how small, is to re-send the entire bundle
>     (which may be hundreds of megabytes); (b) there are no negative
>     ACKs that indicate data loss (custody refusal actually indicates
>     successful data arrival, just at an incapable forwarding point),
>     so recovery from data loss happens only when a timer expires at
>     the current custodian; (c) but it is in the general case
>     impossible to set the timeout value for that timer because no node
>     is ever required to take custody.  You never know (in the general
>     case) who the next custodian will be, so you have no idea what the
>     round-trip time to the next custodian is.
>
>      
>
>     At the same time, Keith Scott has been saying that some important
>     use cases need custody transfer instead of reliable CLAs because
>     no suitable reliable convergence-layer protocol exists: the
>     forward path is unidirectional, the return path is very different,
>     and delay-tolerant hop-by-hop forwarding is needed in one or both.
>
>      
>
>     protocol that performs delay-tolerant hop-by-hop forwarding,
>     because the CL’s protocol data units are bundles.  Like BIBE.
>
>      
>
>     way that CT works in RFC 5050, only a little simpler.  The
>     outbound bundle forms the payload of an encapsulating bundle
>     destined for the next custodian, which might – but would not have
>     to – be the next BP node on the end-to-end path.  On arrival of
>     the encapsulating bundle at the destination node, the CLA at that
>     node extracts the payload (the original bundle) and decides
>     whether or not to accept custody.  It sends a custody signal back
>     to the sending CLA, either accepting or refusing custody, and on
>     acceptance it passes the payload bundle up to the BPA for
>     processing as usual (forwarding, delivery, etc.).  The sending CLA
>     receives and processes custody signals, destroys its copy of the
>     cited original bundle upon custody acceptance, and re-encapsulates
>     and re-transmits the original bundle upon either custody refusal
>     or timer expiration prior to receipt of a responding custody signal.
>
>      
>
>     non-custodial forwarding node goes away: no node other than the
>     next custodian ever sees the encapsulated bundle, therefore cannot
>     fragment it.  The encapsulating (BIBE) bundle might get
>     fragmented, absolutely, but it gets reassembled at the destination
>     (the next custodian) before any CT processing occurs.  So all of
>     the complexity of fragmentary custody transfer disappears.
>
>     ·        Custody transfer suddenly becomes compatible with
>     multi-point delivery.  If you use bundle multicast as prototyped
>     in ION, then each copy of the bundle that is forwarded through the
>     multicast tree is (naturally) conveyed using a point-to-point
>     convergence-layer transfer – which could easily be a BIBE transfer
>     with CT requested.
>
>     time estimation mechanisms (which we prototyped a few years ago)
>     to compute custodial retransmission timeout intervals.  So CT
>     becomes more accurate and efficient as well.
>
>     ·        The relationship of CT to the rest of BP becomes an
>     extremely clean and simple interface, which can easily be added on
>     to any BP implementation.  Implementation of CT becomes simple and
>     self-contained.
>
>     ·        Building CT into BIBE gives us a single CL protocol that
>     can provide cross-domain security solutions, provide reliable
>     disruption-tolerant forwarding over unidirectional links, or
>     both.  And yet the protocol is extremely simple, only 13 pages.
>
>      
>
>     [email-masked] <mailto:[email-masked]>
>

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Fri, 23 Jun 2017 14:57:26 +0000

Marius, I will suggest that you can still do custody transfer along these lines in an opportunistic ad-hoc network, so long as every node that receives the bundle takes custody.  The topology can be discovered dynamically, no problem.  It's only when you don't know who the next custodian will be - you have discovered a neighbor and will forward the bundle to that neighbor, but that neighbor won't take custody and you don't know who will - that there are problems.

You can still use DTN for vehicular networks, disaster response, etc., absolutely - but all nodes need to take responsibility in order for this to work.  Otherwise the current custodian has no way of knowing (in the general case) when to decide that forwarding has failed and the bundle has to be forwarded again.

Scott

From: dtn [mailto:[email-masked]] On Behalf Of Marius Feldmann
Sent: Friday, June 23, 2017 7:46 AM
To: [email-masked]
Subject: Re: [dtn] custody transfer I-D

Yes, for sure this could be also realized as a separate mechanism (e.g. extension block described in a separate document). To keep things simple, in my opinion that should be the way to go.

The sketched scenario should be quite popular in opportunistic ad-hoc networks in which the topology is not known in advance.

If we do not go for a solution, custody transfer is removed from all use cases mentioned in [1] lacking apriori topological knowledge (e.g. Vehicular Delay Tolerant Network, Disaster Response, ...).

Marius

Scott

From: dtn [mailto:[email-masked]] On Behalf Of Marius Feldmann
Sent: Friday, June 23, 2017 1:02 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [dtn] custody transfer I-D

Hi Scott,

Marius

Scott

dtn mailing list

dtn mailing list

---

From: Marius Feldmann <[email-masked]>
Date: Fri, 23 Jun 2017 17:14:57 +0200

Scott, right - I did not state that it is common in all opportunistic
ad-hoc networks but that it is a popular case in these networks (at
least if we assume the networks I see from a research perspective).

Though this is fine for me, we have to be aware that we exclude
scenarios in which the senders' direct neighbors forward bundles and
leave custody to the next hops on the path, e.g. because the direct
neighbors are just a sort of gateways or relays.

Marius

On 23.06.2017 16:57, Burleigh, Scott C (312B) wrote:
>
> Marius, I will suggest that you can still do custody transfer along
> these lines in an opportunistic ad-hoc network, so long as every node
> that receives the bundle takes custody.  The topology can be
> discovered dynamically, no problem.  It’s only when you don’t know who
> the next custodian will be – you have discovered a neighbor and will
> forward the bundle to that neighbor, but that neighbor won’t take
> custody and you don’t know who will – that there are problems.
>
>  
>
> You can still use DTN for vehicular networks, disaster response, etc.,
> absolutely – but all nodes need to take responsibility in order for
> this to work.  Otherwise the current custodian has no way of knowing
> (in the general case) when to decide that forwarding has failed and
> the bundle has to be forwarded again.
>
>  
>
> Scott
>
>  
>
> *Sent:* Friday, June 23, 2017 7:46 AM
> *To:* [email-masked]
> Yes, for sure this could be also realized as a separate mechanism
> (e.g. extension block described in a separate document). To keep
> things simple, in my opinion that should be the way to go.
>
> If we do not go for a solution, custody transfer is removed from all
> use cases mentioned in [1] lacking apriori topological knowledge (e.g.
>     bundle.”  If we need that capability, then we would need a
>     different – or additional – protocol to make that happen.
>
>      
>
>     custody then you don’t know when custody will be taken, and in
>     that case you don’t have any way of knowing that custody has not
>     been taken, so there is no efficient way of triggering
>     retransmission of the bundle from the current custodian.  So I
>     think requiring that capability excludes the efficient discharge
>     of custodial responsibility.
>
>      
>
>     including custodial retransmission – in operational scenarios
>     where the current custodian forwards the bundle without knowing
>     who the next custodian should be.  Are there any?
>
>      
>
>     Scott
>
>      
>
>     *To:* [email-masked] <mailto:[email-masked]>
>     created from it). Thus, it renders it possible to define
>     well-known nodes that guarantee to take the original bundle (even
>     if it has been fragmented between the sender and this well-known
>     node) and confirm custody for it. As far as I get it, that is the
>     basic point.
>
>     Let us assume we only have the proposed option available. How do
>     we transfer custody to an unknown node on the path? Thus, to
>     transmit a bundle with the requirement "Please, anybody on the
>     path, take custody for this bundle." or maybe even an extended
>     variant: "Please, anybody on the path, take custody for the whole
>     or partial data encapsulated in this bundle.".
>
>     I guess we need - at least additionally to the approach proposed
>     by you - protocol support to cover this case.
>
>     Marius
>
>      
>
>         In a nutshell, I suggest that we standardize the
>         Bundle-in-Bundle Encapsulation (BIBE) convergence-layer
>         protocol and build Custody Transfer into it, making BIBE a
>         reliable CL.
>
>          
>
>         I’ve been claiming for some time that reliable
>         convergence-layer protocols (TCP, LTP) are the best way to
>         provide end-to-end delivery reliability in DTN.  Custody
>         transfer is not as good because (a) there are no partial NAKs,
>         so the only option on any data loss, no matter how small, is
>         to re-send the entire bundle (which may be hundreds of
>         megabytes); (b) there are no negative ACKs that indicate data
>         loss (custody refusal actually indicates successful data
>         arrival, just at an incapable forwarding point), so recovery
>         from data loss happens only when a timer expires at the
>         current custodian; (c) but it is in the general case
>         impossible to set the timeout value for that timer because no
>         node is ever required to take custody.  You never know (in the
>         general case) who the next custodian will be, so you have no
>         idea what the round-trip time to the next custodian is.
>
>          
>
>         At the same time, Keith Scott has been saying that some
>         important use cases need custody transfer instead of reliable
>         CLAs because no suitable reliable convergence-layer protocol
>         exists: the forward path is unidirectional, the return path is
>         very different, and delay-tolerant hop-by-hop forwarding is
>         needed in one or both.
>
>          
>
>         retransmission a property of a (now reliable)
>         convergence-layer protocol that performs delay-tolerant
>         hop-by-hop forwarding, because the CL’s protocol data units
>         are bundles.  Like BIBE.
>
>          
>
>         In the specification I just posted, BIBE CT works in much the
>         same way that CT works in RFC 5050, only a little simpler. 
>         The outbound bundle forms the payload of an encapsulating
>         bundle destined for the next custodian, which might – but
>         would not have to – be the next BP node on the end-to-end
>         path.  On arrival of the encapsulating bundle at the
>         destination node, the CLA at that node extracts the payload
>         (the original bundle) and decides whether or not to accept
>         custody.  It sends a custody signal back to the sending CLA,
>         either accepting or refusing custody, and on acceptance it
>         passes the payload bundle up to the BPA for processing as
>         usual (forwarding, delivery, etc.).  The sending CLA receives
>         and processes custody signals, destroys its copy of the cited
>         original bundle upon custody acceptance, and re-encapsulates
>         and re-transmits the original bundle upon either custody
>         refusal or timer expiration prior to receipt of a responding
>         custody signal.
>
>          
>
>             non-custodial forwarding node goes away: no node other
>             than the next custodian ever sees the encapsulated bundle,
>             therefore cannot fragment it.  The encapsulating (BIBE)
>             bundle might get fragmented, absolutely, but it gets
>             reassembled at the destination (the next custodian) before
>             any CT processing occurs.  So all of the complexity of
>             fragmentary custody transfer disappears.
>           * Custody transfer suddenly becomes compatible with
>             multi-point delivery.  If you use bundle multicast as
>             prototyped in ION, then each copy of the bundle that is
>             forwarded through the multicast tree is (naturally)
>             conveyed using a point-to-point convergence-layer transfer
>             next custodian means that CT can take advantage of bundle
>             delivery time estimation mechanisms (which we prototyped a
>             few years ago) to compute custodial retransmission timeout
>             intervals.  So CT becomes more accurate and efficient as well.
>           * The relationship of CT to the rest of BP becomes an
>             extremely clean and simple interface, which can easily be
>             added on to any BP implementation.  Implementation of CT
>             becomes simple and self-contained.
>           * Building CT into BIBE gives us a single CL protocol that
>             can provide cross-domain security solutions, provide
>             reliable disruption-tolerant forwarding over
>             unidirectional links, or both.  And yet the protocol is
>             extremely simple, only 13 pages.
>
>          
>

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Fri, 23 Jun 2017 15:28:09 +0000

Marius, that is certainly true.  But in that sort of scenario - where the sender forwards the bundle to a non-custodian and leaves custody to downstream nodes beyond that neighbor - I don't think the current custodian can reasonably continue to be responsible for moving the bundle to the next custodian.

The current custodian doesn't know who the next custodian will be or when the bundle will reach that custodian, so it can't know when its responsibility to forward the bundle demands that it try again.  So the current custodian will either retransmit prematurely (unnecessarily increasing the traffic load on the network) or retransmit too late (increasing the drain on its own storage resources, delaying bundle arrival, and risking bundle loss due to TTL expiration).

In which case maybe we just say "Too bad, life is harsh" and live with sub-optimal network performance, and in some instances maybe this is unavoidable.  Not my preference, though.

Scott

From: dtn [mailto:[email-masked]] On Behalf Of Marius Feldmann
Sent: Friday, June 23, 2017 8:15 AM
To: [email-masked]
Subject: Re: [dtn] custody transfer I-D

Scott, right - I did not state that it is common in all opportunistic ad-hoc networks but that it is a popular case in these networks (at least if we assume the networks I see from a research perspective).

Though this is fine for me, we have to be aware that we exclude scenarios in which the senders' direct neighbors forward bundles and leave custody to the next hops on the path, e.g. because the direct neighbors are just a sort of gateways or relays.

Marius

Scott

Marius

Scott

Hi Scott,

Marius

Scott

dtn mailing list

dtn mailing list

dtn mailing list

---

From: Lloyd Wood <[email-masked]>
Date: Sat, 24 Jun 2017 03:35:22 +0000 (UTC)

Scott,

Thanks for crediting you?

Well, actually, we discussed source routing for delay-tolerant
networks in our "A Bundle of Problems" paper [1].

Interesting to see that, only a decade on from starting the work
on that paper, that there's still uncertainty about what
custody transfer is and is for. Perhaps more decades of work are
needed?

[1] Lloyd Wood, Wesley M. Eddy and Peter Holliday, 'A Bundle of Problems', 
peer-reviewed conference paper, IEEE Aerospace Conference, Big Sky, 
Montana, March 2009. http://dx.doi.org/10.1109/AERO.2009.4839384 
http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/

Lloyd Wood

-----Original Message-----
From: Lloyd Wood [mailto:[email-masked]] 
Sent: Thursday, June 22, 2017 5:22 PM
To: Burleigh, Scott C (312B) <[email-masked]>; [email-masked]
Subject: Re: [dtn] custody transfer I-D

Hi Scott,

Congratulations! 
Lloyd Wood

Scott

---

From: Carlo Caini <[email-masked]>
Date: Sat, 24 Jun 2017 14:51:38 +0000

Dear Scott,
   I can see your point. If you do not know who will be the next custodian you cannot set the retramssion timers accurately. However, I would say that this is a small price to pay for having a much more powerful and flexible (optional!) feature. The idea of sending something with the request that following nodes takes custody, if for them is possible and if they are willing (no mandatory!), withouth knowing which they are, which is perfectly possible in all DTN networks is in my opinion of great value. I fully agree with Marius on this.
There is the probelm of timer settings, true. But nodes that takes custody have taken the responsability to keep the bundle until either a new custodian takes custody or lifetime expires. In other words, if custodians have declared themselves ready to keep bundles in custody until lifetime expires they should be able and willing to do this! 
That said, it is not difficult to imagine some heursitic rule to set retransmission timers in the absence of any hints (the worst case). For example, as 3 is often used as a magic number (TCP), a custodian could simply attempt 3 retranmissions at interval equals to the time left to lifetime expiring divided by 4. You can select a minimum waiting time to avoid multiple reTx when a bundle is close to expire. Better rules than my example can be deivsed. Anyway 3 is better than no retranmissions at all and you do not flood the network if the minimum waiting time is selected.
Concerning end-to-end retransmissions, cited by a few others, they are not alternative to custodians, but maybe complementary. End-to-end retranmission can work fine if the delay is short and the the topology is stable, two conditions that are difficult to find toghether in DTNs. For example (I have to credit Stephen Farrell for it) in military networks the source can be no more existent (blown up or out of range) after a while. Another example: spy drones. I suppose that they are not happy to keep in their memory photographs of enemy targetes for a long period of time to be ready to retranmit them if necessary, for obvous reasons.  Drones, would prefer to rely on custodians for possible retranmissions (maybe a plane flying in a safer area). More generally, everytime information is as a hot patato, custodians are useful. 
Yours,
   Carlo 
________________________________________
Da: dtn [[email-masked]] per conto di Burleigh, Scott C (312B) [[email-masked]]
Inviato: venerdì 23 giugno 2017 17:28
A: [email-masked]
Oggetto: Re: [dtn] custody transfer I-D

Marius, that is certainly true.  But in that sort of scenario – where the sender forwards the bundle to a non-custodian and leaves custody to downstream nodes beyond that neighbor – I don’t think the current custodian can reasonably continue to be responsible for moving the bundle to the next custodian.

The current custodian doesn’t know who the next custodian will be or when the bundle will reach that custodian, so it can’t know when its responsibility to forward the bundle demands that it try again.  So the current custodian will either retransmit prematurely (unnecessarily increasing the traffic load on the network) or retransmit too late (increasing the drain on its own storage resources, delaying bundle arrival, and risking bundle loss due to TTL expiration).

In which case maybe we just say “Too bad, life is harsh” and live with sub-optimal network performance, and in some instances maybe this is unavoidable.  Not my preference, though.

Scott

Marius

On 23.06.2017 16:57, Burleigh, Scott C (312B) wrote:
Marius, I will suggest that you can still do custody transfer along these lines in an opportunistic ad-hoc network, so long as every node that receives the bundle takes custody.  The topology can be discovered dynamically, no problem.  It’s only when you don’t know who the next custodian will be – you have discovered a neighbor and will forward the bundle to that neighbor, but that neighbor won’t take custody and you don’t know who will – that there are problems.

You can still use DTN for vehicular networks, disaster response, etc., absolutely – but all nodes need to take responsibility in order for this to work.  Otherwise the current custodian has no way of knowing (in the general case) when to decide that forwarding has failed and the bundle has to be forwarded again.

Scott

Marius

On 23.06.2017 16:18, Burleigh, Scott C (312B) wrote:
You’re right, Marius, this approach excludes the option of saying “Please, anybody on the path, take custody of part or all of this bundle.”  If we need that capability, then we would need a different – or additional – protocol to make that happen.

That is by design, though.  If you don’t know who’s going to take custody then you don’t know when custody will be taken, and in that case you don’t have any way of knowing that custody has not been taken, so there is no efficient way of triggering retransmission of the bundle from the current custodian.  So I think requiring that capability excludes the efficient discharge of custodial responsibility.

I have not yet heard of use cases that require custody transfer – including custodial retransmission – in operational scenarios where the current custodian forwards the bundle without knowing who the next custodian should be.  Are there any?

Scott

Hi Scott,

Marius

  *   Custody transfer suddenly becomes compatible with multi-point delivery.  If you use bundle multicast as prototyped in ION, then each copy of the bundle that is forwarded through the multicast tree is (naturally) conveyed using a point-to-point convergence-layer transfer – which could easily be a BIBE transfer with CT requested.

Scott

dtn mailing list

dtn mailing list

dtn mailing list

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Sat, 24 Jun 2017 18:31:56 +0000

Hi, Carlo.  I completely agree that end-to-end retransmission is not a viable alternative to intra-network retransmission (of which Custody Transfer is one instance) in delay-tolerant networks.

But I disagree that custodial retransmission based on inaccurate timeout intervals is better than no custodial retransmission at all.  I would be open to persuasion on this if, as I asked earlier, there are plausible use cases that require custody transfer - including custodial retransmission - in operational scenarios where the current custodian forwards the bundle without knowing who the next custodian should be.  If someone can cite a few such cases that are important enough to justify the potential impact of inefficient retransmission on network performance, I would like to hear about them.

Scott

-----Original Message-----
From: Carlo Caini [mailto:[email-masked]] 
Sent: Saturday, June 24, 2017 7:52 AM
To: Burleigh, Scott C (312B) <[email-masked]>; [email-masked]
Subject: RE: [dtn] custody transfer I-D

Dear Scott,

Scott

Marius

Scott

Marius

Scott

Hi Scott,

Marius

Scott

dtn mailing list

dtn mailing list

dtn mailing list

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 24 Jun 2017 19:58:14 +0100

On 24/06/17 19:31, Burleigh, Scott C (312B) wrote:
> Hi, Carlo.  I completely agree that end-to-end retransmission is not
> a viable alternative to intra-network retransmission (of which
> Custody Transfer is one instance) in delay-tolerant networks.
> 
> But I disagree that custodial retransmission based on inaccurate
> timeout intervals is better than no custodial retransmission at all.
> I would be open to persuasion on this if, as I asked earlier, there
> are plausible use cases that require custody transfer - including
> custodial retransmission - in operational scenarios where the current
> custodian forwards the bundle without knowing who the next custodian
> should be.  If someone can cite a few such cases that are important
> enough to justify the potential impact of inefficient retransmission
> on network performance, I would like to hear about them.

I've not read your draft yet sorry, but I can answer that one.
If I use a CL that is broadcast (or multicast or anycast) in
nature, then I don't know the identity of the next hop. And I
may have a DTN where I want every (or almost every) node to
take custody. IIRC we have seen that scenario in the past in
experiments.

Cheers,
S.

> 
> Scott
> 
> -----Original Message----- From: Carlo Caini
> [mailto:[email-masked]] Sent: Saturday, June 24, 2017 7:52 AM 
> To: Burleigh, Scott C (312B) <[email-masked]>;
> [email-masked] Subject: RE: [dtn] custody transfer I-D
> 
> Dear Scott, I can see your point. If you do not know who will be the
> next custodian you cannot set the retramssion timers accurately.
> However, I would say that this is a small price to pay for having a
> much more powerful and flexible (optional!) feature. The idea of
> sending something with the request that following nodes takes
> custody, if for them is possible and if they are willing (no
> mandatory!), withouth knowing which they are, which is perfectly
> possible in all DTN networks is in my opinion of great value. I fully
> agree with Marius on this. There is the probelm of timer settings,
> true. But nodes that takes custody have taken the responsability to
> keep the bundle until either a new custodian takes custody or
> lifetime expires. In other words, if custodians have declared
> themselves ready to keep bundles in custody until lifetime expires
> they should be able and willing to do this! That said, it is not
> difficult to imagine some heursitic rule to set retransmission timers
> in the absence of any hints (the worst case). For example, as 3 is
> often used as a magic number (TCP), a custodian could simply attempt
> 3 retranmissions at interval equals to the time left to lifetime
> expiring divided by 4. You can select a minimum waiting time to avoid
> multiple reTx when a bundle is close to expire. Better rules than my
> example can be deivsed. Anyway 3 is better than no retranmissions at
> all and you do not flood the network if the minimum waiting time is
> selected. Concerning end-to-end retransmissions, cited by a few
> others, they are not alternative to custodians, but maybe
> complementary. End-to-end retranmission can work fine if the delay is
> short and the the topology is stable, two conditions that are
> difficult to find toghether in DTNs. For example (I have to credit
> Stephen Farrell for it) in military networks the source can be no
> more existent (blown up or out of range) after a while. Another
> example: spy drones. I suppose that they are not happy to keep in
> their memory photographs of enemy targetes for a long period of time
> to be ready to retranmit them if necessary, for obvous reasons.
> Drones, would prefer to rely on custodians for possible
> retranmissions (maybe a plane flying in a safer area). More
> generally, everytime information is as a hot patato, custodians are
> useful. Yours, Carlo ________________________________________ Da: dtn
> [[email-masked]] per conto di Burleigh, Scott C (312B)
> [[email-masked]] Inviato: venerdì 23 giugno 2017
> 17:28 A: [email-masked] Oggetto: Re: [dtn] custody transfer I-D
> 
> Marius, that is certainly true.  But in that sort of scenario - where
> the sender forwards the bundle to a non-custodian and leaves custody
> to downstream nodes beyond that neighbor - I don't think the current
> custodian can reasonably continue to be responsible for moving the
> bundle to the next custodian.
> 
> The current custodian doesn't know who the next custodian will be or
> when the bundle will reach that custodian, so it can't know when its
> responsibility to forward the bundle demands that it try again.  So
> the current custodian will either retransmit prematurely
> (unnecessarily increasing the traffic load on the network) or
> retransmit too late (increasing the drain on its own storage
> resources, delaying bundle arrival, and risking bundle loss due to
> TTL expiration).
> 
> In which case maybe we just say "Too bad, life is harsh" and live
> with sub-optimal network performance, and in some instances maybe
> this is unavoidable.  Not my preference, though.
> 
> Scott
> 
> Sent: Friday, June 23, 2017 8:15 AM To: [email-masked] Subject: Re:
> [dtn] custody transfer I-D
> 
> 
> On 23.06.2017 16:57, Burleigh, Scott C (312B) wrote: Marius, I will
> suggest that you can still do custody transfer along these lines in
> an opportunistic ad-hoc network, so long as every node that receives
> the bundle takes custody.  The topology can be discovered
> dynamically, no problem.  It's only when you don't know who the next
> custodian will be - you have discovered a neighbor and will forward
> the bundle to that neighbor, but that neighbor won't take custody and
> you don't know who will - that there are problems.
> 
> You can still use DTN for vehicular networks, disaster response,
> etc., absolutely - but all nodes need to take responsibility in order
> for this to work.  Otherwise the current custodian has no way of
> knowing (in the general case) when to decide that forwarding has
> failed and the bundle has to be forwarded again.
> 
> Scott
> 
> Sent: Friday, June 23, 2017 7:46 AM To:
> [email-masked]<mailto:[email-masked]> Subject: Re: [dtn] custody transfer
> I-D
> 
> 
> use cases mentioned in [1] lacking apriori topological knowledge
> (e.g. Vehicular Delay Tolerant Network, Disaster Response, ...).
> 
> Marius
> 
> On 23.06.2017 16:18, Burleigh, Scott C (312B) wrote: You're right,
> Marius, this approach excludes the option of saying "Please, anybody
> on the path, take custody of part or all of this bundle."  If we need
> that capability, then we would need a different - or additional -
> protocol to make that happen.
> 
> That is by design, though.  If you don't know who's going to take
> custody then you don't know when custody will be taken, and in that
> case you don't have any way of knowing that custody has not been
> I have not yet heard of use cases that require custody transfer -
> including custodial retransmission - in operational scenarios where
> the current custodian forwards the bundle without knowing who the
> next custodian should be.  Are there any?
> 
> Scott
> 
> Sent: Friday, June 23, 2017 1:02 AM To:
> [email-masked]<mailto:[email-masked]> Subject: Re: [dtn] custody transfer
> I-D
> 
> 
> Hi Scott,
> 
> bundle with the requirement "Please, anybody on the path, take
> custody for this bundle." or maybe even an extended variant: "Please,
> anybody on the path, take custody for the whole or partial data
> encapsulated in this bundle.".
> 
> On 23.06.2017 02:04, Burleigh, Scott C (312B) wrote: Hi.  A few
> minutes ago I posted an Internet Draft
> *   The problem of custodial bundle fragmentation by a non-custodial
> forwarding node goes away: no node other than the next custodian ever
> sees the encapsulated bundle, therefore cannot fragment it.  The
> encapsulating (BIBE) bundle might get fragmented, absolutely, but it
> gets reassembled at the destination (the next custodian) before any
> CT processing occurs.  So all of the complexity of fragmentary
> custody transfer disappears. *   Custody transfer suddenly becomes
> compatible with multi-point delivery.  If you use bundle multicast as
> prototyped in ION, then each copy of the bundle that is forwarded
> through the multicast tree is (naturally) conveyed using a
> point-to-point convergence-layer transfer - which could easily be a
> BIBE transfer with CT requested. *   Looking out a little further,
> knowing the identity of the next custodian means that CT can take
> advantage of bundle delivery time estimation mechanisms (which we
> prototyped a few years ago) to compute custodial retransmission
> timeout intervals.  So CT becomes more accurate and efficient as
> well. *   The relationship of CT to the rest of BP becomes an
> extremely clean and simple interface, which can easily be added on to
> any BP implementation.  Implementation of CT becomes simple and
> self-contained. *   Building CT into BIBE gives us a single CL
> protocol that can provide cross-domain security solutions, provide
> reliable disruption-tolerant forwarding over unidirectional links, or
> _______________________________________________ dtn mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/dtn
>

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Sat, 24 Jun 2017 19:32:31 +0000

Sure, you can do experiments for anything.  What's the operational use case?  Who needs this?

And yes, for broadcast you certainly don't know the identity of the next hop, but not for BP multicast -- at least not for BP multicast in ION, which is the only one I know anything about -- because the multicast messages are propagated through a tree, and over each branch of the tree you know the identity of the receiving node.

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Saturday, June 24, 2017 11:58 AM
To: Burleigh, Scott C (312B) <[email-masked]>; Carlo Caini <[email-masked]>; [email-masked]
Subject: Re: [dtn] custody transfer I-D

On 24/06/17 19:31, Burleigh, Scott C (312B) wrote:
> Hi, Carlo.  I completely agree that end-to-end retransmission is not a 
> viable alternative to intra-network retransmission (of which Custody 
> Transfer is one instance) in delay-tolerant networks.
> 

I've not read your draft yet sorry, but I can answer that one.
If I use a CL that is broadcast (or multicast or anycast) in nature, then I don't know the identity of the next hop. And I may have a DTN where I want every (or almost every) node to take custody. IIRC we have seen that scenario in the past in experiments.

Cheers,
S.

> sending something with the request that following nodes takes custody, 
> if for them is possible and if they are willing (no mandatory!), 
> withouth knowing which they are, which is perfectly possible in all 
> DTN networks is in my opinion of great value. I fully agree with 
> Marius on this. There is the probelm of timer settings, true. But 
> nodes that takes custody have taken the responsability to keep the 
> bundle until either a new custodian takes custody or lifetime expires. 
> In other words, if custodians have declared themselves ready to keep 
> bundles in custody until lifetime expires they should be able and 
> willing to do this! That said, it is not difficult to imagine some 
> heursitic rule to set retransmission timers in the absence of any 
> hints (the worst case). For example, as 3 is often used as a magic 
> number (TCP), a custodian could simply attempt
> Stephen Farrell for it) in military networks the source can be no more 
> existent (blown up or out of range) after a while. Another
> Drones, would prefer to rely on custodians for possible retranmissions 
> (maybe a plane flying in a safer area). More generally, everytime 
> information is as a hot patato, custodians are useful. Yours, Carlo 
> ________________________________________ Da: dtn 
> resources, delaying bundle arrival, and risking bundle loss due to TTL 
> expiration).
> 
> In which case maybe we just say "Too bad, life is harsh" and live with 
> sub-optimal network performance, and in some instances maybe this is 
> unavoidable.  Not my preference, though.
> 
> Scott
> 
> suggest that you can still do custody transfer along these lines in an 
> opportunistic ad-hoc network, so long as every node that receives the 
> bundle takes custody.  The topology can be discovered dynamically, no 
> problem.  It's only when you don't know who the next custodian will be 
> - you have discovered a neighbor and will forward the bundle to that 
> neighbor, but that neighbor won't take custody and you don't know who 
> will - that there are problems.
> 
> absolutely - but all nodes need to take responsibility in order for 
> only when a timer expires at the current custodian;
> original bundle) and decides whether or not to accept custody.
> It sends a custody signal back to the sending CLA, either accepting or 
> the BPA for processing as usual (forwarding, delivery, etc.).
> gets reassembled at the destination (the next custodian) before any CT 
> processing occurs.  So all of the complexity of fragmentary

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 24 Jun 2017 21:20:11 +0100

Hiya.

> use case?  Who needs this?

By "experiment" I meant experimental field deployments. And
since that's mostly all that's ever used the BP, I don't think
we are yet in a position to disparage those;-)

> And yes, for broadcast you certainly don't know the identity of the
> next hop, but not for BP multicast -- at least not for BP multicast
> in ION, which is the only one I know anything about -- because the
> multicast messages are propagated through a tree, and over each
> branch of the tree you know the identity of the receiving node.

It's CLs that broadcast/multicast/anycast where I see the problem
arising, i.e. where the BPA is unaware that various lower layer
recipients may see the same bundle and is hence unaware of any of
their identifiers.

If your draft means that such CLs aren't usable, (with custody)
then I think that ought be positively justified/garner consensus,
rather than the onus being the other way about.

We also probably do not want to lose the ability for bundles to
be sent on USB sticks or equivalent and (even though we decided
those are nodes and not CLs), hops like that have the same issues
I think.

Cheers,
S.

PS: Just to be clear: I'm not a huge fan of custody but I do
think (under the current charter) we ought not lose the concept
except via conscious choice that's positively supported.

> -----Original Message----- From: Stephen Farrell
> [mailto:[email-masked]] Sent: Saturday, June 24, 2017
> 11:58 AM To: Burleigh, Scott C (312B)
> <[email-masked]>; Carlo Caini <[email-masked]>;
> [email-masked] Subject: Re: [dtn] custody transfer I-D
> 
> 
> 
>> Hi, Carlo.  I completely agree that end-to-end retransmission is
>> not a viable alternative to intra-network retransmission (of which
>> timeout intervals is better than no custodial retransmission at
>> all. I would be open to persuasion on this if, as I asked earlier,
>> there are plausible use cases that require custody transfer -
>> next custodian should be.  If someone can cite a few such cases
>> that are important enough to justify the potential impact of
>> inefficient retransmission on network performance, I would like to
>> hear about them.
> 
> I've not read your draft yet sorry, but I can answer that one. If I
> use a CL that is broadcast (or multicast or anycast) in nature, then
> I don't know the identity of the next hop. And I may have a DTN where
> I want every (or almost every) node to take custody. IIRC we have
> seen that scenario in the past in experiments.
> 
> Cheers, S.
> 
> 
>> 
>> Scott
>> 
>> [mailto:[email-masked]] Sent: Saturday, June 24, 2017 7:52
>> AM To: Burleigh, Scott C (312B) <[email-masked]>; 
>> Dear Scott, I can see your point. If you do not know who will be
>> the next custodian you cannot set the retramssion timers
>> accurately. However, I would say that this is a small price to pay
>> for having a much more powerful and flexible (optional!) feature.
>> The idea of sending something with the request that following nodes
>> takes custody, if for them is possible and if they are willing (no
>> possible in all DTN networks is in my opinion of great value. I
>> fully agree with Marius on this. There is the probelm of timer
>> settings, true. But nodes that takes custody have taken the
>> responsability to keep the bundle until either a new custodian
>> takes custody or lifetime expires. In other words, if custodians
>> have declared themselves ready to keep bundles in custody until
>> lifetime expires they should be able and willing to do this! That
>> said, it is not difficult to imagine some heursitic rule to set
>> retransmission timers in the absence of any hints (the worst case).
>> For example, as 3 is often used as a magic number (TCP), a
>> custodian could simply attempt 3 retranmissions at interval equals
>> to the time left to lifetime expiring divided by 4. You can select
>> a minimum waiting time to avoid multiple reTx when a bundle is
>> close to expire. Better rules than my example can be deivsed.
>> Anyway 3 is better than no retranmissions at all and you do not
>> flood the network if the minimum waiting time is selected.
>> Concerning end-to-end retransmissions, cited by a few others, they
>> are not alternative to custodians, but maybe complementary.
>> End-to-end retranmission can work fine if the delay is short and
>> the the topology is stable, two conditions that are difficult to
>> find toghether in DTNs. For example (I have to credit Stephen
>> Farrell for it) in military networks the source can be no more 
>> existent (blown up or out of range) after a while. Another example:
>> spy drones. I suppose that they are not happy to keep in their
>> memory photographs of enemy targetes for a long period of time to
>> be ready to retranmit them if necessary, for obvous reasons. 
>> useful. Yours, Carlo ________________________________________ Da:
>> dtn [[email-masked]] per conto di Burleigh, Scott C (312B) 
>> Marius, that is certainly true.  But in that sort of scenario -
>> where the sender forwards the bundle to a non-custodian and leaves
>> custody to downstream nodes beyond that neighbor - I don't think
>> the current custodian can reasonably continue to be responsible for
>> moving the bundle to the next custodian.
>> 
>> The current custodian doesn't know who the next custodian will be
>> or when the bundle will reach that custodian, so it can't know when
>> its responsibility to forward the bundle demands that it try again.
>> So the current custodian will either retransmit prematurely 
>> From: dtn [mailto:[email-masked]] On Behalf Of Marius
>> Feldmann Sent: Friday, June 23, 2017 8:15 AM To: [email-masked]
>> Scott, right - I did not state that it is common in all
>> opportunistic ad-hoc networks but that it is a popular case in
>> these networks (at least if we assume the networks I see from a
>> research perspective).
>> 
>> scenarios in which the senders' direct neighbors forward bundles
>> and leave custody to the next hops on the path, e.g. because the
>> direct neighbors are just a sort of gateways or relays.
>> 
>> Marius
>> 
>>  suggest that you can still do custody transfer along these lines
>> in an opportunistic ad-hoc network, so long as every node that
>> receives the bundle takes custody.  The topology can be discovered
>> dynamically, no problem.  It's only when you don't know who the
>> next custodian will be - you have discovered a neighbor and will
>> forward the bundle to that neighbor, but that neighbor won't take
>> custody and you don't know who will - that there are problems.
>> 
>> etc., absolutely - but all nodes need to take responsibility in
>> order for this to work.  Otherwise the current custodian has no way
>> of knowing (in the general case) when to decide that forwarding has
>> From: dtn [mailto:[email-masked]] On Behalf Of Marius
>> Feldmann Sent: Friday, June 23, 2017 7:46 AM To: 
>> [email-masked]<mailto:[email-masked]> Subject: Re: [dtn] custody
>> transfer I-D
>> 
>> 
>> The sketched scenario should be quite popular in opportunistic
>> ad-hoc networks in which the topology is not known in advance.
>> 
>> If we do not go for a solution, custody transfer is removed from
>> all use cases mentioned in [1] lacking apriori topological
>> knowledge (e.g. Vehicular Delay Tolerant Network, Disaster
>> Response, ...).
>> 
>> Marius
>> 
>>  Marius, this approach excludes the option of saying "Please,
>> anybody on the path, take custody of part or all of this bundle."
>> If we need that capability, then we would need a different - or
>> additional - protocol to make that happen.
>> 
>> From: dtn [mailto:[email-masked]] On Behalf Of Marius
>> Feldmann Sent: Friday, June 23, 2017 1:02 AM To: 
>> [email-masked]<mailto:[email-masked]> Subject: Re: [dtn] custody
>> transfer I-D
>> 
>> 
>> Hi Scott,
>> 
>>  nodes that guarantee to take the original bundle (even if it has
>> been fragmented between the sender and this well-known node) and
>> confirm custody for it. As far as I get it, that is the basic
>> point.
>> 
>>  transfer custody to an unknown node on the path? Thus, to transmit
>> a bundle with the requirement "Please, anybody on the path, take
>> custody for this bundle." or maybe even an extended variant:
>> "Please, anybody on the path, take custody for the whole or partial
>> data encapsulated in this bundle.".
>> 
>> successful data arrival, just at an incapable forwarding point), so
>> recovery from data loss happens only when a timer expires at the
>> current custodian; (c) but it is in the general case impossible to
>> set the timeout value for that timer because no node is ever
>> required to take custody.  You never know (in the general case) who
>> the next custodian will be, so you have no idea what the round-trip
>> time to the next custodian is.
>> 
>> use cases need custody transfer instead of reliable CLAs because no
>>  suitable reliable convergence-layer protocol exists: the forward
>> path is unidirectional, the return path is very different, and 
>> because the CL's protocol data units are bundles.  Like BIBE.
>> 
>> bundle forms the payload of an encapsulating bundle destined for
>> the next custodian, which might - but would not have to - be the
>> next BP node on the end-to-end path.  On arrival of the
>> encapsulating bundle at the destination node, the CLA at that node
>> extracts the payload (the original bundle) and decides whether or
>> not to accept custody. It sends a custody signal back to the
>> sending CLA, either accepting or refusing custody, and on
>> and re-transmits the original bundle upon either custody refusal or
>> timer expiration prior to receipt of a responding custody signal.
>> 
>> custodian) before any CT processing occurs.  So all of the
>> complexity of fragmentary custody transfer disappears. *   Custody
>> transfer suddenly becomes compatible with multi-point delivery.  If
>> you use bundle multicast as prototyped in ION, then each copy of
>> the bundle that is forwarded through the multicast tree is
>> (naturally) conveyed using a point-to-point convergence-layer
>> transfer - which could easily be a BIBE transfer with CT requested.
>> *   Looking out a little further, knowing the identity of the next
>> custodian means that CT can take advantage of bundle delivery time
>> estimation mechanisms (which we prototyped a few years ago) to
>> more accurate and efficient as well. *   The relationship of CT to
>> the rest of BP becomes an extremely clean and simple interface,
>> which can easily be added on to any BP implementation.
>> Implementation of CT becomes simple and self-contained. *
>> Building CT into BIBE gives us a single CL protocol that can

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Sat, 24 Jun 2017 20:59:30 +0000

Stephen, sure, we don't want to make any protocol design decisions by anything other than conscious choice and consensus.  I think that's what we're doing on this mailing list.

But I really do think we should be making this sort of decision with real operational deployment in mind, not research.  Optimizing BP for experimentation rather than for day-to-day, large-scale use would be a pretty good way to guarantee that it never gets adopted for day-to-day, large-scale use.

And I think we are beginning to get beyond experimental field deployments of DTN.  The start date for Maria Uden's reindeer husbandry project, funded by the Swedish Board of Agrigulture, was March 1, and we've got a long list of science payloads on the International Space Station queued up to get integrated with the DTN gateway nodes that have been operational there for about a year.  A modest start, but a start.

Scott

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Saturday, June 24, 2017 1:20 PM
To: Burleigh, Scott C (312B) <[email-masked]>; Carlo Caini <[email-masked]>; [email-masked]
Subject: Re: [dtn] custody transfer I-D

Hiya.

> Sure, you can do experiments for anything.  What's the operational use 

By "experiment" I meant experimental field deployments. And since that's mostly all that's ever used the BP, I don't think we are yet in a position to disparage those;-)

> next hop, but not for BP multicast -- at least not for BP multicast in 
> ION, which is the only one I know anything about -- because the 
> multicast messages are propagated through a tree, and over each branch 
> of the tree you know the identity of the receiving node.

It's CLs that broadcast/multicast/anycast where I see the problem arising, i.e. where the BPA is unaware that various lower layer recipients may see the same bundle and is hence unaware of any of their identifiers.

If your draft means that such CLs aren't usable, (with custody) then I think that ought be positively justified/garner consensus, rather than the onus being the other way about.

We also probably do not want to lose the ability for bundles to be sent on USB sticks or equivalent and (even though we decided those are nodes and not CLs), hops like that have the same issues I think.

Cheers,
S.

PS: Just to be clear: I'm not a huge fan of custody but I do think (under the current charter) we ought not lose the concept except via conscious choice that's positively supported.

> use a CL that is broadcast (or multicast or anycast) in nature, then I 
> don't know the identity of the next hop. And I may have a DTN where I 
> want every (or almost every) node to take custody. IIRC we have seen 
> that scenario in the past in experiments.
> 
> Cheers, S.
> 
> 
>> 
>> Scott
>> 
>> much more powerful and flexible (optional!) feature.
>> in the absence of any hints (the worst case).
>> For example, as 3 is often used as a magic number (TCP), a custodian 
>> could simply attempt 3 retranmissions at interval equals to the time 
>> left to lifetime expiring divided by 4. You can select a minimum 
>> waiting time to avoid multiple reTx when a bundle is close to expire. 
>> Better rules than my example can be deivsed.
>> Anyway 3 is better than no retranmissions at all and you do not flood 
>> the network if the minimum waiting time is selected.
>> End-to-end retranmission can work fine if the delay is short and the 
>> the topology is stable, two conditions that are difficult to find 
>> toghether in DTNs. For example (I have to credit Stephen Farrell for 
>> it) in military networks the source can be no more existent (blown up 
>> or out of range) after a while. Another example:
>> spy drones. I suppose that they are not happy to keep in their memory 
>> photographs of enemy targetes for a long period of time to be ready 
>> to retranmit them if necessary, for obvous reasons.
>> responsibility to forward the bundle demands that it try again.
>> Sent: Friday, June 23, 2017 8:15 AM To: [email-masked]
>> on the path, take custody of part or all of this bundle."
>> you use bundle multicast as prototyped in ION, then each copy of the 
>> bundle that is forwarded through the multicast tree is
>> the rest of BP becomes an extremely clean and simple interface, which 
>> can easily be added on to any BP implementation.
>> Implementation of CT becomes simple and self-contained. * Building CT 
>> into BIBE gives us a single CL protocol that can provide cross-domain 
>> security solutions, provide reliable disruption-tolerant forwarding 
>> over unidirectional links, or both.

---

From: Lloyd Wood <[email-masked]>
Date: Mon, 26 Jun 2017 06:36:49 +0000 (UTC)

> The start date for Maria Uden's reindeer husbandry project,
> funded by the Swedish Board of Agrigulture, was March 1,
> and we've got a long list of science payloads on the International
> Space Station queued up to get integrated with the DTN gateway nodes
> that have been operational there for about a year.
> A modest start, but a start.

Indeed. In 2009 we asked in [1]:
"Use of a common BP could 
allow a deep space node to communicate directly with a 
reindeer herder – but what do these DTN networks carry that is 
useful across these very different operational scenarios? What 
can be said about reindeer to a Mars rover?"

and we very much look forward to hearing the answers to
those questions from the snowfields.

[1] Lloyd Wood, Peter Holliday, Daniel Floreani and Wesley M. Eddy, 
'Sharing the dream: The consensual networking hallucination offered 
by the Bundle Protocol', Workshop on the Emergence of
Delay-/Disruption-Tolerant Networks (E-DTN),  part of the
International Conference on Ultra Modern Telecommunication 
(ICUMT), St. Petersburg, Russia, 14 October 2009.
http://personal.ee.surrey.ac.uk/Personal/L.Wood/
http://dx.doi.org/10.1109/ICUMT.2009.5345655

L.

Hey, NORAD could track Santa's DTN-enabled
reindeer sleigh at Christmas! As he delivers
Christmas bundles to everyone! ho ho ho.

Lloyd Wood

________________________________
From: "Burleigh, Scott C (312B)" <[email-masked]>
To: Stephen Farrell <[email-masked]>; Carlo Caini <[email-masked]>; "[email-masked]" <[email-masked]> 
Sent: Sunday, 25 June 2017, 7:00
Subject: Re: [dtn] custody transfer I-D

Scott

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Saturday, June 24, 2017 1:20 PM
To: Burleigh, Scott C (312B) <[email-masked]>; Carlo Caini <[email-masked]>; [email-masked]
Subject: Re: [dtn] custody transfer I-D

Hiya.

Cheers,
S.