The Web. E-mail. File sharing. Voice over Internet Protocol (VoIP). Stalker-friendly tools. These are just some of the services available to us through the Internet. What makes these services particularly useful is the nature of the Internet itself: interconnected networks. Through this setup, we are able to video conference with relatives on the other side of the globe, download a movie from a mirror in Germany, and follow Megan Fox on Twitter. All these, of course, we owe to the architecture that made the very concept of connecting different types of networks possible.
This architecture is the topic of David Clark’s paper, titled “The Design Philosophy of the DARPA Internet Protocols”[1]. It provides an insight on the Internet’s primitive architecture, as well as the rationalization behind it.
Before I proceed with details of the paper, I have to admit first that I got confused with the article’s constant shift in discussing between the Internet protocol suite and the Internet’s architecture. To me, it seemed that the author was using the concepts “Internet protocol suite” and “Internet’s architecture” interchangeably, that in some context, I may have misinterpreted them to be the same banana. But, of course, that is not the author’s fault (this is an MIT paper, by the way), and I attribute it to my shallow knowledge in networking. So if ever I get to mix-up or bungle some concepts, pardon me.
The Protocols that Paved the Way for LOLS (and Other Web Jargons)
Now, here comes the serious part. The paper started with a brief introduction on the Transmission Control Protocol (TCP) and the Internet Protocol (IP), collectively known as TCP/IP or the Internet protocol suite. It stated there that the TCP/IP was developed by the Defense Advanced Research Projects Agency (DARPA) some decades back. If I’m not mistaken, though, Vinton Cerf have been doing work on this project even before he became part of DARPA, that is why he is widely regarded as the “Father of the Internet” (not to be confused with Sir Tim Berners Lee, who is the “Father of the World Wide Web”).
As the author said, information about of these protocols is reasonably available, but the motivation and rationalization behind their design is not clear. To give a perspective on how these protocols came to be, the original objectives of the Internet architecture were discussed, starting from the most important goals to the least important ones.
Fundamental Goal
According to the author:
“The top level goal for the DARPA Internet Architecture was to develop an effective technique for multiplexed utilization of existing interconnected networks.”
This goal could very well be the Internet’s defining principle, as well as its claim to fame. To achieve this, the architects were given several options, including the use of circuit switching. But the networks that were to be connected and the applications that they support were based on packet switching, so the method chosen for interconnecting the networks is also packet switching. This became the foundation of today’s Internet structure. No further reason is given as to why this approach was used, so it seems they simply made the logical (and obvious) choice.
However, they also had an alternative to interconnecting existing networks, and that is the creation of a new system that would incorporate different transmission media, resulting to a multi-media network. The author described this as possibly having “a higher degree of integration” resulting to “better performance”, but the architects preferred the use of the existing networks, believing this was necessary if the Internet was going to be “useful in the practical sense.” If the worldwide success attained by the Internet today were any indication, the architects have indeed made the right decision. But the prospect of using a unified network system is enticing. I think this may lead to the standardization of the different transmission media catering to various types of networks.
Second Level Goals
A more detailed list of goals was also presented, this time focusing on how the Internet should behave:
1. Internet communication must continue despite loss of networks or gateways.
2. The Internet must support multiple types of communications service.
3. The Internet architecture must accommodate a variety of networks.
4. The Internet architecture must permit distributed management of its resources.
5. The Internet architecture must be cost effective.
6. The Internet architecture must permit host attachment with a low level of effort.
7. The resources used in the internet architecture must be accountable.
These goals are arranged in order of priority, and must be viewed relative to the context of military use (after all, this is a project of the US Department of Defense).
The top priority in this list is survivability. At first glance, the first goal may sound like continuous uninterrupted connection. Actually, it simply meant that there should be a provision that would allow communications to resume, without having to reestablish conversations, after services are temporarily interrupted due to some network failure. To accomplish this, the architects decided to preserve communication states by storing them in the entities using the network services. This approach is termed by the author as “fate-sharing” (a precursor to session data, perhaps?). This removed the burden of maintaining states from the packet switches, giving the Internet a “datagram” network design. I have to emphasize here that the author once again pointed out a possible advantage of using a multi-media network, saying that a more survivable technology might have been derived from this type of network design.
The support for multiple types of services is the second goal of the Internet architecture. Initially, it was thought that the TCP was general enough support any type of service. But as the nature of certain services became more defined, it became apparent that the reliable service provided by the TCP inappropriate for some them. The reason: some services prioritize other network characteristics, such as speed and latency, over reliability. This led to the separation of IP from TCP into a separate layer. IP provides the basic building block, in the form of a datagram, needed to allow to a variety of services to build upon it. Combined, the TCP/IP provides the flexibility needed to handle several types of services.
The third goal is the support for different types of networks. This was achieved through making a minimum set of assumptions about network behaviors and capabilities, and configuring the Internet architecture to ensure that it would cater to these assumptions. I view these assumptions as the interface that other networks must adhere to in order to be supported by the Internet.
The other goals in the list are considered to be of lower importance, so some of them may have only been partially satisfied, if not completely unsupported as of the paper’s writing. But these days, one may observe that the lesser prioritized goals are already satisfied to a certain extent, giving us a clue that changes might have already taken place in the architecture.
Like in the case of distributed management of resources, I’d say the modern server-client setup, wherein servers are allowed to control the resources given to clients, addresses this goal. Personally, I’d also say that the aim of allowing host attachment with low level effort have also been achieved, as we all could easily connect to the Internet through the simple configuration of our machine’s network properties (given that Internet access is available). Accountability, it seems, has also been addressed. I have encountered several websites that became inaccessible because they have reached the bandwidth limit provided by their hosts. The issue of cost effectiveness, though, is something that I cannot comment about. I’m not sure what qualifies as cost effective in networking terms, nor am I aware of what’s exactly going on beneath the surface.
One specific goal that I was expecting to be addressed, but surprisingly isn’t in the list is security. Well, I’m guessing that it’s either that the burden of security is placed on the individual networks connected to the Internet, or it doesn’t make sense to support it at the architecture. But if these weren’t the case, then no wonder the Internet is continuously being bothered by security issues. =)
Conclusion
Clark’s article provides a fairly detailed insight on the history of the Internet’s architecture. Interestingly, the design decisions made in order to come up with what was the initial Internet architecture were fairly straightforward (well, that is how it seems in paper, at least). In software engineering, there are no hard and fast rules for making software designs, just heuristics. This might have been the case for some of the design philosophy behind the Internet’s architecture. But nobody can argue with success.
References:
[1] D.D. Clark. The Design Philosophy of the DARPA Internet Protocols. ACM SIGCOMM Computer Communication Review, Vol. 18, Issue 4. August 1988.
Friday, June 26, 2009
End-to-End Argument
Sometimes, simple arguments can lead to profound effects.
Take the case of the paper titled “End-to-End Arguments in System Design”[1], authored by J.H. Saltzer, D.P. Reed and D.D. Clark. The paper offers a guide for the placement of functions in communication systems in the form of a principle called the “end-to-end argument”.
The argument goes as follows:
“The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the end points of the communication system. Therefore, providing that questioned function as a feature of the communication system itself is not possible. (Sometimes an incomplete version of the function provided by the communication system may be useful as a performance enhancement.)”
It is as an argument proposing the implementation of functions on the application level as much as it is an argument for discouraging (or at least regulating) the placement of functions in the lower-levels of a system. The reason is quite blunt: place functions on where they will matter, not on where they will just waste resources.
To emphasize the concept being suggested by the argument and to demonstrate the wide range of situations to which this argument applies, they’ve provided several scenarios. I’ll only discuss one of them here, since all of them more or less provide the same idea.
File Transfer Scenario
File transfer is a fairly basic service provided by networks, but this is not necessarily protected from errors. Here are some possible threats enumerated by the authors (based on the setup of two host exchanging files through a network):
1. The file, though originally written correctly onto the disk at host A, if read now may contain incorrect data, perhaps because of hardware faults in the disk storage system.
2. The software of the file system, the file transfer program, or the data communication system might make a mistake in buffering and copying the data of the file, either at host A or host B.
3. The hardware processor or its local memory might have a transient error while doing the buffering and copying, either at host A or host B.
4. The communication system might drop or change the bits in a packet, or lose a packet or deliver a packet more than once.
Given these threats, provisions for ensuring reliable file transfers must be put in place. Following the end-to-end argument, error checking should be implemented in the file transfer application on both hosts, since it is only at that level can the success of the operation can be truly verified.
The communication system may also enforce reliable data transfer using a variety of error checking functions, but this will not guarantee that the file that will arrive at the receiving end is correct. Other forms of errors may occur outside of the communication system before it arrives at its destination disk storage system. As a result, the file transfer application must still perform error checking whether the data coming from the communication system is reliable or not. Not only is the use of functions in the lower levels of the system in this case futile, they are also an instrument for wasteful consumption of resources.
Performance
The authors, however, didn’t completely rule out the implementation of functions on the lower-levels of a communication system. In some cases, particularly in performance issues, this may have beneficial effects too. For example, using functions for ensuring reliability on the lower-levels of a network may increase its performance if the frequency of retrying file transfers outweighs the delay caused by the implementation of these functions. But the authors suggest that such low-level implementations be used only for performance enhancements.
Remark
I agree on the principle being raised by the end-to-end argument. It’s a matter of avoiding the redundant use of resources, and putting functions where they only truly count. Their examples drive home the point of the argument.
I have a minor comment on their argument, though. If they can assume that faults may occur on areas that are expected to be reliable (such as disk storage systems), wouldn’t it be fair to say that the same thing could apply to the applications on the end points of a system, such as the file transfer program? In fact, the second threat in the file transfer scenario highlights this matter. Now, if a file transfer application can commit mistakes in the simple process of buffering and copying data, then much more in the act of error checking (such as the verification of checksums). In short, their end-to-end argument wouldn’t hold if the integrity of end point applications is also compromised.
Conclusion
The authors have presented an argument, which they claim to be similar to “Occam’s razor” (though their scenarios seem to be inspired by Murphy’s Law), for making decisions on the placement of functions in a system. They themselves have admitted that this is not a strict rule to be followed, but a just mere guideline. If applied to a proper context, this simple guide can provide significant benefits for a network.
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.
Take the case of the paper titled “End-to-End Arguments in System Design”[1], authored by J.H. Saltzer, D.P. Reed and D.D. Clark. The paper offers a guide for the placement of functions in communication systems in the form of a principle called the “end-to-end argument”.
The argument goes as follows:
“The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the end points of the communication system. Therefore, providing that questioned function as a feature of the communication system itself is not possible. (Sometimes an incomplete version of the function provided by the communication system may be useful as a performance enhancement.)”
It is as an argument proposing the implementation of functions on the application level as much as it is an argument for discouraging (or at least regulating) the placement of functions in the lower-levels of a system. The reason is quite blunt: place functions on where they will matter, not on where they will just waste resources.
To emphasize the concept being suggested by the argument and to demonstrate the wide range of situations to which this argument applies, they’ve provided several scenarios. I’ll only discuss one of them here, since all of them more or less provide the same idea.
File Transfer Scenario
File transfer is a fairly basic service provided by networks, but this is not necessarily protected from errors. Here are some possible threats enumerated by the authors (based on the setup of two host exchanging files through a network):
1. The file, though originally written correctly onto the disk at host A, if read now may contain incorrect data, perhaps because of hardware faults in the disk storage system.
2. The software of the file system, the file transfer program, or the data communication system might make a mistake in buffering and copying the data of the file, either at host A or host B.
3. The hardware processor or its local memory might have a transient error while doing the buffering and copying, either at host A or host B.
4. The communication system might drop or change the bits in a packet, or lose a packet or deliver a packet more than once.
Given these threats, provisions for ensuring reliable file transfers must be put in place. Following the end-to-end argument, error checking should be implemented in the file transfer application on both hosts, since it is only at that level can the success of the operation can be truly verified.
The communication system may also enforce reliable data transfer using a variety of error checking functions, but this will not guarantee that the file that will arrive at the receiving end is correct. Other forms of errors may occur outside of the communication system before it arrives at its destination disk storage system. As a result, the file transfer application must still perform error checking whether the data coming from the communication system is reliable or not. Not only is the use of functions in the lower levels of the system in this case futile, they are also an instrument for wasteful consumption of resources.
Performance
The authors, however, didn’t completely rule out the implementation of functions on the lower-levels of a communication system. In some cases, particularly in performance issues, this may have beneficial effects too. For example, using functions for ensuring reliability on the lower-levels of a network may increase its performance if the frequency of retrying file transfers outweighs the delay caused by the implementation of these functions. But the authors suggest that such low-level implementations be used only for performance enhancements.
Remark
I agree on the principle being raised by the end-to-end argument. It’s a matter of avoiding the redundant use of resources, and putting functions where they only truly count. Their examples drive home the point of the argument.
I have a minor comment on their argument, though. If they can assume that faults may occur on areas that are expected to be reliable (such as disk storage systems), wouldn’t it be fair to say that the same thing could apply to the applications on the end points of a system, such as the file transfer program? In fact, the second threat in the file transfer scenario highlights this matter. Now, if a file transfer application can commit mistakes in the simple process of buffering and copying data, then much more in the act of error checking (such as the verification of checksums). In short, their end-to-end argument wouldn’t hold if the integrity of end point applications is also compromised.
Conclusion
The authors have presented an argument, which they claim to be similar to “Occam’s razor” (though their scenarios seem to be inspired by Murphy’s Law), for making decisions on the placement of functions in a system. They themselves have admitted that this is not a strict rule to be followed, but a just mere guideline. If applied to a proper context, this simple guide can provide significant benefits for a network.
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.
Subscribe to:
Posts (Atom)