Everything Is
a Protocol

Every functioning system is a stack of agreements about what the layer below is allowed to assume. Change one of those agreements and the thing above it breaks in ways nobody predicted, which is why protocols outlive the companies that wrote them and why the internet still runs on decisions made by a few dozen people in the 1970s. A protocol is not a technology. It is a treaty that happens to be executable.

The word carries an unhelpful smell of specification documents, and it is worth reclaiming. A protocol is what makes two parties who do not trust each other, do not share a codebase, and have never met able to accomplish something together. It is the minimum shared vocabulary. Everything interesting about network architecture is a fight over where that minimum should sit, and who is allowed to look at what passes through.

The founding trick of the internet is layering, and the trick works because each layer is deliberately ignorant of the one above. Ethernet moves frames between machines on a wire and does not know what an IP packet is. IP moves packets between machines anywhere and does not know what a connection is. TCP builds a reliable ordered byte stream on top of an unreliable packet service and does not know whether those bytes are a photograph or a password. HTTP arranges those bytes into requests and responses and does not care how they arrived.

Ignorance is the feature. Because IP does not know about TCP, you can invent a different transport — QUIC, say — without asking anyone's permission or replacing a single router. Because TCP does not know about HTTP, you can redesign the web without touching the transport. Each layer is a substitution point. The whole system is upgradeable precisely to the degree that its layers refuse to peek.

This is why layer violations are treated as something close to a moral failing by people who have had to maintain networks. Every time a layer starts depending on details of the one above, a substitution point closes. The system gets slightly faster and permanently harder to change, and the cost arrives years later, paid by someone else.

In 1981 Saltzer, Reed and Clark wrote down the principle that shaped everything after it. The argument is narrow and its consequences are not. Their observation, in plain terms: if a job depends on understanding what the application is trying to do, the only place it can be finished properly is at the two ends. Doing it in the middle as well does not make it correct — the ends still have to check — so the middle version is at best an optimisation.

Take reliability. A router can retransmit a lost packet, but it cannot know whether your file arrived intact, because the file only exists as a concept at the ends. The endpoints must verify regardless. So the network does not need to guarantee delivery; it needs to be good enough that the endpoints' verification rarely fails. The middle can stay simple and fast, and gets to be simple and fast because the intelligence lives at the edges.

What that principle bought us was permissionless innovation. If the network's job is only to move packets, then anyone with an idea can build on top of it without asking a carrier for support. The web, email, streaming video, encrypted messaging, cryptocurrencies, and every protocol nobody has invented yet exist in the space that a deliberately unopinionated middle leaves open. The dumb pipe was not a limitation. It was the whole point.

> rfc // principle :: end-to-end

Only the endpoints know what the application actually needs. The middle can guess. It cannot know.

The end-to-end argument, summarised — after Saltzer, Reed & Clark, 1981

It did not stay dumb. Address exhaustion produced NAT, which meant a box in the middle now had to understand connections in order to rewrite them. Security produced firewalls, which meant a box in the middle now had to have views about which ports were acceptable. Performance produced caches and CDNs and transparent proxies, which meant a box in the middle now terminated your connection and made a second one on your behalf. Policy produced DPI — deep packet inspection — which meant a box in the middle read the application layer on purpose, to decide whether your traffic was permitted at all.

Each of these solved a genuine problem, and each closed a substitution point. The accumulated result is what engineers call ossification: the network's middle now depends on so many details of what flows through it that changing those details breaks connectivity in the field. This is not theoretical. It is why new transport protocols get quietly dropped by equipment that has never heard of them, and why QUIC was built on top of UDP rather than as a peer to TCP — not because that was elegant, but because UDP was one of the few things the middle would still pass without reading.

Notice the shape of the failure. A protocol designer today does not ask what is correct. They ask what will survive contact with several million middleboxes owned by people they will never speak to, running firmware that will never be updated. Architecture became archaeology.

The endpoints answered the only way the model allows: by making the middle unable to see. This is the part usually filed under security and it is at least as much a structural move. TLS hid the content. QUIC went further and encrypted most of the transport header itself — sequence numbers, connection state, the machinery a middlebox would need to have opinions about — specifically so that the middle could not come to depend on it again. Encrypted Client Hello aims at the last field still travelling in the clear, the server name in the handshake.

Read that as a fight over the envelope rather than the letter. Encryption of content was never seriously contested as a design goal. Encryption of structure is, because structure is what everyone in the middle was using: network operators for troubleshooting and traffic engineering, enterprises for policy enforcement, states for filtering, advertisers for classification. Every one of those parties has a real argument. Every one of those arguments requires the network to stay legible in a way the end-to-end principle says it does not need to be.

There is no clean resolution available, because it is not really a technical disagreement. It is a question about who the network belongs to, being litigated in header formats. The endpoints have the stronger hand — they can always encrypt more — and the middle has the stronger position, because it can simply drop what it cannot read. Both sides escalate. Traffic becomes more uniform, filtering becomes more statistical, and the arms race continues one layer down.

What survives this is worth naming. Protocols that lasted were not the most capable ones; they were the ones that demanded the least agreement. IP asks almost nothing of the networks beneath it and offers almost nothing to the layers above — no reliability, no ordering, no guarantees at all — and that poverty is exactly why it absorbed every underlying technology from telephone lines to fibre to radio without being redesigned. Protocols that asked for more, and there were many, are footnotes.

The same rule shows up everywhere once you look for it. Interfaces that assume less outlive the systems built on them. Formats that specify less get read by more tools. Institutions that require less agreement hold together across more disagreement. In every case, the thing that lasts is not the one with the most opinions but the one that left the most room for someone else to have theirs.

Which is the argument for keeping the middle dumb, restated without the packets. A protocol is a truce about how little we have to agree on in order to get something done. Every additional assumption is a party who now has to be consulted before anything can change. The internet worked because its founding treaty asked for almost nothing — and most of its subsequent history is the story of everyone trying to renegotiate it.