Network Geeks

Network Geeks: How They Built the Internet, by Brian E. Carpenter, Copernicus Books, ISBN 978-1-4471-5024-4, 2013.

The movie opens on a familiar scene, toward the end of a congenial dinner party at the plush home of an august personage. Conversation has been casual and wide-ranging. The group retires to the library for brandy, cigars, and more conversation. Because you are new to your profession and the august personage was involved in its early years, you ask him what it was like. As he begins his recitation, the scene fades to an earlier time... "My great-grandfather, John Winnard, was born in Wigan..."

Such is the style of Brian Carpenter's book, Network Geeks: How They Built the Internet. Although indeed many other people are cited, the book really is Brian’s personal memoir, complete with his own photographs. It explores his background and work, providing a fascinating travelogue of one person's arc through recent history. Given the breadth and scale of the 50-year process of invention and development of the global Internet, we need perhaps a thousand more such reminiscences to provide sufficiently rich detail about the many actors and acts that contributed to its success.

Brian's experiences within that global history are certainly worthy of note. His writing paints pictures of places and topics such as the forces and attractions that drew him to computer networking; in those days, it was an outlier technical topic and people often happened into it, rather than setting out with a plan. Indeed, Brian's doctoral work was in computer speech understanding—not networking. However, he has played a key role in many significant Internet activities. His frequent employer, the Swiss CERN [0], was a focal point for much of the early European networking activity—as well as being the birthplace of the World Wide Web—and Brian's various leadership roles in the Internet Engineering Task Force (IETF) came at pivotal times. Other popular references to Internet history tend to emphasize its American basis, making Brian’s primarily European perspective refreshing and helpful.

The book is short, just 150 pages. Although Brian makes some terse references early in the book, he does not get fully into gear talking about the Internet until a third of the way through it. He started in physics, coming fully to computer science only in graduate school. Over the course of the memoir, we hear quite a bit about his physics work at CERN and elsewhere, as well as his activities with the early European deployment of Internet services, his eventual work with Internet standards, and the like.

The IETF

Brian's reference to his great-grandfather does appear, but not until page 10 in a chapter that extensively details his family history and his own upbringing—how many other books on Internet history are likely to include an inset distinguishing the English Baptist church from the American Southern Baptist? Rather, the book begins with a description of a prototypical IETF plenary session at the thrice-annual standards meeting, and he paints the picture well enough to have prompted a guessing game about the person he was describing. IETF meetings, including the plenaries, have a great deal of audience participation, because these meetings are working meetings, not conferences. I particularly enjoyed Brian's turn of phrase when describing one participant, "...who had given several articulate but incomprehensible arguments at the microphone." Later in the book he also equitably describes a colleague as "a wise leader, decisive or even pig-headed, but willing to listen..."

After its opening sequences, the book follows Brian's life chronology, including extended periods in England, Switzerland, the United States, and New Zealand, most recently landing at the last. His employment has variously been university, research, and corporate, including roles as researcher, manager, chair, and teacher.

This book is a memoir, so Brian casually and regularly moves between discussion of personal and professional developments. From one paragraph to the next, he might describe structural aspects of an Internet organization, insulation of housing in New Zealand, the next effort at particle physics, optimizing travel when flying out of southeast England, the nature of a computer networking technology, or the personal style of a co-worker.

In particular, this work is not a tutorial on Internet technology or on its invention. Although Brian does discuss many aspects of the technologies, the pedagogy suits an after-dinner evening's reminiscences, not a classroom lecture. Some concepts are explained in great detail, while others are merely cited. For example, his early discussion of computer networking references the fact that it enables mesh topologies, in contrast to then-common star configurations, but he doesn't give much sense of what "mesh" means in technical terms. Also, the core technology of networking is packet-switching and although his discussion on the page after the mesh reference cites queuing theory, he never introduces the motivating design construct of "store and forward."

His discussion of addressing suggests his hardware background, and misses the essence that a name at one level of architecture is often an address at the next level up. So although www.example.com is the "name" of a host system attached to the Internet, it has the role of "address" in a URL, because it specifies where to go to resolve the remainder of the URL.

That said, quibbling with such an issue in a tutorial might be reasonable, but it is entirely inappropriate for a memoir. These are Brian’s recollections. If they prompt the reader to explore things later, so much the better; but arguing his view will not do. Perhaps reflexively, it is convenient that the Internet makes such exploration quite easy...

NATs

Except that I remain sorry to see that Brian still has such a strikingly purist view about Network Address Translation (NAT) [1, 2] devices, which map between internal (private) IP addresses and public ones. The purist view is that they are an abomination that breaks the elegance of the "end-to-end" design principle of the Internet. The principle is powerful, because it tends to greatly simplify the communications infrastructure and greatly enable innovation at the endpoints. The problem is that the real world imposes organizational and operational models that are more complex than easily supported by the basic end-to-end construct, at the least needing to include enterprise-level policies. NATs do cause problems, by replacing one IP address for another, and some mechanisms do cease to work because of these replacements. However, the operational world views NATs as being useful against multiple problems. One is address space constraints, which is the formal justification for creating the mechanism: an enterprise uses far fewer public IP addresses—a reality that is now essential as IPv4 addresses have grown scarce. Another justification is the misguided view that they improve enterprise security, and the other is the legitimate view that they simplify enterprise network administration. After more than 20 years of extensive deployment, these devices might be expected to have become tolerable to a pragmatist, possibly even forcing consideration of a more elaborate architectural model for the Internet. Yet Brian suffers no such weakness; NATs are evil.

One of the technical points that intrigued me was Brian's repeated discussion of the Remote Procedure Call (RPC). This mechanism makes network interaction for an application look like little more than a subroutine invocation. It was hoped that it would greatly simplify network-oriented programming and make it accessible to any software developer, rather than requiring the developer to have a deep understanding of networking interfaces and dynamics. Brian cites the mechanism as having been "invented by the ARPANET community in the mid-1970s..." and used at CERN in a programming language shortly after that. But my own recollection is of hearing a Xerox Palo Alto Research Center (PARC) manager in 1980 proudly announce that one of his summer interns had just developed the idea. Indeed, Wikipedia credits the late Bruce Jay Nelson, a Carnegie Mellon University graduate student who was working at PARC. [3]

And that is the essence of a memoir. It is the remembrances of the speaker, not the formal work of a historian or journalist. It is not the diligent unfolding of a researched history, such as in Where Wizards Stay up Late [4], nor the tourist approach of Exploring the Internet: A Technical Travelogue [5] that seeks to name every possible person active at the time—although Brian does sometimes invoke that latter template. Instead it shares one person's sense of what happened—what he remembers doing and seeing.

Railing against architectural biases or historical nuances is essential when evaluating formal professional writing, and we do need such judicious efforts to capture the history of the Internet. But had Brian sought to produce such a tome, it would not have been as rich or as personal.