要約

  • 受信側は実容量 fcwnd と低遅延バックグラウンド目標 RLWND の小さい方を通知し、送信側は従来の cwnd も適用する。
  • 実効上限 min(cwnd, RLWND, fcwnd) は速度を決めるが、どの権限が原因だったかは語らない。
  • 監査可能な導入には三候補、timestamp 品質、Window Scale、窓を縮小せずに目標へ収束した時間の記録が必要だ。

遅れて見えることが正しい場合

TCP の受信窓は単なるレート設定ではない。右端まで送ってよいという約束である。受信側が小さな RLWND を計算しても、既に進めた右端を後退させてはならない。到着したバイト分だけ通知窓を減らし、約 1 RTT をかけて新目標へ近づく。

したがって、判断直後のパケットが古い大きさを残すのは制御失敗とは限らない。判断時刻、目標、通知値の列、in-flight bytes がなければ、ダッシュボードは約束を守る挙動を遅延と誤認する。

一つの欄に二つの受信側理由

通常の fcwnd はバッファとアプリケーションの受信能力を守る。rLEDBAT の RLWND は、キュー遅延を増やさぬようバックグラウンド通信を譲らせる政策だ。受信側は小さい方を通知する。送信側では輻輳窓 cwnd がさらに効き、SND.WND = min(cwnd, RLWND, fcwnd) となる。

三候補は、送信側と経路、受信能力、受信政策という別々の権限に属する。ワイヤ上の最小値だけでは、アプリケーションが遅いのか、クライアントが意図的に譲ったのか、経路が詰まったのかを区別できない。

rLEDBAT の利点は、更新クライアントがサーバーを改造せずに制御できる点にある。標準 TCP 送信側は窓に従うだけだ。ただし損失時の再送や、より小さい cwnd の権限は残る。受信制御は追加であり置換ではない。

時刻は観測値であって証明書ではない

TCP Timestamps の進み方と到着時刻を比較すれば、時計同期なしに順方向遅延の変化を追える。一定のオフセットは差分で消えるが、分解能、skew、同一 timestamp、Delayed ACK、逆方向キュー、再送は残る。末尾損失は後続セグメントがなく、受信側が推測できないこともある。

生の標本、採用標本、除外理由、base delay、RTT を RLWND と結び付けるべきだ。到着時刻は認証されたキュー状態でもない。経路上の攻撃者が遅延観測を動かせば、パッチ取得を長く譲らせる余地がある。

接続開始時に決まる粗さ

Window Scale は大きな窓を表せる代わりに一段を粗くする。RFC は 11 を超える factor が粗すぎる可能性を示し、12 未満を推奨するが、実験課題として残している。値は接続確立時に交渉される。後で細かな制御が必要と判明しても、その接続中には直しにくい。

Experimental の中心

RFC 9840 は IRTF/ICCRG の Experimental 文書である。送受信二つの制御ループ、AQM、L4S、idle 後の再開は未解決の観測対象だ。平均スループットだけでなく、queue delay 分布、loss、ECN、アプリ需要、三窓、idle 区間、送信 CC を記録する必要がある。

Microsoft Delivery Optimization と Apple の資料は OS がバックグラウンド通信を管理する実務的需要を示すが、特定製品が RFC 9840 を実装した証拠ではない。実装主張にはコード、管理された測定、または vendor の明示が要る。

出典