[Olsr-dev] Some reflections on link state routing and metrics

[Markus Kittenberger]

On Tue, Feb 10, 2009 at 3:17 PM, Henning Rogge <(spam-protected)> wrote:

> > > between 0 and 1 and THEN combine it with the LQ from the ETX algorithm
> > > with a
> > > weighted sum.
> >
> > combine with + or with * ??
> for example like this:
>
> LQ = ETX-LQ * a + Bandwith-LQ *  (1-a)

ok sry, i should have read, you already said you want a weighted sum above
*g

> > somthing like this
> > (((ETX-1)*10)^x)/bandwidth
> > x>2
> Seems to be a little bit complicated for integer arithmetics.

i assume you can do quite similar smoothing with integer arithmethics
imho first we have to find what may be good, than how to implement it good

>
> ic)
> > formula is simple
> > uncicast_lq = 1-(1-broadcast_lq)^retry_count
> > #1
> not good... ETX metric works because it does NOT try to calculate unicast
> loss. This way we get bad LQs before unicast starts to degrade.


but ignoring unicast loss completely brings us to much more unwanted
behaviour

and (btw. broadcast) loss degrades the netto bandwidth i used below for my
complete cost function,..

>
>
> But I think we have lot's of time to experiment on linklayer aware metrics.

ACK, this was just one option to put this in,..

>
>
> > if local and neighbour values are both better multiplicated or averaged,
> > i`m unsure at the moment,..
> > if we have a default retry_count of 1 on all interfaces not detectable as
> > wireless, everything is fine
> > on wireless i would prefer getting the real retry count from driver, as i
> > know differtent values on different hardware/plattforms for this (i know
> > vlaues of 4 and 7)
> This would be included in the "bandwith" value we can get from the rate
> control algorithm. Because it includes retransmissions.

but this includes it only linear,

but unicast loss behaves for sure not linear to broadcast_loss or
netto_bandwidth!!
of course having the number of failed retransmission would be the best, and
i think this values is available from maclayer,..
this would imho be the only perfect solution, ...

>
>
> Modern drivers do NOT repeat a packet x times with the same speed, so we
> cannot just take the retry count.


yes we can! *g
as this is only an assumption
it`s also a bad-assumption to use the bradcast-rate loss as input for
calculation unicast_loss of other wireless rates,..
the point is i prefer doing some bad assumptions on it, instead of ignoring
it
if the driver will just perform better than our expectations, this is ok for
me,..
i just dislike it the other way round,..

>
>
> > if impossible to detect we should better use a lower one, and not 7
> > and if we offer a value in the config file to override this retry_count,
> > this should be flexible enough,..
> No, that's a BAD idea... either we detect it from the maclayer or we don't
> use
> it. Making values like this (which can change from kernel to kernel !)
> configurable sounds like a desaster waiting to happen.


there will always be interfaces where you will not be able to detect it,..
because they are inside a different piece of hardware for example (our
beloved/hated 5ghz bridges for example)
the question is what is the bigger disaster:
ignoring it, or making it possible to configure it wrong,..
but one way out of this dilemma is just to detect unicast loss with test
packets, at least when we can`t detect it from maclayer


> > and depending on the lnik cost of the links the packet came from (and go
> > to) a minor update coming from a high cost link, or go over high cos
> tlink,
> > is droppable, while it is not while there are low costs neighbours to
> > inform about
> Hmm... I think we have to draw some graphs on a paper to see if this idea
> really works.


hmm, on an offline or an online piece of paper?

>
>
> > one implementation option would be to interprete ttl (below 128) as
> > costtolive, and every node degrades it by the cost of the link it came
> over
> > it, or a minimum value of 1
> ??
>
*g

maybe we should make at least voip conf on this thread soon,.. *g
(maybe including an online piece of paper)
Markus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20090210/ade16f10/attachment.html>