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

[Markus Kittenberger]

>
>
>
> Of course there are metrics trying to optimize very different aspects
> of connection qualitiy, but for the purpose of the e-mail I'll
> assume that any good metric will need a big range of values to provide
> a proper model for a divers real world mesh like freifunk/funkfeuer.
>
> So the question above boils down to "Will OLSR work with wide-range
> metrics?"
>
> Of course there is the fundamental criticism of most wide-range metrics,
> that they can't properly handle links with unicast package loss (i.e.
> they prefer lossy links just because they have some other good
> property - which of course is a bad thing to do in general). But I won't
> discuss this today, as this has nothing to do with OLSR.

ACK!
see below as it might be a good solution

>
>
> BTW: Does anybody know results about a metric that solely concentrates on
> unicast package loss? It's that obvious that it sure has been studied
> extensively, but I don't know anything about that myself. So if you have
> any references, please share them with me!

i have no references (but i`m also strongly interested in)
but i have already some own ideas on this, a ETT like metric which in fact
calculates theoretical TCP bandwidth, based on packet loss (based on
wireless retry count), and also latency. (optional)
Calculation of costs is based on a theoretical tcp implementation and
assumption (window-size, latency to target)
effect is that links with > 60% packet loss get incredible high costs, as
they suffer some unicast packet loss, which causes extremely slow or
nonexisting tcp bandwidth,.. while between 0 and about 30% packet loss
things are nearly linear, (only rising latency (due to required retransmits)
has some additional effects on tcp bandwidth)
and on an ethernet like medium this metric will also work very reasonable if
you just set/configure retransmits to 1
Markus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20090209/434c96fc/attachment.html>