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

[Jim Gettys]

On Thu, May 4, 2017 at 6:22 AM, Andy Furniss <adf.lists at gmail.com> wrote:

> Jim Gettys wrote:
>
>> On Wed, May 3, 2017 at 5:50 AM, Andy Furniss <adf.lists at 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)?
>

​Yes.
​

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


​Ok.  The usual warnings about netem being dangerous apply, though netem
can be useful if run on a separate machine.  Netem is an attractive
nuisance, but has caused lots of results to be ultimately useless....  Be
careful.
                              - 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.
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/cake/attachments/20170504/8375683b/attachment.html>