[Bloat] The Blind Men and the Elephant.

[Dave Taht]

On Mon, Feb 12, 2018 at 10:13 AM, Jan Ceuleers <jan.ceuleers at gmail.com> wrote:
> On 12/02/18 18:55, Dave Taht wrote:
>> I would certainly like to see translations and outreach into China...
>> Taiwan... Japan... India... Central and South America... Africa...
>>
>> but to me the simpler thing would be to garner folk to ask at
>> vendor/isp press conferences: "Have you implemented RFC8290 yet? If
>> not, when?"
>
> Devil's advocate: "I don't intend to implement this because, as the
> document says, it is only intended for examination, experimental
> implementation and evaluation. I make real products, not experimental-ones."
>

Certainly at the time we started the RFC (2013? sigh...), we
considered FQ_Codel experimental. After a flood of very useful papers
( a bunch of which jg cites, more on google scholar), and a ton of
actual deployment, I grew pretty confident it could actually go
standards track, but by then it was very late in the process. The
"last" patches for fq_codel arrived (and are in the RFC8290), for
doing a bulk drop on overload, and for leveraging pre-existing
(hardware or vpn offloaded) hash information only a year ago.

( https://www.mail-archive.com/aqm@ietf.org/msg01783.html )

 - but there have been continuous improvements all over the stack,
notably in the flow dissector, and there is work around it trying to
make things more lockless.

And that said, even the august, 2012, implementation of fq_codel was
and remains totally deployable.

I certainly consider the other main RFC (pie) far more experimental
than fq_codel is, as it had not seen any deployment. I'd had high
hopes we'd see it in at least one piece of Cisco's gear by now.

pie-docsis 3.1 is now available in 3 devices, so I'm looking forward
to results from there.

There are still some other pieces of work, like L2S and BBR, that
affect primarily the codel+ecn parts of the algorithm, that I hope
settle down one day.

I figure we'd aim for an rfc8290bis after, say, two more years of
deployment, somehow incorporating the work we did on "ending the
anomaly" in wifi, and I'd hope, also for a hardware and LTE
implementation.

I don't intend for what's in sch_cake to end up as an RFC. It's dual
BSD/GPL licensed and I'd hope that would be enough.

Needed is something "else" that would address the rate limiting and
queue management needs of the ISP->home part of the connection without
doing all the work on the home router. that's something that I'd hope
the chip makers were already all over. Could use a dpdk
implementation.

-- 

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