BBR :).
If the packet loss rate is below 15% then BBR is able to fully utilize the path (reaching link_bandwidth*(1 - loss_rate)). This 15% threshold is a design parameter, rather than a fundamental limit
I'm struggling to explain the exact significance of this. Here's Eric Dumazet:
Compared to Cubic, there is 2 to 4 orders of magnitude difference on lossy environments.
Example of 100ms rtt, and 1% packet loss. Cubic performs very badly there.
$ netperf -H 10.246.7.152 -l 30 -- -K cubic
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.246.7.152 () port 0 AF_INET
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 16384 16384 40.00 3.27
$ netperf -H 10.246.7.152 -l 30 -- -K bbr
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.246.7.152 () port 0 AF_INET
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 16384 16384 30.25 9150.01
Third-party testing revealed / elicited an explanation that the current code expects a full buffer (BDP) at the bottleneck, if there is any competition. This is a known target for further improvement. If the condition is not met, it drives up the loss rate. Then traditional TCP's will basically starve.
If there is more buffer than 1 BDP, BBR flows will co-operate to avoid filling excess buffer, hence capping queuing delay as you requested. Traditional TCP's tend to fill the whole buffer. When both are competing, BBR cannot magically fix the behaviour of the traditional TCP flows, however I don't think this hurts BBR in any other way.
If the condition mentioned above is not met, application latency will suffer (having to retransmit lost packets).
https://groups.google.com/forum/#!forum/bbr-dev
https://www.google.co.uk/search?q=tcp-bbr
[PATCH v4 net-next 00/16] tcp: BBR congestion control algorithm