The Illogical TCP Death Loop: TCP Is Not the Solution to the Problem; TCP Is the Problem

The optional protocol TCP was not the solution to the problem in its design of May 1974 and is not the solution to the problem under its specification of record, RFC 9293 of August 2022; TCP is the problem, because when an endpoint is the point of failure and the network is not, so that the network delivered a packet intact on the first send, the sending TCP 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 of the same segment into the network and demanding network capacity for a failure that is not the network’s, which makes the network pay again for a delivery the network already completed, because TCP is an illogical protocol. TCP was not designed to serve its own host in the first place, nor the network. Robert E. Kahn and Vinton G. Cerf did not solve the problem; they created the problem within their design and evangelism of this illogical protocol, and their paper of May 1974 records that they knew of the receiving host’s failures and chose retransmission across the network as the answer, as 14.8 of TCP Ignores Its Own Host’s Failures by Design records. Mark Nichols named that loop the Illogical TCP Death Loop on November 7, 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 intact on the first send, 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 same segment into the network, and keeps retrying, because a missing acknowledgment, which is all the sending TCP observes from the failing endpoint, does not tell the sending TCP whether the endpoint or the network failed, so the network carries the same segment a second time, and every time after, for a delivery that the network already completed. Mark Nichols named that loop the Illogical TCP Death Loop on November 7, 2026. The Illogical 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 Illogical 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 Illogical 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 TCP Ignores Its Own Host’s Failures by Design 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 TCP Ignores Its Own Host’s Failures by Design 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 illogical and records the judgments of Mark Nichols on the design, section 8.0 states the documented-challenge terms, section 9.0 shows that TCP was not the solution to the problem of delivery, because the network delivered before the design of TCP and delivered again in 1996, and section 10.0 records the account that RFC 896 gave on January 6, 1984 of the network of the ARPANET, which handled congestion for most hosts, and of the gateways between networks, which the hosts’ retransmissions could drive into congestion collapse.

1.0 Mark Nichols named the Illogical TCP Death Loop on November 7, 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 Illogical TCP Death Loop on November 7, 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 in the words “That’s the death loop” on the same day, and Mark Nichols named the loop the Illogical TCP Death Loop on November 7, 2026.

1.3 The Illogical 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 16.4 of TCP Ignores Its Own Host’s Failures by Design.

2.2 In the section TCP Input/Output Handling, which 16.3 of TCP Ignores Its Own Host’s Failures by Design 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 TCP Ignores Its Own Host’s Failures by Design 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 16.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 TCP Ignores Its Own Host’s Failures by Design 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 Illogical 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 from an endpoint that fails without answering, 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 TCP Ignores Its Own Host’s Failures by Design 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 TCP Ignores Its Own Host’s Failures by Design states, so the ignorance this page names is the ignorance of the sending TCP, which the design chose, as 0.6 of the same page states, 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.

3.6 RFC 611, Two Changes to the IMP/Host Protocol to Improve User/Network Communications, written by D. Walden of BBN-NET and dated February 14, 1974, three months before the paper of May 1974 that 2.1 names, specified a new message for the interface between the ARPANET and its hosts, the message of type 6, Dead Host Status, which the Interface Message Processor of the ARPANET, the IMP, was to return to the source host shortly after each message of type 7, Destination Host Dead, because the message of type 7 could not say why the destination host was dead. The message of type 6 that RFC 611 specified tells the source host why the destination host is down, among the reasons scheduled hardware work, scheduled software work, an emergency restart, a power outage, a hardware failure, and a destination host so slow to accept traffic from the network that the network declared it down, and, where the destination host had announced it before going down, the day of the week, the hour, and the five-minute interval, in Universal time, at which the destination host would come back up. RFC 611 asks that the information in the message of type 6 reach every user who had a connection to the dead host, so in February 1974 the network of the ARPANET was specified to tell the sending host that its destination host was dead, why, and, where announced, when the destination host would return, which is knowledge that the sending TCP of section 3.0 cannot obtain from a missing acknowledgment. RFC 611 prints its author as D. Walden of BBN-NET, with an initial for the first name and no title.

3.7 RFC 878, The ARPANET 1822L Host Access Protocol, written by Andrew G. Malis of BBN Communications Corp. and dated December 1983, still lists among the messages that the IMP sends to a host the message of type 5, Ready for Next Message, the message of type 6, Dead Host Status, and the message of type 7, Destination Host or IMP Dead (or unknown), and RFC 878 records that the IMP opened a connection from the source host to each destination host and kept that connection open for as long as any message on it still awaited its reply and both hosts remained up. RFC 878 records that when the destination host went down, the IMP sent the source host a message of type 7 for each message still outstanding and for the next message the source host submitted, where the source host had addressed the destination host by its address, and a message of type 9, Incomplete Transmission, with subtype 6 for each outstanding message, where the source host had addressed the destination host by a logical name, and RFC 878 tells the source host to resubmit the lost message because another effective host port may be able to take it. RFC 878 also records that the IMP permitted no more than eight messages awaiting replies on one connection and held a host that offered a ninth until the reply to the first message was sent, so in December 1983 the network of the ARPANET told the sending host that its destination host was dead and held back a sending host that had eight messages awaiting replies. RFC 878 prints its author’s name and employer and no title.

3.8 Section 3.9.2.2 of RFC 9293, titled ICMP Messages, requires a TCP implementation to act on each error message that the IP layer hands up and to deliver the message to the connection that produced the error (MUST-54), and the section classes Destination Unreachable codes 0, 1, and 5 as soft errors and codes 2 through 4 as hard errors. RFC 792, Internet Control Message Protocol, dated September 1981, assigns code 1 to host unreachable and codes 2 and 3 to protocol unreachable and port unreachable, and states that a gateway may send codes 0, 1, 4, and 5 while a host may send codes 2 and 3. For the soft errors, requirement MUST-56 of RFC 9293 forbids a TCP implementation to abort the connection, and recommendation SHLD-25 says that the implementation should pass the information on to the application, while for the hard errors, which include the two codes that RFC 792 says may come from a host, recommendation SHLD-26 says that the implementation should abort the connection.

3.9 Because RFC 9293 of August 2022 classes host unreachable as a soft error, when a gateway of the network reports to the sending TCP that the destination host is unreachable, requirement MUST-56 forbids the sending TCP to end the connection on that report, and the transmissions of the same segment go on under the thresholds R1 and R2 that 3.4 records. Section 3.9.2.2 of RFC 9293 notes, citing section 4 of RFC 5461 of February 2009, that many implementations in wide use handle soft errors as hard errors while a connection is still being set up, and the Illogical TCP Death Loop of 1.1 and 4.5 retries data on a connection that is already established. Under RFC 9293 of August 2022, a report from the network that the destination host cannot be reached, which is the kind of report that 3.6 and 3.7 record from the ARPANET of 1974 and 1983, does not end the retries of the sending TCP.

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 TCP Ignores Its Own Host’s Failures by Design 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 TCP Ignores Its Own Host’s Failures by Design 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 host that cannot accommodate the arrival at all, which are the cases at 5.3, 6.1, and 0.4 of TCP Ignores Its Own Host’s Failures by Design.

4.4 Each retry crosses the network again and repairs nothing at the endpoint: in the household example at 8.4 of TCP Ignores Its Own Host’s Failures by Design, the retry bought no memory and removed no unwanted software, and 12.5 of the same page 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.

4.5 The Illogical TCP Death Loop makes the network pay twice for one delivery, and once more for every further retry. When the network delivers a packet intact to the receiving host on the first send and the receiving host then discards the packet for want of the buffer space, the process readiness, or another resource that 0.2 lists, the sending TCP receives only a missing acknowledgment, as 3.0 states, cannot tell that the receiving host and not the network failed, and sends the same segment across the network a second time. When the sending TCP sends a second time a segment that the network delivered intact, the second send spends network capacity on a delivery that the network already completed, and the network carries the same segment once more for every further retry until the sending TCP closes the connection at the threshold R2, which RFC 9293 recommends be at least 100 seconds and lets an application set to infinity, as 3.4 states. In the Illogical TCP Death Loop, the receiving host that fails is one of the two endpoints of the connection and runs the receiving TCP, so the failure that the sending TCP cannot see lies inside one of the two hosts in which TCP itself runs, while the network, which delivered the packet and which executes no TCP for the traffic the network carries, pays for every retry; TCP: Between the Hosts, Not Between the Networks documents that TCP runs between the hosts and not between the networks.

5.0 The application joins the loop, and the Illogical 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 Illogical 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 Illogical 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 Illogical 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 Illogical TCP Death Loop.

7.0 The word illogical in the name states the judgment of Mark Nichols on the design of TCP, and this section records that judgment and its companion judgments, each dated, beside the documents beneath them.

7.1 It is the judgment of Mark Nichols, dated November 7, 2026, that the TCP death loop is illogical because the retransmission of TCP exists to resend packets that the network failed to deliver, under Robert E. Kahn’s ground rule of 1973 that a packet that “didn’t make it to the final destination” would “shortly be retransmitted from the source,” and yet the design of May 1974 applies the same retransmission to packets that the network delivered and the receiving host discarded, when the TCP at the failing host holds the native host information that the host, and not the network, is the problem, so the design commands the sending TCP to request the network’s facilities again for a failure that the network did not cause and that a resend cannot cure.

7.2 Vinton G. Cerf and Robert E. Kahn knew of the receiving host’s failures and chose not to have the host report them, as 14.8 of TCP Ignores Its Own Host’s Failures by Design records in the words of their paper of May 1974, which directs that “the TCP should simply discard the packet (thus far, no provision has been made for error acknowledgments)” and states on its page 643 that evidence already exists “that individual networks can be effectively constructed without this feature” so the design of TCP was a choice made with the receiving host’s failure in view, and not an oversight.

7.3 It is the judgment of Mark Nichols, dated November 7, 2026, that the assignment of a remedy for network failure to a failure that the paper of May 1974 itself names as the receiving host’s, with the cost of that failure stated in the same paper, as 2.3 and 2.4 of this page record, is bad decision making by the designers of TCP, Vinton G. Cerf and Robert E. Kahn.

7.4 It is the judgment of Mark Nichols, dated November 7, 2026, that TCP does not gatekeep itself: the TCP module runs entirely within its own host, as RFC 793 of September 1981 places it, so the host’s incapability is within the reach of TCP, and yet, for every host condition except the buffer space that the receive window advertises, TCP does not take the intelligent action of telling the other end to hold up because the host has issues and to wait for the host, and instead discards the arrival without an error acknowledgment, as the design of May 1974 provides, and leaves the sender to retry into a network that already delivered the packet.

7.5 It is the judgment of Mark Nichols, dated November 7, 2026, that the sending TCP taxes the network with another retry of the same segment for a failure that is not the network’s while the failing host may never clear, because RFC 9293 of August 2022 recommends that the sending TCP close the connection only at the threshold R2 of at least 100 seconds and lets an application set R2 to infinity, as 3.4 of this page records, so the network can be taxed without end for a host that never recovers.

7.6 It is the stated opinion of Mark Nichols, dated November 7, 2026, that TCP is the most abusive network protocol ever designed, created, implemented, and recommended or required on private intranets, and the dated instance is the one that RFC 896 of January 6, 1984, written by John Nagle of Ford Aerospace and Communications Corporation, records and that 10.4 of this page states: in late 1983 one host’s TCP on the ARPANET retransmitted one datagram over and over at the highest rate the ARPANET would take, disregarded the Source Quench messages of the gateway, and saturated the gateway between the ARPANET and the network of Ford Aerospace and Communications Corporation and Ford Motor Company for several hours, until the faulty host crashed.

7.7 Mark Nichols states, dated November 5, 2026, “TCP is not the solution to the problem; TCP is the problem,” and the statement rests on the documented mechanism of this page: when an endpoint fails on a network that delivered the packet intact, the retry of the sending TCP repairs nothing at the failing endpoint, as 4.4 states, spends network capacity on a failure that is not the network’s, as the section line 4.0 states, and aims the first response at the network even when the remote host is the failing endpoint, as 3.4 states.

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.

9.0 TCP was not the solution to the problem of delivery, because the network of the ARPANET was required in 1968 to deliver and reported a dead destination host to the sending host before the design of TCP, the network delivered again in 1996 before the retry of the sending TCP could fire, and the design of TCP moved the retry into the hosts.

9.1 Request for Quotations No. DAHC15 69 Q 0002, issued July 29, 1968 by the Defense Supply Service-Washington of the Department of the Army for the Advanced Research Projects Agency and signed by Thomas J. Scheblik, Deputy Director for Procurement, solicited the Interface Message Processors for the ARPA computer network, and its Statement of Work required the network contractor to provide “fault detection and recovery to guarantee virtually error-free transmission,” to acknowledge messages positively and negatively, and to have the Interface Message Processors retransmit any message received in error, and the instrument made error checking, fault detection, and fault recovery the sole responsibility of the network contractor, six years before the paper of May 1974 that 2.1 names, as 1.3 of TCP: The Battlefield Protocol quotes the instrument.

9.2 In the ARPANET, the network itself guaranteed delivery, retransmitting hop by hop between the Interface Message Processors inside the subnet, as 1.1 of TCP: The Battlefield Protocol states, the IMP returned to the source host a message of type 5, Ready for Next Message, for a delivered message, as section 2.2.2 of RFC 878 of December 1983 records, and the IMP reported a dead destination host to the source host by the messages of type 7 and type 6 that 3.6 and 3.7 record, so under RFC 611 and RFC 878 the network of the ARPANET delivered, confirmed delivery to the sending host, and told the sending host that its destination host was dead, why, and, where the destination host had announced it, when the destination host would return.

9.3 The design of TCP moved the retry out of the network and into the hosts: the ground rule of 1973 that 2.5 records sent a packet that failed to reach its destination again from the source, the paper of May 1974 gave every failure the answer of sending again across the network, as 2.6 states, and RFC 761 of January 1980, the DoD Standard Transmission Control Protocol, edited by Jon Postel and prepared by the Information Sciences Institute of the University of Southern California for the Defense Advanced Research Projects Agency, states that TCP assumes little about the reliability of what RFC 761 calls the lower level protocols, and that TCP assumes from them only a simple datagram service that may be unreliable, as 1.3 of TCP: The Battlefield Protocol also records.

9.4 The statement of Mark Nichols dated November 5, 2026, “TCP is not the solution to the problem; TCP is the problem,” which 7.7 records, rests also on the documents of section 3.0 and of this section: the Advanced Research Projects Agency required the network to deliver in 1968, as 9.1 records, the network of the ARPANET confirmed delivery to the sending host and reported a dead destination host to the sending host with the reason, as 9.2, 3.6, and 3.7 record, and the design of TCP moved the retry into the hosts and assumed a network that may not deliver, as 9.3 records, where the sending TCP cannot tell an endpoint failure from a network failure, as 3.0 states, and does not end its retries on a report from the network that the destination host cannot be reached, as 3.9 states.

9.5 The network delivered again in 1996, by Mark Nichols’s statement at 6.1: on the network of Digital Island, 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 retransmission timer of the sending TCP never expired, and the network, not the retry of the sending TCP, completed the delivery.

10.0 RFC 896 of January 6, 1984 recorded that the network of the ARPANET had handled congestion for most hosts with its spare capacity and its throttling of the hosts, that hosts sending each packet several times could drive the gateways between networks into congestion collapse, and that one host’s malfunctioning TCP had in effect cut off from the ARPANET, for several hours in late 1983, the network that Ford Aerospace and Communications Corporation and Ford Motor Company operated.

10.1 RFC 896, Congestion Control in IP/TCP Internetworks, written by John Nagle of Ford Aerospace and Communications Corporation and dated January 6, 1984, states that IP and TCP, when used together, suffer congestion problems that arise from the interaction of the transport layer with the datagram layer, gives the name congestion collapse to a failure to which the gateways between networks are vulnerable, especially gateways that join networks whose bandwidths differ widely, and describes congestion collapse as the stable condition in which every packet is sent several times before one copy gets through and the throughput of the network sinks to a small part of its normal level. RFC 896 prints its author’s name and employer and no title, and RFC 896 states that it sets no standard.

10.2 RFC 896 of January 6, 1984 states that the congestion problems of IP and TCP used together had gone generally unrecognized because IP and TCP were used most often between hosts attached to networks that used the IMP technology of the ARPANET, which were built with a large margin of spare capacity, and that the spare capacity, together with the power of the IMP system to throttle what the hosts transmitted, had sufficed to deal with congestion for most hosts and networks using IP and TCP. RFC 896 of January 6, 1984 states that after the recent split of the ARPANET into two interconnected networks, and with the growth of other networks of different properties joined to the ARPANET, the hosts could no longer count on the protective behavior of the IMP system to keep their communication fast and reliable, and a footnote of RFC 896 records that the IMPs stopped a host from sending once the host had too many packets outstanding, as 3.7 records from RFC 878 for a host that submitted a ninth outstanding message.

10.3 RFC 896 of January 6, 1984 states that connections which never cross a gateway are usually kept out of congestion collapse by the flow control between the IMP and the host, that once the gateways are dropping packets and the segments of TCP are carried across the ARPANET and MILNET, nothing but the Source Quench message stands as a fundamental protection against congestion collapse, and that a handful of misbehaving hosts can, on their own, congest the gateways and shut out the traffic of other hosts, which RFC 896 reports having observed repeatedly with certain hosts on the ARPANET.

10.4 RFC 896 of January 6, 1984 records that on one occasion in late 1983, a defect in the TCP of one host on the ARPANET set that host retransmitting one datagram over and over, at the highest rate the ARPANET would take, that the retransmissions saturated the gateway between the ARPANET and the network that Ford Aerospace and Communications Corporation and Ford Motor Company operated, so that almost no useful traffic passed, that the host disregarded the Source Quench messages the gateway kept sending, and that the condition went on for several hours, ending only when the faulty host crashed, while that network was in effect cut off from the ARPANET. RFC 896 of January 6, 1984 records, for late 1983, a failure that was not the network’s, a defect in one host’s TCP, whose retransmissions saturated a gateway of the network for several hours at the expense of other traffic, which is the cost that section 4.0 states: network capacity spent on a failure that is not the network’s.

10.5 RFC 896 of January 6, 1984, in its remedy for the small-packet problem, holds back new segments at the sending TCP for as long as earlier data on the connection is still unacknowledged, states that in the case “where the distant host has failed, sending more data is futile anyway,” and states in the next sentence that the remedy leaves the ordinary retransmission logic of TCP untouched, so that lost messages are still covered. The remedy for the small-packet problem in RFC 896 of January 6, 1984 held back new data from a distant host that had failed and left the retransmission logic of the sending TCP running toward that failed host, because the retry of the sending TCP gives a lost message and a failed host the same answer, as 2.6 and 3.0 state.