by Matthew Lyon
The computers themselves were extremely egocentric devices. The typical mainframe of the period behaved as if it were the only computer in the universe. There was no obvious or easy way to engage two diverse machines in even the minimal communication needed to move bits back and forth. You could connect machines, but once connected, what would they say to each other? In those days a computer interacted with the devices that were attached to it, like a monarch communicating with his subjects. Everything connected to the main computer performed a specific task, and each peripheral device was presumed to be ready at all times for a fetch-my-slippers type of command. (In computer parlance, this relationship is known as master-slave communication.) Computers were strictly designed for this kind of interaction; they send instructions to subordinate card readers, terminals, and tape units, and they initiate all dialogues. But if another device in effect tapped the computer on the shoulder with a signal that said, “Hi, I’m a computer, too,” the receiving machine would be stumped. The goal in devising the host-to-host protocol was to get the mainframe machines talking as peers, so that either side could initiate a simple dialogue and the other would be ready to respond with at least an acknowledgment of the other machine’s existence.
Steve Crocker once likened the concept of a host-to-host protocol to the invention of two-by-fours. “You imagine cities and buildings and houses, and so forth, but all you see are trees and forest. And somewhere along the way, you discover two-by-fours as an intermediate building block, and you say, well, I can get two-by-fours out of all these trees,” Crocker recalled. “We didn’t have the concept of an equivalent of a two-by-four, the basic protocols for getting all the computers to speak, and which would be useful for building all the applications.” The computer equivalent of a two-by-four was what the Network Working Group was trying to invent.
In conceiving the protocol, the NWG members had to ask themselves a few basic questions. What form should the common base take? Should there be a single, foundational protocol on which to build all application protocols? Or should it be more complex, subdivided, layered, branched? Whatever structure they chose, they knew they wanted it to be as open, adaptable, and accessible to inventiveness as possible. The general view was that any protocol was a potential building block, and so the best approach was to define simple protocols, each limited in scope, with the expectation that any of them might someday be joined or modified in various unanticipated ways. The protocol design philosophy adopted by the NWG broke ground for what came to be widely accepted as the “layered” approach to protocols.
One of the most important goals of building the lower-layer protocol between hosts was to be able to move a stream of packets from one computer to another without having to worry about what was inside the packets. The job of the lower layer was simply to move generic unidentified bits, regardless of what the bits might define: a file, an interactive session between people at two terminals, a graphical image, or any other conceivable form of digital data. Analogously, some water out of the tap is used for making coffee, some for washing dishes, and some for bathing, but the pipe and faucet don’t care; they convey the water regardless. The host-to-host protocol was to perform essentially the same function in the infrastructure of the network.
Designing the host-to-host protocol wasn’t the only job before the group. The NWG also had to write the network applications for specific tasks such as transferring files. As the talks grew more focused, it was decided that the first two applications should be for remote log-ins and file transfers.
In the spring of 1969, a few months before Kleinrock and the UCLA host team were expecting to receive the first IMP, a thick envelope arrived from Cambridge. The guys at UCLA had been anticipating it. Inside the package was BBN Report 1822, the newly written set of specifications for connecting host computers to the soon-to-be-delivered IMPs. The ARPA network finally seemed to be coming into place.
After months of guessing, the UCLA team now learned what it was expected to do to get its site ready and build its hardware interface. BBN Report 1822 also instructed the sites in creating a piece of software called a device driver—a collection of code and tables for controlling a peripheral device—to operate the host-to-IMP interface. And, finally, BBN’s issuance of the specifications clarified the boundary between the IMP and the host. It was clear that BBN planned to include no special software in the IMP for performing host-to-host communication. That problem would be left, once and for all, to the host computer and, thus, to the NWG.
This meant a lot of summertime work for the students in Los Angeles. They thought they might be able to finish building the host-to-IMP interface in time. But writing the host-to-host protocol had already stalled Crocker, Cerf, and the entire Network Working Group for months. Rather than try to rush something out in time, they decided to tell every site to patch together its own makeshift protocols for the time being.
UCLA asked technicians at Scientific Data Systems, makers of the Sigma-7, to build the interface hardware for their host-to-IMP connection. The company’s response was discouraging: It would take months and probably wouldn’t be finished in time for the IMP’s arrival. Moreover, the company wanted tens of thousands of dollars for the job. So when a graduate student named Mike Wing-field asked for the job, he got it. And why not? Wingfield was a whiz at hardware and had just finished building a complex graphics interface for another computer.
BBN’s specification for the host-to-IMP interactions and connections was a splendid blueprint. A cookbook of sorts, written by Bob Kahn in crystalline prose, the document was accompanied by detailed diagrams. Kahn’s specification gave Wingfield the basic requirements for mating the Sigma-7 to an IMP. Almost before Wingfield knew it, the summer had flown by and the interface had been built without a hitch.
One week before the IMP was scheduled to arrive on September 1, Wingfield had the hardware finished, debugged, and ready to connect to the IMP. Crocker was so impressed he described it as a “gorgeous” piece of work. But, trying to get the communications software done, Crocker was running behind. He had a tendency to procrastinate anyway, and the absence of the actual IMP had only encouraged this tendency.
Now, like anyone trying to outsmart a deadline, Crocker looked at the calendar and did a few calculations. He counted on having at least one extra day, since September 1 was Labor Day. Moreover, he had heard BBN was having some troubles with the IMP’s timing chain. Synchronizer bugs were horribly nasty. Their bug was his good fortune, and with a little luck it might even buy him an extra week or two, he thought. So he was more than mildly surprised when Len Kleinrock told him that BBN was about to put the IMP on an airplane due to arrive in Los Angeles on Saturday, August 30, two days early.
In Cambridge, Frank Heart was preoccupied with the question of how best to ship the IMP to UCLA. After debating for a couple of days, Heart decreed that it should go by air, and that Ben Barker should go with it. A commercial flight was out of the question. The modified Honeywell 516—now officially BBN Interface Message Processor Number One—was just too big for the cargo bay of a passenger plane. It had to go out by air freight. Had Heart been able to, he would have put Barker straight into the cargo plane’s hold with his wrist handcuffed to the IMP. Never mind that he had chosen the machine precisely because it was battle-hardened; the rigors of combat were nothing compared to the punishment airline freight handlers could dish out. “He wanted somebody to be there, yelling at the cargo people to make sure they weren’t careless with it,” Barker recalled. But Barker would have to travel separately on a commercial passenger flight. Truett Thach, a technician in BBN’s Los Angeles office, would be told to meet the plane.
Once the IMP was crated, Barker took a red Magic Marker and in large letters wrote DO IT TO IT TRUETT on the side of the crate. It was loaded onto an early-morning flight out of Boston’s Logan Airport, and Thach was there to meet it at LAX that afternoon. When he arrived, accompanied by a freight mover, he was relieved to watch the crate come o
ff the plane but appalled when he noticed that Barker’s message to him was upside down. “Somewhere along the way, the IMP had been inverted an odd number of times,” he observed. Thach had the shippers right the box before loading it on their truck. Then he followed them to UCLA.
It was the Saturday before Labor Day and Thach noticed the streets were unusually quiet all the way through Westwood and onto the campus. Barker was already waiting on the loading dock at Boelter Hall with about a dozen other people—Kleinrock, Crocker, Postel, Wingfield, Vint and Sigrid Cerf, and a handful of curiosity seekers. The Cerfs had brought along some champagne. Immediately upon seeing the crate, someone raised a question as to whether the crate would fit into the elevator; the IMP was unpacked so it could be wedged in.
When the machine was removed from the crate, the welcoming party was surprised by its size. Though smaller than the Sigma-7, it was not a small device. It was roughly the size of a refrigerator, weighing more than nine hundred pounds, and was formidably encased in battleship-gray steel, exactly to military specifications. There were four steel eyebolts on top of the IMP for lifting it onto a ship by crane or helicopter. At UCLA the IMP was like a soldier in combat fatigues crashing a faculty party.
When the elevator reached the third floor, the freight movers wheeled the machine down the hall and around the corner to its new home in room 3400. The Sigma-7 hummed nearby, oblivious to the massive disturbance that was about to invade its privacy. “It was a little like seeing your parents invite to dinner someone you’ve never met,” Crocker said. “You don’t pay much attention until you discover they actually intend to marry you off to this stranger.”
Thach and Barker spent a few minutes cabling the IMP and powering it. Instantly the machine’s core memory knew just what to do: It picked up just where it had left off in Cambridge, running the diagnostics that the IMP Guys had written for it. Next, Mike Wingfield attached his interface. Since this was node number one, there wasn’t a network per se on which to test it. But Barker could do shunting experiments between the Sigma-7 and the IMP as they had done many times at Moulton Street between machines to simulate network links. Within an hour the Sigma-7 and the IMP were passing data back and forth as if they had been doing so for years.
Barker was still not absolutely certain that the synchronizer problem had been solved. But he was confident enough to consider going home. That night, Barker called Heart. “We’re done, it’s all working,” he said. “It’s talking to Mike’s [Wingfield] stuff. I’m thinking of getting a flight home in the morning.”
Heart paused, and Barker sensed what might be coming. “Why don’t you just hang out there a few days?” Heart responded. “Just to see if something goes wrong.” Barker spent three days relaxing with Thach, touring Los Angeles, and waiting for the IMP to crash. It didn’t.
A Real Network
A month after the first IMP was installed at UCLA, IMP Number Two arrived at SRI, right on schedule on October 1, 1969. That same month, Bob Taylor left ARPA. He had long since removed himself from the details of the network project. As he explained it, in the 1960s, “ARPA” was a magic word. Taylor’s office was often called upon to sort out problems that others couldn’t. In 1967 and 1968, Taylor had been sent repeatedly to Vietnam to help straighten out, among other things, the controversy over the Army’s “body count” reports handled by the military information centers. The experience had left Taylor burned out. He took a post at the University of Utah.
Many milestones in the network experiment had been passed so far: Taylor’s funding victory and successful wooing of Roberts; Roberts’s network concept; BBN’s construction and delivery of the first IMP. But the installation of IMP Number Two marked the most important achievement to date. At last the researchers could connect two disparate computers and get them talking to each other like a couple of old comrades.
Like the UCLA team earlier, SRI’s group had a similar mad scramble getting ready for the arrival of the IMP. One crucial difference between the two sites was that whereas the UCLA guys disliked their Sigma-7, the SRI guys loved their host computer, an SDS 940. Like the Sigma-7, the 940 was built by Scientific Data Systems. But the Sigma-7 had been designed as a commercial processor, whereas the 940 was basically an academic device, a revolutionary time-sharing system first put together by a team of Berkeley researchers, later to be sold under the SDS nameplate. As a result, it was far more fun to program than the Sigma-7.
Bill Duvall, an SRI researcher, spent about a month writing a clever program for the 940 that essentially fooled it into thinking it was communicating not with another computer but with a “dumb” terminal. A dumb terminal can neither compute nor store information; it serves only to display the most recent set of information sent to it by the computer to which it’s linked. Duvall’s program was a very specific interim solution to the host-to-host communication problem. For weeks, the UCLA researchers had been preparing for their first log-in session by actually dialing into the SRI system long-distance using a modem and a teletype, to familiarize themselves with SRI’s time-sharing system. With both IMPs now in place, and both hosts running, the moment to test the actual two–node ARPA network had finally arrived.
The first thing to do, of course, was to connect. Unlike most systems today, which prompt the user for a log-in name and password, the SRI system waited for a command before acknowledging a connection. “L-O-G-I-N” was one of those commands.
Fastened to the first IMPs like a barnacle was a small phonelike box, with a cord and headset. It shared the line with the IMPs and used a subchannel intended for voice conversations. The voice line was, like the data line, a dedicated link. A few days after the IMP was in place at SRI, Charley Kline, then an undergraduate at UCLA, picked up the telephone headset in L.A. and pressed a button that rang a bell on the IMP in Menlo Park. A researcher in Engelbart’s group at SRI answered it. It was somehow more thrilling to Kline than dialing a regular telephone.
The quality of the connection was not very good, and both men were sitting in noisy computer rooms, which didn’t help. So Kline fairly yelled into the mouthpiece: “I’m going to type an L!” Kline typed an L.
“Did you get the L?” he asked. “I got one-one-four,” the SRI researcher replied; he was reading off the encoded information in octal, a code using numbers expressed in base 8. When Kline did the conversion, he saw it was indeed an L that had been transmitted. He typed an O.
“Did you get the O?” he asked.
“I got one-one-seven,” came the reply. It was an O.
Kline typed a G.
“The computer just crashed,” said the person at SRI. The failure came thanks to a clever bit of programming on Duvall’s part. Once the SRI machine recognized the letters L-O-G, it completed the word. “I think that is where the bug was,” Kline recalled. “When the SRI 940 system received the G, it tried to send back “G-I-N,” and the terminal program wasn’t ready to handle more than one character at a time.”
Later that day they tried again. This time it worked flawlessly. Crocker, Cerf, and Postel went to Kleinrock’s office to tell him about it so he could come see for himself. Back in the UCLA lab Kline logged on to the SRI machine and was able to execute commands on the 940’s time-sharing system. The SRI computer in Menlo Park responded as if the Sigma-7 in L.A. was a bona fide dumb terminal.
There is no small irony in the fact that the first program used over the network was one that made the distant computer masquerade as a terminal. All that work to get two computers talking to each other and they ended up in the very same master-slave situation the network was supposed to eliminate. Then again, technological advances often begin with attempts to do something familiar. Researchers build trust in new technology by demonstrating that we can use it to do things we understand. Once they’ve done that, the next steps begin to unfold, as people start to think even further ahead. As people assimilate change, the next generation of ideas is already evolving.
A network now existed. The f
irst ARPA network map looked like this:
IMP Number Three was installed at UC Santa Barbara on November 1. For the Santa Barbara installation, Barker flew out to California again. By this time, Heart was more relaxed. There were few traces of the suspense that had attended the first trip. In fact, installing IMPs was beginning to seem routine.
Later that month, Larry Roberts decided to fly to California to inspect the network firsthand for the first time. Roberts didn’t like to travel. When he did travel, he never left to catch his plane until the last minute. It drove his secretary crazy, but he missed only one plane that anyone could remember. That happened one afternoon when he was stopped for speeding on his way to Dulles Airport. Convinced that he hadn’t been going too fast, Roberts decided to contest the ticket. He had been pulled over by the squad car near the point at which he had come onto the George Washington Parkway after a full stop, and his contention was that in that short distance he could not possibly have accelerated his Volkswagen Beetle to the speed alleged by the officer. Roberts went back to the scene and carefully measured off the distances. He gathered data on the engine output and weight of his VW bug, factored in Newton’s law of inertia and made a few other calculations, and was prepared to go before a judge to make his case. It wasn’t until friends convinced him he was unlikely to get a judge with a physics degree that he conceded the point and paid the fine instead of taking it to court.
Fortunately, there were no speeding tickets on this trip. Roberts and his program manager, Barry Wessler, flew to California without incident, and in Kleinrock’s lab at Boelter Hall they watched the network in operation. This time, Kleinrock did the typing and in less than a minute he had logged on to the host computer at SRI. Roberts watched closely and left satisfied that the experiment was succeeding.
