On bufferbloat and shoulders of the giants

Is your internet connection slow?

Yeah yeah, you have connection with bandwidth of 7.2 Mbps but it sulks (no pun intended) and you wonder why.

The answer, mostly is, #bufferbloat [1]. In short, the data flows from Google+ to your computer sitting somewhere in the dark corner on the opposite side of the world, ‘packets’ of this data are stored and transmitted at each intermediate stop through which they are passed. The protocol used to communicate between your computer and a google server, and everything in between (the intermediate stops), is called TCP and that beast is pretty good at adapting to the best speed with which those two end points (your computer and the google server) can talk to each other.
The way TCP achieves that is – when google server sends a few thousand packets at a go with the maximum speed it has, your computer might be choking to cope up with the volume and it will start dropping the packets (UPDATE: and acknowledgements, hereafter referred to as ACK, are sent notifying the dropping ACK is sent on successful delivery of packets. Dropping is assumed if no ACK is received in a reasonable amount of time. For more technical details, see excellent comment from James Cape), and google server slows down sending packets accordingly.

Wondering where the problem is, then? Well, all those intermediate points – including servers, routers, your broadband ISPs, their servers, routers, your WiFi router and even the Network Card (NIC) on your computer – have ‘buffer’ to keep a large number of packets, before it could be processed/transmitted further. And that excessive buffering, is what the problem is, which defeats TCP adapting itself. +Jim Gettys was one mastermind who got irritated with the same, decided to investigate, zeroed in on the problem, created widespread awareness and coined the term #bufferbloat for it, towards the end of 2010.

Now the question is, how to fix it. Looks pretty simple – reduce the amount of buffer, right? Unfortunately, not quite. What is the standard size of the buffer to be used? If the size of the buffer is too small, slow connections suffer. If the buffer size is too large, fast connections suffer. What was needed is another algorithm, usually called Adaptive (UPDATE: corrected by Stuart Cheshire in comments) Active Queue Management. There were various attempts to find One True ™ algorithm independent of network/bandwidth/timing/buffer size/queue size, devoid of knobs for fine tuning.

Now, Kathleen Nichols and Van Jacobson (yes, /the/ Van Jacobson) have come up with an algorithm closest to that, called #CoDel [2]. The very first implementations of CoDel by +Dave Taht and +Eric Dumazet and are going into #Linux kernel now, along with similar implementations to #CeroWrt (based on #Linux ) for routers [3]. This is one of the pieces of solution to bufferbloat, not the only one, but definitely one in the right direction.

These extra ordinary people, today, are silently fixing tomorrow’s internet. And they deserve big props for that. All you technologists who didn’t get a chance to appreciate Nikola Tesla or Dennis Ritchie, here is your chance to do that for some of the real heroes of our time.

[1] http://gettys.wordpress.com/category/bufferbloat/
[2] http://queue.acm.org/detail.cfm?id=2209336
[3] http://lwn.net/Articles/496509/

Disclaimer: The descriptions of various technological aspects in this article are overly simplistic and may not be one hundred percent correct, please add a note or comment if you find an inaccuracy.