{{Short description|CongestionNetwork congestion caused by excessive packet buffering}}

'''Bufferbloat''' is a cause of high [[latencyLatency (engineering)|latency]] and jitter in [[packet-switched network]]s caused by excess [[bufferBuffer (telecommunication)|buffer]]ing of [[Network packet|packets]]. Bufferbloat can also cause [[packet delay variation]] (also known as jitter), as well as reduce the overall network [[throughput]]. When a [[Router (computing)|router]] or [[Network switch|switch]] is configured to use excessively large buffers, even very high-speed networks can become practically unusable for many interactive applications like [[voice over IP]] (VoIP), [[audio streaming]], [[Online game|online gaming]], and even ordinary [[web surfingbrowsing]].

Some communications equipment manufacturers designed unnecessarily large buffers into some of their [[Network equipment|network products]]. In such equipment, bufferbloat occurs when a network link becomes [[Network congestion|congested]], causing packets to become queued for long periods in these oversized buffers. In a [[FIFO (computing and electronics)|first-in first-out]] queuing system, overly large buffers result in longer queues and higher latency, and do not improve network throughput. It can also be induced by specific slow-speed connections hindering the on-time delivery of other packets.

The bufferbloat phenomenon was described as early as 1985.<ref>{{cite web | url date=http://tools.ietf.org/html/rfc9701985-12-31 | title = On Packet Switches Withwith Infinite Storage | date url= 1985-12-31https://www.ietf.org/rfc/rfc0970.txt}}</ref> It gained more widespread attention starting in 2009.<ref name ="Ars Understanding">{{cite web | url = https://arstechnica.com/tech-policy/news/2011/01/understanding-bufferbloat-and-the-network-buffer-arms-race.ars | title = Understanding Bufferbloat and the Network Buffer Arms Race | date = 2011-01-07 | accessdate = 2011-11-12 | website = [[Ars Technica]] | first = Iljitsch | last = van Beijnum }}</ref>

An established [[rule of thumb]] for the network equipment manufacturers was to provide buffers large enough to accommodate at least 250&nbsp;[[Millisecond|ms]] of buffering for a stream of traffic passing through a device. For example, a router's [[Gigabit Ethernet]] interface would require a relatively large 32&nbsp;[[MiB|MB]] buffer.<ref name=":0">{{cite web | url = http://conferences.sigcomm.org/sigcomm/2004/papers/p277-appenzeller1.pdf | title = Sizing Router Buffers | format = PDF | year = 2004 | accessdate = 2013-10-15 | author1 = Guido Appenzeller | author2 = Isaac Keslassy | author3 = Nick McKeown | work = ACM SIGCOMM | publisher = ACM}}</ref> Such sizing of the buffers can lead to failure of the [[TCP congestion control algorithm]]. The buffers then take some time to drain, before congestion control resets and the TCP connection ramps back up to speed and fills the buffers again.<ref name="codel-acmq">{{cite web | url = http://queue.acm.org/detail.cfm?id=2209336 | title = Controlling Queue Delay | authorlink = Kathleen Nichols | last1 = Nichols | first1 = Kathleen | authorlink2 = Van Jacobson | last2 = Jacobson | first2 = Van | work = ACM Queue | publisher = ACM Publishing | date = 2012-05-06 | accessdate = 2013-09-27}}</ref> Bufferbloat thus causes 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.<ref>{{cite webcitation | url = http://www.computer.org/portal/web/csdl/doi/10.1109/MIC.2011.56 | title = Bufferbloat: Dark Buffers in the Internet | last = Gettys | first = Jim | publisher = IEEE | date = May–June 2011 | accessdate = 2012-02-20 | series = IEEE Internet Computing | pages = 95–96 | volume = 15 | issue = 3 | doi = 10.1109/MIC.2011.56 | archive-url = https://web.archive.org/web/20121012012532/http://www.computer.org/portal/web/csdl/doi/10.1109/MIC.2011.56 | archive-date = October 12, 2012 | url-status = dead }}</ref>

In the previous example, using an advanced [[traceroute]] tool instead of the simple pinging (for example, [[MTR (software)|MTR]]) will not only demonstrate the existence of a bloated buffer on the bottleneck, but will also pinpoint its location in the network. Traceroute achieves this by displaying the route (path) and measuring transit delays of packets across the network. The history of the route is recorded as round-trip times of the packets received from each successive host (remote node) in the route (path).<ref>{{cite web | url = http://linux.die.net/man/8/traceroute | title = traceroute(8) – Linux man page | accessdate = 2013-09-27 | website = die.net}}</ref>

{{See also|TCP tuning#Window size|TCP congestion control#Slow- start}}

Most [[TCP congestion control]] algorithms rely on measuring the occurrence of packet drops to determine the available [[bandwidth (computing)|bandwidth]] between two ends of a connection. The algorithms speed up the data transfer until packets start to drop, then slow down the transmission rate. Ideally, they keep adjusting the transmission rate until it reaches an equilibrium speed of the link. So that the algorithms can select a suitable transfer speed, the feedback about packet drops must occur in a timely manner. With a large [[buffer (telecommunication)|buffer]] that has been filled, the packets will arrive at their destination, but with a higher latency. The packets were not dropped, so TCP does not slow down once the uplink has been saturated, further filling the buffer. Newly arriving packets are dropped only when the buffer is fully saturated. Once this happens TCP may even decide that the path of the connection has changed, and again go into the more aggressive search for a new operating point.<ref>{{cite journal | url = http://www.cord.edu/faculty/zhang/cs345/assignments/researchPapers/congavoid.pdf | title = Congestion avoidance and control | journal = ACM SIGCOMM Computer Communication Review | author1 = Jacobson, Van | author2 = Karels, MJ | year = 1988 | volume = 18 | issue = 4 | formatpages = PDF314–329 | doi = 10.1145/52325.52356 | url-status = dead | archiveurl = https://web.archive.org/web/20040622215331/http://www.cord.edu/faculty/zhang/cs345/assignments/researchPapers/congavoid.pdf | archivedate = 2004-06-22 }}</ref>

Regardless of bandwidth requirements, any type of a service which requires consistently low latency or jitter-free transmission can be affected by bufferbloat. ExamplesSuch services include digital voice calls (VOIP), online gaming, [[video chat]], and other interactive applications such as [[instantradio messagingstreaming]], [[video on demand]], and [[remote login]].

When the bufferbloat phenomenon is present and the network is under load, even normal web page loads can take many seconds to complete, or simple DNS queries can fail due to timeouts.<ref name="acm">{{cite journal |url=http://cacm.acm.org/magazines/2012/1/144810-bufferbloat/fulltext |title=Bufferbloat: Dark Buffers in the Internet |lastlast1=Gettys |firstfirst1=Jim |last2=Nichols |first2=Kathleen |publisher=ACM |date=January 2012 |seriesjournal=Communications of the ACM |pages=57–65 |volume=55 |issue=1 |doi=10.1145/2063176.2063196 |accessdate=2012-02-28|doi-access=free }}</ref> Actually any [[Transmission Control Protocol|TCP connection]] can timeout and disconnect, and [[User Datagram Protocol|UDP packets]] can get discarded. Since the continuation of a TCP download stream depends on acknowledgement (ACK) packets in the upload stream, a bufferbloat problem in the upload can cause failure of other non-related download applications, because the client ACK packets do not timely reach the internet server.

=== DiagnosticDetection tools ===

Several technical solutions exist which can be broadly grouped into two categories: solutions that target the network and solutions that target the endpoints. The two types of solutions are often complementary. The problem sometimes arrives with a combination of fast and slow network paths.

*[[Active Hybridqueue management|AQM and packet scheduling]] algorithms such as FQ-[[CoDel]] and [[PIE (queue management algorithm)|PIE]].<ref name=fq-codel"PIE">{{Cite webconference| last1 = Høiland-JørgensenPan| first1 = TokeRong| last2 = McKenneyNatarajan| first2 = PaulPreethi| last3 = TahtPiglione| first3 = DaveChiara| last4 = GettysPrabhu| first4 = JimMythili| last5 = DumazetSubramanian| first5 = EricVijay| last6 = Baker| first6 = Fred| last7 = VerSteeg| first7 = Bill| title = The2013 FlowQueue-CoDelIEEE Packet14th SchedulerInternational andConference Activeon QueueHigh ManagementPerformance AlgorithmSwitching and Routing (HPSR)| accessdatechapter = 2017-09-28PIE: A Lightweight Control Scheme To Address the Bufferbloat Problem| date = 2016-03-182013|series url= 2013 IEEE 14th International Conference on High Performance Switching and Routing (HPSR) | pages = https:/148–155| publisher = IEEE| doi = 10.1109/toolsHPSR.ietf2013.org/html/draft-ietf6602305| isbn = 978-aqm1-fq4673-codel4620-067}}</ref>

* Integration of queue management ([[FQ-CoDel]]) into the [[WiFiWi-Fi]] subsystem of the [[Linux]] operating system as Linux is commonly used in [[wireless access points]].<ref name=linux-wifi>{{Cite conference| publisher = USENIX - The Advanced Computing Systems Association| isbn = 978-1-931971-38-6| conference = 2017 USENIX Annual Technical Conference (USENIX ATC 17)| pages = 139–151| last1 = Høiland-Jørgensen| first1 = Toke| last2 = Kazior| first2 = Michał| last3 = Täht| first3 = Dave| last4 = Hurtig| first4 = Per| last5 = Brunstrom| first5 = Anna| title = Ending the Anomaly: Achieving Low Latency and Airtime Fairness in WiFi| accessdate = 2017-09-28| date = 2017| url = https://www.usenix.org/conference/atc17/technical-sessions/presentation/hoilan-jorgesen}} [https://www.cs.kau.se/tohojo/airtime-fairness/ source code].</ref>

For most end-users, the largest improvement can be had by fixing their home router.<ref name=fix-bloat>{{cite web|url=https://www.bufferbloat.net/projects/bloat/wiki/What_can_I_do_about_Bufferbloat/|title=What Can I Do About Bufferbloat?|work=bufferbloat.net|accessdate=26 October 2017}}</ref>{{sps|date=April 2020|certain=y}} Most of the technical fixes are included in recent versions of the Linux operating system and the [[LEDE|LEDE/OpenWrt]] aftermarket router firmware.<ref name=fix-bloat /> The problem may also be mitigated by reducing the buffer size on the OS<ref name=acm /> and network hardware; however, this is often not configurable and optimal buffer size is dependent on line rate which may differ for different destinations.

* {{youtubeYouTube|qbIozKVz73g|Google Tech Talk}} April, 2011, by Jim Gettys, introduction by Vint Cerf

* {{youtubeYouTube|npiG7EBzHOU|Bufferbloat: Dark Buffers in the Internet&nbsp;— Demonstrations Only}} April, 2011, by [[Jim Gettys]], introduction by [[Vint Cerf]]

* {{youtubeYouTube|-D-cJNtKwuw|Bufferbloat: Dark Buffers in the Internet&nbsp;— Demonstrations and Discussions}} 21 minute demonstration and explanation of typical broadband bufferbloat

* {{youtubeYouTube|uQ9ziQg_1zU|LACNIC - BufferBloat}} May 2012, by [[Fred Baker (IETF chair)]] in Spanish, English slides available [https://www.dropbox.com/sh/ihvbcuxfs2t8kp8/2xoXrlSeq9/Fred_Baker_LACNIC%20Wednesday.pptx]