The Design Philosophy of the DARPA Internet Protocols

In the U.S. Department of Defense's initial efforts to build a network of networks, 7 goals were stated clearly that governed the design. First on the list was network resiliency, which naturally led to a stateless networking infrastructure, as it was too costly to replicate state sufficiently to survive network failures. Instead "fate-sharing" was adopted, with the tradeoff of having less expensive network hardware at the cost of more expensive and potentially faulty end hosts. The second goal was to support many types of communication services, leading to the simplicity of services offered by the network architecture. The third goal also argued in favor of this approach, as it was to accomodate a variety of networks, which was generally felt a much easier task if the network were kept simple.

Some of the other goals were not as successfully met. Distributed managment lacked (at the time of writing) sufficient software tools, and many times routers were manually configured. Cost effectiveness too has been questioned, as a more featureful network would do better to support particular types of communication, although clearly not all. Attaching hosts with little effort was also questioned because bare-bones internet architecture forced features to be implemented on the end hosts. Finally, accountability was hardly addressed at all, and is still an active area of research.

Some background information on the OSI model and how different types of services are partitioned in the network stack today reveals the fruit of the design decisions that have been analyzed in the paper. In particular, the hour-glass form of the internet where IP is the common protocol over which all other protocols must communicate demonstrates the simplicity of serivces that the internet provides at its core, and what services must be implemented at the end hosts.

I felt the paper did a relatively good job of recalling historical events in the creation of the internet architecture and why particular design decisions were made. Enumerating the 7 goals at the beginning and digging into each one sequentially provided for a writing structure that was easy to follow. Indeed, looking at current internet protocols reveals little about why they were constructed, and the paper does a good job of recalling why they became what they are today.

Topics for class discusison may include what is currently being done in the area of accountability in intenet architectures, and if such things can be accomplished without burdening the network to such a degree as to degrade service to customers. Also, what were the tools like during the initial construction phases of the internet to provide selective connectivity between separate administrative domains (ASes, as we call them now)? What are the privacy/legal issues with implementing detailed accountability of customer traffic?

The open issues now are, as far as I know, accountability and the cost effectiveness of the internet architecture. Could we develop a mesh of partially specialized networks and acheive greater network utilization per dollar? How can we track traffic flows on a per customer basis and charge appropriately? What are the privacy issues with this?

Taken as a whole, Clark's work allows us to see with much more clarity the reasons why, quite simply, things are the way they are. Years of guesswork and trails went into building an internet architecture that met the intial 7 goals, and this paper takes a proud look at what has been accomplished through the best engineering insights we could muster. The implication of this paper is that we are now more educated about these insights and can use them in our own analysis of the Internet.