[Cake] Policers

Sat Aug 4 03:53:51 EDT 2018

https://www.nanog.org/sites/default/files/20170201_Flach_An_Internet-Wide_Analysis_v1.pdf

On Sat, Jul 21, 2018 at 11:45 AM Dave Taht <dave.taht at gmail.com> wrote:
>
> 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


-- 

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