[Cerowrt-devel] [Cake] inbound cake or fq_codel shaping fails on cable on netflix reno
dave.taht at gmail.com
Sat Jul 21 16:01:07 EDT 2018
A) I think the magic 85% figure only applies at lower bandwidths.
B) We are at least partially in a pathological situation where
CMTS = 380ms of buffering, token bucket fifo at 100mbit
Cakebox: AQMing and trying to shape below 85mbit, gradually ramping up
the signalling once per 100ms downwards.
The cmts buffer fills more rapidly, particularly in slow start, while
presenting packets to the inbound shaper at 100mbit. cake starts
signalling, late, trying to achieve but at that point the apparent
RTTs are still growing rapidly (because of the buffer building up in
the cmts inflicting that RTT), so as fast as we signal, we've got such
a big buffer built up in the CMTS that tcp only sees one signal per
RTT which is mismatched against what cake is trying to thwart. The
the idea for bobbie was that the goal for codel is wrong for inbound
shaping, that instead of aiming for a rate, we needed to sum all the
overage over our rate and reduce that until it all drains from cmts
shaper. So, lets say (waving hands a bit here)
we get 160mbits/sec for 8 seconds with an outbound shaped rate of 100.
That 480mbits (independent of any signalling we did to try to reduce
it) "stuck" up there. We're trying to gradually get it to 85mbits/sec,
but the signalling is now so far behind the tcp's now observed actual
rtt that it takes forever to get anywhere and we end up in steady
The more, aggressive, flows you have, the worst this disparity gets.
using perhaps cake's ingress estimator it seems possible to "bob" the
rate down until it drains, or to work on more aggressively drain the
built up queue than the gentle approach fq_codel uses, policer style.
On Sat, Jul 21, 2018 at 11:18 AM Georgios Amanakis <gamanakis at gmail.com> wrote:
> On Sat, 2018-07-21 at 10:47 -0700, Dave Taht wrote:
> > for reference can you do a download and capture against flent-newark,
> > while using the ping test?
> New data, this is what I did:
> 1) Started a ping test using the flent-fremont server.
> 2) Started a tcp_8down test (for 15 seconds) using the flent-newark
> server. I chose tcp_8down since fast.com was also using 8 flows.
> 3) Captured on the host where the above tests ran.
> It seems to be working as expected here.
CEO, TekLibre, LLC
More information about the Cerowrt-devel