要約

  • RFC 3042 は、受信ウィンドウと飛行量の条件を満たすとき、連続する最初の二つの重複 ACK ごとに未送信の新データを送ることを認めた。
  • 追加の送信が既存の三重重複 ACK のしきい値に届くことはあるが、その間も cwnd は変更しない。

RFC 3042 が描く小さなウィンドウの問題は、セグメント一つの欠落だけではない。送信側に、既存の Fast Retransmit を始めるための ACK も十分に戻らない。cwnd が三セグメントで、その一つが落ちる例では、受信側から返る重複 ACK は多くても二つだ。ほかの信号がなければ、再送タイマーの満了を待つことになる。

Mark Allman、Hari Balakrishnan、Sally Floyd が 2001 年 1 月に公表した RFC 3042 は、Limited Transmit を提案する。まだ送っていないデータがキューにあれば、送信側は最初の連続した二つの重複 ACK に対し、それぞれ新しいセグメントを送るべき（SHOULD）だ。ただし、受信側の広告ウィンドウが許し、未確認データの合計が cwnd + 2 セグメント以下に収まる場合に限る。そして、その二つの送信を理由に cwnd を変えてはならない（MUST NOT）。

この区別が設計の芯にある。Limited Transmit は、厳しく限定した飛行量を追加してフィードバックの時計を動かそうとする。輻輳が解消したと判断することでも、輻輳予算を引き上げることでもない。疑わしい欠落セグメントをすぐに再送する仕組みでもない。新しいセグメントと、それに続く ACK が届けば、さらに一つ重複 ACK が返り、既存の三つというしきい値に達する可能性がある。その時点の再送は従来の Fast Retransmit が行う。RFC 3042 はそれを補い、置き換えない。

重複 ACK の意味は一つではない。受信側が順序の後ろにあるデータを受け取った一方で、欠けた位置を待っている場合もあれば、パケットが並べ替わった場合もある。最初の重複 ACK で古いセグメントを再送するより、新データを送る方が並べ替えに強い、というのが RFC の説明だ。ACK が三つ届いたという事実も、損失の物理的な場所や原因を特定するものではない。

条件は明確だ。キューに新データがあること、受信ウィンドウに余裕があること、FlightSize が cwnd + 2 セグメントを超えないこと。SACK を使う接続では、新しい SACK 情報を含まない重複 ACK に応じて新データを送ってはならない。SACK オプションの説明は RFC 2018 にある。条件が満たされない場合や、追加セグメントまたはその ACK が失われる場合、タイムアウトを避けられる保証はない。

後の RFC 5681 は、最初の二つの重複 ACK で新データを送る手順を Fast Retransmit/Fast Recovery の一連の流れに組み込み、二セグメントの上限と cwnd 不変の条件を維持した。これは仕様の系譜を示すが、計測されていない現代の実装が実際にどう動くかを証明しない。

RFC 3042 の歴史的位置づけは限定的だ。TCP の輻輳制御を作り直すのではなく、小さなウィンドウで ACK が不足する境界を補う。三つ目の重複 ACK、欠落データの再送、その後の累積 ACK は別々の状態遷移である。どれも単独では物理的な原因や、アプリケーションが有用なデータを受け取ったことを示さない。

参照資料