Re: [dtn-interest] Comments on RFC 4838

[Michael Noisternig <[e-mail]>]

Hi Sebastian,

thank your for your comments. See my replies inline.

> 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)

Obviously, my expectations were a bit different, but I understand your 
perspective.

>> 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":

In fact, I am aware of your group's work on ibr-dtn and mudtn. This is 
why I said that even with compression (CBHE) the overhead of the BP 
would probably still be too high for our scenario... addresses in EUI-48 
format, high volume of messages with very small payloads. We are more 
concerned about network overhead than computing resources. Still, we 
will look into your work in more detail.

>> 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)

Thank you, that sheds a bit more light on the issue. Let me make sure I 
understand this correctly... Whereas an EID may represent a single node 
or multiple nodes (or interests or whatnot), there is (more or less) a 
1-1 relationship between applications and nodes, i.e., each node 
represents an application, right?

>> 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

Right... I was thinking of an EID as an identifier, so obviously that 
doesn't work.

>
>
>
> Sebastian

Thanks,
Michael