Babel on a wireless mesh

[Toke Høiland-Jørgensen]

Bernd Naumann <bernd at kr217.de> writes:

> Hey *,
>
> Because Babel popped up on the list, I want to use the opportunity to
> drop a few questions I had over the last days...
>
> On my small home-network I currently use OSPFv3 for IPv4 and IPv6 to
> announce routes from Laptops and PCs, and the Router. (There are some
> "dumb APs", too in the network but routing happens only on "the router"
> and like I mentioned, PCs and Laptops. Some wired, some wireless only,
> some both.)
> Given the fact that both protocols, OSPFv3 and Babel, are using
> multicast; would I "gain anything" switching to Babel? Right now I'm
> only using OSPFv3 because I'm familiar with...

Well, if OSPF is working to your satisfaction I'm not sure you'll "gain"
anything, really. Babel is certainly capable of doing what you describe,
I use it myself for similar stuff. The main "philosophical" difference
between OSPF and Babel is that Babel is a distance vector protocol,
while OSPF is a link-state protocol. Basically, this means that in OSPF
every node has a full view of the network and runs the same algorithm to
agree on the right path. Whereas in Babel, packets are routed "towards
the best path" and every node doesn't need to have the full same view of
the network (which allows nodes to do things like filter and aggregate
routes). I'm simplifying wildly here, and I'm sure Juliusz will jump in
and point out all the ways this simplification is wrong :)

In addition, there are a couple of neat features in Babel:

- The ability to route v4 and v6 traffic using a single instance of the
  protocol (all Babel routing packets are v6, but they carry information
  about v4 routes as well).

- The ability to route v4 packets over v6 nexthops, so nodes internally
  in the network don't need v4 addresses (not in Bird yet, though, see:
  https://bird.network.cz/pipermail/bird-users/2023-January/016502.html)

- Source-specific routing for IPv6

- An RTT extension that lets you pick the lowest-RTT path instead of the
  least-hop one (not in Bird yet either, but I have an implementation
  that I'm planning to submit soonish).

As for which will serve your needs best, well, on a "small home network"
you'll probably be fine with either one. I personally like the
simplicity of Babel (3.5k LoC vs 9k for OSPF), but I'm also hopelessly
biased since I wrote the Babel implementation ;)

> And what really puzzles me, and I don't find "useful" answers:
> If I run a multicast based routing protocol on jittery wireless links,
> do I need to "tune" multicast options for the wireless radio? And if so,
> what options; to what value; based on what? (Regarding the multicast
> radio options of the access points, I'm running OpenWrt.)

Tuning shouldn't generally be needed. In Babel you'd want to set the
wireless interfaces to the (surprise!) "wireless" interface type, which
makes the protocol employ a link quality estimation algorithm that's
more suitable to wireless links (which tend to degrade rather than just
turn off completely).

You're right that multicast traffic has different characteristics than
unicast in Wireless, but if you're "just" trying to pick which of two
links is better, their relative multicast performance are a decent
predictor of their relative unicast performance as well. So in practice
it works OK. One problem with using multicast, though, is that this has
more overhead than using unicast on wireless links. For this reason,
Babel has a mode that switches most of the traffic to being unicast;
however, that's not in Bird yet.

-Toke