Re: [dtn-interest] Comments on RFC 4838

[Joerg Ott <[e-mail]>]

Hi Michael,

first of all (as RG co-chair), especially with our impending work
on a successor to the bundle protocol, your thorough review is
highly appreciated).

As Sebastian said, RFC 4838 has a certain purpose and is to be seen
in the context of the DTNRG and specifically the bundle protocol
(for which it provides the framework).

Speaking as an individual:

You are surely right in saying that these documents don't answer
all the questions.  They provide a basis, upon which you have to fill
in your scenario-specific detail details.  There actually do differ
quite a bit

For a general architectural discussion, Kevin Fall's 2003 SIGCOMM paper
takes a broader viewpoint and provides an excellent overview.

We have seen a lot of efforts on mobile  opportunistic communication.
In fact, the DTN architecture and the bundle protocol are quite a good
platform (you can argue about some of the security details) as we
found.  We built systems for mobile ad-hoc  networking on top of RFC
5050 and the TCP convergence layer with our our neighbor discovery and
routing mechanisms.  See e.g. http://floating-content.net/ and 
http://www.ict-scampi.eu/ (and maybe http://www.netlab.tkk.fi/~jo/dtn/)

Jörg

On 18.06.2013 18:39, Sebastian Schildt wrote:
> Hi Michael,
>
>
> maybe 4838 is a bit aged and does not reflect all the things people have come up with, since. And yes, while it says "_DTN_ Architecture" it is tied quite strongly to the BP. So maybe it isn"t 100% what it says on the can, but writing a short/concise RFC for everything that can be called a DTN would probably be impossible. Or, to put it into a more positive perspective: Partly the intention for the BP WAS to be something for "all kinds of" DTNs. Like TCP/IP it aims for generality,  but this implies tradeoffs. (and functionality-wise BP includes "more stuff" than IP, which makes this balance harder)
>
> However, some more concrete remarks:
>
> Am 18.06.2013 um 11:06 schrieb Michael Noisternig <[e-mail]>:
>
>> 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
>
>
> Ah, a good opportunity for a shameless plug! In fact we DO use the BP as L3 protocol on Contiki based WSN nodes over IEEE 802.15.4. There are two papers and a GIT to "prove it":
>
> Pöttner, W.-B.; Busching, F.; von Zengen, G.; Wolf, L., "Data elevators: Applying the bundle protocol in Delay Tolerant Wireless Sensor Networks," Mobile Adhoc and Sensor Systems (MASS), 2012 IEEE 9th International Conference on , vol., no., pp.218,226, 8-11 Oct. 2012
> http://www.ibr.cs.tu-bs.de/papers/poettner-mass2012.pdf
>
>
> Georg von Zengen, Felix Büsching, Wolf-Bastian Pöttner and Lars Wolf: An Overview of μDTN: Unifying DTNs and WSNs, in Proceedings of the 11th GI/ITG KuVS Fachgespräch Drahtlose Sensornetze (FGSN), Darmstadt, Germany, 2012
> http://www.ibr.cs.tu-bs.de/papers/buesching-fgsn2012.pdf
>
> http://www.ibr.cs.tu-bs.de/projects/mudtn/
>
> While SDNVs and such propose a challenge to small nodes, it is doable with reasonable efficiency. We are convinced this is a better solution than for example 6LoPan for many application scenarios. Without knowing exactly what you are planing YMMV.
>
>> (and in part because of the complexity of the bundle security solution),
> You mean the Bundle Security Protocol? I am not very active in that area, but my feeling is, most people in the community agree, that this is still sub-optimal
>
>
>
>> 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?
> In THEORY BP has a "an EID can be anything" concept: A node, many nodes, one name amongst many for a node, an interest, a haiku...   in PRACTICE, when using DTN2 or IBR-DTN implementations (and probably others), it mostly comes back to the more mundane: An EID is a node identifier, the path is used for multiplexing like Port numbers: dtn://node1/myApp  -> Boring, but that is what is mostly  used. "Colliding" EIDs may, or may not be a problem also depending on the employed routing. 4838 or 5050 do not offer any solution for generating unique EIDs (but putting some sort of Mac Address into an EID is straight-forward)
>
>
>>
>> 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".
> Routing. A can of worms. Like in the WSN community, some "standard" approaches exist that work so-so, often application specific solutions seems to be the key. . Others might disagree, but it really depends much on the application, with scheduled IPNs the one extreme and completely undeterministic, opportunistic networks at the other.
>>
>> Related to this, can (or how can) DTN nodes from different networks (with different schemes) register to the same EID?
> I am not sure if I understand this correctly, but different schemes, imply it is a different EID (it may be the same node), i.e. ipn://23.1 is not the same EID as dtn://23.1
>
>
>
> Sebastian
>
>
>
>
>
>
> _______________________________________________
> dtn-interest mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/dtn-interest
>