[Olsr-dev] Idea for small OLSR improvement

[Mitar]

Hi!

On Sat, Apr 24, 2010 at 1:08 PM, Markus Kittenberger
<(spam-protected)> wrote:
> the problem is that links that are regarded as too bad, are currently not
> used anywhere in the mesh,..

I am not talking just about really bad links but also about very good
links which get temporary (maybe because of the bug in OLSR of WiFi
driver) removed. Like this node:

https://nodes.wlan-lj.net/nodes/node/a9c18585-0fc3-47ac-a0d1-a24b8fafe1c4

It has almost all the time ETX 1.0 link to peering node (you can also
check the graph bellow).

But then the link really fluctuates:

https://nodes.wlan-lj.net/nodes/events/a9c18585-0fc3-47ac-a0d1-a24b8fafe1c4

(Down/up events are events of removing a node from the mesh and back
as reported by OLSR.)

We check topology in 5 minutes intervals but I have reports from users
of that node that there are also many shorter removals from the mesh.
I have wrote about this some time ago and then it was suggested that
we do not use same IP for multiple interfaces. We now do not use that
anymore, but strange link drops still happen. (I think there are some
bugs in OLSR timers. But maybe it is just bad madwifi driver although
if I manually add route between nodes and ping from both directions
there is almost no packet loss (and no packet loss bursts).

This is just one example of where this would be useful. The other
example is where there is a moving tree (a realworld example) just in
the link line. And OLSR is just dropping the link and putting it back.
In this way it would be useful just to leave it alone and lower levels
will try to do something (or not).

> changing this behaviour for the last reminaing link to a node only, might
> get a bit complex, what happens if u have on very bad link and one dramatic
> bad link
> if only the very bad link it detected, it gets announced as its the last
> one, but if the dramatic bad link gets a bit better, sall we announce it
> too? or (worst case) don`t announce both? *g

I do not understand why is this a problem? It is the same as now -
logic behind deciding what to announce or not. If there are multiple
links we chose the best one. If it is just one, we keep it. If some
other comes we use the new one if it is the only one measured. So it
is just just laziness in removing the last route. Everything else
stays the same. So when new (properly measured) link is established we
clean-up previous stale route and use new one.

It can just improve things a bit. Everyhing else stays the same.


Mitar