Zusammenfassung

  • Die 1984 beschriebene 4.2BSD-Konfiguration entschied beim Start pro Schnittstelle über Trailer. Eine solche Entscheidung war gröber als die unterschiedlichen Fähigkeiten ihrer Nachbarn.
  • Die umgestellte Anordnung sollte dem Empfänger Kopierarbeit im Speicher ersparen. Sie veränderte weder die Bedeutung eines TCP-Datenstroms noch die Reihenfolge, die höhere Protokolle nach der Rekonstruktion sahen.
  • RFC 1122 verlangte 1989 bestätigte Unterstützung beider Linkpartner und ohne dynamische Aushandlung pro Ziel eine abgeschaltete Voreinstellung. Zusätzliche ARP-Antworten lieferten dafür begrenzte Fähigkeitsinformationen.

Eine Schnittstelle, mehrere Implementierungen

Der Unterschied zwischen einem Schalter und einer Erkenntnis ist leicht zu übersehen. Ein Schalter legt fest, was die eigene Software tun soll. Er sagt noch nichts darüber, was die Software auf der anderen Seite versteht. Auf einem gemeinsam genutzten Ethernet können beide Fragen sehr unterschiedlich beantwortet werden.

RFC 893 beschrieb im April 1984 eine Trailer-Kapselung, die damals unter anderem 4.2BSD UNIX verwendete. In der geschilderten Implementierung wurde beim Systemstart pro Schnittstelle gewählt, ob Trailer gesendet werden sollten. Das setzte passende Kooperation auf dem gemeinsamen Medium voraus; andernfalls sollte diese Schnittstelle keine Trailer übertragen.

Die Autoren diskutierten eine feinere Möglichkeit: Über eine Erweiterung von ARP könnten einzelne Nachbarn ihre Bereitschaft bekannt machen. Auch der im selben Monat erschienene RFC 894 erwartete eine Änderung in diese Richtung. Die Texte belegen diesen damaligen Stand, nicht eine unveränderliche Eigenschaft sämtlicher BSD-Versionen.

Warum lohnte sich der Aufwand für eine andere Paketform überhaupt? Nicht weil Ethernet plötzlich schneller werden sollte. Der erhoffte Gewinn lag im Speicher des Empfängers.

Der variable Header vor der festen Seite

Beim Empfang können Daten mehrfach innerhalb des Speichers kopiert werden: zwischen Gerät und Speicher oder zwischen Betriebssystem und Benutzeradressraum. Bei geeigneter virtueller Speicherverwaltung lässt sich ein Teil dieser Arbeit vermeiden, indem Seiten neu zugeordnet werden, statt jedes Byte an einen anderen Ort zu schreiben.

Eine solche Möglichkeit benötigt passende Grenzen. Unter den von RFC 893 behandelten Voraussetzungen sollen Daten auf einer Seitengrenze beginnen und ein Vielfaches der Seitengröße umfassen oder entsprechend aufgefüllt sein. Die konkreten Bedingungen hängen von Architektur und Schutzmechanismen ab. Es ging nicht um ein bedingungsloses Versprechen kopierfreien Empfangs.

Vor den Daten stehen jedoch Header. Die Präambel der Link-Kapselung kann fest sein, während IP-, TCP- oder andere übergeordnete Header ihre Länge ändern. Damit verschiebt sich der Datenanfang. Eine sorgfältig gewählte Pufferposition allein löst das Problem nicht, wenn die vorausgehenden Felder unterschiedlich viel Platz benötigen.

Trailer verlagerten diese variablen Header hinter den Datenbereich. Der Sender ordnete das Linkpaket so an, dass der Empfänger bessere Voraussetzungen für die Seitenausrichtung erhielt. Kleine Header konnten weiterhin eigene Kopierarbeit verursachen; entscheidend war, die größere Datenmenge günstiger zu behandeln.

Das VAX-Beispiel mit 512 Datenbytes in RFC 893 erklärt eine historische Architektur. Es bestimmt weder heutige Seitengrößen noch eine überall gleiche Länge von TCP/IP-Headern. Ebenso wenig liefert die Darstellung einen von uns gemessenen Leistungsgewinn auf heutiger Hardware.

Hinten auf dem Draht, vorne im Protokoll

Die Umstellung blieb innerhalb desselben Linkpakets. Der Trailer war kein später eintreffendes zweites Paket und kein Dateianhang einer Anwendung. Linktyp und Positionsinformation ermöglichten es dem Empfänger, den hinteren Abschnitt zu finden. Dort standen Angaben zum ursprünglichen Protokoll und zur Headerlänge sowie die verlagerten Header selbst.

Die Empfangssoftware entfernte die kapselungsspezifischen Bestandteile und stellte die gewöhnliche Anordnung für die höheren Schichten wieder her. TCP erhielt deshalb nicht plötzlich eine andere Bedeutung seiner Sequenznummern. Die Anwendung musste von der lokalen Umordnung nichts wissen.

Der Vergleich mit RFC 894 ist wichtig: Beim gewöhnlichen IP über Ethernet folgt der IP-Inhalt unmittelbar auf den IP-Header. Ein Rechner, der diese Form lesen kann, versteht nicht automatisch die alternative Anordnung. Dieselbe Nutzlast macht zwei Darstellungen nicht ohne zusätzliche Verarbeitung austauschbar.

Auch die zulässige Paketgröße wächst durch Umordnen nicht. Die verifizierte technische Korrektur 570 berichtigt in RFC 894 die Bezeichnung von 1500 Bytes als Minimum zu Maximum. Die Füllbytes für die Ethernet-Mindestlänge zählen wiederum nicht zur IP-Gesamtlänge. Kapazität, Padding und Lage des Headers sind getrennte Fragen; Trailer waren kein Freibrief, die Linkgrenze zu überschreiten.

Die Rechnung gehört dem Empfänger

RFC 893 nennt Bedingungen, unter denen die Optimierung sinnvoll sein kann. Der Empfänger muss sie unterstützen und wollen. Die Ausrichtung darf nicht mehr kosten, als sie einspart. Die verlagerten Header sollten im Verhältnis zum Datenbereich klein bleiben. Und die vermiedene Kopierarbeit muss die zusätzliche Softwarekomplexität rechtfertigen.

Ein weiterer Preis besteht darin, den Header später zu sehen. Wer auf seine Informationen angewiesen ist, muss zunächst das ganze Paket puffern. Eine Implementierung, die früh anhand des Headers ablehnen oder Empfangsressourcen auswählen kann, verliert damit eine Gelegenheit.

Das historische Dokument erkennt die verzögerte Typbestimmung als berechtigten Einwand an. Für den dort diskutierten DMA-Fall argumentiert es, dass ohnehin zunächst das gesamte Paket empfangen werde. Das ist eine bedingte Antwort für diesen Verarbeitungspfad, keine allgemeine Aussage über alle heutigen DMA-Geräte.

Die Vorteile waren also nicht gleichmäßig verteilt. Ein Sender konnte einem Nachbarn eine hilfreiche Anordnung anbieten und einem anderen damit lediglich neue Arbeit aufbürden. Diese Asymmetrie erklärt, weshalb die Zustimmung des Empfängers Teil der Technik war und nicht bloß eine höfliche Begleitregel.

Aus einer Netzannahme wird Wissen über einen Partner

Schon RFC 894 stellte klar: Ein Host musste Trailer nicht implementieren. Zustimmende Systeme auf demselben Ethernet durften sie verwenden, ein Sender benötigte aber positive Kenntnis, dass sein Empfänger sie interpretieren konnte.

RFC 1122 präzisierte im Oktober 1989 die Betriebsgrenze. Trailer blieben optional. Beide Teilnehmer der Linkkommunikation, Host oder Gateway, mussten nachweislich dafür eingerichtet sein. Ohne dynamische Aushandlung pro Ziel musste die Standardkonfiguration die Verwendung deaktivieren.

Das war weder ein allgemeines Verbot noch eine Verpflichtung zur Modernisierung aller Nachbarn. Ein passendes Paar konnte die besondere Form nutzen, während andere weiter die normale erhielten. Die Entscheidung sollte nicht mehr Wissen voraussetzen, als tatsächlich über den jeweiligen Partner vorlag.

Aus den beiden Dokumentationsständen lässt sich allerdings kein universelles Einführungsdatum ableiten. Sie zeigen eine 1984 beschriebene grobe Konfiguration und eine 1989 spezifizierte feinere Austauschregel. Welche Version welche Funktion zuerst auslieferte, ist damit nicht für sämtliche Systeme geklärt.

ARP ergänzt eine Aussage, nicht den ganzen Vertrag

Die gewöhnliche ARP-Aufgabe bleibt begrenzt. Nach RFC 826 wird eine Protokolladresse des nächsten Partners auf dem ausgewählten Link einer Hardwareadresse zugeordnet. Dabei sind der äußere Ethernet-Typ für ARP, das Protokollfeld innerhalb der ARP-Nachricht und der Operationscode für Anfrage oder Antwort unterschiedliche Felder.

Die von RFC 1122 beschriebene Erweiterung ließ den normalen IP-ARP-Austausch normal ablaufen. Ein williger Empfänger sendete zusätzlich eine Trailer-ARP-Antwort: gewöhnliche Antwortstruktur, aber ein Trailer-Protokolltyp im ARP-Inhalt. Es war kein Ersatz für jede normale IP-Antwort und erforderte nicht zuerst eine Trailer-ARP-Anfrage.

Beide Rollen konnten ihre Empfangsfähigkeit mitteilen. Der Empfänger einer normalen Anfrage konnte die zusätzliche Antwort zusammen mit seiner IP-Antwort senden. Der ursprüngliche Fragesteller konnte seinerseits eine solche Nachricht schicken, wenn die zugehörige normale Antwort eintraf. Die Mitteilung beschrieb jeweils die Bereitschaft des Absenders, Trailer zu empfangen.

Ein entsprechend konfigurierter Host konnte diese Information etwa als Kennzeichen im ARP-Eintrag des Partners speichern. Sie war weder ein Leistungszertifikat noch eine kryptografische Beglaubigung. Auch bestätigte sie nicht die Zustellung von Anwendungsdaten.

Der räumliche Geltungsbereich blieb der Link. RFC 1009 erläuterte im Juni 1987 unter anderem Proxy ARP: Ein Gateway kann für ein erreichbares Ziel außerhalb des Links mit seiner eigenen Schnittstellenadresse antworten. Die dabei gewonnene lokale Partnerinformation darf deshalb nicht in eine Fähigkeitszusage des entfernten Endsystems oder des gesamten Pfades umgedeutet werden.

Eine Antwort braucht einen Anlass, der endet

Die zusätzliche Antwort führte zu einer eigenen Zustandsfrage. Ein fehlerhaft arbeitender Host konnte auf eine Trailer-ARP-Antwort mit einer normalen IP-ARP-Antwort reagieren. Würde deren Empfänger jede IP-Antwort wiederum mit einer Trailer-Antwort beantworten, könnten die Nachrichten einander fortlaufend auslösen.

RFC 1122 begrenzte deshalb diesen Zweig: Eine Trailer-Antwort nach einer IP-Antwort war nur vorgesehen, wenn letztere eine noch offene Anfrage beantwortete. Vor der Verarbeitung war die Hardwareadresse in diesem Fall noch nicht bekannt. Eine zusätzliche Trailer-Antwort zusammen mit der normalen Antwort auf eine eingegangene Anfrage blieb ein anderer, zulässiger Fall.

Der Schutz beruhte damit auf dem Zusammenhang zwischen Nachricht und offener Arbeit. Er ist nicht als erfundener Timer, Wiederholungszähler oder neues Authentisierungsverfahren zu lesen. Der lokale Zustand verhinderte, dass ein abgeschlossener Austausch immer neuen Anlass lieferte.

Teilweiser Erfolg konnte täuschen

RFC 1122 warnte außerdem vor einer schwer einzuordnenden Inkompatibilität: Trailer wurden nur für Pakete mit bestimmten Größenmerkmalen gewählt. Im beschriebenen Fall konnte ein kleiner Anteil betroffen sein, während gewöhnlich gekapselte Pakete ankamen. Das Netz wirkte dann zugleich funktionsfähig und defekt.

Daraus folgt nicht, dass alle großen Pakete scheiterten oder jede größenabhängige Störung auf Trailer zurückgeht. Die Hypothese benötigt Belege zur tatsächlich gewählten Kapselung und zur Gegenstelle. Der dokumentierte Mechanismus war ein Formatunterschied, nicht automatisch ein zu kleines MTU-Limit.

Ein erfolgreicher kurzer Austausch hatte deshalb nur begrenzte Aussagekraft. Er konnte genau den besonderen Empfangspfad umgehen, dessen Verträglichkeit noch ungeprüft war. Der grobe Schnittstellenschalter verbarg diese Unterscheidung; die Aushandlung pro Partner machte sie ausdrücklicher.