[Xorp-hackers] OLSR assert

[Bruce Simpson]

Bruce Simpson wrote:
> Ben Greear wrote:
>   
>> The reset_twohop_mpr_state counts neighbors that are strict and reachable.
>> But, the consider_poorly_covered method checks for reachability == 1.
>> In the log below, neighbor 10.7.7.7 is not counted in poorly_covered.
>> Should we maybe check for reachability() > 0 instead of == 1?
>>   
>>     
>
> Off the top of my head, for classical OLSR, as specified in the RFC, it 
> needs to be covered by a minimum of 1 neighbour, in terms of links.
> I don't have the code in front of me, obviously a test of reachability 
> == 1 would be naive. If the fix is that simple, that's great.
>   

I just skimmed this code again. Based on how I interpreted the RFC, a 
'poorly covered two-hop neighbour' is indeed one which is reachable only 
by a single one-hop neighbour, so the reachability test 1 is fine.

This is the case for classical OLSR, but not the case for ETX where the 
reachability has fractional dimension, and it's something the 
'reachability' metric has to take into account.

We could use floating point to compute this, but integer operations are 
generally better for performance, that's just an implementation 
constraint. There are places where you can't get away from using 
floating point. It's not that bad if the target supports IEEE 754 
efficiently.

An uncovered two-hop neighbour would not be considered in the MPR 
computation, and the existence of such would normally only be an 
artefact of pending updates.

Jitter is usually used to avoid such situations, and isn't fully 
implemented in the XORP OLSR process (I did say it was unfinished work :-)).

There are a number of areas where the theory doesn't meet the practice. 
The OLSR.org crew did do a lot of modeling work in the end, and there's 
places where some of the theory in the RFC falls down.

cheers,
BMS