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

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

Jim Gettys wrote:
> 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 guess you mean so cake could be used on egress of sender (in place of fq)?

That's not really the test that I intend to do, which is more like -

[boxA bbr+fq] -> [boxB simulate ISP buffer] -> [boxC cake ingress shape]
a bit lower than "line" rate and see how much "ISP" buffer gets filled.

Also compare bbr, cubic and netem different rtts etc.

>> 
>> 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.