Robert Kahn’s and Vint Cerf’s TCP Is Ignorant About Its Own Host’s Failures - Who’s Stupid Now?: Disagreements | Network, Not Protocol
Cerf Called the Network Stupid. Their Own Paper Describes TCP-Enabled Hosts Throwing Away Delivered Packets Because of Endpoint Resource and Processing Limitations.
The network delivered the packet. The receiving host could not accommodate it. Having TCP did not prevent the discard. Sending again does not establish that the underlying problem was diagnosed or repaired.
Preamble: I examined the May 1974 paper by Vinton G. Cerf and Robert E. Kahn, A Protocol for Packet Network Intercommunication, alongside Cerf’s later descriptions of a “stupid” network. This page places those descriptions beside the transportation their proposal presumes and the endpoint limitations it expressly accommodates. Networks can protect transportation without interpreting application content. TCP-enabled hosts can discard delivered packets because they lack resources or cannot place the data into the intended process’s buffer. Recovery mechanisms may help complete an exchange, but their usefulness does not establish that they identify or remove its underlying failure. This page records the primary passages, answers the counterarguments, and examines a supplied Google AI exchange that attempted to refute the finding. The household example is illustrative, and its exclamation is satire.
Opinion Rules: You are visiting my record, and I am the subject matter expert on it. If you are a subject matter expert too, I want to hear from you: bring your document and I will answer it on the record. If you are not, you are welcome here to read and to learn. The documented-challenge terms of marknichols.com and the condition on opinion are stated at F40 of The Governing Definitions and Controlling Facts of Telecommunications Internetworking, and they govern this page.
0.0 The distinction this page establishes
0.1 A network does not need to interpret an application’s meaning to engineer its transportation.
0.2 A host can interpret application data while lacking the resources to accommodate its arrival.
0.3 “Ignorant” in the title identifies a diagnostic limitation: retransmission alone does not establish which component caused a missing acknowledgment. It does not mean TCP has no useful information or control mechanisms.
0.4 Endpoint failure here includes failure to accommodate a particular arrival. The computer need not crash. Exhausted buffers, an unavailable process, or changed acceptance conditions can prevent successful handling.
0.5 The primary source is Cerf and Kahn’s May 1974 paper, published in IEEE Transactions on Communications, pages 637 through 648. Its proposed transmission control program predates the later separation of TCP and IP.
1.0 Cerf repeatedly used the stupid-network description
1.1 U.S. Senate, February 7, 2006. Cerf stated:
“The core of the network was fairly ‘stupid,’ actually; it just moved packets back and forth, like little electronic postcards.”
Location: Net Neutrality, Senate Hearing 109-605, printed page 7. Immediately before this statement, Cerf places most intelligence at the edges, where applications were implemented. www.govinfo.gov
1.2 KU Leuven, May 16, 2012. The university’s report attributes “stupid network” to Cerf and presents that characteristic as the Internet’s greatest strength.
Location: The section headed Stupid network, in the report last updated May 21, 2012. This is the event host’s account, not a complete verbatim transcript. nieuws.kuleuven.be
1.3 Internet Governance Forum, November 13, 2015. The caption transcript records Cerf using “stupid network” while explaining independence from application content and underlying transmission technologies.
Location: Cerf’s opening contribution to The Destabilization of Internet Governance. The IGF warns that its real-time captioning may contain errors. intgovforum.org
Finding: Cerf presents application independence as beneficial. This page disputes the intelligence metaphor, not that independence.
Calling the network stupid does not establish that the endpoint is competent.
2.0 Transportation engineering does not require application interpretation
2.1 Networks can be engineered with redundant electronics, independent power, protected circuits, physically diverse routes, failure detection, and failover.
2.2 These protections require actual facilities and configuration. Two circuits sharing a conduit, entrance facility, equipment dependency, or power source may fail together. Different circuit numbers do not establish physical diversity.
2.3 Protection can maintain or restore connectivity through covered failures. Some mechanisms may lose packets during transition. Their capabilities must be assessed against the deployment and failure conditions.
2.4 None of this necessarily requires interpreting whether the payload represents The Sound of Music, a payment, or an email.
Finding: Content independence is a separation of responsibilities. It is not evidence of an absence of sophisticated engineering.
3.0 TCP retransmission does not supply physical redundancy
3.1 TCP does not install another circuit, place cable on a diverse route, supply independent power, or replace failed electronics.
3.2 A retransmission can benefit from an alternate path made available by the network. The facilities and network mechanisms supply that opportunity.
3.3 If the only usable physical connection has failed, repeating data does not create replacement infrastructure.
3.4 Hosts can also have redundant interfaces and replicated systems. Those protections require separate engineering.
Finding: Network protection preserves or restores connectivity. TCP recovery uses available connectivity. Recovery does not construct the facilities that make another attempt possible.
4.0 The 1974 paper presumes network transportation
4.1 Printed page 637, Introduction:
A packet communication network includes a transportation mechanism for delivering data between computers or between computers and terminals.
4.2 Printed page 637, Introduction:
In this paper we present a protocol design and philosophy that supports the sharing of resources that exist in different packet switching networks.
4.3 Printed page 638, Introduction:
We obviously want to allow conversion between packet switching strategies at the interface, to permit interconnection of existing and planned networks.
4.4 Printed page 638, Introduction:
Furthermore, the interconnection must preserve intact the internal operation of each individual network.
Finding: These four selected passages establish the proposal’s reliance on constituent networks and their transportation. They are not an exhaustive count.
The paper contains architectural design concerning hosts, gateways, addressing, and packet handling. That design does not itself document construction or operation of all the underlying transportation facilities.
5.0 The TCP-enabled host can discard the delivered packet
5.1 Printed page 644, TCP Input/Output Handling:
A pool of buffers can be set up to handle arrivals, and if all available buffers are used up, succeeding arrivals can be discarded since unacknowledged packets will be retransmitted.
5.2 The sequence is explicit:
- The packet arrives.
- The receiving host has no available buffer.
- The host discards the packet.
- Recovery relies on retransmission.
5.3 The same section identifies additional reasons why placement into a receiving process’s buffer may fail:
The destination process may not be prepared to receive from the stated source, or the destination port ID may not exist.
There may be insufficient buffer space for the text.
Finding: The network can complete transportation to the computer while endpoint conditions prevent successful acceptance by the intended process.
TCP is present. The packet still gets discarded.
6.0 The receiver can permit transmission and subsequently reject the arrivals
6.1 Printed page 644, Flow Control:
The receiver can reduce the window even while packets are en route from the sender whose window is presently larger.
The paper continues:
The net effect of this reduction will be that the receiver may discard incoming packets (they may be outside the window) and reiterate the current window size along with a current window edge as acknowledgment.
6.2 Under this proposed behavior, the sender can transmit within the receiver’s previously advertised allowance. The receiver can then change its acceptance conditions while those packets travel and discard their arrivals.
Who’s stupid now? The receiving system declined data it previously permitted the sender to transmit.
6.3 Historical distinction. RFC 9293, edited by Wesley Eddy and published in August 2022, strongly discourages shrinking the receive window and specifies sender behavior when it occurs. The 1974 proposal must not be presented as the later specification’s recommended practice. www.rfc-editor.org
7.0 Host resource pressure is an explicit reason for recovery
7.1 Printed page 643, Retransmission and Duplicate Detection:
We envision it will occasionally be invoked to allow HOST accommodation to infrequent overdemands for limited buffer resources, and otherwise not used much.
Finding: The authors expressly anticipate recovery accommodating host limitations. Retransmission is not exclusively a response to defective network transportation.
8.0 Meanwhile, meet the home team
8.1 Your fourteen-year-old brother starts an Unreal Tournament match. Your mom streams The Sound of Music. Your dad streams Life of Brian.
Your Windows Vista notebook has 4 GB of RAM, twenty browser tabs open, music playing, and all ten seasons of Friends downloading.
8.2 The notebook also has adware and unwanted toolbars consuming resources. A compromised appliance generates additional traffic without the household’s knowledge.
This is an illustrative scenario. Compromise is a stated condition of the example.
8.3 Everyone competes for the shared connection. Applications and unwanted software compete for the notebook’s processor, memory, storage, and network interface.
When demand exceeds available capacity, delay can increase and packets can be discarded.
8.4 “BUT KAHN AND CERF GAVE YOU TCP! SO NO PROBLEMS!”
That exclamation is satire, not a quotation from either man.
The notebook still has the adware. The appliance is still compromised. The connection still has the same capacity.
The receiving host discards an arrival because its buffers are full. The sender tries again.
The retry did not buy the receiver more memory.
9.0 A receive window is not a reservation of the home team’s resources
9.1 “Home team” includes either endpoint’s hosts, users, applications, LAN, Wi-Fi, switches, firewalls, gateways, and managed WAN infrastructure.
9.2 Advertising a receive window does not itself reserve:
- Bandwidth against competing users.
- Wi-Fi airtime.
- Buffers in intervening equipment.
- WAN capacity.
- Processor time or application availability.
- Resources against unwanted or malicious software.
9.3 TCP does regulate transmission. RFC 5681, September 2009, by Mark Allman, Vern Paxson, and Ethan Blanton, distinguishes receiver flow control from sender congestion control. These mechanisms govern transmission behavior. They do not reserve every resource along the path. www.rfc-editor.org
Finding: Transmission control, resource reservation, physical protection, and equipment security are distinct capabilities.
10.0 The network can participate in control and recovery too
10.1 RFC 3135, June 2001, by John Border, Markku Kojo, Jim Griner, Gabriel Montenegro, and Zach Shelby, documents performance-enhancing proxies using local acknowledgments, local retransmissions, and split connections.
These mechanisms can alter end-to-end semantics and introduce dependencies. They nevertheless demonstrate intermediate participation in recovery. www.rfc-editor.org
10.2 RFC 3168, September 2001, by K. K. Ramakrishnan, Sally Floyd, and David Black, specifies Explicit Congestion Notification. Routers can mark congestion in packet headers so endpoints can respond without interpreting application content. www.rfc-editor.org
Finding: Network participation in control and recovery does not require application-content interpretation.
11.0 TCP does not solve the host failures described here
11.1 TCP does not remove adware, repair a compromised appliance, add memory, correct a firewall rule, or repair faulty equipment.
11.2 Another transmission may succeed because a temporary condition clears. That can recover the exchange without identifying or removing the cause of the original failure.
11.3 A persistent condition can defeat subsequent attempts. An application’s deadline can expire before recovery completes.
11.4 A successful retry can leave an operating problem unresolved. The exchange completes, but the overloaded host, competing traffic, or compromised appliance may remain. The same condition can affect the next exchange.
Finding: Successful recovery establishes an outcome for that exchange. It does not establish that the cause was diagnosed or repaired.
12.0 Retransmission alone does not identify responsibility
12.1 Data may fail to arrive. It may arrive and be discarded at the receiver. An acknowledgment may be generated but fail to return.
12.2 Additional signals can narrow an explanation. They do not turn the occurrence of retransmission into a comprehensive diagnosis.
12.3 Investigation requires evidence from the sending system, forward path, receiving system, and return path. Successful TCP exchanges do not certify that either endpoint is uncompromised.
Finding: The host remains part of the investigation. The carrier cannot be assigned responsibility merely because TCP retransmitted.
13.0 Counterarguments and responses: Does the mechanism solve the stated problem?
13.1 Counterargument: “Stupid network” means application independence.
Correct. But does application independence establish that the network lacks sophisticated protection, or that the endpoint is dependable? No.
The objection concerns the metaphor’s limits. Transportation engineering and application interpretation are different functions.
13.2 Counterargument: TCP flow control protects the receiver.
It regulates how much data the sender may have outstanding according to the advertised allowance. But does the receive window itself reserve processor time, prevent competing software from consuming resources, or guarantee application availability? No.
Flow control is useful. Its presence does not establish that every host resource needed for acceptance remains available.
13.3 Counterargument: D-SACK identifies unnecessary retransmission.
It can support that inference. But does duplicate-receipt information identify and repair an exhausted buffer, stalled process, or discarded acknowledgment? No.
RFC 2883 describes D-SACK feedback in circumstances including reordering, acknowledgment loss, packet replication, and early retransmission timeouts. RFC 3708 identifies difficulties distinguishing network duplication from unnecessary retransmission. The feedback is useful without being comprehensive fault attribution. www.rfc-editor.org
13.4 Counterargument: ECN tells TCP about congestion.
Correct. But does an ECN signal supply missing capacity or repair a host’s resource failure? No.
It communicates a particular condition. It does not diagnose every possible failure or remove every cause. It also demonstrates that network participation does not require understanding application content.
13.5 Counterargument: Congestion control reduces overload.
Correct. Reducing offered traffic can alleviate congestion. But does it remove malware, repair equipment, or reserve resources against all other users? No.
Its useful effect must be identified specifically. It must not be expanded into a claim that every relevant operating problem has been solved.
13.6 Counterargument: The retransmission succeeded, so TCP solved the problem.
It recovered the exchange. But does that establish that the original cause was identified and removed? No.
Temporary resource pressure may have cleared. The same cause may recur. Completion and repair are different findings.
13.7 Counterargument: Host-side discards are rare.
Their frequency requires evidence. But even if rarity were established, would that make a particular retransmission proof of carrier failure? No.
This page does not claim that hosts cause most Internet packet loss. A frequency estimate does not identify the cause of an individual event.
13.8 Counterargument: None of this disproves Cerf and Kahn’s historical contributions.
Correct. Does a documented protocol contribution establish responsibility for all later infrastructure, operating performance, commercial access, or governance? No.
Each broader attribution requires evidence addressing the achievement actually credited.
14.0 The disagreement
THE DISAGREEMENT: Calling the network stupid because it does not interpret application content obscures the engineering that transports traffic and preserves service. Placing intelligence at the endpoints does not establish that those endpoints are capable, secure, or dependable.
Cerf and Kahn’s own paper describes TCP-enabled hosts discarding delivered packets because of endpoint resource and processing limitations. The network may have completed its delivery correctly.
CORRECTED STATEMENT: A network can protect transportation without interpreting application content. TCP can regulate transmission and attempt recovery without supplying physical redundancy, securing the host, reserving every required resource, or identifying every cause of failure.
CONSEQUENCE FOR THE HISTORICAL RECORD: Distinguish application awareness from engineering competence, network protection from endpoint retransmission, and recovery of an exchange from repair of its underlying condition.
15.0 Documentary exhibit: Google AI’s attempted rebuttal
15.1 Provenance. Mark Nichols supplied the following excerpts from an exchange he identified as Google AI. They are reproduced from his supplied text. No share link, model identifier, or independently verified generation timestamp accompanies that text. The exhibit records this supplied exchange.
15.2 The unsupported statistical claim. The supplied response stated:
In actual internet traffic telemetry, host-side buffer discards (
rx_droppedat the OS level due to CPU/RAM starvation) account for a fraction of a percent of overall internet packet loss.
Finding: The answer identifies no dataset, study, measurement method, observation period, or population supporting that percentage. Its interpretation of rx_dropped also requires operating-system and driver context.
Even a valid low percentage would not refute the documented possibility of host discard or establish that retransmission identifies fault location.
15.3 The substitution of a different claim. The response continued:
While the scenario is possible, framing host incompetence as a primary baseline driver of internet transport failure is empirically false.
Finding: This page does not assert that hosts cause most Internet packet loss. The attempted rebuttal substitutes a statistical claim for the page’s narrower diagnostic finding.
15.4 The overstated D-SACK claim. The supplied response stated:
If a sender receives a D-SACK, it proves the network did deliver the original packet correctly, but it simply arrived out of order or the ACK was delayed.
Finding: D-SACK reports duplicate receipt of a sequence range. That does not, by itself, establish the quoted explanation. The relevant distinctions are documented in RFC 2883 and RFC 3708.
15.5 Mark Nichols challenged the rebuttal:
i dotn think you overruled the authors point with all of that
The AI then responded:
The author’s point is structural and logical, not statistical.
Finding: This correction recognizes the mismatch. It does not substantiate the original statistic or D-SACK assertion.
15.6 The correction introduced another overstatement. The supplied response described TCP as:
It is a mathematical engine designed to guarantee delivery.
Finding: TCP does not provide an unconditional guarantee of successful delivery through persistent disconnection, failed hosts, or exhausted resources.
15.7 A subsequent admission introduced another absolute claim:
The author’s structural logic is absolute: TCP cannot see past its own timers and sequence numbers.
Finding: TCP processes additional information, including advertised windows and negotiated signals. The page’s finding does not require claiming that timers and sequence numbers are its only inputs.
15.8 What the exchange demonstrates. The supplied record contains an unsupported numerical claim, a rebuttal to a statistical proposition this page did not make, and an overstated interpretation of D-SACK. When challenged, the system withdrew its rebuttal but introduced further overstatements about guaranteed delivery and TCP’s available information.
Withdrawing an unsupported answer does not validate its replacement. Each correction requires independent verification against the relevant evidence. In this exchange, agreement with the author did not prevent additional technical errors.
An apology is not verification. Agreement after a challenge is not a substitute for checking evidence.
15.9 The controlling finding remains:
A host can discard correctly delivered data because of its own resource or processing limitations. Retransmission alone does not establish where the failure occurred. A useful recovery mechanism does not automatically diagnose or repair the problem it accommodates.
16.0 Sources and related pages
16.1 Cerf’s Senate testimony, February 7, 2006. Net Neutrality, Senate Hearing 109-605, printed page 7.
16.2 KU Leuven’s report of Cerf’s May 16, 2012 visit.
16.3 Cerf’s IGF remarks, November 13, 2015.
16.4 RFC 2883: An Extension to the Selective Acknowledgement Option for TCP. July 2000, by Sally Floyd, Jamshid Mahdavi, Matt Mathis, and Matt Podolsky.
16.5 RFC 3708: Using Duplicate Notifications to Detect Spurious Retransmissions. February 2004, by Ethan Blanton and Mark Allman.
16.6 TCP by RFC 793: The Pre-Existing Network Is Assumed.
16.7 TCP: Between the Hosts, Not Between the Networks.
16.8 The 2000ms Event Horizon. Mark Nichols’s named operational condition, not a universal TCP cutoff.
16.9 Burst Timeout and the Session Death Loop.
16.10 TCP: The Master of Disaster and the Twelve Sins of the Stack.
Every page on this site is governed by The Governing Definitions and Controlling Facts. Historical attribution, technical behavior, and responsibility for particular failures must be measured against the relevant evidence.
Focus keyphrase
TCP host failures
Keyphrase synonyms
TCP endpoint failures, host buffer exhaustion, receiving host packet drops
SEO title
TCP Host Failures: Disagreements | Network, Not Protocol
Slug
kahn-cerfs-tcp-is-ignorant-about-its-own-hosts-failures-whos-stupid-now
Meta description
Cerf called the network stupid. Their own paper describes TCP-enabled hosts discarding delivered packets because of endpoint resource and processing limits.
Social title
Cerf Called the Network Stupid. The TCP-Enabled Host Dropped the Packet.
Social description
TCP-enabled hosts can discard delivered packets. Read the 1974 evidence, counterarguments, and examination of Google AI’s unsupported rebuttal.
Menu label
TCP Is Ignorant About Its Own Host’s Failures