Overview
One of the most famous and influential papers relating to the design of distributed systems is End to End Arguments in System Design by Jerry Salzer, David Reed, and David Clark. The Association for Computing Machinery's (ACMs) SIGOPS group voted this paper to its hall of fame, stating:
"This paper gave system designers, and especially Internet designers, an elegant framework for making sound decisions. A paper that launched a revolution and, ultimately, a religion."
Maybe not a religion, but this paper has helped a lot of designers to think clearly about tradeoffs in organizing distributed systems, and it neatly explains some of the tradeoffs embodied in the architecture of the Internet. This is a surprisingly easy paper to read and understand.
For this assignment, you will also read a very interesting interview with Paul Baran, who was an influential proponent of packet switching in the days before the ARPANET and the Internet were built.
Assignment
Read the paper and the article, and answer the questions. (Of course, it's a good idea to look at the questions before doing the reading.)
Remember that, as with most reading assignments, there are two due dates for the responses to the questions:
- The first due date is just in time for class discussion. Do your best to answer the questions, so you'll be prepared for the class. We will note whether you have made a useful submission, but not record a numeric grade for this first version.
- The second date is a few days after class discussion. If you learn new things in class and want to update your answers, feel free to do so. Your grade will be based on your later submission. If you're happy with your initial submission, that's fine too; there's no need to resubmit unless you want to improve your answers.
A bit of background
In reading the interview with Paul Baran, it may be useful to know that:
- AT&T, sometimes called the "Bell System" (since it evolved from the companies founded by telephone-inventor Alexander Graham Bell), had a monopoly on the US phone system, which was a circuit-switched system. AT&T was viewed by many as the center of "real" expertise on networking in the US. Bell Labs was the research arm of AT&T.
- The networks that existed at the time were built primarily to handle voice. The voice was carried as an analog signal, in which the voltage varied directly in proportion to the amplitude of the sound wave. Data, when carried at all, was typically encoded as an analog (or even audio) signal, and transmitted through the traditional telephone system. Baran discusses the relationship between the adoption of the new (and controversial) digital technologies and the adoption of the new (and controversial) packet-switching technique.
- The ARPANET, which is mentioned in the interview, was the first packet-switched network to get significant use, and it is the direct antecedent of the Internet.
- The RAND Corporation, at which Baran worked, was a "think tank" which helped the government to analyze many matters relating to the military and security. The major national security concern of the US was the "cold-war" with the Soviet Union. One of the questions Baran is asked is whether he can confirm that packet switching was promoted as a technology to create networks that would remain operational following a nuclear attack.
The End-to-End paper was published in 1984, roughly fifteen years after the first message was sent through the ARPANET, and ten years after Vint Cerf and Bob Kahn published the proposal for the TCP/IP Internet protocols, and of course even longer after the work of Baran on packet switching. Nonetheless, the End-to-End paper is often cited as the philosophical rationale for use of packet switching and for the Internet's architecture. How can this be? Quoting from the beginning of the End-to-End paper:
This paper discusses one class of function placement argument that has been used for many years with neither explicit recognition nor much conviction. However, the emergence of the data communication network as a computer system component has sharpened this line of function placement argument by making more apparent the situations in which and reasons why it applies. This paper articulates the argument explicitly, so as to examine its nature and to see how general it really is. The argument appeals to application requirements, and provides a rationale for moving function upward in a layered system, closer to the application that uses the function.
So, the authors were attempting to make people conscious of the implications of key design decisions that had crept into the ARPANET and Internet, and which were having more impact then most people realized.
Getting the Papers
Both references are available online:
- , End to End Arguments in System Design, ACM Transactions in Computer Systems 2, 4, November, 1984, pages 277-288 (pdf)
- ,
Founding Father, (an interview with Paul Baran),
Wired Magazine, March, 2001 (html)
Alternate copy: In January of 2018 the Wired server became unreliable for awhile, so I put up this alternate copy of the article.
Optional background reading
These are indeed optional, but both are excellent reading if you are interested in the history of networking:
- The RAND Corporation has posted a nice history of Baran's work on packet switching, along with links to his original papers. If you find the Wired magazine interview to be interesting then this additional material is a great way to dig deeper. It's always interesting to go back and read the original papers on great developments like this.
- In 2023, IEEE Spectrum published a really interesting retrospective on OSI. OSI was the networking system everyone was sure would become the worldwide, open packet-switching infrastructure. Huge investments were made by governments around the world, and by large (and small) manufacturers of computing systems. What happened instead was that a weird little university and government research project called TCP/IP became ubiquitous instead.
The article has interesting glimpses into the roles of Paul Baran and Don Davies among others, and if you look closely you will see a photo of the attendees of an OSI working group devoted to naming architecture (yes, naming really is a thing when designing systems).
Getting the Questions
As with the Weaving the Web Assignment , questions are provided in an HTML file, a copy of which you can download. You must supply your answers by inserting them in the spaces provided in the downloaded HTML file, and when you are done, you must submit your answers using the usual Tufts CS department "provide" command. See instructions below.
For full credit, your file should validate as HTML5 using the official validator for uploaded files. It may not be possible in all cases for the graders to check the validity of every submission, but we reserve the right to do so when we suspect trouble, and to deduct credit for validation failures.
You must edit the HTML for your submission using a text editor such as VIM, Emacs, SublimeText, etc. Submissions that were edited using Microsoft Word, OpenOffice, or other tools that create or style the HTML for you will not be accepted and may receive no credit. Reasons: part of the reason for using HTML is to give you practice using the format and to show you interesting examples of styling with CSS (you might, for example look into how the question numbering is done); also, when we grade your homework we sometimes return to you an annotated copy of your submission with commentary in line — that can be impractical to do if a word processor has mangled the HTML.
Review questions for this assignment - Download questions for this assignment
Submitting your answers
Download the HTML file with the questions using the link above. Fill in your answers, use your local browser to check formatting, and the HTML validator to make sure your HTML is correct. You may ignore warnings about character encodings. Then use provide to submit:
provide comp117 endtoend endtoendquestions.html
Note that comp117 is lowercase; provide will choke if you get that wrong.