要約

  • PRRはACKが示す配送済みデータを用いて、そのACKに応じて送ってよい量SndCntを算出し、別の輻輳制御が選んだssthreshへ在送データ量を滑らかに近づける。
  • ACKが証明するのは限定された配送の進捗であり、経路全体の健全性ではない。実運用の主張には、目標の決定元、選ばれたPRR分岐、実送信量、pacing、結果の測定を別々に残す必要がある。

最後の数字だけでは見えない

二十セグメントが飛行中に損失が起き、輻輳制御アルゴリズムが回復後の目標を十に設定したとする。従来型の回復では、ウィンドウを一気に下げ、在送量が減るまで送らず、その後に複数セグメントをまとめて出すことがある。RFC 9937の例にある「半ウィンドウ分の沈黙」だ。在送量推定が段差状に変われば、逆に大きなバーストが許可される場合もある。

PRRが問い直したのは、十という終点ではなく、そこへどう近づくかだった。ACKが届くたびに送信可能量を計算し直し、自発的なウィンドウ縮小を一往復時間に分散させる。総送信量が同じでも、ネットワークへ提示される時間の形は変わる。

出発点となった2011年の論文は、Nandita Dukkipati、Matt Mathis、Yuchung Cheng、Monia Ghobadiの共著である。短いフロー、アプリケーション停止、連続損失、ACKの損失や並べ替え、stretch ACKを調べ、従来方式が過剰にウィンドウを落としたり、大きなバーストを生んだりする状況を示した。同研究の対象では、PRRと早期再送の検討によって、損失を経験した接続のTCP遅延が応答サイズに応じて3〜10％減った。これは測定条件付きの結果であり、あらゆる経路への保証ではない。

2013年にはMathis、Dukkipati、Chengによる実験的RFC 6937が発行された。2025年12月、Mathis、Neal Cardwell、Cheng、Dukkipatiによる標準化過程のRFC 9937がこれを置き換えた。Dukkipatiと課題の継続的な関係は、この論文、実験仕様、改訂標準によって確認できる。ただし単独発明や全実装への支配を意味しない。

目標と観測と送信許可

PRRの設計は、権限を三つに分けて読むと明快になる。

まず輻輳制御がssthreshを選ぶ。これは回復終了時に目指す在送データ量である。RenoやCUBICなど対応する制御方式が決めるのであって、PRRは輻輳の深刻さを独自に裁定しない。

次に回復処理がACKから進捗を見積もる。DeliveredDataは、現在のACKが前回以降に受信側へ届いたと示すバイト数について、送信側が持つ最良推定である。「最良推定」という限定が重要だ。順方向の全状況、逆方向、アプリケーション、損失原因を一枚のACKが説明するわけではない。

最後にPRRがSndCnt、つまりそのACKへの応答として送信してよい正確なバイト数を計算する。欠けたデータを再送するか、新しいデータを送るかは別の選択機構が決める。PRRが握るのは量とタイミングであり、中身ではない。

この分業は、共通層を薄くしながら曖昧にしない。相互運用に必要な計算だけは決定的に定め、異なる状態を必要とする判断は、それを持つローカルな部品に残す。ACKの到着を、万能の許可へ昇格させない設計である。

配送実績をリリースの時計にする

回復開始時、送信側はそのエピソードで配送され得る初期飛行量の推定RecoverFSを記録する。ACKで確認された累積進捗はprr_deliveredへ、回復中に送った量はprr_outへ入る。

inflightがssthreshより大きい間、PRRは、初期飛行量のうちどれだけが届き、目標がどれだけ小さいかに応じて、現時点までに放出されるべき総量を比例計算する。そこから既送信のprr_outを引き、次のSndCntを得る。

ここでACKは経路の診断書ではない。限られた送信予算を開く受領票だ。進捗が小刻みなら、放出も小刻みになる。途中のACKが失われても、後のACKがより大きな配送量をまとめて示し、計算が追いつく。推定値の段差だけを理由に、無制限のバーストを出す必要はない。

PRRの節度はここにある。局所的に検証できる信号を、その信号に見合う行為だけに使う。ACKはssthreshを選ばず、経路が治ったとも宣言しない。

目標より下では、慎重さを切り替える

重い損失ではinflightがssthreshより下へ落ちる。配送済み量だけに厳密に従えば遅すぎることがある一方、空きが見えた分を無条件に埋めれば再損失を招く。RFC 9937は二つのReduction Boundを使い分ける。

既定はConservative Reduction Bound（CRB）で、送信量を配送の進捗に強く結び付ける。SafeACKが真なら、Slow Start Reduction Bound（SSRB）が送信側最大セグメント一個分まで上乗せできる。条件は、累積ACKが前進し、そのACKが新たな損失を示していないことだ。

2025年版が選択を適応的にした背景には、トークンバケット型ポリサーがある。トークン枯渇後、端点へ補充速度を知らせないまま大量廃棄へ移る装置があり、過去の性能から選んだssthreshが高すぎる場合がある。そこで既定を保守的にし、定義された進捗が確認できたACKだけに一段の余地を与える。

SafeACKという名前を広く解釈してはならない。それは経路が安全という意味ではなく、この分岐で追加一セグメントを許す二条件が満たされたという意味にすぎない。

終了時にも残るバースト

送信のたびにprr_outが増え、回復終了時にはcwndがssthreshへ設定される。終点は明確になる。しかしRFC 9937は、この終了処理が状況によって連続セグメントのバーストを許す可能性を認め、pacingの利用を推奨する。

したがってPRRは、すべての時間的リスクを消したという主張ではない。穏やかなpacingがもたらし得る効果の一部も、同RFCは未定量だとする。標準としての審査と、ある配備が正しく動いた証拠は別物である。

RFC 9937は、2011年の最初の広範な実装以来、PRRがLinux TCPで既定および対応する輻輳制御モジュールの高速リカバリーに使われてきたと記す。重要な稼働実績だが、特定カーネルが昨日どの分岐を通ったか、pacingが有効だったか、利用者遅延が改善したかまでは証明しない。

運用証跡に残すべきもの

検証可能な主張には、トランスポートまたはカーネルのビルド、輻輳制御モジュール、損失検出の契機、開始時のcwnd、inflight、RecoverFS、ssthreshを選んだ部品と設定が必要だ。

対象ACKごとに、累積進捗、新規損失、DeliveredData、SafeACKの値と理由、比例・CRB・SSRBのどの分岐か、計算されたSndCnt、実送信バイト、更新後のprr_outを残す。再送か新規データかを決めた別判断も記録する。

終了時には、最終ウィンドウと在送量、pacingの状態、バースト、タイムアウト、再損失、そして比較可能な対照群に対する遅延とgoodputの分布を確認する。並べ替え、アプリ停止、対応範囲でのSACK・非SACK、ポリサーも試験する。ACKは進んでも経路やアプリの結果が悪い反例を捨ててはならない。

証跡は主張の順序を守る。ACKは配送を観測した。輻輳制御は目標を選んだ。PRRは枠を計算した。別機構がバイトを選び、稼働コードが送った。効果を証明するのは測定であり、RFC番号ではない。

出典