Subject: Re: [manet] Review of DYMO Draft

From: Georg Wittenburg <[email-masked]>
Date: Sun, 10 Nov 2013 20:11:28 -0500

Hello Charles,

I guess now it's my turn for apologizing after taking overly long in
getting back to you.

First off, very glad I could contribute to AODVv2 with my feedback.

To answer the question in your mail below, regarding whether it would be
better to have AODVv2 parameters resemble those of AODV more closely (as
opposed to those of DYMO) here's my view: The key benefit of the AODV
spec over the DYMO spec used to be that it was clear how protocol
parameters were derived from network properties, e.g., timeouts being
derived from expected maximal network diameter. It would be great if
AODVv2 could establish a similar level of transparency, and possibly
suggest defaults for some typical deployments.

If you're interested in specific parameter values, the values I used in
my deployments were a mix of DYMO and AODV values. These values provided
best layer 3 connectivity for the applications I was evaluating at the
time on our 36-node IEEE 802.11b testbed. The exact values are listed on
page 180 of the document at
http://page.mi.fu-berlin.de/gwitten/papers/wittenburg10spi.pdf.

Let me know in case there are more questions.

Best,

    Georg

Dr. Georg Wittenburg
Freie Universität Berlin
http://page.mi.fu-berlin.de/gwitten/index.html

On 22.10.2012 12:45, Charles E. Perkins wrote:
>
> 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?
>