Re: AODVv2 implementation

Hello Henning and all,

Please excuse my long delay in answering emails on this topic. Follow-up 
inline...
> Hi Juliusz, hi Charlie,
>
> I would not say that AODV (v1 or v2) is impossible to implement (some
> people have done it), but it's much harder to do on most general
> purpose operation systems than OLSR(v1 or v2) because of its necessary
> interaction with the forwarding plane.

AODV is an on-demand protocol.   A route may not exist when needed for 
an application.  As I understand it, that also means that when such an 
application runs, a route somehow needs to brought into the route 
table.  That has not been a standard feature for the operating systems 
that I am familiar with.  Instead, if a route does not exist when called 
for by the application, it has been considered an error.  So, we made 
the design choice of discovering a route in order to correct the error.

> ....

> ... a running implementation of AODVv2 <is> also the only way to test
> if the metric integration in AODVv2 is working reasonably well,
> because I don't think ANY routing protocol will do us good with
> hop-count metric on any wireless radio that supports multiple data
> rates.

Strong agreement on the unsuitability for hop-count for many systems.  
Section 5 specifies the following:

>
>    AODVv2 currently supports cost metrics where Cost(R) is strictly 
> increasing ...


The restriction to use of only monotonically increasing metrics goes a 
long way to avoid the introduction of errors in the metric calculations 
(compared to hop count calculation).  For that reason the experience 
with AODV using hop-counts provides some confidence that AODVv2 metric 
evaluation will work.

Also, one last bit of follow-up, out of order:

On 11/26/2023 11:10 PM, Henning Rogge wrote:
> On Sat, Nov 25, 2023 at 3:32 PM Juliusz Chroboczek<[email protected]>  wrote:
>> Hi Charlie,
>>
>>> I do not have an implementation.
>> It is my understanding that Henning has concerns about the implementability
>> of AODVv2.  Given Henning's track record, I recommend that we should not
>> dismiss his concerns.

It should go without saying, but I certainly never intended to dismiss 
Henning's concerns.

Regards,
Charlie P.

_______________________________________________
manet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/manet