But the Internet wouldn't have the chance to do such things if it weren't designed to accommodate real-time performance. And it's Danny Cohen whose fundamental contribution to the early shaping of the Internet Protocol ensured it had legs for those demanding real-time capabilities that are so sought after. Today's Internet reaps the rewards of that contribution.

In recent years Cohen has been involved developing gigahertz-speed packet-switched interconnect technology. His company, Myricom Inc.-from which he's retired-has been a step ahead of the industry's drive toward intracomputer switch-packet interconnect. Long before similar schemes like Infiniband poked their heads over the horizon, Myricom's interconnect technology, called Myrinet, had already been doing packet-based data movement at rates approaching 2 Gbits/second for a few years.

The Internet didn't start out with the real-time issue on the front burner. In 1974 Vinton Cerf and Bob Kahn published a paper entitled "A Protocol for Packet Network Internetworking." They described how to achieve a reliable connection over unreliable packet networks by using techniques like fragmentation and reassembly, sequence numbers, acknowledgments, timeouts, retransmissions and more. The priority was reliability.

The organization that drove early Internet efforts, the Advanced Research Projects Agency's Network Working Group, started implementing Transmission Control Protocol (TCP) as specified in that paper. As a member of that group, Cohen raised his concerns about it. At the time, Cohen was leading an Arpa-funded project to implement real-time communication (voice first and video later) over packet networks. Before that, he implemented real-time interactive flight simulations over the Arpanet. All that helped Cohen become familiar with the requirements for real-time applications.

"We discovered that in real-time communication timeliness is very important and reliability does not have to be perfect," said Cohen. "It's better to have low-delay voice interaction with few glitches than to have perfect sound with long delay."

TCP achieves reliability at the cost of timeliness, mainly by using timeouts and retransmissions that increase delays. That's OK for file transfers, especially of programs, or financial and other sensitive data-but not for real-time applications like interactive audio/video and flight simulation.

With that in mind, Cohen suggested that TCP be divided in two: an Internet part and the end-to-end part. The former would comprise only information that must be used by the Internet to deliver packets to their destinations; the latter would include what is needed by the end points, such as technology for reliability and flow control. That was done, and as a result it became possible to support real-time applications. The Internet got the name Internet Protocol; the end-to-end part remained TCP.

"The idea was to separate the things that you need on the way from the things that you only need at the end," said Cohen. "That's how we divided it. In retrospect it's so obvious. But at the time it took me a couple of years to get this idea across. Back then we were absolutely the exception doing real-time. Today so many things are real-time. It's hard to believe that at one time it wasn't even considered."

Cohen believes the Internet has the potential to scale up to even larger levels, with no major roadblocks ahead. The bottleneck today is the shortage of Internet multigigabit/second end-to-end connections-but this will be solved with time, he said. The move from megabits a second to gigabits a second is just another step in the evolution, as was the move from kilobits to megabits. Both accelerate the capabilities of the Internet and the demand for those capabilities.

Emerging technologies for packet-switched communications-like the upcoming Infiniband-will enable the use of packet communication technology in intracomputer (intrasystem) networking, not just for intersystem networking, in Cohen's view. There's a widespread feeling in the server realm that inside the computer the PCI bus has to be replaced with a packet-switching fabric. Today's processors run at speeds faster than PCI, so it is a bottleneck.

"PCI is really an eight-inch-long network bus," said Cohen. "The original PCI is running at 1.056 Gbits/s, so you can't do it in 33-MHz, 32-bit configurations of PCI. You must go to either 66 MHz or 64-bit or both."

Serial interconnects like Infiniband or Myrinet are needed to scale servers up to the next level. But will running multigigahertz-signal printed-circuit boards get difficult as bandwidths rise? Cohen said he thinks those physical issues are a matter of engineering, not a matter of invention. Up to a certain speed you can go on ribbon cables if they're short enough. Beyond that designs have to go to serial, he said. The trade-off is that the electronics for serialization is still expensive.