IBM's Computers Couldn't Talk to Each Other — Until One Standard Changed Everything

[00:00:03]In the spring of 1973, a computer at MIT sent a message to a computer at UCLA.

[00:00:11]This was not by itself remarkable. The two computers had been connected since 1969 through the ARPANET, the Defense Department's experimental network that linked research institutions across the United States and was by 1973 carrying a modest but growing volume of electronic mail, file transfers, and remote login sessions between its few dozen nodes.

[00:00:36]Computers at MIT and UCLA had been sending messages to each other for 4 years. What was remarkable was that the MIT computer and the UCLA computer were different machines running different operating systems speaking different network protocols built by different manufacturers to different specifications.

[00:00:57]The fact that they could communicate at all required a layer of translation software protocol conversion code maintained by the arponet's administrators and required to be updated every time a new type of machine joined the network. By 1973, this translation problem was becoming unmanageable. The Arpanet's designers had built a network that connected specific computers using specific protocols. Adding a new type of computer required new translation software.

[00:01:29]Adding a new network, a satellite network, a radio network, a different institution's local computer network, required rethinking the translation architecture from the ground up. The Defense Advanced Research Projects Agency, which funded the ARPANET, had a larger vision. Not a single network connecting a fixed set of machines, but an internet, a network of networks connecting any computer on any network to any other computer on any other network, regardless of what the computers were, what operating systems they ran, or what physical medium carried their signals. Two engineers working in a house in PaloAlto, California in the summer of 1973 wrote a paper that described how to build it. Their names were Vincent Surf and Bob Khan. Their paper described a protocol they called TCP, transmission control protocol, and the standard it eventually became TCP/IP is the reason that every computer, phone, television, and internet connected device in the world can communicate with every other 40 years after the paper was written. This is how two engineers sitting at a kitchen table solved the problem of computers that couldn't talk to each other and in doing so built the plumbing of the modern world. The networking problem that Surf and Khan were trying to solve in 1973 was not a simple technical limitation that better engineering within the existing framework could fix. It was a structural problem created by the way computing had developed. a proliferation of incompatible systems, each designed by people who had solved the problem in front of them without worrying about how their solution would interact with solutions being developed simultaneously by other people with different problems.

[00:03:26]This pattern, excellent local solutions that don't compose into a coherent global system, appears throughout the history of technology infrastructure.

[00:03:35]From railroad gauges to electrical voltages to the dozens of competing telephone standards that existed before AT&T's dominance imposed a single system. Computing in the early 1970s was in the middle of exactly this phase.

[00:03:51]Dozens of incompatible network protocols, each solving the communication problem for a specific set of computers in a specific institutional context with no mechanism to bridge between them. IBM's system network architecture SNA introduced in 1974 was the most sophisticated and most widely deployed proprietary networking system of the era. SNA allowed IBM computers to communicate with each other across long-d distanceance networks using a layered protocol architecture that IBM had spent years developing. It was technically capable, well documented, and thoroughly proprietary. SNA networks connected IBM computers to IBM computers. They did not connect to Digital Equipment Corporation's DeckNet networks, which connected DEEC computers to DEEC computers. They did not connect to the various incompatible networking systems that Honeywell, Control Data, and other mainframe manufacturers had developed for their own customer bases.

[00:04:55]a large corporation in 1973 that had purchased IBM computers for its financial operations and DEEC computers for its engineering operations. A common situation since different types of computers had different strengths had two separate computer networks that could not exchange data directly.

[00:05:14]Information that needed to move from the financial system to the engineering system was printed out on one end and typed in on the other or transferred on magnetic tape. physically carried from one computer room to another. The computers were powerful. The gap between them was a filing cabinet and a bicycle courier. The Arpanet had been designed with a specific elegant solution to the problem of connecting different computers. The interface message processor or IMP. Each computer site connected to the arponet received an IMP, a dedicated mini computer that handled the interface between the site's host computer and the arponet's network links. The IMP spoke the Arpanet's network protocol on one side and was specially programmed to speak the host computer's native protocol on the other side. This architecture worked and worked well for connecting a small number of specific computers to a single network. Its limitation was the cost of the translation layer. Each new type of host computer that wanted to connect to the arponet required new IMP software, new code to translate between the host's native protocol and the arponet's protocol. The arponet's network operations center in Cambridge, Massachusetts maintained this translation software, and as the variety of connected host computers grew, the maintenance burden grew with it. More fundamentally, the IMP architecture was designed for a single network. The ARPANET was the network. Everything connected to it through an IMP and the IMP handled the translation. If you wanted to connect a different network, a satellite communication network, a packet radio network, a European research network to the ARPANET, the IMP architecture provided no clean mechanism for doing so. you would need a different kind of gateway and nobody had designed one. Bob Khan had been thinking about this problem since before he arrived at DARPA. Khan had been one of the engineers at Bolt Baronic and Newman who had designed the IMPs. He had helped build the translation architecture that was now showing its limits. In 1972, DARPA had awarded contracts to develop a packet radio network, a system for communicating with vehicles in mobile field units using radio rather than wired connections, and a packet satellite network connecting research institutions across the Atlantic. Both would need to interconnect with the ARPANET. Neither was compatible with the existing IMP architecture. Bob Khan's specific insight which he brought to surf when they began collaborating in 1973 was that the problem required a different approach entirely. Instead of designing a translation layer between specific networks, you needed to design a protocol that could run over any network, a common language that computers on the arponet could speak, computers on the radio network could speak, and computers on the satellite network could speak without any of the underlying networks needing to know about each other. Vince Surf was an assistant professor of computer science at Stanford in the summer of 1973, 29 years old, working on networking research and deeply familiar with the ARPANET. He had been part of the graduate student group at UCLA that had received one of the first ARPANET connections in 1969.

[00:08:39]Bob Khan was a program manager at DARPA, the Defense Department's research agency, responsible for the packet radio and satellite networking programs that were making the interconnection problem urgent. The two of them spent several months in 1973 working through the design of what would become TCP. They met wherever they could. In Khan's hotel room when he was in town, at conferences, at Stanford, eventually in a house in PaloAlto, where Surf spent extended working sessions. The image of surf sketching protocol designs on a notepad in a lobby while Khan slept has been recounted in multiple histories of the internet. A mundane domestic detail that attaches the invention of the internet's foundational protocol to a specific locatable moment. The paper they produced, a protocol for packet network intercommunication published in ILE e transactions on communications in May 1974 is among the most consequential technical papers of the 20th century. It [snorts] is also by the standards of papers that change the world remarkably readable. It describes a design that is elegant without being obscure, practical without sacrificing generality.

[00:09:58]The core insight of surf and con's design was the concept of endtoend functionality.

[00:10:05]Previous networking architectures had embedded intelligence in the network itself. The network was responsible for ensuring that data arrived correctly, that packets were delivered in order, that errors were detected and corrected.

[00:10:19]This required the network's infrastructure to be sophisticated and to know about the requirements of the applications using it. Surf and Khan proposed inverting this. The network, whatever network, however the network worked, would be responsible for only one thing. Moving packets of data from one point to another on a best effort basis. If packets were lost, that was acceptable. If packets arrived out of order, that was acceptable. The network made no guarantees. The reliability that applications needed, the assurance that data had been received correctly and completely in the right order would be the responsibility of the end points.

[00:10:59]The software running on the source and destination computers would manage reliability, not the network between them. The network would be dumb. The endpoints would be smart. This principle, end toend design, had implications that Surf and Khan probably understood, but that were not fully apparent until the internet was built.

[00:11:20]It meant that any network, however different its physical characteristics, could carry TCP packets because the network only needed to provide the minimal service of moving packets. A network that could move packets could be part of the internet. The internet's architecture was therefore infinitely extensible. Any communication technology that could carry packets could be incorporated without redesigning anything at the core. The specific mechanism that TCP used to implement reliable communication over an unreliable network was at its core straightforward sequence numbers and acknowledgements. When a computer sent data using TCP, it divided the data into segments, assigned each segment a sequence number, and sent them. The receiving computer sent acknowledgements, acts, for each segment it received, indicating which sequence numbers had arrived. If a segment's acknowledgement didn't arrive within a timeout period, the sender retransmitted the segment. If segments arrived out of order, the receiver held them until the missing segments arrived, then delivered the complete data to the application in sequence. This mechanism required nothing from the network except the ability to move packets. The network could lose packets, reorder them, deliver them at varying delays. TCP's acknowledgement and retransmission mechanism would recover from all of these conditions transparently without the application needing to know that any of them had occurred. The IP layer internet protocol handled the routing problem. How to move a packet from its source through a series of intermediate nodes to its destination across networks of different types. IP assigned every computer on the internet a unique address. the IP address and required each intermediate node a gateway later called a router to forward each packet toward its destination based on the destination address. The intermediate nodes didn't need to know the full path.

[00:13:27]They only needed to know which direction to forward the next packet based on the destination address. The packet would find its own way. This distributed routing, no central coordinator, each router making local forwarding decisions meant that the internet had no single point of control and no single point of failure. If a router failed, packets would find alternative paths. If a network segment was congested, packets would be routed around it. The architecture was robust in the specific designed sense that its most critical function delivering packets continued in the face of component failures that would have disabled a more centralized system. The paper that Surf and Khan published in 1974 described a design, not a finished product. Turning the design into working code, testing it against real networks, and persuading the existing networking community, which had substantial investments in the protocols that already existed to adopt a new protocol required the bitter part of a decade. The development of TCP went through several iterations before the version now known as TCP IP emerged. The original TCP specification combined what are now separate functions. The reliable data transfer that TCP handles and the addressing and routing that IP handles in a single protocol. Separating them into TCP and IP which happened in the later 1970s was technically motivated.

[00:14:58]Some applications particularly realtime voice and video needed IP's addressing without TCP's reliability overhead.

[00:15:07]Separating the layers allowed different transport protocols, TCP for reliable delivery, UDP for unreliable but faster delivery to share the same network layer. The engineering work was distributed across multiple institutions and research groups who contributed implementations, tested them against each other, found incompatibilities, revised the specifications, and tested again. DARPA funded this work explicitly, recognizing that developing a standard required not just a design but working implementations that could be tested across the variety of networks and computers the protocol needed to support. The Unix operating system played a critical role in the TCPIP adoption process that is often overlooked in accounts focused on the protocol design itself. When DARPA funded the development of a TCPIP implementation for BSD Unix, the version of Unix developed at the University of California, Berkeley, and included that implementation in the BSD Unix distribution that was licensed to universities at minimal cost. TCPIP became available to every research institution running Unix. Researchers who needed networking capability installed BSD Unix and received TCPIP as part of the package. This distribution strategy, embedding the protocol in an operating system that was itself widely adopted, accomplished something that no amount of standardization committee work could have achieved. It put working TCPIP code into the hands of the researchers and programmers who would write the applications that ran on top of it.

[00:16:49]The transition that formalized TCPIP as the Arponet's official protocol had a specific memorable date, January 1st, 1983. Known in internet history as Flag Day. On January 1st, 1983, every host connected to the ARPANET was required to have switched from the older NCP network control program protocol to TCPIP.

[00:17:15]There was no transition period, no both protocols simultaneously interim state.

[00:17:21]The ARPANET's operators had set a deadline, communicated it months in advance, and on the deadline, the old protocol was turned off. The preparation for Flag Day had taken years. The ARPANET's network operations center had documented the requirements, provided implementation guides, and worked with each connected institution to ensure they had a working TCPIP implementation before the deadline. The flag day was not a surprise. It was a coordinated migration executed on a fixed date. The metaphor of flag day, a single sharp transition rather than a gradual migration, reflects something important about how protocol standardization actually works. Network protocols gain their value from universality. A protocol that everyone uses is enormously more valuable than a protocol that some people use because the value of a communication standard increases with the number of parties who can communicate using it. This means that transitions from one protocol to another are most efficient when they happen quickly and completely rather than slowly with a long period of coexistence that requires supporting both. The January 1st, 1983 flag day established TCPIP as the protocol of the ARPANET and by extension as the protocol of everything that would connect to the ARPANET in the years that followed. The internet in the sense of a network of networks using TCPIP began on January 1st, 1983. While TCPIP was being developed and deployed in the research network environment, the networking technology that most large American corporations used in the late 1970s and 1980s was IBM's SNA, Systems Network Architecture. and SNA was deliberately incompatible with TCPIP by design. IBM had introduced SNA in 1974, the same year that Surf and Khan published their TCP paper. SNA was IBM's comprehensive answer to the networking problem for IBM customers. a layered protocol architecture that defined how IBM computers would communicate with each other, how remote terminals would connect to IBM mainframes, and how IBM networks would be managed. It was designed to support IBM's business model, which depended on customers using IBM computers connected by IBM networking equipment managed by IBM software. SNA worked well for what it was designed for, large corporations with extensive IBM installations connecting IBM terminals to IBM mainframes over IBM leased lines. It supported the specific applications that IBM's corporate customers needed.

[00:20:12]Terminal to mainframe transactions, file transfers between IBM systems, remote job submission, and output retrieval. It was documented, supported, and maintained by IBM's formidable technical service organization. What SNA was not designed for was connecting IBM computers to nonIBBM computers were connecting IBM networks to other companies networks or operating in a world where the customers computing environment might include hardware from multiple vendors. These limitations were not oversightes. They were, from IBM's perspective, features. An IBM network that required IBM equipment to operate was an IBM network that kept customers buying IBM equipment.

[00:20:58]DEEC's DeckNet, Honeywell's distributed systems architecture and the networking protocols of other major computer manufacturers shared SNA's fundamental structure. Each was designed to connect the manufacturer's own computers to each other and each was incompatible with the others by default.

[00:21:18]The specific business problem that TCPIP solved for corporate customers, the problem that SNA and DeckNet and the other proprietary protocols could not solve, was the multi- vendor computing environment. By the early 1980s, most large corporations had computers from multiple vendors. Engineering departments used deck workstations and many computers. Business departments used IBM mainframes. Scientific computing departments used Cray supercomputers or specialized engineering workstations from companies like Apollo and Sun Microsystems. The graphics design department had Macintoshes. The emerging PC users had IBM PCs and compatibles. Each of these systems might have its own internal network. IBM connecting the IBM systems, DeckNet connecting the DEC systems, Apple Talk connecting the Macintoshes.

[00:22:13]But connecting the IBM systems to the DEX systems to the Macintoshes required either dedicated gateway computers that translated between protocols or a common protocol that all of them could speak.

[00:22:26]TCPIP which by the mid 1980s was available for virtually every computing platform. IBM mainframes, deck mini computers, Sun Workstations, Apple computers, IBM PCs was the common protocol. A corporation that adopted TCPIP as its internal network standard could connect its IBM computers to its Deck computers to its Sun Workstations to its Apple Macintoshes without protocol gateways and without requiring any single vendor's proprietary networking technology. This capability, multi- vendor connectivity through a vendorne neutral standard was TCPIP's decisive competitive advantage over the proprietary networking architectures.

[00:23:11]IBM's SNA connected IBM systems efficiently. TCPIP connected everything.

[00:23:18]A networking protocol is only as useful as the programming interface that allows applications to use it. A protocol that is technically elegant but requires complex specialized code to use will be adopted slowly because each application developer must master the complexity before building anything. A protocol that provides a simple consistent interface will be adopted quickly because application developers can use it without deep expertise in its internals. The Berkeley sockets interface developed at the University of California, Berkeley as part of the BSD Unix TCPIP implementation in the early 1980s became the de facto standard programming interface for TCPIP networking. Sockets presented network communication to application programmers as a filelike abstraction. You opened a socket, connected it to a destination address, and then read and wrote data to it using the same operations you used to read and write files. This abstraction, network communication as file IO, was not new. It reflected the Unix philosophy of treating everything as a file, and it made the learning curve for network programming remarkably gentle for programmers already familiar with Unix file operations.

[00:24:45]Writing a program that sent data across a network required learning perhaps a dozen socket functions, most of which were straightforward analoges to familiar file operations. The Berkeley sockets interface spread with BSD Unix through the research and university computing community and then spread further as other operating systems implemented compatible interfaces.

[00:25:10]Windows implemented a version called Windsock. Windows sockets. In the early 1990s, every operating system that needed to support TCPIP applications implemented a sockets interface because the socket model had become the standard that application developers wrote to. Every application that uses the internet, web browsers, email clients, file transfer programs, streaming video players, online games, messaging applications, uses the sockets interface or a higher level abstraction built on top of it.

[00:25:47]The programming model that Berkeley's developers designed in the early 1980s to make TCPIP accessible to application programmers is the programming model that still underlies internet application development today.

[00:26:02]The device that TCPIP required and that made the internet architecturally possible was the router, a dedicated computer whose job was to forward IP packets from one network to another based on the destination address, maintaining no state about individual connections and making forwarding decisions only based on the information in each packet's header. Early IP routing was performed by generalpurpose computers running routing software alongside their other functions. A Unix workstation connected to two networks would run routing software and forward packets between the networks as a secondary function while also performing its primary computational work. This approach worked at small scale and became impractical as networks grew and routing tables became larger and more dynamic. The dedicated router, a specialized device with no other function than forwarding packets as fast as possible, emerged in the early 1980s from multiple directions simultaneously.

[00:27:10]The most consequential of these was Stanford University's graduate students and researchers who were building routing software for the multi-et network environment of the research community. Len Bosac and Sandy Learner, a married couple who both worked in Stanford's computer operations, had been working on connecting the university's various departmental networks into a unified campus network. a challenge that required routers capable of connecting networks running different physical technologies while sharing a common TCPIP layer. The software they developed running on Stanford's computers could interconnect the campus's various networks and route packets between them.

[00:27:54]In 1984, unable to persuade Stanford to commercialize the technology, Bosac and Learner founded Cisco Systems in the house they were renting with credit card debt, three employees who were also personal friends, and the routing software that Bosac had largely written.

[00:28:13]Cisco's first product, the advanced gateway server, was a multi-protocol router that could connect networks running different protocols and forward packets between them. Cisco grew to a market capitalization of over $550 billion dollars at its peak in 2000, making it briefly the most valuable company in the world. A valuation built entirely on the hardware that moved TCPIP packets between networks. The router which TCPIP's architecture had defined as necessary and whose design TCPIP's principles had largely specified became one of the most valuable product categories in the history of the technology industry. TCPIP had been deployed across the research and university computing community through the 1980s with gradually growing momentum. By 1990, thousands of institutions worldwide were connected through TCPIP networks and the internet, the network of networks using TCPIP, was real, functional, and growing. It was also largely invisible to anyone outside the research computing community. The applications available on the internet in 1990, electronic mail, file transfer, remote login, were tools for technical users. They required command line interfaces, knowledge of internet addresses and protocol conventions, and access to a computer connected to the internet, which in 1990 meant either a university computer or a corporate research network. The internet was infrastructure for experts, not a medium for ordinary people. Tim Berners Lee changed this. Working at CERN, the European Particle Physics Laboratory in Geneva, Berners Lee developed the worldwide web, a system of hyperl documents accessible through a standard protocol and deployed the first web server and web browser on CERN's internal network in 1990. The protocol he designed, HTTP, Hypertext Transfer Protocol, ran over TCP IP. The addresses used to identify web documents, URLs, uniform resource locators, incorporated IP addresses or the domain names that resolved to IP addresses as a fundamental component. The web used TCPIP because TCPIP was the network protocol available on the Unix workstations that CERN's researchers used and that the research computing community more broadly used. Berners Lee wasn't making a strategic choice about networking protocols. He was using the infrastructure that already existed.

[00:30:56]When Mark Andreasen and Eric Bina released Mosaic, the first web browser with a graphical interface that made the web accessible to people who didn't know how to use a command line in February 1993. They released it for the Unix computers, Macintoshes, and Windows PCs that their target users already had. All of those platforms had TCPIP networking software available. The web browser worked on any internet connected computer because TCPIP worked on any internet connected computer. The consumer internet that emerged through the mid 1990s, the commercial internet service providers, the early websites, the ecommerce that began with companies like Amazon and eBay, the online services that AOL provided through dialup connections, all of it ran over TCPIP, not because anyone had made a strategic decision that TCPIP would be the protocol of the commercial internet, but because TCPIP was the protocol of the research internet from which the commercial internet grew and changing it would have required the entire installed base of internet infrastructure to be replaced simultaneously.

[00:32:08]The commercial emergence of the internet in the mid 1990s provoked a significant competitive response from companies that had built proprietary networking systems because the internet's growth was eroding the market for those systems.

[00:32:22]IBM responded to the internet's emergence with a combination of internet adoption and continued investment in SNA, eventually developing gateway software that allowed SNA networks to connect to TCPIP networks. The gateway approach worked technically and was commercially unsuccessful because organizations that were building new networks chose TCPIP and organizations that already had SNA networks gradually migrated to TCPIP as their IBM computers aged out of service. The most aggressive proprietary challenge to TCPIP came from Apple's Apple Talk and Novel's IPX SPX protocols that were widely deployed in corporate local area networks through the late 1980s and early 1990s and that competed with TCPIP for the corporate networking market. Apple Talk was designed to be simple to set up.

[00:33:20]Macintoshes connected to Apple Talk networks automatically without requiring manual configuration and advantage over TCP IP's more complex setup requirements in the early 1990s.

[00:33:33]IPXSPX novel's protocol was the networking layer for Netware novel's network operating system that dominated corporate file and print sharing through the late 1980s and early 1990s. Both lost. The reasons varied in detail, but shared a common structure. TCPIP's universality was more valuable than either protocols specific advantages.

[00:33:58]Apple talk worked beautifully in all Mac environments and poorly in mixed environments. IPX spx connected novel clients to novel servers efficiently and required protocol gateways to connect to anything else. As internet connectivity became a requirement for corporate networks rather than an optional feature, organizations with Apple talk or IPX spx networks needed to add TCP IP anyway. And once they had TCP IP for internet access, the reason to maintain a separate protocol for internal networking became harder and harder to justify. Apple deprecated Apple Talk in OSX 10.6 in 2009. Novel was acquired by attachment in 2011. TCPIP had over approximately 15 years displaced every significant competitive protocol in corporate networking. Vince Surf and Bob Khan made a decision about the protocol they had designed that distinguished them from almost every other significant technological inventor of the 20th century. They didn't patent it. TCPIP was developed with DARPA funding which created a specific legal context. Work done under government contract with the government retaining certain rights. But the decision not to pursue patents on the protocol design went beyond the legal requirements. Surf and Khan both understood that TCPIP's value derived from its universal adoption and that universal adoption required that no single company or individual could charge access fees for using the protocol. A patented TCPIP licensed for royalties would have fragmented the internet. Companies that couldn't afford the license fees or found the license terms unacceptable would have developed alternative protocols. The network of networks that TCPIP made possible depended on everyone using TCPIP, which depended on no one owning TCPIP in a way that made using it conditional on paying someone. This decision, intentional or forced by circumstance, and probably some mixture of both, meant that Surf and Khan received none of the direct financial benefit from the technology they had designed. While the companies that built products using TCPIP, Cisco, Microsoft, Apple, Google, and every other technology company that operates on the internet, collected trillions of dollars in value. Surf joined MCI's internet development division after leaving Stanford and later joined Google where he holds the title of chief internet evangelist.

[00:36:46]Khan founded the Corporation for National Research Initiatives, a nonprofit research organization, and remained involved in internet governance and research through his career.

[00:36:57]Both received the Presidential Medal of Freedom in 2005, the ACM Touring Award in 2004, and numerous other honors for work that is now so fundamental to global communication that imagining the alternative requires more imagination than most people want to apply. Neither became wealthy from the invention the way that the founders of companies who built on their work became wealthy. This outcome is consistent with how foundational infrastructure works. The people who build the plumbing don't collect the rent from the buildings connected to it. Today, the internet carries an estimated five quintilion bytes of data per day. Every bite of that data travels in packets formatted according to the IP specification. Every reliable connection, web browsing, email, file transfer, encrypted communications uses TCP. Every realtime connection where speed matters more than reliability, video streaming, voice over IP, online gaming, uses UDP, the alternative transport protocol that shares IP with TCP.

[00:38:06]Every device connected to the internet has an IP address or shares one through network address translation that identifies it to the routing infrastructure. The IP address space, the range of addresses available for internet connected devices was a design decision that surf and con made in 1974 that turned out to be consequentially wrong in a specific way. IPv4, the address format used in the original TCP IP specification, allocated four bytes, 32 bits, to each address, providing approximately 4.3 billion possible addresses. In 1974, 4.3 billion addresses seemed impossibly large. The entire ARPANET had fewer than 100 connected computers. By the late 1990s, with the internet growing faster than anyone had predicted, 4.3 billion addresses were clearly insufficient for a world where every phone, every car, every household appliance might eventually need an internet address.

[00:39:09]IPv6, the successor protocol that expands the address space to 128 bits and provides enough addresses to give every atom on Earth its own internet address, was standardized in 1998.

[00:39:22]The transition from IPv4 to IPv6 has been underway for more than 25 years and is by the standards of protocol transitions slow. A reflection of the massive installed base of IPv4 infrastructure and software that changing requires either replacing or upgrading. The difficulty of the IPv4 to IPv6 transition illustrates the specific permanent nature of the decisions that protocol designers make. TCPIP's end-to-end architecture, its separation of network and transport layers, its distributed routing model. These decisions made at a kitchen table in PaloAlto in 1973 are so deeply embedded in the internet's infrastructure that changing them would require rebuilding the infrastructure from the foundation.

[00:40:12]They won't be changed. They have proven over 50 years to be the right decisions.

[00:40:17]The internet's fundamental architecture has accommodated wireless networks that didn't exist when it was designed.

[00:40:24]Satellite internet with latencies that early TCP IP implementations couldn't handle well. Optical fiber carrying data at speeds that made 1970s network speeds look geological. All of it runs on TCP IP. The telephone network that AT&T built over a century connected people who had telephones to each other through circuits that AT&T managed and controlled. The internet that TCPIP made possible connected computers and through computers people in a way that no central authority controlled because TCPIP's design deliberately excluded central control. This difference, the telephone network as a managed service and the internet as an unmanaged comments produced consequences that neither its designers nor its early users anticipated fully. The absence of central control meant that new applications could be built and deployed without anyone's permission. Electronic mail didn't require AT&T's approval. The worldwide web didn't require FCC licensing. Amazon didn't need to ask Cisco for permission to sell books over the internet. Google didn't need to ask IBM whether building a search engine was acceptable. This openness, the ability to build new services on top of TCPIP without negotiating with the network's owner because the network had no owner, is what made the internet the most significant platform for economic and social activity in human history. The value created by the companies and services built on TCPIP estimated in tens of trillions of dollars spanning every sector of the economy was created in an environment where the infrastructure was available to anyone and the right to build on it required no permission. IBM's proprietary networks, DEEC's proprietary networks, the telephone company's circuit switched networks. These were valuable infrastructure that generated significant revenue for their owners while constraining what could be built on them. TCPIP generated no revenue for its creators and made possible the most explosive creation of economic value in technological history. The two men who designed it got the presidential medal of freedom and their names in textbooks.

[00:42:48]The companies that built on what they designed got the trillion dollar market capitalizations.

[00:42:54]This is perhaps how foundational infrastructure should work. Or perhaps it isn't. The question doesn't have a clean answer, and the people who built the internet's foundation don't seem to have spent much time on it. What they built works. That appears to have been the