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. _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
