Design Philosophies of the DARPA Internet Protocols

This paper acknowledges the difficulty in determining the motivation and reasoning for why the Internet protocols were designed the way they were. The primary goal of the design was to multiplex existing networks using packet switching layers, called gateways, that implement a store and forward switching algorithm. A priority-ordered list of more specific goals shows that having continuing communication despite loss of networks was a top priority, while holding Internet resources accountable was the lowest priority. Cost effectiveness is only moderately important, being number five of seven.

The paper describes in detail the top three criteria: survivability, service variety, and network variety. State maintenance is crucial for survivability. If an Internet connection fails and has to reconfigure, previously communicating entities should not have to do anything to reestablish their state; clients should not even be informed of synchronization loss. A “fate-sharing” technique, rather than replication, can be used to maintain state at the host which is using the communication service. The need for more than one transport service was motivated by the realization that the range of “virtual circuit” services were too difficult to build support for in TCP, e.g. a debugger doesn’t need a reliability constraint, and real-time conferencing can sacrifice missing packets for minimal delay. TCP was separated from IP to offer reliable service and UDP was created to prefer simpler delay characteristics over reliability. The Internet can support a variety of networks because it makes few assumptions about net functionality: network can transport packet or datagram of reasonable size, and there exists some sort of point addressing. If other services like reliability have to be engineered in the transport layer, then they only have to be done once.

The motivation for the constructing the Internet architecture was to connect existing networks: ARPANET and ARPA packet radio network. Packet switching was used to multiplex the network since it was used by the networks to be connected. Before TCP was separated from IP, all bi-directional reliable deliver of data, called “virtual circuits” had been using TCP. The datagram is the building block of IP, representing the minimum network service assumption. Datagrams eliminate the need for connection state in intermediate nodes, and endpoints can combine differently to offer a variety of service types. TCP designers decided flow control should be based on bytes rather than packets. Some of the reasons for this decision were later dropped, but an important one was the ability to group smaller packets into one large packet for retransmission.

This paper is great for showing the rationale behind the design of the Internet protocols, especially with the examples of circumstances or software that guided the motivation. Separating TCP and IP into two layers makes sense when you want to maintain both modularity and variety. The architecture has a flavor of “design first, then see what worked well” that is interesting to observe, like the byte-wise flow control in TCP. Also interesting to observe is how the prioritized list of goals influenced the architecture design, and I wonder how that list may have been different had it been created in this decade. For instance, why is having distributed management only the fourth goal?

Some unanswered questions/thoughts: Is there a better architecture building block than the datagram? What characteristics are lacking?  Also, the authors remarked about the difficulty in guiding a realization implementor to avoid performance problems in additional to logical correctness, especially when performance problems may be a result of the operating system the protocol is running on.