Bufferbloat

Bufferbloat is a phenomenon in a packet-switched computer network whereby excess buffering of packets inside the network causes high latency and jitter, as well as reducing the overall network throughput. The term was coined by Jim Gettys in late 2010.

This problem is caused mainly by router and switch manufacturers making incorrect assumptions about whether to buffer packets or drop them. As a general rule, packets should not be buffered for more than a few milliseconds. Any more than this can lead to TCP's congestion-avoidance algorithms breaking, causing problems such as high and variable latency, and choking network bottlenecks for all other flows as the buffer becomes full of the packets of one TCP stream and other packets are then dropped. The buffers then take some time to drain, before the TCP connection ramps back up to speed and then floods the buffers again.

When bufferbloat is present and the network is under load, the symptom is that normal web page loads can take many seconds to complete. Any type of service which requires consistent throughput (whether low or high bandwidth), be it VoIP, networked gaming, text and video chat programs, and interactive application such as remote login become next to impossible.

While latency has been identified as more important than bandwidth for many years,, the falling price of RAM encourages the use of larger buffers and exacerbates the problem.

The problem may be mitigated by reducing the buffer size on the network hardware; however, this is not configurable on most home routers, broadband equipment and switches, nor even feasible in today's broadband and wireless systems; full solutions require Active Queue Management. Additionally users have no control when bufferbloat occurs within the networks of their ISPs and other third-party networks throughout the Internet.

Details

The TCP congestion avoidance algorithm relies on packet drops to determine the bandwidth available. It speeds up the data transfer until packets start to drop, then slows down the connection. Ideally it speeds up and slows down until it finds an equilibrium equal to the speed of the link. However, for this to work the packet drops must occur in a timely manner, so that the algorithm can select a suitable transfer speed. With a large buffer, the packets will arrive, but with a higher latency. The packet is not dropped, so TCP does not slow down even though it should have done so long before, and TCP may even decide that the path of the connection has changed, and again go into more aggressive search for a new operating point.

In a network buffer, packets are queued before being transmitted. Packets are only dropped if the buffer is full. On older routers, buffers were fairly small so filled quickly and therefore packets began to drop shortly after the link became saturated, so the TCP protocol could adjust. On newer routers buffers have become large enough to hold several megabytes of data, which translates to 10 seconds or more at a 1 Mbit/s line rate used for residential Internet access. This causes the TCP algorithm to share bandwidth on a link to react very slowly as it's behavior is quadratic in the amount of buffering.

The problem also affects other protocols. Since the buffer can easily build up several seconds worth of data before packets start to drop which must wait in the buffer until they are transmitted this can reduce the interactivity of interactive applications and cause latency problems for gamers and VoIP. This is still the case when using DiffServ to prioritise traffic, which uses multiple buffers (queues) for each class of traffic. HTTP and VoIP may be buffered independently, but each buffer will still be independently susceptible to bufferbloat.

With TCP, during network congestion bufferbloat causes extra delays, limiting the speed of internet connections. Other network protocols also are affected, including UDP-based protocols. This can cause problems by restricting the speed of connections, affecting interactive Web 2.0 applications, gaming and VoIP, and causing sporadic failures of essential protocols such as DHCP and DNS.

See also

• Head-of-line blocking

External links

• BufferBloat: What's Wrong with the Internet? A discussion with Vint Cerf, Van Jacobson, Nick Weaver, and Jim Gettys
• Internet Computing Backspace column written by Jim Gettys
• Google Tech Talk April, 2011, by Jim Gettys, introduction by Vint Cerf
• Bufferbloat.net, a central repository for people trying to solve the bufferbloat problem
• Jim Gettys' blog
• Has AT&T Wireless data congestion been self-inflicted?