[mesh-dev] Notes on babel and bmx6

Marc Juul juul at labitat.dk
Sun Jan 11 15:52:06 PST 2015


After playing with bmx6 for a while I thought I'd look more into babel.
I've been trying to figure out what we'd need in order to use babel for the
firmware. Here are my thoughts:

Each node has an IPv4 subnet and an IPv6 subnet.

The IPv4 subnet is assigned using makenode.

The IPv6 subnet is assigned using makenode, randomly using

  generate-ipv6-address from
http://www.pps.univ-paris-diderot.fr/~jch/software/files/

The IPs and subnets are statically configured in openwrt config for each
node just like they are in the old sudomesh firmware, and each node assigns
IPv4 and IPv6 addresses to clients using dhcp. All nodes have their own
subnets and run dhcp servers (as opposed to the old firmware where only
internet-connected nodes ran dhcp).

If tunneldigger succeeds in establishing a tunnel, the node becomes an
internet gateway and announces its route to the internet using:

  babeld -C 'redistribute if eth0 metric 128' mesh0

To begin with we can base the metric on something like the average of the
upload and download bandwidth limit on the node maybe? I'm not exactly sure
how this metric stuff works for these manual route announcements. I assume
the specified metric is the base metric and then normal babel metric
calculations happen on top of that?

In the longer term we could create a babel extension that attaches
information to route announcements about delay to the vpn server and
currently available internet/tunnel bandwidth (averaged since last router
announce). We can see how the babel diversity routing extension is
implemented and base it on that:

  https://tools.ietf.org/html/draft-chroboczek-babel-diversity-routing-00

I'm not sure how we'll measure available bandwidth on a live connection
without saturating it? Maybe we can instead measure whether the bandwidth
is currently saturated by looking at how many packets are getting
queued/dropped? We can also do something even simpler and look at current
bandwidth usage vs. the user-selected bandwidth limit. If we do this then
for nodes with no bandwidth limit, we'd have to measure the available
bandwidth e.g. the first time the node finds an internet connection. We
could just skip this feature in the first firmware version and require a
user-selected bandwidth limit, but then we run the risk of the user
selecting a limit that's higher than their available connection speed.

In the future we can also replace tunneldigger with something using
foo-over-udp, but I think tunneldiggger with the "only try to connect when
a ping succeeds"-addition is good enough for now.

I must say that the more I look at it the more I'm liking babel. It seems
to me that bmx6 has several oddities:

* Can't do IPv4 and IPv6 at the same time.
* Can't have several nodes announcing the same route (e.g. to internet)
* Instead uses tunnel announcements for internet gateway selection, even
though this adds the extra overhead of having a tunnel from each
non-internet-connected node to a internet-connected node for no apparent
reason. The overhead might no be bad but the plurality of tunnel interfaces
makes debugging kinda confusing and it just seems... dirty.
* The weirdness with different nodes ending up on different IPv6 subnet.

Are there any advantages to using bmx6? The only one I can think of right
now is that it already has some internet bandwidth metric stuff
implemented, but on the other hand babel has its diversity routing metric
which is probably going to be important for us in the future if we don't
want to loose a lot of bandwidth on multi-hop routes.

Does babel have any problems I haven't considered?

Thoughts? Comments? Anything I overlooked?

-- 
marc/juul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sudoroom.org/lists/private/mesh-dev/attachments/20150111/db7b42b0/attachment.html>


More information about the mesh-dev mailing list