Re: [dtn] custody transfer I-D

[Marius Feldmann <[e-mail]>]

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]
> *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]
> https://www.ietf.org/mailman/listinfo/dtn