3.2. Fast Retransmit/Fast Recovery
Empfängerverhalten
Ein TCP-Empfänger SOLLTE (SHOULD) ein sofortiges dupliziertes ACK senden, wenn ein Segment außer der Reihe ankommt. Der Zweck dieses ACK ist es, dem Sender mitzuteilen, dass ein Segment außer der Reihe empfangen wurde und welche Sequenznummer erwartet wird.
Ursachen für duplizierte ACKs
Aus Sicht des Senders können duplizierte ACKs durch eine Reihe von Netzwerkproblemen verursacht werden:
- Verworfene Segmente: Alle Segmente nach dem verworfenen Segment lösen duplizierte ACKs aus, bis der Verlust repariert ist
- Neuordnung von Datensegmenten durch das Netzwerk (kein seltenes Ereignis auf einigen Netzwerkpfaden [Pax97])
- Replikation von ACK- oder Datensegmenten durch das Netzwerk
ACK zum Füllen von Lücken
Zusätzlich SOLLTE (SHOULD) ein TCP-Empfänger ein sofortiges ACK senden, wenn das eingehende Segment eine Lücke im Sequenzraum ganz oder teilweise füllt.
Fast-Retransmit-Algorithmus
Der TCP-Sender SOLLTE (SHOULD) den "Fast Retransmit"-Algorithmus verwenden, um Verlust basierend auf eingehenden duplizierten ACKs zu erkennen und zu reparieren.
Der Fast-Retransmit-Algorithmus verwendet die Ankunft von 3 duplizierten ACKs (wie in Abschnitt 2 definiert, ohne dazwischenliegende ACKs, die SND.UNA bewegen) als Hinweis darauf, dass ein Segment verloren gegangen ist. Nach Erhalt von 3 duplizierten ACKs führt TCP eine Neuübertragung des scheinbar fehlenden Segments durch, ohne auf das Ablaufen des Neuübertragungstimers zu warten.
Fast-Recovery-Algorithmus
Nachdem der Fast-Retransmit-Algorithmus das scheinbar fehlende Segment gesendet hat, regelt der "Fast Recovery"-Algorithmus die Übertragung neuer Daten, bis ein nicht-dupliziertes ACK ankommt.
Begründung
Der Grund dafür, keinen Slow Start durchzuführen, ist, dass der Empfang der duplizierten ACKs nicht nur anzeigt, dass ein Segment verloren gegangen ist, sondern auch, dass Segmente höchstwahrscheinlich das Netzwerk verlassen (obwohl eine massive Segmentduplizierung durch das Netzwerk diese Schlussfolgerung ungültig machen kann).
Mit anderen Worten, da der Empfänger nur dann ein dupliziertes ACK erzeugen kann, wenn ein Segment angekommen ist, hat dieses Segment das Netzwerk verlassen und befindet sich im Puffer des Empfängers, sodass wir wissen, dass es keine Netzwerkressourcen mehr verbraucht.
Implementierung von Fast Retransmit und Fast Recovery
Die Fast-Retransmit- und Fast-Recovery-Algorithmen werden zusammen wie folgt implementiert:
1. Erstes und zweites dupliziertes ACK
Beim ersten und zweiten duplizierten ACK, das bei einem Sender empfangen wird, SOLLTE (SHOULD) ein TCP ein Segment von zuvor nicht gesendeten Daten gemäß [RFC3042] senden, vorausgesetzt dass:
- Das angekündigte Fenster des Empfängers erlaubt es
- Die gesamte FlightSize kleiner oder gleich cwnd plus 2*SMSS bleibt
- Neue Daten zur Übertragung verfügbar sind
Ferner DARF (MUST NOT) der TCP-Sender cwnd nicht ändern, um diese zwei Segmente widerzuspiegeln [RFC3042].
2. Drittes dupliziertes ACK
Wenn das dritte duplizierte ACK empfangen wird, MUSS (MUST) ein TCP ssthresh auf nicht mehr als den in Gleichung (4) angegebenen Wert setzen.
3. Neuübertragen und Fenster aufblähen
Das verlorene Segment, das bei SND.UNA beginnt, MUSS (MUST) neu übertragen werden und cwnd auf ssthresh plus 3*SMSS gesetzt werden. Dies "bläht" das Staufenster künstlich um die Anzahl der Segmente (drei) auf, die das Netzwerk verlassen haben und die der Empfänger gepuffert hat.
4. Zusätzliche duplizierte ACKs
Für jedes zusätzliche duplizierte ACK, das empfangen wird (nach dem dritten), MUSS (MUST) cwnd um SMSS erhöht werden. Dies bläht das Staufenster künstlich auf, um das zusätzliche Segment widerzuspiegeln, das das Netzwerk verlassen hat.
5. Zuvor nicht gesendete Daten senden
Wenn zuvor nicht gesendete Daten verfügbar sind und der neue Wert von cwnd und das angekündigte Fenster des Empfängers es erlauben, SOLLTE (SHOULD) ein TCP 1*SMSS Bytes von zuvor nicht gesendeten Daten senden.
6. Fenster entleeren
Wenn das nächste ACK ankommt, das zuvor unbestätigte Daten bestätigt, MUSS (MUST) ein TCP cwnd auf ssthresh setzen (den in Schritt 2 gesetzten Wert). Dies wird als "Entleeren" des Fensters bezeichnet.
Dieses ACK sollte die Bestätigung sein, die durch die Neuübertragung aus Schritt 3 hervorgerufen wird, ein RTT nach der Neuübertragung (obwohl es früher ankommen kann bei bedeutender Lieferung von Datensegmenten außer der Reihe beim Empfänger).
Einschränkungen
Hinweis: Dieser Algorithmus ist bekannt dafür, dass er im Allgemeinen nicht effizient von mehreren Verlusten in einem einzigen Paketflug erholt [FF96]. Abschnitt 4.3 unten behandelt solche Fälle.