Subject: [manet] Re: AODV WG Last Call for Comments

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 28 May 2002 18:57:17 -0700

Hello Yih-Chun,

I hope you can remember the context for your comments of February 12!

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

This is true.  In order to fix it, we would put in an optional list
of neighbors in the Hello message.  That might not be so bad,
after all, since the Hello messages "need" to be bigger, to compare
in size with data packets.  As it is, though, we don't want to
use unidirectional links, and use the RREP-ACK message to avoid
having them be part of a routing path.

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

The best parameter would be "NET_TRAVERSAL_TIME".
Now we define that instead of
          NETWORK_DIAMETER * NODE_TRAVERSAL_TIME.
We also say that reconfiguring NODE_TRAVERSAL_TIME at a
node would require network-wide knowledge.

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

This should not be a problem, as long as the unique identifier for a RREQ
is maintained longer than the aggregate latency of the loop, which would
be almost certainly the case.

> The definition of PATH_DISCOVERY_TIME in Section 10 is unparsable.

Yow, sorry we missed that!

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

How about 3?  It would normally depend on error rates and congestion levels
and importance of the application, and you are right that we don't know how
to provide guidance on factoring those details together.

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

I have a hard time believing this!  That's 2 billion sequence numbers.
I reckon we could limit sequence number generation to be no more
than 100 per second, if this is really a concern.  I can't imagine that
this would ever be a realistic cause of a protocol error.

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

This is the point of the DELETE_PERIOD.  The choice of K is explicitly
made to prevent this from happening.

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

I think it's suitable for all types of networks for which one can have the
right kind of system-wide distribution of RREQ messages, and for which
the mobility factor is not so huge as to invalidate any hope of route
convergence, and for which unidirectional links do not predominate.
In other words, the kinds of networks that have been largely the focus
of the [manet] working group.

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

As stated, I do not exactly agree with your suggestion.  However, I do agree
that RREQ does create routing state, and that this routing state should be
considered when processing other incoming RREQs.  The right action is
to include the next hop towards the originator in the precursor list
for the destination, and the next hop towards the destination in the
precursor list towards the originator, at the time when the RREP
packet is received.  However, something other than precursor list
management might be indicated for the transient RREQ state when other
RREQs are received for the originator.

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

Any such disconnection would be temporary, but you are right that
we had not examined the consequences of this scenario.  I have
included language according to your suggestion.

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

O.K.  Thanks for the pointer!  We have tightened up that
language.  I think that disallowing unidirectional links to
be part of discovered routes will mostly fix this problem.
Before your observation, I think that we were assuming that
"neighbor" carried along with it the implication that the
neighbor node was only one hop away.

Regards,
Charlie P.

_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet