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

[Markus Kittenberger]

On 6/19/08, Henning Rogge <(spam-protected)> wrote:
>
> On Thu, Jun 19, 2008 at 17:09, Markus Kittenberger
> <(spam-protected)> wrote:
> >> Do you think we could use this two arguments to get reasonable values
> for
> >> your
> >> model ?
> >
> > this two parameters are very important for the size/layout of the first
> > linear window,.. and the first averaging function,..
> >
> > one question, how do you now the hello timeout of your neighbours, do
> they
> > put them into their hello messages?


sorry i of course meant the hello interval not the timeout,.
and if its transmitted, everything is fine,..

> the exponentially part of the window, has it`s own tuning paramters, which
> > once we found good values should be quite ok for most networks
> > maybe one total history length/duration parameter makes sense (in
> seconds)
> > (may be useful for example if you know you`ve got some (too long shots)
> of
> > 5ghz bridges which tend to repeatedly-completely fall out in bad weather
> > situations)
> > (the old window size could be even used as input for this
> > (total_history_duration=hello_interval*window_size)
>
> I would like an algorithm which automatically choose it's parameters
> by using the hello timeout.


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,..

Java would be great (I have done more coding in Java than in c ;) )


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,..

> if this difference (from a reboot) is detectable depends on whether the
> > olsrd starts with sequence number 0 or with a random number,..
>
> olsrd starts with a random number I think.


hmm, changeable behaviour?
but, its dirty anyway, because what if a reboot happens just before the
sequence numbers reach their upper limit

> 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?

> of course it may make sense to keep history longer then the link timeout,
> > depending non how short the link timeout is
>
> 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,..

> a link timeout (at which definitely no route will use this neighbour)
> makes
> > much sense with this history algorithm,..
> > than for example while after 12 seconds the lq has dropped to 50% of his
> > "original" value
> > it still has LQ of about 37,5% after 30 seconds
> > after 66 seconds 25%
> > and after 138 seconds it`s still 12,5%
>
> We already have a timeout algorithm, so that should be no rpoblem ;)


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

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,..

Unidirectional links will not really matter because a link is only
> announced if both the neighbor and the node itself generate a "good"
> LQ value (exchanged by Hellos).


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
(-;)

>
> > a method to improve this algorithm on lowering the lq deeper on
> desastrous
> > situations (this includes but is not limited to dead links) would be to
> use
> > the very old part (last quarter (= last 3-4 time slots)) of the history
> only
> > when their values are lower than the newer parts:
> > that means oLQ would be split into an old and a new part, comparing them
> > before deciding whether to use the old parts,..
>
> We will have to be careful with this...


with what?

if most nodes of the network
> just pump out bad ETX values, it will not really matter for routing


ack

(only the relative differences will matter).


this shouldn´t happen, no large jumps should occur,..
and it should be reliable in combination with old olsrs, because it
does sequence number counting, and has no hard hello timeouts,..

> the conclusion, is an completely pessimistic link sensing, which will only
> > generate compareable (to <= 0.5.5) lq result on perfect and/or stable
> links.
> > but this behaviour was the target, and if its too pessimistic, there are
> some
> > parameters, which (when misused) can even make it optimistic,..
>
> 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,..

Markus

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20080619/d8697e2d/attachment.html>