メインコンテンツまでスキップ

3.2. 高速再送信/高速回復

順序外のセグメントが到着したとき、TCP受信側はすべきである (SHOULD) 直ちに重複確認応答を送信します。このACKの目的は、順序外のセグメントを受信したこと、およびどのシーケンス番号が期待されているかを送信側に通知することです。送信側から見ると、重複確認応答はいくつかのネットワーク問題によって引き起こされる可能性があります。第一に、失われたセグメントによって引き起こされることがあります。この場合、失われたセグメントより後のすべてのセグメントが、損失が修復されるまで重複確認応答を発生させます。第二に、ネットワークによるデータセグメントの並べ替えによって引き起こされることがあります (一部のネットワーク経路では珍しい事象ではありません [Pax97])。最後に、ネットワークによるACKセグメントまたはデータセグメントの複製によって引き起こされることがあります。さらに、TCP受信側は、受信したセグメントがシーケンス空間のギャップの全部または一部を埋める場合、すべきである (SHOULD) 直ちにACKを送信します。これにより、第4.3節で概説するように、再送タイムアウト、高速再送信、または高度な損失回復アルゴリズムを通じて損失から回復しようとしている送信側にとって、よりタイムリーな情報が生成されます。

TCP送信側は、受信した重複確認応答に基づいて損失を検出および修復するために、「高速再送信」アルゴリズムをすべきである (SHOULD) 使用します。高速再送信アルゴリズムは、3つの重複確認応答の到着 (第2節で定義され、SND.UNAを進めるACKが間に存在しないもの) を、セグメントが失われたことの指標として使用します。3つの重複確認応答を受信した後、TCPは再送タイムアウトの満了を待たずに、欠落していると思われるセグメントの再送を実行します。

高速再送信アルゴリズムが欠落していると思われるセグメントを送信した後は、非重複ACKが到着するまで「高速回復」アルゴリズムが新規データの送信を統制します。スロースタートを実行しない理由は、重複確認応答の受信が、セグメントが失われたことを示すだけでなく、セグメントがネットワークから出ていっている可能性が高いことも示すからです (ただし、ネットワークによる大規模なセグメント複製はこの結論を無効にし得ます)。言い換えれば、受信側はセグメントが到着したときにのみ重複確認応答を生成できるため、そのセグメントはネットワークを離れて受信側のバッファ内にあり、もはやネットワーク資源を消費していないことがわかります。さらに、ACKの「クロック」[Jac88] が維持されるため、TCP送信側は新規セグメントの送信を継続できます (ただし、損失は輻輳の指標であるため、送信は低減されたcwndで継続しなければなりません)。

高速再送信と高速回復のアルゴリズムは、次のように組み合わせて実装されます。

  1. 送信側が最初と2番目の重複確認応答を受信したとき、TCPは [RFC3042] に従って、受信側が通知したウィンドウが許し、FlightSizeの合計がcwndプラス2*SMSS以下に留まり、かつ送信可能な新規データがあることを条件として、すべきである (SHOULD) 以前に未送信のデータのセグメントを送信します。さらに、TCP送信側は、これら2つのセグメントを反映するためにcwndを変更してはならない (MUST NOT) [RFC3042]。SACK [RFC2018] を使用する送信側は、受信した重複確認応答が新しいSACK情報を含まない限り、新規データを送信してはならない (MUST NOT) ことに注意してください。

  2. 3番目の重複確認応答を受信したとき、TCPはssthreshを式(4)で与えられる値以下に設定しなければならない (MUST)。[RFC3042] を使用している場合、限定送信 (Limited Transmit) で送信された追加データをこの計算に含めてはならない (MUST NOT)。

  3. SND.UNAから始まる失われたセグメントを再送しなければならず (MUST)、cwndをssthreshプラス3*SMSSに設定します。これは、ネットワークを離れて受信側がバッファリングしたセグメントの数 (3つ) だけ輻輳ウィンドウを人為的に「膨らませる」ものです。

  4. さらに受信した各重複確認応答 (3番目以降) について、cwndをSMSSだけ増加しなければならない (MUST)。これは、ネットワークを離れた追加セグメントを反映するために輻輳ウィンドウを人為的に膨らませるものです。

    注: [SCWA99] は、cwndを人為的に膨らませて適切な値より高い送信レートを引き起こすために、多数の偽の重複確認応答をデータ送信側に送る、受信側ベースの攻撃について論じています。したがって、TCPは、損失回復中にcwndを人為的に膨らませる回数を、未処理セグメントの数 (またはその近似値) に限定してもよい (MAY)。

    注: 高度な損失回復メカニズム (第4.3節で概説されているものなど) を使用していない場合、SND.UNAとSND.NXTの間の一部のセグメントがネットワークを離れたと見なされながら依然としてFlightSizeに反映されているため、このFlightSizeの増加によって式(4)がcwndとssthreshをわずかに膨らませることがあります。

  5. 以前に未送信のデータが利用可能で、cwndの新しい値と受信側が通知したウィンドウが許す場合、TCPは以前に未送信のデータを1*SMSSバイト送信すべきである (SHOULD)。

  6. 以前に未確認応答だったデータを確認応答する次のACKが到着したとき、TCPはcwndをssthresh (手順2で設定した値) に設定しなければならない (MUST)。これはウィンドウの「収縮 (deflating)」と呼ばれます。

    このACKは、手順3の再送によって誘発された確認応答であり、再送の1 RTT後であるすべきです (ただし、受信側でデータセグメントが大幅に順序外で配送される場合には、より早く到着することがあります)。さらに、このACKは、失われたセグメントと3番目の重複確認応答の受信との間に送信されたすべての中間セグメントを、それらのいずれも失われていなければ、確認応答すべきです。

注: このアルゴリズムは、一般に、単一のパケットフライトにおける複数の損失から効率的に回復しないことが知られています [FF96]。以下の第4.3節でそのような場合を扱います。