[Olsr-dev] Thoughts about an ETX-FF-Metric plugin

[Henning Rogge]

> sorry i of course meant the hello interval not the timeout,.
> and if its transmitted, everything is fine,..
Every hello contains the time (relative) when you can expect the next one.

> this is no problem, i only stated that some advanced parameters (targetet to
> the exponential history part) in extend to the dynamical hello interval are
> needed, but they will only rarely/never need to be changed by the end user,
> if we found good default values,..
>
> so it can configure itself based on the hello interval,..
Exactly.

> at the moment i tend to an javascript attempt, reusing a framework i
> currently build for an javascript horst-alike tool, and an existing realtime
> lq chart i made some months ago, to get real link (sesing) data from the
> router where it came from,..
> so it can be "installed" on fff routers to show a grpah of current lq/etx
> implementation and some graphs resulting from other interpretations of
> sensing the same link,..
Javascript is okay too.

> hmm, changeable behaviour?
> but, its dirty anyway, because what if a reboot happens just before the
> sequence numbers reach their upper limit
Maybe we can teach olsrd to send a "I'm switching off" packet before
it shuts down. This way the neighborhood has a chance to see the route
loss coming.

>> > the problem is that when the algorithm finds out it was a reboot he has
>> > already filled parts of the history with the low lq values, he generated
>> > with every lq timeout
>>
>> yes, if the reboot happens fast enough this might be a problem.
>
> fast enough?
>
> you mean faster than the link timeout or what?
yes.

>> Not good... when the link times out the datastructure we are using to
>> store our information will be freed.
>
> it depends how long history is, whether i dislike this or not,..
>
> but imo its a good idea to completely stop routing over a link, much earlier
> than to drop any information about it,..
especially we don't need a second timer and a second database (we just
use an addition to the link database).

> yes, but i thin i want two timeouts, one to drop any routes over this link,
> and one to clear all information about this link
As long as the "clear information" timer is shorter than the "drop
route" timer this should be no problem.

> because a 30 second dead link, shouldn`t be used for routing, but if it
> comes up after 35 seconds, the link sensing should still have
> enough information to be at least as skeptic as if the link was down for 20
> seconds,..
Which would be a problem for reboots.

> unidriectinoal or not was not my point, but a dead link`s etx drops slower
> than an 95% loss link, because its nlq is freezed, and i dislike this,..
> maybe it would be a good idea to lower the nlq with every hello timeout
> (only if no olsr packets from this node are received)
> the problem with this feature is, it just breaks anything, and creates loops
> for sure..
> (i will have to investigate a bit before writing any further on this point
> (-;)
At the moment we don't use any link for routing which LQ or NLQ
(neighbor linkquality) is below 0.1.

>> We will have to be careful with this...
> with what?
Careful with pushing out very different ETX values ;)

>> Difficult to use together with old routers.
>
> why?
> the resulting etx, will be stable, but lower,..
> but it`s true routes will more likely go over old routers which tend to
> generate too good values, ..
> so it`s of course a good idea to update old routers,..
LOL... :)

Henning

-- 
"Wo kämen wir hin, wenn alle sagten, wo kämem wir hin, und niemand
ginge, um einmal zu schauen, wohin man käme, wenn man ginge." (Kurt
Marti)