[Cake] inbound cake or fq_codel shaping fails on cable on netflix reno

[Arie]

 You're now the third person where I've seen the hping3 trick work, I'm
pretty pleased it's with Mr Bufferbloat himself ;)

I figured this out by accident some time ago. I used fq_codel and later
cake to keep people happy at a small LAN party where 10 people shared a
40Mbit DOCSIS connection. Year after year we kept renting the same vacation
homes, with the same old Cisco EPC3295 cable modems. We used to bring some
weird pfsense box with tons of custom game-based rules to keep latencies
under control, but we just replaced that with an openwrt box running
fq_codel one day, way simpler and better latencies (thank you and the other
bufferbloat people!)

Suddenly one year, my openwrt/cake box was no longer able to keep the
latency under control and people started complaining. I noticed that while
an upload was running, the latency was fine (despite someone hogging the
downstream with big downloads). As soon as the upload stopped, the big
download started to cause ping spikes again.
After some testing, I was able to use the hping3 trick to send the minimum
needed upstream traffic to keep pings low, LAN party saved.

Meanwhile on my home connection I used a similar DOCSIS modem. I'd always
been able to just shape my connection close to the advertised rates. One
day, latencies (and DSLReports bufferbloat score) got bad. Interestingly,
flent RRUL results reported lower latencies during the test run than during
the idle period before and after the test. Again I could use the same
hping3 trick to "fix" it. I've asked the bufferbloat mailing list to see if
anyone knew what was going on, but nothing came of it.
My ISP kept pushing new DOCSIS modems, so I took my chances despite it
using a puma 6 chipset (TG2492LG). This one is fine without the hping
trick, just like my old modem used to be.

Here's what I learned about some cable modems with my particular ISP
(Ziggo, the Netherlands) in my specific region:
Cisco EPC3212 (DOCSIS 3.0 8x4), used to work fine, now gets big latency
spikes regardless of the shaped rate.
Technicolor 7200 (DOCSIS 3.0 8x4), still works fine.
Arris  TG2492LG (DOCSIS 3.0 24x8), shaping works just fine, latency is
under control, but it has a puma 6 chip which causes latency spikes in TCP
and ICMP packets. UDP does not seem to be affected.


On 22 July 2018 at 00:13, Dave Taht <dave.taht at gmail.com> wrote:

> wow. That is the best dslreports test result for cable I have ever had.
>
> with hping3 -2 -d 0 -s 10080 -k -p 80 -i u150 96.120.89.153
>
> http://www.dslreports.com/speedtest/36209937
>
> Without:
>
> http://www.dslreports.com/speedtest/36210095
>
> You say a different cablemodem does better without hping3 running? which?
> :)
>
> Most of my production gear is based on an older arris modem (which is
> quite good), most of my test gear is a bunch of netgear (free) modems
> and service I got free from my time working for comcast.
>
> I haven't got around to springing for a docsis 3.1 modem yet (they are
> awfully pricy).
> On Sat, Jul 21, 2018 at 2:37 PM Dave Taht <dave.taht at gmail.com> wrote:
> >
> > or, another way we might look at it is there is very little we can do
> > as the cmts has to have data in it in order to burst schedule the mac
> > for the next string of packets, much like how fq_codel for wifi has
> > "one in the hardware, one ready to go", a cmts has at least one in the
> > hardware (per channel? a multiple? what?).
> >
> > or I could be on drugs entirely. And this thread did start with
> > fast.com misbehaving badly regardless of the shaper in place or not,
> > which is not what I'm looking at now.  I need to setup a 45ms rtt
> > test...
> >
> > anyway, as per your suggestion, the latency gets MUCH better with your
> > hping3 idea running, which implies that we've  been fooled all along
> > by the rrul test. On the other hand, I think this will hurt other
> > cable modems on the same wire. On the gripping hand, I'm happier
> > knowing that with a busier network, docsis cable, when shaped, gets
> > better, and that I should junk my existing test cablemodem due to the
> > persistent spikes I see.
> >
> > I wonder if it's the sent path or the return path shattering latency
> > so well? I wonder if hping3 would count against your badwidth cap?
> >
> > going back to trying to figure out why fast.com is so gnarly
> > On Sat, Jul 21, 2018 at 2:18 PM Arie <nospam at ariekanarie.nl> wrote:
> > >
> > > I had a similar issue with my previous cable modem, whatever I shaped
> to didn't matter, I still had long delays. I "fixed" it by continuously
> sending a stream of empty UDP packets upstream:
> > >
> > > hping3 -2 -d 0 -s 10080 -k -p 80 -i u150 IP-OF-FIRST-OUTSIDE-CABLE-HOP-
> HERE
> > >
> > > On 21 July 2018 at 22:36, Dave Taht <dave.taht at gmail.com> wrote:
> > >>
> > >> This is my "inbound trying to shape a cable connection" smoking gun.
> > >> The delay curve is the same
> > >> shaping the 110mbit cmts down to 85mbit OR 55mbit.
> > >>
> > >> _______________________________________________
> > >> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/cake/attachments/20180722/c4786f3c/attachment-0001.html>