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
_______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat