The Stupid TCP Death Loop

When an endpoint is the point of failure and the network is not, the optional protocol TCP at the sending endpoint sees only a missing acknowledgment, cannot tell the endpoint’s failure from the network’s, cannot fix the endpoint, and cannot stop retrying short of abandoning the connection, so the sending TCP keeps firing retries into the network and demanding network capacity for a failure that is not the network’s, and Mark Nichols named that loop the Stupid TCP Death Loop on November 5, 2026.

Preamble: This page names and documents one loop of the optional protocol TCP, the loop in which an endpoint fails and the network does not. When a receiving host discards a packet that the network delivered, or when any endpoint fails without telling the endpoint at the other end of the connection why, the TCP at the sending endpoint receives no acknowledgment, retries the segment into the network, and keeps retrying, because a missing acknowledgment, which is all the sending TCP observes, does not tell the sending TCP whether the endpoint or the network failed. Mark Nichols named that loop the Stupid TCP Death Loop on November 5, 2026. The Stupid TCP Death Loop is the endpoint twin of the Session Death Loop, which Burst Timeout and the Session Death Loop documents from the side of the carrier network: the Session Death Loop began with a carrier network that discarded packets, and the Stupid TCP Death Loop begins with an endpoint that fails on a network that carries every retry. The definitions governing every term on this page are those of The Governing Definitions and Controlling Facts of Telecommunications Internetworking.

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 This page states the Stupid TCP Death Loop in deposition form, fixes the terms the loop depends on, and maps the sections in which each claim is documented.

0.1 This page is written in deposition form: its sections and paragraphs are numbered for citation, and any claim on it can be cited, challenged, or defended by its locus, which is the page’s slug, section number, paragraph number, and sentence ordinal.

0.2 An endpoint is a host at either end of a TCP connection, the machine that runs the TCP implementation and whose processor, memory, buffers, operating system, and local interfaces the TCP implementation depends on, which is how 0.3 of Robert Kahn’s and Vint Cerf’s TCP Is Ignorant About Its Own Host’s Failures - Who’s Stupid Now?: Disagreements | Network, Not Protocol defines the own host of a TCP implementation. An endpoint failure includes a host’s failure to accommodate a particular arrival, so the computer need not crash: the host’s TCP input handling or the intended application can lack the buffer space, the process readiness, or the other resources needed to accept and process the data, as 0.4 of Robert Kahn’s and Vint Cerf’s TCP Is Ignorant About Its Own Host’s Failures - Who’s Stupid Now?: Disagreements | Network, Not Protocol states.

0.3 The network is the plant and the interconnected networks that carry packets between the endpoints: the segments of the sending TCP are carried inside the datagrams of the optional protocol IP, those datagrams are carried inside the frames of the plant, and the plant carries everything.

0.4 This page calls the act of the sending TCP a retry. RFC 793 of September 1981 and RFC 9293 of August 2022 call the same act retransmission, and the word retry names what the sending TCP does: the sending TCP sends the same segment again because the first send went unacknowledged, while the physical, link, and Internet layers perform the transmission with or without TCP, as 9.3 of The “Internet Protocols” states.

0.5 Section 1.0 names and dates the coinage, section 2.0 shows the design of 1974 building the loop in, section 3.0 shows that the sending TCP cannot tell an endpoint failure from a network failure, section 4.0 shows the network carrying the cost of an endpoint failure, section 5.0 shows the application joining the loop and states the loop as the endpoint twin of the Session Death Loop, section 6.0 runs a controlled experiment on a network engineered for the service, section 7.0 states why the word in the name is stupid, and section 8.0 states the documented-challenge terms.

1.0 Mark Nichols named the Stupid TCP Death Loop on November 5, 2026, for the loop in which an endpoint fails, the network does not, and the sending TCP keeps retrying into the network.

1.1 Mark Nichols named the Stupid TCP Death Loop on November 5, 2026 for a loop of five steps: an endpoint fails, the sending TCP receives no acknowledgment, the sending TCP retries the segment into the network, the network carries the retry to the same failing endpoint, and the sending TCP retries again, so the network carries every retry for a failure that is not the network’s.

1.2 Mark Nichols stated the mechanism on November 5, 2026, before he named the loop, in the words “When the endpoint is the failing entity, the endpoint still fires off TCP and demands network capacity, even though the endpoint is the failure, and TCP doesn’t even know it and can’t do anything about fixing it, nor restrain from network-wasting requests, when the endpoint is the point of failure, not the network,” and he then said “That’s the death loop” and named the loop the Stupid TCP Death Loop the same day.

1.3 The Stupid TCP Death Loop is the endpoint twin of the Session Death Loop, which item 13 of section 11 of Mark Nichols: Career records as coined on September 28, 2026, and which Burst Timeout and the Session Death Loop traces from the side of the carrier network, from Frame Relay bursting above the Committed Information Rate to the application’s retry into the same path.

2.0 The design of 1974 builds the loop in: a receiving host may discard arrivals that the receiving host cannot accommodate, the design gives the receiving host no error acknowledgment with which to tell the sender why, and the design relies on the sender to send again.

2.1 Vinton G. Cerf, then of the Department of Computer Science and Electrical Engineering at Stanford University, and Robert E. Kahn, then of the Information Processing Technology Office of the Advanced Research Projects Agency of the Department of Defense, published A Protocol for Packet Network Intercommunication in IEEE Transactions on Communications, Volume COM-22, Number 5, in May 1974. The paper’s own footnote states those affiliations and states neither man’s title, and the paper is transcribed at 17.4 of Robert Kahn’s and Vint Cerf’s TCP Is Ignorant About Its Own Host’s Failures - Who’s Stupid Now?: Disagreements | Network, Not Protocol.

2.2 In the section TCP Input/Output Handling, which 17.3 of Robert Kahn’s and Vint Cerf’s TCP Is Ignorant About Its Own Host’s Failures - Who’s Stupid Now?: Disagreements | Network, Not Protocol places at printed page 644, the paper lets the receiving TCP discard later arrivals once the receiving TCP’s pool of buffers is exhausted, on the ground that the sender will send the unacknowledged packets again, and 5.1 of Robert Kahn’s and Vint Cerf’s TCP Is Ignorant About Its Own Host’s Failures - Who’s Stupid Now?: Disagreements | Network, Not Protocol quotes the passage verbatim.

2.3 The same section of the paper lists three reasons why placing an arriving packet into the receiving process may fail, which are a destination process that is not prepared to receive or a destination port that does not exist, a shortage of buffer space, and a packet that arrives out of order. The section directs the receiving TCP in the first case to discard the packet, with a note that the design so far offers no error acknowledgment, and the section closes by assigning congestion inside the receiving TCP to the paper’s strategy of retransmission and duplicate detection, so the design of 1974 gave the receiving host no message with which to tell the sending TCP why a packet the network delivered was discarded, and the design answered congestion inside the receiving host with repeated sends that the network carries.

2.4 In the section Flow Control, which 17.3 also places at printed page 644, the paper lets the receiver reduce its window while packets are already in transit and discard the arrivals that fall outside the reduced window, states that the flow-control mechanism depends heavily on effective retransmission, and states that a receiving host with little buffer space, which discards every packet that does not sit at the left edge of the window, will pay for those discards in added delay and in the overhead of sending again, so the paper itself names the cost of the receiving host’s discards and assigns that cost to repeated sends. Paragraph 6.1 of Robert Kahn’s and Vint Cerf’s TCP Is Ignorant About Its Own Host’s Failures - Who’s Stupid Now?: Disagreements | Network, Not Protocol records the reduction of the window.

2.5 Robert E. Kahn, then of the Information Processing Technology Office of the Advanced Research Projects Agency, set as his second ground rule of 1973 that communications would be on a best-effort basis and that a packet that failed to reach its destination would be sent again from the source, as A Brief History of the Internet states the rule at page 24 of the ACM SIGCOMM Computer Communication Review reprint of October 2009 and as 6.4 of TCP: Between the Hosts, Not Between the Networks quotes the rule verbatim.

2.6 The paper of May 1974 and the ground rule of 1973 give every failure the same answer, whether the network loses the packet or the receiving host discards a packet the network delivered: the source sends again across the network, and that single answer is the root of the Stupid TCP Death Loop.

3.0 The sending TCP cannot tell an endpoint failure from a network failure, because a missing acknowledgment is all the sending TCP observes and a missing acknowledgment fits both failures.

3.1 A missing acknowledgment may reflect loss on the forward path, discard by the receiving host, or loss of the acknowledgment on its return path, and the retry alone does not select among those explanations, as 12.2 and 0.3 of Robert Kahn’s and Vint Cerf’s TCP Is Ignorant About Its Own Host’s Failures - Who’s Stupid Now?: Disagreements | Network, Not Protocol record.

3.2 The receiving implementation may know why the receiving implementation discarded data, and the host, its operating system, applications, monitoring systems, and operators may know why a local failure occurred, but the sending TCP does not obtain that knowledge from a missing acknowledgment and a retry, as 0.3 of Robert Kahn’s and Vint Cerf’s TCP Is Ignorant About Its Own Host’s Failures - Who’s Stupid Now?: Disagreements | Network, Not Protocol states, so the ignorance this page names is the ignorance of the sending TCP and not the ignorance of every machine at the endpoint.

3.3 RFC 9293 of August 2022, the specification of TCP edited by Wesley M. Eddy of MTI Systems, which obsoletes RFC 793 of September 1981, states in section 3.8.3 that excessive retransmission of the same segment “indicates some failure of the remote host or the internetwork path,” so the specification of record names both suspects and does not choose between them.

3.4 Section 3.8.3 of RFC 9293 then sets two thresholds: when the transmissions of the same segment reach the threshold R1, the sending TCP passes negative advice to the IP layer to trigger diagnosis of a dead gateway, which aims the first response at the network even when the remote host is the failing endpoint, and when the transmissions reach the threshold R2, the sending TCP closes the connection. RFC 9293 recommends that R1 correspond to at least three retransmissions and that R2 correspond to at least 100 seconds, and RFC 9293 lets an application set R2 to infinity, so the specification permits the sending TCP to keep retrying until a user disconnects.

3.5 From the design of 1974 to the specification of 2022, the signal the sending TCP receives from an endpoint that fails without answering stayed a missing acknowledgment, and the answer of the sending TCP to that signal stayed a retry.

4.0 The network carries the cost of an endpoint failure, because the network delivered the packet and every retry the sending TCP fires spends network capacity on a failure that is not the network’s.

4.1 When the receiving host discards a packet the network delivered, the discard alone establishes no network delivery failure, and confirmed delivery followed by host discard does not retroactively become network non-delivery, as 5.4 and 12.4 of Robert Kahn’s and Vint Cerf’s TCP Is Ignorant About Its Own Host’s Failures - Who’s Stupid Now?: Disagreements | Network, Not Protocol state.

4.2 The sending TCP holds back new data when the receiving TCP advertises its limit, because flow control regulates sending according to advertised acceptance conditions, as 13.2 and 11.1 of Robert Kahn’s and Vint Cerf’s TCP Is Ignorant About Its Own Host’s Failures - Who’s Stupid Now?: Disagreements | Network, Not Protocol record, the second with a printer that has run out of paper, and even then section 3.8.6.1 of RFC 9293 has the sending TCP keep probing a zero window and keep the connection open for as long as the receiver answers the probes.

4.3 Every endpoint failure that the receiving TCP does not advertise returns to the network as retries: a receiving host whose arrival buffers are used up when the packet arrives, a receiver that shrinks its window after the sender has sent, and a failed host, which are the cases at 5.3, 6.1, and 15.6 of Robert Kahn’s and Vint Cerf’s TCP Is Ignorant About Its Own Host’s Failures - Who’s Stupid Now?: Disagreements | Network, Not Protocol.

4.4 Each retry crosses the network again and repairs nothing at the endpoint: in the household example at 8.4 of Robert Kahn’s and Vint Cerf’s TCP Is Ignorant About Its Own Host’s Failures - Who’s Stupid Now?: Disagreements | Network, Not Protocol, the retry bought no memory and removed no unwanted software, and 12.5 of Robert Kahn’s and Vint Cerf’s TCP Is Ignorant About Its Own Host’s Failures - Who’s Stupid Now?: Disagreements | Network, Not Protocol states that a host-side discard after confirmed delivery to the host does not, by itself, establish a network fault or assign the correction to the network operator.

5.0 The application joins the loop, and the Stupid TCP Death Loop is the endpoint twin of the Session Death Loop, with an opposite origin and a different cure.

5.1 Steps 5 through 8 of 5.1 of Burst Timeout and the Session Death Loop state what follows once delay passes the application’s timer: state expires, the session dies, the automatic retry fires, and the loop recurs.

5.2 Run from a failing endpoint, the same four steps close the Stupid TCP Death Loop: while the endpoint’s failure persists, the retries of the sending TCP stretch the delay until the application’s timer expires, the application abandons the session, the user or the application starts the transaction again, and the new session carries its packets to the same failing endpoint, where the sending TCP meets the same silence and fires the same retries into the network.

5.3 The Session Death Loop began in the carrier network, where Frame Relay discarded the Discard Eligible frames of a session that burst above its Committed Information Rate, and Mark Nichols removed that loop from the critical path in late 1996 with the AS6553 network of Digital Island, as sections 1 and 8 of Burst Timeout and the Session Death Loop state.

5.4 The Stupid TCP Death Loop begins at a failing endpoint on a network that delivered the packet, and no network architecture repairs a failing endpoint, so the cure for the Stupid TCP Death Loop lies at the endpoint, and the network carries the loop for as long as the endpoint’s failure persists.

6.0 On a network engineered so that no element’s failure becomes the service’s failure, every retry of the sending TCP measures an endpoint failure, as the controlled experiment of four hosts shows when the experiment is run in reverse.

6.1 Mark Nichols states that on the network of Digital Island in 1996, a lost circuit moved its traffic to a redundant and diverse circuit by SONET automatic protection switching, which the SONET standards specify to complete in under 50 milliseconds, so the retry timer of the sending TCP, which the specifications of TCP name the retransmission timer, never expired, as 2.8 and 2.9 of TCP: Between the Hosts, Not Between the Networks record, the second with his stated rule of October 3, 2026 that failure was not an option and that the service was engineered so that no element’s failure became the service’s.

6.2 Paragraph 2.10 of TCP: Between the Hosts, Not Between the Networks runs a controlled experiment with four hosts running the same TCP module byte for byte, holds the hosts identical, varies the network between the pairs, and finds that the activity of TCP measures the failure rate of the network between them.

6.3 Run in reverse, the experiment holds the network constant and lets one host fail: on a network that loses nothing, the network delivers every packet to the failing host, the failing host discards what the failing host cannot accommodate, and the sending TCP fires its retries into a network that has failed at nothing, so every retry measures the failing endpoint.

6.4 On a network that loses nothing, a count of the retries of the sending TCP is a count of endpoint failures, and the capacity those retries consume is the price the network pays for the Stupid TCP Death Loop.

7.0 The word stupid in the name answers Vinton G. Cerf’s description of the network core and places the word on the sending TCP, the component that cannot tell why its packet went unacknowledged.

7.1 Vinton G. Cerf, Vice President and Chief Internet Evangelist at Google, a position that 3.8 of Google Without Mark Nichols Written By Google: What Would Be Different records Mark Nichols stating him to have held since 2005, described the core of the network as stupid in his testimony before the U.S. Senate on February 7, 2006, published in Net Neutrality, Senate Hearing 109-605, at printed page 7, as 1.1 of Robert Kahn’s and Vint Cerf’s TCP Is Ignorant About Its Own Host’s Failures - Who’s Stupid Now?: Disagreements | Network, Not Protocol quotes him verbatim.

7.2 Vinton G. Cerf, in the same position at Google, is reported by the event report of KU Leuven of May 16, 2012, last updated May 21, 2012 and carrying no individual author, to have described the stupid network as a strength, and the caption transcript of the Internet Governance Forum of November 13, 2015, which carries the forum’s warning that the captions may contain errors and are not an authoritative record, records Vinton G. Cerf saying that the network was described as stupid because the network did not know what the network was carrying, as 1.2 and 1.3 of Robert Kahn’s and Vint Cerf’s TCP Is Ignorant About Its Own Host’s Failures - Who’s Stupid Now?: Disagreements | Network, Not Protocol record.

7.3 The network that Vinton G. Cerf called stupid protects and restores transportation and participates in signaling and recovery, as sections 2.0 and 10.0 of Robert Kahn’s and Vint Cerf’s TCP Is Ignorant About Its Own Host’s Failures - Who’s Stupid Now?: Disagreements | Network, Not Protocol record from the RFCs named there, while the sending TCP at the endpoint cannot tell from a missing acknowledgment whether the endpoint or the network failed, as section 3.0 above states.

7.4 Mark Nichols’s judgment, stated November 5, 2026, is that the stupid component in the loop is the sending TCP, which retries into a network that delivered the packet because a missing acknowledgment is all the sending TCP can see, and the name the Stupid TCP Death Loop places the word stupid on that component; the judgment is Mark Nichols’s, and the mechanism beneath the judgment is the documented mechanism of sections 2.0 through 4.0.

8.0 The claims on this page are open to documented challenge on the standing terms of marknichols.com, and the terms are stated here in full.

8.1 The claims on this page are open to challenge on the same terms as every claim on marknichols.com. A challenger who holds that a claim on this page is wrong, or that the Internet is something other than the publicly joinable network of networks of the registry lineage defined at The Governing Definitions and Controlling Facts of Telecommunications Internetworking, states the competing claim or definition in one sentence, names the document that carries it and the document’s date, and sends both to mark@marknichols.com. A challenge submitted with its document is answered on this page, and a competing definition submitted with its document is added to this page as an exhibit with attribution to the person who submitted it; a challenge submitted without a document is an opinion and is heard as one.

8.2 The distinction the site’s definition rests on, that protocols enable interoperability and are not the Internet, is stated in the IETF’s own words, RFC 2026 and STD 1, in the Internet-Draft draft-mnichols-protocols-not-the-internet-01, posted by Mark Nichols to the IETF Datatracker on September 25, 2026 at https://datatracker.ietf.org/doc/draft-mnichols-protocols-not-the-internet/ and stated on this site at Protocols Are Not the Internet: The IETF Internet-Draft by Mark Nichols, so a challenger may also address the definition in the venue that publishes the protocol standards themselves. Any person who holds expertise in telecommunications and a competing claim or definition is invited to bring both, in writing, with the document.