Re: [Cerowrt-devel] taking apart BBR's behaviors in flent

[Alan Jenkins <alan.christopher.jenkins@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2511 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 3432 bytes --]