Zusammenfassung
- Sender und Empfänger mussten die LZS-Historie für jedes Datagramm zurücksetzen; frühere Pakete durften keine Voraussetzung für spätere sein.
- Flush und Endmarke schlossen die aktuelle Codierung und trennten Padding, waren aber keine Zustell-, Integritäts- oder Identitätsbelege.
- Rund 90 Byte und die Calgary-Corpus-Tabelle waren begrenzte Messwerte; Transformvereinbarung, Paketauswahl, Größengewinn, Decodierung und Anwendungserfolg blieben getrennt.
Ein verlorenes Paket durfte kein Wörterbuch vergiften
LZS ersetzt wiederholte Folgen durch Verweise in ein gleitendes Fenster. In einem verlässlichen Strom ist eine lange Historie wertvoll. IP garantiert jedoch weder Reihenfolge noch Vollständigkeit. Verweist Paket zwei auf ein Wörterbuch aus Paket eins, macht dessen Verlust auch das unbeschädigt gelieferte zweite Paket unbrauchbar.
RFC 2395 verlangte deshalb vor jeder Kompression einen Reset und vor jeder Dekompression denselben Neustart. Wiederholungen innerhalb des Datagramms blieben nutzbar; paketübergreifende Abhängigkeiten verschwanden. Der Preis war eine geringere Chance auf Verdichtung, der Gewinn ein klarer Fehlerumfang.
RFC 1967 und RFC 1974 zeigen die Gegenprobe: PPP-Profile derselben LZS-Familie konnten nummerierte Historien und Synchronisationsregeln besitzen. Der Algorithmusname bestimmte nicht die Lebensdauer seines Zustands. Das Profil tat es.
Flush schloss die Eingabe, nicht die Übertragung
Ein Stromkompressor kann Ausgabe zurückhalten, um sie mit späteren Bytes günstiger zu codieren. RFC 2395 verbot diese Schuld: Bei jedem gesendeten komprimierten Datagramm musste der Kompressor geleert werden. Alle Eingabedaten gehörten in dieselbe Ausgabe.
Das war ein enger Beleg. Flush sagte, dass der Encoder nichts behielt. Es sagte nicht, dass das Netz zustellte, der Empfänger akzeptierte, die Dekompression gelang oder die Anwendung Nutzen hatte.
Eine definierte Endmarke trennte außerdem den LZS-Bitstrom von nachfolgendem Padding. Da die Übertragung ganze Oktette brauchte, konnte die eigentliche Codierung mitten im letzten Oktett enden. Die Marke löste diese Grammatikfrage. Sie war weder Hash noch Signatur und bestätigte keinen Absender.
Vereinbart bedeutete nicht immer verwendet
IPCOMP_LZS bezeichnete die Transformation in ISAKMP und bei manueller Zuordnung. Trotzdem blieb die allgemeine IPComp-Regel paketweise: War komprimierte Nutzlast samt Header nicht kleiner, musste das Original ohne IPComp-Header gesendet werden. RFC 3173 behielt diese Regel nach RFC 2393 bei.
Ein fehlender Header beweist daher kein Scheitern der Vereinbarung. Ein vorhandener Header beweist keine erfolgreiche Dekompression. RFC 2395 enthielt zudem keinen adaptiven Komprimierbarkeitstest. Lokales Überspringen schlecht geeigneter Daten war Implementierungspolitik.
Die Zahl 90 trug den Namen ihres Versuchs
Informelle Messungen am Calgary Corpus deuteten unter ungefähr 90 Byte auf mögliche Expansion. Die Tabelle reichte von 1,18 bei 64 Byte bis 2,14 bei 16.384 Byte. Größere Datagramme gaben dem frisch geleerten Fenster mehr Material und verteilten feste Kosten.
Das Corpus war aber kein verschlüsselter Strom, kein bereits komprimiertes Bild und kein Abbild des heutigen Netzes. RFC 2394 profilierte DEFLATE unter eigenen Bedingungen, RFC 3051 später einen anderen Wörterbuchansatz. RFC 3819 warnte vor geringem Nutzen bei bereits komprimierten oder verschlüsselten Daten. 90 Byte waren ein Messhinweis, keine Drahtkonstante.
Auch die Lizenz gehörte zur Adoptionsfläche
RFC 2395 erklärte 1998, Hi/fn halte Patente auf LZS, und beschrieb Lizenzmöglichkeiten. Das war für Implementierer relevant, änderte aber kein Bit. Es ist ein historischer Beleg, keine Aussage über heutige Eigentümer, Gültigkeit, Preise oder Verfügbarkeit.
Die gemeinsame Spezifikation blieb schmal: zurücksetzen, leeren, codieren, beenden. Schwellen, Wirtschaftlichkeit und Einführung blieben lokal. Laufende Pakete und Anwendungsergebnisse konnten diese Entscheidungen korrigieren.
Resilienz entstand durch verweigerte Erinnerung
RFC 2395 zwang IP nicht, sich wie ein zuverlässiger Strom zu verhalten. Es zwang den Kompressor, die Datagrammgrenze ernst zu nehmen. Damit wurde Optimierung nicht zu einer heimlichen Netzgarantie.
Für eine Prüfung braucht es getrennte Belege: verfügbare Transformation, etablierte Zuordnung, Reset, Paketentscheidung, korrekte Endmarke, wiederhergestellte Bytes und Anwendungsergebnis. Keiner ersetzt den nächsten.
Quellen
- RFC 2395 — IP Payload Compression Using LZS
- RFC-Editor-Eintrag zu RFC 2395
- IETF-Datatracker-Verlauf zu RFC 2395
- RFC-Editor-Errata zu RFC 2395
- RFC 2393 — IP Payload Compression Protocol
- RFC 3173 — IP Payload Compression Protocol
- RFC 1967 — PPP LZS-DCP Compression Protocol
- RFC 1974 — PPP Stac LZS Compression Protocol
- RFC 2394 — IP Payload Compression Using DEFLATE
- RFC 2407 — Internet IP Security Domain of Interpretation for ISAKMP
- RFC 3051 — IP Payload Compression Using ITU-T V.44 Packet Method
- RFC 3819 — Advice for Internet Subnetwork Designers
- Heng Lu — Running-Code Primacy
- Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
- Heng Lu — Reality Layers, Symbolic Power, and Clarity
Mitgliederbriefing
Detaillierter Profilkontext
Melden Sie sich mit der richtigen Mitgliedschaftsstufe an, um das vollständige Briefing und die Quellennotizen freizuschalten.
Nur für Strategic Circle
Strategic Circle
Offen für alle Leser. Schalten Sie Profil-Briefings nach Beitritt und Anmeldung frei.
Strategic Circle beitretenNur für Leadership Alliance
Leadership Alliance
Für qualifizierte Inhaber von IP-Assets und Management; melden Sie sich an, um Leadership-Alliance-Briefings freizuschalten.
Leadership Alliance beitreten
