Paper: End-to-End Arguments in System Design

Editor’s note: Imported from my old personal blog @ TC with minor edits to improve readability where necessary.

Those of you who hang out with me on a restricted mailing list may have seen me post short summaries of research-oriented papers that cover some aspect of internetworking or information security. I was recently asked about this, because its been awhile since I’ve done it. Since its not the first time I’ve received positive feedback about these summaries, I’m going to open my new blog with a review of one of the most enduring and important papers in all of computer communications.

J.H. Saltzer, D.P. Reed and D.D. Clark, End-to-End Arguments in System Design, ACM Transactions on Computer Systems (TOCS), Volume 2, Issue 4, November 1984. [pdf]

The e2e paper wants designers to consider the proper placement of functionality in a communications system. Its argues for placing functionality upwards, in a layered protocol model and outwards, towards the application that uses the functionality. However, it does not say that functionality must not exist in lower layers. In some cases functionality at lower layers may be appropriate and worthwhile. All too often the e2e argument is trotted out as careless dogma in debates amongst protocol, system, network or security designers to support a stance on how to best implement a system. I sometimes wonder if these people have even read the paper all the way through. I’m sure some have never read it and equate what is in it with a flawed set of associated ideas and statements they see on mailing lists and in other forums.

I teach a variety of computer networking and security courses at DePaul University. Inevitably I will briefly discuss the end-to-end argument. I attempt to convey as best I am able the main ideas of the paper and encourage my students to carefully consider its implications. I always feel a bit squeamish in doing so. On occasion I read something that David Reed, one of the paper’s original authors, has written on the e2e argument. Sometimes I have found myself coming to a conclusion that is confirmed by what he’s written. Other times my notion of what the e2e argument says or how it is applied will be challenged, making me feel less confident about my ability to have fully grasped the paper’s message. I may not be the most enlightened thinker in the world of communication systems, but if this happens to someone like me who’s been doing this stuff for many years, surely others might fail to fully grasp its message also.

I’ve recently been referring back to a sentence in the paper which I think highlights a key point of the argument, “A great deal of information about system implementation is needed to make this choice intelligently.” For me, this says a lot about how one must correctly interpret the paper. It is the only place in the paper where a form of the word “intelligent” is used and it implicates the person doing the implementing rather than a system component. Often, and I’ve done this myself, people interpret the e2e argument as saying something about the stupid network, but that isn’t quite right.

The e2e argument does suggest a set of guiding principles that may lead to specific designs, but rather than consider it as a set of commandments, remember it is an argument. Its not only a must-read paper, but its a must-re-read paper. If you haven’t read it recently, spend the time to do so. It says a lot, but maybe not what you thought it did.