[Cake] Donation

[Dave Taht]

Pete Heist <peteheist at gmail.com> writes:

>> On Nov 12, 2017, at 6:00 PM, cake-request at lists.bufferbloat.net wrote:
>> 
>> I sometimes think we should establish an organization, with a board of
>> directors, a bank account, etc, but aside
>> from grant money, donated computers and computer time, and all the
>> massive efforts of all the volunteers, that's most of the donations
>> we've ever got, and it would be, at least, 800 bucks to start a
>> non-profit, + an accountant to "do right".
>> 
>> Any and all thoughts as to how to do better are welcomed.
>> 
>> We could have a bake sale for cake, to get it mainlined.
>
> Has there been any thought towards monetizing some portion of the bufferbloat
> project to help pay for it? Here are a couple of ideas:

I'm going to skip commenting in the hope that others chime in first.

> By the way, what or how much is needed to get Cake mainlined?

I'd like us to give it a go when net-next reopens in two weeks,
we'd then have 6 weeks or so to get it right.

We need:

* Someone to do the heavy lifting. Which I suspect would be me.
* Someones with various hardware platforms that current kernels can be
  run on. qemu?
* I'd like to see the ack filtering work get tested on lede at low
  bandwidths on dsl especially.
* A whole lotta tests at various RTTs

Blockers:

* Ripping out all the backward compatability cruft for submission to
  mainline and following netdev formatting conventions for comments and
  indentation. I'd like any new features in the backport to get
  backported, though (sigh), as lede looks to be shipping a 4.9 based
  kernel.
  
* tc-cake man page needs to be updated.

* tc-adv related code updated to latest iproute2

* There is some work going on here to add ack filtering to cake, which
looks VERY promising: https://github.com/dtaht/sch_cake/pull/63

I'm going to add something like this to netem also. It may be that
merely leveraging the hash would be enough in cake's case.

* Testing against the net-next kernel on x86, x86_64, arm, mips, and
aarch architectures. (I just got bit by not testing 32 bit arches, sigh)

Non-Blockers:

* I don't believe in cobalt, or rather, I won't believe in it until we
have data at many RTTs. That said, what I'd propose would be a
monolithic cobalt.h file rather than codel5.h.

The netns stuff will make simulating RTTs and bandwidths much easier....

* I think the fq_codel batch drop facility is better than what cake uses
in case of floods. Partially due to the need to handle backports the
mechanism fq_codel uses is hard to use - but going mainline we could add this.

* The autorate_ingress code should be marked experimental. I keep hoping
it can be improved by better looking for "smoothness" inbound, but
algorithms escape me. This doesn't bother me much, as tcp continues to
be improved over the past 50 years, perhaps we can find ways to improve
this with more users.

* It is possible to tune the quantum and peeling functions to not peel
to the extent they do. Particularly there is usually no need (aside from
wanting accurate statistics) to peel below 1500 bytes (except perhaps
with the new ack filter mode). We experimented a lot with this in the
early days but could never come to a resolution.

* I don't have any use for precidence mode and would like to remove it.