Zusammenfassung

  • Das Silly Window Syndrome ist kein einzelnes kleines Segment, sondern eine stabile Rückkopplung, in der ein geringer Fensterfortschritt immer neue Kleinsendungen hervorbringt.
  • TCP unterbricht den Kreislauf durch Zurückhaltung an beiden Endpunkten; ein Ausnahmetimer verhindert zugleich, dass das Warten auf Effizienz zum Stillstand wird.

Ein Empfangsprogramm liest 50 Byte aus einem beinahe vollen Puffer. Der freie Platz ist real, und TCP könnte ihn sofort ankündigen. Der Sender hat wesentlich mehr Daten in seiner Warteschlange, darf aber zunächst nur diese 50 Byte übertragen. Sie treffen ein, werden von der Anwendung verbraucht und machen erneut 50 Byte frei. Die Bestätigung eröffnet dieselbe kleine Möglichkeit ein weiteres Mal. Jeder einzelne Schritt hält die Flusskontrolle ein. Ihre Folge zwingt die Verbindung dennoch in einen selbsttragenden Kleintakt.

David Clark gab diesem Muster 1982 in RFC 813 den Namen Silly Window Syndrome, kurz SWS. Gemeint war nicht, dass jedes kurze Segment fehlerhaft sei. Beschrieben wurde eine stabile Entartung während langer Übertragungen. Eine natürliche Datengrenze kann das nutzbare Fenster einmal teilen; anschließend erhalten Bestätigungen und kleine Bewegungen des rechten Fensterrands diese Teilung. Solange der Sender nicht innehält, fehlt ein natürlicher Anlass, die Stücke wieder zusammenzuführen.

RFC 813 machte dafür zwei Größen auseinander: das vom Empfänger angebotene Fenster und das beim Sender tatsächlich nutzbare Fenster. Vom Angebot muss der Sender alle bereits übertragenen, aber noch nicht bestätigten Bytes abziehen. Sind von einem angebotenen Fenster mit 1.000 Byte noch 950 Byte unterwegs, bleiben nur 50 Byte für eine neue Sendung. Rückt die rechte Kante mit der nächsten Bestätigung um weitere 50 Byte vor, entsteht erneut dieselbe kleine Gelegenheit. Nicht allein die Fensterzahl, sondern ihre schrittweise Bewegung prägt die Segmentgröße.

Die historische Wirkung beschränkte sich nicht auf zusätzlichen Headeraufwand. RFC 813 berichtete, dass schlechte Fensterstrategien Durchsatz und CPU-Effizienz um Faktoren verschlechtern konnten. Dokumentiert wurden Fälle, in denen das durchschnittliche Segment nur ein Zehntel der von beiden Seiten verkrafteten Größe erreichte und sich Neuübertragungen häuften. Diese Angaben sind Beobachtungen des damaligen Memos, keine Messung heutiger Verbreitung. Sie erklären aber, warum SWS als Problem der Transportarchitektur behandelt wurde.

Der Empfänger löst die Rückkopplung, indem er freien Speicher nicht automatisch als sofort zu veröffentlichendes Sendeguthaben behandelt. Gibt die Anwendung wenig Platz frei, kann TCP die angekündigte rechte Fensterkante festhalten. Der Platz wird intern gesammelt und erst in einem brauchbaren Sprung freigegeben. Zu langes Warten kann die Übertragungspipeline leeren und eine Verzögerung erzeugen. Zu häufiges Öffnen hält dagegen die Fragmentierung am Leben und belastet Netzwerk wie Prozessor. RFC 813 empfahl deshalb eher Zurückhaltung und mindestens eine Öffnung, die ein angemessen großes Segment erlaubt.

RFC 1122 überführte die Erfahrung in eine Hostanforderung. Abschnitt 4.2.3.3 verlangt einen SWS-Vermeidungsalgorithmus beim Empfänger. Die vorgeschlagene Regel hält RCV.NXT + RCV.WND konstant, bis der verfügbare, aber noch nicht angekündigte Platz den kleineren von zwei Werten erreicht: einen Anteil des Empfangspuffers oder eine effektive Sende-MSS. Als Anteil wird ein Halb empfohlen. Unter realistischen Pufferverhältnissen wächst das Fenster damit oft in Einheiten, die ungefähr ein nützliches Segment tragen.

Auch der Sender muss eine protokollgemäß zulässige, aber ineffiziente Gelegenheit ausschlagen können. RFC 1122 §4.2.3.4 fordert daher senderseitige SWS-Vermeidung. Empfohlen wird das Senden, wenn ein Segment maximaler Größe möglich ist, wenn alle zur sofortigen Ausgabe vorgesehenen Daten unter den genannten Bedingungen gesendet werden können, wenn mindestens die Hälfte des größten beobachteten Fensters nutzbar ist oder wenn ein Ausnahmetimer abläuft. Ein kleines nutzbares Fenster ist eine Erlaubnis, keine Pflicht zur sofortigen Nutzung.

Der Timer gleicht einen Wissensunterschied aus. Der Empfänger kennt seinen gesamten Puffer, der Sender nicht. Er kann das größte bisher beobachtete Sendefenster als Schätzung verwenden. Verkleinert der Empfänger später seinen Puffer, ist diese Schätzung zu hoch. Würde der Sender unbegrenzt auf einen Anteil des alten Maximums warten, erzeugte seine Bündelungsregel einen Deadlock. Der Timer erzwingt deshalb irgendwann eine Sendung. RFC 9293 behält dafür einen empfohlenen Bereich von 0,1 bis 1,0 Sekunden bei; daraus lassen sich keine universellen Einstellungen heutiger TCP-Stacks ableiten.

RFC 9293 bewahrt die Pflicht auf beiden Seiten und grenzt sie zugleich vom Nagle-Algorithmus ab. Nagle dämpft kleine Segmente, die entstehen, weil die Anwendung Daten in kleinen Portionen liefert. Senderseitige SWS-Vermeidung dämpft kleine Segmente, die durch kleinschrittiges Vorrücken des rechten Empfangsfensterrands entstehen. Beide Mechanismen ergänzen sich, beantworten jedoch verschiedene Ursachen.