Zusammenfassung

  • Entfernte Ausfälle sollten Gateways durch eine neue Route abfangen. Der Host musste den Sonderfall erkennen, der keinen ICMP-Hinweis mehr senden konnte: sein ausgefallenes unmittelbares Gateway.
  • Eine einzelne ICMP-Fehlermeldung während der Konvergenz war kein Grund, TCP sofort abzubrechen. Wiederholung und User Timeout zeigten Ernsthaftigkeit, der Hinweis lieferte eine wahrscheinliche Ursache.
  • Ein TCP-ACK war kein Abschlussbeleg der Anwendung. Frühe SMTP-Ausfälle und inaktive Telnet-Sitzungen verlangten eigene Bestätigungen, Zeitgrenzen und Lebenszeichen oberhalb des Transports.

Nicht jede Schicht beantwortete dieselbe Frage

RFC 816 begann mit Gateways, die ihre jeweils neueste Einschätzung benachbarter Netze und Gateways austauschten. Nach einem Ausfall konnten diese Einschätzungen vorübergehend widersprüchlich sein. Danach sollte sich eine konsistente Topologie mit einem alternativen Weg ergeben.

Für einen entfernten Fehler war das entscheidend: Die Gateways in seiner Nähe konnten ihn erkennen und umgehen, ohne dass jeder Host eine vollständige Internetkarte pflegte. Der Host sollte von dieser Reparatur möglichst wenig sehen.

Nur das erste Gateway fiel aus diesem Modell. Starb genau die Maschine, der der Host seine Datagramme übergab, konnte sie weder Redirect noch Destination Unreachable zurücksenden. Andere Gateways mochten den neuen Weg schon kennen. Die Pakete erreichten sie nicht, sondern verschwanden am stummen ersten Hop.

Clark gab dem Host deshalb eine schmale Aufgabe: Er musste den Tod des tatsächlich verwendeten nächsten Gateways erkennen und ein anderes unmittelbar erreichbares wählen. Der lokale Befund rechtfertigte eine lokale Korrektur. Er sagte noch nichts über den entfernten Host, dessen Dienst oder das Ergebnis der Anwendung.

Eine Fehlermeldung trug den Zeitpunkt ihrer Beobachtung

ICMP Redirect teilte einen besseren unmittelbaren Weg mit. Destination Unreachable beschrieb, dass der Absender in seinem aktuellen Zustand keinen brauchbaren Weg sah. RFC 816 behandelte beide als Ratschläge.

Während der Routing-Konvergenz konnten zwei Gateways unterschiedliche Wissensstände haben. Ein Datagramm konnte eine einzelne Unreachable-Antwort auslösen, obwohl kurz danach ein neuer Weg stand. Eine etablierte TCP-Verbindung aufgrund dieses einen Signals zu schließen hätte die Fähigkeit des Internets aufgegeben, interne Fehler ohne Unterbrechung der Endpunkte zu reparieren.

Der Hinweis blieb wertvoll. Beim Verbindungsaufbau konnte er auf eine falsche Adresse hindeuten. Nach Ablauf einer Zeitgrenze konnte er die wahrscheinliche Ursache präzisieren. Parameter Problem konnte ein Implementierungsproblem anzeigen. Seine Bedeutung hing von Typ, Code, Absender, Zeitpunkt, Verbindungsphase und Bestätigung durch weitere Signale ab.

Information durfte nach oben fließen, ohne dort automatisch Entscheidungsgewalt zu erlangen. Gerade Herkunft und Alter machten sie verwertbar.

Eine falsche Ausweichwahl ließ sich zurücknehmen

RFC 816 verglich netzseitige Meldungen, kontinuierliches Polling, ausgelöstes Polling und ausgelöste Neuwahl. Dauernde ICMP-Echo-Anfragen hätten Ausfälle erkannt, aber bei ausreichender Häufigkeit Hosts, Netz und Gateways untragbar belastet. Ohne besondere Kostenanalyse war diese Methode untersagt.

Beim ausgelösten Polling gab wiederholte TCP-Übertragung IP einen Verdachtsmoment; erst dann wurde geprüft. Das sparte Last, konnte die Bestätigung aber bis nach dem TCP-Limit verzögern.

Die ausgelöste Neuwahl probierte sofort das nächste bekannte Gateway. War das ursprüngliche tot, begann die Erholung früher. War die Vermutung falsch, konnte das lebende Ersatz-Gateway das Paket weiterleiten und mit einem Redirect auf die bessere ursprüngliche Wahl zurückverweisen.

Unsicherheit führte damit zu einem begrenzten, reversiblen Experiment. Sie rechtfertigte weder blindes Failover noch eine dauerhafte neue Routing-Autorität.

RFC 1122 machte später Erkennung und Ersatz eines ausgefallenen Next Hops zur IP-Anforderung, räumte jedoch ein, dass kein vollkommen zufriedenstellender Universalalgorithmus existierte. Dauerping blieb verboten; positive und negative Hinweise aus TCP, ACKs, Link, ARP und ICMP wurden bevorzugt.

TCP kannte das Ausbleiben von Fortschritt

TCP übertrug ein unbestätigtes Segment erneut, bis ein ACK eintraf oder die Warteentscheidung endete. Wiederholungen konnten IP negative Routenhinweise geben. In Gegenrichtung gelangten ICMP- und Linkfehler zu TCP.

Wiederholung zeigte fehlenden Fortschritt. Der User Timeout legte fest, wann der TCP-Nutzer nicht weiter warten wollte. Der Netzwerkfehler bot eine Erklärung. RFC 816 verlangte, diese Tatsachen bis zum Client weiterzureichen, weil ein Mensch an Telnet anders entscheiden konnte als ein Mailprogramm.

RFC 1122 schrieb später vor, bestimmte weiche Destination-Unreachable-Fehler dürften eine etablierte Verbindung nicht abbrechen und sollten der Anwendung zugänglich sein. RFC 5461 beschrieb den Preis dieser Geduld: Sie erhält Verbindungen bei vorübergehender Rekonstruktion, kann aber den Wechsel von einer dauerhaft unerreichbaren ersten Adresse zur nächsten verzögern. Dokumentierte Abkürzungen beim Aufbau blieben nicht standardkonform.

RFC 9293 trennt weiterhin Retransmission Timeout und User Timeout. Der erste sendet das vorderste Segment erneut. Der zweite leert Warteschlangen, meldet den Abbruch, löscht den Verbindungszustand und schließt. Ein gemeinsamer Name macht aus beiden keine gemeinsame Entscheidung.

Bestätigte Bytes waren noch kein bestätigter Auftrag

Frühe SMTP-Empfänger konnten abstürzen, nachdem sie den gesamten Mailtext erhalten hatten, aber bevor sie die SMTP-Bestätigung sendeten. TCP hatte alle Daten quittiert. Es gab kein ausstehendes Segment, dessen Wiederholungszeitgeber den Fehler sichtbar machte. Der Sender wartete auf eine Antwort, deren Bedeutung nur SMTP kannte.

Ein Zeitgeber in der Anwendung war nötig, aber seine Dauer hatte keine neutrale Größe. Ein kurzes Limit verwarf große Nachrichten, die zu einem langsamen Host normal vorankamen. Ein langes Limit entdeckte echte Fehler spät. Manche Mailer bezogen die Nachrichtengröße ein. Entscheidend war, dass die wissende Schicht sowohl Abschlussantwort als auch Arbeitsmenge kannte.

Ein ACK belegt den Empfang des bestätigten TCP-Sequenzraums durch den entfernten Transport. Es belegt weder das Weiterleben des Prozesses noch Speicherung, Annahme der Mail oder Erfüllung eines Geschäftsversprechens.

Im Leerlauf gab es nichts, was TCP wiederholen konnte

Server-Telnet zeigte den umgekehrten Fall. Der Weg konnte brechen, während der Nutzer nachdachte. Der nächste Tastendruck offenbarte den Fehler dem Menschen. Der Server hatte ohne eigene Daten jedoch kein unbestätigtes Segment und konnte eine tote Sitzung unbegrenzt halten.

Eine anwendungsseitige Anfrage konnte die Gegenstelle prüfen. Für jede ruhende Sitzung häufig ausgeführt, erzeugte sie jedoch dieselbe Last wie kontinuierliches Polling. Die Anwendung musste legitime Stille, Kosten veralteten Zustands und Prüfintervall gegeneinander abwägen.

SMTP hatte Transporterfolg ohne Anwendungsabschluss. Telnet hatte einen toten Weg ohne aktiven Transportvorgang, der scheitern konnte. TCP beantwortete jeweils seine eigene Frage richtig. Es konnte die Frage der Anwendung nicht übernehmen.

Begrenzte Hinweise ließen sich kombinieren

RFC 816 konstruierte keinen universellen Fehlerwert. Routingzustand, lokales Schweigen, Wiederholung, Ende der Wartezeit und Anwendungsbeleg blieben getrennt. So konnte jedes Signal eine Reaktion auslösen, ohne die unbekannten Teile zu überschreiben.

Eine ICMP-Meldung konnte wahr und dennoch nicht endgültig sein. Ein Timeout konnte endgültig und dennoch keine Diagnose sein. Ein ACK konnte echt und dennoch kein Geschäftsbeleg sein.

Die Fehlermeldung gewann durch ihre Begrenzung. Als Rat erklärte sie eine mögliche Ursache und unterstützte lokale Wiederherstellung, ohne der Schicht das letzte Wort zu nehmen, die das eigentliche Ergebnis versprochen hatte.

Quellen