On Tue, Jul 24, 2018 at 2:31 PM Dave Taht <[email protected]> wrote: > > 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).
I don't want this convo to die on details. Having a less cpu intensive than shaping yet more effective than policing "thing" would be a goodness. > 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) Another variant was bloom filters. I'd played with murmur as an alternate hash simply because this pull request was a gas: https://github.com/bitly/dablooms/pull/19 > 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. -- Dave Täht CEO, TekLibre, LLC http://www.teklibre.com Tel: 1-669-226-2619 _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
