[mesh-dev] Notes on babel and bmx6

[max b]

I've been having similar thoughts about this. I agree that bmx6 has seemed
awkward and cumbersome. Especially the bit about creating all of the
differently and seemingly arbitrary named interfaces. Also the IPv6 subnet
issue which I never was able to really sort out and which we never got a
good answer back from Nuemann about.

I've been tinkering with babel and I've actually branched several of our
repos into babel offshoots: makenode, sudowrt-firmware, exitnode. They
should all have some sort of maxb/babel or maxb/barrier-babel branch which
has been my starting point for work on babel. It's certainly not finished
and I don't even know that they all work together yet, but in case someone
wants to take a look through it, it's been my thinking so far.

I also built a firmware image, but for some reason it only built squashfs
and not jffs2. I can upload it to Deeko's hosting when I find my FTP keys
for his server.

On Sun, Jan 11, 2015 at 3:52 PM, Marc Juul <juul at labitat.dk> wrote:

> 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
>
> _______________________________________________
> mesh-dev mailing list
> mesh-dev at lists.sudoroom.org
> https://lists.sudoroom.org/listinfo/mesh-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sudoroom.org/lists/private/mesh-dev/attachments/20150111/a91426ef/attachment.html>