低遅延・低損失・スケーラブルなスループットのための L4S インターネットサービス: RFC 9330
(datatracker.ietf.org)- RFC 9330 は、インターネットアプリケーションのキューイング遅延と輻輳損失を減らすためのL4S アーキテクチャを定義し、遅延の根本原因をキューそのものよりも送信側の容量探索型輻輳制御にあると捉える
- L4S は、送信ホストのScalable congestion control、ボトルネック地点の AQM、ECN ベースのプロトコルを組み合わせ、L4S パケットの識別には IP-ECN フィールドの**ECT(1)**コードポイントを用いる
- 目標とするキューイング遅延は平均 1ms 未満・99 パーセンタイルで約 2ms 未満であり、DCTCP と Dual-Queue Coupled AQM の例では、過負荷時でも 99 パーセンタイルのキューイング遅延はおおむね1〜2ms水準
- 既存の Reno/CUBIC 系Classic 輻輳制御と共存するため、L4S は Classic トラフィックと L4S トラフィックの遅延を分離しつつ、帯域幅は固定分割せず長期的に共有するよう設計されている
- L4S は Diffserv、FQ-CoDel、PIE、BBR を置き換えるのではなく補完するものであり、TCP では AccECN のような精密なフィードバックが必要で、QUIC・DCCP は L4S に必要な ECN フィードバックをすでに提供している
L4S が解決しようとする遅延問題
- Web、音声、ビデオ会議、ゲーム、リモートデスクトップ、クラウドアプリケーション、AR/VR、遠隔制御のように、低遅延を好むトラフィックがボトルネックリンクを埋める状況が増えている
- キャッシュやサーバーをユーザー近くに配置することで伝搬遅延は減ったが、キューイングは依然として遅延の主要かつ断続的な要素として残っている
- 最新の AQM があっても、数百 ms の遅延スパイクは珍しくない
- Classic AQM は、単一の長寿命フローによるノコギリ波状のキュー変動をバッファリングするよう設定されることが多く、その結果、長寿命フロー中のネットワーク全体の遅延ピークが基底経路遅延のおよそ 2 倍になることがある
- L4S の目標は、極めて低いキューイング遅延、極めて低い損失、スケーラブルなスループットである
- 極めて低いキューイング遅延とは、平均 1ms 未満、99 パーセンタイルで約 2ms 未満を意味する
- より厳しいインタラクティブアプリケーションでは、エンドツーエンド遅延が 50ms または 20ms を超えると不自然に感じ始める
- 損失はインタラクティブアプリケーションで再送遅延につながるため、低損失も重要な目標である
遅延の原因: キューよりも Classic 輻輳制御
- L4S は、キューイング遅延の根本原因をキューそのものよりも送信側の容量探索型輻輳制御にあると考える
- Reno や CUBIC のような Classic 輻輳制御は、キュー占有率を大きなノコギリ波状に変動させる
- AQM がキューを浅くしすぎると、Classic 輻輳制御はノコギリ波の谷ごとにリンクを十分活用できない
- フロー速度が上がるほど Classic 輻輳制御の回復時間が長くなり、キューと利用率の制御が緩くなる
- Scalable congestion control は、フロー速度が大きくなっても輻輳シグナル間の平均時間、すなわち回復時間を一定に保つ
- DCTCP は制御された環境で広く使われる例である
- Windows Server Editions、Linux、FreeBSD に実装・展開されている
- TCP/QUIC 上の Prague、L4S 向け SCReAM、BBRv2 の L4S ECN 部分も Scalable congestion control の例に含まれる
L4S アーキテクチャの 3 つの構成要素
- L4S は 3 つの構成要素から成る
- 送信ホストのScalable congestion control
- ネットワークボトルネックのAQM
- 両者の間でパケット識別と輻輳シグナルを担うECN ベースのプロトコル
- 低遅延はネットワークが直接提供するものではなく、L4S 送信側の慎重な Scalable congestion control の動作から生まれる
- ネットワークの主な役割は、L4S トラフィックの低遅延を、Classic トラフィックが必要とするより大きなキューイング遅延から隔離することである
- ネットワークは ECN を使って、キュー増加のごく初期の兆候を即座にトランスポート層へ知らせる
- Classic AQM のように、キュー変動を大きく平滑化してからシグナルを出すことはしない
- ECN 対応は L4S に必須である
- 送信側は ECN フィールドを使い、ネットワークが L4S パケットと Classic パケットを区別できるようにする
ECN と ECT(1) コードポイント
- L4S は、Classic ECN の「ECN シグナルはドロップと同等に扱うべき」という制約から離れた、より細かな輻輳シグナルを必要とする
- シグナルはより頻繁に発生できる必要がある
- キュー変動を平滑化するための大きな遅延なしに、即時にシグナル化できる必要がある
- RFC8311 は RFC3168 の一部要件を緩和し、L4S の実験を可能にした
- RFC9331 は、ECT(1) を L4S パケット識別子として使うよう規定している
- CE コードポイントは、L4S と Classic の両方の処理で Congestion Experienced を示すために使われる
- 経路上流の Classic AQM が ECT(0) パケットを CE としてマークした場合、L4S キューへ誤分類される懸念がある
- RFC9331 付録 B によれば、有害な影響が生じるには 5 つのまれな条件がすべて重なる必要があり、その場合でも誤再送の可能性は極めて小さい
- 運用者は、キューを作らないほど低く滑らかな非 L4S トラフィックを L4S キューに入れたい場合がある
- 例としては VoIP、オンラインゲーム同期用の低速データグラム、DNS、LDAP などがある
- この場合、EF、NQB、運用者固有の識別子のような別のマーキングが必要となる
Dual-Queue Coupled AQM
- L4S は、ネットワークコンポーネントがフロー単位の処理を必須としなくても低遅延を提供できることを目指している
- 代表的設計であるDual-Queue Coupled AQMは、2 つのキューを使う
- L4S キューは低遅延を維持する
- Classic キューは、Classic トラフィックがリンク利用率を維持するのに必要な、より大きなキューを持てる
- DualQ は、遅延は分けるが帯域幅は固定分割しない半透膜のように動作するよう設計されている
- Classic AQM が自身のキュー輻輳ベースのドロップ/マーキング確率を生成し、それを Classic キューと L4S キューのシグナルに結合する
- 結合された輻輳シグナルによって、L4S フローは Classic フローに必要な容量を残すよう速度を下げる
- スケジューラは L4S キューに優先度を与えられる
- 短い時間スケールでは、L4S バーストを素早く解消して低遅延を守る
- RTT を超える長い時間スケールでは、Classic キューの輻輳シグナル結合が帯域優先を相殺し、おおよそのフロー単位公平性を生む
- L4S トラフィックだけが存在する場合、L4S キューの AQM は非常に浅いキューで輻輳マーキングを開始し、低いキューイング遅延を維持する
フロー単位キュー方式と DualQ の違い
- FQ-CoDel、FQ-PIE のようなフロー単位キューも L4S に利用できる
- Linux では、浅い ECN マーキング閾値を ECT(1) パケットにのみ適用できるよう改修されている
- Not-ECT または ECT(0) フローには Classic AQM が適用され、ECT(1) フローには一般に 1ms 未満の浅い閾値が適用される
- フロー単位アプローチは各フローのキューを分離するが、フロー自体が生み出すキューイングを除去することはできない
- DualQ 方式は、L4S 識別子が IP-ECN フィールドにあるため、IP 層より深い検査を必要としない
- IPsec や暗号化 VPN トンネルのようにトランスポート層識別子が暗号化される環境でも利用できる
- フロー単位方式では、アプリケーションフロー間の相対的な速度制御をネットワークが担うことになる
- DualQ は、低遅延の提供とフロー速度制御の問題を分離し、必要なら別個のフロー速度ポリシングを追加できる
ホスト側要件
- 送信側はScalable congestion controlを実装しなければならない
- DCTCP が最も広く使われる例だが、パブリックインターネットで使うには安全性と性能の改善が必要である
- Prague の L4S 要件のうち、他者へ害を与えるリスクに関する部分は RFC9331 の規範要件に含まれている
- TCP Prague は Linux でリファレンス実装として実装されている
- TCP 以外のトランスポートプロトコルも、L4S サービスを使うには Scalable な輻輳応答を実装し、ECT(1) コードポイントでそれを示す必要がある
- QUIC 向けの Scalable 変種が検討されている
- BBRv2 の L4S ECN 部分は、TCP や QUIC など向けの Scalable congestion control として提示されている
- RTP メディア向け SCReAM の L4S 変種も実装されている
- ECN フィードバックはプロトコルごとに状況が異なる
- DCCP と QUIC は、L4S に十分細かな ECN フィードバックを提供する
- TCP の既存 ECN フィードバックは、ECN マークをドロップと同等に見る前提があるため、Scalable TCP には使えない
- TCP 受信側には、より正確な ECN フィードバックであるAccECNの対応が必要である
- SCTP は、L4S をサポートするには新しい ECN 設計の実装と展開が必要になる
- RTP では、RFC6679 と RFC8888 で十分な ECN フィードバックが定義されている
なぜ明示的輻輳シグナルが必要か
- L4S は、損失の代わりに明示的輻輳シグナルを中核手段として使う
- ドロップは性能低下であると同時にシグナルでもあるため、「少ないほど望ましい損傷」と「多いほど望ましいシグナル」という緊張関係を生む
- ECN ベースの明示的シグナルは、損傷なしに RTT ごとに複数回使えるため、キューを短く保つのに有利である
- L4S は、平滑化をネットワークではなくホスト側へ移す
- ネットワークは各フローの RTT を知らないため、Classic 方式では最悪の RTT を前提にしなければならない
- このため Classic 輻輳シグナルは 100〜200ms 遅れることがある
- 各ホストは自身の RTT を知っているので、必要なぶんだけ、通常は数 ms 程度で平滑化できる
- L4S キューは、ドロップと同等ではない新しい L4S ECN 変種を使い、Classic キューは Classic ECN またはドロップを使う
スループット拡張性の根拠
- Classic Reno 輻輳制御は、高帯域幅・高遅延積の環境になるほど回復時間が長くなる
- 例の条件は、ノコギリ波ピークで最大 RTT 30ms である
- Reno のパケットレートが 1,250packet/s から 10,000packet/s に 8 倍増えると、1500B パケット基準で約 15Mb/s から 120Mb/s に増え、回復時間は 422ms から 3.38s に伸びる
- CUBIC は 120Mb/s では Reno-friendly モードで動作し、回復に約 4.3s かかる
- 960Mb/s では true CUBIC モードに入り、回復時間は 12.2s になる
- 7.68Gb/s では回復時間が 24.3s まで延びる
- DCTCP や Prague のような Scalable congestion control は、平均して RTT あたり 2 つの輻輳シグナルを引き起こし、この特性はフロー速度に関係なく維持される
- 2020 年の世界平均固定接続容量は 103Mb/s で、2019 年の CDN までの平均基底 RTT は 25〜34ms だった
- 単一の CUBIC ダウンロードフローは、輻輳ウィンドウ減少後に回復するのに最良の場合でも約 200 RTT、すなわち 5 秒かかることがある
既存技術との関係
- Diffservは重要トラフィックの帯域配分と遅延感度の高いトラフィックのキューイング遅延を扱うが、L4S はキューイング遅延の問題だけを扱う
- Diffserv は、ボトルネックで一部のトラフィックだけが低遅延を要求する場合に有効である
- ボトルネック上のすべてのトラフィックが低遅延を望むなら、Diffserv の区別の利点は失われる
- L4S 識別子は品質要求ではなく、Scalable な輻輳応答という行動上の約束を表す
- PIE や FQ-CoDel のようなClassic AQMは、AQM がまったくない場合よりキューイング遅延を大きく減らす
- L4S はこれらを補完するものであり、広範な展開の必要性を置き換えるものではない
- AQM だけでは、Classic 輻輳制御の大きなノコギリ波のため、遅延とリンク利用率の間の緊張を解消しにくい
- ABE は、ECN マーキングへのホスト応答を変えることでリンク利用率と ECN フローのスループットを高めるが、ネットワークが依然として ECN とドロップを同一に扱う前提に立っている
- BBR は、特別なネットワークロジックなしにエンドツーエンドでキューイング遅延を制御する
- BBR はキューイング遅延を十分低く保つが、L4S ほど低くはない
- BBRv2 は、可能であれば L4S ECN と Scalable L4S 輻輳制御動作を利用できる
適用可能なアプリケーション
- L4S は、負荷がかかった状態で既存アプリケーションの品質を大きく改善できる
- ゲームとクラウドゲーム
- VoIP
- ビデオ会議
- Web ブラウジング
- アダプティブビデオストリーミング
- インスタントメッセージング
- より低いキューイング遅延は、クラウドベースのインタラクティブビデオやクラウドベースの VR/AR のような機能を可能にする
- L4S のデモでは、40Mb/s のブロードバンド接続リンクで、複数の遅延感度の高いアプリケーションとダウンロードが同じボトルネックキューを共有する状況でも、クラウドベースのインタラクティブビデオと VR が同時に動作した
- エンドツーエンドの基底遅延 7ms に対し、追加キューイング遅延は約 1ms 水準だった
- 代替 AQM では、ビデオが指ジェスチャーや頭の動きに目に見えて遅れて追従した
- 指のスワイプや頭の動きでビデオをパンする操作は、VoIP よりはるかに厳しい遅延要件を持つ
- インタラクティブな遠隔テレプレゼンスや、機械・産業プロセスのビデオ支援遠隔制御は、極めて低いキューイング遅延なしには信頼しにくい
展開モデルと段階的導入
- L4S AQM は、インターネット全体に展開されなければ効果が出ない構造ではない
- パブリックインターネットのアクセス網は通常、サイトごとにボトルネックが既知の 1 つの論理リンクで発生するよう設計されている
- サイトには家庭、モバイル端末、中小規模のキャンパス・企業ネットワークなどが含まれる
- xDSL、ケーブル、PON、セルラー、無線、衛星など、さまざまなアクセス技術に適用できる一般化である
- 下り方向では、ボトルネックリンク入口に L4S AQM を展開すれば大半の利点が得られ、上り方向でも上りリンク入口に展開すれば同様に適用できる
- L4S フロー 1 本が利点を得るには、通常 3 つの要素が必要である
- 送信側の輻輳制御
- ボトルネックの AQM
- TCP のような古いトランスポートでは、アップグレードされた受信側フィードバック
- 展開順序はさまざまでありうる
- 既存の DCTCP を制御された試験環境で活用できる
- TCP Prague と AccECN を展開すれば、パブリックインターネット環境で L4S を利用できる
- QUIC は当初から L4S に必要な ECN フィードバックをサポートしているため、送信側 Prague 輻輳制御の展開が容易である
リンク技術ごとの制約
- Wi-Fi、PON、ケーブルは複数パケットのデータをバーストとして集約し、バースト生成中に入ってくるパケットをバッファリングする
- Ethernet と DSL はこのようなパケット集約を行わない
- この集約用バッファリングは送信側では減らせないため、AQM が制御するキューとして数えるべきではない
- セルラー、Wi-Fi、衛星のような無線リンクは容量が急速かつ大きく変動しうるため、急な容量増加を活用するための常駐キューが望ましいと考えられている
- セルラーネットワークは、ハンドオーバーを目立たなくするためのバッファリング要件もあり、さらに複雑である
- L4S は、こうしたすべてのバッファリング要件を取り除けるわけではない
- Classic 輻輳制御の大きなノコギリ波のためのバッファリングという「最も長い棒」を取り除けば、パケット集約バーストサイズや MAC スケジューリング間隔といった他のバッファリング要因もさらに減らす動機が生まれる
非 L4S ボトルネックと損失処理
- L4S が 2 ホスト間で有効化されていても、ボトルネックが ECN をサポートしなければ、L4S 送信側はドロップに対して Reno と安全に共存しなければならない
- このルールは Classic トラフィックを保護するが、損失があると L4S サービスを劣化させる
- 浅いキューのバーストによる一時的なボトルネック損失
- 電気的干渉のような伝送エラー
- 速度ポリシング
- これに対処する 3 つのアプローチは現在研究領域である
- Prague 輻輳制御で、輻輳が原因である可能性の低い一部損失を無視する
- RACK、L4S、並べ替えのないリンク再送を組み合わせて伝送エラーを回復する
- ハイブリッド ECN/drop 速度ポリサー
- 有線網のようにこれらの問題が少ない展開シナリオは、こうした研究と並行して進められる
セキュリティとトラフィックポリシング
- 現在のインターネットでは通常、サイト間共有リンク容量の分離はスケジューラで処理され、個々のアプリケーションフロー速度を普遍的にポリシングしてはいない
- L4S はこの状態を壊さないよう設計されている
- DualQ は、単一キュー AQM より無応答フローに大きな速度優位を与えないよう設計されている
- フロー単位の速度ポリシングが必要なら、L4S/Classic の区別と独立に追加できる
- L4S は、Classic トラフィックの遅延や速度を損なわずに遅延を減らすよう設計されているため、Classic 保護だけを目的に L4S サービスへのアクセスを速度ポリシングする必要はない
- 一部の運用者は、プレミアム顧客のような限定された集団にのみ L4S サービスを提供するかもしれない
- この場合、ECN フィールドだけでなく送信元アドレス範囲のようなローカル識別子も併用できる
- ローカル識別子が一致しなければ、ECT(1) があっても Classic キューへ送れる
- L4S サービスでは、速度だけでなくバースト性の自制も必要である
- DOCSIS 向け低遅延キュー保護機能は、キューを作るフローを一部 Classic キューへリダイレクトして低遅延を保つ方式である
- 単一キュー保護機能は L4S アーキテクチャの必須要素ではなく、L4S 実験の一部はこうした機能が必要かどうかを確認するものである
トンネルとプライバシー
- L4S AQM は ECN フィールドで輻輳をシグナルするため、トンネル内や下位層で動作する際には、ECN フィールドが層をまたいで標準どおり伝搬される必要がある
- L4S アーキテクチャは、トランスポート層識別子を検査する方式を排除しない
- 例としては、L4S 対応が追加された FQ-CoDel がある
- 中核的な革新であるDualQ AQMは、最外層 IP ヘッダーより深い検査を必要としない
- ユーザーが IPsec や暗号化 VPN トンネルでアプリケーションフロー識別子を暗号化しても、低遅延をあきらめる必要はない
- L4S は広いアプリケーション集合に低遅延を提供できるため、ネットワーク通過中に個々のアプリケーションや詳細クラスを区別する必要性が減る
1件のコメント
Hacker News のコメント
これは本当にすばらしい。先月プラハで開催された IETF 118 でライブデモを見たが、バッファブロートを完全になくしていて、ビデオチャットにはとてもよさそうに見えた。
IP パケットに、バッファが満杯かどうかのような情報を入れるための追加ビットが必要になるようだが、実際に動いていて、「こんなことが可能だとは思わなかった」という感じだった。
時間指定リンクが機能しない人は、1時間21分の地点。追記: 違った。これはハッカソンのまとめで、発表を見つけるのは簡単ではない。
受信者が送信者に輻輳をどう知らせるのか気になって調べたが、思ったより見つけにくかった。要点は https://www.rfc-editor.org/info/rfc3168 に文書化されている。
簡単に言うと、フラグは1つではなく3つほどある。送信者がルーターに ECN 対応可能 であることを知らせるフラグ、ルーターが受信者に輻輳を知らせるフラグ、受信者が ACK パケットを送るときに設定するフラグがある。
送信者は ECT コードポイントで ECN 対応を示し、ECN 対応ルーターはパケットを破棄する代わりに IP ヘッダーに CE コードポイントを設定して転送する。受信者は次の TCP ACK に ECN-Echo を設定し、送信者はパケット損失の場合と同様に輻輳へ反応したうえで、次のパケットの TCP ヘッダーに CWR フラグを設定する。
Bob Briscoe は、この方向の考え方に長く取り組んできた。関連する古典として以下の記事を勧めたい。
http://www.sigcomm.org/sites/default/files/ccr/papers/2007/A...
https://dl.acm.org/doi/pdf/10.1145/1080091.1080124
Comcast のケーブル網でいくつかテストが行われており、以下のスライドが説明している。
https://datatracker.ietf.org/meeting/118/materials/slides-11...
どこへ向かうのかは分からないが、ISP が高速レーンに通行料を取り始めるかもしれない、という気がする。
個人的な意見だが、Comcast で働いている。
L4S についてもっと知りたいなら、understandinglatency.com で今日からウェビナーシリーズが始まる。L4S の著者の一部、Comcast の L4S フィールド試験責任者、批判的な立場の人たちも発表する。
RC カーの映像フィードで実際に使っている短いデモを見つけた: https://www.youtube.com/watch?v=RZmS10djDEg
正しい方向への進展ではあるが、輻輳フィードバックを無視してより大きな帯域幅の取り分だけを望む 悪意ある参加者 が1人でもいると問題が起きる。そうなると他の参加者は譲歩し、不公平な側が欲しいものを手に入れることになる。
善良な参加者は他の参加者がルールを守っているかを知るのが難しく、公平キューイング があると分かって初めて、L4S が公平に処理してくれると信じられる。
この問題は、L4S を fq_codel のような公平キューイングで補完し、輻輳制御が公平キューイングの存在を検知できるようにすれば解決可能だ: https://github.com/muxamilian/fair-queuing-aware-congestion-...
公平キューイングの議論は、より大きな議論の一部だ。公平キューイングがなければ、L4S に関係なく公平性はすでにエンドホストが実装しており、サーバーのようなエンドホストが輻輳への反応を無視して公平な取り分より多く取ることができる。これは L4S が新たに作った問題ではないが、L4S がより大きな取り分を得やすくすると見る向きもある。
公平キューイングの支持者は、ネットワークが公平な共有を保証すべきだと考えているが、彼らが選んだ公平性の尺度に全員が同意しているわけではない。特に L4S の主要な支持者の一人は同意しておらず、ここでリンクされている論文で確認できる: https://news.ycombinator.com/item?id=38598023
ユーザーの立場から実際に何が変わるのか気になる。例えばビデオ通話がよりリアルタイムに近づくのか？ 通常 0.5〜1秒ほど遅延があるので、互いに話すときに途切れや割り込みが多い。他にどんなアプリケーションが大きく良くなるのだろう？
3Mbps 未満のビットレートに合わせるには、品質、ビットレート、CPU 時間、遅延の間で難しいトレードオフが必要になる。一般的なノート PC は CPU が遅いか、6コア CPU があってもバッテリー使用中はクロックを低く維持する。ハードウェアアクセラレーションによる動画エンコードも普及していないため、品質と遅延が犠牲になる。
Wi-Fi も遅延を加える。特にノート PC がバッテリーで動作しているときはそうだ。NAT 処理のため、多くのビデオチャットサービスがクラウドサーバーを中継に使い、遅延を増やしている。
https://hpbn.co/wifi/#measuring-and-optimizing-wifi-performa...
ゲームやビデオ会議のようなインタラクション性の高い機能も、遅延なしではるかに良くなる。Web ページを描画したり、動画をストリーミングしたり、Alexa のような AI アシスタントとのやり取りを処理したりするには、現状では多くの往復が必要なので、ユーザーとデバイスが相互作用するほぼすべてのものが良くなり得る。
本質的に L4S はレイテンシのフィードバックループを短くする技術だ。この動画の後半がかなりうまく説明している: https://youtu.be/tAVwmUG21OY?si=lydbqfNL80Y8Uxvp