要約

  • RFC 9937 の PRR は、高速回復中に送信側が ACK ごとに送る量を整える。目標の ssthresh は輻輳制御アルゴリズムが選び、PRR はそこへ flight size を近づける。
  • SndCnt が正しく計算されたことは、送信側の許可を示すにとどまる。ボトルネック、受信アプリケーション、他事業者のキュー、顧客結果を示すものではない。

障害会議では、ACK の再開が「回復」の短い同義語になりがちだ。しかし RFC 9937 が定めるのは、その短縮を正当化する規格ではない。2025 年 12 月の Standards Track 文書は RFC 6937 を置き換え、TCP 等の高速回復時に送るデータ量を調整する。終了時の実際の flight size を、輻輳制御アルゴリズムが選んだ ssthresh に可能な限り近づけるためである。

送信側は DeliveredData、inflight、RecoverFS を最良推定として持つ。ACK が示す配達、未確認データ、回復期間に配達され得る量はいずれも、経路全体の台帳ではない。SafeACK と回復カウンタも合わせて SndCnt を決める。目標より上なら比例的に送り、下なら保守的な境界を使い、進捗が良い ACK のときだけ限定的に緩める。終了時に cwnd を ssthresh にすることは、バーストを生み得るため、別途 pacing が推奨される。

SACK があれば精度は上がるが必須ではない。損失検出の方法も異なり得る。SACK のない場合には、余分な duplicate ACK が配達推定を膨らませないよう制限まで置かれている。これは PRR が慎重でないという意味ではない。慎重なローカル計算も、観測していないキューや受信側の処理を知ることにはならないという意味である。

増分導入は送信側の輸送実装だけを変え、受信側やネットワークの変更を要求しない。Reno や CUBIC と使えても、公平性は輻輳制御アルゴリズムが担う。送信スケジューラが共有資源の判定者になるわけではない。

残すべきは緑の一語ではなく、制御アルゴリズム、ssthresh、ACK/SACK と損失検出の入力、推定値、SndCnt、再送/pacing、ウィンドウとアプリケーション制約、そして後段の独立観測である。亨路の実行中コード優先は、実装が算出した事実を尊重しつつ、それを経路全体の権威にしないための境界である。

出典