Please measure bufferbloat

[Rich Brown]

It would be great to include the results from the DSLReports Speed Test http://www.dslreports.com/speedtest as a standard part of your Router test suite.

What's so great about that particular speed test? DSLReports measures latency during the test to detect bufferbloat - the undesirable latency that comes from the router buffering too much data. (Other speed tests measure a few pings before starting the test. Those don't tell very much about the router's performance.)

If the router's latency stays low during the test, that means that voice calls won't get choppy, gaming won't lag out, and general web and network usage will be snappy, even during heavy up and downloads.

 

[thiggins]

Thanks for the suggestion. But isn't any test using an internet connection going to include bufferbloat in the test path to/from the router as well?

 

[RMerlin]

Thanks for the suggestion. But isn't any test using an internet connection going to include bufferbloat in the test path to/from the router as well?

Correct. Buffer bloat can be introduced at any point along the route, including the client's own network interface (which has its own buffers). So, even testing a client behind a test router, with another test system on the WAN side would require precise testing of the two test systems at first.

My guess is, no mainstream router will have any buffer bloat prevention in place. Codel, the most popular prevention method, is only available with Kernel 3.3 or newer AFAIK.

 

[thiggins]

My guess is, no mainstream router will have any buffer bloat prevention in place. Codel, the most popular prevention method, is only available with Kernel 3.3 or newer AFAIK.

But there could be differences in buffer size, yes?

 

[RMerlin]

But there could be differences in buffer size, yes?

Yes. Some might use smaller buffers than others, which would help in scenarios where buffer bloats can be an issue. It won't be as efficient as a better queuing mechanism would be, but it could have positive benefits.

 

[Nullity]

AQMs like CoDel are the best and easiest solution to bufferbloat at this time. Dynamic queue size based on measured queueing delay instead of number of packets or buffer memory cap.

Bufferbloat at interior hops is possible, but the core internet attempts to have excess bandwidth, right? I read that QoS is not of interest to backbones for this very reason.

Bufferbloat at the edge is almost a guaranteed though, since most people buy a certain bitrate and when the ISP rate limits, bufferbloat happens.

 

[drawz]

Thanks for the suggestion. But isn't any test using an internet connection going to include bufferbloat in the test path to/from the router as well?

Not really. Try the dslreports test and you'll see the impact of saturating your connection on latency. Low latency is the key to any real-time application, like VOIP, gaming, and even web browsing.

When you enable QoS/AQM with fq_codel and set the bandwidth limits appropriately, you move the buffer problem from the modem & ISP to your router where you can actually control it. Ideally, the ISPs and modems would address this, but that's not where we are today. If you want to improve on the situation, you need to do it in your router.

OpenWrt with QoS/fq_codel keeps latency low and keeps your connection responsive regardless of what else is going on without needing to classify or rate limit individual applications/ports/IPs/etc.

This is truly revolutionary stuff. And if you can get the attention of router manufacturers, maybe they will start to address it on the retail side. Right now, the best solutions seem to be in 3rd party firmware like OpenWrt. As RMerlin noted, most manufacturers are stuck on old kerenels that don't support these features. Qualcomm Streamboost was doing it right in some versions - I think Zyxel's is one of the good ones.

 

[thiggins]

I know this is a passion among some. But I Skype and Facetime all the time and never see latency problems. I do encounter problems with video streaming, as do many others. Hence the focus on big buffers (and big CDNs).

Uptake on Streamboost has been minimal. The general public and therefore router manfs just don't see it as a big problem.

I'll poke at it and see what's up.

 

[Nullity]

If you are using less than ~80% of your bandwidth, QoS is unimportant.


My initial interest of traffic-shaping/QoS came when I learned that the inability to simultaneously saturate both your upload and download bitrates was not some natural limitation, but caused by bufferbloat and the additional 500ms+ delay it imparted to all outgoing TCP ACKs. Throw in some traffic-shaping (prioritize ACKs), and bam, problem solved. For me, RTT during a fully saturating egress stream improved from 600ms+ to 50ms just by enabling CoDel with no additional configuration.


If the only option was some overly complicated traffic-shaping algorithm that required lots of complex configuration then I would dismiss most of this as well. CoDel though... you just enable it, or choose an operating system (Linux/BSD) with it. Also though, bandwidth is becoming more and more plentiful, and honestly I see complex traffic-shaping configurations stealing your precious time away becoming much less popular simply because the cost of more bandwidth would be negligable by comparison.

 

[drawz]

I know this is a passion among some. But I Skype and Facetime all the time and never see latency problems. I do encounter problems with video streaming, as do many others. Hence the focus on big buffers (and big CDNs).

Uptake on Streamboost has been minimal. The general public and therefore router manfs just don't see it as a big problem.

I'll poke at it and see what's up.

It's fine if you're only doing one thing at a time that's not using all your bandwidth. But try to Skype/Facetime/game while you're online backup (e.g. Crashplan, iCloud, etc.) is running. Or try the same while several members of the household stream Netflix/Youtube in HD. Another good example is being on a conference call with VOIP while someone is streaming their presentation. Delays during those conversations mean you end up talking over each other.

The problem gets worse as bandwidth goes down (and buffers tend to stay the same), so if you have 100mbps up & down, you probably won't have an issue. On my 25/5 Comcast connection, it definitely matters. It's also worth noting that it's a bigger issue when you have multiple users in the same household.

Larger buffers in the modem/router/etc don't help with video streaming. Bufferbloat may effect these things too - if a packet does not arrive on time, the video will stutter. Buffering on the client PC usually insulates against this being a real world problem though.

The cable industry is starting to recognize this as DOCSIS 3.1 will have AQM with PIE built in (PIE is an alternative to fq_codel). This will help tremendously, but the roll out is taking forever. This is solvable today if you try.

 

[drawz]

Forgot to mention - Streamboost still relies on prioritization a bit too much. One of the great things about OpenWrt SQM/QoS is that this is not required at all. It Just Works (TM), regardless of what applications you're using.

 

[Rich Brown]

Thanks for the suggestion. But isn't any test using an internet connection going to include bufferbloat in the test path to/from the router as well?

Another way to think about it: Bufferbloat is undesired latency *at the bottleneck link*. Almost always, that's your connection through your provider to the Internet.

But if, deeper in the network, your provider (or their provider) is experiencing congestion, the bloat will move into their buffers/routers. There's nothing *you* can do about this, but all providers have monitoring in place to detect and mitigate those sorts of overloads.