[Olsr-dev] Routing loops [was: Freifunk Testing]

[Juliusz Chroboczek]

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

This points at the fact that OLSR is not designed for sparse networks.
In the dense networks for which OLSR is designed, it is reasonable to
assume that the LS databases are in synch most of the time; not so in
sparse networks, which rely on a number of marginal links.

The original OLSR ensures that SPF is only run in well-connected parts
of the network using the so-called ``hysteresis'' setting.  Not so OLSR-ETX,
obviously.

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

I'm not sure why that works.  My guess is that you're assuming that
given a doubly-connected part of the network (one that may give rise
to a routing loop), it is at least simply connected with zero-loss
links to ensure that the LS database is in synch.  Could you clarify 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.

Sven-Ola, as I know you are aware, there are other approaches.  DSDV,
AODV and Babel use algorithms that are provably robust in the presence
of packet loss.  If the nodes in a DSDV mesh become unsynchronised,
then parts of the network may be temporarily black-holed, but under no
circumstances will routing loops internal to the mesh arise.

                                        Juliusz