I’m currently attending the linux.conf.au conference here in Brisbane, Australia.

This morning, Vint Cerf spoke about the direction of the general Internet, and during Q&A, an audience member asked about bufferbloat.

I didn’t know what this  bufferbloat was, so I did a bit of reading, and found this.

In September of 2009, Dave Reed reported very long RTT’s with low packet loss on 3g networks on the end-to-end interest mailing list.  I’ve observed on several different operator’s 3g networks RTT times of order 6 seconds: Dave reported seeing up to 30 second RTT’s. These RTT’s are so long that many of the operations “time out”, by boredom (and extreme frustration) of the user.

Essentially, the explanation of bufferbloat is quite simple. The Internet revolves around the use of the transmission control protocol (TCP), which manages the rate at which nodes on the network send data by using congestion control techniques, such as exponential back-off. This works by monitoring when the network drops packets. If your computer notices that packets are being dropped, it is assumed that this is because of network congestion, and reduces the rate at which it sends new packets. Where the term bufferbloat comes in is buffers at various points in the network (several places in your computer, in your wireless router, in your ISP’s routers, the list goes on…) are getting larger, which confuses the TCP congestion control mechanisms, and creates huge queues of packets at all points in the network, giving rise to huge latencies.

Personally, I have experienced these problems on a daily basis using Vodafone’s 3G network.

If you’re interested in this problem, read more of Jim Gettys’ blog. If you work for Vodafone, please pass this information on.

[Edit] The description that David Reed gave of the problem on AT&T’s network is available here, the subsequent thread of conversation is an interesting dialog into TCP congestion control.

Post a Comment