[Olsr-dev] Idea for small OLSR improvement

[Markus Kittenberger]

the problem is that links that are regarded as too bad, are currently not
used anywhere in the mesh,..

changing this behaviour for the last reminaing link to a node only, might
get a bit complex, what happens if u have on very bad link and one dramatic
bad link

if only the very bad link it detected, it gets announced as its the last
one, but if the dramatic bad link gets a bit better, sall we announce it
too? or (worst case) don`t announce both? *g

(@ henning:)
but hmm arent the 2 nodes (forming the link) responsible if they announce
the link or not?
if so it is a local decision, which would make things easier,.. if this
decision gets somewhat more configureable and/or complex.

or will other nodes still simply ignore this link if lq values are below
their one minimum (if so, this would be anyway a problem (in meshes with old
olsrds)

@mitar: if not, imho just comile olsrd (for first test) with a lower
lq-mimum than 0.1, and use this olsrd on nodes having bad links u want to
keep whatever happens*G

On Sat, Apr 24, 2010 at 12:53 PM, Mitar <(spam-protected)> wrote:

> Hi!
>
> I got an idea for small improvement in OLSR which I think could
> improve its behavior in practical scenarios. The idea is to leave last
> route node had to last peering node in place and do not remove it. So
> if the node has many peers then there is no difference - OLSR is
> choosing the best route. But once node has only one peering node and
> it decides to remove route to it then I would recommend that we leave
> it in place as it has the highest probability that this same route
> will be restored (especially when nodes have fixed locations). And
> maybe even some packets will get through (not so useful for TCP but
> for UDP this is quite useful, like for streaming or telephony). Of
> course whole mesh should also leave last known path in place so that
> traffic can be routed back. Maybe it will be routed in wain, but maybe
> something will come over.
>
> If some other peering node gets route then at that time routes are
> rewritten for that peering node.
>
> With this we do not lose anything in the sense of optimal routing but
> we get a little bit more of robustness.
>
> (Of course this same laziness technique could be used also for other
> routing protocols.)
>
>
> Mitar
>
> --
> Olsr-dev mailing list
> (spam-protected)
> http://lists.olsr.org/mailman/listinfo/olsr-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20100424/dcd85d6e/attachment.html>