The Bufferbloat Problem
Internet links have gotten faster and faster in recent years, helping to drive adoption of voice over IP (VoIP), video conferencing and other interactive applications. But sometimes, inexplicably, Internet connections slow to a crawl, and the quality of those applications suffer. People often mistakenly assume that they don’t have enough bandwidth. However, a more likely culprit is packet delay variation (jitter) caused by “bufferbloat.”
Table of Contents
Use the links below to jump to any part of this page.
Download This Guide as an E-Book
What Is Bufferbloat?
Bufferbloat is when your Internet slows to a crawl because too many packets queue up in buffers between you and the sites you are communicating with. Users experience high latency and/or jitter, even when they have a high bandwidth connection.
Applications that Typically Suffer from Bufferbloat
Bufferbloat is commonly a problem with these kinds of applications:
- voice calls
- video chats
- online gaming
- Internet browsing (when you see the spinning circle saying, “loading”)
- YouTube videos
- uploading large attachments
In particular, interactive or video applications are frequently afflicted by bufferbloat, because it takes a lot more data to use them. You are less likely to notice bufferbloat when downloading text, so it’s less likely to occur then.
How do I Know if I have Bufferbloat?
Sometimes other networking problems can look like bufferbloat, but it’s easy to diagnose. Go to DSLReports.com, hit the Speed Test tab and run the test. It gives your Internet service a letter grade from A+ to F as well as a bufferbloat grade.
Don’t use just any speed test site. The typical speed test, such as at www.speedtest.net, makes very short runs (after all, users want the results
in a hurry), which mainly fill up the buffers and then report a high speed—just what Internet service providers want. Very convenient for people to rush and buy your product based on speeds that you don’t actually deliver, particularly when using data-heavy applications like VoIP.
How do I Know if I have Buffer Bloat?
Sometimes other networking problems can look like buffer bloat, but it’s easy to diagnose. Go to DSLReports.com, hit the Speed Test tab and run the test. It gives your Internet service a letter grade from A+ to F as well as a buffer bloat grade.
Don’t use just any speed test site. The typical speed test, such as at www.speedtest.net, makes very short runs (after all, the user wants the speed answer in a hurry), which mainly fill up the buffers and then report a high speed—just what Internet service providers want. Very convenient for people to rush and buy your product based on speed that you don’t actually deliver.
What Causes Bufferbloat?
The Internet is changing, and the algorithms that controls speed—TCP congestion control algorithms—no longer works well due to routers now having large buffers.
How Improper Buffering Leads to Bufferbloat
Buffering plays an essential role in a well-performing network. If you think of the network as a highway, you can understand why: when traffic gets heavy, cars either have to pull over and wait or crash into the other cars that are already queued up. Buffering gives data packets a place to wait so they don’t “crash” and get lost. On the Internet, these crashed bits of data are resent.
Why Not Just Make the Buffers Bigger?
In our traffic metaphor, why not just make the highway bigger? Most highways sit virtually empty until rush hour hits. Networks are the same way, given the bursty nature of network traffic. Buffering maximizes the use of the available bandwidth by smoothing out the traffic flow.
There are some rules of thumb about how big to make the buffers—traditionally buffers were made to be able to handle about 250 milliseconds of traffic. By that measure, buffers must get bigger and bigger as the available bandwidth increases (and boy has it increased). They are so big now that it takes a very long time for them to fill up and thereby notify the sender that they should slow down; so long that sometimes senders decide they need to find a different network path!
The problem is compounded by the congestion control mechanisms built into TCP/IP. These algorithms are designed to slow down the data transmission rate when they see packets being dropped. But packets aren’t dropped until the buffers are filled, so the algorithms don’t respond appropriately to the congestion.
Quality of Service (QoS) settings don’t relieve bufferbloat very well. QoS prioritizes some traffic by putting it at the front of the queue, but all the traffic at the back of the queue still has to be sent eventually (otherwise lower priority traffic wouldn’t be sent at all). So the buffers stay full and delay is increased for all senders and priorities.
Additionally, QoS has to be configured and constantly updated because usage patterns change all the time. You can devote much time and money to keeping on top of this maintenance nightmare.
Why Hasn’t the Bufferbloat Problem Been Solved?
The purveyors of Internet access are caught up in a speed war—each declaring higher speeds, and proving it with speed tests than can be run from a browser.
The Internet scientist gurus have been mired in proposals for years. The problem was originally discussed in RFC 970 by John Nagle in December, 1985. The academics are only interested in providing a backwards-compatible algorithm that all Internet routers will adapt to in order to cure the problem. It is a difficult enough problem to get the entire Internet to adopt new router software and potential new routers.
The Internet service providers have no incentive to fix what they think is a non-problem; why would they want to watch their speed test scores drop? Plus, the mindset of the industry is that the way to fix any problem is to add more bandwidth, which can be sold as a new service, and at a higher profit.
These factors have stymied both the academic and industry paths to cure bufferbloat. That’s why InSpeed and a very few other vendors chose to tackle the problem. InSpeed’s solution is unique in that it fixes bufferbloat at the network edge and requires no changes to existing routers.
Other than InSpeed Quality Service, there are few solutions to bufferbloat. There is one good solution if your computers are running on Linux (or BSD). The primary module is CoDel (short for “controlled delay”), and an accompanying queuing algorithm, fq_codel (Fair Queuing Controlled Delay).
However, CoDel and fq_codel only fix bufferbloat in the upstream direction between your local network and the ISP’s access router. Any bufferbloat farther upstream or downstream is not fixed. This includes any nodes that your data encounters on the way to the site or data you are trying to download, as well as the destination server. For those unfamiliar with the way TCP works, these nodes are a random assortment of connections that could be computers on the other side of the world, or even other non-computer devices connected to the Internet. Essentially, these nodes have no connection to your router or your ISP. This is why, as terrific as CoDel is as a solution, it is also still extremely limited. InSpeed is the only known solution that fixes bufferbloat both upstream and downstream as well as the entire path from your local network to the cloud/end site.
You May Try This but We Don’t Recommend It
For Windows 7 or earlier, some have suggested Compound TCP. This is enabled by running this code:
netsh int tcp set global congestionprovider=ctcp netsh int tcp set global ecncapability=enabled
Or in Windows 8 or later, you would use
set-nettcpsetting -CongestionProvider CTCP
…instead. However, these are not going to impact your quality of service significantly, unless you are, for example, uploading large video files to the Internet across thousands of miles of ocean. They aren’t useful when going from a fast connection to a slow one, which is often the case when bufferbloat is a problem. Bufferbloat occurs most commonly when a fast network hits a slow network. Unfortunately your PC is fast and is connected to a fast network—so there is no Bufferbloat at that point. What the code above (CTCP) is doing is simply slowing the network for each PC using it. Furthermore, your computer can’t know what’s going on upstream at the modem or further up the network, so at times you’re slowing the network for no reason.
Returning to our traffic metaphor again, this would be like a traffic officer who slows everyone entering the onramp, all the time, even when there is no traffic. It will mean less traffic jams, but all the traffic will be slower.
Get a Specialized Router or Driver
There are specialized modems made for gamers, that favor game traffic while slowing everything else down. And you may be able to purchase updated drivers for your PC, which have the same effect.
Furthermore, keep in mind that whatever solution you find must be applied to all the devices that are being affected by bufferbloat. For that reason, companies with many locations or with VoIP phone systems (for example), getting specialized routers or drivers is not as simple a solution as it seems.
Fix Bufferbloat Forever
Not all Internet slow-down issues are as complex and difficult to solve as bufferbloat. (See our Common VoIP Problems page for troubleshooting other network connectivity issues.) We hope the detail provided on this page clearly explains why this is not a problem you can fix by rebooting, resetting, or rebuying any of your various devices. Nor is it a problem that will be solved by changing Internet service providers.
Bufferbloat is one of the challenges we sought to tackle in offering the next generation in enterprise communications.
InSpeed uses a variety of techniques to preserve quality for interactive applications—voice & videoconferencing—as well as ordinary office software (e.g. web browsing, SalesForce, Office 365, etc.).
Of course, InSpeed makes use of CoDel. But we also have two patents pending on our unique code that:
• measures latency downstream and upstream and
• uses changes in latency to detect bufferbloat.
As latency increases, Inspeed makes small, managed discards to decrease bufferbloat. Because we’re checking the connection from end to end, we can see bufferbloat building up sooner, and react before it becomes a problem.