Subject: [dtn-interest] Comments on RFC 4838

From: Michael Noisternig <[email-masked]>
Date: Tue, 18 Jun 2013 11:06:55 +0200

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.

---

From: Sebastian Schildt <[email-masked]>
Date: Tue, 18 Jun 2013 17:39:49 +0200

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 <[email-masked]>:

> 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

---

From: Joerg Ott <[email-masked]>
Date: Wed, 19 Jun 2013 10:30:41 +0300

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:
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/dtn-interest
>

---

From: Caini Carlo <[email-masked]>
Date: Wed, 19 Jun 2013 11:06:35 +0200

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

---

From: Michael Noisternig <[email-masked]>
Date: Wed, 19 Jun 2013 14:11:15 +0200

Hi Jörg,

thank you for your response.

First of all I would like to apologize as I have probably been behaving 
a bit like the elephant in the room. I should have been not so 
presumptuous in assuming that you are not aware of the issues raised. I 
also should have checked your mailing list discussions beforehand... my 
bad. Finally, I guess I was taking "RFC" a bit too literally. I do want 
to raise here to my defense that I was originally looking at the 
documents from a security perspective, and it was actually my intention 
to comment on RFC 6257, which I considered to be a rather recent or 
"active" document. Maybe I should ask that my comments, particularly on 
the other RFCs, be better interpreted as questions (and critique) rather 
than criticism (language issue, mea culpa).

Yes, I am familiar with Kevin Fall's paper. It was obviously my 
expectation about RFC 4838 that was wrong, so...

I am aware that there are various implementations of the bundle 
protocol, even for resource-constrained devices. Still, we are seeing 
issues with the specification in our scenario, which (in part) was the 
intent of my posts on the other (non-security) RFCs. Of course, as I 
have been told that most of my arguments have been made before, please 
feel free to disregard the noise.

Your links are quite relevant to our work, I will definitely look into 
these projects! Thanks!

Michael

Am 19.06.2013 09:30, schrieb Joerg Ott:
>> 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)
>>
>>> 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
>>> 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
>> 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
>> 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.
>>
>> 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:
>>> 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:
>> 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.
>>>
>> 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
>>
>>
>>
>>
>>
>>

---

From: Michael Noisternig <[email-masked]>
Date: Wed, 19 Jun 2013 14:21:41 +0200

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

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

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.

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

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?

> 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

---

From: Michael Noisternig <[email-masked]>
Date: Wed, 19 Jun 2013 14:30:51 +0200

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:
>> 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).
>
> 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.
> 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.
>
> 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
>
>
>
>> 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.
>>
>> 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----
>>
>> the document promises something different than what it delivers. I had
>> in the document instead was "a DTN architecture for the bundle overlay
>> specification in a subsequent mail. Following are 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:
>> require the source EID be set to the EID of the endpoint that uniquely
>> identifies the DTN node (the "singleton" endpoint)?
>>
>> 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:

---

From: Joerg Ott <[email-masked]>
Date: Wed, 19 Jun 2013 15:38:44 +0300

Hi Michael,

not sure if I came across wrong (besides one incomplete sentence).
We are aware that there are quite a few issues -- sometimes flaws
with better insight now, sometimes design choices to revisited,
etc. -- and input to our upcoming revision discussion is indeed
very much appreciated.  In fact, we have had way too little feedback
from specific (other than maybe space) scenarios on the list.

So, no elephant to be seen anywhere :-)
And, please carry on.

Thanks and cheers,
Jörg

---

From: "Burleigh, Scott C (313B)" <[email-masked]>
Date: Thu, 20 Jun 2013 00:07:42 +0000

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

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

Hi Sebastian,

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

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

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

Thanks,
Michael

---

From: Michael Noisternig <[email-masked]>
Date: Thu, 20 Jun 2013 11:40:40 +0200

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

---

From: "Burleigh, Scott C (313B)" <[email-masked]>
Date: Thu, 20 Jun 2013 15:28:34 +0000

You're right, Michael, the relationships are not as clear as they ought to be.  One thing to bear in mind is that RFC 4838 was written quite a while before RFC 5050, and in that interim the DTNRG engaged in some fairly spirited negotiations of protocol details; RFC 5050 is the product of those negotiations, and it's a normative protocol specification rather than an informative architecture overview, so wherever you see a conflict between the documents it is safer to go with the text in RFC 5050.

Among the decisions that came out of the RFC 5050 negotiations was an intentional generalization of the concept of a BP "application".  There are no application IDs anywhere in DTN; formally, bundles are never addressed to applications.  From the BP perspective, "applications" are merely the constituents of the "application-specific element" of the "application agent" of a node.  An "application" might be hardware or software.  It constructs, requests transmission of, accepts delivery of, and processes application data units (ADUs), somehow; the manner by which it asks the node's protocol agent to transmit application data in bundles and deliver application data that was received in bundles is left entirely to the implementation.  So there's no formally defined relationship between applications and endpoints at all.  An endpoint is simply a set of nodes, which any given node can join or withdraw from at any time; formally, it has nothing to do with applications.

In practice, of course, every implementation provides a concrete, specific way for an application to ask for transmission of data in a bundle whose source EID is a specified string and to ask for delivery of data received in bundles whose destination EID is a specified string.  Every CBHE-compatible implementation, in particular, lets you construct an EID comprising a numeric node ID (MAC address would be a good choice) and a numeric service (port-like) ID; it lets an application request transmission of a bundle whose payload is some ADU and whose source EID was constructed in this way; and it lets an application request delivery of ADUs that are the payloads of received bundles whose destination EID was formed in this way.  But these are implementation mechanisms, not Bundle Protocol requirements.

Scott

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Noisternig
Sent: Thursday, June 20, 2013 2:41 AM
To: [email-masked]
Subject: Re: [dtn-interest] Comments on RFC 4838

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):
> From: [email-masked] [[email-masked]] on 
> behalf of Michael Noisternig [[email-masked]]
>> 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 
> 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:
> 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
>> 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
>

---

From: Michael Noisternig <[email-masked]>
Date: Thu, 20 Jun 2013 18:38:42 +0200

Thanks, Scott, for the additional clarification!

I may need to bend my head around it one more time but it does give me a 
clearer picture!

Michael