<div>the problem is that links that are regarded as too bad, are currently not used anywhere in the mesh,..<br></div><div><br></div><div>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</div>
<div><br></div><div>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</div><div>
<br></div><div>(@ henning:)</div><div>but hmm arent the 2 nodes (forming the link) responsible if they announce the link or not?</div><div>if so it is a local decision, which would make things easier,.. if this decision gets somewhat more configureable and/or complex.</div>
<div><br></div><div>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)</div><div><br></div><div><div>@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</div>
</div><br><div class="gmail_quote">On Sat, Apr 24, 2010 at 12:53 PM, Mitar <span dir="ltr"><<a href="mailto:mmitar@gmail.com">mmitar@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi!<br>
<br>
I got an idea for small improvement in OLSR which I think could<br>
improve its behavior in practical scenarios. The idea is to leave last<br>
route node had to last peering node in place and do not remove it. So<br>
if the node has many peers then there is no difference - OLSR is<br>
choosing the best route. But once node has only one peering node and<br>
it decides to remove route to it then I would recommend that we leave<br>
it in place as it has the highest probability that this same route<br>
will be restored (especially when nodes have fixed locations). And<br>
maybe even some packets will get through (not so useful for TCP but<br>
for UDP this is quite useful, like for streaming or telephony). Of<br>
course whole mesh should also leave last known path in place so that<br>
traffic can be routed back. Maybe it will be routed in wain, but maybe<br>
something will come over.<br>
<br>
If some other peering node gets route then at that time routes are<br>
rewritten for that peering node.<br>
<br>
With this we do not lose anything in the sense of optimal routing but<br>
we get a little bit more of robustness.<br>
<br>
(Of course this same laziness technique could be used also for other<br>
routing protocols.)<br>
<br>
<br>
Mitar<br>
<font color="#888888"><br>
--<br>
Olsr-dev mailing list<br>
<a href="mailto:Olsr-dev@lists.olsr.org">Olsr-dev@lists.olsr.org</a><br>
<a href="http://lists.olsr.org/mailman/listinfo/olsr-dev" target="_blank">http://lists.olsr.org/mailman/listinfo/olsr-dev</a><br>
<br>
</font></blockquote></div><br>