Re: [Cake] Long-RTT broken again

["Toke Høiland-Jørgensen" <toke@toke.dk>]

Jonathan Morton <chromatix99@gmail.com> writes:

> Firstly: I can’t read the flent output with the version of flent
> currently available to pip.  It complains about “version 3” files
> being unsupported as yet.

Ah, right, sorry about that. Will do a new release this afternoon :)

> Running the captures through tcptrace shows that the traffic on each
> flow is very bursty, and that the bursts are roughly synchronised,
> leading to synchronised drop bursts. It reads like a massive
> advertisement for TCP Pacing, and this time cake’s shaper isn’t enough
> to emulate it. (Perhaps a bigger buffer would sort that out.)

Yup, that sounds like a reasonable explanation (and solution, given that
we've seen that a bigger buffer helps).

> Taking one such synchronised drop burst as representative, the sum of
> outstanding data on all four flows in that direction is less than 6MB at that
> moment. This is on the version which I think you’ve patched, and I assume the
> figure also includes data “in flight” in the delay line, not just in cake’s
> buffer. It’s difficult to reconcile that with the nominal 15MB limit. The
> absolute peak within-flow induced delay is 150ms, which corresponds to 1.5MB,
> not 15MB - that’s suspicious.
>
> I also get the impression that CUBIC’s RTT-insensitive behaviour isn’t
> helping matters. I’d be interested to see how more traditional
> algorithms (Reno and Westwood+ in particular) cope with this
> situation.

Can re-run with Reno.

> I’ll try to reproduce the problem locally, then see what I can do to
> fix it.

Awesome! Let me know if you need more info on the setup.

-Toke