概要

vSphere 5.5のESXiでは「輻輳制御アルゴリズム｣として、NewRenoか、CUBICを選択できる。これについて簡単に調べたが、推奨や使い分けについては理解できなかった。

詳細

vSphere 5.5のESXiのTCP/IP構成に、輻輳制御アルゴリズムがある。選択式のパラメータで、選択肢は以下の二つになる。

NewReno（日本語UIでは「新規 Reno」）
CUBIC

デフォルト値はNewRenoだったが、推奨や使い分けは不明。

この先を調べる方の、初期調査の省力化に役立つよう、確認範囲について記録しておく。なお、解説やコメントの投稿は全面的に歓迎。誤りの指摘も歓迎だが、投稿者がそれを受けて「正解にたどり着いて修正する」には能力が不足しているかもしれない。

vSphere 5.5ドキュメントでの記述

vSphere 5.5のドキュメントでの記述を確認した。

「vSphereのインストールとセットアップ Update 2 vSphere 5.5」には輻輳制御についての記述なし。
「vCenterServerおよびホスト管理 Update2 ESXi 5.5 vCenter Server 5.5」には輻輳制御についての記述なし。
「vSphereネットワーク Update 2 vSphere 5.5」では、4章「VMkernelネットワークの設定」で輻輳制御アルゴリズムの選択内容表示(P.69)および選択変更方法(P.70)について触れている。ただし選択肢やその内容には触れていない。

他にvSphere API Documentの「HostNetStackInstanceCongestionControlAlgorithmType」で、ここに（API経由で）指定できる値を以下のように説明している。

cubic - Cubic Algorithm. See http://tools.ietf.org/id/draft-rhee-tcp-cubic-00.txt for detail.
newreno - New Reno Algorithm. See http://tools.ietf.org/html/rfc3782 for detail.

NewRenoとCUBIC

以下はTCP/IPをまったく理解していない本投稿者による、現時点での解釈ないし判断になる。調査の材料にはなるかもしれないが、判断の根拠にしないこと。

NewRenoとその前身であるRenoについては「TCP各バージョンの輻輳制御の観察」を参考にした。どちらもパケットの喪失（ロス）を観測して、喪失が発生していれば転送量を下げて、ネットワークの混雑緩和を図る。80年代からの方式が、改良、改善を加えられてきた、よく枯れた役立つアルゴリズムになる。

CUBICのNewRenoに対する比較については、FastSoft（2012年にAkamaiが買収）のペーパー「TCPの進化とその比較どのTCPが今日のインターネットの要求に合うのか？を参考にした。以下、引用するが、おおむね上記IETFのCUBICについてのメモのIntroductionでの指摘とも内容合致していると思う。

TCP Renoは、エンド-トゥ-エンドのボトルネック容量が大きい、転送距離が長い、パケットロスが多い場合にうまく動作しません。これはこの様な環境では、TCP Reno は利用可能な帯域を探り当てることが下手で、パケットロス発生時には極端に反応してしまいます。また、ランダムなロス（ワイヤレスコネクションのドロップの様な場合）と輻輳によるロスを区別することができません。

この問題に対応するため、Windows Vista は、複合 TCP（CTCP）と呼ばれる新たな TCPの派生品を配備しました。一方 Linux2.6 カーネルは CUBIC と呼ばれる他の派生品を使っています。CUBIC はロスベースですが、“長距離・広帯域”ネットワークで Reno よりもさらにアグレッシブに動作します。

vSphere 5.5での設定

以下はTCP/IPをまったく理解していない本投稿者による、現時点での解釈ないし判断になる。調査の材料にはなるかもしれないが、判断の根拠にしないこと。

現時点で、ESXiでの輻輳制御アルゴリズム選択としては、デフォルト設定となっている「NewReno」で大過ないと思われる。

背景を推測すれば、VMware社はvSphere 5.5で長距離vMotionを実用化しよう（した）としており、災害対策ソリューション（SRM:Site Recovery Manager）の一部として遠距離でのソフトウェアレプリケーションにも力を入れてきている。こうしたケースで「“長距離・広帯域”ネットワーク」に向いたCUBICを選択できるようにしてきたのかもしれない。