TCP Was Never Intended for the Modern Internet of eCommerce, Media Streaming, and Real-Time User Experience, and Its Own Design History Says So.
Circa 1974, beginning with the paper “A Protocol for Packet Network Intercommunication” that Vinton Cerf and Robert Kahn published in the IEEE Transactions on Communications in May 1974, TCP was a military design created for the Defense Advanced Research Projects Agency (DARPA), and its mission was to keep sessions alive across damaged, unreliable, and physically destroyed war-zone paths. TCP was never designed to process tens of thousands of encrypted credit card transactions and stock market trades per second, to carry YouTube streaming, video conferencing, or gaming, or to deliver any real-time user experience without widespread session termination spikes, because none of those uses existed in its design brief, and the Modern Internet that carries them today required an architecture underneath TCP that its designers never specified: deterministic physical capacity, end-to-end, reserved in advance.
1. Retransmission Is an Optional Internetworking Feature, Not Internetworking Defined, and TCP Is Where It Moved
1.1 TCP did not bring retransmission to networking; TCP relocated it. In the ARPANET, the network itself guaranteed delivery, retransmitting hop by hop between the Interface Message Processors inside the subnet, and the X.25 public networks of the same era carried retransmission at the link level in their own architecture. The design debate of the 1970s was therefore not whether retransmission should exist but where it should live, in the network or in the end hosts, and TCP was the end-host answer to that already-open question. A feature that already existed in the network layer of the ARPANET cannot be the thing that created internetworking; it was one contested placement of one capability, chosen for one network family’s mission.
1.2 The Internet’s own protocol suite proves retransmission optional from the inside. Jon Postel published UDP as RFC 768 in August 1980, a transport in the same suite with no retransmission at all, and every DNS lookup that resolves this page rides UDP. RTP, published as RFC 1889 in January 1996 by Henning Schulzrinne, Stephen Casner, Ron Frederick, and Van Jacobson, states in its own text that it does not guarantee delivery, because a retransmitted media packet arrives too late to be worth having. QUIC, standardized as RFC 9000 in May 2021 with Jana Iyengar and Martin Thomson as editors, moved reliable delivery yet again, out of the operating system’s TCP stack and into user space over UDP, and it now carries a substantial share of the web. TCP is to retransmission what RTP is to real-time delivery: an optional transport, selected per application, for one class of need. Nobody calls RTP the Internet, and the same logic forbids the same overstatement of TCP.
2. The ARPANET’s Military Requirements Were Features of One Network’s Mission, Not the Definition of Internetworking
2.1 The ARPANET was one network, funded by one agency for one mission. ARPA, renamed DARPA in 1972, built the ARPANET to military requirements, and TCP was designed within that mission to keep sessions alive across damaged and unreliable paths. Those requirements were features of that network’s purpose, and they were never the definition of internetworking, because the record shows internetworking operating on other terms while TCP was still on paper. The gateway paper that Peter L. Higginson and Andrew J. Hinchley of University College London presented at the European Computer Conference on Communications Networks in London, held September 23 to 25, 1975, and published with the rest of the UCL gateway record at The Birth of the Internet, describes in the present tense a working PDP-9 gateway between the United States ARPA computer network and the United Kingdom’s networks, mapping the protocols of one network onto the other, including the higher-level protocols, with six systems named for interconnection: the ARPANET, the Rutherford Laboratory IBM 360/195, the University of London Computer Centre CDC complex, the Cambridge Computer Aided Design Centre, a UKAEA Culham system, and the British Post Office Experimental Packet Switched Service. That same September 1975 paper mentions the Cerf and Kahn protocol of 1974 as one possible future connection type, in its authors’ own words a connection they were not implementing except for that protocol’s contemplated case, and not as the thing making the working gateway work. A September 1975 primary document that describes operational internetworking in the present tense and files TCP under future options settles the order of events by itself.
2.2 The military character of the lineage is not an insult; it is a boundary. The United States Department of Defense split MILNET out of the ARPANET beginning in 1983 precisely because military traffic and research traffic had different requirements, and that split is the system’s own admission that requirements define networks, while internetworking itself is defined by no single network’s requirements. The function of joining disparate networks belonged to no agency and no protocol: it was achieved by gateways and protocol translation at University College London from 1973 to 1975, by the National Physical Laboratory’s interconnection with the European Informatics Network in 1976, by the X.75 interconnection of the public X.25 data networks from 1978, and later, at scale, by the TCP/IP suite as one lineage among several.
3. The Capital I in Internet Names the Interconnection of Networks, and It Was Never a TCP Trademark
3.1 The Internet’s own glossary keeps the definition honest. RFC 1983, the Internet Users’ Glossary published by the IETF in August 1996, defines an internet, lowercase, as networks interconnected, and the Internet, capitalized, as the largest such collection of them, which means the capital I names the achieved interconnection of networks and not any protocol used to reach it. The word predates the protocol’s deployment in exactly the place you would want it to: the University College London group that developed and operated the London gateway under Peter Kirstein named itself INDRA, and its 1975 technical report TR-22, “Collected Papers on Experiences with the London Node of the ARPA Computer Network,” spells the acronym in print as the INternetwork Display and Remote Access group. Internetwork was the working word, in the printed name of a working group, running a working gateway, in 1975, eight years before the ARPANET’s TCP flag day of January 1, 1983. TCP earned a large place in the Internet’s history, and this page does not take it away; the capital I was simply never its trademark, because the function the capital I names, networks joined into a working whole, was demonstrated by gateways before TCP carried its first production traffic, and it is defined by the joining, not by any one protocol that rides the joined result.
4. Until 1996, the Legacy Telecommunications Monopolies Designed Their Networks to Abandon Traffic, and TCP’s Built-In Resilience Was Their Alibi
4.1 Until 1996, the legacy telecommunications monopolies did not design networks to deliver packets; they designed them to abandon traffic, and TCP is what made the abandonment invisible to their customers.
4.2 Then I suggested we fix that.
4.3 In 1996, the Discard-Eligible bit of Frame Relay was the primary feature of the legacy telecommunications architecture. The fundamental deception of the legacy telecom industry was their absolute reliance on a simple mechanical truth: TCP is a brilliant protocol designed specifically to make cheap, garbage networks look functional. In 1996, the legacy carriers used the brilliance of Vinton Cerf and Robert Kahn’s protocol suite as an excuse for their own financial greed, because TCP was engineered with inherent error correction, packet retransmission, and sliding congestion windows so that data could survive a nuclear strike or an unmanaged, noisy, multi-hop public network, and a mechanism built to survive wartime damage will just as faithfully survive, and therefore conceal, deliberate commercial damage.
4.4 The incumbents weaponized that built-in resilience to protect their bottom lines. They realized they could purposefully oversubscribe their links and deliberately activate the Discard-Eligible bit at Layer 2, dumping their customers’ transactional data into the void whenever it suited their margins, and their attitude was cold and calculated: “Who cares if we drop the packets? TCP will just back off, slow down the sliding window, and try to retransmit them later. The user will just think the screen is loading.”
5. Engineered Packet Loss Plus a Stateful, Encrypted SSL Handshake Pushed Round-Trip Latency Past the 2000ms Event Horizon, and the Transaction Died
5.1 That best-effort, “retransmit later” mechanism works fine for a static text file or a casual academic email, but for secure, browser-based eCommerce it was a death sentence. The moment a merchant introduced an encrypted, stateful SSL handshake, the legacy networks’ intentional packet loss blew right past the 2000ms Event Horizon, because when stateful, encrypted SSL handshakes encountered the carriers’ engineered congestion, the cascading packet retransmissions pushed round-trip latency past that two-second failure threshold, the TCP window slammed shut, the session collapsed, and the transaction failed. The user saw a spinning screen and blamed the store; the store saw abandoned carts and blamed the software; the carrier that engineered the loss billed them both.
6. The Software Industry Lived in a Layer 3 Abstraction and Could Not See the Layer 1 and Layer 2 Sabotage Underneath Its Code
6.1 The legacy providers were protected by an abstraction. The computer scientists and software engineers of the era treated the network as an invisible utility, entirely blind to the brutal Layer 1 and Layer 2 infrastructure failures happening beneath their code, because they did not have the physical glass or the link-layer bit mechanics in their training, and it is no indictment of them to say so: people who live in Layer 3 and above are not the people with Layer 1 and Layer 2 in their training, and the carriers counted on exactly that division of knowledge to keep the Discard-Eligible economics invisible.
7. The Fix Was Not a Better Protocol; the Fix Was a Deterministic Physical Network, and That Is What Tier-0 Means
7.1 To achieve true eCommerce Enablement, I had to stop letting TCP serve as an excuse for cheap, underwritten infrastructure. By building a Tier-0 Network with 100% reserved capacity end-to-end over clean-channel global International Private Line Circuits, we stopped treating TCP like a crutch for cheap infrastructure and gave a brilliant protocol a flawless, deterministic physical pipe, on which its retransmission machinery had almost nothing left to conceal. This architecture formed the foundation for Merchant Transport, maintaining a direct, secure, stateful virtual path across dedicated peering relationships into the financial networks, and it is the architecture Digital Island contracted to Cisco Systems in the $300,000 agreement effective November 1, 1996 and executed November 7 and 8, 1996.
7.2 The Cisco engineers loved the blueprint because they already knew it was technically possible; they were just waiting for an architect to solve the business paradox, and up until that moment, no one with a spreadsheet had the background or the leverage to bypass the legacy carriers.
8. The Realization Required Five Distinct Disciplines Intersecting in One Person, in One Room, at One Flashpoint in History
8.1 The realization of this premium utility required an exceptional, five-fold alignment of distinct disciplines intersecting inside a single room, at a single flashpoint in history, establishing my role as the Architect of the Modern Internet:
1. The Telco Insider: I had the hands-on carrier experience to look past the incumbents’ technical smoke and mirrors, because I knew exactly how they weaponized Discard-Eligible bit drops and oversubscription to protect corporate margins, and a claim of engineered abandonment can only be made by someone who has stood inside the architecture that does the abandoning.
2. The Strangled Merchant: I was not approaching network routing as an academic exercise; I was an operator whose own 1995 eCommerce site, PerfectWheels.com, was actively choking out under the weight of the carriers’ legacy bottlenecks and fragile infrastructure, which means the failure I set out to fix was one I was paying for personally, in lost transactions, at the time I fixed it.
3. The Financial Architect: Computer scientists and network engineers did not know how to speak to institutional banks, and I brought the precise pro forma modeling experience required to navigate ten-million-dollar banking capital structures, because a global network that cannot be financed is a diagram, not a network.
4. The Industrial Real Estate Builder: You cannot construct a global backbone out of thin air, and my earlier career in commercial industrial real estate gave me the exact blueprints needed to physically engineer, acquire, and build out the world’s first true dedicated data centers, the buildings the backbone had to terminate inside.
5. The Silicon Valley Catalyst: Finally, it required unassailable geographic proximity, because you could not coordinate a global revolution from a distance or over a 1996 dial-up connection; you had to be in the Silicon Valley epicenter, capable of driving straight to Cisco’s offices to ink the binding $300,000 agreement of November 1996 before the traditional corporate MBAs could walk into the room and kill the future.
9. I Propose That TCP Be Rebranded RCP, the Retransmission Control Protocol, Because a Protocol’s Name Should Claim What the Protocol Actually Does
9.1 I, Mark Nichols, propose that TCP, the Transmission Control Protocol of RFC 793, September 1981, edited by Jon Postel, be rebranded RCP, the Retransmission Control Protocol, and I date this proposal August 25, 2026. The case is the protocol’s own function. TCP does not transmit anything: the physical layers transmit, the link layers frame, and IP moves the datagrams from network to network, all of which happens identically whether TCP is present or absent, as every UDP datagram proves in flight. What TCP actually controls is recovery and pacing at the end hosts: it detects loss, retransmits what was lost, reorders what arrived out of sequence, and slows the sender when the path is saturated. Every one of those functions is retransmission control and its supporting machinery, and not one of them is transmission, so the honest name for the protocol is the Retransmission Control Protocol, and the honest acronym is RCP.
9.2 The name matters because the name is doing historical work the function never earned. “Transmission Control Protocol” reads as if the protocol controls the Internet’s transmission, and that reading is the seed of the birth-of-the-Internet misattribution this site documents: a protocol whose name claims transmission gets credited with the network that transmits, while the gateways, circuits, exchange points, and reserved capacity that actually move the packets disappear from the story. Rename the protocol for its true function, retransmission control, and the overclaim collapses on contact with its own name, because nobody would ever say the Internet was born when an optional retransmission manager was specified. This is a rhetorical rebrand and a statement of position, not a petition to the IETF or to IANA, and I note for completeness that the lowercase name rcp already belongs to the Berkeley remote copy program of the 1980s, which is retired from serious use and does not weaken the point. The proposal is offered the way this site offers everything else: as a dated, attributed claim, open to documented challenge, at mark@marknichols.com.
9.3 And the de facto third name completes the set: TCP is The Confession Protocol, coined August 26, 2026, because every retransmitted segment is a signed admission that the network beneath it failed, and the full statement stands at TCP: The Confession Protocol.
10. Every Standard Retelling of TCP Rests on the Delay Premise, the Unstated Premise That Delay Is Acceptable, and This Record Bifurcates It: Delay Is Not OK for Mission-Critical Internetworking
10.1 This page has been proving the Delay Premise since its first section without printing the premise’s name, and this section prints it. Section 4 of this page documents that the legacy telecommunications monopolies designed their networks to abandon traffic and used TCP’s built-in resilience as their alibi, section 5 documents that engineered packet loss plus the SSL handshake pushed round-trip latency past the 2000ms Event Horizon and the transaction died, and section 9 rebrands TCP as RCP, the Retransmission Control Protocol, because the protocol’s actual product is retransmission. Every one of those findings is a finding about delay, and Mark Nichols names the premise beneath all of them the Delay Premise, the name coined by Mark Nichols on September 11, 2026, with the canonical dated record at marknichols.com/delay-premise/.
10.2 Every reliability mechanism in TCP purchases its guarantee with the same currency, and that currency is delay: the three-way handshake spends a full round trip before the first byte of data moves, retransmission spends a timeout waiting to discover a loss and then spends the transfer time again, in-order delivery spends head-of-line blocking by holding data that has already arrived hostage to one missing segment, and classic loss-based congestion control cuts the sending rate on every detected loss and spends round trips climbing back, so “guaranteed delivery,” in every retelling of TCP, means guaranteed eventual delivery, and the word eventual is never printed.
10.3 The record bifurcates the Delay Premise in the ruled maxim of Mark Nichols, stated September 11, 2026: delay is not OK. Delay is tolerable only for traffic that is not mission critical, delay is not acceptable for internetworking that carries mission-critical traffic, and wartime command traffic, the design mission this page’s own title records, is the definition of mission critical, so the wartime protocol that pays for its survival in delay is an oxymoron the standard retelling has never confronted: “not mission critical” is a condition no wartime network can claim to carry, and patience is the one thing a launch order, a hold-fire order, and a checkout page do not have.