Where Wizards Stay Up Late

by Matthew Lyon

  “We take the position that it will be difficult to make the system work,” BBN wrote hedgingly in its proposal. In this cautious way the BBN team let Roberts know that it didn’t take for granted a task that was unprecedented in its complexity, revolutionary in concept, and filled with technical details of uncertain feasibility. Yet the proposal then went on to demonstrate that BBN seemed to have the problem solved.

  By the time the proposal was finished, it filled two hundred pages and cost BBN more than $100,000, the most the company had ever spent on such a risky project. The BBN team had covered so much of the design of the IMPs that a large fraction of the entire system was already clearly defined. BBN’s finished proposal was more blueprint than outline. Its engineers had designed test programs and regular performance checks for IMPs and the network. They described how the network would handle congestion in the buffers (storage areas in the machines that served as waiting areas and staging areas for the flow of packets into and out of the network), and how it would recover from line and computer failures. They provided ARPA with flowcharts outlining how the IMP software would handle such difficult problems as timing and the continual updating of routing tables. They came up with detailed computations, equations, and tables that covered, among other things, transmission delays and the queueing of packets. It was all there for Roberts to see.

  The BBN team submitted its proposal on September 6, 1968, relatively certain that no one else had prepared a bid as detailed as theirs. Years later, when people who worked on the BBN proposal were asked how long it took to put the document together, some of them said honestly they thought it had taken six months.

  Heart’s team had obviously done an impressive amount of extra spade work, resolving some problems Larry Roberts hadn’t expected to see covered. BBN held another advantage: its relatively small size. Roberts didn’t want to deal with a lot of bureaucracy, and the other proposals were fraught with it. The team Raytheon was putting forth, for example, spanned five layers of management. Roberts could see that just finding the right person with whom to talk over the slightest problem might require a dozen phone calls. The BBN team, on the other hand, had a very simple hierarchy. Everybody reported to Heart, who handed out the tasks and saw that they got done. Heart had a boss, but he appeared to be giving Heart ample latitude to do as he pleased with this project.

  The first sign that BBN’s bid was being taken seriously came when Roberts called a meeting to review parts of the proposal. Heart, Crowther, Kahn, and Ornstein, their spirits high, took the train to Washington. (Heart tried, unsuccessfully, to convince Crowther to wear something on his feet besides sneakers.) During the meeting, they defended and expanded on their proposal. Roberts tested, prodded, and poked the engineers to see if they had really thought deeply and thoroughly about the system. And his questions continued for some weeks afterward. “At some level I think that the continued questioning by Larry kept us thinking about the problems and continuing to fill out design details subliminally,” recalled Ornstein. “But I think the more important thing was that we took it to heart more than the other contenders. We made the design our problem and did our best to find solutions we believed in without bowing too much to the specifications others had put down.”

  But for the most part, all they could do was wait. If Roberts had a favorite proposal, he wasn’t letting anyone know it. It could take months before they heard anything definite. By midautumn they all returned to what they had been doing before the proposal marathon. Time slowed down again. Crowther went caving, which, next to rock climbing and writing code, was his passion. Heart got home at dinnertime and didn’t go back to work. Kahn was about the only one who, by force of habit, routinely kept working late into the night. Everyone was anxious. “I personally swung from certainty that our proposal couldn’t be beaten,” said Ornstein, “to a belief that there was no way we could win, given the size of BBN compared to the other contenders.”

  Throughout the evaluation process, as the competition for the Interface Message Processor got whittled down, the BBN team heard rumors through the ARPA grapevine, though never from Roberts himself, who remained sphinxlike. Naturally, they did a lot of second-guessing. In their more pessimistic moments, the BBN engineers were inclined to believe that since Roberts knew many of them from Lincoln, it might be difficult or awkward or impossible for him to award the contract to BBN. Nonetheless, ARPA did just that.

  When news reached Massachusetts Senator Edward Kennedy’s office just before Christmas that a million-dollar ARPA contract had been awarded to some local boys, Kennedy sent a telegram thanking BBN for its ecumenical efforts and congratulating the company on its contract to build the “Interfaith Message Processor.”

  4

  Head Down in the Bits

  New Year’s Day, 1969, was the last time Frank Heart’s group would be able to rest for quite a while. The following week, the contract to build the first Interface Message Processors officially began. For a little more than $1 million, BBN would build four IMPs; the first was due at UCLA by Labor Day, followed by one every month through December. In twelve months the network was supposed to be up and running, with four sites on-line. The BBN team had already done a great deal of work in generating the proposal. Now looking ahead, they saw at least eight more months of late nights and intensive systems engineering work. There were still many unknown challenges, a point emphatically underscored by BBN in its proposal. Furthermore, the members of Heart’s team all had different ideas about how difficult building the IMPs would be.

  Heart encountered any number of skeptics—phone company people and academicians mostly—who didn’t believe a packet-switching network would work. Building the hardware wasn’t really the hard part, they argued; rather, making it all work together—the systems part—was the trick. Even if you could integrate all the hardware and software and demonstrate the feasibility of a computer network, some pointed out, there still wasn’t any profit in it for a company like AT&T or IBM, not as a business proposition. Who but a few government bureaucrats or computer scientists would ever use a computer network? It wasn’t as if computing had a mass market like the television networks or the phone company.

  During the weeks before winning the bid, BBN’s biggest doubt had been whether ARPA would entrust the job to such a small company. The members of BBN’s team knew there was a lot riding on them now. If the IMPs didn’t work, networking and packet-switching would fall into the oblivion of failed experiments. Some people—other bidders mostly—expressed astonishment that little BBN had won the contract. “This kind of large systems job just didn’t seem to be up BBN’s alley,” said one competitor.

  By and large, Heart ignored the detractors, although he too worried occasionally about the technical challenges that lay ahead. To be effective, a data network would have to send packets reliably, despite errors unavoidably introduced during transmission over ordinary phone lines. Human ears tolerate telephone line noise, which is often barely audible, but computers receiving data are nit-pickers about noise, and the smallest hiss or pop can destroy small bits of data or instruction. The IMPs would have to be able to compensate.

  Then there were circuit outages to anticipate, especially if the four-node experiment expanded coast to coast as ARPA envisioned. A spot of bad weather somewhere, a thunderstorm in the Midwest or a New England blizzard, would knock out service on a long-distance phone line carrying network data traffic. Brief interruptions in service couldn’t be prevented and would have to be dealt with by the IMPs. On top of that, in the best of conditions, there was a vastly complicated matrix of routing problems to be resolved. Heart’s team had to prevent messages from circulating endlessly in the network, bouncing from node to node without ever reaching their final destination. Finally, the team had to consider the possibility of jam-ups in the memory buffers. Messages could be a maximum of 8,000 bits; IMPs were to break such messages into a sequence of packets with a maximum size of 1,000 bits each. One packet would contain the equ
ivalent of about two lines of text on this page.

  The system had to deliver packets and messages within the time specifications Roberts had set—half a second for a message to go from any source host to any destination host via the IMP subnet. It would mean processing data at speeds on the order of one hundred messages per second, which was certainly possible although synchronizing everything would be difficult.

  As if the technical challenges weren’t enough, the ARPA network project schedule was on a fast track; the schedule set by Roberts was tied to the budget cycle and political realities facing him in Washington. Eight months weren’t enough for anyone to build the perfect network. Everyone knew it. But BBN’s job was more limited than that; it was to demonstrate that the network concept could work. Heart was seasoned enough to know that compromises were necessary to get anything this ambitious done on time. Still, the tension between Heart’s perfectionism and his drive to meet deadlines was always with him, and sometimes was apparent to others as an open, unresolved contradiction.

  BBN faced countless other issues that had pushed other bidders and potential bidders out of the running. Now all these problems belonged to Frank Heart.

  Getting Started

  “It’s one thing when you plug into a socket in the wall and electrons flow,” said Bob Kahn. “It’s another thing when you have to figure out, for every electron, which direction it takes.” To Kahn’s way of thinking, this summed up the difficulty of building a network that switched packets of bits, and did so dynamically. Kahn knew very little about hardware design. He was a scientist who mainly did conceptual work on system designs and architecture. Because he pondered the larger conceptual aspects of the problem perhaps a little more deeply than his colleagues, he worried more about the complexity of building the network. To Kahn the network was more of an abstraction, perfectible and whole, than it was to the other team members, involved as they were in the actual programming and wiring of its many parts.

  The packet-switching concept opened a rich universe in which a theoretically oriented and trained engineer like Kahn could investigate a wide range of hypothetical scenarios. Kahn’s analyses had already helped shape the ARPA network project. Kahn had contributed ideas freely to Larry Roberts, urging him to launch the ARPA networking experiment on a large scale using long-distance telephone lines. Other people had said a small-scale experiment would be fine to begin with, but Kahn had worried that nothing meaningful could be learned from a small experiment. Roberts agreed and decided on a transcontinental network of at least nineteen nodes.

  You could certainly build a network experiment in a single laboratory—if you wanted to. By this time Donald Davies had finally been given the go-ahead and some funding to do just that at the National Physical Laboratory in London, using short lines, each hundreds of yards at most. Kahn was sure that a small-network experiment wouldn’t “scale up,” at least not in practical terms. He reasoned that short links in a laboratory wouldn’t have the same real-world error rates and problems as the long lines used in the telephone system. The real goal was to link computer scientists, and eventually other computer users, cross-country. So a real network would have to cover thousands of miles, and would have to be designed to handle packets—and correct phone-line errors—at a much higher rate than any small network.

  Roberts seemed to trust Kahn’s judgment. Before the request for proposals hit the streets and BBN became a bidder, the two men spoke occasionally. Once Kahn had been enlisted to contribute to BBN’s proposal effort, he worked into the early-morning hours, night after night, occasionally in Severo Ornstein’s living room, helping to design the system for BBN’s bid. The work paid off, BBN won the contract, and Kahn had already decided to return to his own research work after Christmas.

  But as the new year rolled around, Kahn began to have second thoughts. The technical issues were complicated. Perhaps he should stick around for the implementation. It couldn’t hurt. Besides, Kahn was eager to learn more about the hardware side of things from Ornstein. And moving over to Heart’s shop was the only way for Kahn to continue his own network research, or so the folks who ran BBN led him to believe.

  Jerry Elkind, the man to whom both Heart and Kahn reported, urged Kahn to join the IMP group because Heart now had the one contract at BBN specifically devoted to networking. Although he continued to report to Elkind, Kahn moved into Heart’s systems group. Soon he found himself picking up his office and crossing over the BBN footbridge from Bolt’s scholarly haven into the redesigned warehouse where the group of young men who had started calling themselves the “IMP Guys” were already hard at it. (And guys they were. In keeping with the norms of the time, with the exception of Heart’s secretary, the people who designed and built the ARPA network were all men. Few women held positions in computer science. Heart’s wife, Jane, had quit her programming job at Lincoln to raise their three children.)

  The team Heart had assembled knew how to make things that worked, if not perfectly, then well enough. They were engineers and pragmatists. All of their lives they had built things, connected wires, and made concepts real. Their ethos was utilitarian. At its core, all engineering comes down to making tradeoffs between the perfect and the workable.

  Functionality mattered now, not elegance or beauty. Unlike, say, fine Swiss watchmakers, whose engineering and art are inseparable in a $40,000 watch, Heart’s team naturally separated artistry from the craft of building a reliable computer. Looking down into the bits, lesser engineers with larger egos might attempt to show off, to infuse the mechanism with art, to create some wonder of engineering, a gold inlaid, filigreed marvel of complexity. The inner strength of Heart’s team was its restraint, its maturity. This was no place for signature craftsmanship. “There was an infinity of ways we could go wrong, and a substantial number of ways to go right,” said Walden, the first programmer Heart had signed on. “Good engineers find one of the ways of going right.”

  The real-time radar systems, the systems for seismic detection of A-bomb tests and earthquakes, and the other systems that Heart, Ornstein, Crowther, and Walden had all worked on at Lincoln Lab had been more complicated than the IMP. Years later, some people would say that the IMP was nothing but a big I/O device and actually very simple. To the user, the IMP was to be as simple as an electrical outlet or a wall switch that does its job without calling attention to itself. Then again, building the IMP to perform as well and as unobtrusively as a household socket or switch was precisely the challenge.

  The software team had been working together closely since the proposal. Each member had a specific role. Crowther worked on IMP-to-IMP communications, Walden concentrated on the IMP-to-host issues, while Cosell worked on development and debugging tools.

  Willy Crowther, thirty-two years old, quiet but opinionated, was the soul of the team. In the first few weeks of 1969, Crowther did a lot of hanging from office-door frames. Everyone around him just accepted the behavior as Willy’s way of warming up. It helped strengthen his hands for rock climbing and seemed to help his thinking even more. Crowther’s style, recognized by the rest of the team, was to appear as if he were doing nothing for days, or doing just a lot of door-frame chin-ups, before finally releasing in a torrent whatever had been forming in his mind.

  If Crowther and his colleagues were confident about their programming and software design, Ornstein was equally confident about directing the hardware effort. He was responsible for designing high-speed I/O devices that BBN planned to add to the Honeywell 516. The considerable effort that he’d already invested in drafting the proposal was time well spent. After making only a few further refinements and finishing touches, the team would be ready to move into the hardware construction and programming phases of the project. Ornstein’s first task was to bring the hardware design to a point where he could go to Honeywell with a set of detailed modifications to the 516. After that, Honeywell would start to build the specialized I/O devices the IMP needed to communicate with the hosts and other IMPs. />
  The IMP team had to decide which network operations would be handled by the IMP software and which would be hardwired, or built into, the IMP hardware. Simple tasks that had to happen quickly were best handled by hardware. But once designed and built, a piece of equipment was harder to modify than any piece of software. So as a rule, the IMP Guys favored software solutions. If something could be done fast enough in software they did it there, designing the system to give themselves more leeway for revisions later on.

  By February, BBN had firmed up its contract with Honeywell for the purchase of the DDP-516s. Within days, Honeywell delivered and installed the first 516 computer in a room at the front of BBN’s Moulton Street complex. This machine wasn’t the modified, military-grade version on order but a plain vanilla, off-the-shelf 516. It was a tester, the “development” machine, with which the programmers would experiment as they set to work. Programmers are usually not willing (or able) to go far in writing code for a specific computer until the actual hardware it will run on is at hand. Ornstein had just begun the process of working out all the final details of the specialized I/O interfaces; it might be weeks before Honeywell could make those interfaces available to conduct experiments.

  Like virtually all computers of its era, the Honeywell machine had no disk—no hard drive, no floppy (floppies hadn’t been invented yet). It had a core memory—a dense matrix of hair-thin copper wires and magnetized ferrite rings, or cores, each about the size of a mustard seed. The total size of the memory ordered (12k) was miniscule by today’s standards. The amount of memory in a desktop computer circa mid-1990s, if it consisted of ferrite cores, would take up an area roughly the size of a football field.