Re: [dtn-interest] Comments on RFC 4838

["Burleigh, Scott C (313B)" <[e-mail]>]

Hi, Michael.  A couple of remarks on your comments -- and Sebastian's -- in-line below.

Scott
________________________________________
From: [e-mail] [[e-mail]] on behalf of Michael Noisternig [[e-mail]]
Sent: Wednesday, June 19, 2013 5:21 AM
To: [e-mail]
Subject: Re: [dtn-interest] Comments on RFC 4838

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)

>>>  Not quite, I would say.  An EID is a string that identified a BP endpoint, full stop.  And RFC 5050 states pretty unambiguously what a BP endpoint is: it's a set of zero or more BP nodes.  An EID might be a haiku, but an endpoint can't.  In practice, I think DTN2 EIDs (formed in the "dtn" URI scheme) typically include a DNS name that identifies a virtual or physical CPU that is coterminous with some BP node, followed by a string token for demultiplexing bundles sent to that node.  EIDs formed in the "ipn" URI scheme more formally always include a numeric node ID (which may or may not correspond to a CPU) and a numeric service ID (for demultiplexing).
>>> It is true that using MAC address as node ID, in an EID scheme that supports the concept of node IDs, is a good way to prevent EID collisions.

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?

>>> No, that's not the case.  Each node encompasses a single bundle protocol agent, which can send and receive bundles on behalf of any number of applications.  Applications and nodes are orthogonal.

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

>>> Bu EIDs really are identifiers; they identify endpoints, not nodes.  Any number of nodes can register as members of a given endpoint, but the mechanism for advertising those registrations is not defined.  There's nothing whatsoever preventing a given node (which is a functional construct, not a string) from registering in any number of endpoints (sets of nodes) that are identified by strings formed in any number of URI schemes.  There's no reason a given node can't register in both the endpoint identified by "dtn://bills.macbook/chat" and "ipn: 391635.31".

>
>
>
> Sebastian

Thanks,
Michael
_______________________________________________
dtn-interest mailing list
[e-mail]
https://www.irtf.org/mailman/listinfo/dtn-interest