[Olsr-dev] LinkQualityMult problems in 0.5.6-r5

[Henning Rogge]

Am Samstag 05 September 2009 12:25:06 schrieb 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.
The problem is it's practically impossible to manipulate the routing with 
lqmult correctly unless you are the administrator of ALL nodes in the net. 
Other users will see that their routing is strange (because of your changes) 
and will change THEIR lqmults to "correct" it... that's a game you cannot win.

> 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.
Backup link is just a name for "don't use it unless it's the only way".
Anything else should be handled by the routing metric.

> Multiplier should be possible to set per-interface and per-link.
No
 
> 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).
HELL NO !

MANETs (mobile ad hoc networks, Freifunk is a special case of this) do work 
because they use a sane routing metric on all nodes... and they use THE SAME 
routing metric. You cannot really change global behavior with local changes 
without lot's of problems for the rest of the network.

Could you change if the patch in the attachment makes any difference for you ? 
It doesn't really change anything except some "rewording" in the FPM routines, 
which seem to be dependant on architecture and bitlength (32/64).

Henning
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fpm.patch
Type: text/x-patch
Size: 1208 bytes
Desc: not available
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20090905/09ae3447/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20090905/09ae3447/attachment.sig>