Re: [Bloat] No backpressure "shaper"+AQM

[Dave Taht <dave.taht@gmail.com>]

I'd actually written some code for this way back when, if you want to
know how policers currently work,
google for "tri-color policer". They worked ok in the T1 era, but suck
rocks now.

TL;DR

Earlier this week while we (ended up) debugging a buggy comcast modem
I was desparate enough to resume thinking it was time to revisit the
concept as a first stage filter prior to hitting cake.

I did think that an *aqm* that aimed for defeating a burst policer
rate (much like BBR is doing now) would be a goodness. Say you know
there is a policer upstream configured like yours...

Then... I thought we could build something lighter weight than
shaping, but the feature set built and built... A few useful
enhancements to the standard policer like deficits rather than tbf,
adding ECN, shooting equally at all flows it sees (fq), not shooting
at one flow for more than one packet in 4 (thus, voip suffers not),
trying to wait an RTT before shooting again (codel - actually pie in
this case).

As one example I controlled the shooting schedule with a 2048 bit, (2
bits per flow) bitmap sampling every 5ms, keeping around 16 versions
(thus 80ms of history)

I discarded the idea for several other reasons back then

ENOFUNDING
TBF Policers generally are used in switches and routers that do it in
hardware. Everything I came up with
was doable in HW (O1) (which cake/fq_codel are not), but waiting 10
years for it to show up in ISP hardware seemed harder than waiting 10
years to see ISP shapers get fixed.
Shaping, given the growing amounts of multi-core underutilized cpus,
allowed us to be more gentle and achieve
goals like better e2e host and flow fq, while allowing sparse flows to
not be delayed very much.
ENOFUNDING
Identifying flows required taking a hash which slows things down.

Still, a "slightly better" bobbie aqm influenced policer has long
seemed doable so long as it's extremely lightweight.