# TIMELY: RTT-based Congestion Control for the Datacenter
Navigation: [[データセンター輻輳制御]] | [[TCP輻輳制御アルゴリズム]] | [[RDMA]] | [[Google]]
> [!abstract]
> データセンタートランスポートは低レイテンシメッセージングと高スループットの両立を目指す。本論文では、ホストでのラウンドトリップタイムとして測定される単純なパケット遅延が、スイッチフィードバックを必要とせずとも有効な輻輳シグナルであることを示す。まず、NIC ハードウェアの進歩によりマイクロ秒精度の RTT 測定が可能になったこと、そしてこれらの RTT がスイッチのキューイングを推定するのに十分であることを示す。次に、TIMELY が RTT 勾配を用いて送信レートを調整し、高帯域幅を提供しながらパケットレイテンシを低く保つ方法を説明する。OS-bypass 機能を持つ NIC 上で動作するホストソフトウェアに我々の設計を実装した。数百台の機械を用いた Clos ネットワークトポロジでの実験により、優れた性能が得られることを示す。すなわち、PFC を用いるファブリック上での OS-bypass メッセージングに対して TIMELY を有効化すると、99 パーセンタイル尾部レイテンシがラインレートに近いスループットを維持しながら 9 倍低下する。我々のシステムはまた、最適化されたカーネルで動作する DCTCP よりも優れており、尾部レイテンシを 13 倍削減する。我々の知る限り、TIMELY はデータセンターで使用される初の遅延ベース輻輳制御プロトコルであり、(NIC オフロードによる)従来の Vegas のような遅延ベース方式より一桁少ない RTT シグナルしか持たないにもかかわらずこの結果を達成する。
## 論文情報
| 項目 | 内容 |
|---|---|
| 著者 | [[Radhika Mittal]](UC Berkeley 在籍時に Google で研究), [[Vinh The Lam]], [[Nandita Dukkipati]], [[Emily Blem]], [[Hassan Wassel]], [[Monia Ghobadi]](現 Microsoft、Google で研究時), [[Amin Vahdat]], [[Yaogong Wang]], [[David Wetherall]], [[David Zats]] |
| 所属 | [[Google]], Inc.(第一著者 Radhika Mittal は [[UC Berkeley]] 在籍中に Google で本研究を実施) |
| 発表 | SIGCOMM '15, 2015-08-17〜21, London, United Kingdom |
| DOI | 10.1145/2785956.2787510 |
| 発表日 | 2015-08-17 |
| 分野 | ネットワーキング / データセンター / 輻輳制御 / RDMA |
## 概要
TIMELY(Transport Informed by MEasurement of LatencY)は、Google が開発した RTT ベースの輻輳制御スキームである。ECN や QCN のようなスイッチ側のフィードバックを一切必要とせず、ホスト NIC が計測する精密な RTT のみで輻輳を検知する。データセンターの RTT はマイクロ秒精度が要求されるため長らく実用不可能とされてきたが、近年の NIC がハードウェアタイムスタンプとハードウェア ACK 生成をサポートすることで実現可能になったと論じる。核心のアイデアは、RTT の絶対値でなく RTT 勾配(時間微分)を用いて輻輳の立ち上がり・立ち下がりを検知することであり、これにより標準的な「目標キュー長」方式よりも低レイテンシと高スループットを両立できる。RDMA(OS-bypass メッセージング)実装として評価され、PFC を用いる従来ファブリックに対して 99 パーセンタイル尾部レイテンシを 9 倍、最適化済みカーネル DCTCP に対して 13 倍改善する。
## 問題設定
データセンターネットワークは、密結合な計算タスクが多数のバックエンドサーバー間でメッセージをやり取りし、ユーザーリクエスト全体を 100 ms 以内に完了させる必要がある(Dean & Barroso のテールアットスケール問題[21])。このためデータセンタートランスポートは高帯域幅(Gbps)と低レイテンシ(msec)の同時達成を要求されるが、両者はしばしばトレードオフの関係にある。
既存のデータセンタートランスポート(DCTCP・HULL・pFabric・Fastpass 等)はスイッチからの明示的シグナル(ECN 等)に依存する。本論文はこれと対照的に、追加のスイッチサポートを一切要求しない、シンプルかつ即時展開可能な設計を模索する。理想的な輻輳シグナルの条件として、著者らは (1) きめ細かくタイムリーであること、(2) 複数トラフィッククラスを区別できること、(3) 展開が容易であることの 3 点を挙げる。
## 提案手法
### RTT が優れた輻輳シグナルである理由(§2 の実験的裏付け)
**多ビット信号**: ECN マークは 1 ビットの二値情報しか運ばないのに対し、RTT は複数スイッチにまたがるエンドツーエンドのキューイング遅延を多ビットで表現する。**Figure 4: ACK 優先制御の概念図**では、逆方向(ACK)輻輳が正方向(データ)輻輳と混同されうる問題への対処法として、ACK を高優先度 QoS キューに振り分けるアイデアを図示している。
![[_attachments/TIMELY---RTT-based-Congestion-Control-for-the-Datacenter/fig04-ack-prioritization-diagram.png]]
(Figure 4. 左: 副次インキャストの ACK が主インキャストのデータと同じキューを共有し遅延する状況。右: ACK を高優先度キューに移すことで、副次インキャストのデータがキュー前方の ACK を追い越せなくなる。Source: Adapted from Figure 4.)
10 Gbps リンクで隣接 2 ホスト間の 16 KB ping-pong メッセージ(無輻輳)を計測すると、NIC ハードウェアタイムスタンプによる RTT の CDF はほぼ直線(低分散)だが、カーネル TCP スタック計測の RTT は大きく変動する。
![[_attachments/TIMELY---RTT-based-Congestion-Control-for-the-Datacenter/fig01-nic-vs-kernel-rtt-cdf.png]]
(Figure 1. NIC ハードウェアタイムスタンプで測定した RTT はほぼ直線状の CDF(低分散)を示すのに対し、カーネル TCP スタックで測定した RTT はより大きく変動する。Source: Adapted from Figure 1.)
100 フローのインキャスト実験(10 クライアント→1 サーバー、10 Gbps ボトルネック)で、エンドシステム計測 RTT のCDFと、スイッチで直接計測したキュー占有量(時間換算)の CDF はほぼ完全に一致する。
![[_attachments/TIMELY---RTT-based-Congestion-Control-for-the-Datacenter/fig02-rtt-vs-queue-occupancy-cdf.png]]
(Figure 2. エンドシステムで計測した RTT の CDF(Measured RTT)と、スイッチで直接計測したキュー占有量を時間換算した CDF(Queue Length)がほぼ完全に一致する。Source: Adapted from Figure 2.)
対照的に、ECN マークの割合と RTT の相関は弱い。80 KB の ECN マーキング閾値を持つスイッチで、ロングフロー TCP インキャスト実験を行い、RTT ラウンドごとの ECN マーク割合を散布図・箱ひげ図で示すと、両者の相関は弱いことが分かる(64 KB セグメンテーションオフロードによりバースト内のマークがほぼ全て閾値の上か下に偏るため)。
![[_attachments/TIMELY---RTT-based-Congestion-Control-for-the-Datacenter/fig03-ecn-fraction-vs-rtt.png]]
(Figure 3. ECN マーク割合と RTT の散布図(上)と箱ひげ図(下)。RTT レンジ間で ECN マーク割合のばらつきが大きく、弱い相関しか見られない。Source: Adapted from Figure 3.)
**RTT の限界と対処**: RTT は往復両方向のキューイングを合算するため、逆方向(ACK パス)輻輳と順方向(データパス)輻輳を混同しうる。著者らは ACK を高優先度 QoS キューに振り分ける「ACK 優先制御」で対処する。主インキャスト・副次インキャストを用いた実験(Figure 4 の構成)で、ACK 優先制御を適用すると、逆方向輻輳がある場合でも RTT 計測値は逆方向輻輳が全くない場合と区別できないほど一致することを示した。
![[_attachments/TIMELY---RTT-based-Congestion-Control-for-the-Datacenter/fig05-ack-prioritization-rtt-cdf.png]]
(Figure 5. 逆方向輻輳存在下での主インキャストの RTT 分布。ACK 優先制御を適用すると(黒線)、逆方向輻輳が全く無い場合(青線)とほぼ一致する。ACK 優先制御なしで逆方向輻輳がある場合(紫線)はテールレイテンシが著しく悪化する。Source: Adapted from Figure 5.)
### TIMELY のアーキテクチャ(§3)
TIMELY は転送プロトコルの信頼性機構から独立したレート制御フレームワークであり、フローごとに独立したインスタンスとして動作する。3 つのコンポーネントで構成される。
![[_attachments/TIMELY---RTT-based-Congestion-Control-for-the-Datacenter/fig06-timely-overview.png]]
(Figure 6. TIMELY 全体構成。RTT Measurement Engine がタイムスタンプから RTT シグナルを算出し、Rate Computation Engine が許容レートを計算、Pacing Engine がデータをペーシングして送出する。Source: Adapted from Figure 6.)
**① RTT 測定エンジン**: セグメント(最大 64 KB のパケットバースト)単位で ACK による完了イベントを検出し、送信時刻 `t_send` と完了時刻 `t_completion` から RTT を算出する。
```
RTT = t_completion − t_send − (seg. size / NIC line rate)
```
![[_attachments/TIMELY---RTT-based-Congestion-Control-for-the-Datacenter/fig07-rtt-from-completion-time.png]]
(Figure 7. 完了時刻から RTT を求める図。シリアライゼーション遅延を差し引いた残りが伝搬遅延とキューイング遅延の和(RTT)となる。Source: Adapted from Figure 7.)
RTT からセグメントサイズ由来のシリアライゼーション遅延をあらかじめ差し引くことで、TIMELY のレート計算に入力される RTT はセグメントサイズに依存しない。10 Gbps ネットワークでは 64 KB のシリアライゼーションに 51 µs、伝搬遅延は 10〜100 µs、1500 B のキューイングは 1.2 µs 程度である。精密な測定には 2 種類の NIC サポートが必要となる。(a) ACK タイムスタンプ: OS タイムスタンプはスケジューリング・割り込みの影響を受けるため、NIC が完了タイムスタンプを供給する必要がある。(b) 即時 ACK 生成: 受信者側の処理遅延(ターンアラウンド時間)を無視できるよう、NIC ベースの ACK 生成を要求する。
**② レート計算エンジン**: 完了イベントごとに RTT を受け取り、輻輳制御アルゴリズム(後述)を実行して目標送信レートを更新する。パケット単位の動作要求はなく、通常は最大 64 KB のセグメントごとに 1 回の完了イベントを想定する。
**③ レート制御エンジン**: メッセージをセグメントに分割し、単一のスケジューラでフロー横断的にペーシング遅延を計算する。TIMELY はウィンドウベースではなくレートベースである。データセンターの帯域遅延積は少数のパケットバースト分しかない(例: 10 Gbps で 51 µs は 64 KB メッセージ 1 個分)ため、ウィンドウでは細粒度制御が困難であり、バースト間のギャップを直接指定するレート制御の方が適している。
### TIMELY 輻輳制御アルゴリズム(§4)
**評価指標と設計方針**: 主要指標は尾部(99 パーセンタイル)RTT と集約スループット。スループットと RTT がトレードオフになる場合、TIMELY は RTT を低く保つことを優先する(帯域幅は潤沢にある一方、RTT 増大は短い RPC の完了時間に直結するため)。副次指標は公平性と損失であり、安定した設計(振動しない設計)を平均レートより優先する。
**遅延勾配アプローチ**: TCP Vegas・FAST TCP・Compound TCP のような従来の遅延ベース方式は RTT がベースラインを超えたことを輻輳の指標とし、ボトルネックキューを固定の閾値付近に維持しようとする。しかし Kelly ら[33]は、制御ループ遅延よりも短い時間スケールのキューは制御不能であると指摘する。データセンターでは 10 Gbps 上の 64 KB メッセージの制御ループ遅延は最低 51 µs である一方、1 パケット分のキューイングは 1 µs 程度に過ぎず、この条件に該当する。TIMELY はキューを目標値に維持しようとする代わりに、**キューイング遅延の時間に対する勾配(delay gradient)** に反応することで低レイテンシを達成する。RTT 増加による正の勾配はキューの増大を、負の勾配はキューの減少を示す。
N ホストが総レート y(t) でドレインレート C のボトルネックキューへ送信するモデルを仮定すると、キューイング遅延勾配は `dq(t)/dt = (y(t) − C) / C` と表され、これはそのまま RTT の勾配 `d(RTT)/dt` に一致する。TIMELY は各コネクションのレート R(t) をこの誤差信号に基づいて調整することで、集約到着レート y(t) をドレインレート C に一致させようとする。
**Algorithm 1(疑似コード)**:
```
Data: new_rtt
Result: Enforced rate
new_rtt_diff = new_rtt - prev_rtt
prev_rtt = new_rtt
rtt_diff = (1 - α) · rtt_diff + α · new_rtt_diff # α: EWMA重み
normalized_gradient = rtt_diff / minRTT
if new_rtt < T_low:
rate ← rate + δ # δ: 加算増分ステップ
return
if new_rtt > T_high:
rate ← rate · (1 - β · (1 - T_high / new_rtt)) # β: 乗算減少係数
return
if normalized_gradient ≤ 0:
rate ← rate + N · δ # N=5(勾配が5完了イベント連続で負のときHAIモード)、それ以外N=1
else:
rate ← rate · (1 - β · normalized_gradient)
```
RTT 差分を最小 RTT で正規化して無次元量とし、EWMA フィルタで平滑化することで、輻輳を示さない微小なキュー変動を無視しながら全体的なキュー増減トレンドを検知する。勾配がゼロ以下なら加算増分でレートを上げ、正であれば勾配の大きさに比例した乗算減少 `R = R × (1 − β × d(RTT)/dt)` を行う。この遅延勾配シグナルは同一輻輳経路上の全コネクションに共通であり、AIMD の性質から公平性が保証される[19]。
**T_low(低閾値)の必要性**: 現実の実装では 64 KB もの大きなセグメント単位でレートが適用されるため、パケットバーストが一時的なキューと RTT スパイクを生む。T_low はこの一時的スパイクをフィルタし、勾配ベースの調整は T_low を超えた RTT サンプルにのみ発動する。
![[_attachments/TIMELY---RTT-based-Congestion-Control-for-the-Datacenter/fig08-gradient-tracking-zone.png]]
(Figure 8. 勾配追跡ゾーンと低高閾値の関係。RTT が 0〜T_low の範囲では加算増加のみ、T_low〜T_high の範囲では勾配に基づく増加/減少、T_high を超えると乗算減少のみが働く。Source: Adapted from Figure 8.)
**T_high(高閾値)の必要性**: 理論上、勾配がゼロのままキューが高い一定水準に留まる可能性がある(標準キュー方式の弱点)。T_high は許容できるエンドツーエンドキュー遅延(尾部レイテンシ)の上限を与え、`R = R × (1 − β × (1 − T_high/RTT))` により勾配に依らず即座にレートを削減する。平滑化した RTT ではなく瞬間 RTT を用いることで、単発の大きな RTT にも即座に反応する。
**Hyperactive Increase(HAI)**: TCP BIC/CUBIC・QCN の最大探索フェーズに着想を得た機構。勾配が複数完了イベント連続で負(緩やかな増加が続く)場合、加算増分を `δ` から `N·δ` に切り替えて収束を高速化する。
**勾配 vs キューサイズアプローチの比較(§4.4)**: T_low = T_high(単一閾値 T_target)とすると、TIMELY は標準的なキューサイズベース方式(TCP FAST に類似)に帰着する。50 µs/500 µs の低高閾値を用いた勾配方式と、同値の T_target を用いたキューサイズ方式をインキャストトラフィックで比較すると、キューサイズ方式は低レイテンシか高スループットのどちらかしか達成できないのに対し、勾配方式はキューの立ち上がり・立ち下がりを予測することで高スループットと低尾部レイテンシを両立できる。
![[_attachments/TIMELY---RTT-based-Congestion-Control-for-the-Datacenter/fig09-gradient-vs-target-based-cdf-throughput.png]]
(Figure 9. 勾配アプローチ(低高閾値 50µs/500µs)とターゲットベースアプローチ(T_target = 50µs, 500µs)の RTT CDF(上)とスループット時系列(下)比較。ターゲットベースは低レイテンシか高スループットの一方しか達成できない。Source: Adapted from Figure 9.)
また、キューサイズ方式はレートを目標キュー長へ向けて上下させるため振動が大きいのに対し、勾配方式は公平配分付近で滑らかに安定する。
![[_attachments/TIMELY---RTT-based-Congestion-Control-for-the-Datacenter/fig10-per-connection-rate-smoothness.png]]
(Figure 10. コネクション単位のレート時系列。勾配アプローチ(上)は公平配分(500 Mbps)付近で滑らかに安定するのに対し、キューサイズアプローチ(下、T_target=50µs)はより振動的。Source: Adapted from Figure 10.)
## 実装(§5)
10 Gbps・OS-bypass 対応 NIC 上に、RDMA(Remote Direct Memory Access)の文脈で実装された。RDMA Write/Read を用いてローカルホストメモリから NIC へメッセージ転送をオフロードする。輻輳制御部分のみを扱い、信頼性やトランスポートインターフェースには関与しない設計とすることで、メッセージ送受信という単純なインターフェースを維持し、RPC からバイトストリーム(TCP 相当)まで幅広いトランスポートに適用可能とする。
**NIC タイムスタンプの実用上の課題**: 使用した NIC は多重パケット操作完了時の絶対タイムスタンプのみを記録するため、ホストソフトウェア側で送信時刻を記録し、ホストクロックと NIC クロックのキャリブレーション(単純な線形マッピング)で補完する。ソフトウェアのみのタイムスタンプ(interrupt・wakeup 込み)、キャリブレーション補完機構、直接ハードウェアタイムスタンプの精度を比較すると、キャリブレーション機構は直接ハードウェアタイムスタンプとほぼ同等の精度を達成する。
![[_attachments/TIMELY---RTT-based-Congestion-Control-for-the-Datacenter/fig11-nic-vs-sw-timestamp-accuracy.png]]
(Figure 11. ソフトウェアのみのタイムスタンプ(Software)、キャリブレーション補完機構(Approximated Hardware)、直接ハードウェアタイムスタンプ(Direct Hardware)の RTT 精度比較。Approximated Hardware は Direct Hardware とほぼ同等の精度。Source: Adapted from Figure 11.)
NIC 内でのキューイングも RTT シグナルの一部として扱われる。これはネットワークキューイングと同様に輻輳を示唆し、同じレートベース制御で扱われるべきだからである。
**RDMA レート制御**: RDMA Write では送信者が直接セグメントペーシングレートを制御する。RDMA Read では受信者が読み取り要求を発行するため、TIMELY はデータセグメントを直接ペーシングできず、代わりに読み取り要求そのものをペーシングすることで同等の効果を得る。
**アプリケーション制限動作**: フローが目標レートに達するだけのデータを持たない場合、無制限にレートを上げないよう、アプリケーションが目標レートの 80% 以上で送信しているときのみ目標レートの増加を許可し、最大目標レートを 10 Gbps に制限する。
**レート更新頻度**: 最小 RTT 内に複数の完了イベントが発生しうる小セグメントサイズでは、完了ごとにレートを更新しつつ、最小 RTT 内の完了数でスケーリングして過剰反応を防ぐ。スケジューラは送信時刻経過時にレートが下がっていれば再スケジューリングする遅延更新方式を採る。
**追加のペーシング機会**: NIC ハードウェアレートリミッタでラインレート未満のバーストペーシングを行うハイブリッド方式(ソフトウェアによる大セグメントペーシング + ハードウェアによる固定レートペーシング)も検討し、複数バーストがスイッチで混ざりやすくなることでレイテンシスパイクを抑制する。
## 新規性
TIMELY は「遅延はデータセンターで信頼できない輻輳シグナル」という通説を覆す。既存のスイッチサポート型スキーム(DCTCP・QCN・pFabric 等)とは異なり、スイッチ変更を一切要求しない。また TCP Vegas・FAST・Compound のようなウィンドウベースの遅延ベース方式とも異なり、TIMELY はレートベースで、かつ最小 RTT の絶対測定に依存せず勾配のみを用いる点、NIC オフロードによる希薄な RTT シグナル下でも機能する点が新規性である。同時期に独立して提案された DX[17]は DPDK と Linux TCP スタック内で類似の着想を実装するが、加算増加・平均キューイング遅延に比例した乗算減少という従来型の窓ベース制御則を用いる点で TIMELY と異なる。CAIA Delay Gradient(CDG)[25]は広域網 TCP 向けの遅延勾配アルゴリズムだが、ロスベース輻輳制御との共存が主目標であり、TIMELY とは狙いが異なる。
## 実験設定
評価は小規模実験(ラック規模)と大規模実験(数百台、Clos トポロジ)の 2 段階。すべてのリンクは特記なき限り 10 Gbps、OS は Linux。比較対象は以下の 4 構成。
| 略称 | 内容 |
|---|---|
| DCTCP | 最適化カーネルで動作する DCTCP(PFC なしファブリック) |
| PFC | OS-bypass メッセージング + 従来型 RDMA(PFC ありファブリック、TIMELY なし) |
| FAST* | OS-bypass メッセージング + TCP FAST 類似輻輳制御アルゴリズム |
| TIMELY | OS-bypass メッセージング + TIMELY(PFC ありファブリック) |
既定パラメータ: セグメントサイズ 16 KB、T_low = 50 µs、T_high = 500 µs、加算増分 10 Mbps、乗算減少係数 β = 0.8。
## 実験結果
### RTT 測定精度の要求(§6.1)
RTT サンプルにノイズ [0, x] µs(x = 0, 50, 100, 150, 200)を加えて総スループットへの影響を測定すると、平均ノイズ 50 µs から可視的なスループット低下が現れ、ノイズが増えるほど劣化が深刻化する。
![[_attachments/TIMELY---RTT-based-Congestion-Control-for-the-Datacenter/fig12-rtt-noise-impact-on-throughput.png]]
(Figure 12. RTT ノイズがサーバー計測総スループットに与える影響。平均ノイズ 50 µs から可視的な劣化が生じる。ソフトウェアタイムスタンプ由来のノイズはこの水準に容易に達しうるため、NIC ハードウェアによる精密な RTT 計測が TIMELY の要石であると論じる。Source: Adapted from Figure 12.)
### PFC・DCTCP・FAST* との比較(Table 1)
| Metric | DCTCP | FAST* 10M | FAST* 50M | FAST* 100M | PFC | TIMELY |
|---|---|---|---|---|---|---|
| Total Throughput (Gbps) | 19.5 | 7.5 | 12.5 | 17.5 | 19.5 | 19.4 |
| Avg. RTT (µs) | 598 | 19 | 120 | 354 | 658 | 61 |
| 99-percentile RTT (µs) | 1490 | 49 | 280 | 460 | 1036 | 116 |
(Table 1. 総合性能比較。FAST* はネットワークバッファトラフィックパラメータ α を 10/50/100 Mbps に設定した 3 通りを併記。)
TIMELY は PFC 比で平均 RTT を 10 倍以上、99 パーセンタイル RTT を 9 倍(1036 → 116 µs)低下させ、パウズフレームも発生しない。DCTCP 比では平均 RTT を約 10 倍(598 → 61 µs)、尾部レイテンシを 13 倍(1490 → 116 µs)低下させる。TIMELY の Jain 公平性指数は 0.953(PFC は 0.909)。個々のコネクションについても、Figure 13 は 4 コネクションの RTT・レートの時系列を示し、いずれも公平配分 500 Mbps 付近で低い RTT を維持することを示す。
![[_attachments/TIMELY---RTT-based-Congestion-Control-for-the-Datacenter/fig13a-per-connection-rtt-timeline.png]]
(Figure 13(上). 4 コネクションの RTT 時系列。凡例の括弧内数値は各コネクションの平均・標準偏差(µs)。Source: Adapted from Figure 13.)
![[_attachments/TIMELY---RTT-based-Congestion-Control-for-the-Datacenter/fig13b-per-connection-rate-timeline.png]]
(Figure 13(下). 同一実験における 4 コネクションの送信レート時系列。いずれも公平配分 500 Mbps 付近に収束する。Source: Adapted from Figure 13.)
![[_attachments/TIMELY---RTT-based-Congestion-Control-for-the-Datacenter/fig14-timely-vs-dctcp-rtt-cdf.png]]
(Figure 14. TIMELY と DCTCP の RTT 分布(CDF)比較。TIMELY は狭い低 RTT 域に集中し、DCTCP は広く高い RTT 域に分布する。Source: Adapted from Figure 14.)
FAST* との比較では、小さい α = 10 Mbps で TIMELY 並みの低尾部レイテンシ(49 µs)を達成するが、スループットが 7.5 Gbps(20 Gbps ラインレート比 37.5%)に大きく低下する。α を大きくしても TIMELY のスループット・レイテンシのトレードオフを上回れない。
### パラメータ感度分析(§6.1 続き)
T_low を下げるとネットワーク遅延は低下するが、セグメントサイズ(バースト性)が大きいほど閾値を下げすぎたときのスループット低下が顕著になる。16 KB セグメントでは T_low = 50 µs が最高スループット(19.4 Gbps)を、32 KB では 100 µs、64 KB では 200〜300 µs 付近が転換点となる。
![[_attachments/TIMELY---RTT-based-Congestion-Control-for-the-Datacenter/fig15-throughput-rtt-vs-tlow-segsize.png]]
(Figure 15. T_low とセグメントサイズ(16/32/64 KB)を変えたときのスループットと RTT。セグメントが大きいほど T_low を下げすぎると急激にスループットが低下する。Source: Adapted from Figure 15.)
NIC ハードウェアペーシングを併用すると、バースト性が緩和されスループットが向上しレイテンシが低下する。64 KB セグメント・T_low=50 µs で最良のペーシングレートは 700 Mbps 付近であり、18.9 Gbps のスループットを達成する(ペーシングなしでは 11.2 Gbps)。
![[_attachments/TIMELY---RTT-based-Congestion-Control-for-the-Datacenter/fig16-throughput-rtt-vs-pacing-rate.png]]
(Figure 16. 64 KB セグメントに対する NIC ペーシングレートを変えたときのスループットと RTT。700 Mbps 付近が最良点で、それを超えると公平配分に近づきスループットが頭打ちになる。Source: Adapted from Figure 16.)
T_high は多重化されたコネクション数が増えるほど効果が顕著になる。10 コネクション/クライアントの負荷では T_high = 500 µs 以上で 99 パーセンタイル RTT が約 500 µs のまま高止まりするが、200 µs 以下に下げると顕著に改善する。スループットは T_high = 100 µs まではほぼ維持されるが、50 µs では大きく低下する。
![[_attachments/TIMELY---RTT-based-Congestion-Control-for-the-Datacenter/fig17-throughput-rtt-vs-thigh.png]]
(Figure 17. T_high と競合コネクション数(4/7/10 セッション)を変えたときのスループットと RTT。T_high を最大 200 µs まで下げてもスループットは低下せず、尾部レイテンシは改善する。Source: Adapted from Figure 17.)
HAI の効果検証として、10 クライアント×10 コネクションのインキャストから 9 コネクションを一斉停止し公平配分を 10 倍に増やす実験を行うと、HAI は初期レート 200 Mbps から 50 ms で 1.5 Gbps、100 ms で新公平配分の 2 Gbps に到達するのに対し、固定加算増分では 140 ms かけても 1.5 Gbps にしか到達しない。
![[_attachments/TIMELY---RTT-based-Congestion-Control-for-the-Datacenter/fig18-hai-convergence.png]]
(Figure 18. HAI あり/なしでのレート収束比較。HAI は急激に増えた公平配分帯域を素早く獲得する。Source: Adapted from Figure 18.)
### 大規模実験(§6.2、数百台・Clos トポロジ)
64 KB RPC・セグメントサイズで、最長経路一様ランダムトラフィックパターンを用いた実験では、TIMELY はキューイングと一時停止フレームを最小化することで、ネットワークの飽和点(受理負荷が提供負荷を下回る点)をより高い提供負荷まで押し上げる。
![[_attachments/TIMELY---RTT-based-Congestion-Control-for-the-Datacenter/fig19-accepted-vs-offered-load.png]]
(Figure 19. 提供負荷に対する受理負荷(正規化)。TIMELY は PFC より高い提供負荷まで受理負荷が伸び続ける。Source: Adapted from Figure 19.)
TIMELY は PFC 比で中央値 RTT を約 2 倍、99 パーセンタイル RTT を約 5 倍削減し、中央値 RPC レイテンシも約 2 倍改善する。
![[_attachments/TIMELY---RTT-based-Congestion-Control-for-the-Datacenter/fig20-median-99pct-rtt-vs-load.png]]
(Figure 20. Pinger による中央値 RTT(上)・99 パーセンタイル RTT(下)の提供負荷依存性。TIMELY(緑破線)は PFC(赤実線)より一貫して低い。Source: Adapted from Figure 20.)
![[_attachments/TIMELY---RTT-based-Congestion-Control-for-the-Datacenter/fig21-median-99pct-rpc-latency.png]]
(Figure 21. 中央値 RPC レイテンシ(上)・99 パーセンタイル RPC レイテンシ(下)の提供負荷依存性。TIMELY はキューイングをネットワークからエンドホスト側へ移すため、飽和点以降は RPC レイテンシの削減効果が相対的に縮小する。Source: Adapted from Figure 21.)
インキャストによるネットワーク不均衡実験(背景負荷 低/中/高 + 40 対 1 インキャストを追加)では、TIMELY なしの場合スループットが 13%〜54%低下する(PFC のヘッドオブラインブロッキングによる)のに対し、TIMELY は輻輳経路上のフローのみをレート制限することで輻輳拡散を防ぎ、全体スループットをほぼ維持する。
![[_attachments/TIMELY---RTT-based-Congestion-Control-for-the-Datacenter/fig22-incast-throughput-rtt-with-background-load.png]]
(Figure 22. 40 対 1 インキャストパターンを最長経路一様ランダムトラフィックに追加したときの正規化スループット(上)と 99 パーセンタイル RTT(下)。PFC(青)は M-to-1 追加時にスループットが顕著に低下し尾部 RTT が跳ね上がるのに対し、TIMELY(黒)は影響が小さい。Source: Adapted from Figure 22.)
### アプリケーションレベルベンチマーク
データセンターストレージベンチマークにおいて、TIMELY 導入前後でアプリケーションデータユニットのレイテンシ中央値が 8.9 秒から 5.1 秒へ改善した。
![[_attachments/TIMELY---RTT-based-Congestion-Control-for-the-Datacenter/fig23-application-benchmark-timely-onoff.png]]
(Figure 23. アプリケーションレベルベンチマークのレイテンシ推移(対数スケール)。No TIMELY 期間の中央値 8.9 秒に対し、TIMELY 有効化後は 5.1 秒に改善する。この改善はレイテンシ制約を保ちながらより高いスループットでクエリを処理できるようになったことの反映であると著者らは論じる。Source: Adapted from Figure 23.)
## 考察
TIMELY の中心的な主張は「遅延ベース輻輳制御はデータセンターで機能しない」という通説への反証である。近年の NIC のハードウェアタイムスタンプ・ハードウェア ACK 生成という能力進化が、広域網では成立しなかった前提(マイクロ秒精度の正確な RTT 測定)をデータセンターで初めて成立させたことが背景にある。また、RTT 絶対値ではなく勾配を用いることで、Kelly ら[33]が指摘する「制御ループより短い時間スケールのキューは制御できない」という理論的制約を回避しながら低レイテンシと高スループットを両立している点が設計上の要である。実験結果は、単なるベンチマークでの改善だけでなく、実データセンターストレージアプリケーションのレイテンシにも直接反映されており、輻輳シグナルの選択(遅延 vs ECN)がアプリケーション体感性能に直結することを示している。
## 強み / 弱点・課題
**強み**:
- スイッチ変更を一切要求しない、即時展開可能な設計
- RTT 勾配という単純な指標で、標準キューベース方式の理論的限界(Kelly の指摘)を回避し高スループット・低レイテンシを両立
- 数百台規模の Clos トポロジでの実運用に近い評価、本番相当ストレージアプリケーションでの実証
- T_low/T_high・HAI という少数のパラメータで、バースト耐性・尾部レイテンシ対策・高速収束をカバーする実用的な設計
**弱点・課題**:
- 精密な RTT 計測に対応する NIC ハードウェアサポート(タイムスタンプ・ハードウェア ACK)が前提であり、対応 NIC がない環境には適用できない
- RTT ノイズが平均 50 µs を超えると性能劣化が顕在化するため、計測精度への要求が厳しい
- ACK 優先制御は「主に一方向へデータを送るフロー」という一般的なケースで有効だが、双方向対称的な輻輳には追加の対処が必要になりうる(論文では単純な手法で十分としている)
- DCQCN[48]との CPU 使用率も含めた直接比較は将来課題として明示的に残されている
- 論文自身が、データセンター速度が今後一桁上がった場合に RTT ベース輻輳制御がどこまで有効であり続けるかを未解決の将来課題としている
## 関連概念
- [[データセンター輻輳制御]] — DCTCP・DCQCN・QCN との横断比較。TIMELY は遅延ベースという別系統に位置づけられる
- [[TCP輻輳制御アルゴリズム]] — TCP Vegas・FAST・Compound TCP など遅延ベース輻輳制御の系譜
- [[RDMA]] — 本実装が対象とする OS-bypass メッセージング基盤
- [[Google]] — 著者の主要所属
- [[Amin Vahdat]] — 共著者、データセンターネットワークトポロジ研究でも活躍
## 出典
-