E2E Paper

This paper is essentially advocating a minimal network implementation in favor of having error-checking, security, and all other issues (such as guarantees of FIFO ordering) done by the programmers of the high level application. The reasoning behind this is that correctness constraints within the network itself do not necessarily guarantee correctness at the application level. Furthermore, the correctness constraints that would be provided by the network level may be more than is necessary for the application level (a typical VOIP example is provided in this situation).

Thus, the applications must provide their own error-checking routines and checksums regardless of any that may exist at the network level. This means that such routines at the network level simply add additional overhead, with no practical benefit. This paper therefore advocates having no such routines at lower levels, unless they improve the efficiency of the higher levels (and of course, there is a tradeoff to be found here). Even when this is the case, lower level protocols do not need to guarantee correctness; they only need to make incorrectness much less likely.

This paper shows a great deal of foresight; I don't believe there were any VOIP services at the time that it was written. It also hints at the counter-argument of modularity, which would suggest that the low level network routines should include all sorts of guarantees so that high level application developers don't have to rewrite the same code (with slight modifications) over and over again.

This paper sheds light on the existence of protocols. UDP is a protocol that lacks any guarantees, as the paper advocates. However, in many applications (especially applications that involve data transfer, such as instant messaging clients and web servers), the checks and guarantees provided by TCP make perfect sense and are suitable for the problem at hand.

One modern school of thought on programming in general is that as computers continue to get faster, it's favorable to sacrifice some performance in favor of decreasing the amount of time spent programming. This argument can just as easily be applied to computer networks. With the introduction of broadband and cable, computer networks are incredibly fast (and they can be expected to get faster). This allows us to ask whether it is beneficial to use a small amount of network overhead to significantly boost programmer productivity. Of course, this question is only applicable now, and was not applicable when this paper was first published.