Saturday, August 30, 2008

The Design Philosophy of the DARPA Internet Protocols (Clark, MIT)

Briefly summarize the paper (1-2 short paragraphs)
A reflection on the birth of the the network and transport layers of the TCP/IP model protocol stack. Over 15 years countless individuals contributed to the development of a network stack that could support continued growth of the ARPANET. Their design was inspired by 7 goals:
  1. Robustness (it was a military project after all, network gateways might be bombed)
  2. Different applications need different service guarantees (i.e. TCP vs. UDP)
  3. Support variety in the Link Layer (not everybody was running a LAN, e.g. there were radio)
  4. since different companies/gov agencies will own different chunks of the Internet, management must be distributed (not centralized)
  5. Low cost
  6. Adding new hosts must be easy
  7. Accounting must be feasible/easy
This list was sorted by priority with the items near the bottom receiving little attention at the time of the protocol design.

One big lesson to take away from the entire process is that a system that does the job good enough can become popular and be very hard to replace with a future system, even if it does the job much better.

Provide relevant background/related material as appropriate (1-2 short paragraphs)
This was a historic paper, most of the related material consists of other historical papers.

Critique the paper and suggestion discussion topics (2-3 paragraphs)
At a high level, the paper does a great job distilling design principles out of a huge complex project. To be nit-picky, I found section 10 confusing and poorly worded. I got lost on the third paragraph of "pg 113." The paper was also wrong in its conclusion with the intuition that a better building block than the datagram might win over eventually.

Why or why not keep this paper in syllabus?
Keep it in the syllabus because it contains both a fascinating perspective into the history of the internet/networking as we know it as well as useful system design principles (e.g. references to the end-to-end principle, and insight into the iterative process of systems design).

What issues are left open for future research?
He basically ends the paper with a suggestion for a direction he calls "soft state" which he sees as an improvement over the purely stateless datagram model. To my understanding, this idea didn't represent the direction the Internet went.

What are the important implications of the work?
Uhh... The Internet. (e.g. this blog, the whole entire world, the future of humanity!)

End to End Arguments in Systems Design (Saltzer, MIT)

Briefly summarize the paper (1-2 short paragraphs)
This paper explains and explores the tradeoff between pushing functionality, such as encryption, duplication detection, and robustness mechanisms, into the lower levels of the network stack vs. implementing the same functionality at the end hosts of the network connection (i.e. at the application level).

The solution they promote is not simply to push things to the ends, but to be sensitive to the advantages and disadvantages of both scenarios. Each has its limitations. For example, encryption at a low level is not a strong enough guarantee for somebody who does not trust all other users on his machine since sensitive data would be moved between the process and the encryption point which would be low in the system stack. On the other hand encryption done at the application level cannot guarantee that all data going out on the wire is encrypted, which might be desirable from a network policy perspective as a safeguard against "wire tapping" or accidental transmission of sensitive data to an untrusted entity.

Provide relevant background/related material as appropriate (1-2 short paragraphs)
This paper was written as a reflection on the experiences at MIT related to this tradeoff space, including "A Too-Real Example"

Critique the paper and suggestion discussion topics (2-3 paragraphs)
This paper is amazing. I believe that my conscience would bother me I if deigned to react with anything but groveling at the feet of its authors.

Why or why not keep this paper in syllabus?
Absolutely keep it in the syllabus, it is a seminal paper that every CS researcher should read. 

What issues are left open for future research?
The principle is a general and useful one. They provide many examples of the trade-off space, but there are countless more that could be enumerated. In fact it is valuable to consider the end-to-end principle any time a network based system is being designed.

What are the important implications of the work?
We had significant discussion of the end-to-end principle during the design phase of Chukwa, the data collection system I helped build at Yahoo over the summer. The end to end principle is taught as a fundamental tool in all systems design work.