[Cake] Long-RTT broken again

[Jonathan Morton]

> On 5 Nov, 2015, at 16:36, Toke Høiland-Jørgensen <toke at toke.dk> wrote:
> 
> Jonathan Morton <chromatix99 at gmail.com> writes:
> 
>> So, again - what’s going on?  Are there any clues in packet traces
>> with sequence analysis?
> 
> So, reran and took traces. Data and packet dumps at:
> https://kau.toke.dk/experiments/cake/longrtt/
> 
> There's two runs: the first one is what's in git now, the second one
> patches the byte accounting to use the packet length rather than the
> truesize, which helps a bit but is still inadequate.
> 
> The packet dumps and cake stats output agree: cake is running out of
> buffer size. ECN is enabled on this test, and there's not a single mark
> performed, but several thousand drops.
> 
> So something is definitely wrong with the buffer sizing.

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.

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

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.

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

 - Jonathan Morton