[Olsr-dev] Comments regarding the talk of Thomas Clausen at metalab

[Henning Rogge]

Am Dienstag 19 August 2008 03:30:10 schrieb Harald Geyer:
> > Of course the MPR selection must still be "large enough" to be RFC
> > sufficient. I discussed the idea with Thomas Clausen in Vienna and
> > he said he doesn't see a reason why it should not be RFC compatible.
>
> That's part of what I wanted to point out in my initial mail, when
> I was talking about channel diversity and especially when I was talking
> about (weak) long range links:
>
> Direkt neighbors on long range links tend to introduce new 2-hop
> neighbors that can't be reached by any other MPR (in two hops).
The problem is that it's impossible to know at this point of the protocoll if 
we can reach the "weak neighbor" with another link.

Of course you could drop links below a certain treshhold (we do this below a 
LQ or NLQ below 0.1 at the moment), but this might drop the only link keeping 
a network together.

> Now the whole point of the link quality system is IMO to use several
> short links instead of a long one in cases where this will improve
> performance.
MPRs are responsible to retransmit flodded routing messages, bad links over 
MPRs will be not used for routing if the Dijkstra will find a better 
connection.

> So if you want to use link quality for MPR selection you 
> will want to drop the neighbor on the long range link from the MPR set.
> But if you do this the RFC requires you to drop this neighbor from the
> neighbor set as well to get rid of the now "unreachable" 2-hop
> neighbors.
This "weak" neighbor is just a theoretical option that will make the TCs a 
little bit larger. If there is a better 3-hop route the weak 2-hop link will 
be never used for traffic.

> > My idea was just to have to "dump" nodes that give the "master" olsr to
> > communicate over interfaces not connected to his own machine. Maybe just
> > a tunnel protocoll or something like this.
>
> Yes, having a dedicated master that calculates the routing tables for
> all devices (or calculates some general routing table that is refined
> by the slave olsrd) will make things a lot easier, but one
> issue remains: You need some very robust mechanism to keep the
> kernel routing tables on all devices synchronized. If for some reason
> the routing tables get out of syncronization for more then a few
> miliseconds then a node internal routing loop might happen - easily
> producing that much traffic that further routing table update messages
> might get delayed or lost - thus adding to the synchronization
> problem.
There would be two ways to do this.

The easiest way would be to do the routing completely on one device and use 
dump "tunnels" to connect the WLAN interfaces of the "secondary" routers to 
the "main router". But this would require routing the traffic through 
userspace, which is very bad for performance.

The second way would be to keep "konsistent" routing tables on all devices, 
this would require some thoughts about synchronization, but I think this is 
the better option.

> Anyway I think it would be very interesting to try this in practice.
Me too.

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: Dr. rer. nat. Ralf Dornhaus (Vors.), Prof. Dr. Joachim Ender 
(Stellv.)