Re: [dtn-interest] Comments on RFC 4838

[Caini Carlo <[e-mail]>]

Dear Michael,
   just a brief comment about late binding. You wrote:
>Late binding is a nice concept, but of course it conflicts with 
>routing under mobility where identities do not necessarily represent locations.

I agree with you on the fact that is a nice concept, but not just 
this. In my opinion, it is a real feature which does not conflict 
with mobility, but actually helps in dealing with mobility.
I will give you this example, taken from my research experience on 
DTN and smartphones (Nokia N900 with DTN2 on board).

Phase 1 (sending a bundle to a non existing device)
Suppose that you want to send a bundle to the smartphone of a friend 
of you, but you do not know anything about it but its dtn EID (e.g. 
dtn://myfriendsmartphone.dtn). Not only are you unaware of the IP 
address, but also of the location, of the fact that is switched on or 
off, and, in the most extreme case, of the same existence of the 
physical device. In spite of all, and thanks to the late binding, you 
can send a bundle to the mentioned EID, the DTN networks can route it 
until the bundle reaches a gateway where the bundle has to be stored 
because there are no routes to destination. Actually, the physical 
destination may be non existing at this time.

Phase 2 (delivery a bundle to a device bought after bundle sending)
The following day your friend buys a device, install DTN2 on it, 
configure the links in such a way that an ALWAYSON TCP link is 
established to the gateway. Then it switches on the device, the TCP 
convergence layer automatically establishes a link to the gateway and 
informs the gateway about its dtn identity (its EID). The gateway can 
now derive the association between the declared EID and the IP of the 
sender (late binding is performed here), and as a consequence: a) an 
opportunistic link to the smartphone is established; b) a route to 
the smartphone EID through this opportunistic link is written. 
Finally the bundle that was sent before your friend actually had 
bought the device is eventually delivered. Happy end.

This is not science fiction, but what you can do now with the present 
DTN2 implementation, to deal with mobility (let me credit Stephen 
Farrell for this nice feature). Of course you can do more or less the 
same with Dropbox. The difference is that the gateway can be yours.

Frankly speaking, it took me a while (I mean a few years) before 
really understanding the potentiality (i.e. the subtle implications) 
of "late binding", because of its novelty.  Now I love it. And I hope 
you will as well.

Yours,
     Carlo Caini



At 11.06 18/06/2013, Michael Noisternig wrote:
>Dear DTNRG members,
>
>in our research group we are currently investigating the use of DTN 
>functionality for a wireless communication scenario where we expect 
>classical mobile ad-hoc communication protocols to behave poorly due 
>to infrequent end-to-end connectivity. As part of this research I 
>have read up on the documents produced by your working group. By 
>now, I have got several comments, questions and criticism on these 
>documents that I would like to share with you. Below I'll start with 
>reviewing RFC 4838 on "a delay-tolerant architecture". I'll review 
>other documents in subsequent mails.
>
>That said, I realize that you are likely aware of several of the 
>issues I am bringing up and that you are already discussing better 
>protocol solutions for DTN networking. I will read up on your 
>mailing list archives when time permits, but I do want to stress 
>here that a good architecture document is a prerequisite for a good 
>protocol specification. In the mean time, I am still hoping for my 
>comments to be of value to you, and I am looking forward to your kind response.
>
>Kind regards,
>Michael
>
>---->8----
>
>Quite frankly, I was a bit disappointed by RFC 4838 because I think 
>the document promises something different than what it delivers. I 
>had expected an analysis of the different kinds of network 
>architectures delay-tolerant protocols might be applicable for, 
>exploring the difference between homogeneous and heterogeneous 
>networks, the difference between long delays but possibly relatively 
>stable intermediate connections vs. short delays but frequent 
>disruptions, whether networks are fully ad-hoc or have access to an 
>infrastructure backbone, etc. All these aspects clearly influence 
>the solution space, including whether an overlay with separate 
>addressing (and routing) is needed or whether a DTN protocol be 
>directly integrated at L3, whether interactivity between network 
>nodes is feasible, how (key) management can be supported, how 
>routing can be supported, etc. What I did find in the document 
>instead was "a DTN architecture for the bundle overlay protocol". As 
>such the document already makes the assumption that DTN networks 
>consist of heterogeneous interconnected networks and that the bundle 
>overlay protocol is the appropriate solution. However, homogeneous 
>resource-constrained networks are unlikely to benefit from the 
>bundle overlay protocol, even when compressed headers (CBHE) are 
>used and the protocol is directly implemented at L3. As such (and in 
>part because of the complexity of the bundle security solution), I 
>do not see ourselves using the bundle protocol "as is" for our 
>envisaged application scenario. I will comment more on the bundle 
>protocol specification in a subsequent mail. Following are some 
>section-specific comments on RFC 4838.
>
>3.2 and 3.3:
>What wasn't really clear to me in both RFC 4838 and 5050 was the 
>whole node-to-EID registration process. A node registers to an EID, 
>and an application somehow gets associated/registered with a node 
>(via some socket API?). (So there seem to be two separate 
>registration processes.) Then if all applications connect to the 
>same node (e.g., a daemon) how do the applications get multiplexed 
>on the channel? Or is there a 1-1 relationship between applications 
>and nodes? If an application selects the EID to register to how can 
>we assure a unique "singleton" EID for each node? How do these EIDs 
>get registered within the network?
>
>3.3.1:
>I have some comments on the use of URIs; I'll postpone these to my 
>review of RFC 5050.
>
>3.3.2:
>Late binding is a nice concept, but of course it conflicts with 
>routing under mobility where identities do not necessarily represent 
>locations. How is this issue going to be resolved? I'm not sure 
>leaving this as an implementation matter is the appropriate "solution".
>
>Related to this, can (or how can) DTN nodes from different networks 
>(with different schemes) register to the same EID?
>
>3.6.2:
>"Administrative records are sent as bundles with a source EID
>    set to one of the EIDs associated with the DTN node generating the
>    administrative record."
>So, a node can be registered with multiple EIDs, and multiple nodes 
>can register with a particular EID. Then how are we supposed to find 
>out who is the actual source of the administrative record? Why not 
>require the source EID be set to the EID of the endpoint that 
>uniquely identifies the DTN node (the "singleton" endpoint)?
>
>Bundle Delivery: So my understanding is that whereas this 
>administrative record is only being sent for complete ADUs rather 
>than individual bundles, if a source wishes to receive 
>acknowledgments for individual bundles it should request for Bundle 
>Reception messages to be sent by DTN nodes? And what is to do when 
>bundle fragments (erroneously) contain conflicting report-to-EIDs? 
>(This question actually better applies to RFC 5050.)
>
>3.10, 6th paragraph:
>Custody Transfer Accepted Signal: This should be "Custody Signal" 
>according to RFC 5050.
>_______________________________________________
>dtn-interest mailing list
>[e-mail]
>https://www.irtf.org/mailman/listinfo/dtn-interest