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

[xnor]

>On Fri, 28 Apr 2017, xnor wrote:
>
>>As I understand it, increase in RTT due to queueing of packets is the 
>>main feedback mechanism for BBR.
>>So dropping packets, which I already consider harmful, is really 
>>harmful with BBR because you're not telling the sender to slow down.
>
>If BBR does not slow down when packets are dropped, it's too hostile to 
>use on a public network. The only way for a public network to respond 
>to a flood of traffic higher than what it can handle is to drop packets 
>(with a possible warning via ECN shortly before packets get dropped). 
>If BBR doesn't slow down, it's just going to be wasting bandwidth.
No it isn't. Packet loss does not equal conguestion - it never did. 
Dropping packets to signal congestion is an ugly hack for 
implementations that are too dumb to understand any proper congestion 
control mechanism.
Dropping due to queues being full normally doesn't happen before the RTT 
has significantly increased.

BBR fixes both of these problems:
a) it ignores packet loss on unreliable links and therefore achieves 
much higher throughput than conventional congestion control algorithms 
(that wrongly assume congestion on packet loss)
An experiment with 10 Gbps bottleneck, 100 ms RTT and 1% packet loss (as 
described in the net-next commit) showed ~3000x higher throughput with 
BBR compared to cubic.

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.


>
>>Instead, with a controlled delay qdisc like cake or codel, you're 
>>telling the sender to keep sending the data faster because the qdisc 
>>keeps the increase in RTT minimal. To make things worse, you're 
>>throwing away perfectly good packets with no effect other than wasting 
>>bandwidth.
>
>you are mistaking how cake and codel work. They are working at the link 
>endpoint adjacent to where the bandwidth is most limited. They drop 
>packets before they get send over the most contrained link. The fact 
>that the packets eat up some bandwidth on the non-constrained link 
>prior to the bottleneck doesn't matter, the bandwidth is available by 
>definition (otherwise it would be a constrained link to the endpoint 
>before it)
No, my ISP isn't using either cake or codel and neither is Andy's.
We're talking about ingress traffic "shaping" of downloads here, so 
we're not working at the point in front of the most constrained link. 
Instead we work behind the most contrained link.

That's why dropping packets is counterproductive, but as I've mentioned 
before it should be avoided anyway (except for the broken parts of the 
Internet where it still is a necessary evil).