How "Fast" is Broadband?

A perennial issue confronting the industry is determining the actual "speed" of broadband services. I put the word speed in quotes because, of course, we always express broadband in terms of capacity, not speed. Many believe that this is the same thing, but it's not. Overlooking this nit, it is a good time to look at the state of broadband, in terms of the "speed" experienced by end users. This is partly because government dump trucks are getting ready to haul $7.2 billion out to shovel-ready broadband projects, but also because the good people at Akamai have recently released their quarterly The State of the Internet, a rich trove of information concerning internet usage around the world.

One portion of the Akamai report that has been widely quoted in the mainstream media covers broadband speeds. The Q4/2008 report, for the first time, ranks countries by average speed: tiny, dense South Korea (surprise) is #1 at 15 Mbps, the US ranks 17th at 3.9 Mps (others of note include Japan at 7 Mbps, Canada at 3.8 Mbps, Germany at 3.8 Mbps, France at 3.2 Mbps, India at 0.8 Mbps China at 0.8 Mbps, and Syria at a blistering 0.3 Kbps). All interesting data and useful fodder for activist governments wanting to spend taxpayer money to fix things.

But being the type of person who insists on touching a plate the waitress has just warned me is hot, I had to wonder how Akamai is able to measure the capacity of networks that are downstream from their servers. So I asked them.

It appears that Akamai, who admittedly have access to more performance data than any CDN on the planet, deduces the capacity of broadband connections by the length of time required to serve files to IP addresses on the other side of those connections. You do that for every file transfer to every IP address in every country and, pretty soon, you have mountains of data to mine. But I was still confused.

Leaving aside the problem that these data points mix business and residential IP addresses, the bigger problem seems to be the assumption that there is nothing of interest between the Akamai server and the requesting IP address. And if, as figure 1 illustrates, the connection between A and B is dedicated to A then the time required to transfer a file will be an accurate measure of the speed, or capacity, experienced by B. But that is not the way these networks are constructed.

Even when server A is in relatively close proximity (a single router hop) to B there are two other layer two networks that must be traversed—the broadband aggregation network (typically Ethernet) and the broadband pipe itself (DSL, cable, fiber, wireless), as shown in figure 2.

As can be seen, these networks are used for purposes other than just the A-to-B file transfer. B may be simultaneously requesting files from other sources, creating congestion within the broadband pipe and the aggregation network. Further, other subscribers may be requesting files which will create additional congestion on the aggregation network. And this congestion is real; with so much high-value content (e.g., Netflix or Amazon movies) served up by highly reliably and deterministic CDNs (e.g., Akamai, EdgeCast, Level 3), the fact that end users still see such wide variation in speed is almost entirely due to congestion within the broadband network.

The reason the methodology employed by Akamai, while valuable in many regards, is flawed in measuring broadband speeds is that it assumes speed is the inverse of capacity even in congested networks. In the example shown in figure two, if the A-to-B and D-to-B file transfers are equivalent in size and overlap in time, A will assume that the broadband pipe serving B is half of its actual capacity. The C-to-D file transfer could further reduce A's perception of B's capacity even though it has nothing to do with B's broadband pipe.

This is why it is misleading and potentially inaccurate to treat speed and capacity as different sides of the same coin. If it really was speed ("how fast are bits moving?") we were measuring as opposed to capacity ("how many bits can be moved in one second?") the aforementioned methodology would be accurate. After all, even though traffic crawls over LA freeways at slightly-faster-than-walking speeds, the capacity (in terms of vehicles per hour) of those freeways is enormous.

So what does this mean?

First, while we don't really know the average "speed" of broadband connections around the world, the capacity of broadband networks is most likely higher than the Akamai report indicates. How much higher is impossible to determine.

Second, the primary problem is (most often) not the capacity of the broadband pipe but rather congestion within the overall broadband network. This congestion, while not deleterious to garden variety web browsing and emailing, severely hampers streaming video which, according to industry research firm IDC, will constitute slightly more than half of all downstream web traffic in the US by 2013.

Consequently, as we endeavor to "fix" broadband with the $7.2 billion in stimulus funding, let's not lose sight of the fact that these are complex and heavily congested networks. Simply upping the size of the broadband pipe may not yield the performance improvements everyone professes to want. For proof look no further than Japan. After more than a decade of economic stimulus spending, much of it focused on broadband networks and near-ubiquitous availability of 100 Mbps fiber-based consumer broadband services, Akamai reports that Japan posts an average downstream broadband rate of 7.037 Mbps. How could that be?