Zusammenfassung

  • RFC 6928 macht zehn Segmente zu einer optionalen, MSS-abhängigen Obergrenze; ein TCP darf kleiner beginnen.
  • IW10 spart bei kurzen Übertragungen Umläufe, belastet aber die Queue stärker, bevor Pfadbelege vorliegen. Messung und Rückfall auf RFC 3390 sind deshalb Bestandteil der Regelung.

Der Dreiwege-Handshake bestätigt die Endpunkte, nicht die freie Kapazität dazwischen. Er nennt weder die Geschwindigkeit des Zugangs noch die Puffertiefe oder die Zahl konkurrierender Flüsse. Das Initialfenster entscheidet, wie viele Daten TCP in diese Ungewissheit investieren darf, bevor ACKs den Pfad beschreiben.

RFC 6928 setzt die Obergrenze auf min(10*MSS, max(2*MSS, 14600)). Zehn ist ein erlaubtes Maximum, kein Pflichtwert. Die Änderung gilt für die erste Daten-RTT während oder nach dem Handshake; weder SYN/ACK noch dessen abschließendes ACK vergrößern das Fenster.

Das ist nicht TCP Fast Open. Fast Open verlegt Anwendungsdaten vor das Ende des Handshakes. IW10 behält den normalen Ablauf bei und vergrößert den ersten Datenflug der aufgebauten Verbindung. Das eine verschiebt den Zeitpunkt einer Anfrage, das andere die Menge, die vor dem ersten Überlastungsbeleg auf dem Pfad steht.

Ein berechenbarer Vorteil unter engen Annahmen

Im vereinfachten Modell des RFC — unbegrenzte Bandbreite, kein Verlust, normale verzögerte ACKs — kann der Sprung von drei auf zehn Segmente bei Übertragungen über 4 KB bis zu vier RTTs sparen. Das Beispiel mit 32 Segmenten benötigt zwei statt fünf Umläufe. Ein größeres Fenster liefert außerdem eher genügend doppelte ACKs, damit Fast Retransmit einen Verlust ohne anfänglichen RTO behebt.

Diese Rechnung ist keine Zusage für heutige Netze. Ein Empfangsfenster unter zehn Segmenten begrenzt den Nutzen. Die zitierten Versuche arbeiteten vor allem mit einer Ethernet-MTU von 1.500 Byte. Öffnet eine Anwendung viele Verbindungen parallel, addieren sich die Einzelbursts zu einer deutlich größeren Belastung.

Die Queue erfährt den Preis zuerst

Auf einem langsamen Zugang, in einem kleinen Puffer oder an einem belasteten Router kann der erste Burst vorzeitige Verluste, einen Timeout oder einen zu frühen Wechsel aus Slow Start auslösen. IW10-Flüsse können anfangs mehr Kapazität nehmen als RFC-3390-Flüsse. Lange Zugangsqueues übertragen die Verzögerung zudem auf DNS, Sprache, Spiele und andere zeitkritische Verkehre.

RFC 6928 hält es für unwahrscheinlich, dass eine einmalige Erhöhung allein dauerhafte Überlastung erzeugt; TCPs spätere Rücknahme bleibt erhalten. Doch „einmalig“ gilt pro Verbindung. Viele gleichzeitige Verbindungen wiederholen die Handlung auf Ebene der Anwendung.

Drei Fenster mit verschiedenen Aufgaben

Initialfenster, Wiederanlauffenster nach Leerlauf und Verlustfenster nach RTO bleiben getrennt. Das Wiederanlauffenster darf höchstens den kleineren Wert aus Initialfenster und aktueller cwnd verwenden. Das Verlustfenster bleibt bei einem MSS als kleinster Reaktion auf schwere Überlastung. Wird nach mehr als 4 KB im Initial- oder Wiederanlauffenster Verlust erkannt, sollte der Wiederanlauf auf RFC 3390 zurückfallen.

Auf langsamen Pfaden kann die Serialisierungszeit des Bursts die RTT dominieren und scheinbare Timeouts erzeugen. RFC 6928 verlangt deshalb RFC 6298: Für jedes ACK neuer Daten wird der aktuelle RTO neu gestartet.

Beleggrenze

Einzige Quelle ist RFC 6928, veröffentlicht als Experimental im April 2013. Er belegt Formel, Vergleiche und Bedingungen. Er belegt nicht, welche heutigen Systeme IW10 nutzen, wie ein benanntes Netz reagiert oder dass Werte über zehn sicher sind.