Re: [dtn] custody transfer I-D

[Stephen Farrell <[e-mail]>]

On 24/06/17 19:31, Burleigh, Scott C (312B) wrote:
> Hi, Carlo.  I completely agree that end-to-end retransmission is not
> a viable alternative to intra-network retransmission (of which
> Custody Transfer is one instance) in delay-tolerant networks.
> 
> But I disagree that custodial retransmission based on inaccurate
> timeout intervals is better than no custodial retransmission at all.
> I would be open to persuasion on this if, as I asked earlier, there
> are plausible 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.  If someone can cite a few such cases that are important
> enough to justify the potential impact of inefficient retransmission
> on network performance, I would like to hear about them.

I've not read your draft yet sorry, but I can answer that one.
If I use a CL that is broadcast (or multicast or anycast) in
nature, then I don't know the identity of the next hop. And I
may have a DTN where I want every (or almost every) node to
take custody. IIRC we have seen that scenario in the past in
experiments.

Cheers,
S.


> 
> Scott
> 
> -----Original Message----- From: Carlo Caini
> [mailto:[e-mail]] Sent: Saturday, June 24, 2017 7:52 AM 
> To: Burleigh, Scott C (312B) <[e-mail]>;
> [e-mail] Subject: RE: [dtn] custody transfer I-D
> 
> Dear Scott, I can see your point. If you do not know who will be the
> next custodian you cannot set the retramssion timers accurately.
> However, I would say that this is a small price to pay for having a
> much more powerful and flexible (optional!) feature. The idea of
> sending something with the request that following nodes takes
> custody, if for them is possible and if they are willing (no
> mandatory!), withouth knowing which they are, which is perfectly
> possible in all DTN networks is in my opinion of great value. I fully
> agree with Marius on this. There is the probelm of timer settings,
> true. But nodes that takes custody have taken the responsability to
> keep the bundle until either a new custodian takes custody or
> lifetime expires. In other words, if custodians have declared
> themselves ready to keep bundles in custody until lifetime expires
> they should be able and willing to do this! That said, it is not
> difficult to imagine some heursitic rule to set retransmission timers
> in the absence of any hints (the worst case). For example, as 3 is
> often used as a magic number (TCP), a custodian could simply attempt
> 3 retranmissions at interval equals to the time left to lifetime
> expiring divided by 4. You can select a minimum waiting time to avoid
> multiple reTx when a bundle is close to expire. Better rules than my
> example can be deivsed. Anyway 3 is better than no retranmissions at
> all and you do not flood the network if the minimum waiting time is
> selected. Concerning end-to-end retransmissions, cited by a few
> others, they are not alternative to custodians, but maybe
> complementary. End-to-end retranmission can work fine if the delay is
> short and the the topology is stable, two conditions that are
> difficult to find toghether in DTNs. For example (I have to credit
> Stephen Farrell for it) in military networks the source can be no
> more existent (blown up or out of range) after a while. Another
> example: spy drones. I suppose that they are not happy to keep in
> their memory photographs of enemy targetes for a long period of time
> to be ready to retranmit them if necessary, for obvous reasons.
> Drones, would prefer to rely on custodians for possible
> retranmissions (maybe a plane flying in a safer area). More
> generally, everytime information is as a hot patato, custodians are
> useful. Yours, Carlo ________________________________________ Da: dtn
> [[e-mail]] per conto di Burleigh, Scott C (312B)
> [[e-mail]] Inviato: venerdì 23 giugno 2017
> 17:28 A: [e-mail] Oggetto: Re: [dtn] custody transfer I-D
> 
> Marius, that is certainly true.  But in that sort of scenario - where
> the sender forwards the bundle to a non-custodian and leaves custody
> to downstream nodes beyond that neighbor - I don't think the current
> custodian can reasonably continue to be responsible for moving the
> bundle to the next custodian.
> 
> The current custodian doesn't know who the next custodian will be or
> when the bundle will reach that custodian, so it can't know when its
> responsibility to forward the bundle demands that it try again.  So
> the current custodian will either retransmit prematurely
> (unnecessarily increasing the traffic load on the network) or
> retransmit too late (increasing the drain on its own storage
> resources, delaying bundle arrival, and risking bundle loss due to
> TTL expiration).
> 
> In which case maybe we just say "Too bad, life is harsh" and live
> with sub-optimal network performance, and in some instances maybe
> this is unavoidable.  Not my preference, though.
> 
> Scott
> 
> From: dtn [mailto:[e-mail]] On Behalf Of Marius Feldmann 
> Sent: Friday, June 23, 2017 8:15 AM To: [e-mail] Subject: Re:
> [dtn] custody transfer I-D
> 
> 
> 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]<mailto:[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]<mailto:[e-mail]>
> 
> https://www.ietf.org/mailman/listinfo/dtn
> 
> _______________________________________________ dtn mailing list 
> [e-mail] https://www.ietf.org/mailman/listinfo/dtn
>