Re: [dtn] custody transfer I-D

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:marc.blanchet@viagenie.ca] 
Sent: Thursday, June 22, 2017 6:09 PM
To: Burleigh, Scott C (312B) <scott.c.burleigh@jpl.nasa.gov>
Cc: dtn@ietf.org
Subject: Re: [dtn] custody transfer I-D

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

> _______________________________________________
> dtn mailing list
> dtn@ietf.org
> https://www.ietf.org/mailman/listinfo/dtn