Summary

  • RFC 816 gave the host one special routing duty: detect the death of the immediate gateway that could no longer return ICMP advice. More distant failures belonged chiefly to gateways reconstructing the route.
  • An isolated ICMP error during convergence was evidence, not a terminal judgment. Retransmission and user timeout showed that a problem was serious; error advice helped explain its probable cause.
  • TCP acknowledgement still did not prove that an application had completed its work. Early SMTP and idle Telnet failures showed why application-level receipts, timers and liveness rules remained necessary.

The failure that could not report itself

Most failures in RFC 816’s Internet were meant to disappear behind the routing system. Gateways exchanged their latest opinions about neighboring networks and gateways. After an outage they could be confused for a while, then settle on a new topology. A host did not need to diagnose a broken gateway several hops away because the gateways next to that failure could route around it.

The first hop was different. If a host kept sending to an immediate gateway that had crashed, that gateway could not return an ICMP Redirect, a Destination Unreachable or any other useful advice. The other gateways might already have reconstructed the Internet perfectly. None of that helped a packet handed to the silent machine. It simply vanished.

David D. Clark therefore narrowed the host’s fault-isolation task. The host did not become a second routing system with a complete map of the Internet. It needed a strategy for recognizing that the gateway it was directly using was dead, then selecting another immediately reachable gateway. Responsibility followed observability: the local host handled the one failure that the wider routing conversation could not report back through the failed participant.

That boundary also prevented a convenient overreaction. A remote outage was not a reason for every endpoint to rebuild the route. A silent first hop was not a reason to declare the destination dead. The local fact justified a local replacement.

A message could be true too early and false a moment later

RFC 816 called Redirect and Destination Unreachable advisory messages. A Redirect said that another immediate gateway was a better choice and that the triggering datagram had already been forwarded. An Unreachable said that the destination could not currently be reached. Both could be useful without being timeless truth.

Immediately after a network or gateway failed, routing information was in motion. One gateway could still hold an older view while another had learned the new route. A packet crossing that interval might produce an isolated Unreachable even though the internetwork was about to reconnect the endpoints. Aborting a TCP connection on that one message would discard the Internet’s capacity to recover internally while the endpoints stayed in place.

The error was not meaningless. Its evidentiary value depended on when it arrived, which operation elicited it, what type and code it carried, and whether other signals agreed. During a new connection attempt, an error might strongly suggest a bad address or inaccessible service. After a long-established connection encountered one transient routing event, it was weaker evidence of terminal failure.

This is a more demanding design than either blind trust or blind disregard. The message must be retained and passed upward, but its authority remains bounded. It describes what one layer observed at one moment; it does not acquire the right to decide every higher-layer outcome.

Recovery could begin before diagnosis was perfect

RFC 816 compared several ways to find a dead gateway. Some attached networks could report that the next machine was dead. A host could continuously poll gateways with ICMP Echo, but sufficiently frequent polling imposed load on hosts, networks and gateways. The paper prohibited that approach unless a specific analysis showed the overhead was tolerable.

Triggered polling spent that cost only after something seemed wrong. Repeated TCP retransmission could send a hint down to IP, which would then probe the gateway. The confirmation came later, however, and TCP might already have exhausted its patience.

Triggered reselection took a different position on uncertainty. On a higher-layer complaint, IP could try the next known gateway without polling first. If the original gateway was genuinely dead, the new choice shortened recovery. If the original was fine and the switch was unnecessary, a live alternate gateway could forward the packet and return a Redirect toward the better route. The mistaken choice was reversible.

The important mechanism was not reckless failover. It was a bounded experiment whose failure could be corrected by the same advisory system. Local action did not wait for global certainty, but it also did not turn the experiment into permanent route authority.

RFC 1122 later made the next-hop requirement more explicit: IP must detect a failed gateway in its route cache and choose an alternate. It also acknowledged that no completely satisfactory universal algorithm had emerged. Continuous first-hop pinging remained forbidden, and cross-layer positive or negative advice was preferred despite the added interface complexity.

A timeout established seriousness, not cause

At TCP, RFC 816 saw a smaller set of recovery actions. TCP retransmitted an unacknowledged segment until it received an acknowledgement or its connection timer expired. Retransmission could tell IP that the path deserved investigation. In the other direction, IP and the attached network could report ICMP or link errors upward.

These signals answered different questions. Repeated retransmission said that expected progress had not occurred. A user timeout supplied a terminal waiting boundary for the client of TCP. An ICMP message suggested why progress failed. None was a complete diagnosis alone.

The paper distinguished a program such as a mail sender from a human using Telnet. A program needed a defined point at which waiting ended. A person might decide to abandon immediately after one kind of failure or wait through another. RFC 816 therefore argued for asynchronous reporting: let timeout and lower-layer errors reach the client in a useful form so the final decision can be made where the purpose of the connection is known.

Later host requirements preserved the soft-error principle. RFC 1122 said that TCP must not abort an established connection merely because it received specified soft Destination Unreachable errors, and should make that information available to the application. RFC 5461 explained the bargain: patience allows connections to survive transient reconstruction, while a permanently unreachable first address can delay trying another. The informational RFC documented deployed shortcuts at connection startup but explicitly did not change the standard behavior.

RFC 9293 still separates retransmission timeout from user timeout. One resends the segment at the front of the retransmission queue. The other flushes queues, reports that the connection was aborted, deletes its state and closes. A timer is therefore not a single generic fact called “timeout”; it belongs to a particular decision boundary.

Every byte could arrive before the operation failed

RFC 816’s mail example exposed the limit of transport success. Some early receiving programs crashed after they had received all the mail text but before returning the SMTP-level acknowledgement. TCP had no outstanding unacknowledged data, so its retransmission timer had nothing to detect. The sender could wait indefinitely for a reply that only the application could produce.

Adding an SMTP timer was necessary but not mechanically simple. A short interval could reject a large message moving normally to a slow host. A long interval reduced false alarms but made genuine failures expensive to discover. Some mailers varied the interval with message size. The historical choice is less important than its location: SMTP knew which reply constituted mail-level completion and which workload characteristics affected a reasonable wait.

An ACK proved that acknowledged TCP sequence space reached the peer’s transport. It did not prove that the receiving process remained alive, committed the message, wrote durable state or fulfilled a business obligation. Calling a transport receipt “delivery” erased the last decision that mattered.

No outstanding data meant no transport alarm

The inverse failure appeared in server Telnet. A communication path could die while the user was thinking and no traffic was flowing. The next keystroke would reveal the broken session to the user. The server, with nothing to send, could remain unaware because there was no unacknowledged data to drive TCP’s timer.

An application-level query could test the other end, but polling every idle user at a high rate would recreate the overhead problem one layer higher. RFC 816 suggested using such a check when inactivity or another condition made suspicion reasonable. The correct liveness mechanism depended on the application’s pattern of silence and cost of stale state.

The two examples point in opposite directions. Mail could have complete transport acknowledgement without application completion. Telnet could have no transport failure signal because there was no active transfer to fail. TCP was not defective in either case. It was answering the transport question it was designed to answer.

Advice survived because it did not claim the final word

RFC 816 did not say that ICMP errors should be ignored. It said they should contribute probable cause after a timeout, identify likely mistakes during connection opening and expose possible implementation problems. It also said they were not absolutely reliable.

The durable architecture was a combination. Routing advice described the network’s current view. Silence at the first hop justified local reselection. TCP retransmission and user timeout described stalled transport and exhausted patience. The application defined its own acknowledgement and idle-state policy. Each observation moved upward without confiscating the next layer’s decision.

That is why the error message was advice rather than a verdict. Its limited authority made it more useful, not less. The Internet could react quickly to local evidence, survive transient contradiction and still require the layer that promised an outcome to prove that outcome itself.

Sources