Subject: Re: AODV WG Last Call for Comments

From: Yih-Chun Hu <[email-masked]>
Date: Tue, 12 Feb 2002 18:58:09 -0500 (EST)

Sorry these comments are late. These comments are for the WG last call of
aodv-10. This draft appears to be a substantial improvement in the
definition of AODV, as it is more clearly and precisely specifies the
protocol. I did find a few problems with the draft as it stands, and would
like to raise a couple points previously brought up on the list. 

As was mentioned on the list before by Erik Nordstrom (in Message-ID
<[email-masked]> on December
13, 2001), Hello messages don't work with unidirectional links, since
Hello messages can propogate over such links, but packets can't flow in
the reverse direction. 

Because of the use of NODE_TRAVERSAL_TIME, it seems inconsistent to allow
any node to hold a packet beyond NODE_TRAVERSAL_TIME (ie a node buffering
a packet for NODE_TRAVERSAL_TIME MUST drop the packet), and
NODE_TRAVERSAL_TIME should not be a configurable parameter at any node
(needs to be consistant network-wide).

Any cycle in the network which has aggregate latency PATH_TRAVERSAL_TIME
could cause the infinite looping of RREQ packets, and each time the RREQ
goes around this cycle, it would cause another flood of the entire
network, subject to TTL constraints. PATH_TRAVERSAL_TIME therefore should
be conservatively set to NETWORK_NODES * NODE_TRAVERSAL_TIME. 

The definition of PATH_DISCOVERY_TIME in Section 10 is unparsable.

This draft does not seem to define a default RREQ_RETRIES, nor does it
provide any guidance on how one might set that particular parameter. 

There may be a node X which has a very dynamic network on one side of it
and a very static network on the other side of it. It may be possible for
X to issue 2^31 sequence numbers on the active side between new sequence
numbers on the static side. This would cause the static side to believe
that all new sequence numbers were stale for quite a long period of time,
and possibly preclude routing to X. A more aggressive mechanism for
dealing with wraparound is needed. 

Suppose some node Y has a route to X and sends packets over that route
once per ACTIVE_ROUTE_TIMEOUT. If X reboots, and K sequential data packets
or corresponding RERRs are lost over the entire path from X to Y, Y will
be unable to find routes to X until the newly chosen sequence number
becomes greater than Y's current sequence number. 

The draft should give some guidance about the types of networks for which
AODV is a suitable routing protocol.

The precursor list is only set in response to RREPs, but RREQs serve as a
form of RREP in that they create routing state. As a result, precursor
lists SHOULD be set in the sender when an RREQ it propogates is received. 

In Section 10, the draft allows a node to "possibly [reconfigure] the
HELLO_INTERVAL." This is too vague to be in a specification. Allowing
arbitrary changes to HELLO_INTERVAL is also problematic if a node does not
always boot to a consistant HELLO_INTERVAL. For example, if a node X sets
HELLO_INTERVAL to 10s, and advertises it, upstream neighbors only require
one HELLO within 30s. X reboots and need only wait 5 seconds before it
starts participating in the protocol again. Nodes would no longer be able
to reach X. 

In Sec 6.2, the draft allows the receipt of AODV control packets to
confirm that a neighbor is still there. Not only does this suffer the same
problem with unidirectional links as Hello packets, it also is
ill-specified. The language in the draft can be interpreted to allow an
RREQ that has traversed multiple hops could be used to renew the neighbor
status of the source of the RREQ.