The end-to-end approach
Reaction to {End-To-End Arguments in System Design by J.H. Saltzer, D.P. Reed and D.D. Clark}
The objective of any communication system is to transfer a message from the origin to the destination correctly, promptly, and efficiently (ideally). However, as in all man-made systems, perfection is impossible — errors arise and compromises are made and a certain property (correctness, speed of delivery, cost, etc.) is prioritized depending on the application. In a layered architecture, all the layers will have their own imperfections, and where to implement and what the solution will be depends on how drastic and frequent the errors are.
The end-to-end (E2E) argument is a guideline in system design to relegate implementing functions to the endpoints (or highest level) if low-level knowledge is insufficient to successfully implement it. Saltzer et al. cites situations when an E2E approach is suitable, and when it is not. Examples of when the E2E argument applies are:
- When the communication system is acceptably reliable (for all applications using it), and there are errors outside the communication system (and/or within the endpoints) that can only be checked by the endpoints;
- When the communication system is shared, and other applications which do not require the function are penalized (larger payload/reduced bandwidth, for example);
- Or simply when the endpoints can implement the function better.
In the “Careful File Transfer” example, the E2E approach is appropriate because there are errors that occur in the higher layers aside from those in the communication system, and so the endpoints will have to do their own checks anyway — efforts to ensure 100% reliability of the communication system would be a waste since it still won’t guarantee error-free messages. This is not to say that one should not exert effort to improve the communication system’s reliability, but rather, ensure that the communication system is sufficiently reliable for the applications using it, so that the cost of making it so is justified. The E2E argument also reminds designers to consider the effects to all applications using the shared communication system when implementing certain features as low-level functions, because they become imposed.
The IP layer in the TCP/IP model makes use of the end-to-end approach, and by implementing just the necessary functions and stripping off other features, the designers were able to make it flexible and extensible. Looking at how big the Internet has become, would make us appreciate this minimalist approach. The open-ended design now enables the Internet to be used in transmitting different kinds of data — text, voice, multimedia, etc. The TCP/IP suite’s design has served us well over the years, but research in the field is not stagnant because as more and more potential uses for it are unveiled, obstacles also appear. For example, what happens in an overly congested area where wireless LAN is the only option?
It is tempting for designers to create all the functions an application could possibly need, but this usually results in a bloated system that is slow and inefficient. An analogy that immediately came to my mind is some operating systems — consider Microsoft Windows. It used to be that the web browser Internet Explorer could not be uninstalled without causing many of the system applications to malfunction. I don’t like to use Internet Explorer as my web browser, but it is an imposed feature — installing other browsers like Mozilla Firefox or Opera does the web browsing function better, but the footprint of IE remains as I could not delete it from my hard drive. In this analogy, MS Windows is the shared communication system, the web browser is the function which could have been left to a higher layer (the user), IE is the imposed feature, Mozilla Firefox or Opera is the reimplementation, and the hard drive space is the cost. Another example that comes to mind is barebone computers.
E2E is applicable in many instances, but not always. The Internet is the way it is, because it was what was needed at that time — it developed from a set of goals; with some goals more prioritized than the rest. The designer needs a thorough understanding of the goals and requirements, and choose which approach is most appropriate. The mark could be anywhere between the spectrum; the designer’s objective is to find that sweet spot.
Filed under: Computer Networks | Leave a Comment
No Responses Yet to “The end-to-end approach”