Internet Speed Isn't Everything
Don't get us wrong, speed is important. You have to have an Internet connection fast enough to do what you need and want to do. But let's insert a sense of perspective. Consider your Internet connection in the context of another utility--electricity. Just as you need a requisite number of volts from your power company, you also need a certain number of kilowatts to power your home or business. Speed is analogous to volts, and kilowatts are analogous to bandwidth (a.k.a. capacity). You need both, and the current mantra, "it must be infinitely fast," is not sensible.
Google's speed-demonic, second-guessing search algorithms, combined with Google's practice of using speed to rank sites, indicate that for Google faster is always better. The fact that the FCC uses the word "speed" eight times more often than "bandwidth" in its National Broadband Plan indicates that Washington policy makers agree that speed is paramount. But the FCC is in the business of overseeing bandwidth not speed.
Speed (i.e., response time) is governed by many factors, of which bandwidth is only one--and interestingly, as bandwidth increases, its effect on speed decreases. Network application/website responsiveness is most influenced by user-server distance, server response time, the performance of TCP in user and server computers, and an application's design. An FCC-regulated ISP cannot influence any of these response time factors, so the fact that the FCC uses the word speed interchangeably with (and prefers as shown below; click on the image for a closeup) the word bandwidth shows the agency does not fully understand Internet performance.
If bandwidth has a diminishing effect on transaction response time, then why would a consumer buy a high bandwidth connection? There are several good technical reasons why more bandwidth improves performance.
- Many applications open multiple TCP connections in parallel, so they can sum the performance of each individual TCP connection. Most browsers open 4 to 6 connections per web page. Multiple threads counteract the limits of the TCP delay-bandwidth product effect. But again there are diminishing returns with multi-threading.
- Some applications and services don't use TCP. Streaming video, for example, can be delivered without being encumbered by the TCP window mechanism. However, video is also being compressed more and more to reach the largest audience.
- Subscriber households often have multiple users as well as unattended machines connected to the Internet. Higher bandwidth supports the aggregate needs of multiple simultaneous users.
But is it always better to make everything go faster over the Internet? The answer is no, because speed comes at a cost. The cost may be monetary. For example, as a content owner, you can pony up tidy sums so your website delivers Google-like performance. And as a content consumer, you can pay more when Google's lickety-split pre-fetching algorithms download more data than you need to your mobile phone. At some point Google's propensity to pre-fetch more relative to what you see will affect fixed broadband service volume caps.
Speed also consumes energy. Think of the kilowatts consumed and the environmental costs from the coal, oil, gas, or plutonium required to power gigabit-per-second lines, interfaces, wave division multiplexers, routers, and so on. The cost of power and its role in speed is not lost on Google, which built a huge data center near one of the Bonneville Power Administration hydroelectric dams along the Columbia River specifically to take advantage of inexpensive electric power.
Major innovations begin life as new "gee-whiz" technologies, which need to scale with widespread adoption. With maturity, however, cost and sustainability become factors. Mark our words, people will talk about how to make the Internet more environmentally sustainable. Consider one of the greatest of innovations--the light bulb. Long after becoming ubiquitous, in the interest of energy conservation governments the world over now prohibit the sale of energy-hungry, incandescent light bulbs. Within 4 years they won't be sold the US.
We propose that the 'faster-is-always-better' mantra be replaced by something more sensible. The time has come to advance the discussion to include real-world requirements for application performance, and to sensibly weigh the tradeoffs needed to meet those requirements.
What do you think?