Zusammenfassung

  • RFC 1025 machte Interoperabilität in einzelnen beobachtbaren Schritten prüfbar: öffnen, Daten übertragen, schließen, ohne Neustart wiederholen und andere Implementierungen über ein Gateway erreichen.
  • Die Punkteliste ordnete nützliche Befunde, machte aus einem bestandenen Test aber weder einen universellen Korrektheitsbeweis noch ein Leistungsranking oder einen Nachweis tatsächlicher Nutzung.

Was als „korrekt“ galt, war noch Gegenstand der Debatte

Im September 1987 veröffentlichte Jon Postel einen kurzen, bemerkenswert offenen Rückblick darauf, wie TCP und IP geprüft wurden, während Software und Spezifikationen noch in Bewegung waren. Solange es nur wenige Implementierungen gab, so RFC 1025, ließ sich die „Korrektheit“ einer Implementierung praktisch nur feststellen, indem man sie mit einer anderen testete und anschließend darüber stritt, was das Ergebnis zeigte. Ein Test konnte den Code verändern. Die Diskussion konnte ebenso gut die Spezifikation verändern.

Damit verortet RFC 1025 den Bake-off weit entfernt von einem modernen Zertifizierungslabor. Ein fertiges Produkt wurde nicht an einem abgeschlossenen Regelwerk gemessen. Gegenstand war ein entstehendes Protokoll, das eine kleine Gruppe von Entwicklern gemeinsam voranbrachte. Sein Verhalten musste zwischen Maschinen sichtbar werden, bevor sich die Beschreibung im Dokument festigen konnte. Eine gescheiterte Verbindung war ein Hinweis, aber kein automatisches Urteil. Es blieb zu klären, ob der Code die Regel falsch verstand, die Regel unvollständig war oder der Test die falsche Frage stellte.

RFC 1025 ist ein Rückblick, kein minutengenaues Protokoll aller Treffen. Der Text verweist auf eine frühe Testliste im IEN 69 vom Oktober 1978, eine Demonstration von vier TCP-Implementierungen in Reston am 4. Dezember 1978, ein Treffen von sechs Implementierungen am USC Information Sciences Institute am 27. und 28. Januar 1979 sowie einen verteilten Bake-off über das Netzwerk im April 1980. Das 1987 veröffentlichte Memo gibt das Verfahren, die Tests und die Punktevergabe dieser Veranstaltung von 1980 mit nur leichten redaktionellen Änderungen wieder. Die Abfolge zeigt eine Praxis, die in mehreren Begegnungen entstand – keine offizielle Abschlussprüfung, die erst nach Fertigstellung der Protokolle angesetzt wurde. RFC 1025, IEN 69, IEN 77

Ein Gespräch bestand aus mehreren Schritten

Die erste Stufe begann beinahe bei null. Eine TCP-Implementierung erhielt einen Punkt, wenn sie eine Verbindung mit sich selbst öffnete, einen weiteren für das Senden und Empfangen von Daten und einen dritten für das ordentliche Schließen ohne Absturz. Die Wiederholung ohne erneute Initialisierung des TCP brachte zwei zusätzliche Punkte. Ein vollständiges Gespräch über ein Test-Gateway war fünf Punkte wert.

Die Staffelung trennte Vorgänge, die das schlichte Etikett „verbunden“ zusammengeworfen hätte. Der Verbindungsaufbau zeigte, dass beide Endpunkte Zustand herstellen konnten. Der Datenaustausch zeigte, dass dieser Zustand etwas Nützliches transportierte. Das ordentliche Schließen prüfte das Ende der Beziehung. Die Wiederholung ohne Neustart fragte, ob die Implementierung nach dem ersten Durchlauf weiterverwendbar blieb. Das Gateway fügte einen Vermittler und eine weitere Netzgrenze hinzu. Ein erfolgreicher erster Handshake beantwortete keine dieser Fragen vollständig.

In der mittleren Gewichtsklasse wurde der Schritt vom Selbsttest zur Interoperabilität ausdrücklich sichtbar. Öffnen, Datenaustausch und ordentliches Schließen mit einem anderen TCP brachten jeweils zwei Punkte; die Wiederholung ohne Neustart vier; das vollständige Gespräch über das Test-Gateway zehn. RFC 1025 erklärt, dass diese Möglichkeiten für jede angesprochene TCP-Implementierung galten. Das Beispiel nennt bis zu zwanzig Punkte pro weiterer Implementierung. Ziel war eine N-mal-N-Konnektivität: das Netz möglicher Beziehungen zu testen, statt nur zu zeigen, dass ein vorher ausgewähltes Paar miteinander sprechen konnte.

Dadurch ändert sich die Einheit des Befunds. Ein Ergebnis gilt für ein Paar von Implementierungen, einen bestimmten Pfad und eine konkrete Testbedingung. Wenn A mit B sprechen kann, folgt daraus weder, dass B auch mit C korrekt spricht, noch dass A über ein Gateway hinweg funktioniert, das die Paketzustellung verändert. Die Matrix machte Verbindungsnähte sichtbar, die eine einzelne Vorführung verdecken konnte.

Das Gateway durfte den Pfad absichtlich verschlechtern

Das prägnanteste Gerät in RFC 1025 heißt „Flakeway“: ein absichtlich unzuverlässiges Gateway, dessen Regler während des Betriebs festlegen konnten, welcher Anteil der Datagramme verworfen, verändert weitergeleitet oder vor der Zustellung umgeordnet wurde. Der Name ist spielerisch; der Zweck ist ernst. Der Pfad selbst wurde Teil des Experiments. Eine Verbindung, die nur auf einer sauberen Route funktionierte, lieferte einen engeren Befund als ein Austausch, der auch dann weiterging, wenn Pakete verschwanden, verändert wurden oder in anderer Reihenfolge ankamen.

Die Prüfsummenregel machte ein oberflächliches Bestehen schwerer. RFC 1025 verlangte, dass Prüfsummen aktiv geprüft wurden; war die Prüfung ausgeschaltet, gab es keine Punkte. Man konnte den Mechanismus, der Beschädigungen erkennen sollte, nicht deaktivieren und das Ergebnis als Erfolg verbuchen.

Die Schwergewichtsklasse ging weit über ein gewöhnliches Gespräch hinaus. Punkte gab es für gleichzeitige Verbindungen zu mehreren Gegenstellen, den Umgang mit dringenden Daten, den Umlauf der Sequenznummern und ein „Kamikaze“-Segment, das möglichst viele Headermerkmale kombinierte. Die Liste unterschied außerdem zwischen legalen Angriffen – Segmenten, die den Anforderungen der Spezifikation entsprachen – und schmutzigen Angriffen, die diese verletzten: Einen Gegner mit spezifikationskonformen Segmenten zum Absturz zu bringen, brachte 30 Punkte; mit regelwidrigen Segmenten waren es 20.

Das klingt nach Wettkampf, weil die Tests Grenzen in gegnerischen Interaktionen sichtbar machen sollten. Daraus folgt weder, dass ungültige Segmente zum normalen Betriebsfall wurden, noch dass ein einzelner Absturz ein allgemeines Risiko bewies.

Daneben gab es eine eigene IP-Klasse für Hosts und Gateways. Sie vergab Punkte für Fragmentierung und Wiederzusammensetzung, Source-Routing, Rückrouten, Routing-Hinweise, Source-Quench-Meldungen, Dienstkennzeichnungen und Optionen. Ebenfalls Punkte gab es, wenn ein Gateway erkannt wurde, das die TTL nicht verringerte, ein Datagramm mit TTL null weiterleitete oder eine Prüfsumme falsch behandelte. Die Trennung entsprach verschiedenen Aufgaben: TCP steuerte ein Gespräch zwischen Hosts; IP transportierte Datagramme über miteinander verbundene Netze und Gateways. RFC 793, RFC 791

Die Testliste ging weiter durch den Lebenszyklus und die Randfälle: eine Verbindung häufig öffnen und schließen; mehrere gleichzeitig betreiben und prüfen, ob ihre Daten getrennt bleiben; ein lokales TCP abstürzen lassen und dieselbe Verbindung erneut öffnen; einen Socket ansprechen, der Verbindungen ablehnt; an einen Empfänger mit Fenstergröße null senden; mit einem „Fire Hose“ Daten in schneller Folge schicken; dringende Daten testen; und die Sequenznummer über ihre Umlaufgrenze führen. Ein letzter Fall kombinierte ein ungewöhnliches Segment mit einer halb offenen Verbindung, kurz bevor die Sequenznummer umlief.

Netze arbeiten nicht nur unter sauberen Bedingungen. Entscheidend war, was geschah, wenn Regeln aufeinandertrafen, die für sich genommen einfach wirkten.

Eine Punktesumme hatte Grenzen

Punkte gab es auch für das längste Gespräch, die meisten gleichzeitigen Verbindungen und sogar für die beste Ausrede. Das machte den Bake-off einprägsam, erschwert aber die Deutung der Summe als einheitliche Rangliste. Manche Punkte maßen den grundlegenden Verbindungsablauf; andere zählten Funktionen, den Umgang mit Gateways oder die Fähigkeit, viele Gespräche gleichzeitig zu halten. Es waren keine verschiedenen Skalen für dieselbe Eigenschaft.

RFC 1025 räumt diese Grenze im letzten Abschnitt ein. Die vorangegangenen Tests prüften Grundfunktionen und einige schwierige Fälle, berücksichtigten aber weder Leistung noch die Einführung neuerer Ideen. Das Memo nennt die Verfahren von John Nagle, Van Jacobsons Slow Start und Messungen der Rundlaufzeit sowie SQuID-Verfahren als getrennte Themen. Danach folgen mögliche Leistungstests: eine Datei von einem Megabyte per FTP oder NETBLT über Ethernet oder ARPANET übertragen und die Rundlaufzeit eines Zeichens messen, das an den Echo-Server gesendet wird. Der Text warnt, dass solche Ergebnisse stark von den Testbedingungen abhängen. RFC 896, RFC 862

Diese Grenze ist wichtig. Punkte für Verbindungsaufbau, Datenaustausch und Abschluss mit bestimmten Gegenstellen sagten nichts darüber aus, wie schnell ein System auf einem anderen Pfad, unter anderer Last oder mit nicht geprüften Mechanismen arbeiten würde. Ein erfolgreicher Austausch zwischen zwei Systemen bewies auch nicht, dass alle Hosts dieselbe Software einsetzten, alle Installationen bestanden oder alle Randfälle abgedeckt waren. Der Befund hatte einen Geltungsbereich, und das Memo machte ihn sichtbar.

Der Test gehörte zum praktischen Leben des Protokolls

Die frühe Implementierungskultur des Internets wartete nicht auf eine saubere Trennung von Spezifikation und Betrieb. Der Bake-off bot eine wiederholbare Fläche, auf der sich Meinungsverschiedenheiten beobachten ließen: Dieser Endpunkt öffnete, jener nicht; dieses Paar arbeitete nach einem Neustart weiter; jenes Gateway behandelte einen Header falsch; ein beschädigtes Paket wurde erkannt – oder nicht. Daraus konnten eine Codekorrektur, eine Klarstellung des Textes oder eine Änderung der Regel folgen.

Dieser Rückkopplungskreis ist historisch aufschlussreicher als die Punkteliste selbst. Arithmetik machte das Netz nicht korrekt. Sie machte konkretes Verhalten zwischen Verantwortlichen unabhängiger Implementierungen besprechbar. Eine gemeinsame Regel gewann Bedeutung, wenn verschiedene Systeme sie tatsächlich ausüben konnten. Ein Test war nützlich, wenn seine Grenzen deutlich genug waren, dass Ingenieure darüber streiten konnten, was ein Ergebnis belegte – und was nicht.

Das spätere RFC bewahrte eine Momentaufnahme dieser Praxis. Es behandelte Kompatibilität als Netz von Gesprächen, Wiederherstellung als Abfolge eigener Lebenszyklusereignisse und Fehlerbehandlung als etwas, das auch auf dem Pfad und nicht nur an den Endpunkten geprüft werden musste. Die eigenen Einschränkungen verhinderten, dass die Matrix als vollständige Leistungsmessung oder als Test aller neuen TCP-Ideen erschien. So gelesen ist RFC 1025 weder ein Siegesbericht noch ein heutiges Konformitätszertifikat. Es zeigt, wie ein junges Internet „es funktioniert“ in eine Frage verwandelte, die andere Implementierungen anfechten konnten.

Quellen