Ask what happened to the OSI model and you usually get a morality tale: a committee drew seven layers, engineers ignored them, running code won. Here is a document that makes that story very hard to tell.
In February 1985 the National Research Council published its final report on the question as RFC 942, Transport Protocols for Department of Defense Data Networks. Its committee had done the comparison directly — the winner against the loser, side by side — and reached this conclusion:
“A detailed comparison of the DOD Transmission Control Protocol and the ISO Transport Protocol indicates they are functionally equivalent and provide essentially similar services.”
Then it made a recommendation:
“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.”
An independent expert body compared the two stacks, found them equivalent, and unanimously recommended moving to the one that lost.
The receipt, and exactly what it does and does not say
RFC 942 is the final report of the NRC’s Committee on Computer-Computer Communication Protocols. It is not a partisan document and it is not vague. On the specific question of whether the DoD’s own protocol was better than the ISO one, it says the opposite of what the folk history assumes:
“Although there are differences between the two protocols, they do not compromise DOD requirements.”
And, on the design differences it does find — data transfer interface, flow control, connection establishment, out-of-band signalling — it concludes:
“…neither seems intrinsically superior.”
The word inferior does not appear anywhere in RFC 942. Superior appears twice, both times in that same negative construction.
⚠️ This is not a claim that TCP/IP was worse, and it must not be stretched into one. The committee wrote that it was “confident that TP-4 will meet military requirements” — adequate, equivalent, worth transitioning to. That is narrower and more interesting than a scoreboard: in 1985, on the merits, the choice was close to a coin flip. Why the coin landed where it did is a story about procurement, deployment cost, licensing and installed base, and it belongs to this hub’s cornerstone on the protocol wars.
Unanimous on the recommendation, divided on the timing
Precision matters here, because the “unanimously” is doing a lot of work and it applies to one thing only. Under the heading BASIC RECOMMENDATION, RFC 942 records agreement on the destination and open disagreement on the schedule: a majority favoured “immediate adoption of the ISO protocols as costandards with TCP”, while a minority “favored deferring adoption of the ISO protocols by the DOD until after a demonstration of commercial quality implementations supporting military applications”
Unanimous that TP-4 should eventually replace TCP. Split on when. Anyone quoting this report as “the experts said OSI was better” has read one sentence and stopped.
One piece of hygiene, because almost every retelling gets it wrong: TP-4 is not a document. It is Transport Class 4, one option inside ISO 8073, transcribed for the Internet community as RFC 905 in April 1984. That specification says of itself: “This International Standard defines five classes of protocol”, running from Class 0 Simple up to “Class 4: Error Detection and Recovery Class.” Class 4 is the one meant to run over a connectionless network service, which is why it pairs with CLNP the way TCP pairs with IP. CLNP, X.400 and X.500 are standalone specifications; TP-4 is a negotiated option inside a fourth.
“Lost the transport war” and “failed” are different claims
OSI’s transport and network layers lost, comprehensively. CLNP is not carrying your packets and TP-4 is not carrying your bytes. But the OSI programme produced a family of specifications, and the transport pair was not the part that survived.
Check the standards catalogue rather than the folklore. On 8 September 2026, ITU’s record for X.500 — Information technology – Open Systems Interconnection – The Directory — lists the in-force edition as X.500 (10/19), with Amendment 1 (10/24) also in force. The OSI Directory standard was amended in October 2024. The same catalogue lists X.690, the ASN.1 encoding rules, in force at edition 02/21 with a 2021 erratum.
Neither is a museum piece, and the reason is sitting in your browser. X.509 — the certificate format checked on every TLS handshake — was defined inside the X.500 Directory series, and it is encoded with ASN.1. The IETF’s own profile of it, RFC 5280 (May 2008), says in its abstract that “An ASN.1 module and examples are provided in the appendices.” Across that document, “ASN.1” appears 63 times and “X.500” 23 times. Two OSI artifacts — the certificate format and its encoding rules — are load-bearing in every HTTPS connection you make.
The directory itself survived by being rebuilt. RFC 1487 (July 1993) introduced the X.500 Lightweight Directory Access Protocol, “designed to provide access to the Directory while not incurring the resource requirements of the Directory Access Protocol (DAP)”, and listed as its first key aspect that protocol elements are “carried directly over TCP or other transport, bypassing much of the session/presentation overhead.” Thirteen years later, RFC 4511 (June 2006) is still LDAP and still mentions X.500 fifteen times. Every enterprise directory lookup you have done inherits its data model from a 1988 OSI standard.
The abbreviation “OSI” appears zero times in the first LDAP spec
Search RFC 1487 for the string “OSI” and you get nothing. The full phrase “Open Systems Interconnection” occurs exactly once, in a bibliography entry for ISO/IEC 9594-1. A document whose entire purpose is to make an OSI directory reachable from the Internet never once names the programme it inherited from.
That is what surviving looks like for a losing architecture: the artifacts get absorbed, the brand does not travel with them, and a generation later engineers use the parts daily without knowing whose they were. The seven-layer diagram, meanwhile, is still on every networking syllabus — a teaching vocabulary that outlived the protocol suite it was written to organise. (How well that vocabulary maps onto the stack that won is a separate argument, and this hub has a separate article for it.)
AppleTalk plugged in and worked, and the IETF said so in 2013
The strongest single case for “the loser was better at something” is not OSI at all. It is a LAN protocol Apple shipped in 1985 that self-configured, and the receipt is written into the IETF’s own standards.
RFC 6760, Requirements for a Protocol to Replace the AppleTalk Name Binding Protocol (NBP) — Cheshire and Krochmal of Apple, February 2013 — opens its abstract with the goal stated flatly:
“One of the goals of the authors of Multicast DNS (mDNS) and DNS-Based Service Discovery (DNS-SD) was to retire AppleTalk and the AppleTalk Name Binding Protocol (NBP) and to replace them with an IP-based solution.”
That is a 2013 document explaining that a 1985 protocol still needed retiring. It then spends its length cataloguing what the replacement had to match: “This section lists the 15 requirements for an IP-based replacement for AppleTalk NBP.” Section 3.6 is titled Zeroconf Operation, and its first sentence is in the present tense: “AppleTalk NBP is self-configuring.”
The companion standards-track document is even plainer. RFC 6762, Multicast DNS, states in its introduction that mDNS and DNS-SD “were created to provide IP networking with the ease-of-use and autoconfiguration for which AppleTalk was well-known” The word “AppleTalk” appears 60 times in RFC 6760, 13 times in RFC 6763 and 9 times in RFC 6762.
Plug two Macs together in 1985 and they found each other, named each other and offered each other services, with no server and no administrator. The IP world took until February 2013 to standardise an equivalent — and when it did, the specification named its ancestor in its title. Every AirPrint discovery and every smart speaker that appears on your network without configuration is running the descendant of a protocol from a stack that lost.
Where the other five actually went
| Stack | The constraint it optimised for | Where it genuinely won | What is still running |
|---|---|---|---|
| X.25 | Noisy analogue phone circuits; carrier billing per virtual call | Worldwide public data networks through the 1980s | ITU lists X.25 (10/96) as in force; the virtual-circuit model passed into Frame Relay and ATM |
| IPX/SPX | Fast file and print sharing inside one administrative domain | The corporate LAN, comprehensively, before Windows NT Server | Effectively nothing on the wire — NetWare itself moved to native TCP/IP |
| NetBIOS | NetBEUI | A single-office broadcast domain with no router in it | Small workgroup LANs, 1983–1990s | The NetBIOS name service idea, carried over TCP/UDP by RFC 1001/1002 |
| DECnet | One vendor’s coherent enterprise network | DEC’s own Easynet and every VAX/VMS shop | Nothing of Phase IV; Phase V’s network layer was CLNP, i.e. OSI |
| SNA | A scarce, expensive mainframe at the centre of everything | IBM mainframe estates, and they did not evaporate | DLSw tunnels (RFC 1795); SDLC’s descendant HDLC in WAN framing |
| ATM | Predictable switching for voice, video and data on one fabric | Carrier cores and DSL access networks | ITU lists I.361 (02/99) as in force; cells still move traffic in carrier transport |
X.25 paid for reliability in the network, because the links were bad
X.25’s defining choice was hop-by-hop error correction in its LAPB data-link layer. That looks like overhead now and was rational then: the copper underneath was noisy, and fixing errors at every hop was cheaper than discovering them end to end. The Internet did not fight this network, it rode on it — RFC 877 (J. T. Korb, Purdue, September 1983) standardised IP datagrams inside X.25 virtual circuits, and RFC 1356 (August 1992) replaced it nine years later.
Once digital circuits drove bit-error rates toward zero, the hop-by-hop repair stopped earning its keep, and the same standards world built Frame Relay without it. ⚠️ A caution on a detail that circulates widely: the frame-relay RFCs do not describe themselves as a cut-down X.25. RFC 2427 (STD 55, September 1998) mentions X.25 exactly once, to note that its IP encapsulation is “consistent with the encapsulation of IP in X.25”. The lineage is real; the memorable phrasing is not from the specification.
⚠️ A second caution, on dates. X.25 is usually said to have been approved by CCITT in 1976. ITU’s catalogue page for X.25, checked 8 September 2026, does not list a 1976 component at all — its oldest entry is X.25 (11/88), superseded, and the in-force edition is X.25 (10/96) with a 1998 corrigendum. The 1976 date may well be correct; the ITU catalogue is not the source for it.
IPX/SPX won the LAN and never left it
It is easy to forget how completely Novell’s stack owned the corporate network, because nothing of it survives to remind you. RFC 1234 (D. Provan, Novell, June 1991) describes IPX as “functionally equivalent to the Internet Datagram Protocol (IDP) from the Xerox Network Systems (XNS) protocol suite” — the same Xerox ancestry, and the same network-layer-plus-reliable-transport split as IP and TCP, arrived at independently.
What it lacked was an addressing model that anyone but the network’s own administrator could hand out. That is not a performance problem, and it is exactly the ceiling that decides which protocol can become an internet. The tunnelling RFCs are the epitaph: by 1991 Novell was documenting how to carry IPX inside UDP so it could cross an IP network.
DECnet’s ceiling is written into DEC’s own MIB
DECnet Phase IV’s scaling limit is usually quoted as a round number from secondary sources. You can read it off a primary instead. RFC 1289, the DECnet Phase IV MIB Extensions published by Digital Equipment Corporation in December 1991, encodes the ceiling in its type declarations: phivRouteMaxArea is SYNTAX INTEGER (1..63), described as “the largest area number and, therefore, number of areas that can be known about by the executor node’s Routing”; phivRouteMaxAddr is SYNTAX INTEGER (1..1023), “the largest node number and, therefore, number of nodes that can be known about by the executor node’s home area.”
Sixty-three areas of 1,023 nodes. The famous 64,449-node maximum is not folklore — it is the product of two integer ranges in the vendor’s own management information base, checkable in ninety seconds.
DEC’s answer was to rebuild Phase V’s network layer on OSI’s CLNP, then bridge the result onto the winner. RFC 1859 (Y. Pouffary, Digital Equipment Corporation, October 1995) extends the ISO-transport-over-TCP mechanism of RFC 1006, and its section 4 is titled, without irony, “DIGITAL DECnet over TCP/IP”
SNA was hierarchical because the hardware was
IBM’s Systems Network Architecture put a mainframe at the centre and everything else below it. That was the correct shape for the problem IBM had, where the scarce resource was central and expensive, and the wrong shape for a network of peers. It did not go away quietly: RFC 1795 (April 1995), produced by the IBM-sponsored APPN Implementers Workshop, defines Data Link Switching as “a forwarding mechanism for the IBM SNA (Systems Network Architecture) and IBM NetBIOS (Network Basic Input Output Services) protocols”, encapsulated in TCP/IP.
Read one sentence further and the war looks less settled than the retelling suggests. In April 1995, ten years after RFC 942, an IBM-sponsored standards group wrote: “However, other transport connections such as OSI TP4 could be used in the future.” TP-4 was still in the future tense inside a TCP/IP specification.
⚠️ While we are here: NetBIOS and NetBEUI are not one thing wearing two names. NetBIOS is Sytek’s 1983 session and naming API; NetBEUI is IBM’s 1985 protocol built to extend it; the wire protocol underneath is NBF, NetBIOS Frames. NBF has no network-layer address at all, which is why it cannot be routed — a property, not a bug, for a single-office LAN in 1985. What survived is the naming service, carried over TCP and UDP by RFC 1001 and RFC 1002 (March 1987).
ATM’s fixed cell bought predictability and charged rent for it
ATM’s 53-byte cell — 48 bytes of payload behind a 5-byte header — made switch hardware simple and latency predictable, which is precisely what a network carrying a voice call and a file transfer at once needs. It also imposed a floor of about 9.4% header overhead on every cell before any higher-layer encapsulation, and real payloads rarely divide neatly into 48 bytes. That is the cell tax.
⚠️ The story usually told about how 53 was chosen — an American proposal of a 64-byte payload, a European one of 32, split down the middle — could not be confirmed against a primary source for this article. ITU-T I.361 is not freely available as machine-readable text, so the account rests on secondary sources: treat it as well-corroborated folklore, not a sourced fact. What is checkable from ITU’s catalogue on 8 September 2026 is that I.361, B-ISDN ATM layer specification, remains listed as in force at edition 02/99.
IP rode ATM rather than replacing it for years — RFC 1483 (July 1993) and RFC 2225 (April 1998) define how. ATM lost the desktop to Gigabit Ethernet and kept the carrier core, which is a different outcome from dying.
Every one of them bet on a constraint, and the constraint moved
The pattern across all eight is not incompetence. It is a correct bet on a condition that later stopped being true.
X.25 bet that links would stay unreliable; digital circuits made hop-by-hop repair a tax. ATM bet that switching hardware would stay expensive enough to justify fixed-length cells; Ethernet got fast and cheap. SNA bet the centre would stay scarce. DECnet, IPX and NetBEUI all bet that a network had one administrative owner — each worked beautifully inside that assumption and hit a wall at its edge. AppleTalk’s bet was the most interesting: it assumed nobody would administer the network at all, which was wrong for 1985 corporate IT and is exactly right for the phone-and-printer network in your house.
OSI’s bet was that a standard agreed in advance would be the thing everyone converged on. That bet lost at the transport layer and won at the certificate — which is the honest answer to what happened to the OSI model. The transport war was lost, the reference model became the teaching vocabulary, and the Directory and its encoding rules quietly became infrastructure the ITU is still amending.
The generalisable version is not “simpler wins” — RFC 942 spent sixty-eight pages establishing that the two candidates were about equally complex and about equally good. It is that a protocol’s defining engineering choice is a bet on which constraint will still matter later, and that adoption is decided by cost, licensing, timing and who ships running code rather than by a technical comparison. That is the argument this hub’s cornerstone makes at length, and RFC 942 is its cleanest evidence: an independent committee ran the technical comparison, and the technical comparison did not decide the outcome.
❓ Frequently Asked Questions
Did the OSI model actually fail? Two different things wore the name. The protocol suite lost the transport and network layers decisively — CLNP and TP-4 are not deployed. The reference model is still the standard teaching vocabulary, and “layer 3” and “layer 7” remain load-bearing terms in firewall and load-balancer documentation. Meanwhile X.500 and ASN.1 became permanent infrastructure. “Failed” is too blunt an instrument for that mixture.
Is anything from OSI still running on the modern internet? Yes, on every HTTPS connection. X.509 certificates were defined in the X.500 Directory series and are encoded using ASN.1, whose encoding rules ITU publishes as X.690 — in force at the 02/21 edition as of 8 September 2026. LDAP, the protocol behind most enterprise directories, began life as RFC 1487 in July 1993 explicitly as a lightweight route to an X.500 Directory.
Was TCP/IP technically better than OSI’s TP-4? Not according to the most rigorous comparison made at the time. RFC 942, the National Research Council’s February 1985 report, found the two “functionally equivalent”, noted that their differences “do not compromise DOD requirements”, and concluded that “neither seems intrinsically superior.” The committee then unanimously recommended adopting TP-4 as a costandard and moving toward exclusive use of it — while splitting over how quickly to do so.
Why is the seven-layer model still taught if nothing implements it? Because a shared vocabulary for naming a concern is worth having even when it maps imperfectly onto real protocols, and nothing has replaced it. The exam question is a poor reason; the design-review conversation is a good one. Where the mapping breaks down against the four-layer Internet model is a question with its own answer, and its own article.
What is the strongest example of a losing protocol being better than the winner at something? AppleTalk’s zero-configuration networking. It shipped in 1985, and the IETF standardised an IP equivalent in February 2013 — RFC 6762 says mDNS and DNS-SD “were created to provide IP networking with the ease-of-use and autoconfiguration for which AppleTalk was well-known”, and RFC 6760’s stated goal was “to retire AppleTalk and the AppleTalk Name Binding Protocol (NBP)” Twenty-eight years is a long time to be ahead.
Is X.25 or ATM completely gone? Neither is formally withdrawn. ITU’s catalogue, checked 8 September 2026, lists X.25 (10/96) and I.361 (02/99) as in force. ATM cells still move traffic inside carrier transport networks, and X.25 lingers in a few conservative industries. What ended in both cases was the ambition — being the network — not the deployment.
📚 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.
The free primary material genuinely beats the books on this subject, and one document in particular is worth more than any summary of it.
Start with RFC 942 and do not skip to the recommendations. It is the National Research Council’s February 1985 report, it is free, and it is the single most surprising document in this whole argument: an independent expert committee comparing TCP against ISO TP-4 on reliability, security, performance under crisis conditions and cost of transition, concluding that “neither seems intrinsically superior”, and unanimously recommending a move to the protocol that lost. Read Section “SOME COMPARISONS” and then the “BASIC RECOMMENDATION” heading, where the committee records its own split over timing. It will permanently change how you read anyone’s claim that the better technology won.
Then read what TP-4 actually was. RFC 905 (April 1984) is the transcription of ISO 8073 into the RFC series. Section 5.4 is the part that matters — five negotiable classes of transport protocol, of which Class 4 is one. Ten minutes there will stop you ever again describing TP-4 as a document.
For the “the loser was better at something” case, read the Apple RFCs in order. RFC 6760 lists the fifteen things a 1985 protocol did that IP could not, RFC 6762 is the standards-track replacement, and RFC 6763 is its service-discovery half. All three are from February 2013, and all three name AppleTalk.
For the archaeology, two documents are unexpectedly good reading. RFC 1289 is DEC’s own DECnet Phase IV MIB, where the network’s size ceiling is visible in two integer ranges. RFC 1795 is IBM’s SNA-over-TCP/IP tunnel from 1995, which mentions OSI TP4 as a plausible future transport. And ITU’s catalogue is free to search: the pages for X.500 and I.361 will tell you, in about fifteen seconds, that two standards you assumed were dead are listed as in force.
Free and better than a chapter: open any HTTPS certificate in your browser’s inspector and look at the field names — Distinguished Name, Common Name, Organizational Unit. That vocabulary is X.500’s, and it is on your screen right now.
Two books, if you want the long form
- TCP/IP Illustrated, Volume 1: The Protocols, 2nd edition — Fall and Stevens, Addison-Wesley, 2012. Not a history book, and that is the point: it is the reference for what the protocol that won actually does on the wire, which is the necessary counterweight to reading about the ones that did not.
- Where Wizards Stay Up Late: The Origins of the Internet — Simon & Schuster, paperback. Worth knowing what it is and is not: it is a narrative history of how the ARPANET got built, not an account of the OSI–TCP/IP standards fight, so read it for the institutional texture rather than for this article’s argument.
Two further books are named here deliberately without links, because their print editions could not be identity-confirmed for this article and a link that resolves is not the same as a link that is the book you claimed:
- Open Standards and the Digital Age: History, Ideology, and Networks — Andrew L. Russell, Cambridge University Press. The academic history of exactly this question, and the best single source on why a mandated standard lost. ⚠️ ASIN UNVERIFIED
- Patterns in Network Architecture: A Return to Fundamentals — John Day, Prentice Hall. Written by someone who worked on OSI and thinks the whole layering settlement is wrong. ⚠️ ASIN UNVERIFIED