What is bufferbloat? Bufferbloat describes a buffer that’s so big as to be impractical. Why? After a certain amount of time, delivering a packet is pointless. Two examples come immediately to mind.
- A UDP packet for voice traffic is not useful if delivered in an untimely fashion. If the packet arrives hundreds or thousands of milliseconds late, it’s of no value. Therefore, deep buffers are not helpful in this situation.
- A TCP packet of any sort will be retransmitted by the sender if the receiver does not acknowledge receipt in a timely fashion. Overly deep buffers that hold a packet after the TCP acknowledgement timer has expired exacerbates the congestion problem. Instead of the packet traversing the congested link once, it’s now traversing the link twice: once after emerging from the deep buffer, and a second time due to the sender’s retransmission. Yuck.
Bufferbloat can occur at any point there is network congestion and a very large buffer configured. Service providers might configure large buffers in their networks to help with SLA compliance. Assuming the SLA is measuring what I would describe as “the wrong things,” packet delivery might take precedence over latency. In that case, an SP might buffer excessively to insure delivery, ignoring the inherent latency introduced by such a scheme.
But, the greatest bufferbloat concerns aren’t deep inside SP networks. Indeed, there are legitimate reasons for a service provider to buffer traffic in their cores — to handle bursts on a typically uncongested link, for instance.
Bufferbloat is felt most painfully in residential routers, where the connection from a fast home WiFi or gigabit Ethernet network meets a cable modem or DSL router with a much slower link to the ISP. Traffic inbound to the residential modem from the faster network can easily overwhelm the slower upstream link.
Large buffers that hold on to packets for hundreds or thousands of milliseconds during moments of congestion cause problems for applications like Skype, gaming, or DNS lookups that are (directly or indirectly) impacted by latency.
The bufferbloat problem is one of queue management — how to decide what gets buffered, for how long, and de-queued in what order. Enterprise network engineers would answer that question with traditional QoS tools like traffic classification, a variety of token bucket algorithms, and tail-drops.
However, Rich Brown, our guest on today’s podcast, points out that standard QoS techniques don’t necessarily resolve the bufferbloat problem. For instance, tail-drop can be useful but doesn’t resolve the problem of a bloated queue. And having a best-effort traffic queue isn’t a wonderful thing for all the traffic actually lumped together into that best-effort queue. Even for best-effort traffic, there’s a user experience to be considered.
Rich Brown chats with Ethan Banks about CoDel, an algorithm specifically designed to minimize the impact of bufferbloat. CoDel is not new. In fact, it’s been baked into the Linux kernel since May 2012. However, CoDel has not impacted the industry significantly as yet. Residential modem manufacturers deliver their products to market on close margins, and upgrading to more modern Linux kernels aren’t high on their list.
So, for the most part, fixing bufferbloat becomes an end user concern. One solution is OpenWrt, which supports CoDel for those consumers willing to use OpenWrt to replace the OS shipped by the vendor.
Rich and Ethan discuss CoDel in quite a bit more detail, explaining how it works, the head-drop principle, sojourn times, TCP ECN, and more. This is a nerdy look at how your modem handles buffering, and how you make your home networking experience better.
The CoDel Demonstration
In this show, Rich demonstrates in real-time how CoDel helps bufferbloat. Using his Skype voice session for us to listen to, he shows how voice quality suffers with a bloated buffer by saturating the link with netperf. Then he enables CoDel on his connection, and the quality improves dramatically. Note – it’s one of the best real-time demonstrations of technology in action I’ve ever heard.
Worth a Visit
Our thanks to Rich Brown for supplying us with many of these links.