The founding document is titled “SPECIFICATION OF INTERNET TRANSMISSION CONTROL PROGRAM.” Not protocol. Program, singular — RFC 675, December 1974, Cerf, Dalal and Sunshine. TCP and IP were one design, split apart later, and even the winner’s name in the TCP/IP protocol wars was not settled in the right order: RFC 801 (1981) and RFC 896 (1984) both write it IP/TCP.
That is small, and it is a useful calibration. The story most engineers absorbed — elegant, minimal TCP/IP defeats bloated, committee-designed OSI — was assembled after the fact by the side that won, and the primary record does not support it. The losers were not obviously worse. Several were better than TCP/IP at the job they were built for, and one was the officially mandated purchasing standard of the United States federal government at the moment it lost.
What decided it was adoption, deployment cost, licensing, timing and who had shipping code. Those mechanisms have almost nothing to do with protocol design, and they are running live right now in competing blockchains and competing AI agent standards.
Eight Rivals, and Not One of Them Was a Toy
OSI was not one thing, and conflating its halves is the commonest error in the subject. There is a reference model — the seven layers, published by ISO as ISO 7498 and by CCITT as Recommendation X.200 — and a family of shipping protocols: CLNP (ISO 8473, transcribed as RFC 994, March 1986) as a peer to IP, and TP4, which is not a document but Transport Class 4 of ISO 8073, one of five classes, transcribed as RFC 905 in April 1984 — the class built to run over a connectionless network service, which is the same architectural split TCP/IP has. X.400 handled messaging (1984), X.500 the directory (1988). Even the reference model’s publication date is inconsistent: Andrew Russell’s IEEE Spectrum retrospective gives May 1983 in its timeline and 1984 in its body text. What is checkable first-hand is that ITU-T Recommendation X.200 (07/94) was still listed In force, and freely downloadable, on 7 September 2026.
X.25 was a working global network, approved by CCITT in September 1976: virtual circuits, with hop-by-hop error correction in its LAPB link layer because the copper underneath was noisy. PTTs ran real public data networks on it — Transpac, PSS, Datapac, Telenet, Tymnet — and RFC 877 (1983), superseded by RFC 1356 (1992), was the Internet’s bridge onto them. When digital circuits made hop-by-hop correction pointless, X.25’s own lineage produced Frame Relay: same virtual circuits, error correction dropped.
AppleTalk is the strongest “the loser was better at something” case here. Released in 1985, it shipped zero-configuration networking a generation early: AARP let a machine probe on power-up and claim a free address with no server, and NBP mapped those addresses to human-readable names. The IETF took until 2013 to standardise the same experience over IP, and RFC 6760 says so in writing — mDNS (RFC 6762) and DNS-SD (RFC 6763), by Apple’s Stuart Cheshire and Marc Krochmal, exist to retire AppleTalk’s Name Binding Protocol.
The rest each optimised hard for a real constraint. Novell’s IPX/SPX, adapted from Xerox XNS, held 53% of the network-operating-system market on IDC’s 1988 measurement. NetBIOS is Sytek’s 1983 session-and-naming API; NetBEUI is IBM’s separate 1985 Token-Ring product, whose wire protocol NBF has no network-layer header at all. DECnet Phase IV (1982) fixed 64,449 nodes into the protocol, and DEC’s own Easynet passed 17,000 by December 1988 — which is why Phase V (1987) rebuilt the network layer on CLNP. IBM’s SNA (September 1974) put a mainframe at the centre, rational when System/370 inherited a limit of 16 I/O channels and every line counted as a peripheral. ATM built one fabric for voice, video and data from fixed 53-byte cells, won the carrier core, and lost the desktop to Gigabit Ethernet.
| Contender | What it actually was | Where it won | Why it could never have become the internet |
|---|---|---|---|
| OSI (CLNP, TP4, X.400, X.500) | An international standard plus real shipping protocols | Government and telecom procurement, late 1980s–90s | Optionality: the spec admitted both the connectionless and connection-oriented designs, so conformance did not imply interoperability |
| X.25 | Carrier-operated virtual circuits, worldwide | Public data networks, 1976–1990s | X.121 addressing was carrier-assigned; built for a network one operator runs end to end |
| IPX/SPX | Connectionless network + reliable transport, from XNS | ~53% of the NOS market (IDC, 1988) | Network numbers assume one administrative domain hands them out |
| AppleTalk | Connectionless DDP, zero-configuration addressing and naming | Mac and small-office LANs, 1985–late 1990s | Self-assignment needs no central authority — precisely why it cannot coordinate globally |
| NetBIOS / NetBEUI (NBF) | A 1983 API; a 1985 wire protocol with no network layer | Workgroup LANs | Structurally unroutable: bridging works, routing does not |
| DECnet | Eight-layer vendor stack; Phase V rebuilt on CLNP | VAX/VMS shops; Easynet at 17,000+ nodes | A 16-bit address space with a 64,449-node ceiling inside the protocol |
| SNA | Hierarchical, session-oriented, VTAM at the centre | IBM mainframe shops | Addressing and path selection assumed one organisation owned every node |
| ATM | Fixed 53-byte cells for one converged fabric | Carrier cores, SONET/SDH, DSL access | Carrier-assigned NSAP addressing, and a cell tax the LAN refused to pay |
Each won the deployment it was designed for and lost the one nobody had specified yet: permissionless internetworking, across organisations, with no single owner.
In 1985 the Pentagon’s Own Advisers Told It to Switch to OSI
If you read one document from this subject, read RFC 942.
In February 1985 the National Research Council’s Committee on Computer-Computer Communication Protocols reported to the Department of Defense and the National Bureau of Standards on Transport Protocols for Department of Defense Data Networks — a head-to-head study of DoD’s own TCP/IP against ISO’s TP-4 and ISO-IP. It was republished verbatim as RFC 942, so it is free plain text today.
“The committee unanimously recommends that DOD should adopt the ISO TP-4 (and IP) as DOD costandards with its TCP (and IP) and move toward eventual exclusive use of TP-4.”
“It believes the two protocols are sufficiently similar and no significant differences in performance are to be expected if the chosen protocol implementation is of equal quality and is optimized for the given environment.”
That puts the technical-merit explanation in serious trouble. The most authoritative contemporary comparison — unanimous, commissioned by TCP/IP’s own sponsor — found the two functionally equivalent. Any claim that TCP/IP won on protocol design has to deal with this document rather than route around it.
And in 1985 the availability argument pointed at OSI. The committee’s stated motive was commercial products: “The primary motivation for recommending Option 1 is to obtain the benefits of standard commercial products in the communication protocol area at an early date,” with estimated savings of “30 to 80 percent.” The now-standard story — TCP/IP won because it was the one you could actually get — was believed by expert advisers, at the decision point, to run the other way. That they were wrong about the future is the finding; they were not foolish.
They also hedged in exactly the place that mattered. The committee’s split turned on “differences within the committee on the extent of the risk associated with adopting a protocol, TP-4, that has not been implemented on operational networks” — the running-code argument, made in 1985 by people recommending the protocol without the running code, as a risk to manage rather than a reason to decide.
Russell records that the Defense Department went on to embrace the report’s conclusions; that sequel is his secondary claim and is not verified here against a DoD document.
The Mandate Did Not Bite
The United States government made OSI a federal purchasing requirement, and OSI lost inside the government’s own procurement. The document explaining why is RFC 1169, Explaining the Role of GOSIP, by V. Cerf of the IAB and K. Mills of NIST, August 1990 — written after coordination with the Federal Networking Council, in the month the requirement took effect.
What it required:
“Beginning in August, 1990, federal agencies procuring computer network products and services must require that those products and services comply with OSI, where feasible, as specified in GOSIP Version 1.0.”
What the same document says about its own force:
“FIPS 146 is a procurement specification. … GOSIP does not mandate an immediate, total transition to OSI in August 1990.”
“GOSIP is not exclusive.”
“NIST does not have an enforcement responsibility with respect to GOSIP.”
Waivers existed, and the authority to grant them was delegated to the heads of agencies. So the “officially mandated stack” was a purchasing profile: non-exclusive, conditional on feasibility, waivable by the buyer’s own leadership, unenforced.
Write it as the mandate did not bite, not as the mandate was defied. That distinction is the mechanism. Nobody rebelled; the rule was drafted soft, and softness is what let the installed base walk through it. What makes this the strongest single fact in the story is not defiance — it is that Vint Cerf co-authored the document showing the rule to be toothless, in the month it commenced, in a paper whose stated purpose was to support OSI integration.
The rest of RFC 1169 is more remarkable still. In August 1990 the IAB wrote down, in advance, why the thing would not work:
“The large existing installed base of TCP/IP protocol users, the limited deployment of commercial OSI products, and the incomplete development of OSI standards for routing, network management, and directory services combine to make an immediate, total transition to a pure OSI environment in the Internet unrealistic.”
Installed base, product availability, specification gaps — three of the six candidate explanations for the whole outcome, named by the winners’ own standards body, five years before the mandate was unwound.
| Date | What happened | Documented in |
|---|---|---|
| Jan 1987 | GOSIP comment period opens | RFC 1169 |
| Aug 1988 | GOSIP version 1 published | RFC 1169 |
| Feb 1989 | Adopted as FIPS 146 | RFC 1169 |
| Aug 1990 | Becomes a federal procurement requirement | RFC 1169 |
| May 1994 | FIRP: “no single networking protocol suite meets the full range of government requirements” | 59 FR, 4 Aug 1994, Doc. 94-19065 |
| Sept 1994 | NIST proposes removing the requirement; renames the FIPS to POSIT | 59 FR 47119–47121, Doc. 94-22685 |
| May 1995 | FIPS 146-2 (POSIT) approved — the requirement is gone | 60 FR 25888–25890, 15 May 1995, Doc. 95-11917 |
| Nov 1998 | FIPS 146-2 withdrawn entirely | 63 FR 64062–64063, 18 Nov 1998, Doc. 98-30796 |
The Federal Internetworking Requirements Panel, convened by NIST at the request of the Office of Management and Budget, reported in May 1994 that “The Panel concluded that no single networking protocol suite meets the full range of government requirements for data internetworking.” The proposal that followed removes “the requirement that Federal agencies specify the Government Open Systems Interconnection Profile (GOSIP) protocols,” names the IETF as a peer of ISO and ITU, and downgrades must to “strongly encouraged.” Binding life of the mandate: four years and nine months. Europe’s counterpart, Council Decision 87/95/EEC (22 December 1986), is softer still — it obliges member states only to make reference to accepted standards, names OSI in the recital rather than the operative requirement, and lists four grounds for departure.
This proves something narrower and more useful than “mandates don’t work.” A procurement mandate is a demand-side instrument and cannot manufacture a supply side. GOSIP required agencies to buy OSI where feasible, and the IAB’s assessment that same month was that the routing, management and directory standards did not yet exist. The mandate was, by its own terms, conditional on a market it was meant to create.
By the Time the Rule Arrived, There Were 313,000 Hosts
RFC 1296, Internet Growth (1981–1991), Mark Lottor of SRI International, January 1992, is a primary count from host tables and DNS walks.
| Date | Internet hosts |
|---|---|
| 08/81 | 213 |
| 11/86 | 5,089 |
| 12/87 | 28,174 |
| 01/89 | 80,000 |
| 10/90 | 313,000 |
| 01/92 | 727,000 |
GOSIP became a procurement requirement in August 1990. Two months later there were 313,000 TCP/IP hosts, sixty-one times the count four years earlier. Lottor’s own caveats are in the RFC — incomplete zone data before roughly 1988 — so these are good-faith counts with a known undercount bias rather than a census. The magnitude is the point, and it is not in doubt.
NSF supplies the other half: NSFNET, launched in 1986 to connect researchers to the new supercomputer centres, became the de facto US backbone, “connecting around 2,000 computers in 1986 and expanding to more than 2 million by 1993” (NSF, published 10 May 2024, updated 24 June 2026). Read that causal claim carefully. NSFNET was a TCP/IP network from the start and inherited a decision already made, by DARPA’s 1983 cutover and by what already ran on the machines universities had bought. It scaled the outcome; it did not choose it. Meanwhile the Internet barred commercial traffic from its subsidised backbone until 1992, which is why Russell can say that for businesses exchanging data between different kinds of computers, “OSI was the only game in town.” Both were true at once, for most of a decade.
Already on the Machine You Had Bought for Another Reason
Marshall Kirk McKusick’s Twenty Years of Berkeley Unix, an insider account from the Computer Systems Research Group, gives the distribution chain with dates. DARPA funded Bob Fabry’s group from April 1980. Rob Gurwitz at BBN released an early TCP/IP implementation to Berkeley; Bill Joy integrated and tuned it. It shipped roughly as 4.1a in April 1982 and properly as 4.2BSD in August 1983.
“The popularity of 4.2BSD was impressive; within eighteen months more than 1,000 site licenses had been issued.”
“Most of the Unix vendors shipped a 4.2BSD system rather than the commercial System V from AT&T. The reason was that System V had neither networking nor the Berkley Fast filesystem.”
Read that second sentence for what it means. In 1983–85, choosing BSD over System V was a decision about networking and a filesystem — and TCP/IP arrived as an unpriced side effect of a choice nobody framed as a protocol decision. That is how a protocol suite propagates without being selected, and the nine principals who wrote the Internet Society’s Brief History of the Internet reach the same verdict about their own project: incorporating the protocols into a supported operating system for the research community “was one of the key elements in the successful widespread adoption of the Internet.”
Now the correction, because “free and open source” is anachronistic for exactly the years that decided it. McKusick, flatly: “Up through the release of 4.3BSD-Tahoe, all recipients of BSD had to first get an AT&T source license.” 4.3BSD-Tahoe was June 1988. The networking code became independently redistributable only when CSRG carved it out — “The BSD originated networking code and supporting utilities were released in June 1989 as Networking Release 1, the first freely-redistributable code from Berkeley.”
So through 1983–1988, precisely when the installed base ran away from OSI, BSD’s TCP/IP was cheap, ubiquitous in academia and bundled — and still gated behind an AT&T source licence. The free-cost argument that survives is a different one: the specifications were free. RFCs were, and remain, plain text anyone can read without paying or asking; ISO’s documents were not. Keep those two claims apart or the argument collapses on a date check. (And since both overstatements circulate: Berkeley’s code was an adjudicated rewrite of a BBN prototype, evaluated against BBN’s own version by Mike Muuss for DARPA in 1985. Berkeley neither wrote TCP/IP from nothing nor shipped BBN’s code.)
Twelve Months, on a Runway Three Years Long
The transition’s arithmetic gets mangled in almost every retelling, in both directions.
The mandate is twelve months. RFC 801, NCP/TCP Transition Plan, Jon Postel, ISI, November 1981, in its “General Plan”:
“The goal is to make a complete switch over from the NCP to IP/TCP by 1 January 1983. It is the task of each host organization to implement IP/TCP for its own hosts. This implementation task must begin by 1 January 1982.”
Begin 1 January 1982, complete 1 January 1983 — a twelve-month countdown, published six weeks before the clock started.
The runway underneath it is three years and more. DoD had already adopted TCP/IP as a defense standard in RFC 760, “DOD STANDARD INTERNET PROTOCOL,” January 1980. RFC 801’s own milestone table marks “First Internet Service” and “First TCP-only Host” as already achieved in November 1981, so parts of the transition were running before the RFC existed. And the participants’ history says the cutover “was carefully planned within the community over several years before it actually took place.”
Both are true, and they must not be merged into one number. A hard one-year mandate on a three-plus-year runway is a different object from either “a two-year plan” or “an overnight switch.”
Nor is “flag day” a populariser’s exaggeration a careful writer should correct — it comes from the participants. A Brief History of the Internet (Leiner, Cerf, Clark, Kahn, Kleinrock, Lynch, Postel, Roberts and Wolff, 1997) calls it “a ‘flag-day’ style transition” that “went surprisingly smoothly (but resulted in a distribution of buttons saying ‘I survived the TCP/IP transition’).” A long runway ending in a hard cutover; do not set the two framings against each other.
Then weigh what it took: one operator, one network, a protocol both sides had already agreed on, years of notice, and a year of dual-protocol running with relay gateways between NCP-only and TCP-only hosts. That is the smallest, most cooperative migration in this story. Multiply the friction by many operators, many vendors and no pre-agreement, and switching cost stops being an abstraction.
What Each Process Did With a Disagreement It Could Not Settle
The claim that the IETF’s process was faster is easy to assert and hard to make specific. The specific version has nothing to do with temperament.
The IETF deletes what nobody implemented twice. RFC 1310, The Internet Standards Process, Internet Activities Board, Lyman Chapin as chair, March 1992:
“A specification from which at least two independent and interoperable implementations have been developed, and for which adequate operational experience has been obtained, may be elevated to the ‘Draft Standard’ level.”
RFC 2026 (Bradner, BCP 9, October 1996) sharpened it into a weapon:
“In cases in which one or more options or features have not been demonstrated in at least two interoperable implementations, the specification may advance to the Draft Standard level only if those options or features are removed.”
OSI absorbed the disagreement as an option instead. When the datagram camp and the virtual-circuit camp could not agree, Russell’s account is that “Instead of resolving the dispute, they agreed to include options for both designs within OSI, thus increasing its size and complexity.” RFC 1169 confirms the consequence from the other side of the war, and it is why GOSIP had to exist at all: “GOSIP is needed because OSI standards allow many potential options and choices, some of which are incompatible.”
That is a mechanism you can point at rather than a culture you have to assert. Two bodies met an unresolvable disagreement and responded in opposite ways: one absorbed it, one deleted it. Neither is obviously correct — deleting options destroys real capability, and absorbing them is how a specification survives a political conflict. But absorbing them is also how a specification stops producing interoperable products, and interoperability was the entire proposition.
Report the institutional difference without the sneer. RFC 3935 states the IETF’s principle as “any interested person can participate in the work”; ISO and CCITT ran on national delegations through a four-stage ballot. OSI’s model was built to produce standards governments and PTT monopolies could adopt, in a world where those were the buyers; the IETF’s, standards engineers could implement, in a world where engineers were. Both won the war they were designed for. Only one turned out to be the war that mattered.
The credo is from 1992, and it is about the IETF’s own crisis
“We reject: kings, presidents and voting. We believe in: rough consensus and running code” is David Clark, and it is July 1992, at the IETF meeting in Cambridge, Massachusetts — nine years after the ARPANET cutover and two years after GOSIP took effect. It is slide 19 of a 22-slide talk called A Cloudy Crystal Ball — Visions of the Future, alternate title “Apocalypse Now,” headed “The last force on us — us.” Its first two lines: “The standards elephant of yesterday — OSI. The standards elephant of today — it’s right here.”
RFC 1396 (Steve Crocker, January 1993) documents the context independently: after Kobe in June 1992 the IAB had proposed borrowing addressing ideas from CLNP, OSI’s network layer, and “These matters came to a head during the Internet Engineering Task Force (IETF) meeting in July in Cambridge, MA.” Russell describes the engineers present as having “howled in protest and then sacked their leaders for their heresy.”
So the most-quoted sentence in the subject was delivered during a governance revolt provoked by an attempt to adopt OSI technology, by a man warning that the IETF had itself become the new standards elephant. Cite it — dated, and for what it is. It cannot explain an outcome settled before it was said, and RFC 1310 had codified the running-code requirement four months earlier, which is the institutional fact the slogan later collected the credit for.
Where the Record Refuses to Resolve
Two things here are genuinely contested, and reporting the disagreement precisely is the finding. Contested is not the same as unknown.
Was the internet designed to survive a nuclear war? Three parties, three positions, nobody lying. Paul Baran’s RAND work is explicitly survivability research — RM-3420 (1964) opens “Let us consider the synthesis of a communication network which will allow several hundred major communications stations to talk with one another after an enemy attack.” The nine ARPANET principals deny it flatly of ARPANET, in footnote 5 of their own history: “This was never true of the ARPANET” — while conceding in the next sentence that “the later work on Internetting did emphasize robustness and survivability, including the capability to withstand losses of large portions of the underlying networks.” And RAND’s own page, the source with the greatest interest in the survivability story, describes ARPANET as “intended for scientists and researchers who wanted to share computers remotely.” The nearest thing to agreement: Baran was survivability, ARPANET was resource sharing, and the internetworking layer targeted robustness on the participants’ own admission. What is disputed is how much of the first flowed into the third. Donald Davies at NPL arrived at packet switching independently again; his own motivation is not established here from an NPL primary and should not be asserted.
And why did TCP/IP win? Six or seven mechanisms each have real evidence, each is insufficient alone, and they are not independent. DARPA funded Berkeley; Berkeley’s release built the base; the base is what NSFNET scaled; the scaled base is what the IAB cited in 1990 as making transition unrealistic; that unreality is what the FIRP ratified in 1994. One causal chain with five names in it, not five competing causes. What is genuinely disputed is narrower than it looks — how much weight to put on protocol design versus everything else — and on that question RFC 942 is close to decisive against design.
Two traps on the way out. The first is the tidy moral: “simpler won,” “worse is better,” “design by committee failed.” Even the simplicity claim is rejected from inside the IETF — RFC 3439 (Bush and Meyer, December 2002, an individual submission updating the IAB’s RFC 1958 rather than an IAB document itself) concludes “we find that packet switching is more complex than circuit switching.” The second trap is the inverted tidy moral — “actually OSI was fine and it was all politics” — which fails identically, by picking one mechanism and calling it the cause. The field’s leading historian publicly corrected his own tidy version: IEEE Spectrum’s Back Story to Russell’s 2013 piece records that his 2006 article had used OSI as “a foil,” and that John Day told him he had “got it wrong.”
OSI Lost the Transport War and Is Still in Your Certificate Chain
“OSI failed” and “OSI lost the transport war” are different claims, and only the second is true.
Two OSI artifacts are load-bearing in every HTTPS handshake, not one. X.509 — the certificate format your browser validates — is itself an X.500 artifact, defined within the 1988 Directory series. And it is encoded in ASN.1, which traces to CCITT X.409 (1984) and lives on as X.680–X.683 with encoding rules in X.690; RFC 5280 ships an ASN.1 module in its own appendices. A piece of 1984-vintage OSI machinery is parsed on every secure page load, wrapped in a format that came out of the directory standard OSI is supposed to have lost with.
The rest is equally traceable. X.500’s data model became LDAP (RFC 1487 in 1993; current specification RFC 4511, 2006). AppleTalk’s self-configuration is Bonjour’s, by the IETF’s written admission in RFC 6760. SNA’s SDLC became HDLC, under much of the WAN framing that followed. ATM lost the LAN and kept the carrier core, where it carried enormous volumes of the IP traffic that had beaten it, one layer down. And the seven-layer model remains the teaching vocabulary of the entire field.
None of these died the way a wrong answer dies. Each optimised correctly for a constraint that later stopped applying, and each left infrastructure behind when the stack around it lost its reason to exist.
The Prize for Winning Is That You Can No Longer Change It
IP occupies what architects call the narrow waist: the one universal layer everything above and below must agree on. Winning that position is the whole game — and a trap. Middleboxes, firewalls, NATs and traffic shapers spent decades learning to inspect and rewrite exactly the byte patterns TCP produces, so any change to TCP now risks breaking some fraction of a deployed population of boxes nobody owns. The protocol that won by being universally deployed became, through that same deployment, nearly impossible to change in place.
QUIC is the answer, and RFC 9000 (Iyengar of Fastly, Thomson of Mozilla, May 2021) states the motive in its own text: “QUIC packets are carried in UDP datagrams to better facilitate deployment in existing systems and networks.” That is TCP’s job rebuilt from scratch and moved through the network disguised as ordinary UDP, with almost everything else encrypted so the boxes in between cannot ossify it a second time. The most damning detail is the date: Google’s 2009 SPDY whitepaper had already evaluated SCTP and Structured Stream Transport and rejected both, because a new transport cannot traverse home routers — the problem named eight years before QUIC, as an argument not to act. Winning had closed the door by 2009.
The Same Play, Running Now
Open weights are 1989’s Networking Release 1. DeepSeek’s R1 model card lists its licence as MIT (checked 7 September 2026) — permissive, no royalty, redistribute and modify. Whatever is true about relative model quality in a given month, a model whose weights can be downloaded and passed on faces a different adoption curve from one behind a metered API, for exactly the reason 4.2BSD spread faster than any OSI product: the second adopter’s cost of trying it is near zero.
Governance handovers are running on a compressed clock. Anthropic open-sourced the Model Context Protocol on 25 November 2024 as a wholly Anthropic project, and donated it to the Agentic AI Foundation, a Linux Foundation directed fund co-founded with Block and OpenAI, on 9 December 2025 — about thirteen months from one company’s repository to neutral governance. Google announced Agent2Agent on 9 April 2025 with more than fifty partners; the Linux Foundation took it over on 23 June 2025, roughly ten weeks later. Set that against three years from a defense standard to a completed cutover, or seven from a federal mandate to its abandonment.
But do not force today’s landscape into yesterday’s shape. Three ways to get it wrong:
First, MCP and A2A are not rivals for one layer. Google’s own announcement calls A2A “an open protocol that complements Anthropic’s Model Context Protocol (MCP), which provides helpful tools and context to agents.” One connects an AI system to tools and data; the other connects agents to each other. The analogy is TCP and IP dividing transport from addressing, not TCP and TP4 competing for one job. Real competition there is more diffuse — overlapping interoperability efforts, and a de facto chat-completions API shape that vendors implement with no standards body ratifying it, which is itself running code setting the norm ahead of a committee.
Second, there may not be one narrow waist to win. The internet had exactly one universal layer, which is why losing the transport bid meant losing everything. The agent stack has several candidate waists operating at once, and nothing guarantees any consolidates.
Third, blockchain governance did not descend from the IETF, and the token changes the physics. Ethereum’s EIP-1 states its lineage: “This document was derived heavily from Bitcoin’s BIP-0001 written by Amir Taaki which in turn was derived from Python’s PEP-0001.” Two numbered-proposal traditions converged on the same shape without either copying the RFC process — evidence that the form works, not evidence of descent. And the genuine disanalogy: nothing in the TCP/IP-versus-OSI story had a speculatively traded asset attached to which protocol won. The seams still cost what seams always cost, though — Chainalysis counted $2 billion stolen across 13 cross-chain bridge hacks, 69% of all funds stolen that year to that point, as of 2 August 2022. That is a dated snapshot from one named tracker; re-pull it before quoting it as current.
The questions this history licenses you to ask
Not predictions. Diagnostics, each answerable today about a protocol you are being asked to adopt.
- Who has running code, not a roadmap? Ask to see two independent implementations interoperate — the IETF’s written promotion gate since March 1992.
- What does the second adopter pay to try it? Can someone outside the founding team download, modify and ship it without negotiating anything?
- Is it bundled with something people already buy for another reason? Free-as-in-bundled beat free-as-in-licence here by six years.
- What does the process do with a disagreement it cannot settle? Absorb it as an option, or delete it? That choice separates a specification that survives politics from one that produces interoperable products.
- What are the waiver clauses of the mandate you are betting on? Every feasibility clause is an implicit bet that a market will show up.
- If it wins its layer, what happens when it needs to change? TCP’s success is why QUIC had to arrive in disguise.
And the warning the record supports best: expert bodies are most confidently wrong about which ecosystem will have the products. The NRC committee got the protocol comparison right and the market forecast catastrophically wrong. Technical equivalence is knowable. Adoption is not.
The Whole Map: Fourteen Articles From Here
This is the reference article for the series. Fourteen shorter pieces take one idea each, listed as titles rather than links, because they publish over the following weeks and a link written today would point at nothing.
Start here if the stack is new to you: What TCP/IP Actually Is — what the suite is, why it is two protocols rather than the single thing RFC 675 described, and why you have never had to think about it.
Four on the mechanics. Why the TCP Handshake Takes Three Steps demolishes the claim, repeated almost everywhere, that the handshake solves the Two Generals Problem; it does not, nothing can, and RFC 793 says plainly what it does instead. Understanding TCP’s TIME-WAIT State covers the state practitioners hit in production and misdiagnose, whose two-minute MSL is unchanged from RFC 793 in 1981 to RFC 9293 in 2022. How TCP Congestion Control Works is the commons problem solved with no central authority, crediting the lineage rather than a hero — the 1988 paper is Van Jacobson and Michael J. Karels, and Nagle’s RFC 896 had proposed gateway enforcement four years earlier, never built. The End-to-End Argument is the most transferable piece here, written for an architect who will never touch a router, including the performance caveat that is in Saltzer, Reed and Clark’s original and almost always dropped when the argument is cited.
Two about measurement. Bufferbloat Explained shows how oversized buffers defeat loss-based congestion control by hiding the signal it needs — why a connection can measure fine and feel terrible. IPv6 Adoption Numbers is about why two excellent measurers disagree by roughly five points on the same week.
Two on the losers, taken seriously. The OSI Model vs TCP/IP answers the highest-volume question in the subject honestly: both models leak, RFC 1122 calls its own model “an imperfect model,” and neither has a comfortable place for TLS, a VPN or QUIC. What Happened to the OSI Model is the fuller obituary — X.25, IPX/SPX, DECnet, SNA, ATM, and what each left behind.
Two on what came next. QUIC and HTTP/3, the full account of the winner being routed around inside the network it won; and The 1983 TCP/IP Flag Day, the NCP cutover as a migration case study.
Two on security. TCP Sequence Number Attacks traces how a 1981 engineering convenience became a security requirement — RFC 793’s plain clock, Bellovin’s RFC 1948 in 1996, RFC 6528, then the keyed function in RFC 9293 — because threat models age. NAT, Security Myths and IPv6 holds that NAT violated the end-to-end principle, broke peer-to-peer, deployed itself with no coordination, worked, and removed most of the urgency behind IPv6, all at once — then asks whether address translation is access control.
And one reading ladder: The Best Books on TCP/IP and Networking, which leads with the free primary sources, because here they genuinely beat the books.
❓ Frequently Asked Questions
Did TCP/IP win because it was simpler than OSI? That is the popular answer and it is not settled. The strongest evidence against it is RFC 942: in February 1985 the National Research Council compared TCP/IP against ISO’s TP-4 and IP, found them functionally equivalent, and unanimously recommended DoD adopt TP-4. Complexity was a real cost, but licensing, timing, bundled distribution and procurement each explain part of the outcome and are not independent of each other. Even the general “simpler wins” reflex is rejected from inside the IETF, in RFC 3439.
Was the internet designed to survive a nuclear war? Paul Baran’s RAND work was, explicitly and in writing. ARPANET’s builders say flatly that this was never true of ARPANET — and concede in the same footnote that the later internetworking work did emphasise robustness and survivability. RAND’s own history page describes ARPANET as intended for researchers sharing computers remotely. Three research programmes, three motivations, one shared technique; what is disputed is how much of Baran’s flowed into the internetworking layer.
Did the US government really mandate OSI? Yes, and it is the most checkable fact in the story. GOSIP became a federal procurement requirement in August 1990 under FIPS 146. But RFC 1169 — Vint Cerf and Kevin Mills, that same month — records that it was a purchasing specification, that “GOSIP is not exclusive,” that waivers were delegated to the heads of agencies, and that “NIST does not have an enforcement responsibility with respect to GOSIP.” The requirement was removed by FIPS 146-2 in May 1995 and the standard withdrawn in November 1998. The mandate did not bite; it was not defied.
Where does “rough consensus and running code” actually come from? David Clark, July 1992, at the IETF meeting in Cambridge, Massachusetts — slide 19 of a talk titled A Cloudy Crystal Ball, delivered during a governance revolt provoked by the IAB’s proposal to borrow addressing ideas from OSI’s CLNP. That is nine years after the ARPANET cutover and two after GOSIP took effect: a retrospective self-description, not a founding credo, and it cannot explain an outcome it postdates. The institutional version is older and duller — RFC 1310 had required two independent interoperable implementations four months earlier.
Is the OSI model obsolete? Not in any sense that matters. ITU-T Recommendation X.200 was still listed in force in September 2026, the seven-layer model is the field’s teaching vocabulary, X.500 became LDAP, and X.509 certificates — themselves an X.500 artifact, encoded in OSI’s own ASN.1 — are validated by every browser on every secure connection.
Does any of this predict which blockchain or AI protocol wins? No. It gives you diagnostics instead: who has two interoperable implementations rather than a roadmap, what the second adopter pays to try it, whether it arrives bundled with something people already buy, and what happens when a protocol that has won its layer needs to change. It also gives you two disanalogies to respect — today’s competitions carry directly monetised tokens, which none of this history had, and the AI agent stack may never resolve into a single narrow waist at all.
📦 Recommended Resources
Disclosure: the book links below are Amazon affiliate links. If you buy through them, this site earns a small commission at no extra cost to you.
Start with the free primary sources, because on this subject they genuinely beat the books. Every RFC cited in this article is plain text, permanently archived, and costs nothing — which is itself one of the mechanisms the article is about. Read RFC 942 (the 1985 National Research Council report recommending DoD switch to TP-4) and RFC 1169 (Cerf and Mills explaining that GOSIP was not exclusive and NIST would not enforce it) back to back. That pair, in about an hour, will do more to correct the folk history than any secondary account. Then RFC 675 for the “Transmission Control Program” title, RFC 801 for the transition arithmetic, RFC 1296 for the host counts, and RFC 2026 §4.1.2 for the rule that deletes unimplemented options. For the modern half, RFC 9293 is what a conformant TCP does today and RFC 9000 is QUIC in its own words.
The books below are for the layer underneath — the protocol mechanics the history keeps gesturing at, and the network-effects reasoning that explains why a technically equal contender still loses.
- TCP/IP Illustrated, Volume 1: The Protocols (2nd edition) by Kevin Fall and W. Richard Stevens (Addison-Wesley, 2011) — the packet-level reference, substantially rewritten from the 1994 original to cover IPv6, modern congestion control and current TCP behaviour. Buy this one if the history left you wanting to see what the winning protocol actually puts on the wire, rather than what committees said about it. Note that the first edition is a materially different book; the second is the one to get.
- Computer Networking: A Top-Down Approach by James Kurose and Keith Ross (Pearson) — the standard university text, and the reason the seven-layer vocabulary survives even in courses that teach the four-layer stack. Useful here precisely because it shows how thoroughly OSI won the pedagogy while losing the transport layer, which is one of this article’s stranger claims until you see it in practice.
- High Performance Browser Networking by Ilya Grigorik (O’Reilly) — the practical companion to the ossification argument. It covers what TCP’s decades of deployment actually cost you in latency terms, and why so much engineering effort has gone into working around a transport nobody can safely change. Grigorik has also kept the full text free to read online, so the print edition is a convenience rather than a gate.
For the historiography itself, two books are worth naming even though no affiliate link accompanies them here. Andrew L. Russell, Open Standards and the Digital Age: History, Ideology, and Networks (Cambridge University Press, 2014) is the corrected scholarly account by the historian who publicly revised his own earlier, tidier version of this story. Janet Abbate, Inventing the Internet (MIT Press, 1999) remains the standard history of how the network was actually built. Both were bibliographically confirmed for this article; neither is linked, because no product listing was verified first-hand and inventing one is not an option.
✅ Pro tip: Before your organisation commits engineering time to any protocol, chain or agent standard, write down two things: how many independent implementations of it currently interoperate, and what a second adopter pays to try it. Those are the only two questions in this entire history that were answerable in advance — and between 1983 and 1990 they were answered correctly by people who had no idea they were settling anything.