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

[Dave Taht <dave.taht@gmail.com>]

To summarize:

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
pathology persists.

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
state.

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@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.
>
> Georgios



-- 

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