The Birth of the Internet

Spoiler Alert: The Internet is conceptual. It is a network of networks implemented through physical infrastructure and operated by independent organizations that choose protocol methodologies according to their intended applications and requirements. My explanation of why The Internet Is a Network of Networks, Not a Protocol.

1. The Myth of Conceptual Necessity (The NSFNET Intervention)

“The Internet Protocols” are not required for internetworking. Their historical dominance was not simply the result of preordained architecture, market selection, or technical inevitability. NSF networking policy, including decisions associated with Dennis Jennings and the development of NSFNET, played a significant role in establishing TCP/IP as the dominant protocol methodology. Historical dominance, however, does not establish conceptual necessity, practical necessity, or universal legal necessity. Nor does the role of a government agency in establishing or promoting a particular protocol methodology transform that methodology into a prerequisite for interconnecting networks.

TCP/IP is one protocol methodology that became historically significant for ARPANET and subsequently for the interoperability of heterogeneous networks. Its adoption and dominance do not make TCP/IP a prerequisite for internetworking itself, nor do they eliminate the category of alternative internetworking methodologies.

The naming convention “The Internet Protocols” should therefore be discontinued and replaced with more accurate terminology.

2. Rebranding the Methodologies: Meet DRP and ALP

TCP does not control the network. It never did.

TCP operates at the endpoints of a connection. It does not operate the routers, switches, circuits, transmission facilities, routing infrastructure, or interconnection between autonomous networks. It cannot prevent a packet from being dropped, cannot repair a failed link, cannot establish a physical path, and cannot compel another network to deliver a packet.

TCP controls aspects of transport behavior between endpoints. It does not control the transmission infrastructure through which those endpoints communicate.

That distinction matters. The name Transmission Control Protocol can easily be mistaken as describing control of transmission itself. It does not. TCP controls a set of transport mechanisms implemented at the communicating endpoints.

To better characterize TCP’s function, TCP can be described, for purposes of illustration, as a “Degradation Retransmission Protocol” (DRP). TCP provides endpoint transport mechanisms including retransmission, sequencing, acknowledgments, flow control, congestion control, and connection management. TCP does not control the network over which its packets travel. It never has. TCP does not build the links, route the packets, operate the switches, operate the routers, or guarantee that the underlying network will deliver anything. TCP is an endpoint methodology responding to network conditions, not the network itself.

IP can likewise be characterized as an “Address Label Protocol” (ALP), reflecting its role in identifying and addressing packets for internetwork delivery. The naming convention of the “Internet” protocol is overreaching.

These names are intentionally provocative. The point is not that the established names TCP and IP should literally be replaced. The point is that TCP and IP are methodologies with defined functions. They are not the Internet.

IP is not conceptually required for internetworking. TCP is not conceptually required for internetworking. TCP/IP is not conceptually required for internetworking.

Before anyone cries “foul,” let me make this clear. “The Internet” is not a protocol and it is not a singular physical object. Uppercase Internet and lowercase internet describe different uses of the same underlying concept: interconnected networks and the systems through which those networks communicate.

The capital-I “Internet” underwent a historical narrowing of reference. A generic term for an internetwork came to designate the particular internetwork that emerged from the ARPANET/DARPA lineage and subsequently expanded through NSFNET and commercial interconnection. That semantic evolution should not be confused with a technical definition of the Internet as ARPANET, TCP/IP, or any particular physical network.

The capitalization itself was historically useful because Internet distinguished the particular internetwork from an internet as a generic collection of interconnected networks. RFC 1983 makes exactly that distinction while calling the Internet “a multiprotocol internet.”

3. Deconstructing the Archive: What RFC 1122 and 1983 Actually Say

This is not merely semantics invented for this website. The IETF itself stated in RFC 1122:

“The Internet is a network of networks.”

The same RFC states that a host’s connection to the Internet is “only conceptual.” RFC 1122 is therefore useful here because it distinguishes the conceptual Internet from the network to which an individual host is physically connected.

What About RFC 1983?

Any claim that RFC 1983 establishes TCP/IP as synonymous with the Internet is unsupported by the text of RFC 1983.

RFC 1983, Internet Users’ Glossary, is an Informational RFC. Its own Status of This Memo says that it “does not specify an Internet standard of any kind.” It defines internet as a collection of networks interconnected with routers, then defines Internet, with a capital “I,” as the largest internet in the world. Most importantly, it describes the Internet as “a multiprotocol internet.”

Read that carefully.

RFC 1983 does not define the Internet as TCP/IP.

It establishes a naming convention for distinguishing one particular internet from other internets. The capital “I” identifies a particular internetwork. It does not transform an internetwork into a protocol.

In fact, the phrase “a multiprotocol internet” makes the distinction particularly clear. If Internet were synonymous with one protocol suite, describing the Internet as multiprotocol would make little logical sense.

RFC 1983 separately defines Internet Protocol (IP) as the network-layer protocol of the TCP/IP Protocol Suite. The RFC therefore distinguishes the Internet from the Internet Protocol.

So if RFC 1983 is offered as proof that TCP/IP is synonymous with the Internet, the citation fails to establish the proposition.

The Internet is a network of networks. TCP/IP is a protocol methodology used by that network of networks.

TCP/IP became historically dominant. Historical dominance does not establish conceptual necessity.

An internetwork can be constructed using other protocol methodologies. Therefore, TCP/IP is not foundational to the concept of internetworking merely because it became foundational to the particular internetwork that came to be called the Internet.

If you are reading this website, you most likely already understand this. If you do not understand this distinction, you should probably understand it before offering an opinion about what constitutes an Internet or what is required for internetworking.

4. Two Protocols, Two Jobs, Two Different Places: One an Address Label, the Other Optional

From these two protocols came the historical attribution that Robert E. Kahn and Vinton G. Cerf were the “Fathers of the Internet.” Celebrated, repeated, and manifested. Thank you, and chapeau!

The Internet Protocol, IP, specified in RFC 791 in September 1981, is a network-layer protocol whose packet header carries source and destination addressing information. It provides datagram delivery semantics, but makes no delivery guarantee and carries no reliability mechanism of its own.

The Transmission Control Protocol, TCP, specified in RFC 793 in September 1981, is bookkeeping between the two computers at the ends of a connection: it numbers the bytes, waits for acknowledgments, and resends what the network loses. It runs only in those two end machines.

The routers and switches that move traffic between networks do not operate on the TCP layer to make routing decisions, and they never have.

5. The Address Label and the Return Receipt

Here is the analogy the home page promised.

IP is the address label: it names where the parcel should go. Labels do not deliver.

TCP is the return-receipt request the sender staples on: tell me it arrived, and if I hear nothing, I will mail another copy.

The receipt slip has no guarantee behind it. It does not make the truck come, does not fix the road, and does not know why the parcel vanished. It just mails another copy, at longer and longer intervals, into the same conditions that lost the first one.

The trucks, the buildings, the sorters, the routes, the clerks, and the liability, everything a shipper would call the delivery system, are the physical networks: the fiber, the switches, the carriers, the capital, and the operators.

The address label is not the USPS.

6. The Postmen, Not the Post Office

Robert E. Kahn and Vinton G. Cerf published their foundational internetworking protocol proposal in A Protocol for Packet Network Intercommunication, IEEE Transactions on Communications, May 1974. The first detailed TCP specification followed in December 1974 as RFC 675, authored by Vinton Cerf, Yogen Dalal, and Carl Sunshine.

Stationery vs. Facilities: The Postal Analogy

That work was real, foundational, and fully credited here. Shared formats are necessary, and a common addressing convention is essential to any postal system.

But the two men designed stationery, not facilities.

No buildings. No fleet. No routes. No liability when the parcel is lost.

They were the postmen of the story, not the post office, and that distinction is the whole point of this page.

Nobody calls the postman the father of overnight delivery.