「2024-05-28 IIJ セミナー L4S で低遅延インターネットは実現できるか?」の版間の差分

提供: hkatou_Lab
ナビゲーションに移動 検索に移動
(ページの作成:「[https://iijlab-seminars.connpass.com/event/317535/ L4Sで低遅延インターネットは実現できるか?] に行ってきました。 = L4S : Low Latency , Low…」)
 
11行目: 11行目:
  
 
=== 目的 ===
 
=== 目的 ===
低遅延にする !
+
バッファリングさせずに、1ms 以下の低遅延にする !
  
 
* DCTCP を L4S にアレンジして広域のインターネットでも適用
 
* DCTCP を L4S にアレンジして広域のインターネットでも適用
  
 
=== 動作 ===
 
=== 動作 ===
ECN を送信側で制御するのが今までと異なる。
+
TCP のノコギリ型になるスループットをなるべく平滑化する。
 +
 
 +
ECN を輻輳信号から即時信号に変えて、送信側で制御するのが今までのフロー コントロールと異なる。
 +
 
 +
* 輻輳してない場合は Marking , 輻輳する場合に no marking する
 +
* 受信側も Accurate ECN でフィードバックする
  
 
現状の TCP との互換性を保持するため、検証に難航している。
 
現状の TCP との互換性を保持するため、検証に難航している。
 +
 +
* キューを分離する
 +
 +
キューにパケットを貯めない。
  
 
== Scalable Congestion Control ==
 
== Scalable Congestion Control ==
30行目: 39行目:
 
100Mbps 時代は良かったが、10G 以降は Recovery Time が長すぎる。
 
100Mbps 時代は良かったが、10G 以降は Recovery Time が長すぎる。
  
== Acronyms ==
+
== Accurate ECN フィードバック ==
 +
コネクション確立時に accECN を使うかネゴシエーションする。
 +
 
 +
IP ヘッダーの 2 ビット ECN フィールドで、01 が立っていると L4S を示す。
 +
 
 +
== Dual Queue Coupled AQM ==
 +
L4S を実現する最小限の機能を定義。
 +
 
 +
RFC9332 にアルゴリズムが載っており、マーキングの確率を L4S Queue と Classic Queue で同等になるように調整する。
 +
 
 +
* りろんはあってる
 +
 
 +
== 現状の実装 ==
 +
スイッチやルータなどのハードウェアに実装されているか ?
 +
 
 +
サーバなどのソフトウェアの実装のみか ?
 +
 
 +
== 略語 : Acronyms ==
 +
 
 +
=== 輻輳制御 ===
 
RED : Random Early Detection
 
RED : Random Early Detection
  
36行目: 64行目:
  
 
ECN : Explicit Congestion Notification
 
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
 +
 +
[[カテゴリ:イベント]]

2024年5月28日 (火) 18:51時点における版

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