Summary

  • RFC 1152, published in April 1990, records a workshop on very-high-speed networks. David Clark argued that existing protocols could reach a gigabit per second if raw speed were the only requirement; the real design brief also included distance, many users and new services.
  • Other sessions followed the waiting: Keith Lantz described low-delay, synchronized multimedia; Craig Partridge examined the rising processor cost of remote calls; the Nectar project reported a host interface that delivered less throughput to applications than its communication boards could exchange.

A gigabit is an answer to one question

The workshop was sponsored by the Internet Research Steering Group, which sits within the Internet Research Task Force. Craig Partridge's report drew on session summaries reviewed by participants. It reads like a research meeting should: people disagreed, compared prototypes and asked what problem the fast link was actually meant to solve.

David Clark opened the implementation session with a bracing thought. Existing protocols, he argued, could run at a gigabit per second if reaching that rate were the entire goal. Network proposals carried other demands: long distances, large numbers of users and services such as reserved bandwidth. The choice of protocol followed the requirements, rather than a speed label. The report then moved through approaches from specialized protocol processors to clever implementations of existing protocols. It recorded working experiments alongside contested designs, with no single replacement announced for the old stack.

The applications session gave the number on the link a human destination. Keith Lantz described a “portable office”: access to the same services and collaborators from an office, home or distant site. Portability meant access, not just a light computer. Desktop conferencing in that picture would carry text, graphics, audio and video together. The streams could require very different bandwidths, generally low delay, and for some streams little jitter. They would also have to remain synchronized. A mouth that arrives well before its voice is a failure a gigabit label cannot talk away.

Lantz also pushed for adaptation when a path had less capacity, when the network became crowded, or when a user could tolerate a different video resolution. The same application might cross fast and slow sections. More bandwidth at one point would not make every point equally capable. The application had to decide how to continue when the path changed.

The processor got faster; the round trip kept its distance

In the distributed-systems session, Partridge brought the waiting problem down to the program. Computers were becoming faster, while the round-trip delay to another machine remained constrained by distance and the speed of light. A remote procedure call could therefore consume more and more processor instruction cycles in waiting. Running several calls in parallel helped throughput but left a dependent sequence waiting for each answer. Starting future work earlier could help only when the program knew what it would need.

He considered caching, with a comic sting: a large cache eventually needs to stay consistent with other caches, and the system may end up making synchronization calls to avoid ordinary calls. He favored combining work bound for the same machine into a larger operation. Other speakers argued for anticipation or different asynchronous programming styles. The report preserves these as competing approaches, which is more useful than a retrospective winner's medal.

The host itself supplied another bottleneck. The report's preliminary account of Carnegie Mellon's Nectar network said processes on its communication boards could exchange at 70 Mbps, while host processes were limited to roughly 25 Mbps by the VME interface. That comparison belonged to one prototype and one interface, but it showed where a fast network could lose its gains before reaching an application. Jeff Mogul looked ahead to the cost of moving packet data into a processor's cache and notifying the user process. The interface between wire and program was becoming a first-class part of the speed question.

The workshop did not leave behind a magic protocol. It left a more demanding brief. Measure the path to the user's task: the time to reach another machine, the synchronization of several streams, the capacity of the slow segment and the work required to deliver a packet to a process. The gigabit line was impressive. The application was still watching the clock.