[Olsr-dev] LinkQualityMult problems in 0.5.6-r5

Henning Rogge (spam-protected)
Sat Sep 5 13:52:58 CEST 2009

Am Samstag 05 September 2009 13:42:24 schrieb Mitar:
> Hi!
> On Sat, Sep 5, 2009 at 1:03 PM, Henning Rogge<(spam-protected)> wrote:
> > The problem is unless it's a complete trivial situation (or one you
> > control all nodes with the links you want to command) lqmult is a very
> > blunt tool.
> Agreed. Please give is a better tool. Not just remove this blunt tool.

One of these tools are plans for a "internet gateway tunnel daemon" we plan 
together with the openwrt crew. This way users will have a good way to 
whitelist/blacklist internet gateways and stop them from flapping without 
messing with link qualities.

> > Hmm... would be interesting to do lqmult in a way that it only works if
> > both sides of the link agree to the change. That would allow "link
> > management" without all this strange "zero-gain" games.
> What are those "zero-gain" games. Maybe we have not yet encountered
> those problems so this is why we do not yet know why is
> LinkQualityMult problematic.
Some people use lqmult to control what internet gateway they are using. That's 
a bad sollution for a problem that MUST be solved.

If you start to try optimizing routes to certain nodes with lqmult, it get 
really messy if multiple people start doing this.
> > The problem is that decissions about a node should be done on a global
> > level.
> OK, maybe then we are talking about two different things. I agree that
> some things should be configurable on a global level, but some
> decisions should be possible also on a node level because if a network
> is not administered by one body some autonomy should be possible for
> nodes to decide how much they want to participate.
Maybe I should rephrase this.

If a node is bad then the NODE should be flagged as bad, either by the node 
itself or by a collective decission of all neighbors. Just setting lq_mult to 
0.5 on a single neighbor does not solve the problem of a bad node.

> Maybe we could add a global switch for nodes to accept set
> "willingness" (I have described in my other e-mail) of nodes. And so
> if on a global level nodes agree to that then
> users/owners/administrator of nodes can set it per node (and per
> interface if a node have multiple interfaces).
> > If a node behaves bad or just cannot handle traffic more than a certain
> > amount, it should be able to tell this the network. Similar to the
> > (currently unused) willingness parameter of OLSR where you can say how
> > good your node would be as an MPR.
> Maybe we could extend current willingness parameter also to
> data/routing? If it is not currently used. As I have described in my
> other e-mail. (But it should be possible to configure it also
> per-interface.)
The OLSR willingness is just a value between 0 (forward never) and 7 (forward 
always). But it would be interesting to see the effect to include this 
parameter into the routing metric.

I also hope we will get a sane MPR sollution back later. At the moment it 
doesn't really work.

-------------- 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/a907f98d/attachment.sig>

More information about the Olsr-dev mailing list