[Olsr-dev] Freifunk Testing

[Henning Rogge]

There are two main problems with the OlsrV1 RFC and one main problem
with the old olsrd (pre version 0.5) routing agent.

The first problem of OLSR (as presented in the RFC) is the routing
metric. A hopcount metric is a great idea in "nearly no loss"
networks, and it works very well in simulated wireless networks as
long as you use a "Two-Ray ground" model for layer 1 (standard model
in the NS-2 simulator). In reality hopcount metrics try to use the
longest (and worst quality !) links and break down within moments. I
discovered it myself when I did some simple simulations with a more
realistic layer-1 model.

The second problem is that the MPR algorithm has no redundancy. You
hope that one node will receive your and all two-hop neighbor nodes
will receive the retransmission. So you should integrate a little bit
more intelligence in choosing your "relays". New routing metrics try
to integrate the size of the "collision domain" into their alogrithm
because of similar reasons. Sending it through all neighbors will be a
desaster in dense networks.

The problem with the old olsrd implementation was that it performed
(in terms of CPU usage) horrible. This results in packet drop in
larger networks.

We have adressed most of the problems in the olsrd implementation and
did a lot of preparations for the next step (clean up data structures,
use efficient algorithms, get rid of the ETX/hopcount split in the
codebase, extract the metric logic into a plugin system). Olsrd 0.5.6
will become a "infrastructure release", one that has made lots of
advantages in the codebase, but not as much (except bug fixing) in the
algorithms.

---------------

I have read the BATMAN Draft you send to the IETF (not the IEEE ;) )
and I have to say BATMAN has one mayor problem too. BATMAN has no
"tuning parameters", you have one timer value and I don't see many
possibilities to integrate a good routing metric. You just hope that
the "flood the hellos and backtrack them" will produce a good routing
strategy. You cannot even use the bandwith of a link for routing
decissions, because the bandwith cannot be propagated. So my question
is where does the BATMAN plan to go from the current state ?

---------------

If you want Elektra, we can continue with a technical discussion, but
please don't just try to state "facts" while mixing up observations
and reasons.

Fish-Eye algorithms are used to keep the traffic low, but they
introduce ADDITIONAL possibilities for routing loops (at the edge of
the fish-eye domains). So it's a tradeof between traffic problems and
routing update problems.

If you have problems with payload suppressing routing packets you have
to use traffic shaping or priorization, Just creating more routing
packets might make the situation even worse.

And finally, judging the performance of an algorithm running with not
enough CPU power (because of inefficient code) is at least a little
bit suspect...

Henning

-- 
"Wo kämen wir hin, wenn alle sagten, wo kämem wir hin, und niemand
ginge, um einmal zu schauen, wohin man käme, wenn man ginge." (Kurt
Marti)