Subject: [manet] Review of DYMO Draft

From: Georg Wittenburg <[email-masked]>
Date: Wed, 12 Jan 2011 12:19:55 +0100

Greetings all,

Having reviewed the DYMO specification, I have a couple of comments and 
questions for clarification, detailed in the below. This is applicable to rev. 
21 of the draft dated July 26, 2010.

- 3. Terminology

The reserved numeric values for unknown Distance (Dist) and Sequence Number 
(SeqNum) should be stated somewhere, preferably in this section. One could 
probably use zero (0), but it would be helpful to have some explicit statement 
about this.

- 4.2.2. Routing Messages (RM) - RREQ & RREP

TargetNode.AddTLV.Dist is listed as an optional field, but not used anywhere in 
the document

- 5.3.1. RREQ Creation

There should be an explanation why OrigNode.Dist is to be set to a number 
greater than zero and some advice on which value to use.

In fact, I'm somewhat doubtful about the Dist field in general. Sec. 5.2.2 
states that when creating or updating a routing table entry "if known, the 
Route.Dist is set to the Node.Dist". Node.Dist, in this context, is set by the 
sender of the routing message. However, for any non-trivial metric, the 
distance (i.e., the path metric) should differ depending on the link quality 
between sender and each of the potentially multiple receivers of a routing 
message. Hence, it should be up to each receiver to calculate Dist depending 
on the link quality (rather than using the sender-specified Node.Dist from the 
routing message which would be the same for all receivers).

- 5.3.1. RREQ Creation

The statement "For links that do not support multicast or situations in 
which unicast messaging is preferred, the IP.DestinationAddress for unicast 
RREQ is set to the NextHopAddress." could be more clear about what 
NextHopAddress (= IP address of the respective unicast destination) means in 
this context. The same applies to Sec. 5.5.3. "RERR Generation".

- 5.3.4. RM Handling

I found it slightly confusing that the processing of RREQs and RREPs is 
presented in the same section. Personally, I would have preferred two separate 
sections for each of them, which the commonalities (i.e., shared code in the 
implementation) in specific sub-section.

- 5.5.2. Updating Route Lifetimes During Packet Forwarding

If the processing of a data packet causes the routing timers to be reset (as 
specified in the draft), then the respective Route.Broken flag should also be 
cleared and the Route.Forwarding flag should set. This covers the case in which 
data packets arrive from a next-hop neighbor for which a route has been flagged 
as broken, but has not yet been removed from the routing table.

Further, the timers for a routing table entry should be reset when processing 
both data AND signaling packets (i.e., RREQs and RREPs). Otherwise, existing 
routes along which these packets are forwarded may get deleted before seeing 
any data traffic. Note that for RREPs this includes the timers for the routing 
table entries to both the originator and target node.

Similarly, when sending an intermediate RREP (Sec. 5.3.3), the timers for the 
routing table entry of the TargetNode should also be reset.

- 6. Administratively Configured Parameters and Timer Values

The default value of ROUTE_SEQNUM_AGE_MAX_TIMEOUT (60 seconds) may cause 
low-bandwidth routes to be discarded prematurely. As the tradeoffs are non-
obvious, it would be nice to have multiple recommendations for different 
scenarios. I realize that this may require more real-world experience with the 
protocol, but don't really consider this to be a counterargument.

Similarly, the value for ROUTE_RREQ_WAIT_TIME (2 seconds) should be more 
expressive. For instance, AODV (RFC 3561) uses NET_TRAVERSAL_TIME = 2 * 
NODE_TRAVERSAL_TIME * NET_DIAMETER = 2 * 0.04s * 35 = 2.8s. A similarly 
detailed definition should be used in this draft. Furthermore, the value should 
be large enough to give retries of RREQs a chance to succeed (possibly taking 
lower TTLs into account, if expanded ring search is employed).

Finally, the statement "The above timing parameter values work well for small 
and medium well-connected networks with moderate topology changes." is a too 
general to be useful. Once again, exact values for the number of nodes and the 
node degree that led to this recommendation would be more helpful.

Hope this is helpful,

	Georg

-- 
Dr. Georg Wittenburg
Postdoctoral Researcher
INRIA / École Polytechnique, HIPERCOM Team
Laboratoire d'Informatique de l'École Polytechnique (LIX)
Route de Saclay, 91128 Palaiseau (CEDEX)
Phone: +33-(0)1-69334126, Fax: +33-(0)1-69334044
http://www.lix.polytechnique.fr/hipercom/