Where Wizards Stay Up Late (24 page)

Lukasik and Roberts had an excellent relationship, partly because they were both analytical thinkers, and partly because Roberts was always quick to answer any questions Lukasik had about his projects. “If we had a meeting on Tuesday afternoon and I sent Larry away with some questions to answer, he'd come back the next day for another meeting with more than just answers. He'd have trends and projections and comparisons.”

Then Lukasik discovered what was happening, and the utility of e-mail became clearer than ever. Typically, Roberts would leave Lukasik's office, return to his own office and fire off messages to the experts on the topic at hand, who in turn bounced the questions off their graduate students. Twenty-four hours and a flurry of e-mail later, the problem had usually been solved several times over. “The way Larry worked was the quintessential argument in favor of a computer network,” Lukasik said. During Lukasik's tenure, Roberts's annual budget nearly doubled, from $27 million to $44 million.

In 1973, Lukasik commissioned an ARPA study that found that three quarters of all traffic on the
ARPANET
was e-mail. By then, sending e-mail was a simple and nearly trouble-free process. However, trying to read or respond to it was something else: functional but not at all easy. Text just poured onto the screen or out of the printer, and nothing separated the messages. To get to the last one, you had to run through them all again. For many users, the only way to read mail was to turn on the Teletype and print out streams of text. Composing messages was truly an annoyance, because tools for text editing were primitive. And there was no “reply” function for e-mail; to respond, you had to start a new message from scratch.

Lukasik, who hated throwing anything away, was beginning to get frustrated by the volume of e-mail piling up in his in-box. He went to Roberts. “I said, ‘Larry, this e-mail is great, but it's a mess!'” Lukasik recalled. “In typical Larry fashion, he came in the next day, and said, ‘Steve, I wrote some code for you that may help.'And he showed me how to get a menu of messages, or file them, or delete them.” Roberts had just written the first mail manager software.

Roberts called his program
RD
, for “read.” Everyone on the
ARPANET
loved it, and almost everyone came up with variations to
RD
—a tweak here and a pinch there. A cascade of new mail-handling programs based on the Tenex operating system flowed into the network:
NRD
,
WRD
,
BANANARD
(“banana” was programmer's slang for “cool” or “hip”),
HG
,
MAILSYS
,
XMAIL
. . . and they kept coming. Pretty soon, the network's main operators were beginning to sweat. They were like jugglers who had thrown too much up in the air. They needed more uniformity in these programs. Wasn't anyone paying attention to the standards?

For reasons unrelated to e-mail but apparent to all who used the network daily, occasionally the network simply went berserk. Or, as one person said, it became “wrinkled.” Trouble in one machine could trip a systemwide domino effect. Case in point: the Christmas Day, 1973, lockup. The Harvard IMP developed a hardware fault that had the bizarre effect of reading out all zeros into the routing tables, thereby informing other IMPs across the country that Harvard had just become the shortest route—zero hops—to any destination on the
ARPANET
. The rush of packets toward Harvard was breathtaking.

Users would notice a crash like that. Everything came to a halt. “Harvard became a black hole,” said John McQuillan, then a Harvard graduate student. “All the traffic went to Harvard, and like a black hole, no information came out.” McQuillan had been introduced to network operations by Ben Barker and had helped connect Harvard's PDP-1. While finishing his doctorate, McQuillan was hired to improve the software for BBN's Network Control Center. On Christmas Day, as the zeros from Harvard were sent to routing tables across the country, even the control traffic used by BBN to diagnose and debug the system got sucked into the “gravitational orbit” of Harvard's faulty IMP. The BBN operators had to “cauterize”—cut off that part of—the network, debug it, and then bring it back up.

Like a utility company, BBN was rapidly developing the means to deal with such occurrences. And there were relatively few network-wide crashes, none lasting very long.

On Tuesdays, the days that BBN had the
ARPANET
reserved for housekeeping chores, McQuillan got in by six
A
.
M
. Crowther and Walden had stopped programming the IMPs. Between 1972 and 1974 McQuillan picked up primary responsibility for revising the codes and designing the release procedures. He led the team that wrote all the new IMP software and made the releases into the network. He built “fairly elaborate” test networks in the BBN laboratory, where he simulated failure scenarios, forcing the test network to fail so he could learn to make the
ARPANET
more fail-safe.

“You just know that the computers are going to encounter lightning storms, and power failures, and software bugs, and hardware bugs, and the janitor's going to trip over the power cord, and just anything you can think of could happen,” said McQuillan. But of all the potential problems, trouble in the routing algorithm was deemed the worst.

For all of its elegance and simplicity, the original routing algorithm written by Crowther was flawed, for although it was lean, in a sense the scheme was too primitive for heavy traffic. It was a known problem, but it didn't matter until the network reached a point when heavy use and a large number of nodes began to strain the routing scheme. “This didn't start to happen until the network got big,” said McQuillan. “When it was real small, the basic protocols all worked. But when it's small, almost anything will work.” They knew that when the system reached fifty or sixty nodes, the old algorithm wouldn't be able to provide routing updates fast enough, and they'd have a real big mess on their hands. McQuillan made it his mission to “completely bullet-proof” the calculation so that it would “keep working in the face of ‘impossible'problems.”

In two years, with a lot of releases, McQuillan replaced the routing algorithms, the way acknowledgments worked, and eventually the whole IMP operating program. He built a completely different algorithm for flooding information about changes in the network very quickly to all the IMPs so they wouldn't make bad routing decisions. And he eliminated deadlock scenarios, partly by eliminating the infamous RFNM's from the equation.

“I knew all the computers on the network,” McQuillan said. “I knew where they were and what their numbers were and who was there and I knew them all by name.” By now there were nearly fifty IMPs on the
ARPANET
.

•   •   •

Something about a mail system, digital or otherwise, is inviting to those with a certain nonconformist temperament. Perhaps because there must be rules, some people will always try bending them. There was the clever fellow, for instance, who got away with using the U.S. Postal Service to mail bricks, one by one, to Alaska, until he had enough there to build himself a house; it was the cheapest way to ship them from the lower forty-eight states. Or there's Auntie Em, who embellishes her packages to her far-flung nieces and nephews with fanciful illustrations, to the probable amusement rather than consternation of the postal clerks. Somewhere in a thick book of fine print are the official postal regulations regarding U.S. mail—what can be sent, what can't, and how. But within limits, all manner of packages get delivered, because human mail clerks can adjust to a fairly wide latitude of nonconformity.

But imagine a local post office somewhere that decided to go it alone, making up its own rules for addressing, packaging, stamping, and sorting mail. Imagine if that rogue post office decided to invent its own set of ZIP codes. Imagine any number of post offices taking it upon themselves to invent new rules. Imagine widespread confusion. Mail handling begs for a certain amount of conformity, and because computers are less fault-tolerant than human beings, e-mail begs loudly.

The early wrangling on the
ARPANET
over attempts to impose standard message headers was typical of other debates over computer industry standards that came later. But because the struggle over e-mail standards was one of the first sources of real tension in the community, it stood out.

In 1973 an ad hoc committee led by MIT's Bhushan tried bringing some order to the implementation of new e-mail programs. Everyone knew that in the long run a separate mail-transmission protocol—independent of the FTP—was needed. Network mail was taking on a life of its own. It had its own technical problems. And it couldn't stay glued to FTP forever. But for now, just standardizing mail headers was enough of a headache.

Data packets on the
ARPANET
already had something called headers, but they were entirely different from e-mail headers. The headers on data packets were coded bits read strictly by the IMPs, telling them how to handle each packet as it came along. In the context of electronic mail, however, the header refers to a larger raft of information at the top of every e-mail message. The idea was that certain information should always appear at the top of messages in a specified format, really just an elaborate time and date locator, including information such as the time a message was sent and delivered, the route it traveled, other recipients to whom it was sent, and more. Bhushan's committee also suggested a syntax that would make it easier to read headers without the aid of a lot of special message processing.

Headers weren't always something seen only by the user. Some header fields were processed by receiving systems, programmed to deal with reserved meanings and very tightly defined syntax. If the recipient program somehow misinterpreted the sender's header, the results could be exceedingly frustrating. The reader program might stop dead in its tracks or spit out an error message. Dates, for example, were specified in a particular way, and deviations might be unintelligible. Or if you put a comma in the wrong place, your mail program's ability to process messages might go awry. When one mail handler couldn't parse headers sent by others, it was as if a postal clerk in Kenosha, Wisconsin, were being asked to deliver letters addressed in Sanskrit and Arabic.

Machines on the
ARPANET
encountered computer-language barriers of this kind regularly, and the problems multiplied with the growth in both the number of mail programs and the number of nodes on the Net. Depending on the kind of mail system one might use to send a message, an incompatible program or operating system at the receiving end would “barf up” the headers, as one observer put it. If the message got through, the person who received it still might have to deal with a garbled translation or screwed-up formatting. Recipients would complain about the sender. A sender might agree to fix the problem with a hack or kludge (“a kludge is a crock that works,” went one definition), if he had the time. Or, if he liked his own mail program well enough, he might simply complain about the recipient's.

Setting up an e-mail exchange was like asking someone out on a date. “E-mail was seen as something between consenting adults,” said Brian Reid, a computer scientist who was working on his Ph.D. at Carnegie-Mellon. A certain mature understanding was required. “I have an e-mail program, I want to send you mail, and you want to receive it,” he continued, “and as long as we agree on the standard, it's fine.” Many users of early fax machines went through the same kind of rigmarole making sure the sender's machine could communicate with the recipient's fax machine.

The problem occurred on a massive scale between Tenex and non-Tenex machines. Programmers at a few non-Tenex sites, like those working with machines based on the Multics operating system, continued introducing e-mail programs and features in the syntax of their own operating systems, and continued sending their messages out over the Net. Tenex machines, however, couldn't handle the syntax of other formats used at some sites, so again, conflict and confusion would result.

The diversity of nonstandard systems on the Net caused problems even with something as apparently trivial as Tomlinson's @ sign. The @ sign dispute was long-running, and there were many sides to it. There was disagreement over what should go on the left hand side of the sign and what should go on the right. But before that, there was the debate over whether it should even be used at all as the delimiter between the user and host names in the address.

The Multics folks objected vehemently when it was first used, understandably so. Tomlinson, a Tenex hacker, had chosen the @ sign without realizing, perhaps, that in the Multics system it was the character used to send a “line kill” command. Any Multics user who tried to send mail to “Tomlinson@bbn-tenex” would quickly get into trouble. Multics would start reading the address, encounter the @ sign, and throw away everything on the line that had been typed previously.

Ted Myer and Austin Henderson, from the BBN Tenex group, decided to try their hand at solving one of these compatibility issues, the header problem. In April 1975 they issued a new list of “standard” headers. The document, which they gave the title, “Message Transmission Protocol,” appeared as RFC 680.

But RFC 680 immediately created a ruckus among those who thought the effort too Tenex-oriented. Postel, keeper of the RFCs, whose quiet word was often final, wielded the gavel. RFC 680, he said, was as standard as mail ever got. “It is nice that many mail-reading programs will accept mail that does not conform to the standard,” he said, “but that does not justify mail-sending programs' violation of the standard.” If the standard is inadequate, he added, any proposals to change it are welcome.