On Wednesday, 21 September 2016 20:25:32 UTC+1, Dave Taht wrote:> Looking at cake_flowblind_noecn, BBR1 and BBR4 just kills both CUBIC flows.
> Same with PIE.
Yep. The single queue AQMs expect their induced drops to matter to all
flows. BBR disregards them as noise. I think there's hope though, if
BBR can treat ECN CE as a clear indication of of congestion and not
filter it as it does drops.
Extra credit assignment: get the next version of DOCSIS PIE to turn on ECN?
https://tools.ietf.org/html/draft-ietf-aqm-docsis-pie-02#section-4.7
But cake/fq_codel is just fine with different cc's in the mix, and I'm
dying to look at the captures for what happens there.
Very glad to see that, I can keep using fq_codel :).
> So it seems my intuition was wrong, at least for these scenarios. It wasn't
> CUBIC that would kill BBR, it's the other way around.
So (from the other thread) BBR is designed to use the traditional
recommendation of 1 BDP's worth of buffer. In the absence of other CC's,
it would limit itself to that. Understandable for bottlenecks in end-site modems or wifi.
Shallower buffers cause somewhat increased packet loss (given multiple competing BBR streams). BBR is designed to survive this without difficulty (incurring retransmit latency). Competing loss-based CCs will suffer badly.
The patch says it's designed to improve throughput "on today's high-speed long-haul links using commodity switches with shallow buffers" by not "[over-reacting] to losses caused by transient traffic bursts".
If there is systemic congestion at those switches[1]...
[1] ex
https://www.ncta.com/sites/prod/files/MIT-Congestion-DC.pdf
http://groups.csail.mit.edu/ana/Measurement-and-Analysis-of-Internet-Interconnection-and-Congestion-September2014.pdf
...I wait with interest to see what the ACM article says.
My intuition was that "delay based TCPs can't work on the internet!" -
and was wrong, also.
> Great to have testing
> tools! Thanks Flent!
Thx, toke! I try not to remember just how hard it was to do this sort
of analysis on complex network flows when we started.
And thanks for the matrix of test results!
It shows how powerful a tool it is, to see points raised so quickly.
If I'm reading the drops graph right, I can see multi-second periods >= 10% packet loss when the buffer is limited to 25ms (bfifo_64k, bw=20Mbit-rtt=48ms-flows=2-noecn-bbr). Clearly explains why normal CUBIC gets crushed :).
Alan