[Battlemesh] Proposal for battlemesh v10 "testbed"

Linus L├╝ssing linus.luessing at c0d3.blue
Thu Dec 15 06:10:43 CET 2016

On Thu, Dec 15, 2016 at 12:42:09AM +0100, Juliusz Chroboczek wrote:
> > Simon mentioned that he wasn't really personally interested in
> > "battling" protocols so much (as in the first few battlemeshes),
> This would be the kiss of death for Battlemesh.
> Battlemesh is about experimentally comparing the performance of routing
> protocols.  If Battlemesh doesn't compare routing protocols, it becomes
> yet another community meet-up.  The technical people will no longer come,
> the community people, who come to battlemesh because it's a chance to meet
> the technical crowd, will go to places that are more interesting, and
> Battlemesh will wither away.
> (Since recent Battlemeshes have repeatedly shown Batman-"Advanced" to lag
> behind the other protocols, I cannot help but suspect that Simon might be
> biased against performing experimental work.)

Let me put some fuel into the fire - it's a little cold these days
in the northern hemisphere ;).

To me it looks like it's actually any layer 3 routing protocol
"lagging behind": Within all these years, to my knowledge no roaming,
capabilities for external devices were added to any of these. Sure, we
can juggle with fancy numbers, but what use are they if the protocol
is not usable in the real world?

(which of course is a mean exageration from me, but let me just
suggest the assumption here, that an open, public community mesh
network - which is just one! use-case for a routing protocol, of course -
might need not only routing protocols coping with mobile nodes,
but moreover mobile users. At least I haven't observed any
buildings swapping places so far.)

I would love to see how a bunch of ordinary smartphones roaming from
one node to another would compare between BABEL and batman-adv!
Antonio has implemented an incredible, reactive protocol within
batman-adv for the so called "Translation Table" and I would
claim that maybe it might be faster, with less overhead and more
seemless than any reactivity in BABEL.

Unfortunately, so far, even after years we still cannot compare them,
as BABEL still does not support ordinary wifi devices roaming from
one node to another.

And regarding the "so far"...

> > there are already out there mesh firmwares implementing each routing
> > protocol, being maintained every day, and so up to date with kernel,
> > openwrt, and routing protocol versions, etc
> > why not use those firmwares?
> Because comparing firmwares is not going to be interesting for the
> technical folks -- if one firmware performs better than another, is it the
> routing protocol?  The kernel version?  The AQM?  A configuration bug?

... just to share with you guys, even though I'm not sure whether the
people working on it would like that yet, there's been quite some
work on allowing layer 3 routing protocols in Gluon - including
roaming! I had the pleasure to admire probably one of the first
ordinary, mobile devices roaming on a BABEL mesh. Nils Schneider has
done some incredible work for the "l3roamd" [1][2]. And Christof
Schulz is currently feverishly working on its integration in

So not sure if for this Battlemesh, but maybe the one after that
Gluon might be able to provide a stable firmware, tested by
many, many nodes and communities. While still allowing to compare
different routing protocols running on it, with the same kernel,
queuing, rate control etc. for all of them.

Regards, Linus

[1]: https://www.nilsschneider.net/2016/04/10/babel-in-gluon.html
[2]: https://github.com/tcatm/l3roamd

More information about the Battlemesh mailing list