by Adam Sah
(originally appeared in Wired 1.6)
There has been an enormous amount of speculation lately about the future of internetworking, with particular emphasis of how the "data superhighway" will change all of our lives, creating a vast virtual environment with unlimited potential. The talk seems to hinge on the hype surrounding ATM and other "ultra-fast" networking technologies, many offering multi-gigabit bandwidths. The dream is to disconnect your physical location from your "virtual" location- to be able to work with colleagues in Silicon Valley from that beach in Maui.
Unfortunately, we are bumping up against the speed of light. While no one is contesting the seemingly unlimited bandwidth offered, the latency of these devices is still hindered by the medium. Latency is defined as the minimum time to perform the smallest operation. In the case of networks, it is usually measured as the time it takes one packet of data to get to your destination ("trip time"). Clearly, the lower bound of this latency is defined by the actual signals themselves, which currently travel at the speed of light.
To send a packet from here in California to New York (roughly 3000 miles) takes 1/60 second. Imagine a game program being played by two players, one of which is in New York and the other which is in California. If each computer needs information about the other's most recents actions, then such updates can only happen 60 times per second, which just keeps pace with the speed needed to draw the video screen. If we travel halfway around the world, this limit becomes 14.4 times per second, well below the acceptable limit.
In reality, the limit is set by slow software and hardware. Currently, intercontinental traffic can take 1/3 of a second or more. How bad is it? Try typing in an editor while remotely logged in from the other side of the country. The sluggishness you feel is due to network latency. Another good example is netrek, a distributed video game loosely based on Star Trek. Even on fast workstations, it is slowed down by remote players.
Clearly, there is still much room to grow. In current TCP/IP environments, much of the latency is in the software itself, which spends a lot of effort to handle operations like encoding and decoding of packets, fragmenting larger data into smaller packets, authentication and encryption checks, etc. With the increasing speed of the computers themselves, software latency is bound to drop.
The way we transmit data can also be improved. Currently, errors are treated via retransmission. Next-generation protocols will not concern themselves with bandwidth and instead will send error-correcting and/or duplicate data in separate packets, minimizing the need for retransmission.
Nonetheless, interactive telecommuting will be uncomfortable for many years to come, and for many applications it may not be viable in our lifetime. The inherent latency imposed by such vast distances limits us to applications that don't require instantaneous feedback- so remote surgery from Tokyo to Zaire is probably off limits, as would be remote virtual sports games between real users.
The optimistic side of things is that relatively short distance telecommuting is almost inevitable, and latencies will not be a problem- 100 mile telecommutes involve latencies less than 1/1000 of a second, opening the door for the entire gamut of virtual activities.
© 1993-2000 Adam Sah. This copyright pertains to all text contained as well as to material referenced from this page. Reproduction requires written consent of the copyright holder.