Zusammenfassung

  • RFC 1553 konnte den 30 Oktette langen IPX-Header auf ein bis sieben Oktette und einen 36-Oktett-NCP/IPX-Header auf ein bis acht reduzieren. Die ausgelassenen Felder blieben als korrespondierende Slot-Zustände bei Kompressor und Dekompressor erhalten.
  • Allgemeiner IPX-Kontext durfte erst nach Confirmed Initial und Confirm komprimierte Folgepakete tragen. Der engere unbestätigte NCP-Pfad stützte sich stattdessen auf Sequenz- und Wiederholungsverhalten, das einen Kontextbruch sichtbar machen konnte.
  • Die ungefähr mit 2:1 bezifferte Einsparung war eine Beispielrechnung mit angenommenen Paketgrößen. Sie enthielt weder gemessenen Verkehr noch die Kosten von Initials, Bestätigungen, Verlusten, Rejects, Rückfallformaten oder Resynchronisation.

Eine richtige Division kann die falsche Behauptung tragen

Die Beispielzahlen in RFC 1553 sind leicht nachzurechnen. Ein kleines Paket mit 26 Oktetten Daten und einem normalen IPX-Header von 30 Oktetten umfasst zusammen 56 Oktette. Wird der Header in diesem Beispiel auf zwei Oktette verkürzt, bleiben 28. Das Verhältnis ist zwei zu eins.

Keine Zahl daran ist mathematisch falsch. Die mögliche Irreführung beginnt erst beim Namen des Ergebnisses. Aus einer Modellrechnung wird schnell „die Kompression verdoppelte die Effizienz“, daraus „CIPX erzielte in Weitverkehrsnetzen 2:1“ und schließlich eine vermeintliche Betriebserfahrung. Die Quelle belegt nur die erste, engste Aussage: Unter den ausdrücklich angenommenen Größen halbiert sich die betrachtete Bytezahl.

Was die Rechnung nicht enthält, ist für den Mechanismus entscheidend. Sie zählt nicht, wie oft ein vollständiges Initial gesendet werden musste, wie oft ein Confirm ausblieb, wie häufig Slots neu belegt wurden, wie viele Pakete nach einem Verlust verworfen wurden oder wie oft ein reguläres Format die kurze Darstellung ersetzte. Sie sagt nichts über CPU-Aufwand, Laufzeit, Anwendungswiederholungen oder eine installierte Basis.

Gerade deshalb eignet sich die Rechnung als Schlüssel zum gesamten Dokument. Header-Kompression verschiebt Kosten, statt sie einfach zu vernichten. Die Bytes auf dem Link werden weniger; dafür müssen zwei Endpunkte denselben historischen Zustand besitzen und jede Abweichung so behandeln, dass aus einer günstigen Abkürzung keine still falsche Rekonstruktion wird.

Der sichtbare Header war nur die Spitze des Zustands

RFC 1553 erschien im Dezember 1993 als Standards-Track-Dokument und wird vom RFC Editor heute als Historic geführt. Sein Titel lautete Compressing IPX Headers Over WAN Media, abgekürzt CIPX. Der dokumentarische Status sagt etwas über die Veröffentlichungsgeschichte, nicht darüber, welche Produkte oder Netze den Mechanismus tatsächlich verwendeten.

Das Dokument legte zwei Strategien fest. Das allgemeine Verfahren konnte einen 30 Oktette langen IPX-Header auf ein bis sieben Oktette reduzieren. Ein zweites verpflichtendes Verfahren richtete sich an NCP-Anfragen und -Antworten der Typen 0x2222 und 0x3333. Es behandelte den kombinierten 36-Oktett-NCP/IPX-Header und brachte ihn auf ein bis acht Oktette. Andere NCP-Typen konnten weiterhin das allgemeine IPX-Verfahren nutzen, erhielten aber nicht automatisch die spezialisierten Annahmen.

Die ausgelassenen Felder waren weiterhin nötig. Der Dekompressor musste einen vollständigen Header an die nächste Schicht übergeben. Dafür hielten beide Seiten Tabellen. Der Kompressor speicherte vollständige Header in Sendeslots, verglich neue Header mit ihnen und übertrug Änderungen. Der Dekompressor bewahrte die korrespondierenden Empfangsslots auf und setzte aus altem Inhalt und übermitteltem Delta den vollständigen Header zusammen.

Ein Ein-Oktett-Paket war deshalb nicht selbstgenügsam. Sein Flag-Oktett war ein Verweis auf gemeinsam gepflegte Vorgeschichte. Nur wenn Slot, Generation und alle geerbten Werte auf beiden Seiten übereinstimmten, hatte das kurze Muster eine eindeutige Bedeutung.

Nach der Aushandlung von CIPX trug selbst ein regulär und unkomprimiert gesendetes IPX-Paket das CIPX-Flag-Oktett. Der Link hatte nicht bloß ein Menü unabhängiger Kurzformen erhalten. Er befand sich in einem zustandsbehafteten Gespräch, in dem auch die lange Form eine definierte Rolle spielte.

Zwei Kompressionsstufen verlangten eine nachweisbare Reihenfolge

CIPX konnte zusammen mit Datenkompression eingesetzt werden. Die Operationen mussten jedoch in einer bestimmten Reihenfolge stattfinden. Beim Senden kam zuerst die Header-Kompression, danach die Datenkompression. Beim Empfangen wurde die Reihenfolge umgekehrt: zuerst Daten dekomprimieren, anschließend den Header rekonstruieren.

Diese Reihenfolge ist nicht nur Implementierungsdetail. Sie bestimmt, was ein beobachtetes Bytebild bedeutet. Eine Aufzeichnung zwischen beiden Schritten zeigt einen anderen Gegenstand als die Ausgabe nach vollständiger Rekonstruktion. Ohne Angabe des Beobachtungspunkts lässt sich eine Änderung womöglich der falschen Funktion zuschreiben.

Wer lediglich den fertig rekonstruierten Header speichert, verliert außerdem die Herkunft seiner Felder. Später ist nicht mehr zu erkennen, welcher Wert tatsächlich im Paket stand, welcher als Delta kam und welcher aus einem Slot übernommen wurde. Eine reproduzierbare Aufzeichnung braucht daher die Transformationen und den Zustand, nicht allein ihr bequemes Endprodukt.

Die Schichten helfen einander, ohne ihre Aussagen zu verschmelzen. Erfolgreiche Daten-Dekompression bestätigt keinen Slot. Ein bestätigter Slot beweist keine erfolgreiche Anwendung. Eine ausgehandelte Option beweist keine korrekte Rekonstruktion. Wer diese Grenzen im Monitoring zusammenzieht, erzeugt eine umfassendere Behauptung, als irgendein Mechanismus liefern kann.

Ein Slot brauchte eine Generation

Slots mussten wiederverwendbar sein. Eine Verbindung endet, eine andere beginnt, und der begrenzte Tabellenplatz erhält einen neuen vollständigen Header. Wäre allein die Slotnummer maßgeblich, könnte ein verspätetes Paket aus der alten Belegung in der neuen plausibel aussehen.

Deshalb verband RFC 1553 die Slotnummer mit einer ein Oktett langen ID. Wurde dem Slot ein neuer Header zugewiesen, erhöhte sich die ID. Slot und ID bezeichneten gemeinsam eine Generation. Sie sagten nicht nur „nimm Fach fünf“, sondern „nimm die konkrete Belegung von Fach fünf, die zu dieser ID gehört“.

Ein Oktett kann sich wiederholen. Der Text sprach daher von einer „angemessen langen“ Eindeutigkeit und machte sie von Linkgeschwindigkeit, Umlaufzeit und Last abhängig. Das war eine operative Fensterannahme, kein ewiger Identitätsnachweis. Je schneller Slots wiederbelegt wurden oder je länger alte Pakete unterwegs blieben, desto wichtiger wurde die Grenze.

Der Kompressor musste während des Wartens nicht zwangsläufig Nutzdaten zurückhalten. Er konnte denselben Slot und dieselbe ID mit neuen Daten zum gleichen Header erneut senden. Er konnte den Slot mit erhöhter ID auch einem anderen Header zuweisen. Fortschritt blieb möglich, aber ein Wechsel durfte seine Generation nicht verbergen.

Allgemeines IPX verlangte eine bestätigte Ausgangsbasis

Beim allgemeinen IPX-Verfahren war der Verlust des ersten Kontextpakets gefährlich. Der gewöhnliche IPX-Header besaß keine hinreichende Sequenzinformation, aus der der Empfänger zuverlässig auf die fehlende Einführung und ihre Wiederholung schließen konnte. Der Sender hätte auf neuer Grundlage komprimieren können, während der Empfänger noch die alte oder gar keine Grundlage besaß.

Der Confirmed Initial übermittelte deshalb den vollständigen Header, die Slotnummer und die Generations-ID. Der Empfänger antwortete mit Confirm. Erst wenn diese Bestätigung eingetroffen war, durfte der Kompressor weitere Pakete senden, die für ihre Rekonstruktion von dieser Zuordnung abhingen.

Die Bestätigung machte aus lokaler Speicherung einen begrenzten gemeinsamen Tatbestand. Sie bewies jedoch weder spätere Paketzustellung noch Anwendungserfolg. Sie sagte nicht, dass ein Fehlerzähler vollständig war, dass jedes Delta richtig verarbeitet wurde oder dass die rekonstruierte Prüfsumme akzeptiert wurde. Sie galt für die Etablierung genau dieser Kontextgeneration.

Das ist eine nützliche Schranke gegen Statusinflation. „CIPX ausgehandelt“ ist nicht „Initial bestätigt“. „Initial bestätigt“ ist nicht „Tabellen bleiben synchron“. „Header rekonstruiert“ ist nicht „Transport erholt“. „Gute Kompressionsrate“ ist nicht „gute Dienstleistung“. Jede Stufe hat einen anderen Beleg und einen anderen Eigentümer.

NCP ersetzte das Warten durch eine andere Fehlerquelle

Für die spezialisierten NCP-Anfragen und -Antworten ließ RFC 1553 einen Unconfirmed Initial zu. Der Kompressor durfte die Initial-Nachricht senden und unmittelbar mit komprimierten Paketen fortfahren. Das war keine pauschale Behauptung, unbestätigter Kontext sei zuverlässig.

NCP brachte Sequenznummern und Wiederholungsverhalten mit, die einen Kontextbruch sichtbar machen konnten. War eine beobachtete Sequenz nicht genau um eins höher als erwartet, musste eine neue Initial-Nachricht folgen, selbst wenn derselbe Slot weiterverwendet wurde. Das Verfahren verzichtete auf einen expliziten Empfangsbeleg, weil eine konkrete andere Schicht einen Teil der Fehlererkennung und Erholung übernehmen konnte.

Die Ausnahme war damit an eine Eigenschaft gebunden, nicht an eine Präferenz für Geschwindigkeit. Überträgt man sie auf Verkehr ohne dasselbe Sequenz- und Wiederholungsverhalten, bleibt nur das Risiko, nicht aber seine Begrenzung. Wer ein Bestätigungsschritt entfernen will, muss genau benennen können, welches andere Signal dessen fehlende Information ersetzt.

Auch für die Leistungsrechnung macht das einen Unterschied. Unbestätigtes NCP kann Bestätigungswartezeit vermeiden, aber Sequenzsprünge und neue Initials bleiben Teil des tatsächlichen Pfads. Ein Modell, das nur den kleinsten Header zählt, misst nicht die Bedingungen, unter denen er dauerhaft benutzt werden kann.

Das letzte Slot-Oktett kostete Fehlertransparenz

Nach der Reduktion stabiler Felder bot sich eine weitere Einsparung an: Auch die Slotnummer konnte entfallen. Dann bedeutete ein Paket sinngemäß „verwende denselben Slot wie beim vorigen Paket“. Solange beide Seiten dieselbe lückenlose Folge sahen, war das eindeutig.

Ging ausgerechnet das Paket verloren, das den Slot gewechselt hatte, besaß „vorig“ zwei Bedeutungen. Der Sender erinnerte sich an den neuen Slot; der Empfänger, der das Wechselpaket nicht sah, blieb beim alten. Die nächsten Bitfolgen konnten formal ordentlich ankommen und dennoch auf verschiedene vollständige Header angewandt werden.

Darum war Slotnummern-Kompression standardmäßig deaktiviert. Sie durfte nur aktiv werden, wenn die PPP-Linkschicht dem Dekompressor jedes fehlerhafte oder verworfene Paket meldete. Ein später aggregierter Verlustzähler genügte nicht. Derjenige, der den Begriff „voriger Slot“ verwaltete, musste den Bruch an der richtigen Stelle der Sequenz erfahren.

Nach einer solchen Meldung durfte der Dekompressor nicht raten. Er musste alle folgenden Pakete ohne explizite Slotnummer verwerfen, bis ein Paket den Slot wieder ausdrücklich nannte. Möglicherweise wäre eine Vermutung zufällig richtig gewesen. Das Protokoll bevorzugte dennoch einen sichtbaren, begrenzten Verlust gegenüber einer stillen Rekonstruktion aus unbekannter Geschichte.

Die Fehlerbeobachtung war damit Bestandteil der Formatgültigkeit. Sie war kein optionales Dashboard, das ein Betreiber später ergänzen konnte. Wer das Slot-Oktett sparte, ging eine neue Abhängigkeit zwischen Linkschicht und Dekompressor ein. Ohne verlässliche Benachrichtigung war die Einsparung semantisch nicht abgesichert.

Neustart und Reject begrenzten die Lebensdauer alter Gewissheit

Ein Endpunkt konnte neu starten, seine Tabelle verlieren und wieder gewöhnliches IPX senden, während die Gegenseite noch CIPX-Zustand hielt. Ein normaler IPX-Header begann beim üblichen fehlenden Checksum mit 0xFFFF. RFC 1553 reservierte 0xFF so, dass dieser Beginn vom CIPX-Flagraum unterschieden werden konnte.

Die nicht neu gestartete Seite sollte den Rückfall erkennen und die Kompression neu aushandeln. Sie durfte den gewöhnlichen Header nicht mit alter Slotgeschichte vervollständigen. Der Mechanismus gab dem gespeicherten Kontext ein sichtbares Ende: Neustart entzog ihm die Grundlage.

Für unbekannte Pakettypen oder abhängige Flags gab es Reject-Pakete. Sie teilten dem Kompressor mit, welche Funktion der Empfänger nicht verstand. Erweiterungsunterschiede sollten als Ablehnung auftreten, nicht als still voneinander abweichende Tabellen.

Reguläres Format, Reject und Neuaushandlung bildeten Ausgänge aus dem komprimierten Zustand. Ein Ausweg ist kein Zeichen mangelnder Effizienz. Ohne ihn würde die Abkürzung zum Lock-in: Kommunikation wäre nur noch möglich, wenn beide Seiten Übereinstimmung behaupten. Mit ihm konnte ein Unterschied sichtbar werden und der Link zu einer gemeinsam verständlichen Form zurückkehren.

Zwei Verhandlungswege erzeugten unterschiedliche Nachweise

Unter PPP wurde CIPX über eine IPXCP-Konfigurationsoption ausgehandelt. Die Kompression war zunächst aus. Jede Seite forderte ihre Empfangsfähigkeit für eine Richtung an. Bidirektionaler Betrieb verlangte daher zwei gerichtete Anfragen; ein Erfolg in Richtung A nach B belegte B nach A nicht.

IPX-WAN führte dagegen zu einem symmetrischen Ergebnis. Beide Richtungen verwendeten dieselbe Slotzahl und einen gemeinsam akzeptierten Teil der Optionen. Die Symmetrie ersparte jedoch keine spätere Zustandsprüfung. Sie sagte nichts darüber, ob eine bestimmte Initial-Nachricht bestätigt, eine Generation korrekt gehalten oder ein Anwendungsergebnis erreicht wurde.

Ein belastbarer Nachweis muss die jeweilige Verhandlungsgeometrie erhalten. Bei PPP sind Richtung und jeweiliger Antrag unverzichtbar. Bei IPX-WAN interessieren der gemeinsame Auswahlweg und die symmetrische Grenze. Ein einziges Feld „compression=yes“ verwischt genau die Entscheidung, die der Standard getrennt hielt.

Was in der 2:1-Rechnung fehlt

Das Beispiel mit 56 und 28 Oktetten stellt eine mögliche Byteersparnis dar. Für einen Betriebswert wären mindestens die tatsächliche Verteilung der Nutzdatenlängen und der komprimierten Headergrößen nötig. Hinzu kämen Häufigkeit und Größe vollständiger Initials, Confirms, regulärer Pakete und Rejects.

Verluste verändern den Nenner und das Ergebnis zugleich. Nach einem gemeldeten Fehler können Pakete mit implizitem Slot verworfen werden, bis eine explizite Auswahl eintrifft. Diese Bytes wurden vielleicht besonders effizient übertragen und liefern dennoch keinen Nutzen. Anwendungsschicht-Wiederholungen können weitere Last erzeugen, die ein reiner CIPX-Zähler nicht sieht.

Auch Zeit gehört zur Bilanz. Ein Header kann kürzer sein, während Resynchronisation die Antwort verzögert. Rechenaufwand und Tabellenwechsel können auf einem System anders wirken als auf einem anderen. Ohne Messpunkt, Verkehrskorpus und Zeitraum bleibt die Verhältniszahl ein Szenario, kein Produktionsbeleg.

Der knappe Sicherheitshinweis des RFC ist ähnlich eng zu lesen. Das Dokument erklärte, CIPX ändere die grundlegende Sicherheit von IPX nicht wesentlich. Das ist die damalige Bereichseinschätzung, keine moderne Zusicherung für jede Implementierung, fehlerhafte Eingabe, Schichtenkombination oder spätere Umgebung.

Die eingefrorenen Quellen nennen keine konkrete CIPX-Installation, keine installierte Basis, keinen Paketdatensatz, keinen Interoperabilitätstest, keinen Vorfall und kein Nutzerergebnis. Sie belegen Spezifikation und Dokumentgeschichte. Jede weitergehende Erfolgserzählung müsste eine andere Belegkette mitbringen.

Ein kürzerer Header verlangte eine längere Quittung

Eine vollständige Aufzeichnung beginnt mit Verhandlungseigentümer und Richtung, ausgewählten Optionen und Slotzahl. Sie umfasst Slot-Zuweiser und Generations-ID, den vollständigen Initial-Header, das erforderliche Confirm oder den eng begrenzten NCP-Ersatz sowie die Fehlertransparenz der Linkschicht.

Danach folgen akzeptierte Paketreihenfolge, expliziter oder impliziter Slot, Herkunft von Länge und Checksum, ein Hash des rekonstruierten Headers, die Entscheidung des Dekompressors, Transporterholung und Anwendungsergebnis. Diese Felder sind kein bürokratischer Zusatz. Sie sind der Ort, an den die ausgelassenen Bytes ihre Beweislast verschoben haben.

RFC 1553 verkürzte den Drahtausdruck, nicht die Kette der Verantwortung. Das Ein-Oktett-Format funktionierte nur, weil außerhalb des Pakets mehr bekannt war. Wer den Gewinn messen will, muss deshalb nicht nur zählen, was nicht mehr gesendet wurde, sondern auch, welche gemeinsame Geschichte den fehlenden Inhalt ersetzte und was ihre Wiederherstellung kostete.

Quellen