|
||
 |
||
| Ever stand on New York's Park Avenue at rush hour, in a rainstorm, and try to hail a taxi? I don't recommend it. You'll end up wondering why, with a zillion cabs in the city, you couldn't find just one. The same sort of frustrating inability to get what you want, when you want it, is recognized as a major problem for the World Wide Web—sometimes dubbed the World Wide Wait. But the answer that has been settled on, almost by acclamation, is akin to saying that the way to get you that cab before your shoes get ruined is to eliminate all speed limits while installing airplane jet engines on all the taxis in Manhattan. Never mind that the real issue is that the cabs can't maneuver easily on slick roads overburdened with traffic. Like uncontrolled, jet-propelled taxis, the proposed solution for the Internet isn't just a bad idea; it could be dangerous for all involved. The accepted approach to boosting the Internet's commercial potential is to increase bandwidth. That is, to widen (or make "broadband") the pipes through which users of the Internet send and receive data. Everyone from politicians to marketers to chief information officers is on the bandwidth bandwagon. MediaOne proclaims: "This is Broadband. This is the Way." Hughes's DirecPC satellite Internet service promotes high-bandwidth connections to the home at low cost. Bandwidth has even entered our common culture: I've overheard sales executives describing meetings as "high-bandwidth" interactions. But bandwidth is like a car's top speed. As boys in the ' 60s, we pored over every issue of Motor Trend. Cubic inches, horsepower, torque, and top speed were everything. We didn't worry whether the car could maneuver, whether it could stop quickly, how far it could run on a tank of gas. We didn't realize that designing a car around brute speed might eliminate more useful attributes. So it is with network service today. Communications companies, Internet access providers, companies selling cable modem access, and phone companies selling acronyms like ISDN and xDSL (don't ask) all promote bandwidth, leading customers to assume that bandwidth is the be all and end all. In fact, the one critical measure for a user is response time. The right questions for the thoughtful executive are: How long does it take for your customer's computer to display your Web home page? How long does it take to get to the next page on the site? To download an image? To find information? (While we're at it, how long does it take your customer-service people to respond to an inquiry on your Web site? Does it take minutes or hours—as it should—or days?) Equating bandwidth with performance can actually exacerbate the problem with response time. Here's why: If you pay for your Internet service in proportion to bandwidth—users currently are charged based on whether they're reaching the service provider over a regular modem, a cable modem, or a high-speed T1 line—you encourage the network provider to sell all its capacity. Any spare capacity is money the provider is leaving on the table. Users tend to take advantage of all the bandwidth at their disposal, so the network will operate at close to full capacity. And a heavily loaded network that encounters a problem produces response times that are like, well, Manhattan in a rainstorm at rush hour. The real answer for reducing response time, or latency, is to make it the primary measure of service that Internet access providers charge for. The providers will go ahead and build big pipes but will then manage their networks so people don't use all the capacity. If the network operators won't switch to latency measures on their own, then their customers must insist. Even if we all have to pay a premium, it'll be worth it because cutting response time is the right way to serve customers and employees better. You can ask your Internet service provider to put jets on your taxis, if you like. But I think the answer is to have a car waiting, with the engine idling, and to make sure you travel at a time when traffic is light from midtown to LaGuardia.
|
