[Olsr-dev] Freifunk Testing

[Bernd Petrovitsch]

Hi all!

On Sun, 2008-06-15 at 09:48 +0200, Sven-Ola Tücke wrote:
[...]
> no paper on this AFAIK. This is the result of practial implementation, testing 
> and observing. 

Nevertheless a IMHO nice writeup.

> 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)?

In theory this should fix routing loops as it is quite important for the
local neighborhood to know the exact data and pretty much irrelevant for
9 hop nodes.
But I fear it needs more analysis and simulation to get more thorough
wisdom about this.

> * 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.

I'm not following B.A.T.M.A.N. in detail but how much traffic overhead
does this generate?

> * 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. 

Never underestimate the power of nifty pictures in presentations for the
uninformed and/or clueless. SCNR ....

> 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 
    ... as seen by this one node ....
> function. Or a disadvantage: if network/info grows too large e.g. to a size 
> an embedded device cannot handle.

For the last point: Personally I don't think that that will be a real
issue as the size of "embedded devices" are also growing.
And if a mesh net really is too large (how many nodes is that - without
or without other space/CPU savings) for a LinkSys: Is that  mesh net
actually usable (or does it break because of too much OLSRD traffic)?

OK, I don't expect an answer to it.

> 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...

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services