Skip to content

Early Networking Failures: The Protocol Wars

Abstract

Before TCP/IP, the networking landscape was a battlefield of competing protocols, each backed by engineering conviction, corporate investment, and national standards bodies. Token Ring was technically superior to Ethernet on paper. The OSI model was more rigorous than TCP/IP in theory. ATM (Asynchronous Transfer Mode) promised to unify voice and data networks into a single guaranteed-quality infrastructure. None of them won. The Protocol Wars of the 1970s through 1990s produced some of the clearest lessons about how technical networks actually succeed: not through elegance, not through committee endorsement, but through availability, simplicity, and the momentum of early adoption.

The Pre-Internet Landscape

The ARPANET (1969) demonstrated that packet switching worked, but it was a research network with a few dozen nodes, accessible only to universities and defense contractors under government contract. The commercial world needed networks too (office LANs, corporate WANs, bank networks, airline reservation systems) and no single standard existed. Through the 1970s and early 1980s, every large vendor developed proprietary networking protocols: IBM had SNA (Systems Network Architecture, 1974), DEC had DECnet, and Xerox had XNS (Xerox Network Systems). These networks connected machines from the same manufacturer reliably and connected to anything else poorly.

One research network of the period lost at home and won everywhere else. France’s CYCLADES, built at IRIA from 1971 under Louis Pouzin, ran a subnet that made no delivery promises at all and left reliability to the hosts. The French PTT preferred virtual circuits, funded Transpac instead, and CYCLADES was shut down in 1981, by which time its datagram argument had passed through the International Network Working Group into TCP.

The international standards community’s answer was the OSI model (Open Systems Interconnection, 1984), developed by the International Organization for Standardization (ISO) over nearly a decade of committee work. OSI was architecturally rigorous: seven layers, each with precisely defined responsibilities, clean boundaries between them, and formal specifications for every interface. Every major telecommunications company and national standards body endorsed it. The seven layers came from the same building as CYCLADES: Hubert Zimmermann worked in Pouzin’s group at IRIA from 1972, joined the ISO effort in 1977, and set out the architecture in “OSI Reference Model: The ISO Model of Architecture for Open Systems Interconnection” in IEEE Transactions on Communications in April 1980. He got the SIGCOMM Award in 1991 for the work, and in 1986 founded Chorus Systèmes to sell the Chorus distributed microkernel, which Sun Microsystems bought in 1997. The U.S. government published GOSIP (Government Open Systems Interconnection Profile) in 1988 and made it a procurement requirement from August 1990.

OSI produced protocols. X.400 for email, X.500 for directory services, FTAM for file transfer, all formally specified, all officially standardized, all difficult to implement correctly, all significantly slower to arrive than the equivalent TCP/IP protocols (SMTP, DNS, FTP) that had been developed pragmatically for ARPANET. By the time OSI implementations were available, TCP/IP had already been deployed across the growing internet. The standards had arrived too late.

Token Ring vs. Ethernet: The LAN Battle

Ethernet was invented at Xerox PARC by Robert Metcalfe and David Boggs in 1973 and standardized as IEEE 802.3 in 1983. It used CSMA/CD (Carrier Sense Multiple Access with Collision Detection), devices listened before transmitting, and if two devices transmitted simultaneously (a “collision”), both backed off for a random interval and tried again. This was simple, cheap to implement, and worked well under normal load. Under heavy load (when many devices competed simultaneously) collision rates increased and throughput degraded.

Token Ring was launched by IBM on 15 October 1985 at 4 Mbit/s and standardized as IEEE 802.5 in 1989. Instead of random access, Token Ring used a controlled mechanism: a special “token” packet circulated around the ring, and only the device holding the token could transmit. No collisions were possible by design; bandwidth utilization at high load was more predictable than Ethernet. Token Ring was technically more elegant, offered deterministic latency (important for real-time applications), and IBM built extensive enterprise IT around it.

Token Ring lost. The reasons were practical:

  • Cost: a Token Ring interface built on the Texas Instruments TMS380C16 cost roughly three times an Ethernet interface built on the Intel 82586, and router ports were more expensive in the same proportion.
  • Speed: Ethernet advanced from 10 Mbit/s to 100 Mbit/s (Fast Ethernet, 1995) and 1 Gbit/s (1998), while Token Ring ran at 4 Mbit/s and, from the 1988 standard, 16 Mbit/s. A 100 Mbit/s Token Ring was standardized only as the technology was already fading and was never widely used.
  • Ecosystem: Ethernet’s lower cost and open standard attracted more hardware manufacturers, driving prices further down.

A gigabit Token Ring standard was approved in 2001. No products based on it ever shipped.

ATM: The Telco’s Internet

Asynchronous Transfer Mode (ATM) was the telecommunications industry’s attempt to build the universal network for the 1990s. Defined by the ITU-T through a decade of standards work, ATM used fixed-size 53-byte cells (5 bytes header, 48 bytes payload) that could carry voice, video, and data with quality-of-service guarantees. Unlike the variable-length packets of TCP/IP, ATM cells could be switched in hardware at predictable rates, enabling guaranteed bandwidth, critical for voice calls, where variable latency causes audible problems, but also promised for video and “real-time” data.

ATM was deployed extensively in telecommunications backbone networks through the 1990s, generally over SONET optical fibre. The internet itself ran over ATM backbones for several years: TCP/IP packets were encapsulated inside ATM cells, a configuration that wasted bandwidth (the 53-byte cell size was a compromise between European preferences for 32-byte payloads and American preferences for 64-byte payloads, pleasing nobody optimally) and added complexity without using ATM’s quality-of-service capabilities, which TCP/IP couldn’t request anyway.

The commercial internet’s bandwidth growth outran ATM’s engineering assumptions. A 155 Mbps OC-3 ATM link was expensive and sophisticated in 1995; by 2000, IP-over-SONET without ATM’s overhead was cheaper, simpler, and fast enough that the quality-of-service guarantees ATM provided were less valuable than the bandwidth efficiency of eliminating ATM altogether. ATM survived in DSL (the ADSL standard uses ATM cells over telephone lines) and in some carrier backbones, but as a universal networking paradigm, it was replaced by IP.

The Cell Tax

ATM’s 53-byte cell size imposed a 5/53 = 9.4% overhead purely from headers, before any fragmentation overhead from splitting large packets across multiple cells. For voice and video traffic with small payloads, this overhead was acceptable. For data traffic with large packets, it was wasteful. The inability to get international agreement on a sensible payload size was symptomatic of the political compromises that plagued ITU standards development more broadly, and of why pragmatic, deployed protocols consistently outcompeted formally specified ones.

IPX/SPX: The Office Network That Lost

Novell NetWare, using the IPX/SPX (Internetwork Packet Exchange / Sequenced Packet Exchange) protocol suite, dominated corporate LAN networking through the 1980s and early 1990s. NetWare’s file and print sharing were fast, reliable, and better engineered for office workloads than early TCP/IP implementations. By the early 1990s NetWare held close to 70 percent of the network operating system market.

IPX/SPX was not designed for routing across large internets. As corporations expanded and began connecting offices through WANs and eventually to the internet, the need for a single routable protocol became compelling. Microsoft’s Windows NT introduced native TCP/IP support; Microsoft’s networking stack became “good enough” for file and print sharing; and the internet’s growth made TCP/IP connectivity a practical necessity. Corporate IT departments converged on a single protocol (TCP/IP) rather than maintaining separate NetWare and internet stacks. Novell released NetWare IP support (running IPX/SPX encapsulated within IP packets) as a migration path; customers used it to migrate away from IPX entirely. Novell was acquired by Attachmate in 2011; its networking protocol hegemony had ended a decade earlier.

AppleTalk: The Friendly LAN That Lost

AppleTalk was Apple’s networking protocol, designed by a team led by Gursharan Sidhu and built into every Macintosh starting with the original 128K Mac in 1984. Its design goal was radical for the time: zero configuration. A user plugged a Mac into a LocalTalk cable (Apple’s proprietary connector using standard RS-422 ports), and the Mac automatically discovered other Macs and printers on the network without requiring manual IP address assignment, router configuration, or network administrator involvement.

The technical design was elegant: self-assigning addresses (each node picked a random address and broadcast to verify it was unused, a mechanism the IETF standardized for IPv4 only in 2005, as the 169.254.0.0/16 link-local block of RFC 3927), built-in name resolution via NBP (Name Binding Protocol), and protocol layers for file sharing (AFP, the AppleTalk Filing Protocol, later renamed the Apple Filing Protocol) and printer access (PAP, Printer Access Protocol). The AppleTalk printer discovery protocol made PostScript laser printers accessible to any user on the network without configuration.

LocalTalk was slow: 230.4 kbps, compared to Ethernet’s 10 Mbps. Apple extended AppleTalk to run over Ethernet (EtherTalk) and Token Ring (TokenTalk), but the underlying protocol was not designed for large-scale routing across multiple network segments. As organizations grew and connected multiple buildings, AppleTalk’s broadcast-heavy protocols created performance problems. AppleTalk routing through multiple zones was complex to administer; large AppleTalk networks (hundreds of nodes across multiple sites) required careful management that undermined the “plug and play” original promise.

When Apple shipped Mac OS X (2001), built on BSD Unix with native TCP/IP networking, the migration path was clear. AppleTalk support was removed from Mac OS X in 10.6 Snow Leopard (2009); AFP survived over TCP until macOS 11 Big Sur. The zero-configuration networking concepts AppleTalk pioneered survived through Bonjour (Apple’s mDNS/DNS-SD implementation), which brings automatic device discovery to TCP/IP networks, a direct descendant of AppleTalk’s design philosophy, running on the protocol that replaced it.

FDDI: The Speed King Without a Kingdom

FDDI (Fiber Distributed Data Interface, standardized as ANSI X3.139-1987 for the media access layer and X3.148-1988 for the physical layer) was a 100 Mbit/s token ring network designed for campus backbone infrastructure. Where Ethernet operated at 10 Mbps over coaxial cable and Token Ring at 4 or 16 Mbps, FDDI delivered 100 Mbps over fiber-optic cable with fault tolerance: FDDI used a dual counter-rotating ring that automatically bypassed failed nodes. A broken fiber link would trigger automatic reconfiguration in milliseconds, providing network resilience that Ethernet could not match.

FDDI was technically advanced and correspondingly expensive: fibre-optic transceivers, dual attachments and concentrators cost far more per port than coaxial or twisted-pair Ethernet. The customers who could afford FDDI were financial institutions (requiring high-speed, fault-tolerant trading floor networks), medical centers (high-resolution imaging required bandwidth Ethernet could not provide), and government/military installations.

Universities deployed FDDI as campus backbones in the early 1990s, connecting buildings via fiber with FDDI, then using Ethernet within each building. This two-tier architecture worked until Fast Ethernet (100BASE-TX, IEEE 802.3u, 1995) arrived. Fast Ethernet matched FDDI’s bandwidth at much lower cost, ran over existing Category 5 twisted-pair cable rather than fiber, and used the Ethernet protocol that network administrators already knew. Gigabit Ethernet (1998) then provided 1 Gbps at prices FDDI could not approach.

FDDI survived in legacy installations through the 2000s, but as a campus networking standard it was displaced completely by Fast Ethernet and then Gigabit Ethernet. The technical advantages of token ring access control and fault-tolerant dual rings were insufficient to justify the cost premium when Ethernet’s performance caught up.

DECnet and SNA: The Proprietary Empires

IBM’s SNA (Systems Network Architecture, 1974) and DEC’s DECnet (Phase I, 1975, initially linking PDP-11s over DDCMP point-to-point links) were the dominant networking protocols of the mainframe and minicomputer eras, and both were designed with the same fundamental limitation: they worked superbly for connecting equipment from a single manufacturer and poorly for anything else.

SNA was architecturally impressive for its time: a seven-layer hierarchical network architecture connecting IBM mainframes (the “hosts”) through front-end processors to cluster controllers to terminals. An SNA network for a large bank might connect thousands of 3270 terminals to mainframes via leased lines, with guaranteed session management, error recovery, and transaction routing that the networks of the 1980s needed to handle high-volume OLTP workloads. SNA’s APPC (Advanced Program-to-Program Communications) protocol predated TCP/IP’s application-level communication models.

DECnet connected PDP and later VAX systems with reliable point-to-point links; from Phase IV it carried VMScluster support, so a customer running several VAX servers could present them to the network under a single cluster alias, a capability with no equivalent in early TCP/IP implementations.

Both protocols required their manufacturer’s hardware to function at full capability and required their manufacturer’s expertise to administer. When the internet arrived and TCP/IP became the universal protocol, organizations found themselves maintaining parallel network infrastructure: SNA or DECnet for legacy applications, TCP/IP for internet connectivity and new deployments. SNA gateways (translating SNA to TCP/IP) and DECnet-to-IP migration tools became entire product categories. The maintenance cost of parallel networking was the practical argument that drove replacement; TCP/IP won not because it was better than SNA at transaction processing, but because maintaining both networks was expensive and SNA was not available for new deployments on new hardware.

The GOSIP Mandate and Its Failure

The U.S. Government’s attempt to accelerate OSI adoption through procurement requirements illustrates the limits of regulatory standardization when deployment has already chosen a winner. GOSIP (Government Open Systems Interconnection Profile) version 1.0 was published in August 1988, adopted as FIPS 146 on 15 February 1989, and enforced from 15 August 1990, from which date federal agencies buying network products had to require OSI compliance where the functionality GOSIP specified was needed.

GOSIP’s theory was sound: if the largest single buyer in the world mandated a standard, vendors would implement it, the installed base would grow, and OSI would gain the momentum needed to displace TCP/IP. The execution failed for two reasons.

First, GOSIP-compliant products were expensive, complex to configure, and slower than TCP/IP alternatives. The OSI protocol stack required more processing overhead than TCP/IP’s lean implementation. Federal agencies faced a choice between cheaper TCP/IP systems that worked and expensive GOSIP-compliant systems that also worked, and procurement officers found ways to satisfy both requirements simultaneously.

Second, the internet continued to grow. Congress opened NSFNET to commercial traffic with the Scientific and Advanced-Technology Act of October 1992, and the backbone itself was handed over to commercial carriers and decommissioned on 30 April 1995. Federal agencies that needed to communicate with universities, contractors, and commercial entities had to use TCP/IP regardless of GOSIP requirements. The pragmatic response was to implement TCP/IP as the production network and satisfy GOSIP requirements with separate compliant hardware that was minimally used.

NIST issued FIPS 146-2 in 1995, which allowed protocols from other open standards bodies including the IETF, effectively acknowledging that the mandate had failed. By the time OSI protocols were fully available and compliant products well-priced, TCP/IP’s deployment advantage was insurmountable.

Why TCP/IP Won

TCP/IP did not win because it was the best protocol. X.25 handled errors more gracefully. OSI was more rigorous. ATM offered better quality-of-service. TCP/IP won because:

  1. It was available first as a working implementation across heterogeneous hardware.
  2. It was simple enough to implement correctly without expensive specialized hardware.
  3. ARPANET/NSFnet created a network worth connecting to, and TCP/IP was the price of admission.
  4. The end-to-end principle (error handling in the endpoints, not the network) made the protocol robust to hardware heterogeneity.
  5. Open specification, the RFCs were freely available and implementable without license fees.

The Protocol Wars’ lesson is not that technical quality is irrelevant. It is that availability, simplicity, and network effects dominate technical quality during a formative period, and that standards which arrive after deployment cannot displace deployed protocols regardless of their technical merits.

📚 Sources