Re: [dtn] custody transfer I-D

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

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:[e-mail]] 
Sent: Friday, June 23, 2017 7:09 AM
To: Burleigh, Scott C (312B) <[e-mail]>
Cc: [e-mail]
Subject: Re: [dtn] custody transfer I-D

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)

>
> Scott
>
> -----Original Message-----
> From: Marc Blanchet [mailto:[e-mail]]
> Sent: Thursday, June 22, 2017 6:09 PM
> To: Burleigh, Scott C (312B) <[e-mail]>
> Cc: [e-mail]
> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dtn
> _______________________________________________
> dtn mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dtn