Re: [dtn-interest] Comments on RFC 4838

[Michael Noisternig <[e-mail]>]

Thanks, Scott.

The reason why I have difficulties understanding the details is because 
EIDs are solely being described as referring to one or more (RFC 4838) 
(or zero or more (RFC 5050)) DTN nodes, but what we want to address in 
the BP are applications connected to/running on these nodes and not the 
nodes themselves.

RFC 4838 states that "to initiate a registration and thereby establish 
application registration state, an application specifies an Endpoint ID 
for which it wishes to receive ADUs", so may I take it that there is 
(more or less) a 1-1 relationship between EIDs and applications? The 
application uses the node it connects to as a means to get data destined 
for a particular EID to be sent to that node, which then forwards it to 
the application? So the EID the application selects should be globally 
unique, and _may_ be compiled by combining the node's MAC with a local 
service/port id (which would avoid the problem of disseminating the 
node-to-EID registration information in the network)?

I'm sorry that this is not being obvious to me. Thank you for further 
clarifications,

Michael

Am 20.06.2013 02:07, schrieb Burleigh, Scott C (313B):
> 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
> _______________________________________________
> dtn-interest mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/dtn-interest
>