[Olsr-dev] LinkQualityMult problems in 0.5.6-r5

Henning Rogge (spam-protected)
Sat Sep 5 13:03:16 CEST 2009


Am Samstag 05 September 2009 12:53:59 schrieb Mitar:
> Hi!
> 
> On Sat, Sep 5, 2009 at 12:42 PM, Henning Rogge<(spam-protected)> wrote:
> > What we need is a better routing metric that detects that some links are
> > better or worse than others. If we can make OLSR detecting speed,
> > lossrate and similar stuff and put it into the metric there is no need
> > for large scale lqmult-horror.
> 
> But there are so many metrics which could be used. Like link cost. Or
> CPU, memory, bandwidth load on some node which would you would like to
> keep low. Or you would like that some period of a day one routes are
> preferred and during some other period some other routes are
> preferred.
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.

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.
 
> > The option to say "emergency link, don't use unless necessary" might be
> > still useful of course.
> 
> Please do not do it 0 or 1 (use or not only if there are no other
> routes) or at least possible to define when you think it is necessary.
The problem is that decissions about a node should be done on a global level.

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.

Henning
-------------- 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/3f7fe9d2/attachment.sig>


More information about the Olsr-dev mailing list