bufferbloat videos are up.

Sat Feb 4 04:09:56 UTC 2012

On Fri, 3 Feb 2012, Jim Gettys wrote:

> 2. The longer version of the video

Good visualisation. Just a little nitpicking, 802.11 is 54 megabit, not 
megahertz. It should also be pointed out that 802.11 is half duplex, which 
might affect things.

Also, you might want to point out in your material that large buffers are 
there to handle bursts on TCP sessions over high RTT. Your suggestion to 
improve interactive performance hurts high speed TCP high RTT sessions. 
This is probably what most people want to do, but it would be good to 
point it out. Doing a promotion for ECN support in equipment would also be 
good, because introduing WRED with high drop probability a low buffer fill 
will really hurt performance for TCP transfers. ECN will help to avoid 
restransmissions, which just wastes bw.

Where does your 100ms buffer size recommendation come from? The classical 
one is 2xRTT, with a lot of platforms developed around 2000 sized at 600ms 
of buffering (because 300 ms RTT seems like a decent value to choose for 
"max RTT" I guess). At megabit speeds I'd say to achieve your goal having 
100ms FIFO buffering is too high anyway, so to handle your problem you 
need "fairqueue" to look at flows and put persistent buffer filling TCP 
sessions in "the background". This would also mean TCP would be able to 
use full bw without hurting interactivity.

Also, for some operating systems (Linux is the one I know about), there is 
a tendency to have high buffers not only in the IP stack, but also high 
FIFO buffers towards the hardware, in the device driver. I engaged the 
linux-usb mailing list about this, and I did see some talk that indicated 
that people understood the problem.

So basically I agree with your problem statement, however I think it would 
be benficial if your proposed solution was a bit more specific, or at 
least pointed more in that direction. To propose a solution that sounds 
more like "limit buffers to 100ms or less and everything will be fine" 
would indeed remove some of the problem, but it would hurt performance for 
some applications.

The problem you're describing has been know for 25 years, unfortunately 
not by the right people in the business, especially the ones making high 
volume low cost home equipment.

-- 
Mikael Abrahamsson    email: swmike at swm.pp.se