The Design Philosophy of the DARPA Internet Protocols

This paper provides the reasons behind why the elements of the early Internet were designed a particular way. The author made an approach by first presenting the high level goals that were required of the network and then rationalized the many decisions that were made to implement those goals.

The fundamental goal of the network was to interconnect existing networks by sharing network resources. Some of the choices made in this regard was to not design from scratch a unified multi-media system and to use packet switching. Since the DARPA network was intended primarily for military use, the second level goals were prioritized based on wartime needs where survivability being the top priority, and accountability of resources the lowest. But as priorities shift, some of the decisions that were made back then may eventually have a painful consequence in the future.

The only failure that was allowed to be perceived above the transport layer was a total partition so the state information must be stored somewhere in the network to recover from non-fatal failure. The choice was made to store this information with the host so that the state information is lost only when the associated host is lost. This type of “fate sharing” seems very reasonable but one instance I can think of where replication of state information would be better is when there exists some other host in the network that can resume the interrupted job.

The use of datagrams as the building block allowed the flexibility of the network to support a variety of services with different requirements.

One thing that was very confusing about the TCP part was about the EOL flag. Since the “buffer is returned to the user either when it is full, or an EOL is received”, I don't see why there will ever be two buffers that are non-empty. If the current buffer fills up before the out of order packet arrives, it will already have been emptied and there will never be a need to use the second buffer. Maybe I'm not clear of what the buffering strategy is or it's because I'm not familiar with the details of TCP.

Overall, I feel this paper was very effective on explaining why components were designed as they are and also provided an opportunity to re-evaluate the other options that were not chosen at that time from the perspective of modern day requirements.