Where Wizards Stay Up Late (9 page)

And in another daring episode, Roberts and Kleinrock cooked up a plan to cash in on the physics of roulette. The idea was to predict, employing rudimentary laws of motion, just when the ball would fall off its trajectory. To do this, they needed to know the speed of the ball, which traveled in one direction, and the speed of the wheel, which traveled in the other. They decided to build a small machine that would make the predictions, but they needed a little data. So Roberts got a tape recorder, put a microphone in his hand, and made a cast that made it appear he had a broken wrist. The two sat down at the table and Roberts placed his hand next to the wheel to record the sound of the passing ball, from which they could later extrapolate its speed. Kleinrock's job was to distract the pit boss by playing several rounds of roulette. “Everything was working fine except for one thing,” Kleinrock said. “I started winning. It drew attention to me. The pit boss looks over and sees this guy with a broken arm with his hand near the roulette wheel, and he grabs Larry's arm and says, ‘Let me see your arm!'Larry and I made fast tracks out of there.”

•   •   •

Roberts agreed with Taylor that fast response time for the network was critical, because a low message delay time was crucial to interactivity. Anyone who had used time-sharing systems that passed data over standard communications lines knew how sluggish they could be. Data traveled to and from the main computer at excruciatingly slow rates of a few hundred bits per second. Retrieving or sending even a small amount of information was a process that left plenty of time to pour yourself a cup of coffee, or even brew an entire pot, while the modem churned away. No one wanted a sluggish network.

During an early meeting of the loose group of advisors Roberts had assembled, someone banged his fist on the table and said, “If this network can't give me a one-second response, it's no good.” Optimistically, a half-second response time was written into the requirements. The second priority, of course, was reliability. If a network was to be effective, users needed complete confidence in its ability to send data back and forth without snafus.

Another source of consternation was the question of how the network would be mapped out. Several people had proposed that the resource sharing be done on a single centralized computer, sitting in, say Omaha, a popular place for long-distance telephone switches because it lay at the nation's geographic center. If centralization made sense for a telephone network, why not for a computer network? Perhaps the network should use dedicated phone lines—a question that was still unresolved—which would help keep costs uniform. Baran had avoided a centralized system because that increased its vulnerability. Roberts, too, was opposed to a centralized approach, but decided to delay his final decision until he could bring up the topic with a large group. His chance came soon, at a meeting for ARPA's principal investigators in Ann Arbor, Michigan, in early 1967.

Taylor had called the meeting, and the principal item on the agenda was the networking experiment. Roberts laid out his initial plan. The idea, as he described it, was to connect all of the time-sharing computers to one another directly, over dial-up telephone lines. The networking functions would be handled by the “host” computers at each site. So, in other words, the hosts would do double duty, as both research computers and as communications routers. The idea was greeted with little enthusiasm. People from the proposed host sites foresaw no end of trouble. No one wanted to relinquish an unknown portion of valuable computing resources to administer a network about which they were hardly excited. Then there were dozens of idiosyncratic variations to cope with, not the least of which was the fact that each machine spoke a language substantially different from the others. It seemed nearly impossible to standardize around one set of protocols.

The Ann Arbor meeting revealed the lack of enthusiasm, if not downright hostility, to Taylor and Roberts's proposal. Few ARPA principal investigators wanted to participate in the experiment. This attitude was especially pronounced among researchers from the East Coast universities, who saw no reason to link up with campuses in the West. They were like the upper-crust woman on Beacon Hill who, when told that long-distance telephone service to Texas was available, echoed Thoreau's famous line: “But what would I possibly have to say to anyone in Texas?”

Douglas Engelbart, a computer scientist at Stanford Research Institute (SRI) in 1967, remembered the meeting clearly. “One of the first reactions was, ‘Oh hell, here I've got this time-sharing computer, and my resources are scarce as it is.' Another reaction was, ‘Why would I let my graduate students get sucked off into something like this?'” Nonetheless, it quickly became clear just how serious Roberts was. First he tried to allay the skepticism about resource-sharing by pointing out that everyone had something of interest on his computer that others might want. “I remember one guy turning to the other and saying, ‘What have you got on your computer that I could use?'” Engelbart recalled, “And the other guy replied, ‘Well, don't you read my reports?'” No one was taken with the idea. “People were thinking, ‘Why would I need anyone else's computer when I've got everything right here?” recalled Jon Postel, then a graduate student at UCLA. “What would they have that I want, and what would I have that I want anyone else to look at?”

An even more difficult problem lay in overcoming the communications barriers between disparate computers. How could anyone program the TX-2, for instance, to talk to the Sigma-7 at UCLA or the computer at SRI? The machines, their operating systems, their programming languages were all different, and heaven only knew what other incongruities divided them.

Just before the meeting ended, Wes Clark passed a note up to Roberts. It read, “You've got the network inside out.” Roberts was intrigued, and he wanted to hear more; however, the meeting was breaking up, and people were already leaving. Roberts, Taylor and a few others huddled around Clark afterward, and a small group decided to continue the discussion during the ride back to the airport. In the car, Clark sketched out his idea: Leave the host computers out of it as much as possible and instead insert a small computer between each host computer and the network of transmission lines. (This was, by coincidence, precisely what Davies had concluded separately in England.)

The way Clark explained it, the solution was obvious: a subnetwork with small, identical nodes, all interconnected. The idea solved several problems. It placed far fewer demands on all the host computers and correspondingly fewer demands on the people in charge of them. The smaller computers composing this inner network would all speak the same language, of course, and they, not the host computers, would be in charge of all the routing. Furthermore, the host computers would have to adjust their language just once—to speak to the subnet. Not only did Clark's idea make good sense technically, it was an administrative solution as well. ARPA could have the entire network under its direct control and not worry much about the characteristics of each host. Moreover, providing each site with its own identical computer would lend uniformity to the experiment.

The most curious thing about the idea was that Clark thought it up. He hadn't been paying much attention to the proceedings in Ann Arbor. In fact, he was a bit bored by it all. He had already told Roberts in no uncertain terms that he had no desire to put his computer at Washington University in St. Louis on the network. Clark was not friendly toward time-sharing, or even resource-sharing. He had been working on computers designed for individual use and saw no particular reason to share his facility with people on a network. But when he heard the discord over how the ARPA experiment should be deployed, he couldn't help but hazard a suggestion. Perhaps it was Clark's antipathy toward time-sharing that enabled him to think of this. By assigning the task of routing to the host computers, Roberts and others were essentially adding another time-sharing function. Clark's idea was to spare the hosts that extra burden and build a network of identical, nonshared computers dedicated to routing.

During the ride to the airport, the discussion turned lively. Wouldn't an entire subnetwork composed of individual computers be prohibitively expensive and defeat the original goal of saving money? And who, Roberts wanted to know, did Wes Clark think could build such a thing? “There's only one person in the country who can do that,” Clark responded. “Frank Heart.”

Larry Roberts knew Frank Heart. The two had worked together at Lincoln Lab, and Roberts had shared an office with Heart's wife, Jane, a programmer at Lincoln. Roberts and Heart had never worked together directly, but Roberts knew Heart to be an exacting systems engineer. He was an expert in real-time systems built for when the physical world demands a response within fractions of seconds—or at least before the next set of data arrives. Anything dealing with incoming information in a time-critical fashion, such as radar tracking data sent to the SAGE system, and seismic information generated during an earthquake, was considered a real-time system, and in the 1960s few people understood real-time systems as well as Heart did.

Roberts also knew that Heart and Clark were good friends from Lincoln, where Heart had shown Clark the ropes of programming more than a decade earlier. Now, as far as Roberts knew, Heart was at Bolt Beranek and Newman in Cambridge, where he had moved in 1966 to work on the use of computers in medicine.

The ARPA network wasn't intended as a real-time system, not in the same sense of the word that true real-timers understand it. (Anything that takes more than 10 to 20 milliseconds, the point at which delays become humanly perceptible, is not considered real-time.) Strictly speaking, the ARPA network was to be a store-and-forward system. But data would zip in and out of the nodes so quickly, and the response time from a human perspective would be so rapid, that it qualified as a real-time problem. The system would have to cope with dozens of problems involving closely sequenced events and extremely tight timing. The status of the network would change constantly, and whoever programmed the computers that composed Clark's proposed subnet would need to know how to make the system handle incoming and outgoing data reliably at very fast rates.

Despite the logic of Clark's recommendation, however, Roberts couldn't simply turn the job over to Heart. ARPA had to play by the government's contracting rules. Over the years, most proposals requesting funding arrived at ARPA unsolicited. Seldom had the agency actually requested proposals. But this one was different. The agency had come up with the network idea internally, and in that respect it was unusual. Also, because the network would be government property controlled centrally by ARPA and wouldn't reside on one campus, say, or at one research firm, Roberts and others decided they had to send this project out for competitive bids.

When he returned to Washington, Roberts wrote a memorandum describing Clark's idea and distributed it to Kleinrock and others. He called the intermediate computers that would control the network “interface message processors,” or IMPs, which he pronounced “imps.” They were to perform the functions of interconnecting the network, sending and receiving data, checking for errors, retransmitting in the event of errors, routing data, and verifying that messages arrived at their intended destinations. A protocol would be established for defining just how the IMPs should communicate with host computers. After word of Clark's idea spread, the initial hostility toward the network diminished a bit. For one thing, a separate computer to carry out the switching functions removed the burdensome kludge (a kludge is an inelegant solution to a technical problem) that could result from adding those functions to the host computer. People also saw it as a way of getting another computer to play with.

At the end of 1967 another computer conference, this one in Gatlinburg, Tennessee, helped advance the network plan. This symposium was sponsored by the Association for Computing Machinery, the oldest and most prestigious of professional organizations for the growing computer industry. Though small in number, the attendees represented the highest levels of the computer science establishment.

Gatlinburg was a perfect venue for Roberts to present his first paper on what he called the “ARPA net.” In his presentation, Roberts focused on the reasons for the network and described the subnet of IMPs, but said little else about how the network would actually work. One big puzzle still to solve was the question of how the data would actually be transmitted—over what kind of channel. Ever mindful of cost, Roberts closed his presentation with a brief discussion of what he called “communication needs.” He was thinking of using the same type of telephone lines that he and Marill had used for their small TX-2 experiment: full-duplex, four-wire lines. Talk of the matter ended on a note of frustration. Ordinary dial-up phone lines (as opposed to dedicated, leased lines) were slow, and holding a line open was wasteful. Roberts still hadn't found a highly efficient means of carrying the data.

Whereas the Ann Arbor meeting months earlier had been the intellectual equivalent of a barroom brawl, Gatlinburg was high tea. People were politely coming around to the idea of a network. Roberts's presentation was generally well received, even greeted enthusiastically by some.

Another paper was presented by Roger Scantlebury. It came from Donald Davies' team at the National Physical Laboratory and discussed the work going on in England. His paper presented a detailed design study for a packet-switched network. It was the first Roberts had heard of it. Afterward, Roberts and a few others approached Scantlebury, and they began to discuss the NPL work. The discussion continued at the hotel bar and went late into the night. Scantlebury raised the issue of line speed with Roberts. He said that he and Davies were planning to use lines that operated much faster than the 2,000 bits per second speed Roberts was proposing. He suggested Roberts build the ARPA network with fewer lines carrying data at speeds more than twenty times higher to improve the response time.