Too Much of a Good Thing
Imagine a supermarket checkout with a single queue. A customer with a full cart of 200 items gets in line just before you, who only has one item. You wait 10 minutes for something that should take 30 seconds. Now imagine the store has a "10 items or fewer" express lane. You go there instead, and you are done in 30 seconds regardless of how many items the person ahead of you has.
Bufferbloat is the networking equivalent of the single-queue supermarket. As RAM became cheap in the 2000s, router and modem manufacturers added enormous buffers — sometimes hundreds of megabytes — to prevent packet loss during traffic spikes. The intention was good: fewer dropped packets means fewer TCP retransmissions. The unintended consequence was catastrophic for latency-sensitive traffic.
How bufferbloat unfolds:
- You start a large file upload. Your packets fill the router's outbound buffer.
- The buffer is now hundreds of milliseconds deep in queued data.
- You start a VoIP call. Your VoIP packets arrive at the router and join the back of the queue.
- Instead of being dropped (which would signal TCP to slow down), the VoIP packets sit in the queue for 300–800ms before being transmitted.
- Your call sounds like you are talking through a tin can on the moon.
The insidious part: your ping to the router's LAN IP is still 1ms. The problem only manifests under load, which is why bufferbloat went undiagnosed for years. Standard idle-state network tests completely miss it.
Measuring bufferbloat:
The simplest test is the loaded ping test: measure latency under idle conditions, then measure it again while saturating the link. The difference is your bufferbloat penalty. A well-managed link should show less than 5ms of additional latency under full load. A bloated link may show 500ms or more.
Key Point: Large buffers prevent packet loss but replace it with latency. Under load, queuing delay can make a 20ms link behave like a 500ms link, destroying the user experience for real-time applications.