Subject: Re: [manet] Review of DYMO Draft

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 22 Oct 2012 09:45:11 -0700

Hello Georg,

Please excuse the long delay in responding to your comments.

On 1/12/2011 3:19 AM, Georg Wittenburg wrote:

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

For both Distance and SeqNum, I included a sentence in the definition.
However, since the current distance is always a hop count, 65,535 does
not make sense as a maximum value, whereas 0 *is* a valid distance
value.

I changed the spec as follows:
	  The minimum value of distance is the number of IP hops
	  traversed, 0 for local information. The maximum value
	  is 254.  The value 255 is reserved to indicate that the
	  distance is unknown.
and
	  The value zero (0) is reserved to indicate that the SeqNum
   	  for a destination address is unknown.

> - 4.2.2. Routing Messages (RM) - RREQ & RREP
>
> TargetNode.AddTLV.Dist is listed as an optional field, but not used anywhere in
> the document

I have removed this from the base specification.

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

Done.

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

I agree with this, and after the revision to be submitted today, I
will work on using nontrivial metrics with AODVv2.  I will also post
the issue on the Issue Tracker.

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

Yes. I have made some clarification about this.

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

I hope that the new draft is much clearer about this.

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

Thanks for catching this.  I have added the following for both cases:
	"The Route.Broken flag is unset."
The Route.Forwarding flag was removed from the draft.

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

Yes, this is also true.  I have changed the draft to refer to AODVv2
messages as well as data packets.

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

I definitely agree with this.  I don't think there are any realistic
use cases where this TIMEOUT needs to be less than 600 seconds, and
probably the TIMEOUT should be even much longer than that.

In the meantime, I will change 60 to 600.

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

I hope that we can get some more recommendations for these.
My belief is that the timeout parameters are all too small.
Also, there have been experiments networks with greater than
10 hops running AODV, so I changed the MSG_HOPLIMIT to be 20.
In AODV, NET_DIAMETER was 35, and NET_DIAMETER should be less
than MSG_HOPLIMIT.

What if I change the AODVv2 parameters to match the AODV
parameters more closely?

-- 
Regards,
Charlie P.

---

From: Henning Rogge <[email-masked]>
Date: Mon, 22 Oct 2012 18:53:41 +0200

> is 254.  The value 255 is reserved to indicate that the

Do you have a proper use for this "unknown" distance? Why not just
leave out the distance TLV?

> for a destination address is unknown.

I think its a REALLY bad habit to define some crazy rules for sequence
numbers. All generated DYMO message will have sequence numbers, so if
a node remembers another node and its addresses, it also remembers the
sequence number.

Henning Rogge

-- 
Steven Hawkings about cosmic inflation: "An increase of billions of
billions of percent in a tiny fraction of a second. Of course, that
was before the present government."

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 22 Oct 2012 10:05:06 -0700

Hello Henning,

> leave out the distance TLV?

I don't have a ready answer for this just now.  I need to take a close
look at how it affects the draft.  But, thanks for the suggestion.
I'll try to respond properly within the next few days.

> a node remembers another node and its addresses, it also remembers the

Currently, there has to be some value for unknown sequence number, and
it is possible for information about sequence numbers to get lost if nodes
crash and reboot.  This was one of the important lessons from AODV.
Whatever value is chosen has to be "reserved", and then rollover has to
be specified to avoid the "reserved" value.

There is another way to do it, which I can propose later, but it might be
seen to add complexity and storage.  And anyway I couldn't do it by the
submission deadline today.

Should this be put in as an issue on the Issue Tracker?

-- 
Regards,
Charlie P.

---

From: Henning Rogge <[email-masked]>
Date: Mon, 22 Oct 2012 19:18:31 +0200

> crash and reboot.

Wouldn't this make the information related to the sequence number also
be lost? Is this really different than a non-existing database entry?

>  This was one of the important lessons from AODV.

If DYMO needs to transmit a "don't know the sequence number"
information attached to an address in an address block, just do not
attach the sequence number TLV.

Even the message sequence number is optional, no need to have a
special symbol there either I think.

> submission deadline today.

Do you expect not be able to afford a single additional bit for
"sequence number known/unknown" in the internal database?

Henning Rogge