history of communications

IEEE Communications Magazine • August 201026 0163-6804/10/$25.00 © 2010 IEEE

INTRODUCTION

It is impossible to place the origins ofthe Internet in a single moment of time.One could argue that its roots lie in theearliest communications technologies ofcenturies and millennia past, or thebeginnings of mathematics and logic, oreven with the emergence of languageitself. For each component of the mas-sive infrastructure we call the Internet,there are technical (and social) precur-sors that run through our present andour histories. We may seek to explain,or assume away, whatever range ofcomponent technologies we like. It isequally possible to narrow Internet his-tory down to specific technologies withwhich we are the most familiar.

There are also many individuals thatmay be said to have “predicted” theInternet. In 1908, Nikola Tesla foresaw[1] a technology that would allow “abusiness man in New York to dictateinstructions, and have them instantlyappear in type at his office in Londonor elsewhere” and would allow globalaccess to “any picture, character, draw-ing, or print.” Thirty years later, H. G.Wells articulated [2] his idea of a“World Brain” as “a depot whereknowledge and ideas are received, sort-ed, summarized, digested, clarified andcompared.” These ideas were followedby a 1945 essay [3] by Vannevar Bush,predicting a machine with collectivememory that he called the memex, withwhich “Wholly new forms of encyclope-dias will appear, ready-made with amesh of associative trails runningthrough them, ready to be dropped intothe memex and there amplified.”

These predictions, however, do nothelp us understand why the specificevents, innovations, people, and circum-stances that formed our Internetemerged when they did. Doing so is notpossible from the scale of centuries orsingle individuals. This column’s focus ison the defining inventions and decisionsthat separate early technologies thatwere clearly not the Internet, from awide range of recent inventions that mayhelp characterize our Internet, but werealso built within it. Thus, in this columnwe trace both the early history of the sci-ence and infrastructure that emerged asthe ARPANET, and the trajectory ofdevelopment it set for the even broaderconstruct that we now call the Internet.

As one of many individuals who par-ticipated in the Internet’s early history, I

also offer a personal account of thesame events, as an autobiographical ele-ment in this story. In doing so, I aim tofurther contextualize publications fromthe period — my primary source materi-als — with details from firsthand experi-ence. This perspective may add to ourdepth of historical understanding, inwhich the extent of personal detail doesnot imply a greater importance to theevents presented. In focusing on thework of individual researchers anddevelopers, I rely on the various publi-cations that followed the work of theseindividuals to link this story to the factu-al historical record we will follow. Thereare, of course, many important personaland institutional stories that have yet tobe told. The University of California atLos Angeles (UCLA) is heavily men-tioned in this column, as it was the siteof so much foundational work. I viewthis period as a synergistic surge of tech-nology, engineered by a magnificentgroup of researchers and developersamidst a defining period of challenge,creativity, invention, and impact.

BEFORE THE BEGINNING:TWO THREADS THAT MEET

The Internet did not suddenly appearas the global infrastructure it is today,and neither did it form automaticallyout of earlier telecommunications. Dur-ing the late 1950s and early 1960s, twoindependent threads were being woven.One was the research thread that even-tually led to the packet switching net-works of today’s Internet. This threadfollowed three possible paths to thetechnologies that eventually emerged;the researchers involved were, inchronological order, myself, Paul Baran,and Donald Davies. Below we explorethese three paths, which were indepen-dently pursued in the quest to providedata networking theory, architecture,and implementation. The second threadwas the creation and growth of theAdvanced Research Projects Agency(ARPA), the institution that fundedand deployed these technologies — aprocess that, as we will see, was by nomeans automatic. These two threadsmerged in the mid-1960s, creating thehistorical “break” that led to theARPANET. Once these threadsmerged, the implementation anddeployment phase began, bringing inother key contributors and successive

stages of development in Internet histo-ry. I present these threads and phaseschronologically so we can revisit thehistory as it unfolded. One may findelaborations on this history in two earli-er papers [4, 5]

THE RESEARCH THREADIn January 19571 I began as a graduatestudent in electrical engineering at Mas-sachusetts Institute of Technology(MIT). It was there that I worked withClaude Shannon, who inspired me toexamine behavior as large numbers ofelements (nodes, users, data) interact-ed; this led me to introduce the conceptof distributed systems control and toinclude the study of “large” networks inmy subsequent thesis proposal. In thatMIT environment I was surrounded bymany computers and realized that itwould soon be necessary for them tocommunicate with each other. Howev-er, the existing circuit switching tech-nology of telephony was woefullyinadequate for supporting communica-tion among these data sources. Thiswas a fascinating and important chal-lenge, and one that was relatively unex-plored. So I decided to devote my Ph.D.research to solving this problem, and todevelop the science and understandingof networks that could properly supportdata communications.

Circuit switching is problematicbecause data communications is bursty,that is, it is typically dominated by shortbursts of activity with long periods ofinactivity. I realized that any staticassignment of network resources, as isthe case with circuit switching, would beextremely wasteful of those resources,whereas dynamic assignment (I refer tothis as “dynamic resource sharing” or“demand access”) would be highly effi-cient. This was an essential observation,and in 1959 it launched my researchthread as I sought to design a new kindof network. Its architecture would usedynamic resource allocation to supportthe bursty nature of data communica-tions, and eventually provide a structurefor today’s packet-switched networks.

HISTORY OF COMMUNICATIONSEDITED BY MISCHA SCHWARTZ

AN EARLY HISTORY OF THE INTERNETLEONARD KLEINROCK

1 Later that year on October 4, I experienced awidely shared feeling of surprise and embarrass-ment when the Soviet Union launched Sputnik,the first artificial Earth satellite. In response,President Eisenhower created ARPA on Febru-ary 7, 1958 to regain and maintain U.S. techno-logical leadership.

LYT-HISTORY-August-Kleinrock 7/20/10 10:28 AM Page 26

IEEE Communications Magazine • August 2010 27

This concept of resource sharing wasemerging at that time in a totally differ-ent context: that of timesharing of com-puter power. Timesharing was based onthe same fundamental recognition thatusers generate bursty demands, and thusexpensive computer resources were wast-ed when a computer was dedicated to asingle user. To overcome this inefficien-cy, timesharing allocated the computerto multiple users simultaneously, recog-nizing that while one user was idle, oth-ers would likely be busy. This was anexquisite use of resource sharing. Theseideas had roots in systems like SAGE [6]and in the MIT Compatible Time-Shar-ing System (CTSS [7]), developed in1961 by Fernando Corbato (among thefirst timesharing systems to be imple-mented). The principles and advantagesof timesharing were key to my realiza-tion that resource sharing of communi-cation links in networks could providefor efficient data communications, muchlike the resource sharing of processors intimeshared systems was accomplishing.

In addition, there was already anexample of a special-purpose data net-work that used resource sharing: thestore-and-forward telegraph network.The challenge I faced was to create anappropriate model of general-purposedata communications networks, to solvefor their behavior, and to develop aneffective design methodology for suchnetworks.

To do this, I sought to develop amodel with dynamic resource sharing,incorporating the fact that data trafficwas unpredictable as well as bursty. Inorder to clear up some misconceptionsregarding what I and other investigatorswere doing in the field in the early days,I will devote some space in the follow-ing paragraphs to discuss the relation-ship between dynamic resource sharingand packet switching, where the latter isbut one of many ways to realize the for-mer. The basic structure I chose wasthat of a queue since it is a perfectresource sharing mechanism. A queueis dynamic, adaptive, and efficient, anddoes not wait for a message that is notthere, but rather transmits a messagealready waiting in the queue. Moreover,the performance measures one consid-ers in queueing theory are responsetime, throughput, efficiency, buffering,priorities, and so on, and these are justthe quantities of interest in data net-works. In the late 1950s, the publishedliterature contained almost no work onnetworks of queues. However, a singu-lar exception to this was the work byJames Jackson, who published a classicpaper [8] on open networks of queues.

As we see below, I was able to applyJackson’s result to represent the datanetworks of interest by making seriousmodifications to his model.

So the stage was set: There was aneed to understand and design general-purpose data communication networksthat could handle bursty data traffic,there was an emerging approach basedon resource sharing in timeshared sys-tems, there was an existing special-pur-pose network that suggested it could bedone, and there was a body of queueingtheory that looked promising.

As a result, I prepared and submittedmy MIT Ph.D. thesis proposal [9] inMay 1961, entitled “Information Flow inLarge Communication Nets” in which Ideveloped the first analysis of data net-works. I chose a queueing theoreticmodel based on Jackson’s model to char-acterize a data network as a network ofcommunication channels whose purposewas to move data messages from theirorigin to their destination in a hop-by-hop fashion. Each channel was modeledas a resource serving a queue of datamessages awaiting transmission; I dis-cussed how “The nets under considera-tion consist of nodes, connected to eachother by links. The nodes receive, sort,store, and transmit messages that enterand leave via the links….” My underly-ing model assumed that the stream ofmessages had randomly chosen lengthsand, when applied to data networks,yielded a problem whose exact solutionturned out to be hopelessly intractable. Ialtered the model and also introduced acritical mathematical assumption, theIndependence Assumption,2 whichtamed the problem and allowed for anelegant solution. With this solution, Iwas able to solve for the many perfor-mance measures of these networks. Forexample, I showed that by scaling up thenetwork traffic and bandwidth properly,one could reduce the system responsetime, increase the network efficiency,and increase the network throughput, allsimultaneously [10].

In the course of examining data net-work performance, it became clear tome that it was important to explore themanner in which mean response timewas affected when one introduced a pri-ority queueing discipline on the traffic. Ichose to understand this influence in thecase of a single node first and then toapply the results to the general networkcase. This led to a publication in April

1962, which turned out to be the firstpaper [11] to introduce the concept ofbreaking messages into smaller fixed-length pieces (subsequently named“packets,” as explained below). In it Iprovided a mathematically exact analysisof the mean response time, and showedthe advantages to be gained by utilizingpacket switching for this new network.3Note that the fixed length packets Iintroduced did not match the randomlychosen lengths of the model, but fortu-nately, the key performance measure Isolved for, the overall mean systemresponse time, did not require thatassumption, so the mathematical modelproperly reflected the behavior of fixedlength packets as well.

I also developed optimal design pro-cedures for determining the networkcapacity assignment, the topology, andthe routing procedure. I introduced andevaluated distributed adaptive routingcontrol procedures, noting that net-work/routing control is best handled bysharing control among all the nodesrather than relegating control to one ora small number of nodes. This dis-tributes the control load (thereby notunduly loading any one node), intro-duces the ability to change routes onthe fly dynamically (based on currentload, connectivity, and destinationaddress), enables the network to scaleto a very large number of nodes, anddramatically improves the robustness ofthe network.

Whereas my focus was not principal-ly on the engineering details of packetnetworks, I did address engineeringdetails when I built a complete networksimulation model and conducted exten-sive simulation experiments confirmingthe correctness of the theory. Theseexperiments included detailed messageblocks (with headers, origin and desti-nation addresses, priority indicators,routing labels, etc), dynamic adaptiverouting tables, priority queueing struc-tures, traffic specifications, and more.4

Packetization was an integral part ofa much broader body of knowledge thathad to be developed to prove the casefor data networks. Indeed, packetizationalone was not the underlying technology

HISTORY OF COMMUNICATIONS

2 Chapter 3 of my dissertation [16] elucidatesthis problem and the role of the IndependenceAssumption.

3 One of the important advantages of using pack-ets turned out to be that short messages wouldnot get “trapped” behind long messages; I wasable to show this gain in response time exactly.

4 Access to my simulation notes can be found athttp://ucla.worldcat.org/title/leonard-klein-rockscorrespondence-course-and-research-notes-1961-1972/oclc/263164964&referer=brief_results

LYT-HISTORY-August-Kleinrock 7/20/10 10:28 AM 7


28 IEEE Communications Magazine • August 2010

that led to ARPANET design funda-mentals. To be sure, packetization wasand remains a core element of today’snetworking technology, but it is not iden-tical to network efficiency. Rather, thefundamental gain lies in dynamicresource sharing. It is important to pointout that there are many ways in whichdynamic resource sharing can be accom-plished, with packet switching being onlyone such method; other methods includepolling [12], message switching [13],asynchronous time-division multipleaccess (ATDMA) [14], carrier sensemultiple access with collision detection(CSMA/CD) [15], and others.

I completed and filed my Ph.D. dis-sertation [16] in December 1962, havingcreated a mathematical theory of pack-et switching for dynamic resource shar-ing, thus providing the fundamentalunderpinnings for ARPANET technol-ogy. I showed that these networks wereefficient, stable, scalable, robust, adap-tive, and, most of all, feasible. Decadesof important research on these topicshave since taken place around theworld.

By the time my dissertation was pub-lished as the first book [17] on comput-er networks in 1964, the idea ofpacketization itself was appearing morebroadly. The next contributor to packetswitching was Paul Baran of the RANDCorporation, who was busy working onmilitary command and control systemsduring the early 1960s with the goal ofusing redundancy and digital technolo-gy to design a robust multilateral mili-tary communications network. Herecognized the vulnerability of the tele-phone network due to its centralizedarchitecture. In September 1962 hepublished a paper [18] on how “hotpotato” adaptive alternate routing pro-cedures and distributed principles couldutilize a “standard message block,” alsoto fall under the “packet” umbrella,which will be addressed below. His pur-pose was to create a network capable offunctioning after a Soviet nuclear attack[19]. In August 1964 he produced a setof 11 important reports [20] reinforcinghis prior description with simulationsand elaborating on many details of thedesign. He, too, discovered the impor-tance of going to digital networks andof the robustness provided by distribut-ed routing. He attempted to get AT&Tto implement the design, but failed toconvince them (presumably due to theiranalog mindset). In 1965 RANDapproached the Air Force to implementit, but they deferred to the DCA5; atthis point, Baran decided not to pursuethe implementation any further. Baran’s

work was done independently of thework that I had done earlier at MITand, in many ways, the results weachieved in addressing the problem ofpacket networks were complementary.

The third early contributor to packetswitching was Donald Davies, of theNational Physical Laboratory (NPL) inthe United Kingdom. He began think-ing about packet networks in 1965 andcoined the term “packet” that year. In aprivately circulated paper [21] datedJune 1966, he described his design for adata network and used my earlier theo-ry to calculate its performance. Davieslectured to a public audience in March1967, recommending the use of his tech-nology for the design of a publicswitched data network, and publishedan October 1967 paper [22] with hisNPL group in which details of thedesign were first described in an openpublication. This plan was for an NPLData Communications Network, but theU.K. Department of Trade and Indus-try only authorized the implementationof one node. That node became opera-tional in 1970. Further details of a fullnetwork design were described by theNPL team in 1968 [23, 24] and 1969[25]; it is not clear where a multiple-node deployment by this team mighthave led, but it obviously had potential.This reluctance to support an NPLpacket-switched network was reminis-cent of the view taken by AT&T andDCA in not supporting an implementa-tion of the RAND work.

The work of Baran and Daviesfocused on the engineering and archi-tectural issues of the network design.My work emphasized and provided themathematical underpinnings and sup-porting simulation experiments of thenetwork analysis and design, includingoptimization as well as formulating thebasic principles of packet networks thatinclude dynamic resource sharing; thisquantitatively showed that these net-works were feasible. My trajectory wasmore fortunate as the ARPA threadrolled out and adopted my principlesfor their design of the ARPANET, andprovided me the opportunity to partici-pate in its implementation and deploy-ment. Different trajectories were takenby Baran and then later by Davies, withBaran’s unsuccessful attempts to get hisideas implemented and with Davies’frustration by the foot-dragging of theU.K. government. It was not enough to

put good ideas forward, but it was alsonecessary to prove that the conceptswere quantitatively sound, and then toimplement and deploy an operationalnetwork that would bring these ideasand designs to use.

THE ARPA THREADLet us step back chronologically andnow pursue the second thread: the roleof ARPA in defining the need for adata network, putting the managementstructure in place to enable its develop-ment, and providing the funding neces-sary for its implementation anddeployment.

J. C. R. Licklider (“Lick”) enteredthe story when he published his land-mark 1960 paper [26] “Man-ComputerSymbiosis.” He defined the title as “anexpected development in cooperativeinteraction between men and electroniccomputers.” This work envisaged a sys-tem “to enable men and computers tocooperate in making decisions and con-trolling complex situations withoutinflexible dependence on predeter-mined programs”; he had seen such aflexible system in the aforementionedSAGE system. Once again, we find aforecast of what future telecommunica-tions might provide — and Lick wasperhaps the first to write at a time whenviable ways to create that future wereemerging. Although a visionary, Lickwas not a networking technologist, sothe challenge was to finally implementsuch ideas.

In May 1962 Lick and Welden Clarkoutlined their views on how networkingcomputers could support social interac-tion, and provide networked access toprograms and data [27]. This extendedhis earlier ideas of what he nowreferred to as a Galactic Network (infact, he nicknamed his group of com-puter experts “The Intergalactic Net-work”).

Lick was appointed as the first direc-tor of ARPA’s newly formed Informa-tion Processing Techniques Office(IPTO) in October 1962. He quicklyfunded new research into advancedcomputer and networking technologiesas well as areas that involved man-com-puter interaction and distributed sys-tems.

By the end of 1962, Lick had articu-lated his grand vision for the GalacticNetwork, of which I was unaware, and Ihad laid out the mathematical theory ofpacket networks, of which Lick was alsounaware. These ideas would soon inter-sect and reinforce each other in a seriesof key events between 1962 and 1969. Ijoined the UCLA faculty in 1963. Lick

5 Defense Communications Agency, which wasrenamed in 1991 to be today’s (2010) DefenseInformation Systems Agency — DISA.



passed the directorship of IPTO to IvanSutherland, an MIT colleague of mine, inSeptember 1964. In that role Sutherlandwished to connect UCLA’s three IBMmainframes in a three-node on-campuscomputer network, which would havebeen easy to accomplish with the meansI had laid out in my Ph.D. dissertation.However, the UCLA network was neverrealized due to administrative discord.Nevertheless, the seeds for an ARPA-funded network had now been sown.

Early the next year (1965), Suther-land awarded Larry Roberts (anotherMIT colleague of mine who was quitefamiliar with my networking research) acontract to create a dialup 1200 b/s dataconnection across the United States.Later that year, Roberts accomplishedthis in collaboration with Thomas Mar-ill, demonstrating that such a connec-tion required a different, moresophisticated network than the tele-phone network offered [28].

Meanwhile, at ARPA, Sutherlandrecruited Robert Taylor to becomeassociate director of IPTO in 1965.While there, Taylor also recognized theneed for a network, this time specifical-ly to connect ARPA research investiga-tors to the few large expensive researchcomputers across the country. Thiswould allow them to share each other’shardware, software, and applications ina cost-effective fashion.6 Taylor thendropped into the office of the ARPAdirector, Charlie Herzfeld, to requestfunding for this nascent networkingproject. Herzfeld was a man of actionwho knew how to make a fast decision,and within 20 minutes he allocated $1million to Taylor as initial funding forthe project. Taylor, who had since suc-

ceeded Sutherland as IPTO director inAugust 1966, brought in Roberts as theIPTO chief scientist that December.Bringing Roberts in to manage the net-working project turned out to be a criti-cal hire as Roberts was to contribute atall levels to the coming success of datanetworking.

The research and ARPA threadshad now merged, and the project wouldsoon become the ARPANET.

These were critical steps in Internethistory, for not even in the post-warUnited States did technological progressflow directly from ideas. In contrast torefusals from the private sector to fundthe beginnings of the project, ARPAmade available the will and funding ofthe U.S. government.7 ARPA’s man-agement and support fostered the earlyculture of shared, open research thatwas crucial to the success of theARPANET program.

THE BEGINNING: THEARPANET LAUNCH

The commitment to create theARPANET was now in play. Robertswas empowered to develop the networkconcept based on Lick’s vision, my the-ory, and Taylor’s application.

There were basically two matters tobe considered in this project. One wasthe issue of creating the switches andlinks underlying the network infra-structure, with the proper performancecharacteristics, including throughput,response time, buffering, loss, efficiency,scalability, topology, channel capacity,routing procedure, queueing discipline,reliability, robustness, and cost. Theother was to create the appropriate pro-tocols to be used by the attached (host)computers8 so that they could properlycommunicate with each other.

Shortly after his arrival, Robertscalled a meeting of the ARPA PrincipalInvestigators (PIs) in April 1967 at the

University of Michigan, whereARPANET planning was discussed indetail. It was there that the basic specifi-cations for the underlying network weredebated among us PIs. For example,Wesley Clark put forward the conceptof using an unmanned minicomputer ateach location to handle all of the switch-ing and communications functions; itwas to be called an Interface MessageProcessor (IMP). This would offload thenetworking functions from the host,greatly simplify the design by requiringonly one interface to be written for eachhost to the standard IMP, and at thesame time would decouple the networkdesign from any specific host hardwareand software. Another specification hadto do with the measure of reliability ofthe planned network; this we specifiedby requiring that the topological design9

produce a “two-connected net,” thusguaranteeing that no single failurewould cause any non-failed portion ofthe network to lose connectivity.

Yet another requirement we intro-duced was for the network to providean experience as if one were connectedto a local timeshared computer even ifthat computer was sitting thousands ofmiles across the network; for this wespecified that short messages shouldhave response times no greater than500 ms (the network design provided200 ms at its inception). Moreover,since this was to start out as an experi-mental network, I insisted that appro-priate measurement tools be includedin the IMP software to allow for tracingof packets as they passed across thenetwork, taking of snapshots of theIMP and host status at any time, artifi-cial traffic generation, gathering andforwarding of statistics about the net-work, and a mechanism for controllingthese measurements.

Following this April meeting,Roberts put together his outstandingplan for the ARPANET design and pre-sented it as a paper [29] at a conferencein Gatlinburg, Tennessee in October1967. At this conference, Roger Scant-lebury of the NPL also presented theiraforementioned jointly published paper[22] describing a local network theywere developing. It was during a con-versation with Scantlebury at this meet-ing that Roberts first learned of theNPL work as well as some details of thework by Baran at RAND. The researchby myself at MIT, by Baran at RAND,


6 This sharing of resources was the primarymotivation for creating the ARPANET. PaulBaran developed a network design (describedabove) that would maintain communications— and specifically, Second Strike Capability —in the event of a nuclear attack by the USSR.His and my work served different aims. WhenARPA began work on the ARPANET, my workwas used for the reasons described herein. Hisapplication to military communications gaverise to the myth that the ARPANET was creat-ed to protect the United States in case of anuclear attack. This is not to take away fromBaran’s accomplishments; indeed, by the timethe ARPANET began in 1969, he had movedon to different projects, including the Institutefor the Future (he stepped back into the ARPAforay in 1974–1975 to recommend that an earlycommercial version of the ARPANET be insti-tuted beside the original research-driven net-work).

7 In sharp contrast to ARPA’s enthusiasm fornetworking, in the early 1960s, when I intro-duced the ideas of packet-switched networks towhat was then the world’s largest networkingcompany, AT&T, I met with narrow-mindedand failed thinking, and was summarily dis-missed by them. They commented that packetswitching would not work, and even if it did,they wanted nothing to do with it. Baran had asimilar reaction from AT&T.

8 A major challenge for such a network was thatit would connect computers with incompatiblehardware and software.

9 To assist with the topological design, NetworkAnalysis Corporation (NAC), whose CEO wasHoward Frank, was brought in as a contractor.


30


IEEE Communications Magazine • August 2010

and by Davies, Scantlebury, et al. atNPL had all proceeded independently,mostly without the researchers knowingabout the others’ work. There was,though, some cross-fertilization: Davieshad used my analytical model for datanetworks in his work; as a result of dis-cussions at this conference, Robertsadopted Davies’ word “packet” for thesmall fixed length pieces I had suggest-ed we break messages into, and whichBaran referred to as “message blocks”;its fixed length was chosen to be 1024bits for the ARPANET design (bothBaran and Davies had suggested thissame length); as a result of the discus-sion with Scantlebury, Roberts decided[30] to upgrade the backbone line speedfrom 9.6 kb/s to 50 kb/s for theARPANET design.

Following these 1967 meetings, asequence of drafts for the IMP specifi-cation was prepared.10 This culminatedin March 1968 when Roberts and BarryWessler produced the final version ofthe IMP specification, which they thendiscussed at an ARPA PI meeting laterthat month. On June 3, 1968, theARPANET Program Plan [31] was for-mally submitted to ARPA by Roberts,and it was approved on June 21, 1968.The ARPANET procurement processwas now officially underway.

By the end of July 1968, a Request

for Quotation (RFQ) [32] for the net-work IMPs was mailed to 140 potentialbidders. The 19-node example to bedelivered by the contractor is shown inFig. 1.

The handling of data streams speci-fied that the hosts would communicatewith other hosts by sending messages(of maximum length 8192 bits) to theirattached IMPs, that these messageswould be broken into packets (of maxi-mum length 1024 bits each — thus, atmost 8 packets per message) by theIMP, and that IMPs would communi-cate with each other using these pack-ets. The movement of packets throughthe subnetwork of IMPs was to be con-trolled by a distributed dynamicallyupdated routing algorithm based on net-work connectivity and loading as well aspacket destination and priority. Errorsin packet transmission between IMPswere managed by error detection andretransmission. Packets were to bereassembled into their original messagesat the destination IMP before deliveryto the destination host. The basic struc-ture of this IMP specification containedcontributions from a number of individ-uals, including my own research.Roberts had been well aware of mywork since my time at MIT, where wewere officemates, later stating,11 “Inorder to plan to spend millions of dol-lars and stake my reputation, I neededto understand that it would work. With-out Kleinrock’s work of Networks andQueueing Theory, I could never havetaken such a radical step.” [33]

The RFQ resulted in 12 proposalsbeing submitted in August 1968 (notablymissing were IBM and AT&T). As theseproposals were being evaluated atARPA, Roberts awarded a research con-tract to me at UCLA in October to cre-ate the Network Measurement Center(NMC). The task of the NMC was tomeasure the behavior of the ARPANETby conducting experiments to determineits faults, performance, and outer limits(through the use of stress tests). I wasfortunate to have a star team12 of gradu-ate student researchers, developers, andstaff for this project; a number of theseappear in continued roles later in thisstory. A week before Christmas 1968,Bolt, Beranek and Newman (BBN) wonthe competitive bid and was awarded thecontract to develop the IMP-to-IMPsubnetwork. The BBN team,13 super-vised by Frank Heart, produced someremarkable accomplishments. This teamhad selected the Honeywell DDP-516minicomputer with 12 kb of memory forthe program to be the machine on which

Figure 1. 19-node ARPANET as shown in the original RFQ.

U. Utah Lincoln Lab

U. Michigan

ARPA network topology(example)

SDC

UCLA

RAND Stanford U.

UC Berkeley

SRI

UC Santa Barbara U.

Illinois

Proj. MAC Harvard U.

BBN

B.T.L.

Carnegie Mellon U.

Dartmouth College

Pentagon

Washington Univ.

10 Among those involved in these first draftswere Frank Westervelt, Elmer Shapiro, GlenCuller, and myself.

11 Roberts also goes on to say that my disserta-tion was “critical to my standing up to them andbetting it would work.”

12 Key members of my UCLA team included aresearch team (Jerry Cole, Al Dobieski, GaryFultz, Mario Gerla, Carl Hsu, Jack Zeigler), asoftware team (Vint Cerf, Steve Crocker, Ger-ard DeLoche, Charley Kline, Bill Naylor, JonPostel), a hardware engineer (Mike Wingfield),and others.

LYT-HISTORY-August-Kleinrock 7/21/10 2:40 PM Page 30

the IMP would be based; they were con-tracted to implement the IMP functionsby modifying the hardware and softwareof the DDP-516, to connect these IMPsto long-haul 50 kb/s lines leased byRoberts from AT&T under the DoDTelpak tariff, and to deploy the subnet-work. The BBN team developed an ele-gant host-IMP design that met theARPA specifications; this specificationwas written as BBN Report 1822 [34] byRobert Kahn, who was in charge of thesystem design at BBN (Kahn appearslater in this story in some very significantroles, as we shall see below). One of theBBN team, Dave Walden, points outthat he was most likely the first pro-grammer on the Internet by virtue ofhaving done code design for the IMP intheir 1968 response to the RFQ. Where-as members of the BBN team were busytesting the IMP’s ability to provide IMP-to-IMP data exchanges, testing thebehavior of a network of IMPs was diffi-cult to do in a laboratory environment;the true behavior was more properlytested in the deployed network with realtraffic and with many nodes, which isexactly what the NMC was designed todo. Basically, BBN was given less thannine months to deliver the first IMP to

UCLA by early September 1969. Theirperformance was outstanding. The firstIMP at UCLA was to be followed by thesecond IMP in October to SRI, the thirdIMP in November to the University ofCalifornia at Santa Barbara (UCSB),and the fourth IMP in December to theUniversity of Utah. The initial networkwas to be that shown in Fig. 2.

These four sites were selected due totheir ability to provide specialized net-work services and/or support. Specifical-ly, UCLA (connecting an SDS Sigma-7Host computer) would provide theNMC (under my supervision), SRI (con-necting an SDS 940 host computer)would provide Doug Englebart’s HumanIntellect Augmentation System (with anearly version of hypertext in his NLSsystem) as well as serve as the NetworkInformation Center (under Elizabeth[Jake] Feinler’s supervision), UCSB(connecting an IBM 360/75 host com-puter) would provide interactive graph-ics (under Glen Culler’s and BurtonFried’s supervision), and the Universityof Utah (connecting a DEC PDP-10host computer) would provide advanced3D graphics (under the supervision ofIvan Sutherland). The fact that Heartand his team at BBN succeeded in deliv-ering this new technology with newapplications and new users in an on-time, on-budget fashion was incredible.

But this contract to develop theunderlying network was only the first ofthe two key tasks that were needed to

deploy a working packet-switched net-work. Recall that the other task was tocreate the appropriate protocols to beused by the attached (host) computersso that they could properly communi-cate with each other.

This second task was assigned to thefour chosen ARPANET research sitesto figure out on their own. Thus begananother thread of innovative develop-ment that characterized the ARPANETculture. This thread actually begins inthe summer of 1968 when ElmerShapiro of SRI, in response to a requestby ARPA, called a meeting of program-mers from among those first sites thatwere to be connected into theARPANET. Their main charge was tostudy and resolve the issues of host-to-host communication. Present at thismeeting was one programmer fromeach of the first four sites to receiveIMPs as follows: Steve Crocker(UCLA), Jeff Rulifson (SRI), RonStoughton (UCSB), and Steve Carr(University of Utah). This group, plusthe many others who joined later, weresoon to be named the Network Work-ing Group (NWG) with Shapiro its firstchairman.14 UCLA’s Jon Postel servedas the Request for Comments (RFC)editor (a role he held until his untimelydeath in 1998). They had no officialcharter against which to work, and sowere afforded the unique opportunityto invent and create as needed. Therewas no sense of qualifying membership;all one had to do was to contribute andparticipate. Their focus moved to thecreation of high level interactions and,eventually, to the notion of a layeredset of protocols (transport servicesbelow a set of application-specific pro-tocols). Basically, this was a highlyresourceful, self-formed, collegial,loosely configured group of maverickgraduate students who we (the ARPAPIs) had empowered to design andimplement the protocols and softwarefor the emerging network. They took onthe challenge we ceded to them and



13 Key members of Heart’s team included BenBarker, Bernie Cosell, Will Crowther, RobertKahn, Severo Ornstein, Truett Thach, DaveWalden, and others.

14 The names of some of the other key individu-als who participated early on in the NWGinclude Bob Braden, Vint Cerf, Danny Cohen,Bill Duvall, Michel Elie, Jack Feinler, Jon Pos-tel, and Joyce Reynolds.

15 It is remarkable how effective the RFCs, theNWG and the IETF have served the networkcommunity. In spite of the fact that they areloosely structured and involve large numbers ofoutspoken professionals, they have been able tomove forward on a number of critical Internetissues.

Figure 2. The initial four-node ARPANET (1969).

XDS940

DEC PDP-10

UTAH

IMP

SRI

I M P

IBM360/75

UCSB

IMP

XDSX-7

IMP

UCLA



created an enduring NWG structurethat later led to today’s Internet Engi-neering Task Force (IETF).15

Once the IMP-host specification wasreleased by BBN in the spring of 1969,the NWG began to focus on the lower-level issues such as message formats.They decided to exchange ideas througha very informal set of notes theyreferred to as “Requests for Comments”(RFC). The first RFC [35], entitled“Host Protocol,” was written by Crockerin April 1969. Crocker became the sec-ond Chairman of the NWG early on.

We now had the two mainARPANET development efforts under-way:• A formal contract with BBN to cre-

ate the IMP-IMP subnetwork• An informal group of programmers

(mostly graduate students) whowere charged with developing theHost-to-Host ProtocolThings began to move rapidly at this

point. The date of the first IMP deliv-ery, scheduled to arrive to us at UCLAin early September 1969, was fastapproaching. Meanwhile, at the NMC,we were busy collecting data so that wecould predict performance of the net-work based on my earlier theory. Forthis, it was necessary to estimate thetraffic loads that the host sites wouldpresent to the network. Roberts and Icontacted a number of the early sitesand asked them how much traffic theyexpected to generate and to which othersites. We also asked them how muchtraffic they would allow into their sites;to my surprise, many refused to allowany traffic from the network to use their

hosts. Their argument was that theirhosts were already fully utilized servingtheir local customer base. Eventuallythey relented and provided their expect-ed traffic loads. That traffic matrix wasused in the July 1968 RFQ [32] and in apaper I published [36], thereby sealingtheir commitment.

On July 3, 1969, two months beforethe IMP was due to arrive, UCLA putout a press release [37] announcing theimminent deployment of theARPANET. In that release I describedwhat the network would look like, andwhat would be a typical application. Iam quoted in the final paragraph as say-ing, “As of now, computer networks arestill in their infancy, but as they grow upand become more sophisticated, we willprobably see the spread of ‘computerutilities,’ which, like present electric andtelephone utilities, will service individualhomes and offices across the country.”It is gratifying to see that the “computerutilities” comment anticipated the emer-gence of web-based IP services, that the“electric and telephone utilities” com-ment anticipated the ability to plug inanywhere to an always on and “invisi-ble” network, and that the “individualhomes and offices” comment anticipat-ed ubiquitous access. However, I did notforesee the powerful social networkingside of the Internet and its rapidly grow-ing impact on our society.

On Saturday, August 30, 1969, thefirst IMP arrived at UCLA. On Septem-ber 2, the day after Labor Day, it wasconnected via a 15-foot cable to theUCLA host computer, our SDS Sigma-7 machine. This established the first

node of the fledgling network, as bitsmoved between the IMP and the Sigma-7. This is often regarded as a very sig-nificant moment in the Internet’shistory.

In early October the second IMPwas delivered by BBN to SRI in MenloPark, California. The first high-speedlink of what was to become the Internetwas connected between those two IMPsat the “blazing” speed of 50 kb/s. Laterin October, SRI connected their SDS940 host computer to their IMP.

The ARPANET’s first host-to-hostmessage was sent at 10:30 p.m. on Octo-ber 29, 1969 when one of my program-mers, Charley Kline, and I proceededto “login” to the SRI host from theUCLA host. The procedure was for usto type in “log,” and the system at SRIwas set up to be clever enough to fillout the rest of the command, adding“in,” thus creating the word “login.”Charley at our end and Bill Duvall atthe SRI end each had a telephone head-set so they could communicate by voiceas the message was being transmitted.At the UCLA end, we typed in the “l”and asked SRI “did you get the l?”;“got the l” came the voice reply. Wetyped in the “o,” “did you get the o?,”and received “got the o.” UCLA thentyped in the “g,” asked “did you get theg?,” at which point the system crashed!This was quite a beginning. So the veryfirst message on the Internet was theprescient word “lo” (as in, “lo andbehold!”). This, too, is regarded as avery significant moment in the Inter-net’s history.

The only record of this event is an


Figure 3. The entry in the original IMP log, which is the only record of the first message transmission on theInternet.



entry in our IMP log recording it asshown in Figure 3. Here we see that onOctober 29, 1969, at 10:30 pm, we atUCLA “Talked to SRI Host to Host.”

In November and December theIMPs and hosts at UCSB and the Uni-versity of Utah were connected, respec-tively, thus completing the initialfour-node network. Further IMP deliv-eries were halted until we had anopportunity to test this four-node net-work, and test it we did. Among otherthings, we were able to confirm withmeasurements some of our theoreticalmodels of network delay and through-put as presented by Gerry Cole [38].

The ARPANET had now beenlaunched. We now turn to the story ofits rollout through its first decade.

THE FIRST DECADE:FOUR NODES ANDTHEN THE WORLD

By the time the first four nodes weredeployed in December 1969, Roberts(who had succeeded Taylor in Septemberto become the IPTO director) once againmet with the NWG and urged them toextend their reach beyond what they hadarticulated in their first RFC [35], “HostProtocol.” This led them to develop asymmetric Host-to-Host Protocol, thefirst implementation of which was calledthe Network Control Program (NCP)and was described by Crocker in RFC 36in March 1970 [39]. This protocol stackwas to reside in the host machines them-selves and included a hierarchy of lay-ered protocols to implement morecomplex protocols. As NCP begandeployment, the network users couldbegin to develop applications. The NCPwas the first protocol stack to run on theARPANET, later to be succeeded byTCP/IP. The trajectory of protocol stackdevelopment touched on below is anoth-er example of multiple possible pathsthat led the way from the ARPANET asit evolved into the Internet.

After the short evaluation periodfollowing the initial four-node deploy-ment, a continual succession of IMPsand networks were then added to theARPANET. In May 1970, at the AFIPSSpring Joint Computer Conference, alandmark session was devoted to thepresentation of five papers [40] regard-ing the newly emerging ARPANETtechnology; these papers were packagedinto a special ARPA pamphlet that waswidely circulated in the community andspread information of the then-currenttechnology that had been deployed.

(Two years later, in May 1972, anotherkey session at the same conference wasdevoted to the presentation of fivepapers [41] that updated theARPANET state of the art; this, too,was packaged into a second specialARPA pamphlet.) In mid-1970 the firstcross-country link was added with aconnection from UCLA to BBN, andby July the network contained 10 IMPs.The net grew to 15 IMPs by March1971. In September 1971 BBN intro-duced a terminal interface processor(TIP) that conveniently would allow aterminal to connect directly to theARPANET without the need to con-nect through an attached host. Later inthe year, BBN slipped in a “minor” fea-ture called electronic mail. Electronicmail had existed since the mid-1960s forstandalone timeshared computer sys-tems, but in late 1971 at BBN, RayTomlinson added a small patch to itthat allowed the mail to pass betweendifferent computers attached to theARPANET using an experimental file-sharing network program calledCPYNET. Once he saw that it worked,he sent an email message to his groupat BBN announcing this new capability,and so “The first use of network emailannounced its own existence.” [42].This capability went out as a generalTENEX release in early 1972. By July1972, Roberts added a managementutility to network email that allowedlisting, selective reading, filing, forward-ing, and replying to email messages. Inless than a year email accounted for themajority of the network traffic. The net-work’s ability to extend communicationbetween people was becoming evident,a nascent image of Lick’s vision.

Later that year, in October 1972, thefirst public demonstration of theARPANET technology took place atthe International Conference on Com-puter Communications (ICCC) inWashington, DC. Kahn, who by nowhad been hired into ARPA by Roberts,organized this large and very successfuldemonstration in which dozens of ter-minals in Washington accessed dozensof host computers throughout the Unit-ed States in a continuously reliablefashion for the three-day duration ofthe conference.

The reaction of the computer manu-facturers to this ARPANET phe-nomenon was to create proprietarynetwork architectures based on theirown brand of computers.16 The tele-

phone company continued to ignore it,but the open network that was theARPANET thrived.

Soon, additional networks wereadded to the ARPANET, the earliest ofwhich were those whose origins cameout of work on wireless networking.Connecting the ARPANET with thesedifferent networks proved to be a feasi-ble but not seamless interoperabilityissue, and it received a great deal ofattention. The interconnection of net-works was referred to as “internetwork-ing” during the 1970s, a neologism fromwhich the expanded ARPANET waseventually renamed as the Internet.

Let us briefly trace the work on wire-less networking that led to these addi-tional networks, which themselvesforced attention on improving interop-erability solutions. As pointed outabove, these networks were based onwireless multi-access communications inwhich a shared channel is accessed bymany users. By late 1970, Norm Abram-son had developed AlohaNet [43] inHawaii, a 9600 b/s packet radio netbased on the novel “unslotted (pure)ALOHA” multi-access technique ofrandom access. In this scheme (unsyn-chronized) terminals transmit theirfixed length packets at any time over ashared channel at random times; ifmore than one transmission overlaps(i.e., collides), then destructive interfer-ence prevents any of the involved pack-ets from succeeding. This tolerance ofcollisions was a departure from themore standard methods of wirelinecommunications to control multi-accesssystems that used demand access meth-ods (queueing, polling, etc., as men-tioned earlier) and allowed only onetransmission at a time (thus precludingsuch collisions). In 1973 Abramson cal-culated the capacity of the unslottedALOHA system [44], which had a maxi-mum efficiency of 18 percent, and in1972 Roberts calculated the capacity ofa synchronized version (i.e., slottedALOHA) [45] whose capacity was dou-bled to 37 percent. However, theseanalyses ignored an essential issue withrandom access to shared channels: thatthey are fundamentally unstable, andsome form of dynamic control wasneeded to stabilize them, for example, abackoff algorithm to control the way inwhich collided transmissions areretransmitted. This stability issue wasfirst identified and addressed by Lamand myself [46, 47].

It is interesting to note that theALOHA systems studies eventually ledto an investigation of carrier sense mul-tiple access (CSMA) as another wire-


16 Among the proprietary networks were IBM’sSNA and DEC’s DECnet.



less access method. CSMA itself ledRobert Metcalfe to consider a variationcalled CSMA with collision detection(CSMA/CD), which was the basis forthe original Ethernet development.Based on these concepts, Metcalfe andDavid Boggs implemented CSMA/CDon a coaxial cable network, which wasup and running by November 1973. Insum, they created the Ethernet, whichis today perhaps the world’s most per-vasive networking technology [48]. Eth-ernet is crucial to the story of NCP andTCP/IP, for researchers at Xerox PARCbuilt on this technology in efforts toaddress the challenges of internetwork-ing. Implemented in 1974 and publishedin 1975, the PARC Universal Packet(PUP) remained an internetwork archi-tecture as late as 1979 [49]. PUP wasone potential means through which toimprove on NCP, although as we seebelow, that role was later taken on byTCP/IP. This is one of many storiesthat call out for more research into thehistories and the individuals involved.

Let us now return to the story of theabove-mentioned wireless technologiesto help explain the motivation that ledto TCP/IP (as different from that whichmotivated PUP). These technologiesled to wireless networks that attachedto the ARPANET, thereby exposing thenature of the problems of supportingconnectivity among heterogeneous net-works.

The first step was taken in Decem-ber 1972, when an IMP in Californiaused a satellite channel to connect toAlohaNet through an ALOHA host inHawaii. Thus, the ARPANET, runningthe existing host-to-host Network Con-trol Protocol, NCP, was now connectedto a ground radio packet network, theAlohaNet. This was the first new net-work to connect to the ARPANET.AlohaNet had its own protocol and wasworking independent of ARPANET,yet a gateway provided internetworkconnectivity between the two. In 1972Roberts extended the ARPANET toNorway over a leased line that ARPAhad already installed to receive seismicdata and then extended it to London inthe United Kingdom. This was theARPANET’s first international connec-tion. In London Peter Kirstein thenbuilt a gateway to connect theARPANET to a network built withanother protocol between the U.K. uni-versities. This was another case of dif-ferent networks “internetworking,” andas this function became an increasinglyimportant focal point of ARPANETdevelopment, the network came to beknown as the Internet to reflect this

growth. NCP was now handling the net-work-to-network interconnection ofAlohaNet and the U.K. university net-work, both of which were attached tothe ARPANET. The problems resultingfrom interconnected heterogeneousnetworks were becoming clear, andincluded the network-to-network proto-col conversion needed between any(and every) pair of networks that wereinterconnected. It was clear that thecombinatorial complexity of this pair-wise protocol conversion would presentconsiderable problems as the number ofattached networks scaled up. TCP/IPwas soon to emerge as the responsechosen to address these problems.

At DARPA17 in early 1973, Kahnwas the program manager responsiblefor, among other things, the groundpacket radio network and the satellitepacket radio network. He recognizedthe differences between the ARPANETrunning NCP, and these two radio net-works. As a result, he set out to designa scalable end-to-end protocol thatwould allow dissimilar networks to com-municate more easily. In the summer of1973 Kahn discussed his approach fordealing with this internetwork complex-ity with Vint Cerf of Stanford who hadconsiderable knowledge of NCP, sincehe had been a key member of theUCLA software group involved in theNCP design. Together, they drafted adetailed design of a new protocol, theTransmission Control Program (TCP).TCP was to take over the NCP’s func-tions, but handle them in a more uni-form manner: it would allowapplications to run over an internet-work while hiding the differencesbetween network protocols by using auniform internetwork protocol. Theydistributed this design at a computercommunications conference held atSussex University in September 1973.(In October 1973 Roberts left IPTO tobecome CEO of TELENET, the firstcommercial packet switching networkcarrier.) By 1974, Cerf and Kahnfleshed out their design and published adefinitive paper [50] on TCP. Underly-ing TCP was the key idea of an opennetwork architecture that allowed pack-et networks of different types to inter-connect with each other and forcomputers to exchange informationend-to-end across these interconnectednetworks.

This contribution by Cerf and Kahnwas a critical step in the development

of the Internet. In 1973–1974 DARPAcommissioned three independent imple-mentations of TCP: Cerf at StanfordUniversity, Tomlinson at BBN, andKirstein at University College London.In addition, David Clark of MITworked on a compact version of TCPfor the Xerox Alto personal worksta-tion in the mid-1970s and later for theIBM PC desktop computer; DavidReed, also of MIT, was working oninternetworking among high-perfor-mance computers on LANs for the Lab-oratory for Computer Science Network(whose work was merged with the gen-eral TCP project in 1976). In August1976 these implementations led to thefirst experimentation using TCP to con-nect two different networks: the packetradio network using Stanford’s TCPimplementation, and the ARPANETusing BBN’s TCP implementation. Fol-lowing that, in 1977, Kahn implementedthe satellite reservation protocolRoberts had designed, creating a sec-ond path from the ARPANET to theUnited Kingdom, sharing the capacityof a 64 kb/s Intelsat IV satellite broad-cast channel among a number of groundstations in Europe and the East Coastof the United States. This AtlanticPacket Satellite Net (later to be calledSATNET) was the ARPANET’s secondinternational connection. This was thesecond two-network TCP demonstra-tion. Then a three-network demonstra-tion of TCP was conducted onNovember 22, 1977, when the packetradio network, SATNET, andARPANET were interconnected toallow an Internet transmission to takeplace between a mobile packet radiovan at SRI and a USC/ISI host comput-er (both in California) via an interconti-nental connection through UniversityCollege London. This impressive featwas the first three-network TCP-basedinterconnection.

This first version of TCP only sup-ported virtual circuits at the transportlevel (which is fine for applications thatrequire reliable transmission). But itfailed to support, among other things,real-time traffic such as packet voicewhere many aspects of the session flowwere more properly handled by theapplication as opposed to the network.That is, real-time traffic called for sup-port of an “unreliable” transportmechanism that would cope with missedpackets, packets with errors, out-of-order packets, delayed packets, and soon. The use of unreliable transport sup-port was already in use with NCP, priorto TCP; specifically, the earlyARPANET IMP protocol allowed for


17 ARPA was renamed DARPA in March 1972when the word “Defense” was prepended.



unreliable transport by use of what wascalled type 3 packets (also known as“raw” messages), which were intro-duced by Kahn in the BBN 1822 report.However, BBN was concerned that theuncontrolled use of these packets woulddegrade the network performance, sothey regulated the use of type 3 packetsto be on a limited, scheduled basis. In1973–1974 Danny Cohen of USC/ISIimplemented a Network Voice Protocol(NVP) [51] under ARPA support andrequested BBN to allow him to use type3 packets; with Kahn’s influence, BBNallowed this. Cohen’s real-time networkvoice experiments required the abilityto cope with unreliable data transport.The early Version 1 design of TCP in1974 did not support it, nor did Version2 when it was implemented around1977.

It was around this time that pressurefor supporting unreliable transport inTCP came from Cohen, now joined byJohn Shoch and Reed, and with involve-ment from Crocker and Bob Braden.That is, they advocated modifying TCPsuch that type 3 packet functionalitywould be supported alongside reliabledata transport. Cohen convinced JonPostel of this, and Postel added a fur-ther concern, addressing layer viola-tions, stating “We are screwing up inour design of internet protocols by vio-lating the principle of layering. Specifi-cally we are trying to use TCP to do twothings: serve as a host level end-to-endprotocol, and to serve as an Internetpackaging and routing protocol. Thesetwo things should be provided in a lay-ered and modular way. I suggest that anew distinct internetwork protocol isneeded, and that TCP be used strictly asa host level end to-end-protocol.” [52]Postel then went on to describe how tobreak TCP into “two components: thehop-by-hop relaying of a message, andthe end-to-end control of the conversa-tion.” A robust internetworking solutionwas no easy task, and today’s TCP/IPwas built with much experimentation onthe ground laid by NCP.

Thus, there was a clear call to cleaveTCP, splitting the function of network-layer connectivity, which involvedaddressing and forwarding, from itstransport-layer end-to-end connectionestablishment, which also involved flowcontrol, quality of service, retransmis-sion, and more. TCP Version 3 (1978)introduced the split into two compo-nents, but it was only in TCP Version 4(1980, with an update in 1981) that wesee a stable protocol running that sepa-rated out the Internet Protocol (IP)from TCP (which now stood for Trans-

port Control Protocol) and was referredto as TCP/IP. This version has come tobe known as IPv4. Along with the splitinto TCP and IP, the capability to sup-port unreliable transport (i.e., type 3packet functionality) was included. Theformal name for this unreliable trans-port support was the User DatagramProtocol (UDP) [53].

In 1980 the U.S. Department ofDefense (DoD) declared [54] theTCP/IP suite to be the standard forDoD. In January 1983, TCP/IP becamethe official standard [55] for theARPANET; after a short grace periodof a few months, no network wasallowed to participate in the Internet ifit did not comply with IPv4. Of course,Internet protocols never stop develop-ing, and the 1998 upgrade to Version 6dramatically extends the address spaceand introduces some significant securityenhancements. It is still in the processof being deployed worldwide.

Meanwhile, as the 1970s rolled out,in addition to the ARPANET andTELENET, other packet networks werebeing designed across the globe in thisperiod. Peter Kirstein, in his earlierpaper [56] in this IEEE Communica-tions Magazine History of Communica-tions series, addresses much of theinternational work, especially the U.K.story (to which we refer the reader formore details). As a result of thesenational and international activities, aneffort, spearheaded by Roberts, was putforth that resulted in the InternationalConsultative Committee on Telephoneand Telegraph (CCITT) Recommenda-tion X.25. This agreed-upon protocolwas based on virtual circuits — whichwas to be the CCITT’s own equivalentof TCP — and was adopted in 1976[57]. During this period, the NetworkMeasurement Center (NMC) at UCLAwas deeply involved in measuring, test-ing, stressing, and studying theARPANET. Bill Naylor and I publisheda summary of the tools used by theNMC as well as details of a weeklongmeasurement and evaluation of theresults in 1974 [58]. In 1976 I publishedthe first book that described theARPANET technology, including itsanalytical modeling, design, architec-ture, deployment, and detailed mea-surements. A summary of theARPANET principles and lessonslearned appeared in a 1978 paper [59]after almost a full decade of experiencewith the use, experimentation, and mea-surement of packet networks; this paperwas part of a special issue on packetcommunications which contains a num-ber of key papers of that era [60]. One

of the first measurements we made wasto determine the throughput fromUCLA to UCSB in the initial four-nodenetwork shown in Figure 2; note thatthere are two paths between these twonodes. Whereas only one path wastagged as active in the routing tables atany one time, we found that both pathswere carrying traffic at the same timesince queued traffic continued to feedone of the paths when the other pathwas tagged. Among the more spectacu-lar phenomena we uncovered were aseries of lockups, degradations, andtraps in the early ARPANET technolo-gy, most of which were unintentionaland produced unpredicted side effects.These measurements and experimentswere invaluable in identifying and cor-recting design issues for the earlyARPANET, and in developing a philos-ophy about flow control that continuesto inform us today. Moreover, it provid-ed us, as researchers, a wealth of infor-mation for improving our theoreticalmodels and analysis for more generalnetworks. In July 1975 responsibility forthe ARPANET was given to DCA. Thisterminated the systematic measure-ment, modeling, and stress testing thatthe UCLA NMC had performed foralmost six years, and was never againrestored for the Internet.18

It is outside the scope of this columnto address Internet histories beyondthose of its early period as theARPANET. Likewise, I have not donejustice to the untold stories thatabound, but I hope to have convincedthe reader that many people contribut-ed to its success. This early history ofthe Internet, the first decade of designand deployment of the ARPANET, laidfoundations on which today’s networksdepend and continue to develop.


18 The work of the NMC required a strongdegree of cooperation from BBN since it wasthey who controlled any changes to the networkcode and architecture. At the NMC, each timewe discovered a lockup, hardware problem, orother measured network problem, we alertedBBN so that they would take corrective action.Over time we developed an efficient workingrelationship with them, and errors were dealtwith more expeditiously. It is worthwhile notingthat the history of packet networks has met withinstitutional impediments to its progress, ashave so many other technical advances over thecourse of history. In this case I have called outthree with which I was personally involved:AT&T's lack of interest in packet switching, theresearchers’ reluctance to connect to the earlynetwork, and the above-mentioned negotiationwith BBN.



ACKNOWLEDGMENT

I want to thank Bradley Fidler, MischaSchwartz, and the reviewers of this col-umn for their helpful comments andsuggestions.

REFERENCES (A PARTIAL LIST OFSELECTED REFERENCES)

[1] W. W. Massie and C. R. Underhil l , “TheFuture of the Wireless Art,” Wireless Telegra-phy and Telephony, 1908, pp. 67–71.

[2] H. G. Wells, World Brain, Methuen & Co.Ltd., 1938.

[3] J. Nyce and P. Kahn, From Memex to Hyper-text — Vannevar Bush and the Mind’sMachine, Academic Press, Inc. 1991

[4] L. Kleinrock, “History of the Internet and ItsFlexible Future,” IEEE Wireless Commun.,Feb. 2008, pp. 8–18.

[5] B. Leiner et al., “The Past and Future Historyof the Internet,” Commun. ACM, vol. 40, no.2, Feb. 1997, pp. 102–08.

[6] K. C. Redmond and T. M. Smith, From Whirl-wind to MITRE: The R&D Story of The SAGEAir Defense Computer, The MIT Press, 2000.

[7] F. J. Corbató, M. M. Daggett, and R. C.Daley, “An Experimental Time-Sharing Sys-tem,” AFIPS Conf. Proc., vol. 21, 1962 SJCC,pp. 335–44.

[8] J. R. Jackson, “Networks of Waiting Lines,”Operations Research, vol. 5, no. 4, Aug.1957, pp. 518–21.

[9] L. Kleinrock, “Information Flow in LargeCommunication Nets,” Ph.D. thesis proposal,MIT, May 1961.

[10] L. Kleinrock, “Creating a Mathematical The-ory of Computer Networks,” INFORMS-Oper-ations Research, Jan.–Feb. 2002.

[11] L. Kleinrock, “Information Flow in LargeCommunication Nets,” RLE QuarterlyProgress Report, MIT, Apr. 1962.

[12] J. F. Kurose, M, Schwartz, and Y. Yemini,“Controlling Window Protocols for Time-Constrained Communication in a MultipleAccess Environment,” Proc. 8th Symp. DataCommun., Oct. 3–6, 1983, pp. 75–84.

[13] G. R. Andrews, “The Design of a MessageSwitching System: An Application and Evalu-ation of Modula,” IEEE Trans. Software Eng.,vol. SE-5, No. 2, Mar. 1979.

[14] W. W. Chu, “Demultiplexing Considerationsfor Statistical Multiplexors,” IEEE Trans.Commun., COM-20: 603–609, June 1972.

[15] L. Kleinrock, Queueing Systems, Volume II:Computer Applications, Wiley Interscience,New York, 1976

[16] L. Kleinrock, Message Delay in Communica-tion Nets with Storage, Ph.D. dissertation,MIT, Cambridge, MA, 1962.

[17] L. Kleinrock, Communication Nets; Stochas-tic Message Flow and Delay, McGraw-Hill,New York, 1964.

[18] P. Baran, “On Distributed CommunicationNetworks” Rand Paper P-2626, Sept. 1962.

[19] D. Hochfelder and P. Baran, An Oral Histo-ry, IEEE History Center, 24 Oct. 1999,http://www.ieeeghn.org/wiki/index.php/Oral-History:Paul_Baran#Institute_For_the_Future.2C_1967.2B

[20] P. Baran et al., “On Distributed Communi-cations,” The RAND Corporation, SantaMonica, CA, Aug. 1964.

[21] D. W. Davies, “Proposal for a Digital Com-munication Network,” unpublished memo,June 1966, http://www.archive.org/details/NationalPhysicalLaboratoryProposalForADigi-talCommunicationNetwork

[22] D. W. Davies et al., “A Digital Communica-

tion Network For Computers Giving RapidResponse At Remote Terminals,” ACM Symp.Op. Sys. Principles, Gatlinburg, TN, Oct. 1967.

[23] D. W. Davies, “The Principles of a DataCommunication Network for Computers andRemote Peripherals,” Proc. IFIP Hardware(Edinburgh1968) D1.

[24] R. A. Scantlebury, P. T., Wilkinson, and K.A. Bartlett, “The Design of a MessageSwitching Centre for A Digital Communica-tion Network,” Proc. IFIP Hardware (Edin-burgh 1968) D26.

[25] R. A. Scantlebury, “A Model for the LocalArea of a Data Communication NetworkObjectives and Hardware Organization,” Proc.1st ACM Symp., Problems in the Optimizationof Data Communications Systems, Pine Moun-tain, GA, Oct. 13–16, 1969, pp. 183–204.

[26] J. C. R. Licklider, “Man-Computer Symbio-sis,” IRE Trans. Human Factors in Electronics,vol. HFE-1, Mar. 1960, pp. 4–11.

[27] J. Licklider, and W. Clark, “On-Line Man-Computer Communication,” Spring JointComp. Conf., National Press, Palo Alto, CA,May 1962, vol. 21, pp. 113–28.

[28] T. Marill and Lawrence Roberts, “Toward aCooperative Network of Time-Shared Com-puters,” Fall AFIPS Conf., Oct 1966.

[29] L. Roberts, “Multiple Computer Networksand Intercomputer Communication,” ACMSymp. Operating System Principles, Gatlin-burg, TN, Oct. 1967.

[30] See the fourth entry under “1967” inhttp://www.packet.cc/

[31] L. Roberts, “Resource Sharing Computer Net-works,” June 3, 1968; http://ia310808.us.archive.org//load_djvu_applet.php?file=0/items/ResourceSharingComputerNet works/Resource-SharingComputerNetworks.djvu

[32] “Specifications of Interface Message Proces-sors for the ARPA Computer Network,”Department of the Army DBD/bj/OX 5-0494,July 29, 1968; http://www.cs.utexas.edu/users/chris/DIGITAL_ARCHIVE/ARPANET/RFQ-ARPA-IMP.pdf

[33] L. G. Roberts, http://www.ziplink.net/users/lroberts/SIGCOMM99_files/v3_document.htm

[34] “Interface Message Processor: Specificationsfor the Interconnection of a Host and anIMP,” BBN Report 1822; http://www.bit-savers.org/pdf/bbn/imp/BBN1822_Jan1976.pdf

[35] S. Crocker, RFC 1, “Host Protocol”;http://www.faqs.org/rfcs/rfc1.html

[36] L. Kleinrock, “Models for Computer Net-works,” Conference Record, IEEE ICC, Boul-der, CO, June 1969, pp. 21-9–21-16.

[37] T. Tugend, “UCLA to be first Station inNationwide Computer Network,” UCLA PressRelease, 3 July 1969. http://www.lk.cs.ucla.edu/LK/Bib/REPORT/press.html.

[38] G. C. Cole, “Computer Network Measure-ments; Techniques and Experiments,” UCLASchool of Engineering and Applied Science,Engineering Report UCLA-ENG-7165 Oct. 1971.

[39] S. Crocker, RFC 36, “Protocol Notes”;http://www.rfcarchive.org/getrfc.php?rfc=36

[40] Special session on the ARPANET in Proc.Spring Joint Comp. Conf., AFIPS Conf. Proc.,vol. 36, May, 1970, pp. 543–97:

L. G. Roberts and B. D. Wessler, “Computer Net-work Development to Achieve ResourceSharing,” pp. 543–49.

F. Heart et al., “The Interface Message Processorfor the ARPA Computer Network,” pp.551–67.

L. Kleinrock, “Analytic and Simulation Methodsin Computer Network Design,” pp. 569–79.

H. Frank, I. T. Frisch, and W. S. Chou, “Topologi-cal Considerations in the Design of the ARPANetwork,” pp. 581–87.

S. Carr, S. Crocker, and V. Cerf. “Host-HostCommunication Protocol in the ARPA Net-work,” pp. 589–98.

[41] Special session on the ARPANET in Proc.Spring Joint Comp. Conf., AFIPS Conf. Proc.,vol. 40, May, 1972:

S. M. Ornstein et al., “The Terminal IMP for theARPA Computer Network,” pp. 243–54.

H. Frank, R. Kahn, and L. Kleinrock, “ComputerCommunication Network — Design Experi-ence with Theory and Practice,” pp. 255–70.

S. D. Crocker et al., “Function-Oriented Proto-cols for the ARPA Computer Network,” pp.271–79.

R. H. Thomas, D. A. Henderson, “McROSS — AMulti-Computer Programming System,” pp.281–94.

L. G. Roberts, “Extensions of Packet Communi-cation Technology to a Hand Held PersonalTerminal,” pp. 295–98.

[42] R. Tomlinson, “The First Network Email,”http://openmap.bbn.com/~tomlinso/ray/firstemailframe.html

[43] N. Abramson, “The AlohaNet — Surfing forWireless Data,” IEEE Commun. Mag., vol. 47,no. 12, Dec. 2009, pp. 21–25.

[44] “The ALOHA System — Another Alternativefor Compute r Communication,” Proc. AFIPSFall Joint Comp. Conf., vol. 37, 1970, pp.281–85.

[45] L. G. Roberts, “ALOHA Packet System withand without Slots and Capture,” ARPA Net-work Info. Center, Stanford Research Inst.,Menlo Park, CA, ASS Note 8 (NIC 11290),June 1972.

[46] L. Kleinrock and S. Lam, “Packet Switchingin a Slotted Satellite Channel,” AFIPS Conf.Proc., vol. 42, Nat’l. Comp. Conf., New York,June 1973, AFIPS Press, pp. 703–10.

[47] S. Lam and L. Kleinrock, “Packet Switchingin a Multiaccess Broadcast Channel: DynamicControl Procedures,” IEEE Trans. Commun.,vol. COM-23,Sept. 1975, pp. 891–904.

[48] R. Metcalfe and D. Boggs “Ethernet: Dis-tributed Packet-Switching for Local Comput-er Networks,” Commun. ACM, vol. 19, no. 5,July 1976, pp. 395–404.

[49] D. R. Boggs et al., “Pup: An InternetworkArchitecture,” IEEE Trans. Commun., COM-28, no. 4, pp. 612–24, Apr., 1980, p. 26.

[50] V. G. Cerf and R. E. Kahn, “ A Protocol forPacket Network Interconnection,” IEEE Trans.Commun. Tech., vol. COM-22, V 5, May1974, pp. 627–41.

[51] D. Cohen, S. Casner, and J. W. Forgie, “ANetwork Voice Protocol NVP-II,” ISI/RR-81-90, Apr. 1981.

[52] J. Postel, “Comments on Internet Protocoland TCP,” IEN 2, 1977.

[53] J. Postel, “RFC 768 — User Datagram Proto-col,” 1980; http://www.faqs.org/rfcs/rfc768.html

[54] G. P. Dinneen, “Host-to-Host Data Commu-nications Protocols,” Apr. 3, 1980;http://www.potaroo.net/ietf/ien/ien152.txt

[55] J. Postel, “NCP/TCP Transition Plan,” RFC801, Nov. 1981; http : / /www.rfceditor.org/rfc/rfc801.txt

[56] P. T. Kirstein, “The Early History of PacketSwitching in the UK,” IEEE Commun. Mag.,vol. 47, no. 2, Feb. 2009, pp. 18–26

[57] T. Rybcznski, “Packet Switching(1975–1985): A Canadian Perspective,” IEEECommun. Mag., vol. 47, no. 12, Dec. 2009,pp. 26–31.

[58] L. Kleinrock and W. Naylor, “On MeasuredBehavior of the ARPA Network,” AFIPS Conf.Proc., vol. 43, National Comp. Conf., Chica-go, IL, May 1974, AFIPS Press, pp. 767–80.

[59] L. Kleinrock, “Principles and Lessons inPacket Communications,” Proc. IEEE, SpecialIssue on Packet Communications, vol. 66,no. 11, Nov. 1978, pp. 1320–29.

[60] Proc. IEEE, Special Issue on Packet Commu-nications, vol. 66, no. 11, Nov. 1978.



history of communications

Documents