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

[Harald Geyer]

Henning Rogge <(spam-protected)> 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.

I know. So you would need to use information from the full routing
table, to drop some nodes from the MPR set only if the information is
available. Do you see there anything fundamentally wrong with such an
aproach?

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

I agree that this would be a bad idea ...

> > 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 wil=
> l =
> 
> be never used for traffic.

I'm not sure if/where we disagree: My point was: If you want to drop
neighbors on long links from the MPR set (i.e. because there is a
better multi hop route to them) then you (in a typical situation) need
to drop them from the neighbor set as well.

Do you see anything wrong with this statement?

Did I miss your point?

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

That's what Markus Kittenberger and me are working on right now.
Actually we don't use tunnels but link layer bridging, which
seems to be sufficiently performant.

There are at least three devices in the funkfeuer net testing our
setup since about 4 weeks, but there are still some issues (unrelated
to olsr) which prevent us from suggesting wider deployment. See the
(german) wiki page for more info if you are interested:
http://wiki.funkfeuer.at/index.php/Arbeitsgruppe_Software_AdhocBridge

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

Yes, in the long term I'd prefer to have such a feature in the olsrd
too. The above bridge setup was meant as a proof of concept to
convince other people that we need this in olsrd ...

Harald