1. はじめに (Introduction)

Van Jacobsonのパケット保存原則 (packet conservation principle) [Jacobson88]は、受信者に配信されたN個のデータセグメントが確認応答を生成し、データ送信者がこれらの確認応答をクロックとして使用してネットワークに別のN個のデータセグメントを送信するトリガーとする自己クロックプロセスを定義しています。

Reno [RFC5681]やCUBIC [RFC9438]のような輻輳制御アルゴリズムは、この自己クロックプロセスの概念的基盤の上に構築されています。これらは、輻輳ウィンドウ (congestion window, "cwnd") を使用して「インフライト (inflight)」(接続が特定の時点でネットワーク内を飛行していると推定するデータ量) を制限することにより、トランスポートプロトコル接続の送信プロセスを制御します。さらに、これらのアルゴリズムは、トランスポートプロトコル接続がパケット損失に応答してcwndを削減することを要求します。高速リカバリ (fast recovery) ([RFC5681]および[RFC6675]を参照) は、このcwnd削減を実行するために確認応答からのフィードバックを使用するアルゴリズムです。その明示された目標は、リカバリ中にネットワークにより多くのデータをクロック化するために戻ってくるACKに依存することにより、送信者の自己クロックを維持することです。

比例速度削減 (Proportional Rate Reduction, PRR) がない場合、高速リカバリは通常、データを送信する前にラウンドトリップタイム (round-trip time, RTT) のほとんど (Reno [RFC5681]の場合はRTTの半分のACK、またはCUBIC [RFC9438]の場合はRTTの30%) を待機することによってウィンドウを調整します。

[RFC6675]は、「パイプ (pipe)」(送信者によるネットワーク内でまだ未確認のバイト数の推定値) を計算することにより、選択的確認応答 (Selective Acknowledgment, SACK) [RFC2018]をサポートする高速リカバリをより正確にします。[RFC6675]では、高速リカバリは、パイプがssthresh (高速リカバリのための輻輳制御アルゴリズムによって設定される目標ウィンドウサイズ) に一致するように上昇できるようにするために、各ACKで必要に応じてデータを送信することによって実装されます。これにより、多くの場合、重大な損失がある状況で高速リカバリがタイムアウトから保護されます。しかし、[RFC6675]には2つの顕著な欠点があります。

第一に、高速リカバリの開始時にcwndに非常に大きな乗法的削減を行うため、ウィンドウ全体の後半のデータまたはACKが失われた場合、タイムアウトを引き起こす可能性があります。第二に、大量の欠落データを暗示するSACKオプションを運ぶ単一のACKは、パイプ推定器にステップ不連続性を引き起こす可能性があり、これが高速再送信時にデータのバーストを送信させる可能性があります。

PRRは、これらの過度なウィンドウ調整を回避する方法で高速リカバリ中の送信プロセスを調整し、送信が滑らかに進行し、リカバリの終了時に実際のウィンドウサイズがssthreshにできるだけ近くなるようにします。

PRRが採用するアプローチは、Van Jacobsonのパケット保存原則に触発されました。PRRは、可能な限り自己クロックプロセスに依存し、飛行中のデータ量などの推定器の精度からはわずかな影響しか受けません。これが、他の推定器に不確実性を引き起こすイベントが存在する場合でも、アルゴリズムがその精度を維持する理由です。

インフライトがssthreshを上回っている場合、PRRは、配信されたデータとssthreshに比例する速度で送信をクロック化することにより、インフライトをssthreshまで滑らかに削減します。

インフライトがssthreshを下回っている場合、PRRは、すべてのメカニズム (一時的なアプリケーション停止および損失自体を含む) による総ウィンドウ削減を制限するために、2つの削減境界 (Reduction Bounds) の間で適応的に選択します。ベースラインとして、PRRは、相当な輻輳がある可能性がある場合の慎重さのために、パケット保存を厳密に遵守する保守的削減境界 (Conservative Reduction Bound, CRB) を使用します。リカバリが順調に進んでいるように見える場合、PRRは、PRR-CRBよりもACKごとに最大1セグメント攻撃的なスロースタート削減境界 (Slow Start Reduction Bound, SSRB) を使用します。

PRR-CRBは、付録Aで説明されている強いパケット保存境界 (Strong Packet Conservation Bound) を満たします。しかし、実際のネットワークでの性能は、[RFC6675]で説明されているアルゴリズムほど良くありません。後者は、単独のアルゴリズムとして使用される場合、多数のケースでより攻撃的であることが示されています。PRR-SSRBは、特定の状況でPRR-CRBに対してACKごとに1つの追加セグメントを送信することを許可することにより、妥協点を提供します。PRR-SSRBは[RFC6675]よりも攻撃的ではありません (より少ないセグメントを送信するか、送信により多くの時間を要します) が、リカバリ中の追加損失の確率が低いため、それを上回ります。

パケット保存原則の元の定義 [Jacobson88]は、失われたと推定されるパケット (例えば、再送信候補としてマークされたパケット) をネットワークを離れたものとして扱いました。このアイデアはPRRが使用するインフライト推定器に反映されていますが、付録Aで説明されている強いパケット保存境界とは異なります。後者は実際に受信者に到着したデータのみに基づいて定義されます。

本文書は、[RFC6937]のPRRの初期バージョンに対するいくつかの主要な変更を規定します。第一に、インフライトがssthreshを下回っている場合にPRRがどれだけ保守的になるか (PRR-CRBを使用するかPRR-SSRBを使用するか) を決定する手動で構成されたパラメータを置き換える新しい適応的ヒューリスティックを導入します。

第二に、アルゴリズムは非SACK接続 (「SACK-permitted」オプションを介してSACK [RFC2018]サポートを交渉しなかった接続) の動作を規定します。第三に、アルゴリズムは、送信者が高い並べ替えを経験し、かなりのシーケンス空間がSACKされた後まで損失リカバリを開始しない場合でも、滑らかな送信を保証します。

最後に、本文書には、PRRと輻輳制御および損失検出アルゴリズムとの統合に関する追加の議論も含まれています。

PRRは、2011年の最初の広く展開されたTCP PRR実装 [First_TCP_PRR]以来、複数のTCP実装で広範な展開経験を持っています。