News
Architecture and Hardware ACM at 60: a look back in time

SIGCOMM’s Archaeological Journey Into Networking’s Past

Documenting the technical history of a SIG is indeed a priceless resource.
Posted
  1. Introduction
  2. Planning the Tutorial
  3. Examples of Pioneers' Presentations
  4. Primary Sources
  5. Research-Grade Oral Histories
  6. Planning a History Event
  7. References
  8. Author
  9. Footnotes
  10. Sidebar: For SIGs, There are Many Options, but Get Expert Advice

In 1999, as part of the annual ACM conference for the Special Interest Group on Communication (SIGCOMM), a extraordinary event took place: the first Technical History of the Internet Tutorial, which featured 19 network pioneers as presenters. As SIGCOM’s Conference Coordinator, I was a member of the team that planned the tutorial. I also edited the tutorial notebook, filling it with early networking materials contemporaneous to the original design timeframe. My initial interest in those sources has grown into an archaeological exploration of early network history. Since that tutorial, I have visited four network archives to find primary sources, read all the oral histories on networking, enjoyed the scholarly texts by historians, and introduced students to network-history research.

My specific goal here is to convey that it is within a SIG’s reach to collect hard-to-find primary sources, to create a digital archive of a subset of those materials, and to create or sponsor well-researched oral histories. While these resources can be collected without hosting a history event, the SIGCOMM99 Tutorial was the catalyst to collecting these primary sources and recording the pioneers’ presentations. SIG members, as well as historians and biographers, will benefit from these priceless resources in the years ahead.

I am particularly interested in writing technical histories on early network designs and synthesizing the early concepts with today’s perspective. Technical history is relevant for the insights I gleaned about the participants, their design decisions, and trade-offs. Are there mistakes that should not be repeated? Are there designs, that failed early on, whose time has come? The network history examples noted in this article illustrate insights to be gained from a technical history.

The impact of the SIGCOMM99 Tutorial is still felt today. Indeed, the annual keynote presentation by the SIGCOMM Award winner is now routinely archived. Pioneer Bob Braden suggested the community create an Internet history mailing list, now hosted by USC ISI’s Postel Center.1 Under the umbrella of the THINK Protocols project [12], I have built a digital archive with support from SIGCOMM and the Postel Center. In addition, undergraduate research students have written technical histories, bibliographies, and timelines aimed to introduce undergraduates to research.

This article describes the tutorial, explores the roles of primary sources and oral histories infused with networking examples, suggests history events a SIG could host, and offers a few simple tips for SIGs on how to proceed. Any history project will benefit greatly from advice by archivists, digital librarians, historians, and the resources available from the ACM History Committee.2

Back to Top

Planning the Tutorial

In March 1999, while selecting tutorials for the conference, SIGCOMM99 Tutorial Chair Ellen Zegura proposed creating an Internet technical history tutorial that would recapture early discussions and design decisions in the field. Her suggestion resonated with the conference committee, since SIGCOMM99 was already planning to host a panel of 11 past SIGCOMM Award winners, all recognized for their lifetime technical achievements in data and computer communications.

Time for planning the tutorial was short. We formed a team to structure the tutorial and create a Tutorial Notebook. SIGCOMM chairs Lyman Chapin, Craig Partridge, and Vinton G. Cerf drafted an outline covering 30 years of network technologies and then invited a wide range of pioneers to present. The tutorial was strongly influenced by the diversity of participating SIGCOMM Award winners. When the dust settled, we had 19 pioneers presenting a total of 28 13-minute presentations in five sessions spanning six hours.

As described in the SIGCOMM99 announcement: "This tutorial will present the technical history of the Internet—the evolution of thinking about the architecture and technologies of packet networks and internetworking, starting roughly with the early 1960s work on packet switching and extending to the present day. It will be told by many of the people who were there, but it will focus on the technical debates and decisions rather than on `who did what, when, and where’. …The presenters are the voices for the ideas and insights of a much larger cast of contributors."

As editor of the Tutorial Notebook, I asked the presenters for their slides, a bibliography, and the particularly scarce primary sources related to their tutorial topic. I was inundated with express mail filled with early drafts, email threads, and hard-to-find papers. As I opened each package it occurred to me that I was on an archaeological dig; handling the materials gently as I brushed the years away, discovering forgotten fragments, and wondering how it all fit together. I received over 1,500 pages and distilled them to a 635-page notebook.

Back to Top

Examples of Pioneers’ Presentations

The tutorial presentations by these noted pioneers were videotaped to form a key component of the SIGCOMM archive [11]. Their presentations supplement and now enhance the documentary sources by allowing us to read between the lines. They capture the thought processes behind the documents; reveal assumptions that were common at the time, but may not be obvious to later audiences; and provide context, such as the limitations of technology or the objectives of funding agencies.

The presentations were autobiographical, including technical perspectives, insights, debates, and decisions aimed at a technical audience. Many of the presenters chose to use primary source visuals, contemporaneous to the design. The presenters were compelling, their passion for networking was visible, the audience was transported back in time, and even the pioneers learned from one another.

The following memories are just examples, more of which can be found at the SIGCOMM archive [11].

Paul Baran (SIGCOMM Award Winner and co-inventor of packet switching). The 1960 challenge was to build a network such that a significant subset of the network could survive a military attack. He told us he knew he could design a solution once he realized that, "given redundant paths, the reliability of the network could be greater than the reliability of the parts." Baran used the figures from his 1962 RAND report—his earliest detailed description of packet switching.

Larry Roberts (SIGCOMM Award Winner and ARPA Program Manager of the initial design and implementation of ARPANET) refuted any myth that associates ARPANET with an attack. Instead, he emphasized the motives to build it were resource sharing for both scientific and military needs. In his presentation and his 1967–1968 program plans and papers he described the motives as linking computers for both data sharing and timesharing.

Sandy Fraser (SIGCOMM Award Winner and known for his virtual circuit switching designs) described building early asynchronous time-division multiplexers (ATDM) for a high-speed data network. The inspiration for his window flow-control protocol was the Lazy-Susan revolving serving tray. But the audience paid special attention when he related how his multiplexer had only 512 bytes of memory in which he implemented four layers: transport, multiplexing, management, and reservation. His story certainly gave the younger generation a new perspective and appreciation of that era.

Danny Cohen (real-time systems experimenter, active in splitting TCP) emphasized how packet-voice applications require different network services. Cohen recalled that ARPANET’s host-to-host protocol NCP was not appropriate for voice traffic; therefore, a second host-to-host protocol NVP was added. The same dilemma occurred in 1977 for the Internet’s TCP. In the 1974 classic paper by Vint Cerf and Robert Kahn [4], TCP is described as a single host-to-host protocol for both gateways and hosts. Cohen emphasized the original TCP had two headers: an internetwork header and a process header, given the differences between gateways and hosts, and packets and segments. The only solution for a second host-to-host service was to split TCP into two protocols: the lower-layer Internet Protocol (IP) and TCP. The split ensured that other services could use IP without TCP. In fact, most of the audience was not aware that TCP had been split.

Back to Top

Primary Sources

The tutorial collected a valuable set of primary source materials on early network designs. The UCLA Institute on Primary Resources states: "Primary sources are the evidence left behind by participants or observers… can be in any form, and are a source of direct evidence that describes or documents an historical event from the perspective of someone who was there".3 By expressing the concerns and assumptions of the time, primary sources can provide intellectual context. Forgotten early visions and proposals provide useful comparisons to later events, and technical forecasts can be compared with actual outcomes. Such documents can present not only design decisions behind existing technologies but also alternative designs that were considered and rejected.

The easiest sources to find are numbered series, which typically have an archive and an index; for example, technical reports from academic and corporate institutions, funding agency plans and reports, and the classic ARPANET and Internet RFCs. The challenge is to find the miscellaneous: drafts of very early design documents, minutes of meetings, early papers published by professional societies that no longer exist, user manuals, and early dissertations.

Two examples of primary sources include the following:

Network forecasts in 1965. Some of the earliest primary source materials that I received for the tutorial were from Donald Davies, a British network pioneer known today as one of the co-inventors of the packet-switched network paradigm. I knew nothing of his early work until I opened the package to find his original papers on packet switching, along with a cover letter and his 1982 summary. In particular, he included four drafts written between 1965–1966 describing usage, costs, and design details of his packet-switched network.

In his first draft dated Nov. 10, 1965 [5], Davies forecast today’s "killer app" for his new communication service: "The greatest traffic could only come if the public used this means for everyday purposes such as shopping… People sending enquiries and placing orders for goods of all kinds will make up a large section of the traffic… Business use of the telephone may be reduced by the growth of the kind of service we contemplate." In the first page of the same draft, he also addressed security: "The security of the information is a problem, however, which leads to a subject of research." His concern was "unauthorised access [to business data] via a national network". Unfortunately, Davies’ design received minimal funding.

Today, Davies’ drafts are in the SIGCOMM archive [11]. From these primary sources, one can derive a variety of stories; for example, the ability to compare his designs, motivations, and insights to the work of his contemporaries or explore how his 1971 isarithmic algorithm has been applied to other fields. One can ask networking students to read Davies’ first draft, reflect on his forecasts, and make their own forecasts. Donald Davies died May 28, 2000, several months after I returned his papers. The value of this work is incalculable.

Context for the Internet. By 1972 there were several publicly available packet-switched networks with incompatible protocols. To address this problem the International Network Working Group (INWG) was formed to design an interconnection of networks, now known as an internet. The INWG held its first meeting at the October 1972 International Conference on Computer Communication (ICCC) with an ad hoc collection of representatives, including telephone companies. Vint Cerf was asked to chair the new group and created the INWG Notes series to document the design discussion. (Ironically, at the same conference, ARPANET was maturing. Hundreds of attendees connected to it for their first time, experienced successful packet switching, and accessed applications at sites throughout the U.S.)

While researching this article, I discovered an intriguing example of context, as written for the 1972 INWG meeting—INWG#1: Report of Subgroup 1 on Communication System Requirements by Davies, Shanks, Heart, Barker, Despres, Detwiler, and Riml. They wrote: "It was agreed that interworking between packet switching networks should not add complications to the hosts, considering that networks will probably be different and thus gateways between networks will be required. These gateways should be as uncomplicated as possible, whilst allowing as much freedom as possible for the design of individual networks" [6]. INWG#1 clarified that gateways and simplicity were accepted concepts when INWG was formed. The value lies in tracing the context in which TCP was developed, rather than TCP introducing the concepts.

Many INWGs were never published and very few are online today. The networking community is fortunate that Alex McKenzie, INWG Secretary, filed the INWG notes and later gave them to the Charles Babbage Institute (CBI). When I visited the INWG Notes at CBI two years after the tutorial, I found a cache of design discussions, including alternative designs for an internet by Louis Pouzin and the French Cyclades team. Pouzin radically simplified the packet-switched network; everything besides routing, switching, congestion control, and network management was removed. Today, we call it "connectionless" or "datagram" packet switching. His analogy for an internet was a concatenation ("catenet") of networks, such that: "network + network = network." Another absorbing discovery was INWG#39—a draft of the 1974 Kahn/Cerf paper on internetworking and TCP. Key INWGs must be available online! These resources, and wherever they lead, will inspire some interesting technical analyses.

Back to Top

Research-Grade Oral Histories

While the SIGCOMM archive does not currently contain research-grade oral histories, such a resource is important. The term "oral history" is ambiguous and is defined by CBI historian Norberg: "The content of oral histories range from the random and autobiographical, for which the interviewer engages in little or no preparation and asks few questions, to recordings of speeches and seminars chosen by the `interviewee’, to carefully planned interviews, for which the interviewer engages in significant preparatory research on the life and work of an individual to formulate meaningful questions that can elicit important information on events, technologies, and organizations. This third type is a research-grade oral history" [9].

Production of research-grade oral histories can be labor-intensive and costly for a SIG. CBI4 and the IEEE History Center5 have each created several hundred research-grade oral histories. Other sources include the Smithsonian6 and the Computer History Museum.7 Research-grade oral histories are just as priceless as primary sources. And each reader can use the same oral history for very different purposes.

Oral histories vary by the interviewer, the interviewee, and the context of the interview. For example, most of CBI’s interviews on networking topics are from research on the influence of DARPA on the development of computer science in the U.S. An interesting introduction to research-grade oral histories is to compare the two interviews of Paul Baran: the 1990 CBI interview for the DARPA project [1] and the 1999 IEEE History Center interview that focused only on Baran, his technical career, and perspectives [2].

Back to Top

Planning a History Event

Beyond collecting primary sources and oral histories, it is important to create a history event. Such an event can range from the archival History of Programming Languages (HOPL) to the more informal pioneers day [10]. To clarify your goals for a history event, read the short papers in the HOPL II Session: "Forum on the history of computing" [3]. Start with Mahoney’s `What Makes History’ [8], Lee’s "Issues in the Writing of Contemporary History" [7], and then Sammet’s "An Effective History Conference" [10].

The HOPL paradigm is directed at creating histories of archival quality. Indeed, the goal drives the structure: a detailed set of questions to consider at the outset, a two-year timeframe for multiple drafts and reviews, and a published transcript of the presenter’s remarks, the discussant’s remarks, questions and answers.

The SIGCOMM99 Technical History of the Internet Tutorial focused on recording autobiographical oral histories from pioneers. History events that follow the pioneers day paradigm have a simpler planning process, providing the organizers with time to consider additional history activities and products. If your SIG chooses an event comparable to that tutorial, I suggest focusing on a few topics and allowing sufficient time per presenter and for discussion.

Both paradigms have their benefits. Alternatively, pick a point between the HOPL model and SIGCOMM’s model. History events energize both pioneer and student. History unfolds rapidly; capture it while you can.

This article is available at doi.acm.org/10.1145/1230819.1230840.

Back to Top

Back to Top

Back to Top

Back to Top

    1. Baran, P. Interview by Judy O'Neill (Menlo Park, CA, Mar. 5, 1990). Charles Babbage Institute, University of Minnesota; www.cbi.umn.edu/collections/.

    2. Baran, P. Interview by David Hochfelder (1999), IEEE History Center, Rutgers University; www.ieee.org/organizations/history_center.

    3. Bergin, T.J. and Gibson, R.G., Eds. 1996 History of Programming languages II. ACM Press; portal.acm.org.

    4. Cerf, V. and Kahn, R. A protocol for packet network intercommunication. IEEE Transactions on Communications 22, 5 (May 1974), 637–648.

    5. Davies, D.W. Remote On-line Data Processing and its Communication Needs. National Physical Laboratory (Nov. 10, 1965); www.acm.org/sigcomm/history.

    6. International Packet Network Working Group. INWG 1 Report of Subgroup 1 on Communication System Requirements (Oct. 24, 1972); www.acm.org/sigcomm/history.

    7. Lee, J.A. Issues in the writing of contemporary history. History of Programming Languages—II. T.J. Bergin and R.G. Gibson, Eds. ACM Press, New York, NY, 1996, 808–809.

    8. Mahoney, M.S. What makes history? In History of Programming Languages—II, T.J. Bergin and R.G. Gibson, Eds. ACM Press, New York, 1996, 831–832.

    9. Norberg, A.L. Use of CBI's Research-Grade Oral Histories from CBI. Charles Babbage Institute Newsletter 24, 3 (2002), 3–6; www.cbi.umn. edu/about/nsl/v24n3text.pdf.

    10. Sammet, J.E. An effective history conference. In History of Programming Languages—-II, T.J. Bergin and R.G. Gibson, Eds. ACM Press, New York, 1996, 795–798.

    11. SIGCOMM History Resources; www.acm.org/sigcomm/history.

    12. THINK Procotols: Technical History of the Internet and other NetworK Protocols; www.cs.utexas.edu/users/chris/think.

    1Postel Center, Information Sciences Institute, USC Viterbi School of Engineering; www.postel.org.

    2ACM History Committee; history.acm.org.

    3UCLA Institute on Primary Resources—Definition of Primary Resources; ipr.ues.gseis.ucla.edu/info/definition.html.

    4Charles Babbage Institute: CBI's Collections--Oral Histories; www.cbi.umn.edu/collections/.

    5IEEE History Center—Oral Histories; www.ieee.org/organizations/history_center.

    6Smithsonian Institution Lemelson Center: Resources—Computer Oral History Collection; invention.smithsonian.org/resources/fa_comporalhist_index.aspx.

    7Computer History Museum Collection—Oral History Program; www.computerhistory.org.

Join the Discussion (0)

Become a Member or Sign In to Post a Comment

The Latest from CACM

Shape the Future of Computing

ACM encourages its members to take a direct hand in shaping the future of the association. There are more ways than ever to get involved.

Get Involved

Communications of the ACM (CACM) is now a fully Open Access publication.

By opening CACM to the world, we hope to increase engagement among the broader computer science community and encourage non-members to discover the rich resources ACM has to offer.

Learn More