要約

  • RFC 9332のDualQは、L4S用とClassic用のキューを分け、輻輳シグナルを結合する。ECT(1)と該当する場合のCEはL4S識別子だが、実際に入ったキューやAQMの判断、待ち時間の記録ではない。
  • 運用者はL4S識別子を保ったままパケットをClassicキューへ送れる。また、選んだ非L4SトラフィックをLキューへ入れても、そのECN識別子をL4Sに変えてはならない。
  • Koen De Schepper、編集者でもあるBob Briscoe、Greg Whiteによる仕様は、識別子に代わる証拠として、キューごとのトラフィック、マーキング、廃棄、平均遅延、99パーセンタイル遅延、過負荷事象の監視も求めている。

パスポートには旅程が書かれていない

境界で採取したパケットのECNフィールドがECT(1)だった。この観測から「L4Sを名乗っている」と読むことはできる。しかしダッシュボードが直ちに「低遅延」と表示すれば、未確認の二つの事実を埋めてしまう。途中の装置がどのキューへ分類したのか。そして実際にどれだけ待ったのか、である。

ECT(1)はL4Sを理解するノードに、送信側のプロトコル上の選択を伝える。通過した分類器、そのポリシー版、キュー、Active Queue Managementの判断、ボトルネックごとの滞在時間は含まれない。2ビットのフィールドを、経路全体の行動履歴として読むことはできない。

2023年1月にExperimental RFCとして公開されたRFC 9332は、Dual-Queue Coupled AQMの枠組みを定義する。L4S処理のLキューとClassicトラフィックのCキュー、それぞれのAQM、そして両者の輻輳シグナルを結ぶ仕組みである。スケジューラはLを優先するが、Cを飢餓させないよう優先度には上限が要る。非常に小さいキュー遅延、少ない輻輳損失、拡張可能なスループットは設計目標であって、識別子を見ただけで完了する認証ではない。

入国先を変えても識別子は消さない

RFC 9331はECT(1)と、必要な文脈でのCEをL4S識別子とする。これを設定する送信者は、L4Sの輻輳制御要件を満たすことが想定される。L4Sノードは通常、ECT(1)をLへ分類する。

重要なのは「通常」である。RFC 9332は、運用者がポリシー上の理由で特定のL4SパケットをLから外す余地を認める。その際、ローカルな処理が違うからといって、エンドツーエンドの識別子を書き換えてはならない。下流の運用者にも、送信者の元の意思を読み、自分の分類を選ぶ権利がある。

したがって、ECT(1)を観測、ノードXでポリシーYに一致、Cへ分類、識別子は保持という記録は矛盾ではない。識別子は送信者の事実、分類はその場所の事実である。

逆方向もある。アドレス、Diffservコードポイント、DNSのようなプロトコルを補助識別子として、サービスを害さないトラフィックをLへ入れることができる。それでもNot-ECTやECT(0)をECT(1)に変えてはならない。Lに入ったことはL4Sの身分を生まず、L4Sの身分は全ホップでLに入ったことを保証しない。

二つのキューは二色のレーンではない

DualQが解こうとするのは、異なるフィードバック特性の共存である。Classic輻輳制御はリンクを使い切るためにある程度の滞留を必要としやすい。Scalable制御は頻繁なECNシグナルへ小さなレート変化で反応できる。無防備に同居させれば、Scalable側がReno互換のフローよりはるかに攻撃的になり得る。

そこでキュー遅延は分離し、輻輳圧力は結合する。RFCの説明では、Classic AQMが基礎確率を作り、その二乗をClassicのマーキングまたは廃棄に使う。一方、倍率を掛けた値がL側への結合シグナルとなる。Lキューは、自身の即時的な遅延から生じるネイティブなシグナルと、Cから来る結合シグナルの強い方を採る。

このためCEマークはストップウォッチではない。L自身の状態、Cから結合された圧力、あるいは過負荷処理を反映し得る。目的はエンドポイントに調整を促すことで、当該パケットの待ち時間を報告することではない。

識別子とキューが食い違う場合は、さらに実行記録が必要になる。Cに入ったECT(1)には結合確率によるマーキングが想定される。Lに入ったECT(0)はClassic制御に適した扱いとLの遅延目標を両立させる。LのNot-ECTは、非応答フローからキューを守る別の仕組みの有無で処理が変わる。ECT(1)の総数だけでは、どの分岐が実行されたか分からない。

低遅延には複数の時計がある

正しいLキューの記録があっても、利用者体験の一部分を示すにすぎない。RFC 9332のキュー遅延は、先頭パケットのシリアライズ遅延とメディア獲得の遅延を除く。伝搬、別ノードの待ち時間、トランスポートの再送や回復、サーバのスケジューリング、アプリケーション処理も含まれない。

一つのDualQを数マイクロ秒で通っても、要求全体は遅いかもしれない。逆に、空のCを通る短いClassicパケットは速くてもL4Sにはならない。キュー遅延、エンドツーエンドRTT、アプリケーション応答時間は別の時計で測る必要がある。

平均値にも限界がある。実験実装はキューごと、サンプル区間ごとに平均と99パーセンタイルのキュー遅延を導けるべきで、診断用に最大値を持つこともできる。低い平均は少数の深刻なテールを隠す。期間のない最大値は過去の一件を永続的な状態に変える。統計名、期間、母数、観測位置を一緒に残さなければならない。

一か所のアクセス回線にDualQがあっても、経路全体は証明できない。別のボトルネック、Wi-Fiスケジューラ、トンネル終端、上流インターフェースが支配する可能性がある。「L4S対応経路」は複数主体にまたがる主張である。

過負荷では守れる約束が変わる

通常の応答性のある負荷なら、結合によってLを浅く保ちながらClassicを飢餓させないことを目指せる。想定外の流量と過負荷では判断が難しくなる。Lの優先が無条件なら、常に忙しいLがDNS要求や初期ウィンドウのような少量のCを短時間でも止めてしまう。

持続的過負荷にはもう一つの限界がある。ECNマーキングが100%に達すれば、それ以上強い信号をマークで送れない。RFC 9332は、過負荷を検出するDualQ実装に対し、事象が収束するまで両方のECN対応トラフィックへClassic型の廃棄を導入するよう求める。開始と継続時間を報告し、ヒステリシスで通知の嵐を避けることも示している。

ECT(1)は過負荷の前後で変わらない。その間にキュー、廃棄リスク、遅延は変わり得る。運用画面に必要なのは期限のないL4Sバッジではなく、時刻の付いた過負荷状態である。

Bob Briscoeが示した境界は共同作業の成果

RFC 9332の著者はKoen De Schepper、Bob Briscoe、Greg Whiteで、Briscoeが編集者を務める。謝辞と貢献者欄にはさらに広い技術コミュニティが記録されている。単独の発明者物語にする根拠はなく、特定運用者の導入判断をBriscoeに帰すこともできない。

本稿のために保存したIETF Datatrackerは、輻輳制御、ECN、トランスポートに関する彼の長い文書記録を示す。公式個人サイトは公開経歴と肖像の出典である。これらは人物と技術的寄与を確認するが、現在の市場占有率や特定ネットワークの挙動を証明しない。

ここで重要なのは境界の精密さだ。共有識別子は小さく安定させ、ローカル分類は文脈を持つ運用者に残し、共有ビットが語れない結果は実装の統計で示す。Heng Luの最小初期仕様と同じ発想である。Running-Code Primacyを当てはめれば、RFCと設定は仕組みの存在を示し、実際の分岐は稼働記録だけが示す。

代理問題は、最も安い観測が最も大きな約束へ変わるときに起きる。ベンダーはECT(1)カウンタを簡単に見せられる。分類器の版、キュー別カウンタ、テール遅延を出す負担は運用者にある。サービス低下は顧客が受ける。「L4S有効」という表示だけを調達条件にすれば、少ない証拠を持つ主体に説明権が集中する。

六つの受領記録をつなぐ

第一は送信者の記録で、トランスポート、輻輳制御実装と版、ECT(1)を設定した判断、フロー境界、時刻を持つ。第二はパケット境界で、観測ECN、カプセル化、インターフェース、方向、時刻、採取完全性を残す。

第三は分類器で、装置、ソフトウェア、ポリシー版、一致規則、補助識別子、L/Cの結果を示す。第四はキューで、実インスタンスとAQM、投入・排出観測、スケジューラ選択、想定外の組み合わせに使った分岐を残す。

第五は輻輳記録で、ネイティブと結合の圧力をCE、ECN・非ECN廃棄、過負荷の開始・終了、到着数、AQM提示数、転送数へ結ぶ。第六は性能記録で、キュー別利用率、平均、99パーセンタイル、任意の最大値、区間、ヒストグラム定義を持つ。RTTとアプリケーション時間は別にする。

この六つはL4S識別子を疑うためではない。識別子が観測した範囲だけを正しく語り、ローカル処理と結果をそれぞれの証人に返すためにある。

情報源