Early Networking Failures: The Protocol Wars

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.

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 U.S. government mandated OSI-compatible protocols for federal procurement in 1988 (GOSIP — Government Open Systems Interconnection Profile).

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 developed by IBM and standardized as IEEE 802.5 in 1985. 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: Token Ring network interface cards cost $500–$1,000 in the late 1980s; Ethernet cards cost $50–$150 and falling.
• Speed: Ethernet advanced from 10 Mbps to 100 Mbps (Fast Ethernet, 1995) and 1 Gbps (1998), while Token Ring remained at 4 Mbps and 16 Mbps. IBM announced 100 Mbps Token Ring in 1999 — after Ethernet had won.
• Ecosystem: Ethernet’s lower cost and open standard attracted more hardware manufacturers, driving prices further down.

IBM discontinued new Token Ring development in 2001.

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. Carriers used ATM to carry SONET optical fiber traffic. Enterprises bought ATM switches at costs of $50,000 to $500,000 per unit. 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.

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. At its peak in the late 1980s, approximately 70% of corporate LANs ran NetWare.

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 concept that TCP/IP would not formalize until APIPA in 1998), built-in name resolution via NBP (Name Binding Protocol), and protocol layers for file sharing (AFP, AppleFiling 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 deprecated in Mac OS X 10.6 Snow Leopard (2009) and removed in Mountain Lion (2012). 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, ANSI X3.166, 1987) was a 100 Mbps 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. A FDDI network interface card for a workstation cost approximately $1,000–$1,500 in the early 1990s, versus $50–$200 for an Ethernet card. FDDI concentrators and routers cost $20,000–$100,000. 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, 1995, IEEE 802.3u) arrived at $100–$200 per port. Fast Ethernet matched FDDI’s bandwidth at one-tenth the cost, ran over existing Category 5 twisted-pair cable rather than expensive 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 found a long-lasting niche in storage area networks and 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 (1975) 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 VAX clusters and PDP systems with reliable point-to-point links and cluster support for failover. A DEC customer running multiple VAX servers could take advantage of DECnet’s clustering to present a single system image across multiple physical machines — 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) was published by NIST in 1988 and required federal agencies to purchase OSI-compatible networking equipment for all procurements after August 1990.

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. By 1993, the NSFNET backbone had been commercialized and internet connectivity was available to private companies. 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 amended GOSIP in 1995 to allow TCP/IP as an alternative, 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

• Metcalfe, Robert M. & Boggs, David R.: “Ethernet: Distributed Packet Switching for Local Computer Networks” — Communications of the ACM, Vol. 19, No. 7 (1976)
• Hafner, Katie & Lyon, Matthew: Where Wizards Stay Up Late: The Origins of the Internet (1996), Simon & Schuster
• Day, John D. & Zimmermann, Hubert: “The OSI Reference Model” — Proceedings of the IEEE, Vol. 71, No. 12 (1983)
• McDysan, David E. & Spohn, Darren L.: ATM: Theory and Application (1994), McGraw-Hill
• Clark, David D.: “The Design Philosophy of the DARPA Internet Protocols” — ACM SIGCOMM Computer Communication Review, Vol. 18, No. 4 (1988)