Paper review: <Cla88>

Reviewer: <Jason Oh>

1. This paper attempts to explain the rationale behind the design choices behind TCP/IP.
2. The main contribution of this paper is presenting a new analysis of why TCP/IP was designed as it was. Clark notes that there have been papers and specifications describing how the protocols work, but few if any describing why the protocols are as they are. This question is still important today because it points to broader issues in design methodologies of new networking infrastructures.
3. The key ideas of this paper come from analyzing DARPA's design philosophy for TCP/IP. One is that network designers should have solid goals when designing a network, including not only simply functionality and survivability, but expandibility as well. Another key point is that supporting a variety of services at the transport level is more easily accomodated by having more than one transport service, which led to TCP/IP being separated into two layers. A third concept revolves around incorporating a variety of network technologies, as TCP/IP does, as a key feature for wide distribution of the network.
4. Critique the main contribution
   • I think this paper provided significant contribution to the analysis of network design philosophies by considering the reasons behind implementation choices of TCP/IP.
   • Clark's solution approach is quite convincing. He considers the goals of the TCP/IP protocol, examines at how they were treated in the design, and then looks at the implications for other network designs. His arguments are logical and convincing, and his conclusions rest on solid analyses of the design of TCP/IP.
   • Probably the most important limitation of Clark's approach is that there's limited empirical proof other than what's come before. That is, he has only the case study of TCP/IP to prove his assertions.
5. I think Clark's paper is a solid resource for anyone thinking about designing a new network protocol, and even for anyone examining the merits of a newly designed protocol. One question he leaves open is whether there is a better fundamental building block than the datagram.