[Olsr-dev] Freifunk Testing

[Sven-Ola Tücke]

Moins,

no paper on this AFAIK. This is the result of practial implementation, testing 
and observing. 

While I'm not a routing expert (you may note that I've missed to learn the 
specific vocabulary) this is my personal opinion on different mesh routing 
protocols doing loops and such:

* Loops occur, because a couple of nodes do not agree on their routing 
decisions. Two reasons: different (topo) input or different algo (also known 
as bugs).

* While algo/bugs can be solved by deploying software, different input is 
fundamental. Transferring state info over lossy links automatically leads to 
different input. At least on the time axis (e.g. if you make a snapshot of a 
typical mesh, you'll find that nodes have a different notion on the networks 
status).

* The original RFC-OLSR also includes an optimization to limit the amount of 
traffic necessary to spread info by use of MPRs (some "overlay network" of 
nodes involved in info transmission).

* Current OLSRd approach to overcome this is "brute force". Simply send out 
info more than once. And disable the MPR optimization so every possible link 
spreads info. This is a "bandwith wasting does not care" approach. To limit 
ridiculous high bandwith wasting, we use higher spread rates in near 
neighborhood (in hops) which is called fisheye (or HSLS? didn't read the 
paper - really the same)?

* The other approach is to throw away "calculation based on input". And use 
measurement instead. This is realized with B.A.T.M.A.N. Constantly flood the 
network with a lot of packets and do the routing based on "where does most 
packets come through". Has some aspects of ant-routing. Works, because Radio 
links always loose packets. Currently - as elektra pointed out - BATMAN is 
superior to OLSR because it does reasonable routing decisions and does not 
loop.

* With OLSR every node is aware of the complete network. Which can be used 
e.g. to draw nifty pictures without additional softs installed on every node. 
This is an advantage: you only need the routing daemon to have the complete 
picture) and nobody can disable this "side effect" without loosing the 
function. Or a disadvantage: if network/info grows too large e.g. to a size 
an embedded device cannot handle.

To come to a end: spreading topo info is the critical thing. The recent OLSR 
implementation changes are done to make is possible to change the info spread 
algo in the near future. As far as I understand it: will be something based 
on a more active role of each node - query for topo / sync answer with  
diffs. But that has to be elaborated by the original coders...

// Sven-Ola

Am Sonntag 15 Juni 2008 07:53:16 schrieb Jan Groenewald:
> Hi
>
> On Sat, Jun 14, 2008 at 10:47:01PM +0200, elektra wrote:
> > Btw: There should be an option to disable the MPR algorithm completely.
> > It is superfluous anyway for Freifunk-like configurations since Wizard
> > of OS 2004. Setting MPR redundancy to 7 in the config is just a dirty
> > hack to get rid of the negative effects of  MPR selection and the
> > problems that are growing out of it.
>
> Is there somewhere we can read why/how MPR is bad for freifunk-like
> configurations?
>
> regards,
> Jan
>
> --
>    .~.
>    /V\     Jan Groenewald
>   /( )\    ICT Manager
>   ^^-^^    www.aims.ac.za