3.1. Slow Start und Congestion Avoidance

Die Slow-Start- und Congestion-Avoidance-Algorithmen MÜSSEN (MUST) von einem TCP-Sender verwendet werden, um die Menge an ausstehenden Daten zu kontrollieren, die ins Netzwerk eingefügt werden.

Zustandsvariablen

Um diese Algorithmen zu implementieren, werden zwei Variablen zum TCP-Pro-Verbindung-Zustand hinzugefügt:

1. Staufenster (Congestion Window, cwnd): Eine senderseitige Begrenzung der Datenmenge, die der Sender ins Netzwerk übertragen kann, bevor er eine Bestätigung (ACK) erhält
2. Angekündigtes Empfängerfenster (Receiver's Advertised Window, rwnd): Eine empfängerseitige Begrenzung der Menge ausstehender Daten

Das Minimum von cwnd und rwnd steuert die Datenübertragung.

Eine weitere Zustandsvariable, die Slow-Start-Schwelle (Slow Start Threshold, ssthresh), wird verwendet, um zu bestimmen, ob der Slow-Start- oder Congestion-Avoidance-Algorithmus zur Steuerung der Datenübertragung verwendet wird, wie unten diskutiert.

Zweck von Slow Start

Der Beginn der Übertragung in ein Netzwerk mit unbekannten Bedingungen erfordert, dass TCP das Netzwerk langsam sondiert, um die verfügbare Kapazität zu bestimmen, um zu vermeiden, das Netzwerk mit einem unangemessen großen Datenburst zu verstopfen. Der Slow-Start-Algorithmus wird zu diesem Zweck verwendet:

• Zu Beginn einer Übertragung
• Nach der Reparatur eines durch den Neuübertragungstimer erkannten Verlusts

Slow Start dient zusätzlich dazu, die "ACK-Uhr" zu starten, die der TCP-Sender verwendet, um Daten in den Slow-Start-, Congestion-Avoidance- und Verlusterholungsalgorithmen ins Netzwerk freizugeben.

Anfangsfenster (IW)

IW, der Anfangswert von cwnd, MUSS (MUST) unter Verwendung der folgenden Richtlinien als Obergrenze gesetzt werden:

Wenn SMSS > 2190 Bytes:
    IW = 2 * SMSS Bytes und DARF NICHT mehr als 2 Segmente sein

Wenn (SMSS > 1095 Bytes) und (SMSS <= 2190 Bytes):
    IW = 3 * SMSS Bytes und DARF NICHT mehr als 3 Segmente sein

Wenn SMSS <= 1095 Bytes:
    IW = 4 * SMSS Bytes und DARF NICHT mehr als 4 Segmente sein

Wie in [RFC3390] spezifiziert, DÜRFEN (MUST NOT) der SYN/ACK und die Bestätigung des SYN/ACK die Größe des Staufensters nicht erhöhen. Ferner MUSS (MUST), wenn der SYN oder SYN/ACK verloren geht, das Anfangsfenster, das von einem Sender nach einem korrekt übertragenen SYN verwendet wird, ein Segment sein, das aus höchstens SMSS Bytes besteht.

Eine detaillierte Begründung und Diskussion der IW-Einstellung ist in [RFC3390] vorgesehen.

Erwägungen zur Path MTU Discovery

Wenn anfängliche Staufenster von mehr als einem Segment zusammen mit Path MTU Discovery [RFC1191] implementiert werden und die verwendete MSS sich als zu groß herausstellt, SOLLTE (SHOULD) das Staufehster cwnd verringert werden, um große Bursts kleinerer Segmente zu vermeiden. Genauer gesagt, SOLLTE (SHOULD) cwnd um das Verhältnis der alten Segmentgröße zur neuen Segmentgröße verringert werden.

Anfangswert von ssthresh

Der Anfangswert von ssthresh SOLLTE (SHOULD) willkürlich hoch gesetzt werden (z.B. auf die Größe des größtmöglichen angekündigten Fensters), aber ssthresh MUSS (MUST) als Reaktion auf Stau reduziert werden.

Das Setzen von ssthresh so hoch wie möglich erlaubt den Netzwerkbedingungen, anstatt einer willkürlichen Host-Begrenzung, die Senderate zu diktieren.

Algorithmusauswahl

• Der Slow-Start-Algorithmus wird verwendet, wenn cwnd < ssthresh
• Der Congestion-Avoidance-Algorithmus wird verwendet, wenn cwnd > ssthresh
• Wenn cwnd und ssthresh gleich sind, kann der Sender entweder Slow Start oder Congestion Avoidance verwenden

Slow-Start-Algorithmus

Während Slow Start erhöht ein TCP cwnd um höchstens SMSS Bytes für jedes empfangene ACK, das kumulativ neue Daten bestätigt. Slow Start endet, wenn:

• cwnd ssthresh überschreitet (oder optional, wenn es erreicht wird, wie oben erwähnt), oder
• Wenn Stau beobachtet wird

Empfohlene cwnd-Erhöhung

Während traditionell TCP-Implementierungen cwnd um genau SMSS Bytes beim Empfang eines ACK, das neue Daten abdeckt, erhöht haben, EMPFEHLEN (RECOMMEND) wir, dass TCP-Implementierungen cwnd erhöhen, gemäß:

cwnd += min (N, SMSS)    (Gleichung 2)

wobei N die Anzahl der zuvor unbestätigten Bytes ist, die im eingehenden ACK bestätigt werden.

Diese Anpassung ist Teil von Appropriate Byte Counting [RFC3465] und bietet Robustheit gegen sich schlecht verhaltende Empfänger, die versuchen könnten, einen Sender dazu zu verleiten, cwnd künstlich aufzublähen, indem sie einen Mechanismus verwenden, der als "ACK-Teilung" [SCWA99] bekannt ist.

Congestion-Avoidance-Algorithmus

Während Congestion Avoidance wird cwnd um etwa 1 vollständiges Segment pro Round-Trip-Zeit (RTT) erhöht. Congestion Avoidance setzt sich fort, bis Stau erkannt wird.

Richtlinien für die Erhöhung von cwnd

Die grundlegenden Richtlinien für die Erhöhung von cwnd während Congestion Avoidance sind:

• KANN (MAY) cwnd um SMSS Bytes erhöhen
• SOLLTE (SHOULD) cwnd gemäß Gleichung (2) einmal pro RTT erhöhen
• DARF NICHT (MUST NOT) cwnd um mehr als SMSS Bytes erhöhen

Empfohlene Implementierung

Der EMPFOHLENE (RECOMMENDED) Weg, cwnd während Congestion Avoidance zu erhöhen, ist, die Anzahl der Bytes zu zählen, die durch ACKs für neue Daten bestätigt wurden. Wenn die Anzahl der bestätigten Bytes cwnd erreicht, kann cwnd um bis zu SMSS Bytes erhöht werden.

Beachten Sie, dass während Congestion Avoidance cwnd NICHT (MUST NOT) um mehr als SMSS Bytes pro RTT erhöht werden darf.

Alternative Formel

Eine andere häufige Formel, die ein TCP KANN (MAY) verwenden, um cwnd während Congestion Avoidance zu aktualisieren, ist in Gleichung (3) angegeben:

cwnd += SMSS*SMSS/cwnd    (Gleichung 3)

Diese Anpassung wird bei jedem eingehenden ACK, der neue Daten bestätigt, ausgeführt. Gleichung (3) liefert eine annehmbare Annäherung an das zugrunde liegende Prinzip, cwnd pro RTT um ein vollständiges Segment zu erhöhen. (Beachten Sie, dass bei einer Verbindung, bei der der Empfänger jedes zweite Paket bestätigt, (3) weniger aggressiv ist als erlaubt — cwnd wird etwa alle zwei RTTs erhöht.)

Implementierungshinweise zu Gleichung (3)

Hinweis 1: Da in TCP-Implementierungen üblicherweise Ganzzahlarithmetik verwendet wird, kann die Formel von Gleichung (3) cwnd nicht erhöhen, wenn das Staufehster größer als SMSS*SMSS ist. Wenn die obige Formel 0 ergibt, SOLLTE (SHOULD) das Ergebnis auf 1 Byte aufgerundet werden.

Hinweis 2: Ältere Implementierungen haben eine zusätzliche additive Konstante auf der rechten Seite von Gleichung (3). Dies ist inkorrekt und kann tatsächlich zu verminderter Leistung führen [RFC2525].

Hinweis 3: Einige Implementierungen führen cwnd in Einheiten von Bytes, andere in Einheiten von vollständigen Segmenten. Letztere werden Gleichung (3) schwer verwenden können und bevorzugen möglicherweise den zuvor besprochenen zählbasierten Ansatz.

Reaktion auf Verlust

Wenn ein TCP-Sender Segmentverlust mit dem Neuübertragungstimer erkennt und das gegebene Segment noch nicht durch den Neuübertragungstimer neu gesendet wurde, MUSS (MUST) der Wert von ssthresh auf nicht mehr als den in Gleichung (4) angegebenen Wert gesetzt werden:

ssthresh = max (FlightSize / 2, 2*SMSS)    (Gleichung 4)

wobei, wie oben diskutiert, FlightSize die Menge an ausstehenden Daten im Netzwerk ist.

Andererseits, wenn ein TCP-Sender Segmentverlust mit dem Neuübertragungstimer erkennt und das gegebene Segment bereits mindestens einmal durch den Neuübertragungstimer neu gesendet wurde, wird der Wert von ssthresh konstant gehalten.

Implementierungshinweis zu FlightSize

Ein leicht zu machender Fehler besteht darin, einfach cwnd anstelle von FlightSize zu verwenden, was in einigen Implementierungen dazu führen kann, dass der Wert weit über rwnd hinaus ansteigt.

Einstellen von cwnd nach Timeout

Ferner MUSS (MUST) bei einem Timeout (wie in [RFC2988] spezifiziert) cwnd auf nicht mehr als das Verlustfenster LW gesetzt werden, das gleich 1 vollständigem Segment ist (unabhängig vom Wert von IW).

Daher verwendet der TCP-Sender nach der Neuübertragung des verworfenen Segments den Slow-Start-Algorithmus, bevor Congestion Avoidance wieder übernimmt.

Spurious Retransmissions

Wie in [FF96] und [RFC3782] gezeigt, kann die auf Slow Start basierende Verlustwiederherstellung nach einem Timeout spurious Retransmissions auslösen, die wiederum duplicate ACKs hervorrufen. Die Reaktion auf das Eintreffen dieser duplizierten ACKs variiert in TCP-Implementierungen erheblich. Dieses Dokument spezifiziert nicht, wie mit solchen ACKs umzugehen ist, weist aber darauf hin, dass dies ein Bereich ist, der von weiterer Aufmerksamkeit, Experimenten und Spezifikation profitieren könnte.