Re: [dtn] custody transfer I-D

[Marius Feldmann <[e-mail]>]

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
>
>  
>
> *From:*dtn [mailto:[e-mail]] *On Behalf Of *Marius Feldmann
> *Sent:* Friday, June 23, 2017 7:46 AM
> *To:* [e-mail]
> *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
>
> [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:[e-mail]] *On Behalf Of *Marius
>     Feldmann
>     *Sent:* Friday, June 23, 2017 1:02 AM
>     *To:* [e-mail] <mailto:[e-mail]>
>     *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
>
>      
>
>     On 23.06.2017 02: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.
>
>          
>
>         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] <mailto:[e-mail]>
>
>         https://www.ietf.org/mailman/listinfo/dtn
>
>      
>
>
>
>
>     _______________________________________________
>
>     dtn mailing list
>
>     [e-mail] <mailto:[e-mail]>
>
>     https://www.ietf.org/mailman/listinfo/dtn
>
>  
>
>
>
> _______________________________________________
> dtn mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dtn