Re: [manet] DYMO/AODVv2 and LOADng -- Problems and Proposed Solutions

"Charles E. Perkins" <charliep@computer.org> Tue, 04 December 2012 18:26 UTC

Return-Path: <charliep@computer.org>
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4B0F21F8CB0 for <manet@ietfa.amsl.com>; Tue, 4 Dec 2012 10:26:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FvMJIWkjVz6n for <manet@ietfa.amsl.com>; Tue, 4 Dec 2012 10:26:13 -0800 (PST)
Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id C331C21F8CAE for <manet@ietf.org>; Tue, 4 Dec 2012 10:26:12 -0800 (PST)
Received: from [107.1.141.74] (helo=[192.168.253.71]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charliep@computer.org>) id 1TfxC7-0006Ri-DH; Tue, 04 Dec 2012 13:26:11 -0500
Message-ID: <50BE4036.30507@computer.org>
Date: Tue, 04 Dec 2012 10:25:58 -0800
From: "Charles E. Perkins" <charliep@computer.org>
Organization: Saratoga Blue Skies
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Marius Portmann <marius@itee.uq.edu.au>
References: <55276FFE1B06A541A659C0B360E8066F17E689@UQEXMDA8.soe.uq.edu.au>
In-Reply-To: <55276FFE1B06A541A659C0B360E8066F17E689@UQEXMDA8.soe.uq.edu.au>
Content-Type: multipart/alternative; boundary="------------010302090205060505060308"
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad861efc673f53c3bb5e637f511fc4fc19ea350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 107.1.141.74
Cc: "'manet@ietf.org'" <manet@ietf.org>
Subject: Re: [manet] DYMO/AODVv2 and LOADng -- Problems and Proposed Solutions
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Dec 2012 18:26:13 -0000

Hello Marius,

Interesting results.  I have some follow-up questions.

On 12/3/2012 9:21 PM, Marius Portmann wrote:
>
> (1) Non-Optimal Routes
>
> --------------------------------
>
> On-demand/reactive routing protocols (such as AODV, DYMO and 
> LOADng) often fail to discover the best (shortest) routes [1,2].
>

This is certainly true.  There have been measurements about how far from 
optimal
the routes can be, and if I remember correctly it's typically somewhere 
in the
neighborhood of 10%, depending on congestion and node mobility.

> The problem is that during route discovery the destination (target) 
> node does not forward route requests; so, nodes that lie downstream of 
> the destination node frequently create non-optimal routes to the 
> source. Knightly and Miskovic [1] have shown that "poorly selected 
> paths can have significantly higher routing-metric costs, and their 
> duration can extend to minute time scales".
>
> We have verified that this problem exists in DYMO and LOADng.
>

Moreover, the result makes intuitive sense.  However, the nodes which 
establish
non-optimalroutes to the source are also unlikely to use those routes.

> As a possible solution, we propose that route requests are always 
> forwarded, even by nodes generating a route reply [2,3]. The forwarded 
> request should include a flag stating that a reply has already been 
> initiated. In [3] it is shown that this increases the quality of 
> routes. Of course this could increase the overhead of control 
> messages, but in most of the cases the additional overhead is minimal, 
> since a request floods the entire network anyway.
>

This can be made into an optional behavior, controllable either by a
system-wide configuration parameter, or a new RREQ option.  I would
not expect that it should be the default behavior.


> (2) Route Reply Loss
>
> -----------------------------
>
> AODV can lose route replies 
> (http://www.ietf.org/mail-archive/web/manet/current/msg05702.html).
>
> The reason is that route replies are only forwarded by an intermediate 
> node when the node updates its routing table.
>
> This problem has partly been solved in DYMO and LOADng by increasing 
> sequence numbers when initiating a route reply.
>
> However, a careful analysis shows that replies can still be lost; 
> yielding again non-optimal routes or route discovery failures. Namely, 
> if one route reply overtakes another, i.e., a newer reply reaches a 
> node earlier than an older one, then the older route reply is dropped [4].
>

I guess you mean that the two RREPs under discussion were going towards
two distinct Originating Nodes. Otherwise, it would be good for the 
older RREP
to be dropped.

For the case of two distinct Originating Nodes, the behavior is a protocol
error that needs to be fixed."Always forwarding" RREPs is one alternative,
and certainly preferable to a new Route Discovery cyclein the network.
I am confident that there is a better solution, and I will work on finding
and specifying it.

> (3) Route Request Loss
>
> ---------------------------------------------
>
> Similar to (2), route requests might be lost in DYMO and LOADng.
>
> Namely, if one route request overtakes another, i.e., a newer request 
> reaches a node earlier than an older one, then the older route request 
> is dropped.
>
> This problem does not occur in AODV, thanks to the use of a list of 
> previously seen RREQ IDs.
>

I think that a "better" solution for (2) will also resolve this problem.
Here, the solution of "always forwarding" seems much less palatable.

Thanks much for reporting these error cases, and for providing the
references.

-- 
Regards,
Charlie P.