3.2. 高速再送信/高速回復
受信側の動作
TCP受信側は、順序が乱れたセグメントが到着したときに即座に重複ACKを送信すべきである (SHOULD)。このACKの目的は、順序が乱れたセグメントが受信されたこと、および期待されるシーケンス番号が何であるかを送信側に通知することです。
重複ACKの原因
送信側の観点から、重複ACKは多くのネットワーク問題によって引き起こされる可能性があります:
- ドロップされたセグメント: ドロップされたセグメントの後のすべてのセグメントは、損失が修復されるまで重複ACKをトリガーします
- ネットワークによるデータセグメントの再順序付け(一部のネットワークパスでは珍しいイベントではありません[Pax97])
- ネットワークによるACKまたはデータセグメントの複製
ギャップ埋めのためのACK
さらに、TCP受信側は、受信したセグメントがシーケンス空間のギャップの全部または一部を埋める場合、即座にACKを送信すべきである (SHOULD)。
高速再送信アルゴリズム
TCP送信側は、受信した重複ACKに基づいて損失を検出および修復するために「高速再送信」アルゴリズムを使用すべきである (SHOULD)。
高速再送信アルゴリズムは、3つの重複ACK(第2節で定義されているように、SND.UNAを移動する介在ACKなし)の到着をセグメントが失われた指標として使用します。3つの重複ACKを受信した後、TCPは再送信タイマーの期限切れを待たずに、失われたように見えるセグメントの再送信を実行します。
高速回復アルゴリズム
高速再送信アルゴリズムが失われたように見えるセグメントを送信した後、「高速回復」アルゴリズムは、非重複ACKが到着するまで新しいデータの送信を管理します。
根拠
スロースタートを実行しない理由は、重複ACKの受信がセグメントが失われたことを示すだけでなく、セグメントがネットワークを離れている可能性が高いことも示しているためです(ネットワークによる大規模なセグメント複製がこの結論を無効にする可能性がありますが)。
言い換えれば、受信側はセグメントが到着したときにのみ重複ACKを生成できるため、そのセグメントはネットワークを離れて受信側のバッファにあり、ネットワークリソースを消費していないことがわかります。
高速再送信と高速回復の実装
高速再送信と高速回復アルゴリズムは次のように一緒に実装されます:
1. 最初と2番目の重複ACK
送信側で最初と2番目の重複ACKを受信したとき、次の条件が満たされる場合、TCPは[RFC3042]に従って以前に送信されていないデータのセグメントを送信すべきである (SHOULD):
- 受信側の通知ウィンドウが許可する
- 合計FlightSizeがcwnd + 2*SMSS以下のままである
- 送信用の新しいデータが利用可能である
さらに、TCP送信側はこれら2つのセグメントを反映するためにcwndを変更してはならない (MUST NOT) [RFC3042]。
2. 3番目の重複ACK
3番目の重複ACKが受信されたとき、TCPはssthreshを式(4)で与えられる値以下に設定しなければならない (MUST)。
3. 再送信とウィンドウの膨張
SND.UNAから始まる失われたセグメントを再送信しなければならず (MUST)、cwndをssthresh + 3*SMSSに設定します。これは、ネットワークを離れて受信側がバッファリングしたセグメント数(3つ)だけ輻輳ウィンドウを人為的に「膨張」させます。
4. 追加の重複ACK
受信した各追加の重複ACK(3番目の後)に対して、cwndをSMSSだけ増加しなければならない (MUST)。これは、ネットワークを離れた追加のセグメントを反映するために輻輳ウィンドウを人為的に膨張させます。
5. 以前に送信されていないデータの送信
以前に送信されていないデータが利用可能で、cwndの新しい値と受信側の通知ウィンドウが許可する場合、TCPは1*SMSSバイトの以前に送信されていないデータを送信すべきである (SHOULD)。
6. ウィンドウの収縮
以前に未確認応答のデータを確認応答する次のACKが到着したとき、TCPはcwndをssthresh(ステップ2で設定された値)に設定しなければならない (MUST)。これは「収縮」ウィンドウと呼ばれます。
制限事項
注意: このアルゴリズムは、単一のパケットフライト内の複数の損失から効率的に回復できないことが一般的に知られています[FF96]。以下の第4.3節でこのようなケースに対処します。