Subject: Article Review 2: End-to-End Arguments

Summary

The paper by Saltzer discusses the end-to-end argument in a distributed communication system. The end-to-end argument proposes that functions at the low levels of a system may not be cost-efficient because these functions may not be used by higher level applications. These functions may also be redundant, when higher-layer clients have to re-implement these features to suit its own requirements. Providing the functions at the lower level will then become more costly and not useful.

The authors proceed to give examples of the end-to end argument in delivery guarantees/ acknowledgements, data transmission and encryption, suppressing duplicate messages, correct arrival order of messages (FIFO delivery), and data storage systems. The main question in these examples is on where to place the functions – at the low or high level? To arrive at an answer, it is necessary to evaluate the trade-offs between performance, reliability, and costs when comparing the feasibility of placing functions on each of the identified levels.

In conclusion, the authors state that end-to-end arguments can be thought of as “Occam’s Razor”. That is, only the functions that are absolutely necessary must be included in the designed communication subsystem.

Background

History of End-to-End Arguments (http://en.wikipedia.org/wiki/End-to-end_principle#History)

The concept and research of end-to-end connectivity and network intelligence at the end-nodes reaches back to packet-switching networks in the 1970's, cf. CYCLADES. A 1981 presentation entitled End-to-end arguments in system design^[1] by Jerome H. Saltzer,David P. Reed, and David D. Clark, argued that reliable systems tend to require end-to-end processing to operate correctly, in addition to any processing in the intermediate system. They pointed out that most features in the lowest level of a communications system have costs for all higher-layer clients, even if those clients do not need the features, and are redundant if the clients have to reimplement the features on an end-to-end basis.

This leads to the model of a "dumb, minimal network" with smart terminals, a completely different model from the previous paradigm of the smart network with dumb terminals. However, the End-to-end principle was always meant to be a pragmatic engineering philosophy for network system design that merely prefers putting intelligence towards the end points. It does not forbid intelligence in the network itself if it makes more practical sense to put certain intelligence in the network rather than the end-points. David D. Clark along with Marjory S. Blumenthal in "Rethinking the design of the Internet: The end to end arguments vs. the brave new world" wrote in 2000:

From the beginning, the end to end arguments revolved around requirements that could be implemented correctly at the end-points; if implementation inside the network is the only way to accomplish the requirement, then an end to end argument isn't appropriate in the first place.

Occam’s Razor (http://en.wikipedia.org/wiki/Occam%27s_Razor)

William Ockham (c. 1285–1349) is remembered as an influential nominalist but his popular fame as a great logician rests chiefly on the maxim attributed to him and known as Occam's razor: Entia non sunt multiplicanda praeter necessitatem or "Entities should not be multiplied unnecessarily." The term razor refers to the act of shaving away unnecessary assumptions to get to the simplest explanation.

Critique

I found the paper very effective in explaining the merits of applying the end-to-end principle in system design. I agree that system designers must not be overzealous in providing functions at the low-level subsystem in the attempt to “help” the users at the higher level. A good system is one that provides only the functions that are absolutely necessary, and this will result in overall cost-effectiveness. Ultimately, which functions should be provided in each layer must be decided based on requirements analysis of the application that will use the system. Entities should not be multiplied unnecessarily.

Main Reference:

End-to End Arguments in System Design

by Saltzer, et al

Article Review 1: DARPA

Summary

The paper discusses in detail how the DARPA internet protocols used today were developed.

The fundamental goal of the DARPA Internet Program was to develop a technique for utilizing the currently existing networks of the Department of Defense. This fundamental goal can be described in detail by seven second-level goals, which identifies in order of importance the desirable features of an effective interconnection. The most important goal in the list states that internet communication must continue despite of loss of networks or gateways. To achieve this goal, the fate-sharing approach, wherein it is acceptable to lose the state information of an entity being transmitted over the network if the entity itself is also lost, was chosen over replication. Another goal is that the internet should be able to support a variety of services. As a result, the TCP and IP protocols -- which were originally just 1 protocol, were created as two separate layers. A third goal was to incorporate and utilize a wide variety of network technologies – including military and commercial facilities. The basic assumption in achieving this flexibility is to have a datagram or packet of reasonable size with acceptable delivery.

The top 3 goals of survivability, supporting a variety of types of service, and accommodating a variety of networks, had the most effect in the existing architecture of the internet today. The other remaining goals were not met as effectively. The challenge today is to design networks using the existing internet protocols that would best fit the desired performance levels and type of service required. The author suggests exploring alternative building blocks from the datagram, and one he specified is called “flow”. The gateways will monitor the flow state to remember the nature of the flows that are passing through them. Then endpoints will enforce what type of service will be associated with the flow by sending messages. The DARPA Internet Program is currently conducting explorations of alternative building blocks .

Background

What is DARPA?

The Defense Advanced Research Projects Agency (DARPA) is an agency of the United States Department of Defense responsible for the development of new technology for use by the military. DARPA has been responsible for funding the development of many technologies which have had a major impact on the world, including computer networking, as well as NLS, which was both the first hypertext system, and an important precursor to the contemporary ubiquitous graphical user interface.

DARPA is independent from other more conventional military R&D and reports directly to senior Department of Defense management. DARPA has around 240 personnel (about 140 technical) directly managing a $3.2 billion budget. These figures are "on average" since DARPA focuses on short-term (two to four-year) projects run by small, purpose-built teams.

http://en.wikipedia.org/wiki/Defense_Advanced_Research_Projects_Agency

Critique

I honestly found the beginning of this paper boring. It was a struggle just getting past the first page. Surprisingly enough the material becomes a more interesting read when the goals were being discussed and the pros and cons for choosing one method over another were being explained. Overall, the DARPA internet project is a good example that not all project goals can be achieved (whether this is planned failure or a sad reality, is subject to argument). And many times, certain aspects have to be sacrificed in order to make way for more important objectives.

As a last note, I found it really funny on how the author subtly injected humor by saying that he does not have an idea on how to guide the procurement person (at DARPA?) who did not make sure that the performance specifications were in the procurement documents, but let slide limitations that would limit the performance goals.

Main Reference:

Design philosophy of the DARPA internet protocols

by David C. Clark