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

[Markus Kittenberger]

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

> It's a matter of mapping. We could map the raw transmission speed to a
> value
> between 0 and 1 and THEN combine it with the LQ from the ETX algorithm with
> a
> weighted sum.

combine with + or with * ??

>
>
> Or we only use bandwith as a tie-breaker if the ETX value is smaller than
> 1.1
> (or something like this).

way better i think, but of course this shoud be smoothed
somthing like this
(((ETX-1)*10)^x)/bandwidth
x>2
but i still want something else, which reflects layer 2 retries as well (see
below)

>
>
> > See above, why this isn't enough.
> Markus Kittenberg told me about a 10 gbit/s fibre link in Vienna with 20%
> packet loss because of the bad fibre... I was a little bit shocked, but I
> understand the problem now.

in fact we have no 10gbit at the moment in vienna* it was jsut a samnple

but we had packetloss on fibre links, and strange packetloss due to
incompatible switches/gbit interfaces, an packetloss due to bad
media-converters, and i have my own stories about packetloss due to bad
copper wires
my point is only you can not trust ethernet,
and if ethernet has the speed to get really low costs (an we want it to have
low costs!!!) we have to make sure there is no packetloss, and if we detect
one, raise the cost to values similar too bad wireless links
cause we have no layer 2 error correction on ethernet,..
in fact a link with ETX of 20 has same amount of unicast packetloss than a
ethernet link with ETX of 1.1
or to repeat it once again, i insist (*g) on layer 2 retry count to be used
in the metric!!
(as usually we route 99,x% unicast traffic)
formula is simple
uncicast_lq = 1-(1-broadcast_lq)^retry_count
#1

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)

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,..
btw. 5ghz ptp bridges should usually also get retry_value of 1, as they
usually have layer 2 corrections also on broadcasts!!

>
> > > If the link metric cost will have a higher range than ETX we might be
> > > forced to drop fisheye and develop some cost-change based link interval
> > > system.
> >
> > ACK. fisheye is one of those nasty things, that don't make all this
> easier.
> Markus had the idea to use something like fisheye in the forwarding
> function.
> If the LQ change is not higher than some function depending on the TTL, you
> don't forward the packet.

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

maybe a translation function between link_cost and "ttl_cost" is needed of
course
this aproach may be somewhat compatible to existing fisheys, as packet with
ttl 8 or 16 would still be somewhat meaningful, while ttl 255 would still
travel more than 128 hops,..
but still interoperability would be very limited, and is not very desireable
to mix this interpretations of ttl,.. *g
Markus
#1based onthis ETTlike metric than could be
cost=(1/(unicast_nlq*unicast_lq))/(netto_bandwidth+neightbour_netto_bandwidth)
netto_bandwith is either reporting by the hardware or calculated by
netto_bandwith=brutto_bandwidth*lq
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20090210/690ff231/attachment.html>