1. Introduction (Einführung)

1. Introduction (Einführung)

Dieses Dokument beschreibt ein IP-Header-Komprimierungsverfahren für langsame serielle Verbindungen.

Header-Komprimierung ist für langsame und mittelschnelle Verbindungen wichtig, da sie folgendes ermöglicht:

• Die maximal übertragbare Einheit (Maximum Transmission Unit, MTU) auf der Verbindung so klein wie möglich zu halten

  Die MTU ist die maximale Paketgröße, die ohne Fragmentierung über eine Verbindung übertragen werden kann. Eine kleine MTU ist für langsame Verbindungen wichtig, um zu verhindern, dass verzögerungsempfindlicher interaktiver Datenverkehr hinter großen Bulk-Transfer-Paketen zurückbleibt. Um beispielsweise die Warteschlangenverzögerung auf 200 ms zu begrenzen, MUSS auf einer 9600-bps-Verbindung eine MTU von weniger als 240 Oktetten verwendet werden. Auf einer solchen Verbindung verlangt IPv6 jedoch eine Mindest-MTU von 1280 Oktetten; IPv4 schreibt keine kleine MTU vor. Bei Verwendung mit Verbindungen mit kleiner MTU ist eine Fragmentierung auf der langsamen Verbindung erforderlich. Wenn Pakete auf einer langsamen Verbindung fragmentiert werden, müssen zusätzliche Header gesendet werden: Die in den Headern verwendeten Bytes summieren sich über alle Fragmente zu mehr als dem ursprünglichen Header. Die Header-Komprimierung kann die Anzahl dieser zusätzlichen Header-Bytes erheblich reduzieren, insbesondere wenn das ursprüngliche Paket klein ist, und verringert dadurch die Zeit zum Senden des Pakets, wodurch die maximale MTU erhöht wird, die auf der langsamen Verbindung verwendet werden kann.

• Kleine Pakete für verzögerungsempfindlichen Datenverkehr mit niedriger Datenrate zu ermöglichen

  Für solche Anwendungen, z. B. Sprache, ist die Zeit zum Füllen eines Pakets mit Daten erheblich, wenn das Paket groß ist. Um eine geringe Ende-zu-Ende-Verzögerung zu erzielen, werden kleine Pakete bevorzugt. Ohne Header-Komprimierung verbraucht der minimale IPv6/UDP-Header (48 Oktetten) bei einer Paketrate von 50 Paketen/Sekunde 19,2 kbit/s. 50 Pakete/Sekunde entspricht 20 ms Sprachproben pro Paket. Der IPv4/UDP-Header verbraucht bei 50 Paketen/Sekunde 11,2 kbit/s. Tunnel- oder Routing-Header, z. B. zur Unterstützung von Mobilität, erhöhen den Header-Bandbreitenverbrauch um 10–20 kbit/s. Dies ist mit der für die eigentlichen Sprachproben benötigten Bandbreite zu vergleichen, z. B. 13 kbit/s bei GSM-Kodierung. Die Header-Komprimierung kann die für Header benötigte Bandbreite erheblich reduzieren, in diesem Beispiel auf etwa 1,7 kbit/s. Dies ermöglicht eine höhere Sprachqualität bei 14,4- und 28,8-kbit/s-Modems.

• Den Header-Overhead zu reduzieren

  Heute beträgt die übliche Größe eines TCP-Segments für Bulk-Transfer auf mittelschnellen Verbindungen 512 Oktetten. Wenn ein TCP-Segment getunnelt wird, z. B. weil Mobile IP verwendet wird, beträgt der IPv6/IPv6/TCP-Header 100 Oktetten. Die Header-Komprimierung reduziert den IPv6/TCP-Header-Overhead von 19,5 % auf unter 1 % und den getunnelten IPv4/TCP-Header-Overhead von 11,7 % auf unter 1 %. Bei Leitungsgeschwindigkeiten bis zu einigen Mbit/s ist dies ein erheblicher Gewinn.

  Die IPv6-Spezifikation schreibt Path-MTU-Discovery vor, sodass bei Verwendung von IPv6 Bulk-TCP-Transfers nach Möglichkeit Segmente größer als 512 Oktetten verwenden sollten. Dennoch reduziert die Header-Komprimierung bei Verwendung von 1400-Oktett-Segmenten (RFC-894-Ethernet-Kapselung erlaubt 1500 Oktetten Nutzlast, von denen 100 Oktetten für IP-Header verwendet werden) den IPv6-Header-Overhead von 7,1 % auf 0,4 %.

• Die Paketverlustrate auf verlustbehafteten Verbindungen zu senken

  Da pro Paket weniger Bits gesendet werden, ist die Paketverlustrate bei einer gegebenen Bitfehlerrate geringer. Dies führt zu einem höheren TCP-Durchsatz, da das Sendefenster zwischen Verlusten weiter geöffnet werden kann, und zu weniger verlorenen Paketen bei UDP.

Der hier beschriebene Mechanismus ist für Punkt-zu-Punkt-Verbindungen gedacht. Es wurde jedoch darauf geachtet, Erweiterungen für Mehrfachzugriffs-Verbindungen und Multicast zu ermöglichen.

Zu den komprimierbaren Headern gehören TCP-, UDP-, IPv4- und IPv6-Basis-Header sowie Erweiterungs-Header. Für TCP-Pakete wird der Mechanismus von Van Jacobson [RFC-1144] zur Wiederherstellung nach Verlusten verwendet. Es werden auch zwei zusätzliche Mechanismen beschrieben, die die Effizienz der VJ-Header-Komprimierung auf verlustbehafteten Verbindungen verbessern. Für Nicht-TCP-Pakete ermöglichen Compression Slow-Start und periodische Header-Aktualisierungen, die Paketverlustzeiträume nach dem Verlust eines kontextändernden Headers zu minimieren. Es gibt Erweiterungspunkte für Header-Komprimierungsverfahren über UDP, z. B. für die Komprimierung von RTP-Headern.

Header-Komprimierung beruht darauf, dass viele Felder in aufeinanderfolgenden Paketen desselben Paketstroms konstant sind oder sich selten ändern. Felder, die sich zwischen Paketen nicht ändern, müssen überhaupt nicht übertragen werden. Felder, die sich häufig mit kleinen und/oder vorhersehbaren Werten ändern, z. B. TCP-Sequenznummern, können inkrementell kodiert werden, sodass die für diese Felder benötigten Bits erheblich reduziert werden. Nur Felder, die sich häufig und zufällig ändern, z. B. Prüfsummen oder Authentifizierungsdaten, müssen in jedem Header übertragen werden.

Das allgemeine Prinzip der Header-Komprimierung besteht darin, gelegentlich Pakete mit vollständigen Headern zu senden; nachfolgende komprimierte Header referenzieren den durch den vollständigen Header etablierten Kontext (Context) und können inkrementelle Änderungen am Kontext enthalten.

Dieses Header-Komprimierungsverfahren erfordert nicht, dass alle Pakete desselben Stroms die komprimierte Verbindung durchlaufen. Bei TCP-Strömen können die Unterschiede zwischen aufeinanderfolgenden Headern jedoch unregelmäßiger werden und die Komprimierungsrate kann sinken. Es ist auch nicht erforderlich, dass die entsprechenden TCP-Daten- und Bestätigungspakete in entgegengesetzter Richtung die Verbindung durchlaufen.

Dieses Header-Komprimierungsverfahren ist sowohl auf Erst- und Letzthop-Verbindungen als auch auf Verbindungen in der Mitte des Netzwerks nützlich. Wenn viele Paketströme (mehrere Hundert) eine Verbindung durchlaufen, kann ein Phänomen namens CID-Jitter auftreten, bei dem Header selten mit einem vorhandenen Kontext übereinstimmen und als unkomprimierte oder vollständige Header gesendet werden müssen. Implementierungen müssen Techniken wie Hysterese verwenden, um sicherzustellen, dass die Paketströme mit der höchsten Komprimierungsrate ihren Kontext behalten. Diese Technik ist eher in der Mitte des Netzwerks erforderlich.