Zusammenfassung

  • RFC 3150 behandelte die Übertragungszeit eines Pakets als Frage gemeinsam genutzter Leitungskapazität: Ein großes Paket konnte auf einer sehr langsamen Verbindung die Schnittstelle so lange belegen, dass andere Datenströme es spürbar merkten.
  • Die Empfehlung von 100–200 Millisekunden war kontextgebundene Best Current Practice, kein universelles MTU-Gebot. Kleinere Pakete verringern die Belegungszeit, verursachen aber mehr Header und andere pfadabhängige Kosten.

Ein Paket hat eine Dauer, nicht nur eine Größe

Die Länge eines Pakets wird gewöhnlich in Bytes angegeben. In einem schnellen Büronetz fällt die Zeit, um diese Bytes auf die Leitung zu bringen, kaum ins Gewicht. Auf einem Zugangsweg mit niedriger Bitrate kann sie dagegen das Nutzungserlebnis prägen: Solange das letzte Bit eines Pakets serialisiert wird, kann ein anderer Datenstrom dieselbe Sendegelegenheit nicht nutzen. Er muss womöglich warten, obwohl keine lange Warteschlange vorliegt und die Verbindung genau wie vorgesehen arbeitet.

Das ist das weniger offensichtliche Entwurfsproblem in RFC 3150, „End-to-end Performance Implications of Slow Links“. Das Dokument wurde im Juli 2001 als Best Current Practice 48 veröffentlicht. Es behandelt Pfade mit sehr langsamen Verbindungen und nennt als Beispiele ein 56-Kb/s-Modem sowie drahtlosen Zugang mit 4,8 Kb/s. Es ist weder der Bericht eines bestimmten Anbieters noch ein Benchmark bestimmter Geräte, sondern eine Reihe von Empfehlungen für allgemeinen Internetverkehr auf eingeschränkten Pfaden.

Bei der MTU weist die RFC darauf hin, dass ein vergleichsweise großes Paket so lange zur Übertragung brauchen kann, dass andere Nutzer derselben Schnittstelle eine wahrnehmbare Verzögerung erleben. Sie nennt 100–200 Millisekunden als wahrnehmbaren Bereich und empfiehlt MTUs, die die Schnittstelle nicht wesentlich länger monopolisieren. Eine 296-Byte-MTU für Einwahlzugänge wird mit Header-Kompression als Kompromiss beschrieben, der auf einer 9,6-Kb/s-Leitung ungefähr 200 Millisekunden beansprucht.

Von Bytes zu gemeinsamer Wartezeit

Die Rechnung macht den Zielkonflikt sichtbar. Ohne Rahmung und Header übertragen 56 Kb/s in 100 Millisekunden 700 Bytes; bei 4,8 Kb/s sind es nur 60. Bei doppelter Zeit verdoppeln sich die Werte. Das veranschaulicht die Serialisierungszeit, ist aber keine MTU-Vorgabe: Rahmung der Sicherungsschicht, Kapselung und tatsächliche Bitrate verändern die Belegungsdauer.

Der begriffliche Schritt ist wichtig: Eine MTU ist nicht nur die maximale Paketgröße, ein Mittel zur Verteilung des Header-Aufwands oder eine Fragmentierungsgrenze. Sie bestimmt auch, wie lange ein Paket das gemeinsam genutzte Medium beansprucht. Ein großer Nutzdatenblock kann den Header-Aufwand pro Byte senken und gleichzeitig einem anderen Datenstrom einen längeren Turn zumuten. Betroffen ist jede Kommunikation über die Leitung, nicht nur der Sender, der die Größe gewählt hat.

Kleinere MTUs sind nicht kostenlos. Header werden häufiger übertragen; bei Gebühren pro Paket können dieselben Nutzdaten teurer werden. Auf langsamen, verlustbehafteten Pfaden können kleinere Segmente jedoch auf andere Weise helfen: In ein kleines Congestion Window passen mehr Segmente, was eine Wiederherstellung nach doppelten ACKs begünstigen kann; eine Warteschlange mit gleich vielen Paketen enthält zudem weniger Bytes. Das hängt vom Pfad und vom Protokollverhalten ab – „kleiner ist immer schneller“ folgt daraus nicht.

Serialisierungs- und Warteschlangenverzögerung sind getrennte Größen. Serialisierung bezeichnet die Zeit, in der die Paketbits die Leitung belegen; Warteschlange die Zeit hinter früheren Paketen. Eine kleinere MTU kann einzelne Turns verkürzen und die Warteschlangendynamik verändern, aber sie macht beide Zeiten nicht identisch. Die RFC-Aussage zur wahrnehmbaren Belegungszeit beweist für sich allein weder eine lange Warteschlange noch eine langsame Anwendung.

Eine Best Practice, keine globale Einstellung

RFC 3150 bündelte mehrere Optimierungen für langsame Leitungen: Kompression von Headern und Nutzdaten, TCP-Stauverhalten, automatische Pufferanpassung, Verlustbehandlung bei kleinen Fenstern und Limited Transmit. Diese Verfahren wirken zusammen, machen aber nicht jeden langsamen Pfad gleich. Header-Kompression verändert die Zahl der zu sendenden Bits; eine Fensteranpassung ändert, wie viel der Sender unterwegs haben darf; aktives Warteschlangenmanagement betrifft Ort und Zeitpunkt der Stausignalisierung. Nichts davon ist mit der Serialisierungszeit eines einzelnen Pakets gleichzusetzen.

Der Rat, die Leitungsbelegung in der Nähe einer wahrnehmbaren Zeitspanne zu halten, ließ die konkrete Entscheidung daher bei Implementierern und den jeweiligen Bedingungen. 100–200 Millisekunden sind weder eine zeitlose psychophysische Konstante noch eine verbindliche Standardvorgabe oder das Optimum für jede Technologie. Die Empfehlung stellt eine nutzerbezogene Frage an die Paketgröße: Wie lange dauert ein Turn für alle anderen?

Als Methode bleibt die Frage nützlich, obwohl die Einwahlbeispiele historisch sind. Die tatsächliche Serialisierungszeit muss mit Rahmung und Bitrate berechnet oder gemessen und anschließend von Warteschlange und Anwendungsverarbeitung getrennt werden. Erst so lässt sich eine Aussage über gemeinsame Verzögerung auf den beobachteten Pfad begrenzen.

Der historische Beitrag ist klein, aber aufschlussreich: RFC 3150 verstand Paketierung auch als Verteilung von Wartezeit zwischen Datenströmen und nicht bloß als effizienten Byte-Transport. Als redaktionelle Deutungsrahmen dienen Lu Hengs Note 64 über Mindestvorgaben und lokale Entscheidung sowie Note 20 über die Trennung formaler Beschreibung von beobachtbarer Wirklichkeit. Das sind redaktionelle Perspektiven, keine Aussagen der RFC-Autoren.

Quellen

  1. RFC 3150 — End-to-end Performance Implications of Slow Links
  2. RFC-3150-Eintrag beim RFC Editor
  3. RFC 1144 — Compressing TCP/IP Headers for Low-Speed Serial Links
  4. RFC 2416 — When TCP Starts Up With Four Packets Into Only Three Buffers
  5. RFC 2689 — Providing Integrated Services Over Low-bitrate Links
  6. RFC 3155 — End-to-end Performance Implications of Links with Errors
  7. RFC 3449 — TCP Performance Implications of Network Path Asymmetry
  8. RFC 7567 — IETF Recommendations Regarding Active Queue Management
  9. Lu Heng, Note 64
  10. Lu Heng, Note 20