Ornstein had a reputation as a hard taskmaster, and he was very effective as a technical examiner. His trademark line was, “I'm just a dumb hardware guy, convince me!” He wouldn't let go until the explanation made sense to him. Often he uncovered some hidden soft spot.
Many of the planning sessions at BBN took place in the Weiner Room, a high-ceilinged conference room with a big square table and plenty of chalkboards. It was conveniently located at an intersection of corridors in the middle of BBN's systems division, a crossroads between the 516 computer room, the lunchroom, and Heart's office. The Weiner Room served as a regular gathering place for the IMP Guys. The IMP team was small enough, their offices close enough, and contact among team members frequent enough that formal design reviews were unnecessary. They talked in the hallways, sat in one another's offices, debated, and shared ideas constantly. In the Weiner Room, chalk was applied liberally and often to explain, diagram, outline, argue, and teach. Ornstein used the room to hold an informal lecture series, in which software and hardware were explained in detail, and occasionally visitors would come in to talk about technical subjects. The whole team shared information. “Everybody knew everything,” as Crowther put it.
The team members also wrote a numbered series of informal technical notes that they circulated among themselves. The notes didn't have a strict format but always began “The IMP Guys'Notes.” They wrote down their ideas, exchanged them, and then usually got together to discuss them. The notes also gave Heart a way of monitoring their progress.
Heart's reviews of the work as it matured were nothing like traditional design reviews. A design review is usually a major event in the course of an engineering project. An engineering team may work for weeks preparing a design for review, then come together to submit, elaborate on, and debate it under the scrutiny of colleagues and senior engineers. Heart's reviews tended to be ad hoc and ongoing, which isn't to say that they were easy. “It was like your worst nightmare for an oral exam by someone with psychic abilities,” recalled Bernie Cosell, the team's ace software troubleshooter. “He could intuit the parts of the design you were least sure of, the places you understood least well, the areas where you were just song-and-dancing, trying to get by, and cast an uncomfortable spotlight on parts you least wanted to work on, meanwhile virtually ignoring the parts you were so proud of for having gotten really nailed down and done right.”
Like the less-frequent meetings with Roberts, Heart's design reviews were meant “to help thrash through the hard parts,” Cosell said. Heart had implicit respect for the things his engineers did that worked well. But he was sparing with his praise. His attitude seemed to be, Why waste time with that? Younger and less experienced engineers might have been devastated by the lack of positive feedback from Heart, but the IMP Guys were a seasoned, closely knit, self-assured bunch well accustomed to Heart's ways.
Because of Heart's insistence on reliability, and Kahn's early analysis of this area, a large number of error-control mechanisms were designed into the system. Every communications system is prone to errors in transmission caused by noise in the communication circuits. Voices passing through telephones, an analog transmission, can be garbled or ambiguousâas when the sounds of “s” and “f” are confused. Digital transmissions can also be distorted: a “1” can come through as a “0” and vice versa. Errors occur in bursts. If a given bit is in error, the probability of surrounding bits being in error is much higher than normal. Despite these problems, there are good techniques for detecting and even correcting digital errors, and the IMPs would have to rely on them.
Digital error correction rests upon the basic idea of the “checksum,” a relatively small number that is calculated from the data at its source, then transmitted along with the data, and recalculated at the destination. If the original and recalculated numbers do not agree, there has been an error in the transmission, unless perhaps the checking hardware itself failed, a very unlikely proposition.
Checksums appear in data transmissions of all kinds. For instance, every beep you hear at the supermarket checkout counter signifies that a tiny laser has scanned a bar code and transmitted its digits to a computer where the checksum has been calculated and found to be correct. The machine at the checkout counter has done some sophisticated decimal arithmetic along the way by shuffling, multiplying, and adding the scanned digitsâall in the blink of an eye. In most supermarket systems the result must end in 0, the single-digit checksum used for all products.
If a product is scanned and the computer fails to beep, it means the arithmetic didn't check. If the computer had a way of correcting the error, it would beep on every pass and save time. But error-correcting techniques add cost to the system, so the checkout person must pass the item through the scanner again, perhaps two or three times until the code is transmitted without error.
The IMP Guys faced a similar problem: If a checksum detected a packet error on the network, how should it be handled? Should the transmitting IMP send the packet again, or should the receiving IMP be augmented with hardware to correct the error? In a network, error correction eats up space on the communications circuits and increases hardware expense in the switching equipment. Consequently, the BBN team decided that if an IMP detected an error in a packet, it would discard the packet without acknowledging receipt. The source IMP, still possessing a duplicate packet and still awaiting acknowledgment but not getting it, would then retransmit the duplicate.
Before issuing the request for proposals, Roberts had had to decide on the type of checksum for the IMPs. How many bits should be assigned to it and how sophisticated should it be? The precise requirement, based on an average number of errors in the phone lines, was difficult to determine because there was no hard information available about error rates on the high-speed lines over which the data was to be sent. Still, it was obvious that a 1-bit checksum would never do. Nor would a 2-bit, or even an 8-bit. Even a 16-bit checksum might not be good enough.
Kahn had earlier documented that a 16-bit checksum might not be sufficiently powerful to reach the desired level of reliability in the network, especially given the uncertainty in error performance of the high-speed lines. Kahn shared with Roberts some rough calculations that strongly suggested a 24-bit checksum would be a much better choice, pointing out that the extra 8 bits added very little expense to the hardware. The checksum was one of many technical issues on which Roberts listened to Kahn's advice, and a 24-bit checksum got written into the RFP. Later, Kahn argued the same case convincingly to Crowther and the others, and the IMP Guys settled on the 24-bit checksum as one vital piece of the error-control system.
The BBN engineers had good intuition for which problems to solve in hardware and which ones to solve in software. It made sense to let the IMP's hardware calculate the checksum, because a software calculation would be too slow. The final IMP-to-IMP error-detection scheme was a clever mix of known engineering techniques and others of the BBN team's own invention. As Crowther put it, “We'd steal ideas from anywhere, but most of the time we had to roll our own.”
On Valentine's Day 1969, Cambridge was socked in by a snowstorm. About two dozen people were in attendance at an all-day meeting at BBN. This was the first meeting between Heart's team and the researchers and graduate students from the host sites.
Through Heart's cautious eyes, this crowd of mostly graduate students looked hungry to get their hands on the IMPs. He suspected that when ARPA decided to put the IMPs out at the sites, the researchers expected to have another computer to play with. He imagined they'd want to use the IMPs for all sorts of other thingsâto play chess or calculate their income taxes. “I took an extraordinarily rigid position,” Heart recalled. “They were not to touch, they weren't to go near it, they were to barely look at it. It was a closed box with no switches available.”
Kahn was still hard at work on the host-to-IMP interface specification, so it remained unclear to host team members exactly what they'd be required to build. Some people from the host sites asked to see what BBN had in mind, but the IMP Guys hadn't settled on a plan among themselves. On that issue nothing much was resolved at the meeting.
The graduate students decided to share with BBN a plan they had devised for the hosts to compute an end-to-end checksum. This would provide an extra layer of protection against errors in host-to-host communications. It was designed to catch various imagined errors, including the possible misassembly of message packets by the IMPs.
Heart was distressed to hear this, because it would slow down the hosts and make the entire system appear slow. Nor did the very idea that the IMPs might pass damaged packets up to the hosts sit well with him. The students argued that BBN's 24-bit checksum didn't cover the paths from the IMPs to the host computers, and that bits traveled “naked” between the two machines. Heart assured everyone, in no uncertain terms, that the IMP checksum would be reliable. It remained to be seen, and in time the students would be more right than wrong, but with Heart's confidence on display, the host sites dropped their plans to include a checksum in the host protocols.
More problematic was the idea of connecting multiple host computers to the IMP at each site. When Roberts first designed the network, his idea was to connect oneâand only oneâhost computer to each IMP. However, by the Valentine's Day meeting, representatives from the sites were making it clear that they wanted to connect more than one host computer to each IMP. Every research center had multiple computers, and it made sense to try to connect more than one machine per site, if possible. Roberts sent word to Cambridge that BBN was to redesign the IMP to handle up to four hosts apiece. Walden, Crowther, and Cosell invented a clever way to do it.
After Valentine's Day, the IMP Guys really went to work. Their working hours stretched long into the night. Heart, who lived in the rural town of Lincoln, tried to get home in time to have dinner, but often he didn't make it. It was easier for the others to go home for dinner and return to work, or not go home at all. When he was deep into the project, Crowther would sit at his terminal until he fell asleep.
Now the real pressure was on Kahn. He spent much of the next two months on the phone with people at the host sites, grinding away at the interface specification. Kahn became BBN's main point of contact with the host research community. Researchers called him regularly to check what was happening, and what the schedule was, or simply to pass along new ideas.
By mid-April, Kahn finished the specification, a thick document describing how a host computer should communicate with a packet switch, or IMP. “It had been written partly keeping in mind what we'd been told the hosts wanted, and quite a lot keeping in mind what was going to be possible to implement, and what made sense to us,” said Walden. A committee of representatives of the host sites reviewed it and told BBN where they didn't think it would work. The specification was revised until an acceptable design was reached. The host sites had something to build now. The UCLA team, which would be first, had less than five months to get ready for the arrival of its IMP.
Heart had drawn a clear line between what the IMPs would handle and what the hosts would do. “Early on, Frank made a decision, a very wise decision, to make a clean boundary between the host responsibilities and the network responsibilities,” said Crowther. Heart and his team decided to put “maximum logical separation” between the IMP and the host. It made conceptual and design sense for them to draw the line there to avoid cluttering or crowding the IMP's functions. This also made building the IMPs more manageable. All IMPs could be designed the same, rather than being customized for each site. It also kept BBN from being caught in the middle, having to mediate among the host sites over the network protocols.
BBN had agreed with Roberts that the IMPs wouldn't perform any host-to-host functions. That was a large technical problem. There were neither language standards nor word-length standards, and so far nothing that would facilitate easy communication between hosts. Even individual manufacturers, such as Digital, built a number of wholly incompatible computers.
The last thing BBN wanted was the additional headache of solving the host-to-host problems. Furthermore, Roberts didn't want to give BBN or any other contractor that much control over the network design. Roberts was determined to distribute responsibilities evenly. Between Roberts and BBN it was settled: The IMP would be built as a messenger, a sophisticated store-and-forward device, nothing more. Its job would be to carry bits, packets, and messages: To disassemble messages, store packets, check for errors, route the packets, and send acknowledgments for packets arriving error-free; and then to reassemble incoming packets into messages and send them up to the host machinesâall in a common language.
The IMPs were designed to read only the first 32 bits of each message. This part of the message, originally called a “leader” (and later changed to “header”), specified either the source or destination, and included some additional control information. The leader contained the minimal data needed to send and process a message. These messages were then broken into packets within the source IMP. The burden of reading the content of the messages would be on the hosts themselves.
The host computers spoke many different languages, and the hardest part of making the network useful was going to be getting the hosts to communicate with each other. The host sites would have to get their disparate computers to talk to each other by means of protocols they agreed on in advance. Spurred by ARPA, the host community was making an organized effort to begin resolving those protocol issues, knowing it would be quite a while before anything was settled definitively.