Zusammenfassung

  • RFC 2414 machte ein größeres TCP-Anfangsfenster optional: begrenzt auf min(4*MSS, max(2*MSS, 4380 bytes)). Die Regel galt für den ersten Datenflug einer neuen Verbindung, nicht für jeden Neustart nach Leerlauf oder Verlust.
  • Die erhoffte Abkürzung: Ein zweites Segment konnte eine Bestätigung auslösen, ohne den verzögerten ACK-Timer abzuwarten. In vielen modellierten Fällen ergaben die ns-2-Simulationen von RFC 2415 niedrigere mediane Web-Seitenlatenzen.
  • Gemischte Gruppen ergaben kein einheitliches Urteil. Bei moderater Last schadete IW=3 der IW=1-Gruppe nicht; in einem extrem überlasteten Szenario mit 32/32 Web-Clients war die Gruppe mit dem größeren Fenster selbst im Nachteil.
  • Das waren Simulationen, keine Erhebung zum weltweiten Einsatz. Der Geschwindigkeitsgewinn einer Verbindung und die Verteilung der Wirkungen auf einem gemeinsam genutzten Pfad sind verschiedene Fragen.

Die erste Bestätigung war der Gewinn

Der Vorschlag klang klein: Eine neue TCP-Verbindung sollte mehr als ein Datensegment senden, bevor sie wartete. Der Nutzen konnte eintreten, noch bevor ein großer Transfer begonnen hatte. Befindet sich nur ein Segment im Flug, wartet ein Empfänger mit verzögerten Bestätigungen womöglich bis zum Timer. Ein zweites eintreffendes Segment kann die Bestätigung früher auslösen. Bei einem kleinen Web-Objekt könnte die vermiedene Wartezeit entscheiden, ob die Übertragung innerhalb eines Umlaufs abgeschlossen wird.

RFC 2414 erklärte, dass die Änderung bei einer Verbindung mit wachsendem Überlastungsfenster bis zu drei Umläufe und einen verzögerten ACK-Timeout in der anfänglichen Slow-Start-Phase einsparen könne.

RFC 2414 verlangte nicht vier Segmente für jede Verbindung. Der 1998 im September als Experimental veröffentlichte RFC erhöhte die erlaubte Obergrenze auf min(4*MSS, max(2*MSS, 4380 bytes)) und erklärte, TCP MAY den größeren Wert verwenden. Je nach MSS entsprach die Grenze zwei, drei oder vier Segmenten. Die Regel bezog sich auf das Anfangsfenster nach dem Drei-Wege-Handshake. Das Verlustfenster blieb bei einem Segment; der Neustart nach längerer Inaktivität war Gegenstand einer separaten optionalen Regel. Ein größerer Start war also ein begrenzter Versuch, keine Erlaubnis, jedes Fenster nach einer Verkehrspause zu vergrößern.

Der Endpunkt konnte den ersten Datenflug wählen, aber nicht die Warteschlange reservieren, in die seine Pakete gelangten. RFC 2414 benannte beide Seiten des Zielkonflikts: Der eigene Burst konnte der initiierenden Verbindung Verluste oder Timeouts bescheren; an einem überlasteten gemeinsamen Link konnten andere Flows Verluste oder Unfairness tragen. Die Autoren warnten zudem, dass Browser mit mehreren gleichzeitig geöffneten Verbindungen das Problem verschärfen würden, falls jede größer startete. Eine Verbesserung pro Flow verändert die Last einer Warteschlange, die vielen gehört.

Die Simulationen führten mehr als eine Wertung

Der begleitende Informational-RFC 2415 untersuchte die Kontroverse mit ns-2; er war kein Bericht über den praktischen Einsatz. Das Modell setzte einen Engpass von 1,5 Mbit/s und 50 ms RTT zwischen schnelleren Links. Es variierte 8, 16 oder 32 Web-Clients, bis zu drei lange FTP-Transfers und Anfangsfenster von einem bis vier 1460-Byte-Segmenten. Das Web-Modell verwendete kleine Seiten mit drei eingebetteten URLs und zufällig verzögerten Folgeabrufen; FTP übertrug Dateien von einem Megabyte. So wurde ein kontrollierter Vergleich möglich, zugleich aber auch klar begrenzt, wofür er stand.

In vielen modellierten Fällen senkten größere Anfangsfenster die mediane Seitenlatenz, häufig um etwa 30 Prozent. Die Autoren führten einen großen Teil des Sprungs von einem auf zwei Segmente auf ihre URL-Größenverteilung zurück: Der Median der Haupt- und eingebetteten Objekte passte in zwei Pakete. Eine andere Verteilung könnte eine andere Kurve ergeben. Das war ein Mechanismusbefund innerhalb eines Modells, keine allgemeine Prozentzusage für Browser oder Links.

Die getrennten Kohorten schärften die Frage. In Aufteilungen 8/8 und 16/16 der Web-Clients auf IW=1 und IW=3 beobachteten die Autoren keinen negativen Effekt für die Ein-Segment-Gruppe; die größere Fenstergruppe behielt einen Vorteil. Bei 32/32 wurden IW=3-Clients in einem als pathologisch überlastet bezeichneten Szenario beeinträchtigt. Als Ursache nannten die Autoren viele gleichzeitige Verbindungsstarts und mehrere Verluste. Das zeigte nicht, dass jeder größere Start Nachbarn schädigt; es zeigte, dass eine bessere Gesamt- oder Medianzahl nicht die Erfahrung jeder Kohorte unter jeder modellierten Last abbildet.

Diese Evidenz unterscheidet sich von der bereits behandelten Einzelverbindungsspur mit drei Puffern aus RFC 2416. RFC 2415 betrifft viele modellierte Flows an einem Engpass und die Wirkung ihrer Mischung. Keine der beiden Simulationen belegte das Verhalten realer Geräte im gesamten Internet oder lieferte ein universelles Fairnessmaß. Später löste RFC 3390 RFC 2414 mit einer optionalen Obergrenze im Standards Track ab; RFC 5681 hielt die Regel fest, und RFC 6928 erprobte experimentell zehn Segmente. Die spätere Veröffentlichungsgeschichte macht das Modell von 1998 nicht nachträglich zu einer Einsatzstatistik.

Heng Lus Running-Code Primacy dient hier nur als Beweisdisziplin: Mechanismus und tatsächlich getestetes System auseinanderzuhalten. On Reality Layers mahnt, Seitenlatenz, Warteschlangenverluste und Aussagen über ein ganzes Netz nicht zu einer Beobachtung zu verschmelzen. Keine der beiden Notizen ist historische TCP-Evidenz; diese liefern die RFCs.

Quellen