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

[Andy Furniss <adf.lists@gmail.com>]

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.

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.