Zusammenfassung

  • RFC 1106 beschrieb ein beratendes NAK und ein 30-Bit-TCP-Empfangsfenster. Die Erweiterungen waren mit NASA-Ressourcen implementiert und vorgeführt worden, blieben aber experimentell und wurden nicht als Internetstandard vorgeschlagen.
  • RFC 1110 fand zwei Monate später eine außerhalb des Tests liegende Bedingung: Das Fenster wuchs, der 32-Bit-Sequenzraum nicht. Eine Nummer konnte nach vier Umlaufzeiten wiederkehren und ein altes Duplikat gültig aussehen.
  • Ein NAK belegte nur eine am Empfänger sichtbare Lücke. Es unterschied weder Verspätung von endgültigem Verlust noch Rauschen von Überlast und belegte keine erneute Sendung, Wiederherstellung oder Zustellung.

Der Erfolgssatz enthielt seine Zuständigkeit

RFC 1106 von R. Fox erschien im Juni 1989. Zwei TCP-Erweiterungen seien mit Ressourcen der NASA implementiert und funktionierend gezeigt worden. Im selben Statusabschnitt nannte das Memo sie ein experimentelles Protokoll, keinen Vorschlag für einen Internetstandard und einen Ausgangspunkt weiterer Forschung.

Beide Aussagen können unverändert stehen. Der Code lief in einer bestimmten Topologie, Endpunkte handelten Zustand aus und Messungen entstanden. Diese Belege reichten bis zu den beobachteten Bedingungen, nicht automatisch bis zu jedem Zustand eines paketvermittelten Internets.

Das Abstract benannte die offene Grenze: Überlastung gegenüber Rauschen sowie die Übertragbarkeit vom isolierten Satellitennetz auf die gesamte Internet-Infrastruktur. Eine Leistungszahl ohne diese Umgebung wäre kein kürzerer Bericht, sondern eine andere Behauptung.

Heute führt die RFC-Editor-Seite das Dokument als Historic im Legacy Stream; der IETF Datatracker bewahrt den Datensatz. Der heutige Status ist Beleg für spätere Autorität und Annahme, nicht für die Nichtexistenz des damaligen Versuchs.

Die Lücke war sichtbar, ihr Grund nicht

Das NAK sollte auf langen Pfaden früher reagieren als ein normaler Timeout. Zeigte ein späteres Segment eine Lücke, konnte der Empfänger die Daten anfordern, die den linken Fensterrand weiterbewegten.

RFC 1106 räumte die entscheidende Unschärfe ein: Der Empfänger konnte verspätete Daten nicht von endgültig verlorenen unterscheiden. Ein frühes NAK konnte eine echte Lücke schließen oder ein unnötiges Duplikat erzeugen.

Die Nachricht war beratend und selbst unzuverlässig. Sie wurde nicht wiederholt. Der Sender durfte nichts tun oder sofort erneut senden; ging das NAK verloren, blieb die normale TCP-Wiederherstellung zuständig. NAK gesendet war somit kein Beleg für Verlust, Senderhandlung, Erfolg oder Zustellung.

Auch die Ursache blieb offen. Rauschen, Warteschlangenabwurf, Umordnung und ungewöhnliche Verzögerung erzeugten dieselbe lokale Abwesenheit. Wer die Lücke sah, sah deshalb noch nicht den Pfad.

Das große Fenster bot Endpunktspeicher an

Das 16-Bit-Fenster begrenzte unbestätigte Daten auf 64 KiB. Für Pfade mit hohem Bandbreite-Verzögerungs-Produkt war das zu klein. RFC 1106 ließ die unteren Bits im TCP-Header und trug obere Bits in einer Option, sodass ein 30-Bit-Empfangsfenster entstand.

Beide Seiten mussten in SYN und SYN-ACK zustimmen; danach sollte jedes Paket den oberen Anteil mitführen. Diese Aushandlung belegte gemeinsame Interpretation. Sie belegte nicht, dass Sequenzraum, Paketlebensdauer und Umordnung auf jedem Pfad zusammenpassten.

Das Empfangsfenster war außerdem keine Netzkapazität. Es spiegelte Puffer und lokale Annahmepolitik. RFC 1106 warnte, ein willkürlich großes Fenster könne Speicher erschöpfen, andere Arbeit verdrängen oder die Maschine zum Absturz bringen. Die bei NASA-Ressourcen erwogene Beschränkung auf bestimmte Programme war lokale Ressourcensteuerung, keine reservierte Bandbreite.

Aus 65.536 Umläufen wurden vier

Im August veröffentlichte A. McKenzie RFC 1110. Das Internet konnte Pakete verlieren, umordnen und duplizieren. TCPs 32-Bit-Sequenznummern liefen um; ein kleines Fenster und begrenzte Paketlebensdauer verhinderten, dass alte Daten beim nächsten Zyklus plausibel wurden.

Im Modell von RFC 1110 führte das 16-Bit-Fenster zur Wiederverwendung nach 65.536 Umlaufzeiten. Ein 30-Bit-Fenster im unveränderten Sequenzraum verkürzte sie auf vier. Ein NAK konnte nach einer Runde ein Duplikat anstoßen. Blieb ein altes Paket ungefähr fünf Runden im Netz, konnte es in einem späteren Fensterzyklus eintreffen und alte Bytes als aktuelle ausgeben.

Die Kritik erklärte den Versuch nicht für erfunden. RFC 1110 nahm sogar an, ein isoliertes Satellitennetz könne gedächtnislos sein: Es liefere der Reihe nach oder verwerfe. Dort fehlte der problematische Zustand. Das allgemeine Internet erlaubte mehr Zustände; die Verallgemeinerung, nicht die Messung, brach.

Spätere Dokumente trennten Defekt, Nutzung und Ersatzmechanismen

RFC 4614 bezeichnete RFC 1106 später als für allgemeine Nutzung fehlerhaft, RFC 1110 als ihre Abwertung und die Optionen als nicht von der breiten Gemeinschaft angenommen. Die erwähnte NAK-Nutzung in SCPS-TP blieb eine begrenzte Ausnahme.

RFC 6247 setzte beide Dokumente 2011 formal auf Historic, zusammen mit TCP-Erweiterungen ohne breite Nutzung. Fehlende Verbreitung ist nicht dasselbe wie fehlende Implementierung.

RFC 7323 löste verwandte Aufgaben getrennt: Window Scale ist ein in SYN ausgehandeltes Angebot; SACK beschreibt empfangene und fehlende Segmente; Timestamps und PAWS schützen vor alten Duplikaten beim Sequenzumlauf. Eine direkte Abstammung von RFC 1106 ist nicht belegt. Die Trennung der Evidenz ist es.

Zum Messergebnis gehörte eine Weltbeschreibung

Ein haltbarer Versuch speichert Version, Topologie, Fehlermodell, Puffergrenzen, Fenster, Sequenzumlaufrate, maximale Verweildauer, Umordnung, Duplikation, Verkehr und Beobachtungspunkte. Ebenso wichtig sind Zustände, die nicht vorkamen.

Nur „funktioniert“ macht einen lokalen Befund universell. Nur „Historic“ löscht einen wirklichen Versuch. RFC 1106 und RFC 1110 sind gemeinsam stark, weil sie das Ausgeführte und das nicht Geprüfte getrennt bewahren.

Quellen