End-to-end arguments, put the function at the endpoint.

TL;DR

Consider a file transfer from one computer to another, where the goal is reliable delivery. You could put reliability at the application layer (the receiver computes a checksum on the file after it arrives), at the transport layer (TCP retransmits dropped segments), at the link layer (Ethernet retransmits lost frames), or in the file system (the sender re-reads the file after writing). Saltzer, Reed and Clark argue: only the application-layer check actually verifies what the application cares about — that the file is correctly stored on the destination disk. Lower-layer mechanisms detect some failures but can't detect application-relevant ones (corrupted on the receiver's disk before checksumming, for example). The paper formalises this into a principle: a function should be implemented at the layer where it can be done correctly, and lower layers should be optimised for performance rather than completeness.

The problem

The 1970s and early 1980s were dominated by competing visions of how networks should be structured. The PTT-led telecom industry favoured intelligent networks: every link reliable, every routing decision made by the network, applications doing little. The ARPA / DARPA community favoured the opposite: a "best-effort" network where applications handled reliability themselves. The argument was contentious — the X.25 standard provided reliable virtual circuits at the network layer; TCP took reliability all the way up to the transport and let the network drop packets at will.

The Saltzer paper provided the architectural justification for the ARPA position. It wasn't a partisan argument; it was an analysis of when intermediate-layer functions actually help vs when they're wasted effort. The reasoning was rigorous enough that the paper was cited in every subsequent design decision about TCP/IP, ATM, MPLS, and so on.

The key idea

The central idea: most "checks" or "guarantees" provided by an intermediate layer are incomplete — they catch failures within that layer but miss failures at adjacent layers. Only an end-to-end check (sender to receiver) verifies the property the application actually cares about. Therefore: put the function at the endpoints; don't replicate it at intermediate points unless the replication provides a worthwhile performance optimisation.

The paper works through several examples. File transfer: a link-layer checksum verifies a single link, but the file can still be corrupted at the receiver's file system. A receiver-side application checksum verifies what the application cares about. Encryption: link-layer encryption protects the link, but the data is decrypted on intermediate routers and visible to them. End-to-end encryption protects the message regardless of the path. Duplicate suppression, transaction management, reliable delivery — each follows the same pattern.

The paper is careful to qualify: end-to-end implementations don't mean intermediate-layer mechanisms are wrong. A link-layer retransmission can be a performance optimisation — it's cheaper to recover a lost packet on the link where it was lost than to retransmit from the sender. The principle is that the end-to-end check is required for correctness; intermediate mechanisms are performance helpers.

Contributions

Named the principle. Before this paper, the trade-off was informal. After it, "end-to-end" became the standard architectural vocabulary.

Justified TCP/IP's design. The paper was the philosophical foundation for the IETF's approach to reliability, congestion control, and transport-layer placement. The "stupid network, smart endpoints" framing came directly from this argument.

Anti-pattern catalogue. The paper points out cases where intermediate layers tried to provide end-to-end-equivalent functions and got it wrong — usually because the layer couldn't see the failure mode that the application cared about.

Performance qualifier. The principle isn't absolute: intermediate-layer mechanisms can be performance optimisations. The paper carefully separates correctness (always at endpoints) from optimisation (might be lower).

Criticisms and limitations

The principle is sometimes mis-applied. Some applications can't do certain functions at the endpoint efficiently — encryption with key management, deduplication of large objects, content-delivery caching. The principle says "if you can do it correctly at the endpoint, do it there"; it doesn't say "don't add intermediate mechanisms ever".

The middle has crept back. Modern networks have re-acquired a lot of intermediate intelligence: TLS-terminating load balancers, anti-DDoS scrubbing centres, CDN edge logic, programmable switches, eBPF in the kernel. The argument now is whether these are end-to-end-principle violations (the original authors' position would be: yes, they're performance optimisations, not correctness mechanisms) or evidence that the principle is too strict.

The paper assumes the endpoints can be trusted. In a world of compromised endpoints (malware, supply-chain attacks), end-to-end mechanisms aren't obviously enough. Recent work on confidential computing tries to provide end-to-end-style guarantees while protecting against compromised endpoints.

Where it shows up today

TCP/IP, every layer-3 protocol: best-effort delivery; endpoints handle ordering and retransmission.

HTTPS / TLS: the encryption is end-to-end between client and server; intermediate proxies see only ciphertext.

QUIC / HTTP/3: takes the principle further by encrypting transport metadata too, so middleboxes can't even see the packet number.

The IETF design principles documents (RFC 1958, RFC 3724) cite this paper directly.

Modern application architectures: trust the application layer for retries and idempotency; treat the cloud as a best-effort substrate. The opposite of the X.25 "intelligent network" worldview the paper was arguing against in 1984.

Follow-up reading

• Rethinking the Design of the Internet: The End-to-End Arguments vs the Brave New World — Blumenthal & Clark · 2001. Twenty years later, Clark revisits the principle in the context of NATs, firewalls, CDNs, and the rise of the "middle".
• TCP Congestion Control — Van Jacobson · 1988 · SIGCOMM. End-to-end congestion control as the response to the 1986 internet collapse.
• Active Networks: An Idea Whose Time Has Passed? — Spatscheck · 2013. A retrospective on programmable-network proposals that violated the end-to-end principle.
• RFC 1958: Architectural Principles of the Internet — Carpenter · 1996 · IETF. The IETF's own articulation, citing this paper as the source.
• The QUIC Transport Protocol — Langley et al · 2017 · SIGCOMM. How modern transport takes end-to-end further.