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

[Harald Geyer]

Hi!

Sorry for the late reply, but I've been busy with other projects the
last days. I think most important points about this topic were already
mentioned in the thread, but a few further remarks from my side:

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

I'm not sure if these things you are throwing in here are still metrics,
ie. if they still work to compute path costs from link costs.

> > 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 such a fibre/cable exists it shouldn't be used at all. My concern is not
with cable links but mostly with low cost wifi links. There are people
in Vienna that call for ETX=0.1 for 5 GHz links and ETX=0.01 for cable
links. And even 5 GHz links have some package loss.

I'm not saying that wide range metrics won't work, but I think you need
to pay some attention to protocol consideration. I happily notice that
from what I have read in this thread this already seems to be the case... ;)

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

Yeah, I know the setup in Vienna pretty well...
But I don't have data from freifunk networks so I really only can
speculate.

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

Nice.

Harald