Jump to content

Bufferbloat: Difference between revisions

From Wikipedia, the free encyclopedia
Browse history interactively
← Previous editNext edit →
Content deleted Content added
VisualWikitext
m corrected "exasperates" to "exacerbates"
JimGettys (talk | contribs)
70 edits
Add references to ACM queue articles; clarify mitigation and solution. Still needs more work though.
Line 9: Line 9:
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 can be eliminated by simply reducing the buffer size on the network hardware; however, this is not configurable on most routers and switches. Additionally users have no control when bufferbloat occurs within the networks of their ISPs and other third-party networks throughout the Internet.
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://queue.acm.org/detail.cfm?id=2071893 |title=Bufferbloat: Dark Buffers in the Internet|publisher=ACM |date= |accessdate=2012-12-10}}{{date=November 2011}}</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 ==


The [[TCP congestion avoidance algorithm]] relies on packet drops to determine the [[bandwidth (computing)|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 (telecommunication)|buffer]], the packets will arrive, but with a higher latency. The packet is not dropped, so TCP does not slow down even though it really should. It does not slow down until it has sent so much beyond the capacity of the link that the buffer fills and drops packets, but this then means it has far overestimated the speed of the link.
The [[TCP congestion avoidance algorithm]] relies on packet drops to determine the [[bandwidth (computing)|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 (telecommunication)|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 work erratically and possibly even time out completely.
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.
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 [[Transmission Control Protocol|TCP]], during [[network congestion]] bufferbloat causes extra delays, limiting the speed of internet connections. Other [[network protocol]]s also appear to be affected, including [[User Datagram Protocol|UDP]]-based protocols. This can cause problems by restricting the speed of connections, affecting interactive [[Web 2.0]] applications, gaming and [[VoIP]].
With [[Transmission Control Protocol|TCP]], during [[network congestion]] bufferbloat causes extra delays, limiting the speed of internet connections. Other [[network protocol]]s also are affected, including [[User Datagram Protocol|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 ==
== See also ==
Line 31: Line 31:
== External links ==
== External links ==


* [http://queue.acm.org/detail.cfm?id=2076798 BufferBloat: What's Wrong with the Internet?]] A discussion with [[Vint Cerf]], [[Van Jacobson]], Nick Weaver, and [[Jim Gettys]]
* [http://www.computer.org/portal/web/computingnow/0611/whatsnew/internetcomputing Internet Computing Backspace column] written by Jim Gettys
* [http://www.computer.org/portal/web/computingnow/0611/whatsnew/internetcomputing Internet Computing Backspace column] written by Jim Gettys
* [http://www.youtube.com/watch?v=qbIozKVz73g Google Tech Talk] April, 2011, by Jim Gettys, introduction by [[Vint Cerf]]
* [http://www.youtube.com/watch?v=qbIozKVz73g Google Tech Talk] April, 2011, by Jim Gettys, introduction by [[Vint Cerf]]
Line 36: Line 37:
* [http://gettys.wordpress.com/2010/12/03/introducing-the-criminal-mastermind-bufferbloat/ Jim Gettys' blog]
* [http://gettys.wordpress.com/2010/12/03/introducing-the-criminal-mastermind-bufferbloat/ Jim Gettys' blog]
* [http://blogs.broughturner.com/2009/10/is-att-wireless-data-congestion-selfinflicted.html Has AT&T Wireless data congestion been self-inflicted?]
* [http://blogs.broughturner.com/2009/10/is-att-wireless-data-congestion-selfinflicted.html Has AT&T Wireless data congestion been self-inflicted?]





Revision as of 18:25, 19 December 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, 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

References

  1. ^ "The criminal mastermind: bufferbloat! « jg's Ramblings". Gettys.wordpress.com. 2010-12-03. Retrieved 2011-07-05.[better source needed]
  2. ^ Iljitsch van Beijnum (2011-01-07). "Understanding bufferbloat and the network buffer arms race". Ars Technica. Retrieved 2011-11-12.
  3. ^ "It's the Latency, Stupid". Rescomp.stanford.edu. Retrieved 2011-07-05.[self-published source?]
  4. ^ "Bufferbloat: Dark Buffers in the Internet". ACM. Retrieved 2012-12-10.Template:Date=November 2011

External links

Retrieved from "https://en.wikipedia.org/w/index.php?title=Bufferbloat&oldid=466721563"