[Cake] second system syndrome

[Dave Taht]

Jonathon, please comment on the proposals I laid out in:

https://lists.bufferbloat.net/pipermail/cake/2015-December/000861.html



On Mon, Dec 7, 2015 at 1:24 PM, Kevin Darbyshire-Bryant
>>> I find myself torn by 3 things.
>>>
>>> 1) The number of huge wins in fixing wifi far outweigh what we have
>>> thus far achieved, or not achieved, in cake.
> The distractions of crappy wifi and then the FCC débâcle haven't helped
> the focus on Cake one bit.

Wifi is not a distraction for me. Crappy wifi was *why* I got involved
in the whole bufferbloat project. I was otherwise quite happily
retired.

https://www.facebook.com/photo.php?fbid=374680036761&set=t.1483968819&type=3&theater

Everything else I've tackled... was to chase funding, or chase ideas
that were working out on some front or another, or cope with the fears
of people I respected...

For 3 years now, we've had the ability to make a dent in some of
wifi's problems. That's over a billion wifi devices shipped that could
have had a better wifi stack. If I could just have one set of working
wifi devices connecting me to San Juan Del Sur, in heavy rain, I'd
be back at that pool, above, and logout from civilization again.

> Personally speaking, there's a lack of clear project 'lead' -

In my mind, jonathon is and has always been the project lead for cake.
I was very happy when he signed up to do it, and went off in april to
try to finally pull together enough resources to tackle wifi.

One thing that went wrong with the cake project along the way was not
being able to incrementally test each new idea.

new rule: Thou Shalt NOT make changes to codel without being able to
test at a wide variety of RTTs.

And not being able to run perf on any architecture hurt too.

I got grumpy when I started seeing featuritis (and yes, I contributed
to this too, guilt also mine) and algorithmic changes without any
realistic testing being done, and stepped in to try and fix these
things.

perf's fixed.

I emphatically want to bail on me even thinking about cake. It is not
my job to get it upstream, it is not my job to make it better. I think
I have shown conclusively (by doing bcake) that a multitude of
features and code bloat don't actually accomplish anything.

There are still no realistic tests of very low bandwidth behavior...
(which I've asked toke to poke into)

>I persist
> in my assertion that I'm not a coder, certainly not a confident one.
> I've been reluctant to push commits to the repo with ideas/lunacy quite
> frankly because I don't want to piss either you or Jonathan off by
> messing with what I perceive to be 'his' code.

I never feel that way about things. It's just "code". It is either
good or it isn't. Lots of things are worth trying. Most of which
aren't worth keeping. always happy to see new ideas.

> On the other hand, some
> things have happened (and stuck!) because I just blew a raspberry in the
> general direction, said 'stuff it' and pushed - anything that went into
> a feature branch got ignored, anything in 'master' got at least compiled
> and possibly even reviewed.   We should make better use of git &
> (mis)feature branches.   But there's need for a 'Linus' here.  And a lot
> more collaboration.

Well, a dumazet would be more effective than a linus.

The architectural choice here is mostly *what to take away*, which is
nearly everything new in it, and get it upstream for further comments.

Which are the choices I'd like jonathon to make, or at least comment
on, which I laid out in my original mail. *not my job*.

After the GRO code is proven I'd rip out sebastian's treasured last
packet size stat, too. I might rip out all the dscp models in favor of
the 3 tier sqm one. I'd go back to 32 bits for codel.

My cup overfloweth. My job at the moment is to move the bloat related
sites elsewhere before isc turns the power off next week.