[Babel-users] reducing delays in wifi mcast queues

[Dave Taht]

welcome back!

On Tue, Sep 18, 2018 at 4:19 PM Juliusz Chroboczek <jch at irif.fr> wrote:
>
> > (I ran across this babelweb pic from my old c.h.i.p + rtod experience,
> > which cracked 16sec of delay in the mcast queue:
>
> Bufferbloat in the driver queues?

In that case yes, the driver had an infinitely long mcast queue. Once
the number of routes
cracked a certain point, updates across the 1mbit "bus" hit RFC970.
One answer of course
is to fix the driver (which I never got around to), another is to
think about some sort of
delay based rate control, and to ensure hello packets get out on
reasonable intervals.

...

Now that bufferbloat is fixed in several wifi cards (ath9k, ath10k,
mt76, and soon iwl),
and we don't have infinitely long queues...
new problems are rearing their heads. Recently I tried to deploy a few
babel 1.8.2 nodes
with the latest openwrt, which I had to back out rapidly because I was
dropping so many
babel packets under contention.

A patch to universally enable babel ecn in net.c "solves" this
problem, even with no defined response,
my network - particularly the congested gw in the middle - got a *ton*
more reliable. But this opens whole cans of worms as to what the right
approach is to respond to CE marks (mine is to treat it like a loss -
or like half a loss - but to never expire the route merely because it
is congested) - and doesn't solve the infinite queue problem either.

Honestly I'd hoped to have unicast to deploy rather than continue to
fiddle with ecn.

https://www.bufferbloat.net/projects/ecn-sane/wiki/

-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619