Re: [dtn] custody transfer I-D
"Marc Blanchet" <marc.blanchet@viagenie.ca> Fri, 23 June 2017 01:09 UTC
Return-Path: <marc.blanchet@viagenie.ca>
X-Original-To: dtn@ietfa.amsl.com
Delivered-To: dtn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C917129BD7 for <dtn@ietfa.amsl.com>; Thu, 22 Jun 2017 18:09:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JKdl4GcMyu-e for <dtn@ietfa.amsl.com>; Thu, 22 Jun 2017 18:09:30 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1D565129BBD for <dtn@ietf.org>; Thu, 22 Jun 2017 18:09:30 -0700 (PDT)
Received: from [206.123.31.198] (h198.viagenie.ca [206.123.31.198]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 21844478B9; Thu, 22 Jun 2017 21:09:29 -0400 (EDT)
From: Marc Blanchet <marc.blanchet@viagenie.ca>
To: "Burleigh, Scott C" <scott.c.burleigh@jpl.nasa.gov>
Cc: "dtn@ietf.org" <dtn@ietf.org>
Date: Thu, 22 Jun 2017 21:09:28 -0400
Message-ID: <1BDC15F2-B1B7-4DE6-8094-FC72EE7257C0@viagenie.ca>
In-Reply-To: <A5BEAD028815CB40A32A5669CF737C3B8AF03E12@ap-embx-sp40.RES.AD.JPL>
References: <A5BEAD028815CB40A32A5669CF737C3B8AF03E12@ap-embx-sp40.RES.AD.JPL>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.9.6r5347)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/z1kFtxAvR127KNRksoTWVWo8VtY>
Subject: Re: [dtn] custody transfer I-D
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." <dtn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dtn>, <mailto:dtn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dtn/>
List-Post: <mailto:dtn@ietf.org>
List-Help: <mailto:dtn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dtn>, <mailto:dtn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Jun 2017 01:09:33 -0000
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
- Re: [dtn] custody transfer I-D William Ivancic
- [dtn] custody transfer I-D Burleigh, Scott C (312B)
- Re: [dtn] custody transfer I-D Lloyd Wood
- Re: [dtn] custody transfer I-D Burleigh, Scott C (312B)
- Re: [dtn] custody transfer I-D Marc Blanchet
- Re: [dtn] custody transfer I-D Lloyd Wood
- Re: [dtn] custody transfer I-D Marius Feldmann
- Re: [dtn] custody transfer I-D Burleigh, Scott C (312B)
- Re: [dtn] custody transfer I-D Burleigh, Scott C (312B)
- Re: [dtn] custody transfer I-D Marc Blanchet
- Re: [dtn] custody transfer I-D Burleigh, Scott C (312B)
- Re: [dtn] custody transfer I-D Burleigh, Scott C (312B)
- Re: [dtn] custody transfer I-D William Ivancic
- Re: [dtn] custody transfer I-D Marius Feldmann
- Re: [dtn] custody transfer I-D Burleigh, Scott C (312B)
- Re: [dtn] custody transfer I-D Marius Feldmann
- Re: [dtn] custody transfer I-D Burleigh, Scott C (312B)
- Re: [dtn] custody transfer I-D Lloyd Wood
- Re: [dtn] custody transfer I-D Carlo Caini
- Re: [dtn] custody transfer I-D Burleigh, Scott C (312B)
- Re: [dtn] custody transfer I-D Stephen Farrell
- Re: [dtn] custody transfer I-D Burleigh, Scott C (312B)
- Re: [dtn] custody transfer I-D Stephen Farrell
- Re: [dtn] custody transfer I-D Burleigh, Scott C (312B)
- Re: [dtn] custody transfer I-D Lloyd Wood