the end-to-end principle

Suppose you want to mail a fragile vase and be sure it arrives intact. You could demand that every post office and truck along the way handle it with extra care — or you and the recipient could agree on a check at the ends: she opens the box, and if anything is broken, she phones you and you resend. The second approach keeps the postal system simple and still gets you a guarantee. The end-to-end principle is that idea applied to networks: put the smarts in the end hosts, and keep the network in the middle as simple and general as possible.

Stated more precisely, a function such as reliable, in-order, error-free delivery often cannot be completely and correctly implemented by the network alone — the end points have to check anyway, because errors can creep in above the network (in memory, in the application). Since the ends must do the check regardless, building that same function deep into every router is often redundant and may even hurt performance for applications that don't want it. So such functions belong primarily at the ends. This is exactly why TCP's reliability lives in your computer and the server, not in the routers between them, and why UDP can simply skip reliability for apps that prefer speed.

Why it matters: this principle shaped the Internet's design. A simple, dumb core that just forwards packets is cheap, scalable, and easy to extend — new transport protocols (TCP, UDP, QUIC) and new applications can be deployed at the edges without upgrading the middle. The principle is a guideline, not an absolute law: real networks add in-network functions like NAT, firewalls, and caching for practical reasons, and these middleboxes sometimes break the clean end-to-end model. But the core insight — keep the network general, push specialization to the edges — remains one of the most influential ideas in computer networking.