A better solution would be to have a deep buffer (especially needed for bursts and temporary surges) that is kept shallow using AQM techniques. A small buffer can't be the right solution because when the queue fills an increased loss rate is generated, which shows up in timeout-driven retransmissions. Moreover, the excessive buffer might not be a problem inside the network, while it certainly is at the edge of the network including operating systems, home routers and broadband gear. Buffer size cannot be configured on most routers and switches. To solve this problem, there is no single right solution. As a result, services that require low latency, such as network gaming, VoIP, or chat programs, can slow to the point of becoming unusable. And the more packets are in the queue, the higher is the latency given that once the buffer is filled it takes time to drain and let in other packets. Considering that TCP's congestion-avoidance mechanisms rely on packet drops to detect congestion, a big buffer will be flooded with packets before any drops actually happen. While some buffering is needed in order to reduce loss, big buffers lead to higher delay and reduced throughput. Nowadays due to cheaper and cheaper memory, buffering is overdone in many network devices. Jim Gettys' hypothesis is that some recent developments have sneakily conspired to make this a common occurrence in practice, and that it is time to do something about this.

It has long been known that overly large buffers can lead to problems an early description of some of them is John Nagle's RFC 970: On Packet Switches With Infinite Storage from 1985.

Using tools like Smoke Ping and ICSI Netalyzr he found that all these major problems were caused by excessive buffering in the network. The term 'Bufferbloat' was coined by Jim Gettys, when spending much effort on attempts to understand why his home network was performing so poorly (1.2 seconds latency plus horrible jitter).

Using netbalancer to solve buffer bloat