概要
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を選択できるようにしてきたのかもしれない。