Where Wizards Stay Up Late: The Origins of the Internet

by Katie Hafner

  By summer 1970, machines number six, seven, eight, and nine had been extracted from Honeywell and were now operating at MIT, RAND, System Development Corp., and Harvard. AT&T had replaced the first cross-country link with a new 50-kilobit line linking BBN to RAND. A second cross-country link connected MIT and the University of Utah. The ARPA network was growing at a rate of about one node per month.

  One day in 1970, a delivery truck from Honeywell pulled up to the Moulton Street loading dock and started backing up to unload another new 516 computer. Alerted to the truck’s arrival, Severo Ornstein hurried out the door, made a quick inspection of the machine while it was still in the truck, and loudly waved the driver off. Heart, who had come out of his office to see what the commotion was about, stood watching, taken aback, as Ornstein told the driver to turn around and drive the machine back to Honeywell; he was rejecting the delivery.

  Ornstein had had it with late deliveries and incomplete, faulty equipment. Sending the truck back caused an uproar at Honeywell, he said. But for once their attention was focused. BBN wasn’t accepting another Honeywell 516 until some things were straightened out. The difficulties had been growing. To Heart’s team, the relationship with Honeywell felt more like an arm-wrestling match than a partnership. “They kept shipping us machines that had the same old errors in them,” Ornstein recalled. After the loading dock incident, he began going to Honeywell regularly to inspect each new machine before it was sent to BBN.

  Before long, Honeywell had pulled its IMP-building team together and was producing acceptable machines. IMPs were delivered to Lincoln Laboratory and Stanford, and by the end of the year Carnegie-Mellon University and Case Western Reserve University were also connected to the network. By that point, hundreds of minor revisions had been written into the IMP software. Hardware had been tuned and retrofitted. The telephone company, doing its part, now had fourteen 50-kilobit links installed in the network. BBN’s remote-diagnostic and network-management tools were also undergoing constant improvement. ARPA had extended BBN’s contract to keep producing IMPs and run the control center, and it was all clicking.

  The level of activity in the monitoring center at BBN increased. With the network’s steady expansion, the diagnostic reports coming into BBN were starting to bloat and grow cumbersome. The IMP Guys were having difficulty staying on top of the data, scanning the printout of the Teletype log and locating trouble signs. They needed a housekeeper. So they decided to connect a spare machine, BBN’s earliest prototype IMP, to the ARPA Network, where it would function as a host machine behind the regular BBN IMP. This new host machine would be used to help process the network status reports. The BBN programmers wrote new code to compile hourly summaries of the more frequent IMP status messages that were now stacking up at the rate of one per minute from each IMP. The code’s operative assumption was that no news was bad news: If the Network Control Center failed to receive a status message from an IMP for three minutes, the network status readout would indicate that that IMP was dead. This and other improvements made it easier to detect important status changes in the network.

  It was November 1970 when Alex McKenzie returned to BBN from a short leave of absence. He and his wife had spent six months camping in Europe. In the short time he was gone, the network project had advanced dramatically. Settled back into Cambridge now, McKenzie realized the importance to BBN of managing the network as if it were an electrical utility. That meant a reordering of certain fundamental assumptions would have to occur. The time had come to shift the network from an experimental to operational mode, he reasoned. And McKenzie began pressing that view on all of his colleagues. Organized and meticulous, McKenzie seemed the perfect candidate to take charge of BBN’s Network Control Center, and Heart appointed him to the task.

  Other cultural changes were in the wind around BBN. McKenzie’s sensibility about the network project was in tune with a more business-oriented company overall. BBN itself was growing. Within a year or two after McKenzie made his push for running the network as a utility, BBN had bought the Superior Laundry at the busy end of Moulton Street and torn it down to make space for a new seven-story headquarters building. Eventually, the Network Control Center and the rest of Heart’s division moved to the fifth floor of the new quarters. Architecturally, the style of the impressive new building subtly suggested a sleek fortress. Built at the height of the antiwar movement in the early 1970s, it reflected BBN’s emerging corporate consciousness about antiestablishment threats to companies engaged in U.S. Defense Department contracting. The building had no windows on the ground floor, where a large computer center was located. It also had a basement parking garage designed so that the building itself stood back, surrounded by a substantial, waterless moat, allowing access to the front door only over a short footbridge.

  On the fifth floor, the Network Control Center occupied one large room with large plateglass windows looking north to the hills beyond Cambridge. Heart’s team, numbering about thirty people, was spread out in modern offices and well-equipped labs throughout the floor. Heart’s division had the only floor in the building with its own tiny kitchenette tucked off a central corridor, a special request by Heart, who intended to equip it with a restaurant-quality Italian espresso machine someday.

  Dominating one large wall of the control center was a logical map of the network. Constructed of movable magnetic pieces on a metal background, the map was a wiring diagram showing all of the IMPs, host computers, and links—indicated by square, round, and triangular markers. Color codes and pointers indicated the status of each IMP, node, and link. At a glance, operators could tell which lines or IMPs were down and where traffic was being routed around the trouble spots. Besides critical information, an occasional joke or cartoon might be tacked up with a magnet as if the control map were one big refrigerator door.

  One of the NCC’s primary tasks was to issue software upgrades and reload IMP operating programs when necessary. The operators used a cleverly cooperative scheme by which every IMP downloaded the software from a neighbor. Every Tuesday from 7:00 to 9:00A.M., BBN had the network reserved for software distribution, network testing, and maintenance. Within these two hours, operators in the NCC could have every IMP on the network running a new software release. All new versions of the IMP operating codes were eventually distributed this way. The process of electronic propagation would begin in Cambridge as a new software program was downloaded to a nearby site, which in turn would download the software package to another neighbor, at the command of the operators.

  The method also had restorative potential. If an IMP’s operating program were found to be destroyed, the IMP could send a request for a program reload to a neighboring IMP. The responding IMP would send back a copy of its own program.

  Fine Tuning

  Other big changes had also taken place in the network’s second year. BBN and ARPA decided that the ruggedized Honeywell 516, reflecting too much worry about reliability, was an expression of overkill. It was expensive, too. The 516 cost roughly 20 percent more than a newer version of the computer, the Honeywell 316, which was not available in ruggedized form. Ben Barker, who remained intimately involved in maintaining and troubleshooting more than a dozen IMPs now in the field, actually concluded that the cabinetry on the ruggedized 516 was a source ofreducedreliability, because it hampered what should have been easily performed routine maintenance tasks.

  Honeywell was under contract to handle routine maintenance. But here, too, they were slow in coming around to BBN’s emerging view—McKenzie’s utility model—of how a computer network should operate. There were periods in which the downtime of the IMPs averaged as much as 3 or 4 percent on a monthly basis. If an electrical utility or the telephone system were down that much of the time—a day out of every month—its performance would be considered abysmal. But Honeywell had to be coaxed into picturing where BBN and ARPA wanted to go with the network.

  “I remember a great meeting when we went over the numbers with the guys
at Honeywell,” Barker recalled. “The Honeywell guys said, ‘Wait a minute. You’re saying these machines are down between half an hour and an hour a day? That’s like, uh, three percent downtime. You mean, these machines are up ninety-seven percent of the time on a twenty-four-hour a day basis. How are you doing that!?’”

  The 3 percent downtime that amazed Honeywell, was, in BBN’s words, “prolonged hardware failure syndrome.” The normal procedures of calling in and working with Honeywell field engineers had not cleared up several of these “persistent failures,” reported BBN. They were particularly concerned about problems at several sites in the Washington, D.C., area.

  Frustrated by recurring maintenance problems, Roberts threatened, ever so vaguely, to cancel BBN’s contract. Barker eventually went to Heart and proposed letting him put together a BBN-directed maintenance team, with an adequate field staff for periodic maintenance and a roving expert “firefighter.” But McKenzie adamantly opposed the idea, not because he was content with how things were going with Honeywell but because he feared that Barker would only make things worse. It was Barker’s slovenly personal style to which McKenzie, a fastidious man, was reacting; he said Barker’s office looked like a garbage truck had been backed up to it and emptied of its contents, and indeed it was a fitting image. Few would dispute that Barker’s office was, on a good day, a total mess. Nor would they dispute the sharpness of his technical knowledge and skills. So in trade, Barker made a concerted effort to keep his office clean, and Heart handed him the job of building and directing a crack maintenance team.

  Maintenance aside, Heart’s own confidence about the network’s intrinsic reliability had grown in the first year. He had seen the IMPs functioning successfully in the field. His team had met its initial tests. He was also a little more relaxed after a while about the trustworthiness of the on-site investigators and graduate students. As a consequence, the last ruggedized version of the Honeywell 516 rolled into Moulton Street around the end of 1970 and eventually was shipped as IMP Number Fifteen, headed for the Burroughs Corporation in Paoli, Pennsylvania. At about the same time, the University of Illinois at Urbana-Champaign received machine Number Twelve, which had been delayed.

  By now, BBN had received ARPA’s go-ahead to shift into another intensive engineering effort: designing a prototype 316-based IMP. Honeywell promised delivery of the machine in early 1971. The transition to the lighter 316 IMP was only part of a developing structural shift in the ARPA network.

  For months, Heart’s team and Roberts had been discussing the possibility of connecting many new users to the net without going through a host computer. It appeared they could make it possible to log onto the network, reach a distant host, and control remote resources through a simple terminal device—a Teletype or a CRT with a keyboard— directly connected to an IMP. The new scheme would eliminate the need for a host computer between every user and the IMP subnet. All you’d need to make it work would be a dumb terminal connected to an IMP. This would open up a lot of new access points.

  If it could be worked out technically, then hundreds or even thousands more users might gain access to the network without physical proximity to a host computer. Then, the network would no longer be just an experiment for the hardcore computer scientists with mainframe accounts, but open to a whole panoply of more casual users—military officers, government bureaucrats, university administrators, students—who would be brought into the networking community. That would bring the world one step closer to realizing Licklider’s vision of the computer as a facilitator of communication and human interaction.

  But neither the original IMPs nor the new 316 IMPs could support more than four host interfaces. Neither machine could accommodate a terminal connection. To make the new concept workable, Heart’s team would have to build a new interface that could handle dozens of terminal lines feeding into the IMP and the network. Sensing the value of going in this new direction, BBN launched an accelerated effort to design a terminal controller that could manage the traffic generated by a large number of terminal devices connected directly or through dial-up lines. The new device was called simply a Terminal IMP, or TIP.

  Within six months, BBN and Honeywell completed the design and construction of two new prototype machines based on the 316. The first was a basic IMP, the other a TIP that included a multi-line controller capable of managing the signal traffic of up to sixty-three terminals at once. All terminal devices attached to a TIP would be addressable as if belonging to a single host on the network. In the backroom where BBN took deliveries, Heart’s team had set up a small test cell to debug the incoming machines; the last of the 516 machines had been coming in the door at a fairly steady pace every four weeks, and at any time there might be two or three machines, sometimes more, linked together to test their performance and simulate network traffic. The first four deliverable TIPs were scheduled to arrive at BBN by late summer of 1971.

  Everything seemed to be working according to design. BBN began exploring the gamut of terminal devices that might be connected to the network. The options ranged from graphics CRT displays, to slow and fast line printers, to alphanumerical displays, and Teletype-like terminals. The team was also considering how to link to card readers, magnetic tape recorders, and other peripheral devices.

  Still more routing algorithm tests, throughput tests, tests of flow-control schemes, and remote diagnostics tests continued to occupy the BBN team on a daily basis, week in and week out, leading to steady improvements in their packet-switching technology.

  The Network Control Center kept expanding with the network. Pressure to maintain the network grew. It became a steady part of ARPA’s contract with the firm, and soon the center was staffed around the clock, seven days a week. At one point, the NCC upgraded some equipment and added an automatic phone dialer to the system. The auto-dialer was intended specifically to monitor the condition of modems spread throughout the network. There were dozens of modems handling data traffic to the TIPs. The BBN troubleshooters had the auto-dialer run a simple test: The dialer was programmed to call each modem once a day and listen for an answer. If a modem picked up and whistled back, its vital signs were considered normal. Any modem not answering or signaling back improperly turned up on a trouble report.

  At one point, the NCC staff picked up on a particular modem that appeared to be malfunctioning whenever the auto-dialer ran its check. Someone suggested placing a call through the auto-dialer to the troublesome modem, while a technician listened in; perhaps he could diagnose the signal coming back. So he placed the call, listened for the modem to pick up, and heard an angry voice on the other end of the line. Before slamming down the receiver, the voice is reputed in countless retellings to have said, “Hey, Martha, it’s that nut with the whistle again!”

  Congestion control, one of the troublesome problems demonstrated by Kahn’s experiments, had been attacked and improved. BBN had redesigned the scheme to reserve enough space in the IMP memory buffers for reassembly of incoming packets. A specific amount of reassembly space for each message would be reserved at a destination IMP before the message would be allowed to enter the network. The sending IMP would check, and if told that there was insufficient space available in the destination IMP’s buffers, the RFNM (Request For Next Message) was delayed. The solution was not unlike the treatment many an airline passenger has experienced when a plane cannot take off because bad weather at the destination airport prevents the plane from landing. The passenger sits on the ground and waits for an opening at the destination. In simulations, the new scheme succeeded in preventing the insertion of more traffic into the network than the destination IMP could handle.

  If development of the network was to proceed at a steady pace now, closer coordination would be necessary between BBN’s effort to introduce the Terminal IMP and the Network Working Group’s effort to develop protocols. So Heart’s team decided to involve itself much more deeply in the work of the Network Working Group. By mid1971, BBN had injected itself int
o the NWG’s committees (McKenzie was the BBN representative) working on the host-to-host protocol, the file-transfer protocol, and the Telnet protocol.

  Although it took more than a year to work out, the Telnet protocol was a relatively simple procedure. It was a minimal mechanism that permitted basic communication between two host machines. The first four nodes had connected four different machines, while other host sites offered a further melange of incompatible computers, ranging from the DEC PDP-10 to large IBMs, to Honeywell and Xerox machines. Telnet was conceived in order to overcome simple differences, such as establishing a connection and determining what kind of character set to use. It was TIPs and Telnet together that paved the way for rapid expansion of the network.

  File transfers were the next challenge. For a couple of years, a half-dozen researchers had been trying to arrive at an acceptable file-transfer protocol, or FTP. The file-transfer protocol specified the formatting for data files traded over the network. Transferring files was something of a life force for the network. File transfers were the digital equivalent of breathing—data inhale, data exhale, ad infinitum. FTP made it possible to share files between machines. Moving files might seem simple, but the differences between machines made it anything but. FTP was the first application to permit two machines to cooperate as peers instead of treating one as a terminal to the other. Bringing this functionality to the network depended on the FTP working group coming up with a working final product.