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.