Instead of Stochastic Fairness Queuing, a better approach the bufferbloat problem from the end host is to enable RED/ECN on all client hosts. However, as the a

Instead of Stochastic Fairness Queuing, a better approach the bufferbloat problem from the end host is to enable RED/ECN on all client hosts. However, as the author mentions, this is going to massively hurt the non-ECN capable hosts in the network. This approach is "better" because it is analytically proven that for a number of fair TCP stacks competing on an ECN enabled link, the average buffer occupancy can be controlled "around" a certain operating value, which puts a bound on the latency contributed by a particular link. Also, I wonder if the bufferbloat problem becomes significant only in really small RTT networks. i.e., where the RTT is at least the same order of magnitude compared to queuing delays. On long distance links, my guess is that the propagation delays might dominate latencies. I disagree with the point that a solution to bufferbloat is purely end-to-end, if that's what the author implied (Apologies if the author didn't mean this). Even if you have perfectly shaped end hosts, if they share a bottleneck link that's deep buffered, they both will suffer the latency problems. Queuing/buffering in networks is a very nice research area. "How much buffering do we need in a network?" "What if I run a network with as small a buffer as possible?" There are some people who believe that there should just be O(1) buffering in the network. It has been theoretically and experimentally shown that TCP loses only 30% of the throughput if the bottleneck link in the network has a buffer size of just ONE PACKET! So the question here is: is 30% thput loss acceptable? If latency matters, then perhaps yes.