Notes for Janet Abbate Inventing the Internet

Key concepts: adaptive routing, application layer, distributed computing, distributed network, host layer, interface message processor, message protocol, packet switching, protocol stack, Request for Comments, store and forward, subnet, virtual community.

Related theorists: Philip Agre, Paul Baran, Wesley Clark, Donald Davies, Douglas Engelbart, Joseph C. R. Licklider, Lev Manovich, Lawrence Roberts, Gene Rochlin, Sherry Turkle.

(1) The transcendence of geographic distance has come to seem an inherent part of computer technology. But in the early 1960s, when computers were scarce, expensive, and cumbersome, using a computer for communication was almost unthinkable. Even the sharing of software or data among users of difference computers could be a formidable challenge.

Practice and meaning of computing redefined by Internet long distance interaction, as Manovich argues emergence of personal computers led to cultural software.

(2) By making long-distance interaction among different types of computers common-place reality, the Internet helped redefine the practice and the meaning of computing.

Social construction: curious alliance of military and civilian interests, like taking a tank for a joyride.
(2) Like all technologies, the Internet is a product of its social environment. The Internet and its predecessor, the ARPANET, were created by the US Department of Defense's Advanced Research Projects Agency (ARPA), a small agency that has been deeply involved in the development of computer science in the United States. My curiosity about the Internet grew out of my experiences as a computer programmer in the mid 1980s, when few people outside the field of computer science had heard of this network. I was aware that the Internet had been built and funded by the Department of Defense, yet here I was using the system to chat with my friends and to swap recipes with strangers—rather like taking a tank for a joyride! This apparent contradiction goes to the heart of the Internet's history, for the system evolved through an unusual (and sometimes uneasy) alliance between military and civilian interests.
(2) The history of the Internet holds a number of surprises and confounds some common assumptions.
(3) The history of the Internet is not, therefore, a story of a few heroic inventors; it is a tale of collaboration and conflict among a remarkable variety of players.

Claim of unique SCOT approach applied to computer communication, involving narratives of origins, production and use.

(4) Relatively few authors have looked at the social shaping of computer communications. There have been many social and cultural studies of computing in recent years, including compelling analyses of networking by Sherry Turkle (1995), Gene Rochlin (1997), and Philip Agre (1998a,b), but these works tend not to examine in detail the origins of computer technologies, focusing instead on how they are used once they exist. In this book I hope to cross the divide that exists between narratives of production and narratives of use.
(5) My account of the origins of the network demonstrates that the design of both the ARPANET and the Internet favored military values, such as survivability, flexibility, and high performance, over commercial goals, such as low cost, simplicity, or consumer appeal. These values have, in turn, affected how the network has been managed and used.

Decentralized paradigm for proposing new features.
(5) Their dual role as users and produces led the ARPANET's builders to adopt a new paradigm for managing the evolution of the system: rather than centralize design authority in a small group of network managers, they deliberately created a system that allowed any user with the requisite skill and interest to propose a new feature. As access to the ARPANET and the Internet spread beyond the initial group of computer scientists, non-expert users also exerted influence, improvising new ways of using the network and deciding which applications would become standard features of the system and which would fade away.
(6) I believe that they key to the Internet's success was a commitment to flexibility and diversity, both in technical design and in organization culture.
(6) That is what the title of this book,
Inventing the Internet, is meant to evoke: not an isolated act of invention, but rather the idea that the meaning of the Internet had to be invented—and constantly reinvented—at the same time as the technology itself.

White Heat and Cold War: The Origins and Meanings of Packet Switching

Packet switching that has become dominant network practice arose in ARPANET and other early networks from margins to center.

(7) The successful use of packet switching in the ARPANET and in other early networks paved the way for the technique's widespread adoption, and at the end of the twentieth century packet switching continued to be the dominant networking practice. It had moved from the margins to the center, from experimental to “normal” technology.

Contested origins of packet switching include independent invention by Baran and Davies in US and England.

(8) Packet switching was invented independently by two computer researchers working in very different contexts: Paul Baran at the Rand Corporation in the United States and Donald Davies at the National Physical Laboratory in England. . . . it is easy to get the impression that packet switching simply took a detour through the United Kingdom before re-emerging, unchanged, in the United States to fulfill its destiny as the underlying technology of the ARPANET.

Adoption of packet switching dependent on social fit as much as technical criteria.

(8) Packet switching was never adopted on the basis of purely technical criteria, but always because it fit into a broader socio-technical understanding of how data networks could and should be used.

Networking Dr. Strangelove: The Cold War Roots of Packet Switching in the United States

The movie Dr Strangelove highlighted vulnerability of existing communication channels.

(9) Dr. Strangelove, though humorous, highlighted the vulnerability of the United States' communications channels to disruption by a Soviet attack, which might make them unavailable just when they were needed most. . . . Even before Dr. Strangelove opened, the Air Force was exploring a very different solution to the threat of a first strike: building a communications system that would be able to survive an attack and so that “proper command and control” could be maintained. . . . The need for “survivable communications” was generally recognized by the early 1960s.

Rand role in computer science research positioned it to develop military network communications.

(10) Rand's role was visible enough to be reflected in popular culture—for example, the fictional Dr. Strangelove turns to the “Bland Corporation” when he needs advice on nuclear strategy. Because its approach to systems analysis emphasized quantitative models and simulation, Rand was also active in computer science research.

Baran envisioned multiplexed, distributed communications using multiple formats and media.

(11) He envisioned a system would allow military personnel to carry on voice conversations or to use teletype, facsimile, or low-speed computer terminals under wartime conditions. The key to this new system was a technique that Baran called “distributed communcations.”
(11) In Baran's proposed system, each of several hundred switching nodes would be connected to other notes by as many as eight lines (figure 1.1). Several hundred multiplexing stations would provide an interface between users and the network.

Store and forward switching; see analysis of telegraph operations by Hayles.

(11) To move data through the network, Baran adapted a technique known as “message switching” or “store-and-forward switching.”
(13) For the postal and telegraph systems, message switching was more efficient than transmitting messages or letters directly from a source to a destination.

Adaptive routing allows distributed nodes to make use of their extra links.

(13) Since the nodes in a message switching system act independently in processing the messages and there are no preset routes between nodes, the nodes can adapt to changing conditions by picking the route that is best at any moment. . . . Baran realized that survivability depended on more than just having redundant links; the nodes must be able to make use of those extra links.

Departures from Other Contemporary Systems

Examining other state of the art messaging systems like ATT AUTOVON to tease out innovations of Baran ideas, in particular local intelligent routing of an all digital system using redundant components with lower quality communications links.

(13-14) Paul Baran was not the first to propose either message switching or survivable communications to the military. Systems of both types already existed or were in development. A look at the state of the art in these areas makes it easier to see what aspects of Baran's ideas were really innovative and why he saw opportunities to depart from contemporary practice in certain areas.
(16) One implication of Baran's design was that the nodes would have to have enough “intelligence” to perform their own routing—they would have to be computers, not just telephone switches. This brings us to Baran's second departure from the AT&T approach: Baran envisaged an all-digital network, with computerized switches and digital transmission across the links. . . . Digital signals, on the other hand, could be regenerated at each switch; thus, digital transmission would allow the use of many links without cumulative distortion and errors.
(16) Baran's system would push contemporary switching and transmission technology to their limits, so it is understandable that contemporary experts reacted skeptically to his claims.
(17) Baran chose instead to make do with lower-quality communications links to provide redundant components to compensate for failures.

Packet Switching in Baran's System

Packet switching method explained.

(17-18) Baran proposed that, rather than sending messages of varying sizes across the network, messages should be divided into fixed-size units that he called “message blocks.” . . . The multiplexer would add to each block a header specifying the addresses of the sending and receiving parties as well as other control information. . . . When the blocks reached their destination, the local multiplexer would strip the header information from each block and reassembled the blocks to form the complete message.

Baran more interested in building a distributed network for flexible transmission of bursty data, which called for time division multiplexing, than employing packet switching for its own sake.

(18) For all its eventual significance, the decision to transmit data as packets was not the original focus of Baran's work.
(19) But the biggest potential reward was efficient and flexible transmission of data.
(19) Since computer data tends to have this “bursty” characteristic, Baran felt that time division was a more “natural” form of multiplexing for data transmission. . . . Thus, he associated packet switching with time division multiplexing and its promise of efficient data transmission.
(20) Packet switching, as Baran understood it, made perfect sense in the Cold War context of his proposed system.

The Impact of Baran's Work

Baran presented and published his work, though academic computer scientists not focused on survivability.

(21) Following Rand's standard practice, Baran presented his work to various outside experts for comment as he was developing his ideas. . . . Most academic computer scientists were not concerned with the survivability of communications, and they may not have seen the applicability of Baran's research to their own interests.

Forging Packet Switching in the White Heat: Networks and Nationalism in the United Kingdom

Wilson in UK eager to enact economic and technological regime via Minitech.

(22) When Labour came to power in the 1964 general election, [Harold] Wilson was eager to act on his vision by implementing a new economic and technological regime for the United Kingdom.
(22) Minitech, as it came to be called, had two main aims: to transfer the results of scientific research to industrial development, and to intervene in industry so as to make private enterprise more efficient and competitive.

Davies priority was interactivity and user friendliness.

(23) If the watchword for Baran was survivability, the priority for Davies was interactive computing. Davies was one of many researchers who hoped to improve the user friendliness of computers.

Time sharing model addressed mismatch between human and computer paces of action.

(24) Batch processing rationalized the flow of input to the computer, but it was frustrating and inefficient for the programmer.
(24) By sharing the computer's processor among multiple users, time sharing addressed the mismatch between the pace of human action and the much faster processing of the computer.

Independent development in both UK and US, time sharing fomented excitement for interactive computing business models.

(25-26) The first proposals for time sharing operating systems were presented independently in 1959 by Christopher Strachey of the National Research Development Corporation in the United Kingdom and John McCarthy of the Massachusetts Institute of Technology in the United States. . . . Businesses began to spring up that offered access to time sharing machines on a commercial basis to customers who would rent or buy a terminal, connect to the service using a modem and a telephone line, and access the service's computers for an hourly rate. Many people thought that time sharing represented the future of interactive computing, since few if any anticipated the advent of small, inexpensive “personal” computers in the late 1970s.

Davies awareness of inadequate data communications for interactive computing led to ideas of packet switching.

(26-27) It was during these discussions that Davies became aware of a widely perceived obstacle to interactive computing: inadequate data communications. . . . As he thought about the data communications problem, he came up with the idea that a new approach to switching might offer a solution. . . . Davies proposed dividing messages into standard-size “packets” and having a network of computerized switching nodes that would use information carried in packet headers to route the packets to and from time sharing computers.

Packet Switching in Davies's System

Packet switching the communications equivalent of time sharing, achieving fairness in access.

(27) Packet switching, in his view, would be the communications equivalent of time sharing: it would maximize access to a scarce resource in order to provide affordable interactive computing.
(27-28) One of the merits he saw in packet switching was that it helped achieve fairness in access to the network. . . . This kind of fairness was appropriate for a system where computers were serving the everyday needs of civilians rather than transmitting life-or-death messages through a command hierarchy.

Davies wanted to commercialize packet switching under Wilson economic revitalization plan, proposing national network offering numerous civilian services.

(28) Ultimately, Davies thought, packet switching technology could become a commercial product that would contribute directly to Harold Wilson's plan to revitalize the British economy.
(29) In December of 1965, Davies proposed the idea of a national packet switching network that would provide inexpensive data communications across the United Kingdom. He envisioned the network as offering a number of services to business and recreational users, including remote data processing, point-of-sale transactions, database queries, remote control of machines, and even online betting.

Unable to gain support, Davies developed in house experimental network at National Physical Laboratory.

(29) Since Davies felt there was no hope of convincing the GPO to collaborate on a national network, he decided that a small in-house experiment would be the only feasible alternative.
(31) Through the network, NPL researchers could have remote access to computers for writing and running programs, for querying a database, for sharing files, for special services such as a “desk calculator,” and for “communications between people.” The system also included a file server and a “Scrapbook” application that provided document editing and communication tools.

Design focused on interface for providing remote resources to business people with identical access procedures as local resources, a concept ahead of its time.

(31) Most of the effort centered on the design of the network interface. This design was shaped by Davies's assumption that businesspeople would turn out to be the main users of networks.
(32) Using the network as a common communication channel for all components would make it possible for any pair of machines to interact. . . . Remote resources would be as easy to use as local ones, since the access procedures were identical. This was a radical concept in user interface design—a concept that would not become a commonplace feature of networked systems for another twenty years.

The Impact of Davies's Work

Davies Mark I had only local impact.

(33) The Mark I came to be used regularly by researchers at the National Physical Laboratory, and in 1973 Donald Davies's team introduced an upgraded version of the system called “Mark II.”
(33) But despite Davies's technical innovations and the local success of the system, the Mark I did not have the kind of influence that the ARPANET would have. Davies was never able to build the national network he had proposed, and the specific techniques used in the Mark I were not transferred outside the NPL.

Conversational Computing on the South Bank generated public debate and user activism.

(35) Well attended and widely reported in the press, Conversational Computing on the South Bank generated a public debate on the idea of building a national packet switching network.
(35) Eventually, the activism of computer users forced General Post Office authorities to develop data communication services. . . . The Wilson government had aimed to encourage the development and exploitation of British computing technology, but its failure to coordinate decision making with the researchers on the front lines of innovation had had—at least in the case of the NPL networking effort—the opposite effects.

Putting It All Together: Packet Switching and the ARPANET

IPTO [Information Processing Techniques Office] project office of ARPA funded establishment of computer science as a discipline in the US, and created research centers at universities whose connection the ARPANET intended.

(36) Throughout its existence ARPA has remained a small agency with no laboratories of its own. ARPA managers initiate and manage projects, but the actual research and development is done by academic and industry contractors. Recognized even by its critics for good management and rapid development of new technologies, ARPA has had some success in transferring its technologies to the armed services and the private sector.
(36) Computer science, not yet an established discipline in 1962, developed rapidly once IPTO began funding it. IPTO has been the driving force behind several important areas of computing research in the United States, including graphics, artificial intelligence, time sharing operating systems, and networking.
(37) IPTO created several computing research centers, giving large grants to MIT, Carnegie Mellon, UCLA, and other universities. By 1970, ARPA had funded a variety of time sharing computers located at universities and other computing research sites across the United States. The purpose of its proposed network—the ARPANET—was to connect these scattered computing sites.

Roberts adopted some of NPL packet switching design, then encountered Baran book on distributed communications leading to routing revelation.

(37) The ARPANET project was managed by Lawrence Roberts, a computer scientist who had conducted networking experiments at MIT's Lincoln Laboratory before joining ARPA in 1966.
(38) The NPL group influenced a number of American computer scientists in favor of the new technique, and they adopted Davies's term “packet switching” to refer to this type of network.
(38) Soon after returning to Washington from Gatlinsburg, Roberts had read Baran's
On Distributed Communications. Later he would describe this as a kind of revelation: “Suddenly I learned how to route packets.”
(39) The decision to employ packet switching on such a large scale reflected ARPA's commitment to high-risk research: if it worked, the payoff would be not only greater efficiency and ruggedness in the ARPANET itself, but also a significant advance in computer scientists' understanding of network properties and techniques.

The Social Construction of Packet Switching

Computer technologies become policy instruments in US and UK, though the US government was less inclined to manage domestic computer industry than UK.

(40) One thing that Baran, Davies, and Roberts had in common was the insight that the capabilities of a new generation of small but fast computers could be harnessed to transcend the limitations of previous communications systems.
(40) In the 1960s, computing technologies became policy instruments both in the United States and in the United Kingdom.
(41) The US government was less inclined to try to manage the domestic computer industry. Overall, Roberts had much more support and much less interference form his government than Davies had from his.

Packet switching seen as superior technique only after success of highly visible examples.

(41) Making packet switching work was not just a matter of having the right technical idea; it also required the right environment. Only after the ARPANET presented a highly visible example of a successful packet switching system did it come to be seen as a self-evidently superior technique.

Building the ARPANET: Challenges and Strategies

Licklider inspiration for ARPANET as logical extension of time sharing.

(43) The ARPANET was born from an inspiration and a need. The inspiration can be traced back to Joseph C. R. Licklider, the first director of ARPA's Information Processing Techniques Office (IPTO). . . . To many computer scientists, networking seemed like the next step in interactive computing and a logical extension of time sharing.
(36) For ARPA's manager, then, the network project represented a chance to pursue advanced research in a new branch of computer science, potential financial savings for the agency, and the fulfillment of a vision of interactive computing. These goals set the general outline of the proposed network.

Unique technical and managerial strategies by Roberts.

(47) To keep the project on track, Roberts deployed a unique set of technical and managerial strategies. Both the ARPANET itself and ARPA's approach to building it would have a lasting influence on the emerging field of computer networking.

Initial Challenges

Packet switching vetted by success of ARPANET.

(47) The fact that the eventual success of ARPANET was widely interpreted as a proof of the feasibility of packet switching indicates that the technique had not previously achieved wide acceptance.

Message protocol proposed to address variety of computers to be connected.

(48) Another unusual and potentially troublesome characteristic of the ARPANET was the great variety of computers it would connect.
(49) They proposed that each host computer implement a general-purpose set of rules for handling a network connection, which they called the “
message protocol(Marill and Roberts 1966, p. 428).

Resistance by PIs who did not want to lose control over computing resources.

(50) Many PIs did not want to lose control of their local computers to people at other sites, and they saw the network as an intrusion.

System-Building Strategies

Layered, decentralized, collegial management.

(51) Layering and a decentralized, collegial approach to management came to be seen by members and observers of the project as essential characteristics of the ARPANET, and were later held up as models for successful project development.


Layered system has technical and social implications; connect to diachrony in synchrony.

(51) A layered system is organized as a set of discrete functions that interact according to specified rules. . . . Each higher-level function builds on the capabilities provided by the layers below.
(51) Thus, layering has both technical and social implications: it makes the technical complexity of the system more manageable, and it allows the system to be designed and built in a decentralized way.

Division of labor plan by principal investigator Clark led to subnet of IMP minicomputers.

(52) In [Wesley] Clark's plan, the minicomputers, rather than the hosts, would form the nodes of the network and handle the packet switching operations. This network of minicomputers was designated the subnet. . . . Taylor endorsed the subnet scheme, and Roberts incorporated it into the ARPANET designs, calling the minicomputers “interface message processors(IMPs).
(52-53) The subnet design created a division of labor between the switching nodes (IMPs), whose task was to move packets efficiently and reliably from one part of the network to another, and the hosts, which were responsible for the content of those packets.

Protocol stack model.

(53) The “protocol stackmodel would quickly come to dominate the way people thought about organizing networks precisely because it offered a blueprint for reducing the complexity of network components while increasing the predictability of the system as a whole.

Informal Management

Network itself provided new methods of coordination, though still an old boy network.

(54) The network itself provided a new way to coordinate dispersed activities and came to function as a meeting place for the computer science community.
(54) The ARPA approach exhibited the weaknesses and the advantages of an “old boy” network.

Getting Started

Basic infrastructure of time sharing hosts, packet switching IMPs, and leased lines; contract from IMPs to BBN, other contracts awarded less formally.

(56-57) The basic infrastructure of the ARPANET would consist of time sharing hosts, packet switching interface message processors, and leased 56-kilobits-per-second telephone lines to connect the IMPs. The hosts were already in place and the lines would be provided by AT&T, so the main development task was to build the IMPs. . . . In early 1969, after considering bids from a dozen companies of all sizes, Roberts awarded the contract to the Bolt, Beranek and Newman Corporation of Cambridge, Massachusetts, a relatively small company specializing in acoustics and computing systems.
(57) Other contracts were awarded less formally.

Hope that Engelbart NLS at SRI would provide network information center.

(59) Engelbart was developing a database, a text-preparation system, and a messaging system with a sophisticated, user-friendly interface. Roberts hoped that, with such tools available, SRI would provide an easy-to-use information center for the network community.

Network Working Group supported UCLA PhD students Crocker, Cert, Postel under Kleinrock.

(59) At UCLA, which was particularly active in the NWG, Leonard Kleinrock was using ARPA money to support a number of Ph.D. students, including Stephen Crocker, Vinton Cerf, a Jon Postel, all of whom were to be important figures in the development of host software.
(60) The informal atmosphere of the project was, no doubt, attributable in large part of the many social ties among the contractors.

Managing Technical Complexity
Building the IMP: Putting Layering into Practice

Surprising reliability through acknowledgments and checksums using digital rather than analog system.

(61) Acknowledgments and checksums used the computing power of the IMP to give links a degree of reliability that many telephone engineers, on the basis of their experience with analog systems, had thought unattainable.

Routing the most difficult switching task, which was distributed so each IMP independently and adaptively decided where to send packets, making the system more robust, but also prone to unexpected interactions.

(61-62) Perhaps the most difficult packet switching task for the IMP was routing. In the ARPANET, routing was distributed: rather than having a central routing mechanism, each IMP decided independently where to send packets. . . . Distributed routing made the systems more robust by minimizing its dependence on any one component. Adaptive routing allowed IMPs to improve the speed and reliability of the network by avoiding congested routes and node or line failures. The price of relying on so many independent, constantly changing routing decisions, however, was a complex system prone to unexpected interactions.

Enforcement of distinctions between network layers became way to manage social relations and reduce technical complexity.

(62-63) But the design of the IMP was also shaped by the BBN group's strong beliefs about how it should perform in relation to the rest of the network. In particular, the BBN team tried to enforce the distinctions between network layers. . . . In the BBN vision, the IMP subnet was to be autonomous. Hosts would be isolated from failures in the subnet unless a host's own local IMP were disabled. . . . Nor would the people at the host sites be able to interfere with the operation of an IMP in any way. . . . As practiced by Heart and his group, the technique of layering became a way to manage social relations as well as to reduce technical complexity.

Remote monitoring and control and automatic recovery as key components of ideal distributed network.

(63) The team built into the IMP capabilities for remote monitoring and control that allowed BBN staff members to run diagnostic procedures or to reload software on an IMP without making field visits or relying on local operators. The IMP also was designed to recover from its own failures. . . . By anticipating and solving such day-to-day maintenance problems, the BBN team gave a practical form to the ideal of a distributed network.

Terminal IMP opened the network to users without ARPANET hosts.

(64) In 1971 (two years into the project), Roberts decided to make the network accessible to users whose sites did not have ARPANET hosts. He directed BBN to create a new version of the IMP, called a “terminal IMP” or a “TIP,” that would interface directly to terminals rather than to hosts.

Operating the Network: Redefining Responsibilities

NCC leader McKenzie promoted vision of ARPANET as computer utility, foreshadowing integration of computing and telecommunications systems; NCC managerial reinforcement of layering.

(65) The responsibility for providing user support fell to Alex McKenzie. . . . Believing that BBN should provide “the reliability of the power company or the phone company,” McKenzie (1990, p. 13) promoted a vision of the ARPANET as a “computer utility.”
(66) More generally, by building and operating its own switching network ARPA was able to control the characteristics of the communications system in such areas as cost, connection setup time, error rates, and reliability—areas in which computer users who relied on dial-up connections had little say. In this way the ARPANET represented a significant step toward integrating computing and telecommunications systems.
(66) The NCC had become a managerial reinforcement of ARPA's layering scheme.

Defining Host Protocols: A Collaborative Process

Host and application layers precursor to TCP/IP.

(67) Roberts suggested separating the host functions into two layers. The first, called the “host layer,” would feature a general-purpose protocol to set up communications between a pair of hosts; the second, called the “application layer,” would specify protocols for network applications such as remote login or file transfer.
(67) The host-layer protocol, implemented by a piece of software called the Network Control Program (NCP), was responsible for setting up connections between hosts.
(67) The NCP's design was shaped by assumptions about social and power relations in the networking community.

Core applications were telnet, ftp, and later, email; common formats for representing files and terminals addressed compatibility issues among different types of host machines.

(68-69) Telnet initially formed the basis for other services, including file transfer, but eventually the NWG created a separate file transfer protocol called ftp. Electronic mail was added to the system later, coming into general use around 1972. . . . In the process of working out applications that could run on different types of host machines, NWG members also addressed long-standing compatibility issues by developing common formats for representing files and terminals. These common formats became general purpose tools that aided users of both networked and non-networked computers.

Managing Social Issues

National social networks develped through workshops and retreats.

(69) By bringing researchers from around the United States together to work on pressing technical problems of mutual interest, PI retreats and graduate student meetings helped the social networks of computer scientists to become national rather than merely local.

BBN force by ARPA to make IMP source code freely available.

(70-71) To preserve its strategic advantage in having designed the IMP, BBN tended to treat the IMP's technical details as trade secrets. . . . The authorities at ARPA eventually intervened and established that BBN had no legal right to withhold the source code and had to make it freely available.

Disagreements between BBN and more theoretical groups, but in general the perceived joint effort argued to be unique in computer science at the time.
(71) The BBN team often had disagreements with the more theoretical groups at UCLA and at the Network Analysis Corporation.
(72) In a 1972 conference paper, representative of the three main contractors—Howard Frank of NAC, Robert Kahn of BBN, and Leonard Kleinrock of UCLA—described how the ARPANET had provided a rare opportunity for collaboration across disciplines. They perceived their joint effort as something unique in computer science.

Preserving Informality: The Network Working Group

Roberts entrusted creating host protocols to relatively inexperienced researchers of the Network Working Group, which developed Requests for Comments as means of disseminating technical proposals to promote informal communication and sharing of ideas; informal evolution of formal standards though RFCs and NWG meetings.

(73) One of the most important mechanisms for pooling efforts and building consensus among the scattered sites was the Network Working Group. In assigning the NWG to create the host protocols, Lawrence Roberts had entrusted an important aspect of the system to a group of relatively inexperienced researchers.
(74) The NWG developed its own social mechanisms to ease the challenges it face. Acting on a suggestion by Elmer Shapiro, Crocker proposed that technical proposals and minutes of meetings be distributed as a series of documents called Requests for Comments (RFCs). Another UCLA student, Jon Postel, took on the job of editing these documents. The RFCs were specifically designed to promote informal communication and the sharing of ideas in the absence of technical certainty or recognized authority. . . . Eventually, after members had debated the issues through RFCs and at NWG meetings, a consensus would emerge on protocols and procedures, and this consensus was generally accepted by ARPA as official policy for the network. RFCs enabled the NWG to evolve formal standards informally.

Shaping the Political Environment

ARPA managers shielded research projects from often conflicting national politics while presenting pragmatic and security reasons to Congress for supporting projects.

(75) To a large extent, ARPA managers were able to shield their research projects from national politics, which sometimes conflicted with the agency's own priorities.
(76) Though ARPA unquestionably played an important role in advancing basic computer research in the United States, the agency was careful to present Congress with pragmatic economic or security reasons for all its projects. It often characterized the ARPANET as an administrative tool for the military rather than an experiment in computer science.
(76) Although ARPA's concern for defense applications and cost savings was genuine enough, the agency's disavowal of basic research was more rhetorical than real.

Computer scientists perceived ARPA as offering large degree of intellectual freedom.

(77) Obviously, ARPA contractors did not have absolute intellectual freedom. . . . However, during the period during which the ARPANET was built, computer scientists perceived ARPA as able to provide research funding with few strings attached, and this perception made them more willing to participate in ARPA projects. The ARPA managers' skill at constructing an acceptable image of the ARPANET and similar projects for Congress ensured a continuation of liberal funding for the project and minimized outside scrutiny.

Launching the System

Connecting a host to the subnet the primary obstacle, but public interest in networking also needed to be increased, inspiring ICCC.

(78) The obstacle was the enormous effort it took to connect a host to the subnet.
(79) By the time the First International Conference on Computer Communications opened, enough programs were ready to capture the attention of the crowds.

ICCC demo featured numerous interesting uses of networked applications and remote communications, a turning point in use of the ARPANET spanning commercial services and training a generation of American computer scientists in its techniques.

(79) From a demonstration area containing dozens of computer terminals, attendees were able to use the ARPANET to access computers located hundreds or thousands of miles away; there was even a temporary link to Paris. Software on these computers allowed participants to try out meteorological models, an air traffic simulator, conferencing systems, a mathematics system, experimental databses, a system for displaying Chinese characters, a computerized chess player, Joseph Weizenbaum's psychiatrist program Eliza, and a variety of other applications.
(79) “It was a watershed event that made people suddenly realize that packet switching was a real technology,” recalled Kahn.
(80) The ICC demonstration marked a turning point in the use of the ARPANET. . . . Telenet was the first network to reach the market, initiating service to seven US cities in August 1975. These new networks began to offer the general public the kind of reliable, cost-efficient data communications that the ARPANET had provided for a select few.
(81) The ARPANET would train a whole generation of American computer scientists to understand, use, and advocate its new networking techniques.

“The Most Neglected Element”: Users Transform the ARPANET

Predictions by APRA about users benefits were wrong, so its success needs explained rather than taken for granted, focusing on active users who played a role in its development; go beyond simple view of consumers amassing after a technology has been delivered to the market.

(83) A number of diverse groups did make productive use of the ARPANET in the early 1970s, but other potential users were excluded or discouraged from using it, and many of ARPA's original predictions about how the network would benefit users turned out to be wrong. The fact that the network became so successful is not something to be taken for granted, but rather something to be explained.
(83) In any case, it is generally assumed that users become involved after a technology has already been developed. But the ARPANET's ultimate “consumers”--the researchers who were to use it in their work—were directly involved in its development. . . . The ARPANET provides an instructive example of the variety of active roles users can play in shaping a new technology, and of the sometimes surprising results of their involvement.

By No Means Complete or Perfect”: The ARPANET as Experienced by Early Users

Challenge of using early ARPANET, contrary to ease of access and use taken for granted today with the Internet, transformed by virtual communities built by experiments building features like sharing information, support, recreation in the network environment.

Consider Turkle critique of virtual communities against heroic struggle to create new ways of interacting.

(84) Computer networks provide access to cyberspace, which appears as a welcoming, even playful environment in which newcomers receive instruction and encouragement from their fellow users.
(84) The conditions encountered by the ARPANET users of the early 1970s stand in stark contrast to this rosy picture.
(84) One challenge in making the ARPANET user friendly lay in translating activities that build community—sharing of information, support, recreation—to the network environment. In taking these steps for the first time, early users of the ARPANET laid the groundwork for future virtual communities.

Reliance on local knowledge led to development of online documentation, system announcements, email support that spread virtual community and became our habitual practices of interactivity.

(89) Since most of the software available on the ARPANET had been developed as part of some local research project rather than as a commercial product, instruction and support tended to rely on informal local interactions. . . . In response to requests for help from ARPANET users, some sites began supplementing or replacing older means of support with online documentation, system announcements sent to each user's terminal, the ability to query support staff by email, and/or methods for “linking” terminals so that the user and the remote system operator would see the seam screen output and could work through a problem together.

Ironic that TIP users wanted features of synchronous batch terminal designed for batch processing.

(91) The most common complaint was the the TIP would handle only terminals for interactive computers (“asynchronous” terminals), while many people wanted to use terminals designed for batch processing computers (“synchronous” terminals).

ANTS terminal and peripheral interface was too difficult to debug and maintain.

(92) Even before BBN had begun providing TIPs, some users had taken the initiative to build their own terminal interface machines. . . . The system accommodated a wider range of terminals than the TIP, including the synchronous terminals typically used with batch machines. ANTS also allowed users to access other types of peripherals not supported by the TIP: users could read in data from punch cards, disks, or tapes for transmission across the network, and incoming data could be stored on these media or sent to local printers.
(92-93) However, as BBN had warned, ANTS proved difficult to debug and maintain in the field. Furthermore, its complexity hindered transfer of the technology, and only a few sites ended up using it.

New Communication Paths

MIT turned its IMP into hub for a LAN, supporting many unplanned uses of ARPANET devised by its users, increasing its perceived value.

(93-94) No one had envisioned such a use of the ARPANET, and BBN's network monitors were puzzled when they started to notice that there was heavy traffic at the MIT IMP but not over MIT's outgoing lines. Eventually they realized that the MIT users had, in effect, turned their IMP into the hub of a local-area network (LAN). . . . A spontaneous innovation by users had contributed substantially to the use of the ARPANET and hence to its perceived value. Sites continued to use the ARPANET as a local-area network until “real” LANs based on Ethernet technology became available in the 1980s (McKenzie 1997).
(94) Some users also created unusual or even illicit links between the ARPANET and other data communications systems.

New Applications

Failure of organized lobbying by USING.

(95) In November of 1973, as enthusiasm for the network was beginning to grow among the ARPANET community, a group of systems developers who wanted to improve network services formed the Users Interest Working Group (USING). Members of this group began to critique the difficulty of using the network, and they lobbied ARPA to support the development of more and better applications.
(95) The fate of USING revealed the limits of ARPA's generally non-hierarchical management approach. Individual users or research teams had tacit or explicit permission to add hardware and software to the system; ARPA even gave financial support for some of these experiments. However, users as a group had no say in the design decisions or funding priorities of the ARPANET project.

Datacomputer as early specialized network resource meant to dominate future of computing; Lanier siren server the model that succeeded.

(98) On large resource that had been explicitly designed for the ARPANET was the Datacompuer, a database system located a the Computer Corporation of America in Cambridge, Massachusetts. . . . He [Lawrence Roberts] held that in a networked environment host sites would tend to become specialized to take advantage of economies of scale, and that the availability of these specialized resources would eventually make the general-purpose computer obsolete. The Datacomputer was meant to be an example of the specialized resources that would dominate the future of computing.

Unexpected advantages of networked computing by giving researchers access to other machines, programming languages, and services.

(99) However, after being forced by economies to give up their local machine, the researchers found that networked computing had some unexpected advantages. Programmers could choose from diverse machines offering a range of services, including time sharing, fast calculation, and graphics routines.

Who Benefited?

Information sharing and enhanced collaboration noted by computer scientists as key benefits of networking, transforming how science was done; did their anonymous transfers and software theft become cultural norm?

(100) The ARPANET changed the way computer scientists worked and the types of projects that were feasible. . . . In a 1986 Science article, several computer scientists noted: “The major lesson from the ARPANET experience is that information sharing is a key benefit of computer networking. Indeed it may be argued that many major advances in computer systems and artificial intelligence are the direct result of the enhanced collaboration made possible by ARPANET” (Jennings et al. 1986, p. 945).
(101) Most collaborative projects involved the transfer of files containing documents or programs. A procedure for anonymous file transfer, implemented early on, made it possible to leave files in a “guest” account for anyone who wished to retrieve them. This allowed files to be exchanged informally, even without the originator's knowledge. The Stanford computer scientist Les Earnest recalled: “Another thing that happened a lot in the 1970s was benign theft of software.”

The Decline of the Ideal of Resource Sharing

Ideal of resource sharing declined, and distributed computing never materialized; did need for administration of distributed computing resources lead to siren servers?

(104) As the 1970s progressed, the demand for remote resources actually fell.
(104-105) Many had expected that the network would be used for “
distributed computing.” . . . Aside from the fact that there were incompatibilities between computers, the technical vision of distributed computing did not mesh with the administrative reality of using computer resources.

Social value of email practiced within ARPA and DoD.

(107-108) Within the ARPA office and in the wider Department of Defense community, the use of email was vigorously promoted by Roberts and by ARPA director Stephen Lukasik. . . . Roberts found that email helped him overcome obstacles of time, space, and social distinctions in managing ARPA's many computer contracts.

Email a surprise success because network built for providing computer access shifting to connecting people.

(109) Why then was the popularity of email such a surprise? One answer is that it represented a radical shift in the ARPANET's identity and purpose. The rationale for building the network had focused on providing access to computers rather than to people.

Users did not collaborate like model promoted by SRI NIC, using mostly email and file transfer due to their simplicity compared to NLS developed by Engelbart.

(109) But Roberts and others had expected users to collaborate by sharing files and programs for by using the centralized bulletin boards at SRI's Network Information Center. To help the NIC fill this role, Douglas Engelbart had created NLS, an information resource that provided a sophisticated environment for creating databases and conducting online discussions . . . Had NLS been easier to use, it might perhaps have become the preferred method of communication, rather than email.

User centered design through participation of non-expert users promoted by Lukasik such as adding features to mail readers since email was the most popular non-expert use.

(109-110) Computer experts put the first email programs in place, but non-expert users also had a role in building this new capability. In particular, ARPA director Stephen Lukasik used his influence to make sure that new features were added to the mail readers, so that a network tool that had been designed for computer scientists would meet the needs of other users.

Mailing lists credited for creating and maintaining ARPANET user virtual community; compare to recent criticisms of using same term as locally congregating physical personal communities, as computer programming language is also noted as an ambiguous equivocation with human natural languages.

Virtual communities provided new substantiation of humans forming communities through shared interests without respect to bodily proximity.

(110) Email and mailing lists were crucial to creating and maintaining a feeling of community among ARPANET users. . . . Even more important, mailing lists allowed a virtual community to take on an identity that was more than the sum of the individuals who made it up. . . . Mailing lists provided a way for people to “meet” and interact on the basis of shared interests, rather than relying on physical proximity or social networks.

The ARPANET Remade

Email use and participation in virtual communities altered common perception of ARPANET as communications system more than computing system, that is, a place for running programs; here computing descended into background both as internalizing interface use, evolved behavior Thrift attributes to coaction of technical unconscious with human endeavor.

(111) Email laid the groundwork for creating virtual communities through the network. Increasingly, people within and outside the ARPA community would come to see the ARPANET not as a computing system but rather as a communications system.

Abbate, Janet. Inventing the Internet. Cambridge, MA: The MIT Press, 1999. Print.