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

[Hannes Gredler]

On Tue, Aug 19, 2008 at 08:36:35AM +0200, Henning Rogge wrote:
| 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.

jumping late into the thread:
i may be completely mistaken, but isn't generating 'consistent' routing
tables the job of a routing-protocol ? - what is the root-cause problem
that you are trying to solve here ?

/hannes