The Design Philosophy of the DARPA Internet Protocols

Summary

This paper describes the reasoning that went into creating the major internet protocols. Many people know the "what" of the protocols; this paper explains the "why". The 2 main protocols explored in this paper are IP and TCP.

The author explains that the fundamental goal of the internet was to connect the many smaller networks that existed at the time. Using several assumptions and the knowledge they had of current networks, they came up with the following design: a network made up several interconnected networks that used packet-switched communication, connected together with store-and-forward gateways.

The author lists the 7 second level goals of the internet in order of importance, and stresses that this list strongly reflects its use at the time, which was in a military context. This explains why survivability was so high on the list and accountability so low.

The author goes on to explain each goal in depth. Survivability made it necessary for state to be stored somewhere in the network; the designers decided to take the "fate-sharing" approach and stored the state in the hosts. IP and TCP, which were originally designed to be combined, were split in order to be able to support many different types of services. This led to a datagram being the basic building block. The internet is successfully able to support many different network technologies because it makes a very minimal set of assumptions about what the internet will provide. Then, the paper goes over the remaining goals and explains how some of the main problems we have with the internet today are due to these goals being so low on the priority list and therefore not well implemented.

The paper emphasizes how a datagram is not a service in itself, but rather was designed to be a building block. It also includes a discussion on TCP and some of the issues due to counting by bytes rather than packets. The paper finishes off with an for a new building block for the "next generation of architecture" called flows, which would be able to better address the goals of resource management and accountability.

Criticisms & Questions

I thought it was interesting how the author mentions "the next generation of architecture". The way he talks about it, it almost seems like there was a plan to redesign and rebuild the internet from scratch. It would be really interesting to know if at that time people did believe it was possible to switch over to a new, redesigned internet.

It would also be really interesting to know what the metrics were when evaluating the various goals, particularly the second level goals. Most of these goals are very hard to measure so I would imagine that knowing whether the goal was achieved or to what extent it was achieved would be hard to determine.

Feedback

I really enjoyed reading this paper. It was great to get more insight into what the designers considerations were when designing the internet. It definitely teaches one to look at it from their perspective before criticizing the design of the Internet. I would agree to keep this paper in the syllabus.

End-to-End Arguments in System Design

Summary

This paper explains the "end-to-end principle" as it is used in system design, with many examples of its current use in communication networks.

The end-to-end principle states that many functions are best implemented at the higher layers because implementing them in the lower layers is redundant and lowers overall performance. Redundancy comes from the fact that a function provided at the lowest level does not meet all the needs of every application - therefore, the application will have to implement that function at the highest level as well, rendering the lower-level function unnecessary. Another argument for end-to-end is that if everything is implemented at the lower levels, all applications whether or not they need them will be forced to use them, hindering their performance.

The authors illustrate the concept with a "careful file transfer" example, which I think did a great job of explaining when to and when not to put some functionality in the lower layers. The authors suggest that the only time functionality should be added to the lower layers is if it improves the application's performance in a manner that cannot be done by the application. However, this should still not be a full implementation of that functionality - the application will still be expected to implement it. The authors also provide an example (real-time voice communication) of where including functionality in the lower levels would actually hinder an application.

Criticisms & Questions

One thing I would have liked to see in the paper were the drawbacks to the end-to-end argument. The authors briefly touch on the fact that end-to-end may increase overall cost because each application would have to implement their own reliability mechanisms. However, I would have liked to see more discussion on the potential drawbacks. Possibly in a future paper, it would be interesting to see if end-to-end could be modified to address those drawbacks.

I see how the end-to-end argument applies in many situations, but I would think that there are sets of applications that all require the same mechanisms, and in that case, each application programmer would have to re-implement those mechanisms, leading to redundancy at the application level. I wonder if it's possible to add in some way for these applications to share these more common mechanisms.

Feedback

I enjoyed reading this paper - it was clear and easy to understand. I especially liked all the examples - they helped me to understand the different applications of the end-to-end argument. Therefore, I would argue that this paper should be kept in the syllabus.