[Cake] Long-RTT broken again
toke at toke.dk
Fri Nov 6 06:00:27 EST 2015
Jonathan Morton <chromatix99 at 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
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.
More information about the Cake