Re: [dtn-interest] Comments on RFC 4838

Thanks Caini, that is a very nice scenario!

So the issue to be solved is disseminating the new EID throughout the 
network. I still see an issue where you don't know beforehand which DTN 
network the intended destination currently (or in the future) resides 
in. I mean, the new device may log in in some network with a dtn2:// 
scheme, right? Then how can you properly address this device?

Michael

Am 19.06.2013 11:06, schrieb Caini Carlo:
> 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
>> dtn-interest@irtf.org
>> https://www.irtf.org/mailman/listinfo/dtn-interest
>