The Design Philosophy of the DARPA Internet Protocols

D. Clark, The design philosophy of the DARPA internet protocols, ACM SIGCOMM Computer Communication Review, August 1988.


This paper explores the underlying design philosophy, motivation and reasoning behind the DARPA Internet protocols which includes the Internet Protocol (IP) and the Transmission Control Protocol (TCP). The paper begins by highlighting that the fundamental goal  of the DARPA Internet Architecture was to develop an effective technique for multiplexed utilization of existing interconnected networks. For this, packet switching multiplexing technique was used over circuit switching mainly because of two reasons. Firstly, application such as remote login were better served by packet switching and secondly because the networks that were to be integrated were packet switching networks. Moreover, since the technique of store and forward packet switching was well understood, it was assumed that the networks would be interconnected by a layer of Internet packet switches called gateways.

Keeping the fundamental goal in mind, several secondary goals were set based on priority. First goal was that the Internet communication must continue despite the loss of networks or gateways. Since the network was designed to operate in a military context, it seems pretty reasonable for this to be a high priority goal. For this, a reliability approach called "fate sharing" was proposed where the transport level synchronization information  and other state information was kept on the end points. This resulted in stateless packet switches and a "datagram network". This idea was also in agreement with the End-to-End argument. Second goal was that the Internet must support multiple types of communicationn service. It was realized that not all communication services want to have a bi-directional reliable delivery of data. Examples of XNET, the cross-Internet debugger and that of real-time delivery of digitized speech further strengthened the author's point. Due to this, it was realized that more than one transport service would be required which resulted in TCP and IP to be split into 2 layers. TCP provided a reliable data stream while IP provided the basic datagram approach. Thirdly, the Internet architecture must accommodate a variety of networks. This was an important goal as this allowed the Internet architecture to make a minimum set of assumptions about the functions of the individual networks which made it even more useful and robust. 

Fourth goal was that the Internet architecture must permit distributed management of resources which led to several different management centers (ISPs) deployed in the Internet operating a subset of gateways. Fifth was that the whole Internet architecture must be cost effective which cannot be claimed to have been perfectly met. The headers of Internet packets are pretty long and this becomes an overhead for small packet sizes. Moreover, since lost packets are not recovered at the network level, it is an added overhead to retransmit lost packets. Sixth goal was that the architecture must permit host attachment with low level of effort. This is another objective that was not perfectly met. The cost of attaching a host is somewhat higher because all the reliability and state mechanisms must be implemented in the host. The final goal was that the resources used in the internet architecture must be accountable. This goal was not perceived important earlier when the end hosts were only military nodes however, now that the Internet has expanded to include all types of users, accountability of packet flows has gained a lot of importance.

Overall, I really liked this paper as it helped me appreciate the reasons for the numerous design decisions that led to the development of current Internet protocols. However, I think that many important design considerations that were valid at that time may no longer be valid now. For eg. cost effectiveness and accountability should definitely be considered to be two really important goals. In light of this, it would be really great to discuss as to what design approach the protocol designer would have taken given the current scenario in mind.