Where Wizards Stay Up Late (13 page)

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.”

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 equivalent 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.

“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.

One interesting advantage of core memory is its nonvolatile nature. If you turned the machine off in the middle of working on something, it wouldn't lose its place; it would pick right back up again where it had left off. Heart's team had also designed an automatic restart feature: If the power failed, the machine was supposed to come to a clean stop and then restart automatically when power returned. With the core memory, the machine would restart at the beginning of the program as soon as power was restored. The only time a program had to be reloaded was when a new release was issued or when some hardware or software glitch caused the memory to be over-written. In these cases, the IMP program would be reloaded from a paper tape reader, a kludgy electro-mechanical device which shone light from an incandescent bulb through a paper tape that was pulled across a line of photocells. The IMP had other self-sufficiency measures, one of which was called a “watchdog” timer. “If the program went wild,” Heart explained, a small timer in the machine would run down to zero (but a healthy program would continually reset it). If the timer reached zero and went off, the IMP was assumed to have a trashed program. It would then throw a relay to turn on the paper tape reader, give it a while to warm up, and then reload the program. BBN would ship each machine with a copy of a tape that had three copies of the entire IMP operating program in sequence, giving each IMP the chance to do three auto-reloads before someone had to go and rewind the tape. Later, an even more ingenious scheme would be invented by BBN to reload crashed IMPs from the nearest neighbor IMPs, and start fresh. These were all unusual features at the time.