3.2. Schnelle Übertragungswiederholung/Schnelle Erholung

Ein TCP-Empfänger SOLLTE (SHOULD) sofort eine doppelte Bestätigung senden, wenn ein Segment außer der Reihe ankommt. Der Zweck dieser Bestätigung besteht darin, den Sender darüber zu informieren, dass ein Segment außer der Reihe empfangen wurde und welche Sequenznummer erwartet wird. Aus der Sicht des Senders können doppelte Bestätigungen durch eine Reihe von Netzwerkproblemen verursacht werden. Erstens können sie durch verlorene Segmente verursacht werden. In diesem Fall lösen alle Segmente nach dem verlorenen Segment doppelte Bestätigungen aus, bis der Verlust behoben ist. Zweitens können doppelte Bestätigungen durch die Umsortierung von Datensegmenten durch das Netzwerk verursacht werden (auf manchen Netzwerkpfaden kein seltenes Ereignis [Pax97]). Schließlich können doppelte Bestätigungen durch die Vervielfältigung von Bestätigungs- oder Datensegmenten durch das Netzwerk verursacht werden. Darüber hinaus SOLLTE (SHOULD) ein TCP-Empfänger sofort eine Bestätigung senden, wenn das eingehende Segment eine Lücke im Sequenzraum ganz oder teilweise füllt. Dies liefert zeitnähere Informationen für einen Sender, der sich über einen Übertragungswiederholungs-Zeitgeber, eine schnelle Übertragungswiederholung oder einen fortgeschrittenen Verlusterholungsalgorithmus von einem Verlust erholt, wie in Abschnitt 4.3 beschrieben.

Der TCP-Sender SOLLTE (SHOULD) den Algorithmus der „schnellen Übertragungswiederholung" verwenden, um Verluste anhand eingehender doppelter Bestätigungen zu erkennen und zu beheben. Der Algorithmus der schnellen Übertragungswiederholung nutzt die Ankunft von 3 doppelten Bestätigungen (wie in Abschnitt 2 definiert, ohne dazwischenliegende Bestätigungen, die SND.UNA verschieben) als Hinweis darauf, dass ein Segment verloren gegangen ist. Nach dem Empfang von 3 doppelten Bestätigungen führt TCP eine Übertragungswiederholung des offenbar fehlenden Segments durch, ohne auf den Ablauf des Übertragungswiederholungs-Zeitgebers zu warten.

Nachdem der Algorithmus der schnellen Übertragungswiederholung das offenbar fehlende Segment gesendet hat, steuert der Algorithmus der „schnellen Erholung" die Übertragung neuer Daten, bis eine nicht doppelte Bestätigung eintrifft. Der Grund dafür, keinen langsamen Start durchzuführen, ist, dass der Empfang der doppelten Bestätigungen nicht nur anzeigt, dass ein Segment verloren gegangen ist, sondern auch, dass Segmente höchstwahrscheinlich das Netzwerk verlassen (obwohl eine massive Segmentvervielfältigung durch das Netzwerk diese Schlussfolgerung ungültig machen kann). Mit anderen Worten: Da der Empfänger eine doppelte Bestätigung nur erzeugen kann, wenn ein Segment angekommen ist, hat dieses Segment das Netzwerk verlassen und befindet sich im Puffer des Empfängers; wir wissen also, dass es keine Netzwerkressourcen mehr verbraucht. Da außerdem die Bestätigungs-„Uhr" [Jac88] erhalten bleibt, kann der TCP-Sender weiterhin neue Segmente übertragen (wobei die Übertragung allerdings mit einem reduzierten cwnd fortgesetzt werden muss, da ein Verlust ein Hinweis auf Stau ist).

Die Algorithmen der schnellen Übertragungswiederholung und der schnellen Erholung werden gemeinsam wie folgt implementiert.

1. Bei der ersten und zweiten doppelten Bestätigung, die ein Sender empfängt, SOLLTE (SHOULD) ein TCP gemäß [RFC3042] ein Segment bisher ungesendeter Daten senden, sofern das angekündigte Fenster des Empfängers dies zulässt, die gesamte FlightSize kleiner oder gleich cwnd plus 2*SMSS bleibt und neue Daten zur Übertragung verfügbar sind. Ferner DARF (MUST NOT) der TCP-Sender cwnd nicht ändern, um diese beiden Segmente widerzuspiegeln [RFC3042]. Beachten Sie, dass ein Sender, der SACK [RFC2018] verwendet, DARF NICHT (MUST NOT) neue Daten senden, es sei denn, die eingehende doppelte Bestätigung enthält neue SACK-Informationen.

2. Wenn die dritte doppelte Bestätigung empfangen wird, MUSS (MUST) ein TCP ssthresh auf höchstens den in Gleichung (4) angegebenen Wert setzen. Wenn [RFC3042] verwendet wird, DÜRFEN (MUST NOT) zusätzliche Daten, die im Rahmen der begrenzten Übertragung (Limited Transmit) gesendet wurden, nicht in diese Berechnung einbezogen werden.

3. Das verlorene Segment beginnend bei SND.UNA MUSS (MUST) erneut übertragen und cwnd auf ssthresh plus 3*SMSS gesetzt werden. Dies „bläht" das Stauffenster künstlich um die Anzahl der Segmente (drei) auf, die das Netzwerk verlassen haben und die der Empfänger gepuffert hat.

4. Für jede weitere empfangene doppelte Bestätigung (nach der dritten) MUSS (MUST) cwnd um SMSS erhöht werden. Dies bläht das Stauffenster künstlich auf, um das zusätzliche Segment widerzuspiegeln, das das Netzwerk verlassen hat.

   Hinweis: [SCWA99] erörtert einen Angriff auf der Empfängerseite, bei dem viele gefälschte doppelte Bestätigungen an den Datensender gesendet werden, um cwnd künstlich aufzublähen und eine höhere als angemessene Senderate zu bewirken. Ein TCP DARF (MAY) daher die Anzahl der Male, in denen cwnd während der Verlusterholung künstlich aufgebläht wird, auf die Anzahl der ausstehenden Segmente (oder eine Näherung davon) begrenzen.

   Hinweis: Wenn kein fortgeschrittener Verlusterholungsmechanismus (wie in Abschnitt 4.3 beschrieben) verwendet wird, kann diese Erhöhung der FlightSize dazu führen, dass Gleichung (4) cwnd und ssthresh leicht aufbläht, da angenommen wird, dass einige der Segmente zwischen SND.UNA und SND.NXT das Netzwerk verlassen haben, während sie noch in der FlightSize widergespiegelt werden.

5. Wenn bisher ungesendete Daten verfügbar sind und der neue Wert von cwnd und das angekündigte Fenster des Empfängers dies zulassen, SOLLTE (SHOULD) ein TCP 1*SMSS Bytes bisher ungesendeter Daten senden.

6. Wenn die nächste Bestätigung eintrifft, die bisher unbestätigte Daten bestätigt, MUSS (MUST) ein TCP cwnd auf ssthresh setzen (den in Schritt 2 gesetzten Wert). Dies wird als „Entleeren" (deflating) des Fensters bezeichnet.

   Diese Bestätigung sollte die durch die Übertragungswiederholung aus Schritt 3 ausgelöste Bestätigung sein, eine RTT nach der Übertragungswiederholung (sie kann jedoch bei erheblicher Auslieferung von Datensegmenten außer der Reihe beim Empfänger früher eintreffen). Darüber hinaus sollte diese Bestätigung alle Zwischensegmente bestätigen, die zwischen dem verlorenen Segment und dem Empfang der dritten doppelten Bestätigung gesendet wurden, sofern keines davon verloren ging.

Hinweis: Es ist bekannt, dass dieser Algorithmus sich im Allgemeinen nicht effizient von mehreren Verlusten in einem einzelnen Paketflug erholt [FF96]. Abschnitt 4.3 unten behandelt solche Fälle.