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).
_______________________________________________
Cake mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cake
