[Babel-users] About split horizon in Babel, and scaling the number of neighbours

[Baptiste Jonglez]

On Thu, Jun 26, 2014 at 01:18:01PM +0200, Juliusz Chroboczek wrote:
> Ah, I see.  You're performing routing both in the VPN (tinc) and in Babel,
> and the two routing algorithms are interacting in unpleasant ways.
> Ideally, you wouldn't do that -- you'd use the VPN for point-to-point
> links only, and let Babel take care of the routing.

Actually, there is a way to tell Tinc *not* to route anything, thus using
it only for building connections between routers.  This is why we may get
a non-transitive Ethernet segment, exactly like 802.11 in ad-hoc mode.

But Babel speakers may still see a high number of neighbours.  In
addition, multicast is emulated using unicast, which amplifies the control
traffic.  I'm still experimenting with this, it might be a good idea to
limit the number of VPN connections.

Actually, this is kind of funny: the better Tinc will be at building
connections, the more trouble Babel will have handling so many neighbours.

> If for some reason you insist on routing inside tinc and want Babel to
> take care of the resulting mess, you could modify Babel to send multiple
> unicasts instead of a single multicast (for updates only -- hellos still
> need to be multicast).  I'd be willing to accept a patch that does that
> (configured by setting the maximum number of unicasts before we switch to
> multicast) assuming it's clean enough and avoids code duplication.

I thought about doing that for IHUs, since they're conceptually unicast,
but actually sent as multicast: this is inefficient when multicast is
emulated.  But the optimisation is probably not worth it for a realistic
number of neighbours.

Regarding updates, I don't quite understand.  Don't we want to send them
to *all* neighbours anyway?

> Perhaps related, Ray Hunter said the following on the Homenet list:
> 
>   Multicast has issues on some link topologies (e.g. where it has to be
>   emulated), and in situations where devices attempt to sleep for as long
>   as possible. So even though link-local multicast may be part of the IPv6
>   base spec, it may be desirable to avoid use of multicast traffic where
>   possible. e.g. a routing protocol could perform initial neighbor
>   discovery using multicast, but then switch to unicast when maintaining
>   individual neighbor associations on the longer term, or for exchanging
>   information with specific neighbors.

Interesting.  It might also be useful for 802.11, where multicast packets
use the lowest bitrate possible, which occupies the link for a longer
time.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/babel-users/attachments/20140626/76cbbe2b/attachment.sig>