CHALLENGES TO TCP/IP

The TCP/IP protocols, and the process that created them, have not been without their challenges. One came from the Open Systems Interconnection (OSI) protocol suite, which had been developed by the ISO.

The simultaneous existence of TCP/IP and OSI raised two possibilities. One was that the Internet would have ‘tipped’ and only one of the two competing standards would have survived. Alternatively, the Internet could have become fragmented, with both TCP/IP and OSI being in use at the same time.¹⁰ Which of these two outcomes was more likely depended on whether users placed greater value on being on a large ‘network’ or on the intrinsic characteristics of the alternative standards. It also depended on the success of the tactics employed by the sponsors of the competing alternatives.

The challenge from proprietary protocols not only raised the possibility that TCP/IP would be displaced but also that a small number of commercial entities might dictate Internet standards. If that were the case, those entities could have charged for access to their intellectual property or denied rivals access to their standards altogether, or they could have obtained a competitive advantage through their superior knowledge of the standards and control of their further development.

As it turned out, both challenges to TCP/IP, and to the IETF process, were repulsed. Exactly why is subject to some interpretation. Some believe that the outcome of the TCP/IP-OSI ‘war’ was largely the result of the fact that TCP/IP was deployed first and developed an early lead, which, through network effects, created a ‘bandwagon’ that OSI could not overcome.¹¹ Others have argued that TCP/IP was, in many ways, superior to the OSI model, so that its ‘victory’ reflected this superiority, not only TCP/IP’s head start.

The problem with the OSI protocol was that it was a technically driven revolutionary change to current practice, was highly complex, and required a great deal of expertise to implement cor­rectly. Additionally, reference implementations and test suites were lacking when initial deploy­ments were made, which caused severe interconnection problems. The IETF with its concept of ‘rough consensus, running code, and dual implementations’ provided a much simpler solution to the problem that could be implemented by all vendors. (Cargill, 2011)

Finally, some observers have emphasized the importance of the fact that TCP/IP had been incorporated into a number of versions of the popular Unix operating system. According to Hafner and Lyon, ‘When Sun included network software [which included the Berkeley version of Unix] as part of every machine it sold and didn’t charge sepa­rately for it, networking exploded’ (Hafner and Lyon, 1996, p, 250). Similarly, Mowery and Simcoe note:

The TCP/IP protocols became an integral part of [the implicit standard based on the Unix operating system], since the networking protocol was included in the 4.2 BSD version of Unix that was available at a nominal cost and was widely used in the academic research computing community. (Mowery and Simcoe, 2002, p. 1373; footnote omitted)

It should also be noted that even those who predicted the eventual success of OSI noted the problems that it faced in dislodging TCP/IP as an industry standard. For example, Cashin claimed that ‘[b]y the year 2000, the OSI model may be the only one supporting completely open processing requirements’ (Cashin, 1989).

Five years later (in 1994), Cashin’s view seems to have changed substantially. He noted that ‘While still largely unimplemented, OSI does have pockets of support. OSI adher­ents, however, rail about the lack of software supporting the model’ (Cashin and Frye, 1994).¹³ The following is a list of factors that Cashin and Frye identified as undermining OSI:

• Products were developed only after the standard was developed and, as a result, ‘No one detects errors in specification logic until long after the process begins’.

• ‘Standards committees try to solve almost every conceivable problem their members envision. Because many different committees... carried OSI standards development forward, delays became common’.

• There was ‘a lack of a migration path... migrating to OSI requires some interim steps due to its complexity and unique nature. For many of those who looked to TCP/IP as one of those interim steps, it became the final one’.

• ‘OSI’s lack of stability presented another obstacle... In view of OSI’s complexity, stability is a must if vendors are to build products’.

• ‘OSI products were too long in coming to market’.¹⁴

Although TCP/IP did not always work smoothly at first, and had to undergo a ‘shake­down’, that process took place via direct communications and collaborations among implementers without the need to propose changes to a standards organization before undertaking the needed technical work.

The United States government was a major player on both sides of the standards dispute. On the one hand, because DARPA had supported the development of the Internet and the TCP/IP protocols, these protocols were widely used within the scientific and research communities. On the other hand, in an attempt to standardize networking protocols for the Federal government, the National Institute of Standards and Technology (NIST) in the Department of Commerce succeeded in requiring all computer systems acquired by the Federal government to use the OSI protocol set (GOSIP).¹⁶ However, after considera­ble turmoil, this decision was reversed in 1995 through FIPS PUB 146-2, which provided ‘guidance for the acquisition and use of networking products implementing open, volun­tary standards such as those developed by the Internet Engineering Task Force (IETF), the International Telecommunication Union, Telecommunication Standardization Sector (ITU-T; formerly the Consultative Committee on International Telegraph and Telephone [CCITT]), and the International Organization for Standardization (ISO)’ (National Institute of Standards and Technology, 1995).

As Cerf noted recently:

As the new president of the Internet Society, I wrote to the US National Institutes of Standards and Technology in 1992, requesting that an evaluation be performed to determine whether TCP/ IP protocols could be an acceptable alternative to the OSI protocols that were, at that time, formally preferred by the U.S.

This effectively ensured the dominance of TCP/IP protocols in both government and private networks and established them as the dominant and de facto wide area network­ing standards.

The dominance of TCP/IP over DECNET and SNA/APPN can be largely explained by: (1) the increasing rejection of manufacturer-dominated, that is, proprietary, stand­ards; (2) the increasingly widespread demonstration of the benefits and ease of use of open standards; and (3) the failure of some major industry players to adapt to the new more decentralized environment.¹⁷

Many of the computing and networking industries before 1990 were dominated by a plethora of incompatible proprietary standards, symbolized by phrases such as ‘IBM compatible’. This led to charges that firms such as IBM and AT&T were able to extract monopoly rents from buyers by subjecting manufacturers of competing products to changes in specifications that limited their ability to compete. Although technological progress had led to the downsizing of information and communications technology (ICT) devices and a rapidly expanding market for such products, the existence of propri­etary standards continued to be seen as an impediment to competition and a number of actions had been taken by the US government to lower the barriers to entry that propri­etary standards had created.¹⁸

The creation of Interop in 1986 provided an important illustration of the benefits of the new open TCP/IP standards. Billed as a trade show, volunteers built a bare bones TCP/IP network in less than 48 hours and exhibitors were then invited to attach their TCP/IP-compatible devices to it and test and demonstrate the interoperability of their products. Attendance grew from 50 exhibitors and 5000 attendees in 1988 to 600 exhibi­tors and 70 000 attendees in 1993.¹⁹ These events, by demonstrating the benefits of open standards, gave a major impetus to their adoption.

Finally, the major computer manufacturer at the time, IBM, failed to make the shift to the newer, more distributed environment. As late as 1997, IBM described its APPN offering as ‘an open data networking architecture that is easy to use, has decentralized control with centralized network management, allows arbitrary topologies, has connec­tion flexibility and continuous operation, and requires no specialized communications hardware’ (IBM Corporation, 1997, p. x; emphasis added). Central management was seen as increasingly inappropriate for a network that depended for its growth and value on its becoming increasingly heterogeneous and public.²⁰

Finally, it is important to observe that, regardless of which standard eventually ‘won’, it was widely accepted that there would be only one standard, and thus a single Internet. That is, although different participants favored different standards, all preferred compat­ibility to incompatibility. Once it became clear that TCP/IP would ‘win’ the competition to become the standard, the use of competing standards for public networks effectively ceased.²¹

10.5