[Olsr-users] How to make routes *very* sticky?

[Henning Rogge]

On Wed, Jun 3, 2015 at 10:01 PM, Ben West <(spam-protected)> wrote:
> Thank you Teco and Henning for the responses.  I do fully agree overloading
> a multi-hop link is suboptimal.  I'm actually doing this for the purpose of
> stress testing, i.e. wilfully creating worst case conditions.
>
> The route flapping doesn't occur when these nodes don't use olsr just have
> static routes set, yet with the same traffic (over)load.
Obvious things are obvious.

Where should "route flapping" come from static routes?

> My interest in
> trying to deploy olsr in this mesh is to see if it could be useful in
> establishing backup routes through the redundant wifi links, in the event of
> a repeater node along the preferred multi-hop route going down.  (I.e. where
> just setting static routes manually would fail.)

Are you talking about backup "interfaces" (different technology, maybe
wifi with a WAY different channel?) or just backup links (same
interface, other neighbor).

With wifi you have to start thinking about "collision domains"...
EVERY wifi packet is broadcast on OSI Layer 1, that is the nature of
electromagnetic waves in the air. Wifi tries to solve its problems by
a "monitor channel, they try and use Acknowledgement to see if it
worked"... which doesn't work that well for a Hidden Station scenario
(three nodes, the middle can see left/right, but left/right cannot see
each other. Left and right can still jam each others transmission to
the middle).

> Indeed, I wouldn't expect olsrd to flap routes disruptively under moderate
> traffic load.  However, the catch-22 I'm seeing is that the backup routes
> through the weaker links would be more likely to saturate (i.e. since their
> capacity is less), meaning the very conditions where I'd like to see olsr
> establish the backup routes are also those where it may start flapping
> routes disruptively.

You are seeing the compromise build into every routing metric... you
get input (wifi data) which contains noise, you need to choose a
tradeoff between reaction speed and stability.

Olsrd calculates the metric of a link based on the OLSR control
traffic received from the node. The metric averages the incoming loss
rate in a time window of 32 seconds.

At the moment you have four nodes, at default each of them is
producing a HELLO every two seconds and a TC every five seconds. TCs
are repeated by every node.

This means you get ~ 1-2 control packets per seconds on a link, maybe less.

This means the LQ (link quality) part of the metric is measured by
just ~30-50 broadcast packet. When you look up the math about throwing
a coin 50 times and judging how "fair" the coin is you will notice
that you still don't have a really good confidence in the result.
There is nothing you can do about this except for "getting more
data"... either by sending out more TCs/HELLOs per second or by
averaging over a larger time window. The first will increase the
overload situation even more, the second will make the protocol more
slow to react to changing links.

Priorization of OLSR traffic should help a bit, making sure that
RTS/CTS is working will help too. But wifi does not handle high-load
situations well in Adhoc mode with Hidden Stations.

> Independent of queuing discipline (if any), what is the best way simply to
> make olsrd extremely unwilling to change routes?  I.e. where a particular
> link has to be extremely bad (or non-existent if the node goes down) where
> olsrd alters any routes?

You would either have to change the parameters of the routing metric
or design another one. But I would suggest NOT to optimize your metric
to a very special case that is already handled BADLY by the linklayer
below. It will get you in trouble in more normal situations.

Maybe traffic shaping could help a bit... make sure you don't saturate
the wifi interface that much... unfortunately this is very difficult
because of the multi-datarate capabilities of wifi.

Henning