要約

  • draft-ietf-ccwg-ratelimited-increase-11 は、アプリケーションの供給量や受信側フロー制御で送信量が制限されていても cwnd の増加を認める一方、過去に観測した最大 FlightSize から上限を導く。
  • その上限は送信側の状態を律するものであり、将来の帯域、受信 credit、pacing の実施、次のデータの到着を保証しない。

二十セグメント分の輻輳ウィンドウがある接続に、アプリケーションが四セグメントしか渡さない。四つはすべて確認され、損失も見えない。アルゴリズム上はウィンドウが健全に保たれ、条件次第では増える。

それでも、ネットワークが次回の二十四セグメント分を確保したわけではない。

2026年9月6日公開の draft-ietf-ccwg-ratelimited-increase-11 は、この境界を TCP、QUIC、SCTP、DCCP、CUBIC の間で揃えようとする CCWG の作業文書である。現在の仕様は、ウィンドウが使い切られていないときの増加について一様ではない。増加を止める方式は可変レートのアプリケーションを過度に保守的に扱い得る。無制限に増やせば、最近実際に使った経路容量から cwnd が離れていく。

草案でいう rate-limited は、輻輳制御が許す量より少なく送る状態だ。アプリケーションに送るデータがない場合も、受信側の接続またはストリーム credit が不足する場合も含む。いずれも輻輳そのものではないが、送信済みで未確認の量である FlightSize は、未確認データの上限 cwnd を下回る。

提案は maxFS という限定的な記憶を使う。これは直近の cwnd 減少以後に観測された最大 FlightSize である。FlightSize が更新されるたびに大きい値を残し、理由を問わず cwnd が減ればゼロへ戻す。その後の増加は limit(maxFS)、すなわち maxFS 一窓分が正常に送られ、その ACK に対してアルゴリズムが増やしたであろう最大値を超えてはならない。Slow Start の例では 2*maxFS、Congestion Avoidance では maxFS+SMSS が上限になる。

これは未使用分を将来へ繰り越す制度ではない。直前の一窓を使い切った事実に応じた通常の増加を許しつつ、アプリケーションや受信側が長く送信量を抑えた間に cwnd だけが膨張することを防ぐ。ACK された FlightSize は限定的な状態更新を支えるが、旧ウィンドウ内の空白が試験済みだったことにはならない。

草案自身が状態の陳腐化を認めている。別の縮小方法がなければ maxFS は長く残り、現在のエンドツーエンド経路を反映しなくなる可能性がある。その補完として参照される RFC 7661 は、測定 RTT 内で確認された量を pipeACK として扱い、最近検証された cwnd と古い容量に基づく非検証状態を区別する。瞬間値の FlightSize も、期間観測の pipeACK も、未来に対する権利書ではない。

運用では三つの権限を混ぜてはならない。アプリケーションは送るべきバイトを供給する。受信側は flow-control credit を決める。輻輳制御はネットワークの証拠から投入可能量を制限する。大きな cwnd は需要を作らず、受信側の背圧を解除せず、現在の経路に空きキューを用意しない。「利用可能スループット」という一つの値へ畳むと、それぞれの制御主体が消える。

pacing も別の事実だ。多くのデータを flight に置ける送信側でも、パケットを時間方向に分散してバーストを避けられる。草案の maxFS 上限は pacing を妨げないが、特定実装が pacing を有効にしたこと、適切な間隔を選んだこと、offload が再び塊を作らなかったことまでは示さない。

ACK の権限も過去の特定データまでである。ACK は損失回復や輻輳状態を更新できるが、経路が不変であること、競合トラフィックがないこと、policer が作動しないこと、受信 credit が増えること、次のオブジェクトをアプリケーションが受理することは保証しない。認証された ACK でも未来のネットワークの代理人にはなれない。

この草案が承認されれば RFC 4341、5681、9002、9260、9438 を更新する。ただし現在は変更可能な Internet-Draft で、IANA への要求もない。標準化の進展、コードへの実装、機能の有効化、実運用の成果には別々の証拠が必要だ。

出典