[Cake] policers, finally

Sat Jul 21 14:45:21 EDT 2018

I was off in the cheap seats watching,

https://www.youtube.com/watch?v=LdjavTiMrs0&feature=youtu.be&t=1h10m3s

saying "yes, for ghu's sake, back off half on ecn - or more! And if
you are going to try defeating policers, despite the desperate reasons
for them to exist... it's time to come up with a policer that will
fool your algorithm enough so the gamer downstairs stops screaming in
frustration!"

and then there was the aqm talk where they tried to move the setpoint
so the link was always buffered, rather than trying to hit the
artificially small buffer size and back off... (actually I liked this
talk because you can also try configuring the setpoint to where it was
below capacity)
On Sat, Jul 21, 2018 at 11:38 AM Dave Taht <dave.taht at gmail.com> wrote:
>
> On Sat, Jul 21, 2018 at 11:37 AM Dave Taht <dave.taht at gmail.com> wrote:
> >
> > On Sat, Jul 21, 2018 at 11:23 AM Arie <nospam at ariekanarie.nl> wrote:
> > >
> > > It does.
> >
> > well, one approach seems to be to police as per that bug report at say
> > 90-95% of the actual inbound rate, while shaping at 85%... or some
> > combination thereof.
> >
> > figuring out the "burst" value is tricky, of course, but I'd much
> > rather let the queues build up in cake than the cmts, and putting a
> > brick wall there at this point in the internet's evolution seems like
> > a start.
> >
> > this morning I spent watching ietf preso after preso "accept" that
> > 100ms of queuing delay and pdv was acceptible, then showing tests with
> > 50 packet buffers showing that things like BBR worked ok at 100mbit,
> > when... well... here I am at hundred mbit, with 300+ms of inherent
> > queuing delay on the cable downlink, that shapes down nicely using
> > cake vs cubic to 5-40, looking at the carnage. I *don't like* policers
> > (at least, not what's deployed today), and the BBR folk don't like
> > them either... but they seem necessary if overly aggressive transports
> > (as netflix's appears to be, also) exist.
> >
> >
> > >
> > > On 21 July 2018 at 20:02, Dave Taht <dave.taht at gmail.com> wrote:
> > >>
> > >> In other news:
> > >>
> > >> https://github.com/tohojo/sqm-scripts/issues/68
> > >>
> > >> does the ER4 have act_police?
> > >>
> > >> On Sat, Jul 21, 2018 at 10:55 AM Arie <nospam at ariekanarie.nl> wrote:
> > >> >
> > >> > It's Ziggo NL/Liberty Global. I'm surprised by the reported latency in the fast.com test. Both the site and the flent ping test report about the same 60-ish ms.  DSLReports and flent RRUL report way more bufferbloat, so I guess those stress my connection more than fast.com
> > >> >
> > >> >
> > >> > On 21 July 2018 at 19:45, Dave Taht <dave.taht at gmail.com> wrote:
> > >> >>
> > >> >> Thank you. At least for your ISP (?), at 250mbit, you can hold the
> > >> >> damage down to something reasonable, and certainly you are winning big
> > >> >> on the upload.
> > >> >>
> > >> >> Good to know the ER4 can keep up, also.
> > >> >> On Sat, Jul 21, 2018 at 10:36 AM Arie <nospam at ariekanarie.nl> wrote:
> > >> >> >
> > >> >> > Unshaped reno attached.
> > >> >> >
> > >> >> > On 21 July 2018 at 19:27, Dave Taht <dave.taht at gmail.com> wrote:
> > >> >> >>
> > >> >> >> Yours is not as horrific as mine in either case.
> > >> >> >>
> > >> >> >> Can you provide an unshaped result as well?
> > >> >> >>
> > >> >> >>
> > >> >> >> On Sat, Jul 21, 2018 at 10:24 AM Arie <nospam at ariekanarie.nl> wrote:
> > >> >> >> >
> > >> >> >> > Two more data points. Shaped my connection to 250Mbit out of the advertised 250Mbit (my usual setting) and shaped to 200Mbit out of the 250Mbit. This is a pre-linux-net-next cake running on an Edgemax ER4 with kernel 3.10.107-UBNT.
> > >> >> >> >
> > >> >> >> > The regular spikes in ICMP ping is due to the crappy Puma 6 chipset in the cable modem. UDP is not affected.
> > >> >> >> >
> > >> >> >> > On 21 July 2018 at 19:20, Georgios Amanakis <gamanakis at gmail.com> wrote:
> > >> >> >> >>
> > >> >> >> >> On Sat, 2018-07-21 at 09:09 -0700, Dave Taht wrote:
> > >> >> >> >> >
> > >> >> >> >> > 1) Can someone else on a cablemodem (even without the latest cake,
> > >> >> >> >> > this happens to me on older cake and fq_codel) try this test?
> > >> >> >> >> >
> > >> >> >> >>
> > >> >> >> >> I just tried this on my cable comcast connection. I set ingress to ~80%
> > >> >> >> >> of what fast.com reports when no shaper is in place.
> > >> >> >> >>
> > >> >> >> >> #tc qdisc add dev ens4 root handle 8011 cake bandwidth 16000kbit dual-
> > >> >> >> >> dsthost docsis ingress
> > >> >> >> >> #tc qdisc add dev ens3 root handle 8012 cake bandwidth 2500kbit dual-
> > >> >> >> >> srchost nat docsis ack-filter
> > >> >> >> >>
> > >> >> >> >> I got the same result as you. This is using latest cake.
> > >> >> >> >>
> > >> >> >> >> Georgios
> > >> >> >> >>
> > >> >> >> >> _______________________________________________
> > >> >> >> >> Cake mailing list
> > >> >> >> >> Cake at lists.bufferbloat.net
> > >> >> >> >> https://lists.bufferbloat.net/listinfo/cake
> > >> >> >> >>
> > >> >> >> >
> > >> >> >> > _______________________________________________
> > >> >> >> > Cake mailing list
> > >> >> >> > Cake at lists.bufferbloat.net
> > >> >> >> > https://lists.bufferbloat.net/listinfo/cake
> > >> >> >>
> > >> >> >>
> > >> >> >>
> > >> >> >> --
> > >> >> >>
> > >> >> >> Dave Täht
> > >> >> >> CEO, TekLibre, LLC
> > >> >> >> http://www.teklibre.com
> > >> >> >> Tel: 1-669-226-2619
> > >> >> >
> > >> >> >
> > >> >>
> > >> >>
> > >> >> --
> > >> >>
> > >> >> Dave Täht
> > >> >> CEO, TekLibre, LLC
> > >> >> http://www.teklibre.com
> > >> >> Tel: 1-669-226-2619
> > >> >
> > >> >
> > >>
> > >>
> > >> --
> > >>
> > >> Dave Täht
> > >> CEO, TekLibre, LLC
> > >> http://www.teklibre.com
> > >> Tel: 1-669-226-2619
> > >
> > >
> >
> >
> > --
> >
> > Dave Täht
> > CEO, TekLibre, LLC
> > http://www.teklibre.com
> > Tel: 1-669-226-2619
>
>
>
> --
>
> Dave Täht
> CEO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-669-226-2619

-- 

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