[dtn-interest] Comments on RFC 4838

[Michael Noisternig <[e-mail]>]

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.