要約

  • 新方式は、アプリケーションまたは受信側に制限された送信者のcwnd増加を、直近の減少以降に実際に使った最大飛行量から算出する上限に収める。
  • 正当なACKは送ったデータの到着を示すが、経路に載せていない空き枠の安全性までは示さない。

数字だけが先へ進む

草案の例では初期ウィンドウを10セグメントとする。10個を送り、いったん停止する。損失がなく、1セグメントごとにACKが返れば、スロースタートでcwndは20になる。

次にアプリケーションが4個だけ用意する。4個は届き、確認される。制約がなければcwndは24になるが、1 RTTで実際に飛んだ最大量は依然10である。

ACKに誤りはない。実データの到着を正しく報告している。問題は、小さな飛行の成功から、一度も使っていない枠の増加まで承認したと解釈することだ。

これは障害報告ではない。遅延ACK、バイト単位の計算、ペーシングや損失を除いた説明用のケースである。だからこそ、何が送信者に未確認データを増やす権限を与えるのかが見える。

承認と稼働は別の状態

8月24日17時57分UTCの発表で、IESGは draft-ietf-ccwg-ratelimited-increase-10 をProposed Standardとして承認した。Congestion Control Working Groupの成果で、DCCP CCID 2、TCP、QUIC、SCTP、CUBICの既存規則を更新する。

8月28日の証拠固定時点では、Datatracker上はまだActive Internet-Draftで、RFC Editor queueにあり、著者の回答待ちだった。IANAへの措置はない。IESG承認、RFC番号、ソフトウェアへの実装、既定値、有効な運用結果を一つにまとめてはいけない。

発表は複数実装と、Linux 3.16以降の実運用経験を挙げる。実現可能性を支える材料ではあるが、すべてのカーネル、QUICライブラリ、装置が同じ判断と計測値を持つ証明ではない。

何が送信を止めたか

輻輳制御が送信を許しても、実際の送信は少ないことがある。アプリケーションにデータがない。受信側がTCPの受信窓、あるいはQUICの接続・ストリームcreditを絞る。ペーサーが間隔を広げる。

草案は、許可を使い切った状態をcwnd-limitedと呼ぶ。RFC 7661に基づき、cwndの半分以下しか使わない状態をrate-limitedかつ未検証の段階とする。

主体は別々である。アプリケーションは供給、受信側はcredit、トランスポートはcwnd、ペーサーは時刻、経路は損失・ECN・遅延・到達を決める。「未使用」という一語だけでは、どの面が閉じたのか分からない。

cwndは帯域幅の測定値でもない。現在のアルゴリズム状態で、未確認のまま飛ばしてよい量を示すローカルな許可である。将来の経路容量や受信アプリケーションの準備状態を保証しない。

maxFS が実使用に権限を結ぶ

新規則は、最後のcwnd減少以降に観測した最大の FlightSize を maxFS として保持する。初期値は初期ウィンドウで、その後は各飛行量との最大値を取る。

cwndが理由を問わず減れば、maxFS はゼロに戻る。次の飛行が新しい基準になる。損失やECNへの反応は現在の許可を縮めるだけでなく、過去の最大値が持っていた将来への効力も終わらせる。

FlightSize < cwnd のときもACKによる増加は可能だが、結果は limit(maxFS) を超えない。これは maxFS と同じ大きさの一窓をすべて送り、すべて成功したなら、元のアルゴリズムが到達したはずの値である。

RFC 5681のスロースタート例では 2 * maxFS、輻輳回避では maxFS + SMSS が上限になる。ACKを無視するのではなく、その証明力を限定する。

10と4の例なら、最初の飛行で20まで増やせる。次の4ACKは有効でも20を越えられない。後の飛行が実際に10を超えたとき、初めて maxFS と上限が動く。

共通原則は同一実装を意味しない

標準TCPにはこの状況の明確な上限がなかった。DCCP CCID 2はcwndを使い切らずに増える余地があった。一方、QUICは未使用時に増加しないよう求め、SCTPとCUBICにも保守的な停止条件があった。

新文書は、完全停止より柔軟で、無制限増加より厳しい共通の上限を置く。レート型制御も、このcwnd方式が許した最大持続レートを超えてはならない。ペーシングは、1 RTTの飛行量を水増ししない限り使える。

BBRのような複合型では、推定レート、pacing rate、cwnd、アプリケーション制限サンプルを分ける必要がある。標準が共通化するのは根拠の上限であり、コードや計測面すべてではない。

古い最大値は別の経路に残り得る

草案自身が、cwndが減らないと maxFS が長く残り、現在のエンドツーエンド経路を反映しなくなると警告する。移動通信の切替、ルート、トンネル、キュー方針の変更が変数を都合よく初期化するとは限らない。

RFC 7661のCongestion Window Validationと pipeACK は、最近の飛行より大きくなった窓の妥当性を扱う関連機構である。増加を制御する今回の方式と同一ではない。

最大値の保持は、アプリケーションが休むたびに学習し直す無駄を減らす。反対に、時刻、経路、減少理由を失えば、由来のない古い記憶になる。

ACKの真正性にも意味の限界がある

輻輳制御は受信側が適切にACKすることを前提とする。攻撃耐性はトランスポートの認証・保護特性に依存する。しかし正当なACKでも、確認するのは特定の送信だけで、未使用容量、将来RTT、公平性、経路安定性までは保証しない。

現在のLinux RenoとCUBICは、増加前に tcp_is_cwnd_limited() を確認する。これは稼働コードの公開例であり、特定フリートの構成証明ではない。

運用では、トランスポートとbuild、アプリケーションキュー、受信credit、ペーシング、cwnd、FlightSize、maxFS、初期窓、ssthresh、ACK済みバイト、損失・ECN減少、計算上限、経路、再開後の損失と遅延を一つの時間軸に結ぶ。文書は最小規則を示す。ローカルな安全性は稼働結果が示す。

出典