Subject: RE: AODV WG Last Call for Comments

From: Scott Corson <[email-masked]>
Date: Wed, 13 Feb 2002 09:31:39 -0500

Yih-Chun,

The comments are late.  The WG last call closed last Friday and the draft is
with the IESG at this time.

Still thanks for the input and I will forward these to the ADs for their
consideration during IESG review.

Thanks,

-Scott

> -----Original Message-----
> From: Yih-Chun Hu [mailto:[email-masked]]
> Sent: Tuesday, February 12, 2002 6:58 PM
> To: Joe Macker
> Cc: [email-masked]
> Subject: Re: AODV WG Last Call for Comments
> 
> 
> 
> 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. 
> 
>

---

From: Manel Guerrero Zapata <[email-masked]>
Date: Wed, 13 Feb 2002 21:00:47 +0200

Hi :)

I know... I know... I'm also late. :(

But, if you are interested in more. Here it comes a couple of comments:

COMPARING SEQUENCE NUMBERS
==========================

In 6.1 (Maintaining Sequence Numbers), there is a new paragraph about how
sequence numbers should be compared. The main idea behind this is that if
a sequence number overflows, rounds back to zero. So sequence numbers might
be 'reused'. It is like the big hand of a clock.
Therefore, to check if a destination sequence number received in an AODV
message is stale or not, it checks if it is in the half after or in the half
before of the clock's hand.
The very same concept that makes that if you know that it's 5 o'clock and your
watch says that it is 4 o'clock, you will think you watch is one hour late
(but you never think that it is 11 hours advanced).

That is not a very bad assumption, until somebody wants to send a packet to us.
If it does not have an active route and does not know no sequence number it
will use '0' (acording to 6.3 (Generating Route Requests)).

It is bad because when we receive it, we have to do the following (from 6.1):
       "Immediately before a destination node originates a RREP in
        response to a RREQ, it MUST update its own sequence number to
        the maximum of its current sequence number and the destination
        sequence number in the RREQ packet."

In the example of the watch, zero would be 12 o'clock. In the new paragraph
'maximum' should be adapted to the watch concept (so we would check
if the sdn in the RREQ is stale compared with our own sequence number).
But that also means that if it is 7 o'clock and the RREQ comes with 12
o'clock I'll update to 12 o'clock (thinking that my clock is 5 hours late).
Which, of course, makes no sense.

The problem comes, not from the 'clock alike' system, but from the fact
that nobody should tell me which is my sequence number. Especially when
I could easely keep track of it.

My proposed solution would be (again):

8<--------------------------------------------------
* Every time you modify your sequence number, you store it somewhere.
* When you reboot you read the value, and start to operate
	(who wants to wait for DELETE_PERIOD (15 seconds) ! )
* You increment your own sequence number in the following situations:
	- Before generating a RREP (being you the final destination)
	- Before sending a Hello (this can be considered as a specific
		case of the previos situation)
	- Before originating a RREQ flood (as it is said in 8.1)
* You don't update your destination sequence number believing in what
	others say. You _know_ which is your sequence number.
-------------------------------------------------->8

DELETE PERIOD
=============

The default value has changed:

   "DELETE_PERIOD = K * max (ACTIVE_ROUTE_TIMEOUT, HELLO_INTERVAL)
	(K = 5 is recommended)."

But then, the rest of the text about delete period seems quite contradictory:
K seems to play the role of ALLOWED_HELLO_LOSS (although it has a bigger
value). But then it should be: max(A_R_T, K * H_I) to make sense with:

   "If Hello messages are used, then the
    ACTIVE_ROUTE_TIMEOUT parameter value MUST be more than the
    value (ALLOWED_HELLO_LOSS * HELLO_INTERVAL)."

Best regards,

	Manel Guerrero Zapata