[Babel-users] babeld wishlist

[Juliusz Chroboczek]

Dear Dave,

Here, at Babel Towers, we are busy working on Babel, working on babeld,
lecturing undergrads, correcting exams, writing papers, and protesting
against the stupidity of the current state of emergency.  We have all but
given up on having a life outside of work.

You will therefore doubtless understand that we must be very selective in
our choice of things to do with Babel and babeld.  My policy, which has
served us well, is to concentrate on features requested by people who
actually are trying to solve a problem in deployment, and to ignore things
that would be cool to have but are not actual issues impeding deployment.

My current plans are, in order of urgency:

 - tweak things until Kosko (Jernej) and Mitar tell me they're running
   unpatched babeld in their mesh, then release the result as 1.7.0;
 - add a configuration interface that suits the Nexedi people, so they can
   abandon their local hacks;
 - integrate the babeld/hncpd pair into Debian so that one can do "apt-get
   install hncpd" and have a working Homenet router;
 - find a chair and prepare a Babel IETF meeting for Buenos Aires.

Please keep this in mind when reading my answers below.

> ** Working channel diversity selection based on the current linux wireless api

Yes, but that's some tedious work.  Patches gratefully accepted.

> ** Correct channel diversity for 802.11ac

No idea what needs to be done.

> ** Fast channel switching in light of a DFS changeover

That's not babeld's job -- babeld asks the kernel for link layer
parameters, but doesn't tweak the link layer itself.

> ** Channel selection integration support with hncpd

Interesting idea.  Probably an open research problem, though.

> ** full debian/ubuntu/fedora/arch support

L'intendance suivra.

> ** clean restarts and other reconfiguration

Yes, this will happen.  A lot of tedious work, unfortunately.

> *** openwrt procd support
> *** systemd support

Nothing needs to be done -- babeld is a single process that doesn't
daemonise by default, it works fine from inittab, runit, procd and other
sane init systems.

(There is no need for explicit notification, socket activation or other
gratuitious complexity, whatever the self-nominated Linux experts claim.)

> ** Version output in the monitoring interface

Yes, this will happen.  Matthieu mentions it whenever he gets a chance.

> ** similar to existing useful on olsr plugins or interfaces to babel's
> monitoring interfaces, whatever they are

Huh?

> ** more unicast instead of multicast
> lower the load on wifi

Easy to implement, but difficult to test.  Who'll do the testing?

> ** short haul metrics based on rtt and congestion
> I know, I know, I keep wanting to do this but it is stuck on per
> station queuing working at all in any wifi driver which is my big job
> next year

Baptiste implemented everything you asked for, Dave, we'll still waiting
for your testing results.

> ** Bird version finished
> *** IPv4?

Unfortunately, that's not possible until we get support for an IPv4 data
plane in bird6.  Please start a discussion on bird-devel, I'll chime in.

> ** Atomic route updates
> example patch for quagga: http://patchwork.quagga.net/patch/1435/

Who'll do the testing?

> ** ECN and rate control for larger networks

We've discussed this before -- ECN is the wrong thing to use here.  We'll
hopefully get some data from our Slovene friends that will show whether we
need better rate control.

> ** Covering/collapsing routes and interdomain routing

Automatic aggregation is tricky -- as far as I know, nobody's ever managed
to pull it off.  You want to speak with Sobrinho.

> ** what can be learned from BGP?

I'm reasonably familiar with BGP, Dave, and Babel already integrates
a number of good ideas from BGP.

> ** Faster dead link detection with switches that support it

A lot of work, and a lot of testing.  Who'll do the testing?

> ** Koruza support

Koruza is a purely physical layer device -- it appears as a plain
Ethernet, and uses a standard Ethernet transceiver.  Nothing needs to be
done -- and nothing can be done.

> ** many radio types (802.11ad, lte, bluetooth, 802.14 etc) supported
> sanely at the same time (6 radios, say...), gradual route optimization
> over such

Who'll do the testing?

> ** Homeplug vs ethernet routing selections

Homeplug appears as an Ethernet to the upper layers, you need to send
proprietary 802.2 frames to find out that there is one.  You probably want
to speak with Barbara Stark.

> ** Rebuild quagga patches for babel based on GPL sources (from bird?)

No way.  I'm not going to try to work with the Quagga crooks again.  Let's
give up on Quagga, as much of the routing community appears to have done.

> ** source specific routing tested at more scale with things like tinc

Who'll do the testing?

> ** ns2/ns3 support

Yes, we need that.  That would be a good fourth year project if I find
two students that are good enough.

> ** rfc7298 support in everything

Yes.

> ** Testing over WPA encrypted and other sorts of semi p2p networks
> like, for example the 24ghz airmax products

Who'll do the testing?

> ** Better dhcp/babel integration for hosts that wish to participate

Doesn't that happen automatically when using hncpd or hnetd?

> ** better mobility for hosts running a stubby babel

Yeah, sbabeld needs some love.

> ** Babel fuzzer and more testing of misaligned data

Yes.

> ** A pony

A ratel, an aardvark, even a mule would do, but certainly not a pony.

-- Juliusz