Re: [Cake] cake default target is too low for bbr?

[Jim Gettys <jg@freedesktop.org>]

[-- Attachment #1: Type: text/plain, Size: 2541 bytes --]

On Wed, May 3, 2017 at 5:50 AM, Andy Furniss <adf.lists@gmail.com> wrote:

> Andy Furniss wrote:
>
>> Andy Furniss wrote:
>>
>> b) it reacts to increase in RTT. An experiment with 10 Mbps bottleneck,
>>>> 40 ms RTT and a typical 1000 packet buffer, increase
>>>> in RTT with BBR is ~3 ms while with cubic it is over 1000 ms.
>>>>
>>>
>>> That is a nice aspect (though at 60mbit hfsc + 80ms bfifo I tested
>>> with 5 tcps it was IIRC 20ms vs 80 for cubic). I deliberately test
>>> using ifb on my PC because I want to pretend to be a router - IME
>>> (OK it was a while ago) testing on eth directly gives different
>>> results - like the locally generated tcp is backing off and giving
>>> different results.
>>>
>>
>> I retested this with 40ms latency (netem) with hfsc + 1000 pfifo on
>> ifb.
>>
>
> So, as Jonathan pointed out to me in another thread bbr needs fq and it
> seems fq only wotks on root of a real eth, which means thay are invalid
> tests.
>

​Specifically, BBR needs packet pacing to work properly: the algorithm
depends on the packets being properly paced.

Today, fq is the only qdisc supporting pacing.

The right answer would be to add packet pacing to cake/fq_codel directly.
Until that is done, we don't know how BBR will work in our world.
                                              - Jim​

>
> I will soon (need to find a crossover cable!) be able to see using a
> third sender how cake varies shaping bbr in simulated ingress.
>
> I can test now how bbr fills buffers - some slightly strange results,
> one netperf ends up being "good" = buffer only a few ms.
>
> 5 netperfs started together are not so good but nothing like cubic.
>
> 5 netperfs started with a gap of a second or two are initially terrible,
> filling the buffer for about 30 seconds, then eventually falling back to
> lower occupancy.
>
> TODO - maybe this is a netperf artifact like bbr/fq thinks it is app
> limited.
>
> The worse thing about bbr + longer RTT I see so far is that its design
> seems to be to deliberately bork latency by 2x rtt during initial
> bandwidth probe. It does drain afterwards, but for something like dash
> generating a regular spike is not very game friendly and the spec
> "boasts" that unlike cubic a loss in the exponential phase is ignored,
> making ingress shaping somewhat less effective.
>
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
>

[-- Attachment #2: Type: text/html, Size: 4122 bytes --]