[Cake] cake default target is too low for bbr?
xnoreq at gmail.com
Fri Apr 28 18:02:38 EDT 2017
>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
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
>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
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).
More information about the Cake