In the late 1990s, when I was in graduate school, the paper
JH Saltzer; DP Reed; DD Clark: End-to-end arguments in system design. ACM Trans. Comput. Syst. 2(4):277-288, 1984. DOI=10.1145/357401.357402
was pretty much required reading in every operating systems class at every university, and it still seems to be one of the primary guiding principles underlying the design of the internet. (See for example: J Kempf, R Austein (eds), and the IAB, "The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Architecture," RFC 3724, March 2004.)
The end-to-end principle states (Saltzer et al., 1984):
[If] 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, ..., providing that questioned function as a feature of the communication system itself is not possible. [Although] sometimes an incomplete version of the function provided by the communication system may be useful as a performance enhancement.
Or more briefly (from the abstract):
The end-to-end argument suggests that functions placed at low levels of a system may be redundant or of little value when compared with the cost of providing them at that low level.
But I've had little success applying the end-to-end principle in my own experience (which is in computer architecture, not internet architecture). Since the principle is stated as a "poem" (i.e., in English prose with a bunch of terms that are not mathematically defined) it is quite easy to fool oneself into thinking that "the function in question can completely and correctly be implemented only with the knowledge and help of the application." But what is "the function in question," let alone "the knowledge and help" of an application?
Example: On-chip networks (unlike the internet) aren't allowed to drop packets, but have quite limited buffering, so you need to have some way of either avoiding or recovering from deadlock. On the other hand, the application needs to make itself deadlock free as well, right? So I might reason that I should make the common case (no deadlock) fast and push deadlock avoidance off on the app. This is, in fact, what we tried on Alewife and Fugu (Mackenzie, et al., Exploiting Two-Case Delivery for Fast Protected Messaging, Int'l Symp High-Perf Comp Arch, (HPCA-4):231-242, 1998. Or John Kubiatowicz's dissertation.) It "worked," (by having the interconnect interrupt the processor when the buffers got filled and having the OS augment with software buffering) but I haven't seen anyone in academia or industry (including any of us that were authors on that HPCA paper) racing around trying to replicate the idea. So apparently deadlock avoidance in a network is not the same "function in question" as application-level deadlock avoidance, or the end-to-end principle is wrong.
Is it possible to turn the end-to-end principle from a "poem" into a theorem? Or at least, can it be stated in terms understandable to a computer architect?