The word “dumb” does not appear anywhere in the paper. Neither does “stupid,” nor “intelligence,” nor — and this one is worth sitting with — the phrase “end-to-end principle.” What Saltzer, Reed and Clark actually published is called the end-to-end argument, that exact phrase appears twenty-eight times in it, and its abstract closes on a sentence the popular version flatly contradicts:
Low level mechanisms to support these functions are justified only as performance enhancements.
Justified. Not forbidden. The most-cited architectural idea in computer networking spends a whole section explaining when you should implement the function in the lower layer after all — and that section is the first thing almost every retelling deletes.
That deletion is why this article is aimed at engineers who will never configure a router. The argument is not about networks. It is a general test for where in a system a function belongs, and the paper says so itself, working through magnetic-tape backup, encryption key management, two-phase commit and RISC instruction sets alongside the packet-switching examples. Networking is where the reasoning got famous, not where it applies.
The claim, and the parenthesis carrying half of it
Here is the passage, from the full text on J.H. Saltzer’s own MIT page:
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. Therefore, providing that questioned function as a feature of the communication system itself is not possible. (Sometimes an incomplete version of the function provided by the communication system may be useful as a performance enhancement.)
Read it as three moves rather than one slogan. The first names a condition: the function needs knowledge only the end points hold. The second draws the consequence — given that condition, a complete implementation lower down is not possible, not merely inelegant. The third, in parentheses, gives the lower layer its job back on different terms.
It is a completeness test, not a purity test
Nothing there says a lower layer must stay simple or that networks should do less. It says a particular function, in a particular system, cannot be finished anywhere except at the ends. You run the test per function: does correctness here require information that only exists over there?
The paper’s opening line frames the whole thing as an ordinary design problem rather than an ideology:
Choosing the proper boundaries between functions is perhaps the primary activity of the computer system designer.
The publication trail, since it gets muddled
The paper has two canonical appearances and citations mix them freely. The first version was presented at the Second International Conference on Distributed Computing Systems in Paris, 8–10 April 1981, pages 509–512; the revised version nearly everyone actually cites appeared in ACM Transactions on Computer Systems, volume 2, number 4, November 1984, pages 277–288, and was reprinted in Craig Partridge’s Innovations in Internetworking in 1988. All of it is printed in the paper’s own front matter.
The slogan against the paper, line by line
| The slogan says | The paper says | Where to check |
|---|---|---|
| “Keep the network dumb” | The string “dumb” appears zero times | Search the full text |
| Intelligence belongs at the edges | Certain functions cannot be completed below the end points | The main claim, above |
| Never implement it in the lower layer | “Low level mechanisms … are justified only as performance enhancements” | The abstract |
| A lower-layer version is a design smell | An “engineering tradeoff based on performance” | “Performance aspects” |
| It is the end-to-end principle | That phrase appears zero times; “end-to-end argument” appears 28 | Search the full text |
| It is about networks | Worked examples include RISC, tape backup, two-phase commit | Sections on other systems |
“Performance aspects” is a section heading, not a footnote
The paper does not leave the caveat in a parenthesis; it builds a case for it, arithmetically, over roughly a page. The setup is a network dropping one message in a hundred. Send a whole file and check it afterwards, and the probability that every packet survived falls exponentially with file length, so expected transfer time grows exponentially too. The authors’ conclusion is not the one the slogan predicts:
It would be too simplistic to conclude that the lower levels should play no part in obtaining reliability, however.
And then the sentence that ought to be quoted every time the argument is invoked:
Thus the amount of effort to put into reliability measures within the data communication system is seen to be an engineering tradeoff based on performance, rather than a requirement for correctness.
The balance is explicit in both directions. Too little lower-layer reliability and the application burns time on retries. Too much and you pay in redundant bytes and added delay, “when it is considered that the end-to-end check of the file transfer application must still be implemented no matter how reliable the communication system becomes.” The authors state the target themselves:
But the key idea here is that the lower levels need not provide “perfect” reliability.
They also post the warning sign, in a sentence that reads like a code review comment: “Using performance to justify placing functions in a low-level subsystem must be done carefully.” The optimisation is licensed. The excuse is not.
The paper’s cautionary tale is a real incident at MIT. Gateways between local networks checksummed each hop, so application programmers assumed transmission was reliable — while the data sat unprotected in each gateway’s memory. One gateway began swapping a byte pair roughly once per million bytes. Operating-system source files were transferred through it repeatedly, silently corrupted, and recovered by “the ultimate end-to-end error check: manual comparison with and correction from old listings.” Every per-hop check worked exactly as specified. The bytes were still wrong.
When the argument became a principle, the caveat started travelling badly
You can watch the drift happen in documents that are free to read. The authors did call it a design principle, in the abstract — but the name they gave the thing itself was always “argument.”
| Document | Date | Calls it | Keeps the performance clause? |
|---|---|---|---|
| Saltzer, Reed & Clark | 1981 / 1984 | “end-to-end argument” 28×; “end-to-end principle” 0× | It is the paper’s own clause |
| RFC 1958 (IAB) | June 1996 | Quotes “argument”, then says “This principle” | ✅ quoted, with the parenthesis |
| RFC 3234 (Carpenter & Brim) | February 2002 | “end-to-end principle” 6× vs “argument” 1× | ✅ and sharpened |
| RFC 3439 (Bush & Meyer) | December 2002 | Both; §3 is “Layering Considered Harmful” | Reframed as state orthogonality |
RFC 1958, the Internet Architecture Board’s Architectural Principles of the Internet, quotes the passage faithfully — including the parenthesis — and then, in the very next sentence, writes “This principle has important consequences.” The same section had called it an argument a few sentences earlier. The rename happens inside one page, in the document whose reference list is “deliberately limited to two fundamental papers on the Internet architecture” — and those two papers are Saltzer/Reed/Clark and Clark’s 1988 design-philosophy paper, which is a fair summary of the reading list for this entire subject.
The transcription also drifts by a space: RFC 1958 has the application “standing at the endpoints,” where the paper has “standing at the end points.” Trivial — and a quotation that degrades one small increment per hop is, unhelpfully for the copyists, the exact failure mode the paper is about.
The best short restatement is not in the paper at all. RFC 3234, the IETF’s middlebox taxonomy, keeps the caveat and adds the qualifier the original only implies. The end-to-end principle, it says,
notes that providing an incomplete version of such functions in the network itself can sometimes be useful as a performance enhancement, but not as a substitute for the end-to-end implementation of the function.
Useful as a performance enhancement, but not as a substitute. Pin that sentence above a service boundary and most of the arguments about where validation belongs answer themselves. Note the irony in the same file: RFC 3234 says “principle” six times, and its bibliography cites a paper titled End-To-End Arguments in System Design.
One attribution to get right, because it is routinely garbled. RFC 3439 — the one containing a section called “Layering Considered Harmful” — is not an IAB document. Its header names R. Bush and D. Meyer, carries the line Updates: 1958, is dated December 2002, and is categorised Informational: an individual submission extending an IAB document. RFC 1958 is the IAB one. In an argument about reading claims carefully, the attribution has to survive the same scrutiny as everything else.
The strongest evidence for the argument is that TCP and IP are two protocols
The stack’s own history contains the cleanest available case study, and it is not the one usually told.
TCP and IP began as one thing. RFC 675, December 1974, is Specification of Internet Transmission Control Program — the last word is Program, not Protocol, and there is one of it. The split is proposed in writing on 15 August 1977, in Jon Postel’s IEN 2, which opens its discussion section without any diplomacy at all:
We are screwing up in our design of internet protocols by violating the principle of layering. Specifically we are trying to use TCP to do two things: serve as a host level end to end protocol, and to serve as an internet packaging and routing protocol. These two things should be provided in a layered and modular way. I suggest that a new distinct internetwork protocol is needed, and that TCP be used strictly as a host level end to end protocol.
Ten months later the two-protocol design exists in specifications: the RFC Editor’s IEN index lists IEN 40, Specification of Internetwork Transmission Control Protocol – Version 4, and IEN 41, Internetwork Protocol Specification – Version 4, both Postel, both June 1978. That “Version 4” is the lineage that becomes IPv4.
Here is the part the layering story usually omits. Postel’s stated reason is layering, but the reason recorded by the architect is a workload. David Clark’s 1988 SIGCOMM paper The Design Philosophy of the DARPA Internet Protocols names two concrete services TCP could not carry. One was XNET, the cross-Internet debugger: “First, a debugger protocol should not be reliable,” Clark writes, because “under conditions of stress or failure (which may be exactly when a debugger is needed) asking for reliable communications may prevent any communications at all.” The other was packetized speech, where a retransmission arrives too late to be worth anything and the missing speech “can simply be replaced by a short period of silence.”
This goal caused TCP and IP, which originally had been a single protocol in the architecture, to be separated into two layers. TCP provided one particular type of service, the reliable sequenced data stream, while IP attempted to provide a basic building block out of which a variety of types of service could be built.
Now put the two documents side by side. Clark is a co-author of the 1981 end-to-end paper, and that paper’s section “Identifying the ends” works through packet voice as its own hardest case, reaching the same conclusion:
It is better to accept slightly damaged packets as they are, or even to replace them with silence, a duplicate of the previous packet, or a noise burst.
The same worked example, by the same person, appears once as an argument about where a function belongs and once as the recorded reason the architecture is shaped the way it is.
The payoff arrived on a timescale nobody could have planned for. Splitting IP out from TCP made UDP possible, and UDP made QUIC possible: RFC 9000, May 2021, states that “QUIC packets are carried in UDP datagrams [UDP] to better facilitate deployment in existing systems and networks.” A boundary drawn in 1977 to serve a debugger and a telephone was still paying out forty-four years later. (Why QUIC needed that escape hatch is a separate story about middleboxes, and belongs to its own article.)
What transfers
None of this requires a network. Four transfers, in rough order of how often they bite.
Run the completeness test at every service boundary
The question is never “is this layer allowed to be smart.” It is: can this function be completed correctly here, with only the information available here? A payment service that trusts an upstream gateway’s already_validated flag has answered no by accident — the amount, the currency and the idempotency key are facts only the payment service holds, and no gateway can validate them on its behalf. The flag is a performance enhancement pretending to be a substitute, which is exactly the line RFC 3234 draws.
Idempotency is the end-to-end argument with the serial numbers filed off
The paper reaches the conclusion directly, in the language of 1981:
if the application level has to have a duplicate-suppressing mechanism anyway, that mechanism can also suppress any duplicates generated inside the communication network, so the function can be omitted from that lower level
Substitute message queue for communication network and it is the standard argument for idempotency keys. You cannot buy exactly-once delivery from an intermediary, because the duplicate that matters is the one a user creates by refreshing a page that seemed to hang — and the paper uses precisely that example, a “remote system user, puzzled by lack of response,” initiating a second login. The queue’s at-least-once guarantee is worth having. It is not worth trusting.
A helpful guarantee from below is a claim you still have to check
The MIT gateway is the pattern, not an anecdote. Every per-hop checksum passed; the corruption happened in the gap between checks, where no check was specified. The modern shapes are familiar: a schema validated at the API edge and mutated by a service behind it; a database constraint that holds for writes through the ORM and not for the batch job; a TLS-terminating load balancer that makes everything downstream “internal traffic.” Ask what the guarantee actually covers, then ask what happens in the space between two of them. That space is where your data spends most of its life.
Optimise below, but never delete the check above
Caches, CDN edges, read replicas, retry-with-backoff at an intermediate hop — all legitimate, all licensed by the parenthesis, and all conditional on the end-to-end check surviving. The client still has to detect a stale read. The consumer still has to tolerate a redelivery. Delete the end check because the optimisation usually works and you have built exactly the system the paper warns about: one whose correctness depends on a component that was never designed to provide it.
Where the argument runs out
It is not a law, and the authors did not present it as one. Their conclusion calls end-to-end arguments a kind of Occam’s razor for choosing what a communication subsystem should provide, and their complaint about layering is that it lacks criteria rather than that it is wrong:
It is fashionable these days to talk about “layered” communication protocols, but without clearly defined criteria for assigning functions to layers.
Identifying “the ends” is a judgement call too, and the paper says as much: applying the argument, it notes, sometimes requires subtle analysis of what the application actually requires. In a distributed system the ends move depending on which function you are asking about. For a payment they are the client and the ledger. For a personalisation cache they might be the CDN and the browser.
And the architecture drifted. RFC 3234’s diagnosis of middleboxes — “Instead of concentrating diversity and function at the end systems, they spread diversity and function throughout the network” — is the argument running in reverse, at scale, in deployed hardware. RFC 3439 offers the most useful patch: the network core is allowed state, but that state should be “almost orthogonal to the state maintained by the end-points.” Orthogonality is a better test than emptiness, and it is the one that survives translation to a service mesh, a proxy tier, or a platform team’s shared library.
All of which is worth an engineer’s afternoon for the same reason the wider story of how TCP/IP beat its rivals is: the decisions that lasted were rarely the ones that looked decisive at the time. A boundary drawn in 1977 for a debugger is still earning. Hold your own boundaries to that standard.
❓ Frequently Asked Questions
Is it the “end-to-end argument” or the “end-to-end principle”? Both are in wide use; only one is the authors’. The phrase “end-to-end principle” appears zero times in Saltzer, Reed and Clark, while “end-to-end argument” appears twenty-eight times. The IETF adopted “principle” — RFC 3234 uses it six times against one “argument” — so the word is not wrong, just later. The distinction is practical: an argument has premises you check against your situation, and a principle is something you obey or violate.
Does it say the network should be dumb? No, and the word is not in the paper. It says a function requiring knowledge held only at the end points cannot be completely and correctly implemented anywhere else, and that an incomplete lower-layer version “may be useful as a performance enhancement.” The paper devotes a section titled “Performance aspects” to when that is worth doing.
Where do I read the original? J.H. Saltzer’s MIT page hosts the full text free, in both PDF and plain text. It is about six thousand words — shorter than most blog posts summarising it, and the front matter settles the citation questions.
How is this different from “push logic to the edges” or a thin-client argument? Those are conclusions about topology; the end-to-end argument is a test about information. It fires only when correctness depends on knowledge the lower layer does not have. Where the lower layer does have that knowledge, it says nothing at all — plenty of function belongs downstairs, and this test is simply not the reason.
What does it mean for microservices specifically? That a guarantee from an upstream service is an optimisation, not a substitute. If service B cannot verify a fact with the information B holds, B is not entitled to assume it, whatever A’s response says. Idempotency keys, request-level validation and end-to-end checksums keep reappearing in mature systems because they are the checks that could not be delegated.
Was the TCP/IP split actually an application of the argument? Partly, and the two records differ in an interesting way. Postel’s IEN 2 (15 August 1977) makes the case in layering terms outright. Clark’s 1988 paper gives the engineering motive: TCP’s reliable byte stream could not serve a cross-net debugger or packetized speech, so the architecture needed a plain datagram building block underneath. Both are first-hand, and the second is the one usually missing.
📚 Recommended Resources
Disclosure: some links below are Amazon affiliate links. If you buy through them, this site earns a small commission at no extra cost to you.
For this particular argument the free primary material is not a consolation prize — it is better than every book written about it. Everything quoted in this article came from four documents that are free, permanent, and shorter than most of the blog posts summarising them.
Read the paper itself. It is about six thousand words. End-to-End Arguments in System Design is hosted by J.H. Saltzer on his own MIT page, in plain text as well as PDF. Read the abstract, then jump straight to “Performance aspects” — the section the retellings drop — and then “Identifying the ends,” which is where the authors admit the hard part. The sections on encryption key management, tape backup and RISC take another ten minutes and are what make it a systems paper rather than a networking one.
Then read Clark on why the architecture came out the way it did. The Design Philosophy of the DARPA Internet Protocols (SIGCOMM 1988) is the first-hand account of the goals, in priority order, and it is the document that explains the TCP/IP split as a service-type problem rather than a tidiness problem. Read it directly after the end-to-end paper; Clark wrote both, seven years apart, and the second one shows the first one being spent.
Two RFCs, for how the idea aged. RFC 1958 (IAB, June 1996) is eight pages and its reference list contains exactly two papers — the two above. RFC 3234 (February 2002) contains the best one-sentence statement of the rule anywhere, sharper than the original: useful as a performance enhancement, but not as a substitute. If you want the dissent, RFC 3439 has a section titled “Layering Considered Harmful,” written by two network operators rather than by the IAB.
And one 1977 memo, for the pleasure of it. IEN 2 is Jon Postel proposing the TCP/IP split in language no modern design document would survive. Two pages.
Books, if you want the long form
- TCP/IP Illustrated, Volume 1: The Protocols, 2nd edition — Kevin R. Fall and W. Richard Stevens, Addison-Wesley. Not a book about design philosophy, and that is why it pairs well with one: it shows you the bytes that the philosophical arguments were actually about, which is the fastest cure for arguing about layers in the abstract.
- Designing Data-Intensive Applications, 2nd edition — Martin Kleppmann and Chris Riccomini, O’Reilly, March 2026. The closest thing to a modern restatement of this article’s transfer section: its chapters on reliability, idempotence and exactly-once semantics reach the same conclusion from distributed-systems first principles rather than from a 1981 networking paper.
- Patterns in Network Architecture: A Return to Fundamentals — John Day, Prentice Hall. The most sustained published argument that the layer models are wrong in ways that matter, written by someone who worked on OSI. Contrarian, occasionally infuriating, and the only book here whose subject is the modelling question itself.