Almost eight months ago in my annual predictions column I made a big deal about Bufferbloat, which was the name Bell Labs researcher Jim Gettys had given to the insidious corruption of Internet service by too many intelligent network devices. Well I’ve been testing one of the first products designed to treat bufferbloat and am here to report that it might work. But like many other public health problems, if we don’t all pay attention and do the right thing, ultimately we’ll all be screwed.

At the risk of pissing-off the pickier network mavens who read this column, Bufferbloat is a conflict between the Internet’s Transmission Control Protocol (TCP) and various buffering schemes designed into network devices like routers and modems as well as into applications on PCs and mobile devices.

TCP was designed in the Bob Kahn and Vint Cerf era to support devices with very limited memory connected over links that maxed-out at around 50 kilobits-per-second.  Network reliability was paramount, trumping speed, the idea being that if there was an ABORT LAUNCH signal sent by the White House it had darned well better be delivered.  So flow control was very robust.

But then memory got cheaper, networks got faster, and we started sending new data types like Laverne & Shirley video streams that were intended to be delivered without interruption — something that had never been imagined for a best effort network like the Internet. Our method that eventually emerged for watching TV and other bandwidth-intensive Internet activities was through the clever use of datagram protocols and pre-buffering. Connect to Hulu for an episode of Glee (or to Netflix to watch Cliff Robertson in 633 Squadron as I did last night) and you can watch that buffer fill, making us wait half a minute or so in exchange for an implied guarantee that there will be no further stopping and starting once the video starts to play.

Yet pre-buffering often isn’t enough and the show stops for more buffering or even a change of network connections or speeds — that’s Bufferbloat.

Bufferbloat becomes a problem when you have a buffer in your application (say a video player) a buffer in your PC network connection, another in the router, and another still in your cable or DSL modem. Add to this at least one and sometimes two levels of Network Address Translation (NAT) and things start to get ugly. All that filling and emptying of buffers defeats TCP’s own flow control algorithms leading to the wholesale destruction of network connections that are so confused by cascading buffer effects they don’t even know they’ve been destroyed and so take even longer to be reestablished — up to seven seconds in cases I’ve measured at home.

The solution is to keep buffers as small as possible and to be looking constantly for network performance issues. That’s what happens in Cerowrt, experimental Open Source firmware for certain Netgear N600 routers that I’ve been testing. The N600 is one of the few routers in the market with Open Source software so it is an easy platform for experimentation. And having experimented now for several days I can report that it might even work.

I think my network is running better but there are no good benchmarks yet for this stuff. And to really show obvious effects we should all be running Cerowrt or its closed source counterparts.

One of the issues here is network speed. We need a new marketing term. Broadband connections that clock in excess of 20 megabits-per-second (mbps) yet carry with them latencies in excess of a second aren’t fast at all.  In practice, by turning on bandwidth shaping latency can be easily reduced but that comes at a bandwidth cost.  Your connection may be faster at 20 mbps but much snappier throttled back to 1-2 mbps. “Speed” has been stolen from us as a useful term.

In fact our fixation with Internet speed tests may well be hurting us all in this regard.

I know this problem is both real and within our capability to fix. Hopefully as modem and router manufacturers and network application vendors become more aware of these systemic issues they’ll do the right thing to minimize Bufferbloat in their new products.  The cable industry has already updated its DOCSIS spec to allow a CMTS (Cable Modem Termination System of course) to centrally control buffering in downstream cable modems.  Modems that support the change will probably be in stores later this year, though not broadly deployed for two years or more. This will reduce the bufferbloat problem (though not solve it; you need Active Quality Management for that).

In my example, this DOCSIS change (and a new modem for me) would take latency from 1.2 seconds down to around 100ms. One hundred milliseconds is still too much, but it’s a Hell of a lot better than where we are today.

And if we do nothing? My fear is that sections of the Internet will succumb to a sort of TCP standing wave, large files will become effectively untransportable and Cliff Robertson will never grace my Roku box again.