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

[Juliusz Chroboczek]

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

It's already implemented, actually:

  http://git.wifi.pps.univ-paris-diderot.fr/?p=babeld.git;a=blob;f=message.c;h=99c3008b7d8c2ca55b5fb0987128769c7411ab73#l1443

It's not worth it in general, since sending IHUs over unicast prevents
aggregation.  Currently, 100 IHUs are sent in a single multicast packet;
if sent over unicast, they would require 100 distinct packets.

We're currently very conservative, we only send a unicast IHU if we
already know we're going to send a unicast packet to that particular
neighbour in the near future.  I'm sure a better heuristic can be devised.

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

Yes, but for small numbers of neighbours it's not clear that sending one
multicast is cheaper than sending n unicast packets.  It depends on the
link layer: on a broadcast Ethernet, a multicast is just as cheap as
a unicast; on a switched Ethernet, it depends on the topology, while on
WiFi or Tinc, multicasts are excessively expensive.

-- Juliusz