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

L. Aaron Kaplan (spam-protected)
Mon Feb 9 13:12:57 CET 2009


On Feb 9, 2009, at 12:40 PM, Henning Rogge wrote:

>>
>> Some additional remark: This is much worse for funkfeuer like  
>> networks
>> (with centralistic uplink organisation) than for freifunk like  
>> networks
>> (with O(n) uplink gateways) because funkfeuer tends to have long  
>> routes,
>> where it is much more likely to hit a loop. I guess that also  
>> explains
>> why so many olsrd bugs have been found in Vienna.
> Sorry, you got it exactly the wrong way. Vienna with it's 5 Ghz  
> backbone to
> the central uplink(s) have a short average hopcount compared to  
> networks like
> Berlin od Leipzig.


Jup.
/me is digging out data now to prove that.
Sooo... Ok, current analysis shows that most paths have a  pathlenght  
of 6 hops in Leipzig. Quite a few also have 12!
Vienna looks like this: most have 4 or 5 and there are very very few  
paths with length 6 or higher.  So there is a sharp drop between 5  
hops and 6 hops.
I do not want to publish this all *yet* since we are in preparation of  
writing a paper about it. But as Henning said correctly, the reason  
behind this is our 5GHz switched backbone.


But, I want to add that this is already very funkfeuer / freifunk  
specific discussion.
I just want to remark that we should  keep olsr.org's OLSRd much more  
usable and applicable to many networks (mobile, static, community wifi  
etc).
So, I believe it is an interesting discussion which was started with  
the range of possible metric values.
What about using metric values from different sources such as  
effective bandwidth etc but on a limited range? Like 1-16? Essentially  
that means coarser quantization. And will your arguments change in  
case we propagate only in case a) either something bad could happen  
and we need to sync tables quickly (I believe this was Hannes's  
proposal) or b) otherwise when the value changes a lot (similar to  
coarser quantization)?

a.






More information about the Olsr-dev mailing list