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

[Henning Rogge]

Am Tuesday 10 February 2009 12:17:28 schrieb Harald Geyer:
> > > 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!
> >
> > ETT can be thought as a package loss metric, especially if you just
> > directly take the unicast bandwith from the mac-layer and put it
> > through a smoothing process.
> >
> > (see
> > http://linuxwireless.org/en/developers/Documentation/mac80211/RateControl
> >/m instrel
> > )
>
> Good point. But that's a rather indirekt relationship in this case.
The idea with 802.11 speed is that you only get good rates if the unicast 
retransmission will reach the target. If they don't the rate drops very fast.
(to prevent unicast loss !)

> > > Anyway OLSR works with ETX at least reasonably. Seems that now
> > > people are becoming discontent with ETX too, so how will the funkfeuer
> > > OLSR mesh behave with a metric that has link costs in some very big
> > > range?
> >
> > A metric change does not need necessarily mean a very big range.
>
> Hm, most new metrics that I've heard of seem to imply a range that is
> quite bigger than ETX. Do you have any particular counter example in
> mind?
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.

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

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

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

> Sorry, I have been (too) short: What I wanted to write was: "funkfeuer
> tends to have long *default* routes compared to freifunk". I don't have any
> actual data about freifunk networks but I would be very surprised if this
> was wrong. And loops in the default route is, what people usually
> notice ...
I'm still not sure you got it right. Vienna has a partly SWITCHED backbone of 
5 Ghz bridges, so you get very far in a few hops.

Markus and me discussed an iptables/ipqueue base loop detector/resolver 
yesterday, so we might have some ideas how to break loops if they happen. If 
this works we could reduce the (insane) high TC rate in the Freifunk/Funkfeuer 
networks. :)

Henning

*************************************************
Diplom Informatiker Henning Rogge
Forschungsgesellschaft für
Angewandte Naturwissenschaften e. V. (FGAN) 
Neuenahrer Str. 20, 53343 Wachtberg, Germany
Tel.: 0049 (0)228 9435-961
Fax: 0049 (0)228 9435-685
E-Mail: (spam-protected)
Web: www.fgan.de
************************************************
Sitz der Gesellschaft: Bonn
Registergericht: Amtsgericht Bonn VR 2530
Vorstand: Prof. Dr. rer. nat. Maurus Tacke (komm. Vors.), Prof. Dr.-Ing. 
Joachim Ender (Stellv.)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20090210/86bf29e7/attachment.sig>