[Babel-users] Bucket full, dropping packet

[Juliusz Chroboczek]

>> Oh, sadly not 75 max. The number of neighbours of one node is
>> potentially very large, because all nodes with Internet uplink
>> connects to the VPN server. So, all those nodes are then neighbours of
>> that VPN server node. Currently this is for example 140 nodes on one

> So yes, 75 is the current number of Babel peers, but there are otherwise
> many more peers and there will be even more. How does babeld scale in
> this case (BTW, is this a problem with the protocol or the implementation)?

The implementation.  The protocol should be able to scale very well.

Look at the code at xroute.c line 304 -- this is quadratic in the number
of the routes in the kernel, and is done every time the kernel tells us
the set of routes has changed.  This is easily fixed (the kernel provides
us with deltas, we don't need to take a complete dump every time), but
I need some profiling data before I spend time on that.

Another issue is that a Babel node keeps a redundant routing table -- it
keeps routes that are not installed so it can recover from a failure
immediately.  The current implementation doesn't limit the amount of
redundancy -- it will keep up to (v*n) routes.  The obvious solution is to
be just 3-redundant -- keep just the best 3 routes to a given destination.
Obviously, this means that route selection will be suboptimal in some
cases, and that recovery from loss will be slower, but something's got to
give.

Mitar, Jernej -- this is exciting stuff, and I'm pretty sure we'll be able
to solve it.

> But I am thinking that we do need some faster way to debug these
> issues that this ping-pong over the mailing list, with what should we
> run and then file back and so on. What about you getting one cheap
> TPLink, go to https://nodes.wlan-si.net/, register a node and deploy
> it?

Very good idea.  Is it possible to use a Debian box?  With all the
profiling and debugging tools, it would be more useful.

-- Juliusz