# TCP輻輳制御アルゴリズム ## 定義 TCP輻輳制御アルゴリズムは、ネットワークが共有資源であることに起因する輻輳(ルーターやスイッチによるパケットドロップ、レイテンシ増大による再送)を防ぎながらスループットを最大化するために、送信側の輻輳ウィンドウを調整するカーネル内のプラガブルな機構である。Linuxはシステムチューニングの一部としてアルゴリズムを選択できるようにしている。代表的なアルゴリズムには、重複3個のACK検出でウィンドウを半分にするReno、同様の検出で輻輳ウィンドウを最大セグメントサイズ(MSS)1個分まで下げるTahoe(いずれも4.3BSD向けに開発)、ウィンドウのスケーリングに3次関数を使いLinuxのデフォルトになっているCUBIC、ウィンドウベースではなくプロービングフェーズでネットワークパス特性(RTTと帯域幅)の明示的モデルを構築するBBR、キューが非常に浅い段階でECNを生成するよう構成されたスイッチを前提とするDCTCPがある。これ以外にもVegas・New Reno・Hyblaなどのアルゴリズムが存在する。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 10 ネットワーク]] §10.4.1.2.5) ## 横断的知見 - **輻輳制御アルゴリズムの選択が実運用のスループットを数倍単位で左右した実例がある**: Netflixクラウドサービスは、パケットがひどく消失している状況でBBRに切り替えることでスループットを3倍に向上させた。一方でBBRは「一部のネットワークパスでは劇的にパフォーマンスが向上するが、それ以外では逆にパフォーマンスが損なわれる」という両面性を持ち、欠点解消を謳うBBRv2が開発中とされる。アルゴリズム選択が万能でないことと、実運用での定量効果の両方が同じ章で示されている。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 10 ネットワーク]] §10.4.1.2.5) - **DCTCPは一般的なTCP輻輳制御アルゴリズムの選択肢の1つとして紹介される一方、[[データセンター輻輳制御]] ではRDMA/RoCEv2文脈におけるDCQCNとの対比のなかでより深く扱われる**: 本概念が示す「Linuxのプラガブルな輻輳制御アルゴリズムの1つとしてのDCTCP」という一般的TCPスタック視点と、[[データセンター輻輳制御]] が示す「ECN信号を共有しつつウィンドウベース(DCTCP)とレートベース(DCQCN)で反応機構が全く異なる」というRDMA特化視点は、同じDCTCPという技術を異なる粒度で捉えている。一般TCPスタックの文脈では「浅いキューでECNを生成するスイッチが前提」という運用条件だけが述べられ、`cwnd ← cwnd × (1 − α/2)` という具体的な反応式までは踏み込まない。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 10 ネットワーク]] §10.4.1.2.5、[[データセンター輻輳制御]]) ## 未解決の問い - BBRv2は本章執筆時点(原書2020年)で開発中とされているが、v1のどの欠点が解消されたか。CUBICとの比較評価はどの程度蓄積されているか。 - Linux 5.6で導入されたBPFによるカスタム輻輳制御アルゴリズムの開発は、CUBIC/BBR/DCTCPと比べてどの程度の採用実績があるか。 - スロースタート・輻輳回避・高速再送・高速回復という古典的な4フェーズモデルは、BBRのようなモデルベースアルゴリズムにもそのまま適用できる概念か、それとも別の分析軸が必要か。 ## 関連 - [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 10 ネットワーク]] — Reno/Tahoe/CUBIC/BBR/DCTCPのアルゴリズム概説とNetflixのBBR事例(§10.4.1.2.5)。 - [[データセンター輻輳制御]] — DCTCP/DCQCNをRDMA/RoCEv2文脈で深く扱う関連concept。 - [[詳解 システム・パフォーマンス 第2版]] ## 出典 - [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 10 ネットワーク]] §10.4.1.2.5