Home page logo

nanog logo nanog mailing list archives

Re: bufferbloat videos are up.
From: Mikael Abrahamsson <swmike () swm pp se>
Date: Sat, 4 Feb 2012 05:09:56 +0100 (CET)

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 () swm pp se

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]