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 plate-glass 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:00
A.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.
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 of
reduced
reliability, 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.