[Olsr-dev] LinkQualityMult problems in 0.5.6-r5

[Mitar]

Hi!

On Sat, Sep 5, 2009 at 11:54 AM, Henning Rogge<(spam-protected)> wrote:
> I'm not sure if I like this approach... maybe an additional flag for
> interfaces (backup-if) would be better. LQ-Multiplier is used for MANY
> horrible things ^^

Like what?

I think that any dynamic routing protocol should have some way of
customizing how routing is decided and currently this is done by
LinkQualityMult. Of course you can always make a mess and do bad
things when you have power to do it but I do not believe that the
proper approach is to remove this just to be sure nobody misuses it.

It is normal that you want to prioritize links (maybe just from
economical reasons because not all links cost the same or from
political reasons because some go over "uncharted territories" and
some over more familiar ones) in OLSR. You are using OLSR in the first
place so that it would help you (dynamically) managing routes. And 0
or 1 approach is also not good as sometimes you want to switch to a
backup link when main link is "bad enough" for some value of bad.

Multiplier should be possible to set per-interface and per-link.

Maybe we could even extend this idea to be able to change
LinkQualityMult while OLSR is running and thus influence ETX with your
own external link "quality" logic. Or is this an example of a horrible
thing? :-) What would be a recommended way to extend ETX calculation
with your own formula? Because maybe this would then be a general
solution: get rid of LinkQualityMult as a configuration option and add
a plugin interface (and default plugin to have the same behavior as
now) which would allow users to change it as they see fit (through
static multiplier or dynamic based on Moon and Mars positions).


Mitar