Re: [Bloat] [bbr-dev] Re: taking apart BBR's behaviors in flent

[Neal Cardwell <ncardwell@google.com>]

On Thu, Sep 22, 2016 at 8:09 AM, Alan Jenkins
<alan.christopher.jenkins@gmail.com> wrote:
> 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.

I mentioned this in another thread this afternoon, but will mention it
here as well,
since it's an important point:

Yes, the current behavior where of creating a ~1*BDP queue when bulk BBR flows
share a bottleneck is something we are actively working on improving. The
current behavior is not the end goal, but rather the place where the current
code arrives due to some subtle trade-offs.  We want the number of packets in
flight to be allowed to potentially be ~1*BDP beyond the pipe BDP, in order to
handle delays that are due to link-layer or receiver effects that cause
delayed, stretched, or aggregated ACKs (these are very common for wifi,
cellular, and cable systems). But ideally we don't want more packets in flight
if the delays are simply due to competing flows, since that can lead to the
~1*BDP of queue you can see in these tests. So we are working on improving the
behavior (reducing the queue) in the case with competing BBR flows.

neal