Zusammenfassung

  • RFC 1306 berichtet von einem Cray-Projekt aus dem Jahr 1992, in dem ein Routing-Lookup eine Anfrage an einen externen Controller für eine bedarfsgeschaltete T3-Verbindung erzeugen konnte.
  • Ein unvollständiger Anschluss durfte durch einen Datenübertragungsversuch nicht automatisch aktiviert werden; TCP sollte erst nach vollständiger Verbindung Daten über diese Route senden.
  • Weil frühe Implementierungen TCP-Retransmission-Timer schon vor dem ersten gesendeten Datenbyte zurücklaufen ließen, trennte eine spätere Version die Wartezeit für den Leitungsaufbau in einen eigenen Timer.

Analyse

Ein Lookup gab einen Anlass, keine Zusage

Das Quellsystem hatte in diesem Projekt ein Wissen, das ein gewöhnlicher nachgelagerter Rechner nicht brauchte: Bestimmter Verkehr sollte möglicherweise eine geschaltete Verbindung anfordern, und ein bestimmter Controller war dafür anzusprechen. Nach dem Routing-Lookup konnte der Kernel daher eine Steuerungsnachricht erzeugen. Der lokale Eintrag war ein Anlass, den nächsten Akteur zu fragen.

Der Akteur blieb aber ein anderer. Der Controller erstellt nach einer Anfrage eine Verbindung, sofern er es kann. Kapazität, Zustand und Erfolg werden damit nicht durch die Route bezeugt. Eine Oberfläche, die nur den Lookup oder die ausgesendete Anfrage zeigt, darf nicht behaupten, sie zeige schon eine vorhandene Leitung. Sie zeigt eine genau begrenzte Initiative des Hosts.

RFC 1306 erwähnt auch Routen-Aliase. Sie konnten der Quelle mehrere Alternativen durch eine vertraute Routing-Schnittstelle anbieten. Die politischen und Routing-Fragen dazu nimmt der Bericht ausdrücklich nicht in Besitz. Das ist wichtig: Eine aufgeführte Alternative ist kein Recht auf ihre Nutzung, keine Entscheidung über ihren Vorrang und kein Nachweis, dass der externe Controller sie fertigstellt.

Vor dem Abschluss war kein Datenpfad entstanden

Der Bericht setzt eine klare Sperre: Ein Übertragungsversuch über eine unvollständige Verbindung darf den Circuit nicht automatisch aktivieren. TCP darf über diese Route erst übertragen, wenn der Circuit vollständig ist. Der erste Sendeversuch einer Anwendung wird dadurch nicht zum stillschweigenden Auftrag, eine fremde Ressource bereitzustellen.

Ohne diese Sperre verschwimmen mehrere Fragen. Ein Host kann eine Anfrage protokolliert haben. Der Controller kann noch arbeiten, ablehnen oder keine Ressourcen finden. Die Leitung kann noch unvollständig sein. Der erste TCP-Segment kann weiterhin ausstehen. Ein einzelnes Wort wie „verbunden“ verwischt die Beweisarten, die zur Unterscheidung nötig wären.

Die im Bericht genannten Nachrichten für Anforderung und Abbruch unterstreichen denselben Punkt. Eine Anforderung kann zurückgenommen werden. Sie ist keine bleibende Einrichtung und keine Quittung für Übertragungsfähigkeit. Das Protokoll des Wunsches besitzt nicht den Rang des herbeigeführten Zustands.

Der Timer sollte seine eigene Frage beantworten

Die erste Kernel-Implementierung ließ die üblichen TCP-Retransmission-Timer während des Verbindungsaufbaus zurücklaufen, obwohl noch keine Daten gesendet waren. Die spätere Lösung führte dafür einen eigenen Timer ein. Damit wurde nicht der Aufbau beschleunigt oder garantiert; seine Beobachtung wurde begrifflich sauberer.

Ein Retransmission-Timer hat einen bestimmten Bezug: Er hilft, aus der ausbleibenden Reaktion auf bereits gesendete Daten zu schließen. Wenn er vor dem ersten Versand läuft, sieht eine externe Aufbaulatenz aus wie ein Transportproblem. Er kann einen Verlust oder eine Verzögerung nahelegen, für die es noch keinen Datenaustausch als Grundlage gibt.

Der getrennte Timer bewahrt den Zustand „Aufbau ausstehend“. Das ist keine kosmetische Messung. Automatisierung, Alarmierung und spätere Diagnose sind nur so belastbar wie die Ereignisse, die ihre Instrumente wirklich gesehen haben. Ein Timer darf eine Wartezeit benennen; er darf kein fehlendes Paket erfinden.

Was diese historische Quelle begrenzt

RFC 1306 ist ein Informational RFC vom März 1992 und ein Erfahrungsbericht, keine gegenwärtige Einsatzstatistik und kein Standardversprechen. Er stützt keine Aussage über heutige Carrier, Produkte oder die Verfügbarkeit einer bestimmten Leitung. Wohl aber zeigt er eine robuste Reihenfolge: Route wählen, Anfrage absenden, externe Einrichtung, vollständige Verbindung, Daten senden, Transport beobachten, Wirkung beurteilen.

Kein Schritt verleiht automatisch die Aussage des nächsten. Eine Route belegt keinen Circuit, ein Circuit keine Lieferung und eine Lieferung keinen Geschäftserfolg oder Dienstzustand. Diese Zurückhaltung ist keine Bürokratie; sie hält eine sichtbare Steuerungsnachricht davon ab, sich als Realität auszugeben.

Quellen

RFC 1306 dokumentiert ein Projekterlebnis von 1992; es belegt weder aktuelle Bereitstellung noch Routenbefugnis, Kapazitätsrecht, fertige Leitung, Paketlieferung oder Nutzerergebnis.