JP5819530B2 - ネットワーク輻輳を回避するための方法およびその装置 - Google Patents

Description

近年では、データセンタアプリケーションおよびウェブ検索は、一般的に分割／集約（Ｐａｒｔｉｔｉｏｎ／Ａｇｇｒｅｇａｔｅ）通信パターンを示す。最初に、要求が分割され、いくつかのワーカノードに送出される。次いで、ワーカにより生出される応答パケットが、集約のための共通ノード、すなわちアグリゲータノードに送信される。そのようなタイプのトラフィックは、複数のワーカが同時に同じアグリゲータに応答パケットを送出する際に、ネットワーク輻輳を引き起こす場合がある。データセンタネットワーク用のトランスポートプロトコルの設計は、このインキャスト（ｉｎｃａｓｔ）輻輳問題に起因して難題であった。

Ａ．関連研究
ＴＣＰインキャスト問題は、スケーラブルな記憶アーキテクチャの設計においてＤ．Ｎａｇｌｅらにより最初に報告された。Ｄ．Ｎａｇｌｅらは、クライアントと多くの記憶デバイスとの間の同時トラフィックが、記憶デバイスの数が増大する際にネットワークを苦しめることを見出した。このことによって、複数のパケット損失およびタイムアウトがもたらされ、クライアントは、長いＲＴＯ継続期間の間アイドル状態となることを強いられる。インキャスト輻輳を緩和するために、Ｄ．Ｎａｇｌｅらは、クライアントの受信ソケットバッファサイズを６４ｋＢ未満に低減している。Ｄ．Ｎａｇｌｅらはさらに、重複ＡＣＫしきい値を低減しスロースタートを使用不可能にするなどしてＴＣＰレベルを調節して、再送タイムアウトを回避することを提案している。しかしながらＤ．Ｎａｇｌｅらは、根本的なインキャスト問題に対処していない。

インキャスト問題に対処する２つの主な手法が提案されている。第１の手法は、ＲＴＯ_ｍｉｎをミリ秒からマイクロ秒の粒度に低減する。この解決策は、主な性能測定基準がＴＣＰスループットを高めることであるクラスタベースの記憶システムに対しては非常に効果的である。それでも、その解決策は依然として高いキューイング遅延を誘発するので、その解決策は、ウェブ検索などのソフトリアルタイムアプリケーションには適していない。第２の手法は、バッファオーバーフローの前の輻輳回避を用いることである。ＲＴＴは通常、広域ネットワークにおいて良好な輻輳指標であり、したがって、ＴＣＰ Ｖｅｇａｓなどの遅延ベースの輻輳回避アルゴリズムは良好な候補であり得る。しかしながら、データセンタにおいてのＲＴＴのマイクロ秒の粒度は、ネットワーク輻輳を、パケット／転送処理オーバーヘッドにより引き起こされる遅延スパイクと区別するには感度が高すぎる場合があることがよく知られている。したがってＤＣＴＣＰは、明示的輻輳通知（ＥＣＮ）を使用してネットワーク輻輳を明示的に検出し、ＥＣＮマークの数を使用することにより細粒度の輻輳ウィンドウベースの制御を提供する。別の手法はＩＣＴＣＰである。ＩＣＴＣＰは、全体の入トラフィックの帯域幅を測定して、利用可能な帯域幅を取得し、次いで、この情報に基づいて各々の接続の受信ウィンドウを制御する。しかしながらインキャスト輻輳は、これらの手法においてもワーカの数が増大する際には不可避である。

Ｂ．ウィンドウベースの輻輳制御の限界
図１は、インキャスト輻輳が発生する典型的な接続形態を図示する。そのようなインキャスト輻輳を回避するために、未処理のパケットの総数は、帯域幅遅延積（ＢＤＰ）から取得されるネットワークパイプサイズを超過すべきではない。

このことは次式のように表現される。

ただし、ＭＳＳは最大セグメントサイズを表し、ｎは同時接続の総数であり、ｗ_ｉは第ｉの接続のウィンドウサイズである。この場合ではＢＤＰは、データセンタネットワークにおいてきわめて小さい場合がある。例えば、ネットワーク経路が１Ｇｂｐｓのリンク容量（ｌｉｎｋ ｃａｐａｃｉｔｙ）および１００ｕｓの遅延を有するならば、ＢＤＰは、おおよそ１２．５ｋＢとなり、または、ＭＳＳが１．５ｋＢであるとき８．３ＭＳＳとなる。このことは、

が、パイプオーバーフローを回避するために８．３より小さくあるべきであることを示唆する。この場合では、経路が維持することが可能であるＴＣＰ接続の数は、最小限のウィンドウサイズが１であるならば多くても８となる。換言すれば、９を超えるＴＣＰ接続は、すべての送出器が少なくとも１つのパケットを一斉に送信するならば、キューイング遅延およびパケット損失を引き起こす場合がある。この理由で、既存のウィンドウベースの制御体系は基本的には、いくつかのワーカを利用する典型的なデータセンタネットワークアプリケーションにおいてスケーラブルではない。この洞察が、データセンタ環境に対するＢＤＰ測定に基づくレートベースの制御手法に結び付く。

ＴＣＰが前のインキャスト通信パターンのもとで良好に作動しないいくつかの理由が存在する。第１に、トップオブラック（ＴｏＲ）スイッチは典型的には、コストを削減するために小さなバッファメモリ（例えば、５２個のポートに対して４ＭＢの共有メモリ）を使用し、このことが頻繁なバッファオーバーフロー、すなわちパケット損失を招く。第２に、多少のパケット損失であっても、フロー内の応答パケットの数は通常、高速再送および回復が行われるには小さすぎるので、結果としてＴＣＰタイムアウトになる場合がある。さらに汎用オペレーティングシステムにおいて、最小再送タイムアウト（ＲＴＯ_ｍｉｎ）が一般的には２００ｍｓまたは３００ｍｓのいずれかに設定され、一方で、データセンタネットワークにおいてのラウンドトリップ時間（ＲＴＴ）は２５０ｕｓより小さい場合がある。この場合では、パケット損失を検出するのに８００ＲＴＴより多くかかることになる。最後に、分割／集約パターンにおいてアグリゲータは、意味のある結果を作製するために、そのアグリゲータのワーカからのすべての応答を待つ必要がある場合があり、そのことによって総合的な性能は、接続の大部分がパケット損失に少しも遭遇しない場合でも、単一の輻輳状態にある接続により決定される。要約すると、分割／集約トラフィックパターンは通常、データセンタネットワークにおいてネットワーク輻輳を引き起こし、このことが、ＴＣＰスループットの崩壊をもたらし、ウェブアプリケーションのサービス品質（ＱｏＳ）を低下させる。

本発明は、エンドツーエンド輻輳回避アルゴリズムを用いてインキャスト問題に対処する。具体的には本発明は、インキャスト回避ＴＣＰ（ＩＡ−ＴＣＰ）、ネットワークパイプに注入されるパケットの総数を制限して帯域幅遅延積（ＢＤＰ）を満たす、レートベースの輻輳制御アルゴリズムを提案する。本発明のアルゴリズムは、ワーカのＴＣＰデータ送出レートを制御するように、ＴＣＰ確認応答（ＡＣＫ）規則によってアグリゲータ側で動作するように設計される。ＮＳ−２シミュレーションによって本発明は、ＩＡ−ＴＣＰがインキャスト輻輳を完全に回避することを示し、高いグッドプットおよび高速のクエリ完了時間を示す。

ＴＣＰインキャスト輻輳問題は、従来技術の多くの文献において以前に研究されている。これらの従来技術は主に、ウィンドウベースの輻輳制御を重点的に取り扱っており、一方で本発明は、レートベースの輻輳制御アルゴリズムを提案する。

本発明の態様によれば、アグリゲータおよび複数のワーカを含むネットワークでのネットワーク輻輳を回避するための方法であって、複数のワーカが、アグリゲータへの同じボトルネックリンクを共有し、方法が、アグリゲータとワーカとの間の接続の数を計数するステップ、複数のワーカの各々のウィンドウサイズ（Ｗ）を調整するステップであって、ウィンドウサイズ（Ｗ）が接続の数に基づく、調整するステップ、ＡＣＫにＡＣＫ遅延（Δ）を付加するステップであって、ＡＣＫ遅延（Δ）がウィンドウサイズ（Ｗ）に基づく、付加するステップ、および、ワーカにウィンドウサイズ（Ｗ）とともにＡＣＫを送出するステップを含む、方法が提供される。

好ましい実施形態によれば、接続の数を計数するステップは、接続の数を初期化するステップをさらに含む。

方法の別の好ましい実施形態によれば、接続の数は、接続が生成されるときは常に増大され、接続の数は、接続が閉じられるときは常に減少される。

方法の別の好ましい実施形態によれば、接続の数を計数するステップは、複数のワーカの各々にクエリ要求を送出するステップをさらに含む。

方法の別の好ましい実施形態によれば、すべての接続のウィンドウサイズ（Ｗ）は同じである。

方法の別の好ましい実施形態によれば、ウィンドウサイズ（Ｗ）を調整するステップは、ウィンドウサイズ（Ｗ）を最大値に設定するステップをさらに含む。

方法の別の好ましい実施形態によれば、ウィンドウサイズの最大値は、

であり、ただし、ａｄｖｅｒｔｉｓｅはウィンドウサイズであり、ＭＳＳは最大セグメントサイズであり、ＲＴＴは最小ラウンドトリップ時間であり、ｎは同時接続の総数である。

方法の別の好ましい実施形態によれば、ＡＣＫ遅延（Δ）は、

であり、ただし、ａｄｖｅｒｔｉｓｅはウィンドウサイズであり、ＭＳＳは最大セグメントサイズであり、ＲＴＴは最小ラウンドトリップ時間であり、ｎは同時接続の総数である。

方法の別の好ましい実施形態によれば、ＡＣＫ遅延（Δ）の第１のものの代わりに、一様分布にしたがう０から（ＲＴＴ＋Δ）までのランダム値が選定され、ただし、ＲＴＴは最小ラウンドトリップ時間である。

方法の別の好ましい実施形態によれば、ウィンドウサイズ（Ｗ）とともにＡＣＫを送出するステップは、ＡＣＫ遅延（Δ）がｇより大きいならば、遅延タイマが期限切れになった後で実行される。

方法の別の好ましい実施形態によれば、ウィンドウサイズ（Ｗ）とともにＡＣＫを送出するステップは、ＡＣＫ遅延（Δ）が負であるならば、遅延なしに即時に実行される。

方法の別の好ましい実施形態によれば、方法はＴＣＰレイヤにおいて実行される。

方法の別の好ましい実施形態によれば、方法はレートベースの輻輳制御アルゴリズムである。

本発明の別の態様によれば、アグリゲータおよび複数のワーカを含むネットワークでのネットワーク輻輳を回避するためのアグリゲータであって、複数のワーカが、アグリゲータへの同じボトルネックリンクを共有し、アグリゲータが、プロセッサ（図示せず）および送受信器（図示せず）を備え、プロセッサが、アグリゲータとワーカとの間の接続の数を計数すること、複数のワーカの各々のウィンドウサイズ（Ｗ）を調整することであって、ウィンドウサイズ（Ｗ）が接続の数に基づく、調整すること、および、ＡＣＫにＡＣＫ遅延（Δ）を付加することであって、ＡＣＫ遅延（Δ）がウィンドウサイズ（Ｗ）に基づく、付加することを遂行するように構成され、送受信器が、ワーカにウィンドウサイズ（Ｗ）とともにＡＣＫを送出することを遂行するように構成される、アグリゲータが提供される。

アグリゲータの好ましい実施形態によれば、接続の数を計数することは、接続の数を初期化することをさらに含む。

アグリゲータの別の好ましい実施形態によれば、接続の数は、接続が生成されるときは常に増大され、接続の数は、接続が閉じられるときは常に減少される。

アグリゲータの別の好ましい実施形態によれば、接続の数を計数することは、送受信器によって複数のワーカの各々にクエリ要求を送出することをさらに含む。

アグリゲータの別の好ましい実施形態によれば、すべての接続のウィンドウサイズ（Ｗ）は同じである。

アグリゲータの別の好ましい実施形態によれば、ウィンドウサイズ（Ｗ）を調整することは、ウィンドウサイズ（Ｗ）を最大値に設定することをさらに含む。

アグリゲータの別の好ましい実施形態によれば、ウィンドウサイズの最大値は、

であり、ただし、ａｄｖｅｒｔｉｓｅはウィンドウサイズであり、ＭＳＳは最大セグメントサイズであり、ＲＴＴは最小ラウンドトリップ時間であり、ｎは同時接続の総数である。

アグリゲータの別の好ましい実施形態によれば、ＡＣＫ遅延（Δ）は、

であり、ただし、ａｄｖｅｒｔｉｓｅはウィンドウサイズであり、ＭＳＳは最大セグメントサイズであり、ＲＴＴは最小ラウンドトリップ時間であり、ｎは同時接続の総数である。

アグリゲータの別の好ましい実施形態によれば、ＡＣＫ遅延（Δ）の第１のものの代わりに、一様分布にしたがう０から（ＲＴＴ＋Δ）までのランダム値が選定され、ただし、ＲＴＴは最小ラウンドトリップ時間である。

アグリゲータの別の好ましい実施形態によれば、ウィンドウサイズ（Ｗ）とともにＡＣＫを送出することは、ＡＣＫ遅延（Δ）がゼロより大きいならば、遅延タイマが期限切れになった後で実行される。

アグリゲータの別の好ましい実施形態によれば、ウィンドウサイズ（Ｗ）とともにＡＣＫを送出することは、ＡＣＫ遅延（Δ）が負であるならば、遅延なしに即時に実行される。

本発明の別の態様によれば、アグリゲータおよび複数のワーカを備えるネットワークシステムであって、ワーカが、アグリゲータへの同じボトルネックリンクを共有し、アグリゲータが、プロセッサおよび送受信器を備え、プロセッサが、アグリゲータとワーカとの間の接続の数を計数すること、複数のワーカの各々のウィンドウサイズ（Ｗ）を調整することであって、ウィンドウサイズ（Ｗ）が接続の数に基づく、調整すること、および、ＡＣＫにＡＣＫ遅延（Δ）を付加することであって、ＡＣＫ遅延（Δ）がウィンドウサイズ（Ｗ）に基づく、付加することを遂行するように構成され、送受信器が、ワーカにウィンドウサイズ（Ｗ）とともにＡＣＫを送出することを遂行するように構成され、アグリゲータが、アグリゲータに関する上記の実施形態にしたがう、ネットワークシステムが提供される。

本発明の別の態様によれば、アグリゲータおよび複数のワーカを含むネットワークでのネットワーク輻輳を回避するためのコンピュータプログラムであって、複数のワーカが、アグリゲータへの同じボトルネックリンクを共有し、コンピュータプログラムが、アグリゲータとワーカとの間の接続の数を計数するステップ、複数のワーカの各々のウィンドウサイズ（Ｗ）を調整するステップであって、ウィンドウサイズ（Ｗ）が接続の数に基づく、調整するステップ、ＡＣＫにＡＣＫ遅延（Δ）を付加するステップであって、ＡＣＫ遅延（Δ）がウィンドウサイズ（Ｗ）に基づく、付加するステップ、および、ワーカにウィンドウサイズ（Ｗ）とともにＡＣＫを送出するステップを実行し、コンピュータプログラムが、方法に関する上記の実施形態にしたがう、コンピュータプログラムが提供される。

本発明の価値は、データセンタネットワークにおいてのよく知られているインキャスト輻輳が完璧に回避され得るということである。したがって主な有益性は、クラウドサービスなどのデータセンタアプリケーション、ウェブ検索等が最終的に、より良好な性能、すなわちサービス品質（ＱｏＳ）を示すことになるということとなる。

分割／集約アプリケーション用の典型的なネットワーク接続形態の構造を例示する図である。 ネットワーク輻輳を回避するためにアグリゲータで遂行されるインキャスト回避アルゴリズムを例示する図である。 第１のＡＣＫ期間に対するランダム遅延の例を例示する図である。 背景フローがない状態での集約グッドプット（Ｍｂｐｓ）を例示する図である。 背景フローがない状態でのＴＣＰタイムアウトの割合（％）を例示する図である。 長期的なＴＣＰフローがある状態での集約グッドプット（Ｍｂｐｓ）を例示する図である。 ３０個の短いフローおよび１つの長いフローがある状態でのクエリ完了時間（ｍｓ）を例示する図である。 ＩＡ−ＴＣＰフロー間のグッドプット公平性を例示する図である。

本節では、インキャスト回避のための理想的なデータパケットレートが導出され、次いで、本発明のＩＡ−ＴＣＰアルゴリズムが詳細に解説される。

Ａ．インキャスト回避のためのデータパケットレート
インキャスト回避は、分割／集約アプリケーションがネットワーク輻輳を少しも引き起こさないように、未処理のパケットの総数が経路のＢＤＰを超過しないことを意味する。この目的で、式（１）から、ワーカの集約データパケットレート

×ＭＳＳ／ＲＴＴをリンク容量より小さいように制御することが必要である。本発明の手法は、データパケットの総数が増大する場合に、ＲＴＴにΔ（ｓ）を付加することである。例えば、リンク容量が１０ＭＳＳ／ＲＴＴであると考えてみる。このことは、１０個のパケットのみが、ネットワーク輻輳を回避するために１つのラウンドトリップ時間の間に経路内にあることが許されるということを意味する。今回本発明は、分母に１ＲＴＴの遅延を付加して同じレート２０ＭＳＳ／２ＲＴＴを実現することにより、２０ＭＳＳを可能にし得る。次に、インキャスト回避のための集約データパケットレート、ＩＡレートが、以下のように規定される。

結果として本発明は、すべてのワーカがＩＡレートでデータパケットを送出するならば、ＴｏＲスイッチで発生するインキャスト輻輳を能動的に回避することが可能である。

図２は、本発明によるインキャスト回避アルゴリズムを提示する。インキャスト回避アルゴリズムは、アグリゲータおよび複数のワーカを含むネットワークでのネットワーク輻輳を回避するためのアグリゲータで遂行される。手短に言うと、行番号９−１６は、同じボトルネックリンクを共有するＴＣＰ接続（すなわちワーカ）の総数を計数するためのものである。アグリゲータがＡＣＫを送出する必要があるときは常に、アグリゲータは、行１９−２１において、ワーカにより注入されるパケットの総数を制御するためにａｄｖｅｒｔｉｓｅを計算する。次いで２３−２８においてＡＣＫ＿ｄｅｌａｙ（Δ）が、第１のＡＣＫに対する一様ランダム遅延を除いて決められることになる。行２０においてリンク容量は、ＴｏＲスイッチに接続されるインターフェースのリンクレートを意味し、それはＴＣＰレイヤでの取得可能な情報であることが想定される。最後に行３０−３４において、ＡＣＫ＿ｄｅｌａｙがゼロより大きいならば、ａｄｖｅｒｔｉｓｅとともにＡＣＫが、遅延タイマが期限切れになった後で送出されることになる。この行部分は、本発明のアルゴリズムが、遅延されたＡＣＫではなく即時のＡＣＫを使用することもまた示唆する。

詳細なＩＡ−ＴＣＰアルゴリズムは以下の通りである。アグリゲータは、アグリゲータとワーカとの間のＴＣＰ接続の数を計数する（行９−１６）。グローバル変数が、ｔｃｐ＿ｎｕｍ←０のように初期化される（行９−１０）。そしてグローバル変数は、接続が生成されるときは常に増大される（行１２−１３）。同様にグローバル変数は、接続が閉じられるときは常に減少される（行１５−１６）。これらの場合では、クエリ要求が通常、アグリゲータから各々のワーカに送出される。この理由で本発明は、データパケット制御ではなく確認応答（ＡＣＫ）パケット制御を遂行する。

次いで、各々のワーカのウィンドウサイズ（ｗ_ｉ）およびＡＣＫ間隔（Δ）が、集約データパケットレートをリンク容量より小さくするためにアグリゲータで調整される。

第１に、各々のワーカのウィンドウサイズ（ｗ_ｉ）が調整される（行１９−２１）。アグリゲータがＡＣＫを送出する必要があるときは常に（行１９）、ウィンドウサイズ（ｗ_ｉ）が、ワーカにより注入されるパケットの総数を制御するために計算される（行２０−２１）。この場合では、すべての接続のウィンドウサイズは、簡単のため、およびＩＡ−ＴＣＰ接続間の公平性のため、Ｗとして同じであると想定される。次いで、式（１）からウィンドウサイズＷが以下のようになる。

標準ＴＣＰを用いるワーカは基本的には、インキャスト回避のための能力を有さないので、本発明はこのＷを使用して、ＡＣＫヘッダ内の広告（ａｄｖｅｒｔｉｓｅｍｅｎｔ）フィールドを使用して各々の接続のウィンドウサイズを制御する。例えば、ＢＤＰが１０ＭＳＳでありｎが５であるならば、広告ウィンドウは２となり、その結果各々のワーカは、ＲＴＴごとに２つのデータパケットを送出することが許される。次いで、Ｗの最大値に対する広告ウィンドウが以下のように設定され得る（行２１）。さらに、ウィンドウサイズが整数値であるべきであり、その最小限の値が１であることが留意される。

第２に、ＡＣＫ＿ｄｅｌａｙ（Δ）が、第１のＡＣＫに対する一様ランダム遅延を除いて調整される（行２３−２８）。各々のＡＣＫパケットにＡＣＫ＿ｄｅｌａｙ（Δ）を付加することが、アグリゲータ側で実行される。この遅延が、Ｗは１より小さいが、広告ウィンドウは式（４）により１になるときに、集約データパケットレートがリンク容量を超過することを防止する。（２）、（３）、および（４）から、その遅延は次式にしたがう。

次いで、ＡＣＫ＿ｄｅｌａｙがゼロより大きいならば、ａｄｖｅｒｔｉｓｅとともにＡＣＫが、遅延タイマが期限切れになった後で送出されることになる（行３０−３４）。Δが負であるならば、ＡＣＫは遅延なしに即時に送出され得る（行３０、３２−３４）。最後に、未処理のパケットの総数がアグリゲータにより制御される場合でも、すべてのワーカの送出時間がまれに同期させられる場合に、オーバーフローすることが可能性としてあり得る。そのような送信同期を防止するために、第１のＡＣＫ＿ｄｅｌａｙに対する、一様分布にしたがう０から（ＲＴＴ＋Δ）までのランダム値が、Δの代わりに選定される。図３は、ランダム遅延がランダム遅延期間（すなわち第１のＡＣＫ）の間に各々の接続に与えられ、その結果すべての未処理のパケットが、次の期間からの平均間隔がｎ／（ＲＴＴ＋Δ）である状態で経路にわたって時間的に分布させられる例を示す。

シミュレーション結果
次に、ＩＡ−ＴＣＰアルゴリズムがＮＳ−２により実装され、１つのアグリゲータおよび複数のワーカが、（４ＭＢの共有メモリ／５２個のポート／１．５ｋＢのＭＳＳを想定すると）その（ポートごとの）バッファサイズが５６パケットである、同じＴｏＲスイッチに接続される。リンク容量は１Ｇｂｐｓに設定され、ワーカとアグリゲータとの間のラウンドトリップ伝搬遅延は１００ｕｓに設定される。すべての実験において、アグリゲータは１０Ｂの要求クエリをワーカに送出し、次いで各々のワーカは特定のサイズのデータをアグリゲータに返信する。パケットサイズは１５００バイトに固定され、ＲＴＯ_ｍｉｎは２００ｍｓに設定される。

既存の輻輳回避体系（例えばＩＣＴＣＰ）のコードが利用不可能であるため、ＩＡ−ＴＣＰアルゴリズムは、ＴＣＰ ＳＡＣＫ、および、その送出ウィンドウサイズが１に固定される１−ｗｉｎ ＴＣＰと比較され、そのことにより、スケーラビリティに関してのウィンドウベースの輻輳制御体系の限界が確認され得る。

− Ａ．背景トラフィックがない状態での集約グッドプットおよびタイムアウトの割合
提案される体系を評価するための最も重要な性能測定基準は、インキャスト輻輳がどの程度緩和されるかを示すこととなり、応答データサイズを６４ｋＢ、１２８ｋＢ、および２５６ｋＢに設定することによる、集約グッドプットおよびタイムアウトの割合が測定される。集約グッドプットは、クエリ要求を送出してから複数のワーカの中での最後のデータパケットを受信するまでの時間にわたる、ワーカからの受信されるデータの総量を意味する。結果は、１００回の反復により平均化される。タイムアウトの割合は、反復の総数（すなわち１００）にわたって少なくとも１つのタイムアウトに遭遇するシミュレーションの数を意味する。最高で９６のワーカの数は、現実のデータセンタにおいて９０パーセンタイルに対するアグリゲータへの約１００個の同時接続が存在し得るので、増大されてもよい。ここでは背景トラフィックは存在しない。

図４は集約グッドプットのグラフを提示し、１−ｗｉｎ ＴＣＰは、ある決まった範囲において最も高いグッドプットを示すものの、ワーカの数が３２を超える際に性能低下を示すことが観察される。この結果は、データセンタネットワークにおいてのウィンドウベースの輻輳制御に関する限界を明らかにする。すなわち、最小ウィンドウサイズ（１−ウィンドウ）は、ワーカの数が増大する際にインキャスト輻輳を引き起こす場合がある。他方でＩＡＴＣＰのグッドプットは、高い集約グッドプットを実現している。このことは、提案される体系が、ワーカが高いスケーラビリティによって小さなネットワークパイプを共有可能であるように、すべての接続のデータパケットレートを良好に制御することを示す。

図５は、ＴＣＰタイムアウトの割合のグラフを提示する。グラフは、ＴＣＰ ＳＡＣＫおよび１−ｗｉｎ ＴＣＰが、それぞれ、ワーカの数が８および２４を超えるときに１００％のタイムアウトの割合に遭遇するが、ＩＡ−ＴＣＰはすべての実験においてゼロのタイムアウトを示すことを例示する。さらに、既存のウィンドウベースのインキャスト回避手法、すなわちＤＣＴＣＰおよびＩＣＴＣＰが、（それらの実験セットアップにおいて３５を超えるワーカを伴う状態で）少なくとも１つのタイムアウトを引き起こすことを考慮すると、本発明のＩＡ−ＴＣＰアルゴリズムは、ワーカの数に関して、よりスケーラブルである。

− Ｂ．長期的な背景ＴＣＰフローがある状態での集約グッドプット
図６は、分割／集約フローの集約グッドプットを示す。１−ｗｉｎ ＴＣＰおよびＴＣＰ ＳＡＣＫの両方は、背景ＴＣＰフローに起因して非常に低下させられるが、ＩＡ−ＴＣＰのグッドプットは、ワーカの数が増大するにつれてより高くなっていることが観察される。応答データのサイズの違いが、ＩＡ−ＴＣＰのグッドプットに影響を与えることはまれであるように思われる。このシミュレーションは、ＩＡ−ＴＣＰに関してタイムアウトがないこともまた示すが、このことはここでは省かれる。

− Ｃ．クエリ完了時間
多くの分割／集約アプリケーションはソフトリアルタイム特性を有するので、短いフローおよび長いフローが共存するときのクエリ完了時間を測定することは重要である。３０個の短いフローおよび１つの長いフローが走らされ、それらの完了時間が、図７に示されるように測定される。応答データサイズは、短いフローに対しては１０ｋＢであり、長いフローに対しては１０ＭＢである。ＴＣＰ ＳＡＣＫの場合では、短いフローの平均クエリ完了時間は、大部分の短いフローがインキャスト輻輳により引き起こされるパケット損失およびタイムアウトに遭遇するので、比較的高いことが観察される。１−ｗｉｎ ＴＣＰは、ＴＣＰ ＳＡＣＫよりはるかに低い平均完了時間を示すが、総合的な性能は、長いフローにより影響を受けるいくつかのフローがより長い完了時間を有するので、低下させられる場合がある。ＩＡ−ＴＣＰは、インキャスト輻輳を回避することにより、短いフローに対して、非常に高速の平均および最長の完了時間を示す。ＩＡ−ＴＣＰが、ネットワークパイプを効果的に利用することにより、他のものより高速に長いメッセージを移送することもまた観察される。

− Ｄ．ＩＡ−ＴＣＰフロー間の公平性
最後に、同じボトルネックリンクを共有する複数のＩＡ−ＴＣＰフロー間のグッドプット公平性が測定される。データセンタ環境は通常、同種ネットワークおよび単一の運営管理制御などの快適な状態を供与するので、レガシープロトコルに対する公平性は考慮されない。公平性を測定するために、５つのＩＡ−ＴＣＰフロー群が、図８に示されるように３秒間隔で順に開始する。各々の群は８つのＩＡ−ＴＣＰフローからなり、各々のフローの応答データサイズは１００ＭＢである。図８から、各々の群内のすべてのフローは同じ帯域幅部分を有し、すべての群は、群が追加／終了される際に帯域幅を公平に共有することが観察される。

本発明は、レートベースの輻輳制御アルゴリズムであるインキャスト回避ＴＣＰ（ＩＡ−ＴＣＰ）に関して説明されたが、本発明はそのようには限定されない。当業者であれば、本明細書の教示を、１つのノードがその接続状態を別のノードに移転させる他のネットワークに容易に拡張することが可能である。加えて本発明は、ワイヤレス、無線、セルラー、または他の非有線の用途において使用するのに好ましくあり得るが、本発明は、そのように限定されず、パケットベースの通信をサポートする有線ネットワークまたは光ネットワークにおいて用いられ得る。

本発明は、それらの方法を実践するために、方法、装置、デバイス、およびシステムの形態で実施され得る。本発明は、ＣＤ−ＲＯＭ、ハードドライブ、または任意の他の機械可読記憶媒体などの有形媒体内のコンピュータプログラムコードの形態でさらに実施され得るものであり、プログラムコードが、コンピュータなどの機械にロードされ、その機械により実行されるとき、その機械は本発明を実施するための装置となる。本発明は、例えば、記憶媒体に記憶され、機械にロードされ、および／または機械により実行されるか、あるいは、電気配線もしくはケーブル接続を介して、光ファイバを通して、または電磁放射によってなど、何らかの送信媒体によって送信されるかを問わず、プログラムコードの形態でさらに実施され得るものであり、プログラムコードが、コンピュータなどの機械にロードされ、その機械により実行されるとき、その機械は本発明を実施するための装置となる。汎用プロセッサ上で実装されるとき、プログラムコードセグメントはプロセッサと結び付いて、特定の論理回路に類似して動作する独特のデバイスをもたらす。

本発明の特質を解説するために説明および例示された部分の、細部、材料、および配置構成の様々な変更が、以下の特許請求の範囲において表現されるような本発明の原理および範囲から逸脱することなく、当業者により行われ得ることがさらに理解されるであろう。

本発明は、オンラインサービスに提供され、それらのオンラインサービス自体のデータセンタを、データセンタネットワークにおいての典型的なインキャスト輻輳問題を完璧に回避するように動作させ得るものである。本発明は、クラウドサービスなどのデータセンタアプリケーション、ウェブ検索等が最終的に、より良好な性能、すなわちサービス品質（ＱｏＳ）を示すことになるという有益性のために提供される。

Claims (15)

1. アグリゲータサーバおよび複数のワーカサーバを含むネットワークにおいてのネットワーク輻輳を回避するための方法であって、複数のワーカサーバが、アグリゲータサーバへの同じボトルネックリンクを共有し、方法が、
   アグリゲータサーバと複数のワーカサーバとの間の接続の数を計数するステップ、
   ワーカサーバにＡＣＫを送出し、ラウンドトリップ時間（ＲＴＴ）を測定するステップ、
   接続の数およびＲＴＴから複数のワーカサーバの各々に対して許されるウィンドウサイズを計算するステップ、
   計算されたウィンドウサイズから遅延を計算するステップ、ならびに、
   ネットワーク輻輳を回避するために、ＡＣＫに遅延を付加するステップ
   を含む、方法。
2. 複数のワーカサーバの各々に対して許されるウィンドウサイズ（ａｄｖｅｒｔｉｓｅ）が、
   

   

   であり、ただし、ＭＳＳが最大セグメントサイズであり、ｎが接続の数である、請求項１に記載の方法。
3. 遅延（Δ）が、
   

   

   である、請求項２に記載の方法。
4. 計算された遅延（Δ）がゼロより大きいならば、ワーカサーバに、計算されたウィンドウサイズとともに遅延されたＡＣＫを送出するステップをさらに含む、請求項３に記載の方法。
5. 計算された遅延（Δ）が負であるならば、遅延を付加することなしにワーカサーバにＡＣＫを即時に送出するステップをさらに含む、請求項３に記載の方法。
6. 遅延されたＡＣＫを送出するステップが、０からＲＴＴ＋Δまでの時間の間に複数のワーカサーバの各々にＡＣＫをランダムに送出するステップをさらに含む、請求項４に記載の方法。
7. 方法が、データセンタネットワークにおいて、ＴＣＰレイヤにおいて実施される、請求項１に記載の方法。
8. アグリゲータサーバおよび複数のワーカサーバを含むネットワークにおいてのネットワーク輻輳を回避するためのアグリゲータサーバであって、複数のワーカサーバが、アグリゲータサーバへの同じボトルネックリンクを共有し、アグリゲータサーバが、
   送受信器、および、
   プロセッサを備え、プロセッサが、
   アグリゲータサーバと複数のワーカサーバとの間の接続の数を計数すること、
   ワーカサーバにＡＣＫを送出し、ラウンドトリップ時間（ＲＴＴ）を測定すること、
   接続の数およびＲＴＴから複数のワーカサーバの各々に対して許されるウィンドウサイズを計算すること、
   計算されたウィンドウサイズから遅延を計算すること、ならびに、
   ネットワーク輻輳を回避するために、ＡＣＫに遅延を付加すること
   を遂行するように構成される、アグリゲータサーバ。
9. ワーカサーバの各々に対して許されるウィンドウサイズ（ａｄｖｅｒｔｉｓｅ）が、
   

   

   であり、ただし、ＭＳＳが最大セグメントサイズであり、ｎが接続の数である、請求項８に記載のアグリゲータサーバ。
10. 遅延（Δ）が、
    

    

    である、請求項９に記載のアグリゲータサーバ。
11. 計算された遅延（Δ）が０より大きいならば、ワーカサーバに、計算されたウィンドウサイズとともに遅延されたＡＣＫを送出することを遂行するようにアグリゲータサーバがさらに構成される、請求項１０に記載のアグリゲータサーバ。
12. 計算された遅延（Δ）が負であるならば、遅延を付加することなしにワーカサーバにＡＣＫを即時に送出することを遂行するようにアグリゲータサーバがさらに構成される、請求項１０に記載のアグリゲータサーバ。
13. 遅延されたＡＣＫを送出することが、０からＲＴＴ＋Δまでの時間の間にワーカサーバの各々にＡＣＫをランダムに送出することをさらに含む、請求項１１に記載のアグリゲータサーバ。
14. アグリゲータサーバが、データセンタネットワークにおいて、ＴＣＰレイヤにおいて動作させられる、請求項８に記載のアグリゲータサーバ。
15. アグリゲータサーバおよび複数のワーカサーバを含むネットワークにおいてのネットワーク輻輳を回避するためのコンピュータプログラムであって、請求項１から７のいずれか一項に記載の方法を実施する、コンピュータプログラム。

Images