Design Philosophy of DARPA Internet Protocols, Clark

This paper discusses the various architectural decisions that were faced in the creation of the Internet. It discusses different approaches that could have been taken and justifies the reasons behind the ultimate choices. The list of priorities in creating the Internet contained a number of unsurprising items: survivability, flexibility, accountability, cost-effectiveness, and distributed resource management.

However, the ordering of these priorities was a surprise; the utmost goal of the Internet was to connect together existing networks, but survivability in the case of failure was not far behind. I was amazed to see that cost-effectiveness was ranked as the 5th secondary goal out of 7 and can only imagine how different the Internet would be today if it were being created for commercial rather than military purposes.

One important decision made was for the use of the "fate sharing" scheme, that is, placing state information at endpoints to protect against intermediate node failures. This idea comes directly out of the need for survivability but also meshes well with the end-to-end argument. The disadvantages of employing the end-to-end strategy were that retransmitted packets may cross intervening networks multiple times and also that programmers would have to deal with implementing protocols themselves, an idea that perhaps strikes slightly less fear into current-day programmers than it did then.

A decision driven by the need for flexibility was the splitting of TCP and IP to allow for different transport protocols. This drive for letting in a variety of networks and providing a variety of services means that there were very minimal requirements for networks to meet; the requirement of being "fairly reliable" in transporting a "reasonably sized" packet using addressing (usually) was left general to accommodate the many different networks already in existence. However, because the designers did not want to constrain flexibility/variability, they did not tackle the difficult problem of formalizing performance constraints.

An interesting feature present in the ARPANet protocol that was changed for TCP is that ARPANet flow control was based on both bytes and packets. Despite the variability the designers strove for in terms of networks and services incorporated into the Internet, TCP was made to only deal with bytes. To eliminate one form of regulation because it seems too complex seems like a poor excuse, particularly since the ARPANet already had ways of dealing with both. However, the designers really had no reason to spend time on anything complex that did not contribute to the top goals of survivability or network variability of the Internet. Unfortunately, tools for distributed management and accountability also fall on the list of under-developed concepts.