Wednesday, June 24, 2009

Review: The Design Philosophy of the DARPA Internet Protocols

The paper, The design philosophy of the DARPA internet protocols by David D. Clark [1], presents some of the early reasoning and motivations that contributed to the how the Internet was designed. The top level goal for the DARPA Internet Architecture was to develop an effective technique for multiplexed utilization of existing interconnected networks. They established a list of detailed goals ranked by their importance to DARPA project to achieve the fundamental goal.

Because this was a military project, the first goal on the list was survivability, which means the Internet should continue to supply communication service even though networks and gateways are failing. In other words, the connection should never be lost unless there is no physical path. The architecture chose the "fate sharing" approach wherein the end host is made responsible of maintaining the state information about an ongoing connection, and this lead to the use of "datagram" networks which made the internet, "connectionless". The second and third goal was to support a variety of types of services and utilize a wide variety of network technologies. Because of this, TCP and IP became two layers and the datagram became the basic building block in which multiple types of services could be constructed from. The remaining goals were: The internet architecture must permit distributed management of its resources, must be cost effective, permit host attachment with a low level of effort and the resource used in the Internet architecture must be accountable. Because these goals were lower in importance, they were less effectively met or not completely engineered but nonetheless contributed to the success of the Internet. And it was mentioned by the author that if the order of the goal list were different, a different Internet architecture would have been created. And with this, he suggests that there may be a better design of the Internet if the designer's priorities match with those of the actual users.

The author did a great job of giving the details on how and why the Internet was designed. The designers of the Internet architecture were successful in meeting their ordered list of goals which suited the need of the DARPA project. However I do agree with the author that the priorities of the list of goals have changed since the migration from military to commercial setting. Some of the goals that were lower in importance when the Internet was created that have less been effectively met might led to the Internet's deficiencies today.

It was mentioned in the paper that an alternative to interconnecting existing networks was to design a unified system which incorporated a variety of different transmission media or a multi-media network. At the time of the design of the Internet, the support for multimedia traffic was not a priority because it was not one of their needs at that time and also multimedia traffic was a minimum. However, today's Internet is heavily burdened by large amount of multimedia traffic. Is the Internet still sufficient in providing good performance? Although the Internet is flexible enough to support the various services that have been created over the years, some of these services might be wearing this flexibility.

References:

[1] D. D. Clark, "The design philosophy of the DARPA Internet protocols," ACM SIGCOMM Computer Communication Review, vol. 18, issue 4, August 1988.

Review: End to End Arguments in System Design

The paper, End-to-end arguments in system design by J.H. Saltzer, D.P. Reed and D.D. Clark [1] presents a design principle called end-to-end argument that discourages the placement of functions in the lower level of the system unless they provide performance enhancements. It suggest instead that these functions be move upward in the layered system, closer to the application or the End where the requirements for these functions are more defined. The only justification of creating a lower level function is to provide performance optimization but only to certain degree. However, the end-to-end argument is not absolute but rather a guideline and one must use some care to identify the Ends to take the right approach.

As mentioned in [2], the end-to-end principle is one of the key architectural guidelines of the Internet. Because of the bias of the principle in the movement of function "up" from the lower level or the network and "out" to the edge node or applications, the Internet network have remained rather simple and general and because of this, it is able to support many different applications like e-mail, World Wide Web (WWW), web browsers, multi-player games etc. The application of the end to end arguments makes the network transparent, packets go in and they come out and that is all that happens in the network.

The biggest advantage of use of the end to end arguments as a design principle is the simplicity that it produces at the lower levels of a system. Building simple rather than complex lower layers increases the potential uses of these layers which may be unknown or unpredictable at design time. Because of this design, the Internet was able to grow. By making the host responsible for reliability, the network's role was made simple and it became possible to join the different networks that existed at that time.

However the principle's biggest advantage might well be its source of fault. Aside from the additional work that is left out for the higher layer in implementing functions, placing the functions in the slower upper layers has potential performance cost.


References:

[1] J. H. Saltzer, D.P. Reed and D. D. Clark, "End-to-end arguments in system design," ACM Transactions in Computer Systems, vol. 2, no. 4, pp. 277-288, November 1984.

[2] M. S. Blumenthal and D. D. Clark, "Rethinking the design of the Internet: The end to end arguments vs. the brave new world," ACM Transactions on Internet Technology, vol. 1, no. 1, pp. 70-109, August 2001.