Bufferbloat: Difference between revisions
update main reference for bufferbloat to the CACM article. |
|||
| Line 10: | Line 10: | ||
While latency has been identified as more important than bandwidth for many years,<ref>{{cite web|url=http://rescomp.stanford.edu/~cheshire/rants/Latency.html |title=It's the Latency, Stupid |publisher=Rescomp.stanford.edu |date= |accessdate=2011-07-05}}{{Self-published inline|date=July 2011}}</ref>, the falling price of [[Random-access memory|RAM]] encourages the use of larger buffers and exacerbates the problem. |
While latency has been identified as more important than bandwidth for many years,<ref>{{cite web|url=http://rescomp.stanford.edu/~cheshire/rants/Latency.html |title=It's the Latency, Stupid |publisher=Rescomp.stanford.edu |date= |accessdate=2011-07-05}}{{Self-published inline|date=July 2011}}</ref>, the falling price of [[Random-access memory|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<ref>{{cite web|url=http:// |
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<ref>{{cite web|url=http://cacm.acm.org/magazines/2012/1/144810-bufferbloat/fulltext |title=Bufferbloat: Dark Buffers in the Internet|publisher=ACM |date= January 2012|accessdate=2012-02-20}}</ref>; 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 == |
== Details == |
||
Revision as of 20:13, 20 February 2012
 | This article needs attention from an expert in Internet. Please add a reason or a talk parameter to this template to explain the issue with the article. (January 2012) |
 | This article needs additional citations for verification. (June 2011) |
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.[1][2]
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,[3], 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[4]; 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 that has been filled, the packets will arrive at their destination, but with a higher latency. The packet is not dropped, so TCP does not slow down once the uplink has been saturated, further filling the buffer. Only once the buffer is fully saturated newly arriving packets are dropped. TCP may even decide that the path of the connection has changed, and again go into more aggressive search for a new operating point[clarification needed][citation needed].
In a network buffer, packets are queued before being transmitted. In the problematic situation 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, and the issue wouldn't become apparent. 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 that shares bandwidth on a link to react very slowly as its behavior is quadratic in the amount of buffering[clarification needed].
The problem also affects other protocols. All packets passing through a simple buffer will experience the same delay, so the latency of any connection that passes through a filled buffer will be affected. This can also reduce the interactivity of applications using other network protocols, including the UDP protocol, which is used in VoIP and some games[citation needed] and may cause failures in essential protocols such as DHCP and DNS. This is still the case when using DiffServ to prioritise traffic[dubious – discuss], which uses multiple buffers (queues) for each class[clarification needed] of traffic. HTTP and VoIP may be buffered independently, but each buffer will still be independently susceptible to bufferbloat.
See also
References
- ^ "The criminal mastermind: bufferbloat! « jg's Ramblings". Gettys.wordpress.com. 2010-12-03. Retrieved 2011-07-05.[better source needed]
- ^ Iljitsch van Beijnum (2011-01-07). "Understanding bufferbloat and the network buffer arms race". Ars Technica. Retrieved 2011-11-12.
- ^ "It's the Latency, Stupid". Rescomp.stanford.edu. Retrieved 2011-07-05.[self-published source?]
- ^ "Bufferbloat: Dark Buffers in the Internet". ACM. January 2012. Retrieved 2012-02-20.
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?