2024-05-28 IIJ セミナー L4S で低遅延インターネットは実現できるか？
L4Sで低遅延インターネットは実現できるか？ に行ってきました。
L4S : Low Latency , Low Less , and Scalable Throughput
L4S はコミュニティの知見の集大成で、QoS 系の技術を元に検討・実装されてきている。
サマリ
解決するべき課題
Cable / DSL など非対称で上りの速度が限られる回線で、深いキューによる遅延が問題になっている。
目的
バッファリングさせずに、1ms 以下の低遅延にする !
- DCTCP を L4S にアレンジして広域のインターネットでも適用
動作
TCP のノコギリ型になるスループットをなるべく平滑化する。
ECN を輻輳信号から即時信号に変えて、送信側で制御するのが今までのフロー コントロールと異なる。
- 輻輳してない場合は Marking , 輻輳する場合に no marking する
- 受信側も Accurate ECN でフィードバックする
現状の TCP との互換性を保持するため、検証に難航している。
- キューを分離する
キューにパケットを貯めない。
Scalable Congestion Control
輻輳制御が走ったとき、スループットが低下するが、その時の Recovery Time がスループットによらず一定なのが問題になっている。
Reno はスループットが高いとリカバリも高くなり、比例してしまっている。
- スループット 10 倍 = リカバリタイム 10 倍
- Reno : 1990 年に登場した輻輳回避アルゴリズム
100Mbps 時代は良かったが、10G 以降は Recovery Time が長すぎる。
Accurate ECN フィードバック
コネクション確立時に accECN を使うかネゴシエーションする。
IP ヘッダーの 2 ビット ECN フィールドで、01 が立っていると L4S を示す。
Dual Queue Coupled AQM
L4S を実現する最小限の機能を定義。
RFC9332 にアルゴリズムが載っており、マーキングの確率を L4S Queue と Classic Queue で同等になるように調整する。
- りろんはあってる
現状の実装
スイッチやルータなどのハードウェアに実装されているか ?
サーバなどのソフトウェアの実装のみか ?
略語 : Acronyms
輻輳制御
RED : Random Early Detection
DCTCP : Data Center Transport Protocol
ECN : Explicit Congestion Notification
AQM : Active Queue Management
TCP ヘッダ
AE : Accurate ECN
CWR : Congestion Windows Reduced
ECE : Echo of Congestion Encountered
RFC
RFC9330 Informational : L4S : Low Latency , Low Less , and Scalable Throughput (L4S) Internet Service : Architecture
RFC9331
RFC9332
Internet Drafts
More Accurate EECN Feedback in TCP
ECN++ Adding Explicit Congestion Notification (ECN) to TCP COntrol Packets
Non-Queue Building Per-Hop Behavior (NQB PHB) for Differentiated Services
Operational Guidance on Coexistence with Classic ECN During L4S Deployment
ISP Dual Queue Neworking Deployment Recommendations