特表 2022-533970 速度最適化された輻輳管理

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2022-07-27

(54)【発明の名称】速度最適化された輻輳管理

(51)【国際特許分類】

   H04L 47/263 20220101AFI20220720BHJP

   H04L 47/11 20220101ALI20220720BHJP

【ＦＩ】

H04L47/263

H04L47/11

【審査請求】未請求

【予備審査請求】未請求

(21)【出願番号】P 2021568610

(86)(22)【出願日】2020-05-15

(85)【翻訳文提出日】2021-12-25

(86)【国際出願番号】 US2020033154

(87)【国際公開番号】W WO2020236599

(87)【国際公開日】2020-11-26

(31)【優先権主張番号】16/415,609

(32)【優先日】2019-05-17

(33)【優先権主張国・地域又は機関】US

(81)【指定国・地域】

(71)【出願人】

【識別番号】521499815

【氏名又は名称】ペンサンド システムズ インク．

(74)【代理人】

【識別番号】100082072

【弁理士】

【氏名又は名称】清原 義博

(72)【発明者】

【氏名】パン，ロン

(72)【発明者】

【氏名】ニューマン，ピーター

【テーマコード（参考）】

5K030

【Ｆターム（参考）】

5K030GA13

5K030LC11

5K030MB06

(57)【要約】

【解決手段】
ＲｏＣＥｖ２ネットワーク中の輻輳を低下させるための方法およびシステムが、提供される。方法は、送信者ノードから受信者ノードへ流れるデータ転送量上で、データセンターの大きな規模で作動するように、構成される。記載される方法は、高速開始段階、移行段階、および調整段階の、３つの段階を有する。高速開始段階では、送信者は、高速の初速度で受信者にデータを送信する。これは、受信者が輻輳イベントを観察するまで継続してもよい。これが起こると、方法が移行段階に入るため、送信者は、データ転送速度を低下させる。低下速度から、方法は調整段階に入り、ここで、速度は、フィードバック制御ループと加法増加乗法減少（ＡＩＭＤ）アルゴリズムとの組み合わせ使用して、増加される。
【選択図】図４

【特許請求の範囲】

【請求項1】

ネットワークプロトコル中の輻輳を管理する、コンピュータ実装された方法であって、前記方法は、
ａ）ネットワーク中の輻輳イベントを検出する工程と、
ｂ）データ転送速度を初速度から最小速度に減速させる工程と、
ｃ）データ転送速度を初速度の半分に増加させる工程と、
ｄ）ネットワークの一方向の待ち時間を周期的にモニタリングする工程と、
ｅ）フィードバック制御アルゴリズムと加法増加乗法減少（ＡＩＭＤ）アルゴリズムとを使用して、データ転送速度を調節する工程と、
を含む、方法。

【請求項2】

初期データ転送速度を設定することは、帯域遅延積と等しい初期ウィンドウを設定すること、かつ、初期ウィンドウを設定することの後に輻輳が検出されない場合に、ウィンドウサイズを上昇させることを、さらに含む、請求項１に記載のコンピュータ実装された方法。

【請求項3】

前記初期データ転送速度はネットワークリンクのライン速度と等しい、請求項１に記載のコンピュータ実装された方法。

【請求項4】

閾値待ち時間は、データパケットの送信のためのラウンドトリップタイムに基づく、請求項１に記載のコンピュータ実装された方法。

【請求項5】

最小データ転送速度は、初期データ転送速度の少なくとも１パーセント未満である、請求項１に記載のコンピュータ実装された方法。

【請求項6】

フィードバック制御ループは、比例－積分コントローラを含む、請求項１に記載のコンピュータ実装された方法。

【請求項7】

データを最小データ転送速度で送信者から受信者に転送することは、輻輳通知パケットを受信者から送信者に送ること、および、送信者が前記輻輳通知パケットを受信した際に、速度を更新することを含む、請求項１に記載のコンピュータ実装された方法。

【請求項8】

一方向の待ち時間を継続的にモニタリングすることは、受信パケットのバイトの合計数のトラッキングを維持することを含む、請求項１に記載のコンピュータ実装された方法。

【請求項9】

管理された転送速度は、最小転送速度での１期間と初速度の半分での１期間の後に計算される、請求項１に記載のコンピュータ実装された方法。

【請求項10】

期間は、送信パケットのラウンドトリップタイムに基づく、請求項９に記載のコンピュータ実装された方法。

【請求項11】

前記初期転送速度は、送信者と受信者との間のライン速度に基づく、請求項１に記載のコンピュータ実装された方法。

【請求項12】

前記初期転送速度は、前記送信者のリンク速度と前記受信者のリンク速度との間の最小速度である、請求項１１に記載のコンピュータ実装された方法。

【請求項13】

前記ＡＩＭＤアルゴリズムは、管理速度が閾値を下回る場合に、前記管理速度に対して加法を実施し、前記管理速度が閾値を上回る場合に、前記管理速度に対して乗法を実施することを含む、請求項１に記載のコンピュータ実装された方法。

【請求項14】

前記加法は、正の数によるものである、請求項１３に記載のコンピュータ実装された方法。

【請求項15】

前記乗法は、０と１との間の数によるものである、請求項１３に記載のコンピュータ実装された方法。

【請求項16】

ａ）期間の閾値数にわたり、前記データ転送速度を調節する工程から、少なくとも前記初速度を取得する工程と、
ｂ）輻輳イベントに関してネットワークをモニタリングする工程と、
をさらに含む、請求項１に記載のコンピュータ実装された方法。

【請求項17】

複数の演算ノードを含む、ネットワーク中のネットワーク輻輳を管理するためのシステムであって、
前記演算ノードは、
ａ）１以上の以前に取得された待ち時間値および命令のセットを格納するためのメモリと、
ｂ）１以上のプロセッサであって、前記命令のセットに、
ｉ）前記ネットワーク中の輻輳イベントを検出する、
ｉｉ）データ転送速度を初速度から最小速度に減速させる、
ｉｉｉ）前記データ転送速度を前記初速度の半分に増加させる、
ｉｖ）前記ネットワークの一方向の待ち時間を周期的にモニタリングする、
ｖ）フィードバック制御アルゴリズムと加法増加乗法減少（ＡＩＭＤ）アルゴリズムとを使用して、前記データ転送速度を調節する、
ことを実行させるように、構成された、前記プロセッサと、を含む、システム。

【請求項18】

前記ネットワークは、少なくとも１つのリンクを有する、請求項１７に記載のシステム。

【請求項19】

前記複数の演算ノードは、送信者ノードと受信者ノードとを含む、請求項１７に記載のシステム。

【請求項20】

初期データ転送速度を設定することは、帯域遅延積と等しい初期ウィンドウを設定すること、かつ、初期ウィンドウを設定することの後に輻輳が検出されない場合に、ウィンドウサイズを上昇させることを、さらに含む、請求項１７に記載のシステム。

【請求項21】

前記初期データ転送速度は、イーサネットリンクのライン速度と等しい、請求項１７に記載のシステム。

【請求項22】

閾値待ち時間は、データパケットの送信のためのラウンドトリップタイムに基づく、請求項１７に記載のシステム。

【請求項23】

最小データ転送速度は、初期データ転送速度の少なくとも１パーセント未満である、請求項１７に記載のシステム。

【請求項24】

フィードバック制御ループは、比例－積分コントローラを含む、請求項１７に記載のシステム。

【請求項25】

データを最小データ転送速度で送信者から受信者に転送することは、輻輳通知パケットを受信者から送信者に送ること、および、送信者が前記輻輳通知パケットを受信した際に、速度を更新することを含む、請求項１７に記載のシステム。

【請求項26】

一方向の待ち時間を継続的にモニタリングすることは、受信パケットのバイトの合計数のトラッキングを維持することを含む、請求項１７に記載のシステム。

【請求項27】

管理された転送速度は、最小転送速度での１期間と初速度の半分での１期間の後に計算される、請求項１７に記載のシステム。

【請求項28】

期間は、送信パケットのラウンドトリップタイムに基づく、請求項２７に記載のシステム。

【請求項29】

前記初期転送速度は、送信者と受信者との間のライン速度に基づく、請求項１７に記載のシステム。

【請求項30】

前記初期転送速度は、前記送信者と前記受信者との間の最小ライン速度である、請求項２９に記載のシステム。

【請求項31】

前記ＡＩＭＤアルゴリズムは、管理速度が閾値を下回る場合に、前記管理速度に対して加法を実施し、前記管理速度が閾値を上回る場合に、前記管理速度に対して乗法を実施することを含む、請求項１７に記載のシステム。

【請求項32】

前記加法は、正の数によるものである、請求項３１に記載のシステム。

【請求項33】

前記乗法は、０と１との間の数によるものである、請求項３１に記載のシステム。

【請求項34】

ネットワーク中のネットワーク輻輳を管理するための、コンピュータ実装された方法であって、前記コンピュータ実装された方法は、
ａ）データ速度を初期速度に設定すること、および、送信者と受信者との間で、前記受信者が輻輳イベントを検出するまでデータ転送を実施することを含む、高速開始段階と、
ｂ）ある期間にわたり、前記データ速度を最小データ速度に低下させること、およびその後に、ある期間にわたり、前記データ速度を前記初速度の半分に増加させることを含む、移行段階と、
ｃ）フィードバック制御ループと加法減少乗法増加アルゴリズムとの組み合わせを使用して、前記データ速度を修正することを含む、調整段階と、
を含む、コンピュータ実装された方法。

【請求項35】

前記高速開始段階の前に、前記送信者と前記受信者との間でクロック速度とライン速度とを共有することを含む、初期設定フェーズを、さらに含む、請求項３４に記載のコンピュータ実装された方法。

【請求項36】

前記高速開始段階の前に、データパケットを送信するために、ウィンドウサイズを初期ウィンドウサイズに設定する工程を、さらに含む、請求項３４に記載のコンピュータ実装された方法。

【請求項37】

輻輳イベントが前記ネットワーク内で検出されていない間は、前記ウィンドウサイズを増加させる工程を、さらに含む、請求項３６に記載のコンピュータ実装された方法。

【請求項38】

前記ウィンドウサイズは指数関数的に増加される、請求項３７に記載のコンピュータ実装された方法。

【請求項39】

前記移行段階は、前記輻輳イベントの検出後に始まる、請求項３４に記載のコンピュータ実装された方法。

【請求項40】

前記フィードバック制御アルゴリズムは、比例積分アルゴリズムである、請求項３４に記載のコンピュータ実装された方法。

【請求項41】

前記フィードバック制御ループは、現在速度、比例項、および積分項の間の差異として説明され得る、請求項４０に記載のコンピュータ実装された方法。

【請求項42】

前記比例項は、現在待ち時間と閾値待ち時間との間の差異を説明し、他方、前記積分項は、現在待ち時間と以前の待ち時間との間の差異を説明する、請求項４１に記載のコンピュータ実装された方法。

【請求項43】

乗法増加は、確率イベントに対応して実施される、請求項３４に記載のコンピュータに実施された方法。

【請求項44】

乗法増加は、フィードバック制御ループより低い周波数で実施される、請求項３４に記載のコンピュータ実装された方法。

【請求項45】

複数の演算ノードを含む、ネットワーク中のネットワーク輻輳を管理するためのシステムであって、前記演算ノードは、
ａ）１以上の以前に取得された待ち時間値および命令のセットを格納するためのメモリと、
ｂ）１以上のプロセッサであって、前記命令のセットが、
ｉ）データ速度を初期速度に設定すること、および、送信者と受信者との間で、前記受信者が輻輳イベントを検出するまでデータ転送を実施することを含む、高速開始段階と、
ｉｉ）ある期間にわたり、前記データ速度を最小データ速度に低下させること、およびその後に、ある期間にわたり、前記データ速度を前記初速度の半分に増加させることを含む、移行段階と、
ｉｉｉ）フィードバック制御ループと加法減少乗法増加アルゴリズムとの組み合わせを使用して、前記データ速度を修正することを含む、調整段階と、
を実装するように前記命令のセットを実行するように、構成されている、前記プロセッサと、を含む、システム。

【請求項46】

前記高速開始段階の前に、前記送信者と前記受信者との間でクロック速度とライン速度とを共有することを含む、初期設定フェーズ、をさらに含む、請求項４５に記載のシステム。

【請求項47】

前記高速開始段階の前に、データパケットを送信するために、ウィンドウサイズを初期ウィンドウサイズに設定することを、さらに含む、請求項４５に記載のシステム。

【請求項48】

輻輳イベントが前記ネットワーク内で検出されていない間は、前記ウィンドウサイズを増加させることを、さらに含む、請求項４７に記載のシステム。

【請求項49】

前記ウィンドウサイズは指数関数的に増加される、請求項４８に記載のシステム。

【請求項50】

前記移行段階は、前記輻輳イベントの検出後に始まる、請求項４５に記載のシステム。

【請求項51】

前記フィードバック制御アルゴリズムは、比例積分アルゴリズムである、請求項４５に記載のシステム。

【請求項52】

前記フィードバック制御ループは、現在速度、比例項、および積分項の間の差異として説明され得る、請求項５１に記載のシステム。

【請求項53】

前記比例項は、現在待ち時間と閾値待ち時間との間の差異を説明し、他方、前記積分項は、現在待ち時間と以前の待ち時間との間の差異を説明する、請求項５２に記載のシステム。

【請求項54】

前記乗法増加は、確率イベントに対応して実施される、請求項４５に記載のシステム。

【請求項55】

前記乗法増加は、フィードバック制御ループより低い周波数で実施される、請求項４５に記載のシステム。

【発明の詳細な説明】

【技術分野】

【0001】

関連出願の相互参照
本出願は、２０１９年５月１７日に出願され、「ＲＡＴＥ－ＯＰＴＩＭＩＺＥＤ ＣＯＮＧＥＳＴＩＯＮ ＭＡＮＡＧＥＭＥＮＴ」と題される、米国特許出願第１６／４１５，６０９号の利益を主張し、その内容は、全ての目的のために、参照によって本明細書に組み込まれる。

【背景技術】

【0002】

データセンターアプリケーションは、ホストのネットワークスタックを含むネットワークに、高スループットと超低の待ち時間を要求する。標準ＴＣＰ／ＩＰの高ＣＰＵオーバーヘッドにより、イーサネット（ＲｏＣＥｖ２）にわたるリモート・ダイレクト・メモリ・アクセス（ＲＤＭＡ）が、代替技術として、現代のデータセンターに展開されて、低待ち時間と高性能とを達成する。高い負荷がかかった場合に、データセンターネットワークで輻輳が発生して、パケットドロップを引き起こす可能性がある。その結果、ＲＤＭＡの性能は大幅に低下し、ＲｏＣＥｖ２は優先度ベースのフロー制御（Ｐｒｉｏｒｉｔｙ－ｂａｓｅｄ Ｆｌｏｗ Ｃｏｎｔｒｏｌ）（ＰＦＣ）に依存して、ドロップフリーネットワークを達成する。ＰＦＣは輻輳の広がりを引き起こすかもしれず、ここで、ネットワークの１つのエリアにおけるデータ転送量の減速は、ネットワークの他のエリアにおけるデータ転送量を減速させる。従って、輻輳管理は、輻輳の広がりを回避するのに必要である。データセンター量子化輻輳通知（ＤＣＱＣＮ）などの、ＲｏＣＥｖ２ネットワーク中の輻輳管理の既存の方法は、大規模での作動が不十分であり、数千のポーズフレームを生成し、ネットワーク使用率と平均スループットとを低下させ、輻輳フローの終了を非常に遅くさせる可能性がある。

【発明の概要】

【0003】

データセンターネットワークにおける、大きな規模で有効な、輻輳管理が必要とされている。そのような方法は、高リンク利用率、趙低の待ち時間、およびネットワークフェアネスを達成するだろう。開示される方法は、輻輳イベントに対応して、データ速度をダイナミックに変更することによって、および、フィードバック制御アルゴリズムを加法増加乗法減少（ＡＩＭＤ）アルゴリズムと組み合わせることによって、これらのゴールを達成する。

【0004】

一態様では、ネットワークプロトコル中の輻輳を管理するコンピュータ実装された方法が、開示される。方法は、ネットワーク中の輻輳イベントを検出する工程を含む。方法は、次に、データ転送速度を初速度から最小速度に減速させる工程を含む。方法は、次に、データ転送速度を初速度の半分に増加させる工程を含む。方法は、次に、ネットワークの一方向の待ち時間を周期的にモニタリングする工程を含む。最終的に、ネットワークは、フィードバック制御アルゴリズムと加法増加乗法減少（ＡＩＭＤ）アルゴリズムとを使用して、データ転送速度を調節する工程を含む。いくつかの実施形態では、初期データ転送速度を設定することは、帯域遅延積と等しい初期ウィンドウを設定すること、かつ、初期ウィンドウを設定することの後に輻輳が検出されない場合に、ウィンドウサイズを上昇させることを、さらに含む。いくつかの実施形態では、初期データ転送速度は、ネットワークのライン速度と等しい。いくつかの実施形態では、閾値待ち時間は、データパケットの送信のためのラウンドトリップタイムに基づく。いくつかの実施形態では、最小データ転送速度は、初期データ転送速度の少なくとも１パーセント未満である。いくつかの実施形態では、フィードバック制御ループは、比例－積分コントローラを含む。いくつかの実施形態では、データを最小データ転送速度で送信者から受信者に転送する工程は、輻輳通知パケットを受信者から送信者に送ること、および、送信者が輻輳通知パケットを受信した際に、速度を更新することを含む。いくつかの実施形態では、一方向の待ち時間を継続的にモニタリングすることは、受信パケットのバイトの合計数のトラッキングを維持することを含む。いくつかの実施形態では、管理された転送速度は、最小転送速度での１期間と初速度の半分での１期間の後に計算される。いくつかの実施形態では、期間は、送信パケットのラウンドトリップタイムに基づく。いくつかの実施形態では、初期転送速度は、送信者と受信者との間のライン速度に基づく。いくつかの実施形態では、初期転送速度は、送信者のリンク速度と受信者のリンク速度との間の最小速度である。いくつかの実施形態では、ＡＩＭＤアルゴリズムは、管理速度が閾値を下回る場合に、管理速度に対して加法を実施し、管理速度が閾値を上回る場合に、管理速度に対して乗法を実施することを含む。いくつかの実施形態では、加法は、正の数によるものである、いくつかの実施形態では、乗法は、０と１との間の数によるものである。いくつかの実施形態では、コンピュータ実装された方法は、期間の閾値数にわたり、データ転送速度を調節する工程から、少なくとも初速度を取得する工程と、輻輳イベントに関してネットワークをモニタリングする工程と、をさらに含む。

【0005】

別の態様では、ネットワーク中のネットワーク輻輳を管理するためのシステムが開示される。システムは、複数の演算ノードを含む。演算ノードは、１以上の以前に取得された待ち時間値および命令のセットを格納するためのメモリと、１以上のプロセッサに加えてインストラクションのセットと、を含む。プロセッサは、物理層リンク中の輻輳イベントを検出するために、命令のセットを実行し、データ転送速度を初速度から最小速度に減速させ、データ転送速度を初速度の半分に増加させ、ネットワークの一方向の待ち時間を周期的にモニタリングし、そして、フィードバック制御アルゴリズムと加法増加乗法減少（ＡＩＭＤ）アルゴリズムとを使用して、データ転送速度を調節する、ように構成されている。いくつかの実施形態では、ネットワークは、少なくとも１つのイーサネットリンクを有する。いくつかの実施形態では、複数の演算ノードは、送信者ノードと受信者ノードとを含む。いくつかの実施形態では、初期データ転送速度を設定することは、帯域遅延積と等しい初期ウィンドウを設定すること、かつ、初期ウィンドウを設定することの後輻輳が検出されない場合に、ウィンドウサイズを上昇させる、をさらに含む。いくつかの実施形態では、初期データ転送速度は、イーサネットリンクのライン速度と等しい。いくつかの実施形態では、閾値待ち時間は、データパケットの送信のためのラウンドトリップタイムに基づく。いくつかの実施形態では、最小データ転送速度は、初期データ転送速度の少なくとも１パーセント未満である。いくつかの実施形態では、フィードバック制御ループは、比例－積分コントローラを含む。いくつかの実施形態では、データを最小データ転送速度で送信者から受信者に転送することは、輻輳通知パケットを受信者から送信者に送ること、および、送信者が輻輳通知パケットを受信した際に、速度を更新することを含む。いくつかの実施形態では、一方向の待ち時間を継続的にモニタリングすることは、受信パケットのバイトの合計数のトラッキングを維持することを含む。いくつかの実施形態では、管理された転送速度は、最小転送速度での１期間と初速度の半分での１期間の後に計算される。いくつかの実施形態では、期間は、送信パケットのラウンドトリップタイムに基づく。いくつかの実施形態では、初期転送速度は、送信者と受信者との間のライン速度に基づく。いくつかの実施形態では、初期転送速度は、送信者と受信者との間の最小ライン速度である。いくつかの実施形態では、ＡＩＭＤアルゴリズムは、管理速度が閾値を下回る場合に、管理速度に対して加法を実施し、管理速度が閾値を上回る場合に、管理速度に対して乗法を実施することを含む。いくつかの実施形態では、加法は、正の数によるものである、いくつかの実施形態では、乗法は、０と１との間の数によるものである。

【0006】

さらに別の態様では、ネットワークプロトコル中の輻輳を管理するコンピュータ実装された方法が、開示される。方法は、データ速度を初期速度に設定すること、および、送信者と受信者との間で、受信者が輻輳イベントを検出するまでデータ転送を実施することを含む、高速開始段階を含む。方法はまた、ある期間にわたり、データ速度を最小データ速度に低下させること、およびその後に、ある期間にわたり、データ速度を初速度の半分に増加させることを含む、移行段階を含む。方法はまた、フィードバック制御ループと加法減少乗法増加アルゴリズムとの組み合わせを使用して、データ速度を修正することを含む、調整段階を含む。いくつかの実施形態では、コンピュータ実装された方法は、高速開始段階の前に、送信者と受信者との間でクロック速度とライン速度とを共有することを含む、初期設定フェーズを、さらに含む。いくつかの実施形態では、コンピュータ実装された方法は、高速開始段階の前に、データパケットを送信するために、ウィンドウサイズを初期ウィンドウサイズに設定する工程を、さらに含む。いくつかの実施形態では、コンピュータ実装された方法は、輻輳イベントがネットワーク内で検出されないない間は、ウィンドウサイズを増加させる工程を、さらに含む。いくつかの実施形態では、ウィンドウサイズは指数関数的に増加される。移行段階は輻輳イベントの検出後に始まる。いくつかの実施形態では、フィードバック制御アルゴリズムは比例積分アルゴリズムである。いくつかの実施形態では、フィードバック制御ループは、現在速度、比例項、および積分項の間の差異として説明されてもよい。いくつかの実施形態では、比例項は、現在待ち時間と閾値待ち時間との間の差異を説明し、他方、積分項は、現在待ち時間と以前の待ち時間との間の差異を説明する。いくつかの実施形態では、乗法増加は、確率イベントに対応して実施される。いくつかの実施形態では、乗法増加は、フィードバック制御ループより低い周波数で実施される。

【0007】

さらに別の態様では、ネットワーク中のネットワーク輻輳を管理するためのシステムが開示される。システムは、複数の演算ノードを含む。演算ノードは、１以上の以前に取得された待ち時間値および命令のセットを格納するためのメモリを含む。演算ノードはまた、１以上のプロセッサであって、命令のセットが、データ速度を初期速度に設定すること、および、送信者と受信者との間で、受信者が輻輳イベントを検出するまでデータ転送を実施することを含む、高速開始段階と、ある期間にわたり、データ速度を最小データ速度に低下させること、およびその後に、ある期間にわたり、データ速度を初速度の半分に増加させることを含む、移行段階と、フィードバック制御ループと加法減少乗法増加アルゴリズムとの組み合わせを使用して、データ速度を修正することを含む、調整段階と、を実装するように当該命令のセットを実行するように、構成される、１以上のプロセッサ、を含む。いくつかの実施形態では、システムは、高速開始段階の前に、送信者と受信者との間でクロック速度とライン速度とを共有することを含む、初期設定フェーズを、さらに含む。いくつかの実施形態では、システムは、高速開始段階の前に、データパケットを送信するために、ウィンドウサイズを初期ウィンドウサイズに設定することを、さらに含む。いくつかの実施形態では、システムは、輻輳イベントがネットワーク内で検出されていない間は、ウィンドウサイズを増加させることを、さらに含む。いくつかの実施形態では、ウィンドウサイズは指数関数的に増加される。いくつかの実施形態では、移行段階は輻輳イベントの検出後に始まる。いくつかの実施形態では、フィードバック制御アルゴリズムは、比例積分アルゴリズムである。いくつかの実施形態では、フィードバック制御ループは、現在速度、比例項、および積分項の間の差異として説明されてもよい。いくつかの実施形態では、比例項は、現在待ち時間と閾値待ち時間との間の差異を説明し、他方、積分項は、現在待ち時間と以前の待ち時間との間の差異を説明する。いくつかの実施形態では、乗法増加は、確率イベントに対応して実施される。いくつかの実施形態では、乗法増加は、フィードバック制御ループより低い周波数で実施される。

【図面の簡単な説明】

【0008】

本主題の新規の特徴は、添付の特許請求の範囲において、具体的に説明されている。本主題の特徴と利点についてのよい良い理解が、本主題の原理が利用される、例示的実施形態を説明する以下の詳細な説明と、添付の図面（以下図（「Ｆｉｇｕｒｅ」および「ＦＩＧ．」））とを参照することによって、得られるであろう。

【図1】リンクを通じての通信を示す例示的なブロック図である。

【図2】本明細書に記載される実施形態に係る、輻輳管理システム中で測定される、複数の変数を概略的に示す。

【図3】物理層リンク中の輻輳管理の方法のためのフロー図を示す。

【図4】通信のための最適作動点を示す；

【図5】開示される方法の待ち時間の、ＤＣＱＣＮとの比較を、両方法で実施された実験からのデータを使用して示す。

【図6A】図５の実験からのネットワーク中の、データフローの図を示す。

【図6B】図５の実験からのネットワーク中の、データフローの図を示す。

【図7A】開示される方法とＤＣＱＣＮとの間のキュー占有率の比較を示す。

【図7B】開示される方法とＤＣＱＣＮとの間のキュー占有率の比較を示す。

【発明を実施するための形態】

【0009】

開示される方法は、例えば、イーサネットネットワーク中のリンク層における、ＲｏＣＥｖ２ネットワーク中の輻輳を効果的に管理する。方法は、送信者ノードと受信者ノードとの間の通信に実装されてもよく、それらは、１以上のネットワークリンクによって接続されてもよい。送信者と受信者は、多数のユーザーからのデータフローを管理してもよく、また、リンクを通じてデータを送信する多数のユーザー間の送信データの効率性とフェアネスを維持しなければならないかもしれない。

【0010】

開示されたる方法は、３つの主要な段階、高速開始段階、移行段階、および調整段階、を有する。高速開始段階では、送信者と受信者は、受信者が輻輳イベントを記録するまで、データを初速度で互いに送信してもよい。輻輳イベントは、受信者の観点で測定された待ち時間中のスパイクとして、検出されてもよい。輻輳イベント後に、移行段階が始まる。移行段階では、輻輳を管理するために、送信者は、最初に、データ速度を期間の最小速度に低下させ、次に、データ速度を初速度の半分に増加させる。移行段階後に、調整段階が、フィードバック制御と加法増加乗法減少（ＡＩＭＤ）アルゴリズムとの組み合わせを使用して、低待ち時間、効率性、およびフェアネスを維持しながら、速度を増加させる。

【0011】

フィードバック制御ループは、調整段階で主要速度計算を誘導し、そこで、速度の増減が、例えば比例－積分アルゴリズムを使用して、精密にチューニングされる。ＡＩＭＤアルゴリズムは、フローが長期間にわたってリバランスする、小さな動揺を加える。これは、データパケットの輻輳キューに対する合計到達速度に、混乱を多く与えすぎることなく、行われる。

【0012】

調整段階の後、送信者と受信者は、最終的に、初速度でのデータ送信を再開してもよい。方法は、次の輻輳イベントが検出された時に、再開してもよい。

【0013】

一態様では、本開示の方法とシステムは、待ち時間のばらつきの測定に基づいて、ネットワーク輻輳状態を判定するために提供される。待ち時間測定は、ラウンドトリップタイム（ＲＴＴ）遅延などの、フォワードパス待ち時間、またはラウンドトリップタイム待ち時間であってもよい。待ち時間のばらつきまたは変化は、輻輳シグナルとして使用されてもよく、このように、送信者は、輻輳の範囲について、折よく通知されてもよい。

【0014】

図１は本明細書に記載される主題の実施形態に係る、リンク（１０３）を通じての通信を示す例示的なブロック図である。送信者（１０１）と受信者（１０５）は、リンク（１０３）を通じて通信している。本明細書に記載される例では、システムは、特定の送受信タスクを、送信者と受信者に委任する。しかし、パケットは、送信者から受信者に、または受信者から送信者に、送信することができる。通信は、輻輳を制御するために、輻輳管理メカニズムを使用してもよい。場合によっては、リンクに沿ったネットワーク輻輳の状態が判定されてもよい。送信者と受信者はまた、それぞれ、起点および宛先と呼ばれてもよい。他の場合では、ラウンドトリップ（送信者から受信者、そして送信者に戻る）のためのネットワーク輻輳が判定されてもよい。

【0015】

送信者（１０１）と受信者（１０５）は、パソコン、タブレットコンピュータ、スマートフォン、セットトップボックス（ｓｅｔ ｔｏｐ ｂｏｘ）、デスクトップコンピュータ、ラップトップ、ゲーム用システム、サーバ、データセンター、および様々な他のデバイスまたはシステムなどの、様々なタイプのコンピューティングデバイスであり得る。複数の他のデバイスまたはコンポーネントは、ネットワークを通じて接続を確立することができる。１以上の送信者は、１以上の受信者に接続することができる。送信者と受信者は、有線接続および／または無線接続で、ネットワークに接続することができる。送信者または受信者は、ネットワーク中の起点ノードと宛先ノードと呼ばれてもよい。ノードは、通信能力を備えた任意のデバイスであってもよい。通信は、有線通信あってもよく、無線通信であってもよい。

【0016】

送信者と受信者は、それぞれ、メモリ（１２０）とＣＰＵ（１３０）とを有する。受信者は、ＲＤＭＡを使用して、送信者のオペレーティングシステムを迂回する一方で、送信者のメモリに格納されたアイテムにアクセスしてもよい。

【0017】

リンク（１０３）は、無線ネットワーク、有線ネットワーク、またはその両方の組み合わせであり得る。例えば、ネットワークは、ＩＳＰ、セルラー、ブロードバンドのケーブルプロバイダ等を通じての、インターネット、イントラネット、セルラーネットワーク、ホームネットワーク、パーソン・エリア・ネットワーク（ｐｅｒｓｏｎ ａｒｅａ ｎｅｔｗｏｒｋ）などの１以上を含んでもよい。リンク（１０３）は、１以上のネットワークコンポーネント、データサーバ、接続ノード、スイッチなどの、インターネット・プロトコル・インターフェースと関連付けることができる。別の態様では、送信者（１０１）と受信者（１０５）は、リンク（１０３）の一部と見なすことができる。

【0018】

送信者（１０１）と受信者（１０５）の両方は、ネットワークインターフェイス（１４０）を含んでおり、それは、ネットワークインターフェースカード（ＮＩＣ）であってもよい。ネットワークインターフェースは、送信者ノードと受信者ノードがリンク（１０３）に連結することを可能にする。ネットワークインターフェース（１４０）は、スマート機能を有して、それらがネットワーク中のノードへのデータ送信速度を制御するためのアルゴリズムを実装することを可能にしてもよい。

【0019】

起点ノード（例えば送信者）から宛先ノード（例えば受信者）に送信されたデータパケット（１１１）は、リンクに沿って、遅延に陥るかもしれず、または陥らないかもしれない。いくつかの実施形態では、待ち時間のばらつきまたは変化の測定は、輻輳の範囲についての即時のシグナルを提供してもよい。待ち時間は、データパケット（１１１）の到着時間からデータパケット（１１１）の送信時間を減算することによって、計算されてもよい。いくつかの実施形態では、データパケットの送信時間は、送信者のクロック（１０７）によって提供され、そして、データパケットの到着／受信時間は、受信者のクロック（１０９）によって提供される。

【0020】

送信者クロック（１０７）と受信者クロック（１０９）とを同期する必要はない。場合によっては、送信者クロック（１０７）および／または受信者クロック（１０９）は、同期されていない自走クロックであってもよい。場合によっては、送信者クロック（１０７）と受信者クロック（１０９）は、同じ速度または周波数で作動している。代替的に、送信者クロック（１０７）と受信者クロック（１０９）は、異なる速度または周波数で動作してもよい。場合によっては、共通の速度または周波数は、接続確立時間において設定されてもよい。例えば、共通の速度または周波数は、データパケットの送信の前に接続プロトコルによって設定された、既定の周波数である。場合によっては、送信者と受信者に関連付けられた速度または周波数は、それぞれ、接続確立時に交換されてもよい。場合によっては、受信者は、送信者の速度または周波数によって通知を受けてもよい。代替的な場合では、送信者と受信者は、互いに未確認の異なる周波数で動作してもよい。例えば、送信者と受信者の両方が、ハンドシェーク要求（例えば、あるハンドシェークタイプの制御パケット）を接続設定時に送信し、ここで、ハンドシェークパケットは、送信者と受信者の両方がそれを使用して通信すると合意した共通周波数、または、送信者と受信者のそれぞれに関連付けられた周波数を、含んでもよい。クロック周波数または速度は、接続確立時間においてのみならず、いつでも送信することができることに留意されたい。例えば、クロックの周波数を含むハンドシェークパケットは、通知メッセージが生成される時、またはタイムアウトタイマーが時間切れになる時に、１間隔に１度で、送信することができる。クロックは、ＮＩＣハードウェア時間、またはホストデバイス（例えばＣＰＵ）クロックなどの、任意のタイプのローカルのハードウェアまたはデバイスのクロックを含んでもよい。送信者クロックと受信者クロックは、同じタイプでもよく、同じタイプでなくてもよい。いくつかの状況では、適合またはマッピングスキームが、ホストタイムスタンプへのマップＮＩＣタイムスタンプに対して使用されてもよい。いくつかの状況では、クロック周波数ドリフトが、送信者クロックと受信者クロックとの間で生じてもよく、その結果、待ち時間の変化に傾向をもたらす。周波数ドリフトの検出と更新は、本明細書で後に議論される。

【0021】

データパケット（１１１）が送信される時の現在時間を表わすタイムスタンプは、データパケット（１１１）に含まれていてもよい。タイムスタンプは、送信者クロックによって生成されてもよい。タイムスタンプは、データパケットの任意のフィールドに埋め込むことができる。タイムスタンプは、マルチビットであってもよい。タイムスタンプは、３２－ビットまたは６４－ビットなどの、任意のビット数を含んでもよい。タイムスタンプは、ピコ秒、ミリ秒、またはマイクロ秒の尺度で、時間分解能を提供してもよい。

【0022】

いくつかの実施形態では、各データパケット（１１１）に、タイムスタンプが押される。代替的に、データパケットのいくつかに、タイムスタンプが押される。例えば、送信時間を表わすタイムスタンプは、Ｘの数のパケットを全て含んでもよく、ここで、Ｘは、任意の整数であるかもしれない。

【0023】

タイムスタンプを含むデータパケットを受信する際、待ち時間は、受信者によって計算されてもよい。待ち時間は、受信者におけるローカルクロックの現在値からデータパケット中のタイムスタンプ値を（またはその逆を）減算することによって、判定されてもよい。受信者におけるローカルクロックの現在値は、送信者クロックと同期していないかもしれないので、差異は絶対待ち時間を表わさないかもしれない。したがって、時間差異は、擬似待ち時間と呼ばれてもよい。本開示では、「擬似待ち時間」および「待ち時間」という用語は等価であり、そして、「待ち時間」は、絶対待ち時間を表わすと解釈されるべきでない。

【0024】

待ち時間の差異または変化は、輻輳の範囲を予測するために使用されてもよい。待ち時間値の変化の差異は、遅延キューの変化を示してもよい。例えば、待ち時間値の増加による待ち時間の正の変化は、キューの上昇を示してもよく、その一方で、待ち時間の負の変化は、キューの減退を示してもよい。正の変化が検出される状況では、行列キュー（ｓｔａｎｄｉｎｇ ｑｕｅｕｅ）が形成するのを待つことなく遅延に対応し、従って、低待ち時間に関する方法を達成するのに有利である。負の変化が検出される状況では、送信速度を調節して、帯域幅を完全に利用するのに有利である。場合によっては、待ち時間の変化を待ち時間差異閾値と比較することによってなどで、待ち時間の変化が特定の範囲を超過していると判定された時には、通知メッセージが生成されてもよい。通知メッセージは、変化の増加または変化の減少が既定の待ち時間差異閾値を超過している時に、生成されてもよい。輻輳状態は、閾値を超える待ち時間の変化の検出を含んでもよい。輻輳状態は、待ち時間の測定された変化を含んでもよい。輻輳状態は、本明細書で後に議論されるような、待ち時間に関係する任意の他の変数をさらに含んでもよい。いくつかの実施形態では、輻輳状態の判定に際して、通知メッセージは、受信者によって生成されてもよい。通知メッセージは、待ち時間に関係する複数の変数を含んでもよい。

【0025】

図２は、本明細書に記載される主題の実施形態に係る、輻輳管理システム中で測定される複数の変数を、概略的に示す。送信者（２０１）と受信者（２０３）は、図１に説明されるように、ローカルクロック（２０５）、（２０７）にそれぞれ関連付けられていてもよい。送信者と受信者は、データパケット、制御パケット、通知パケットなどのメッセージを送受信するように構成されてもよい。図２に示されるように、１以上のデータパケット（２１１）、（２１７）、（２１９）は、送信者（２０１）から受信者（２０３）に送信されてもよい。場合によっては、１以上のデータパケットに、送信者のローカルクロック（２０５）によって、タイムスタンプが押されてもよい、送信者と受信者が通信システム中に描写されているが、任意の他のコンポーネントがシステム中に含まれ得ることに留意されたい。

【0026】

データパケットは、送信者または受信者から第１の時間で送信されてもよく、そして、送信者または受信者の他方によって第２の時間に受信されてもよい。第１の時間（例えばＴ１）と第２の時間（例えばＴ２）は、ローカルクロック（２０５）、（２０７）によって、それぞれ判定されてもよい。Ｔ４とＴ５またはＴ６とＴ７などの様々な時間時点が、同時におよび／または様々な順序で、生じる可能性がある。各通信が、１以上のパケットを含むことができる；しかし、読み易さを目的として、通信が、１つのコンポーネントから他のコンポーネントに送信された単一のパケットとして記載されていることに留意されたい。読み易さを目的として、通信が、オーバーラップしないものとして、そして様々なタイミングで描写されていることに、さらに留意されたい。さらに、内容に別段の示唆がない限り、いずれの通信もオーバーラップする可能性があり、異なる順序になる可能性があり、様々なネットワークコンポーネント（例えば中間ノード、スイッチなど）へと進められる可能性がある。送信者と受信者との間で、任意の異なる量のメッセージを送受信することができ；同様に、送信者と受信者は、図に示されていない様々な他のコンポーネントに／コンポーネントから、メッセージを送受信することができる。

【0027】

上述の様に、待ち時間の範囲は、待ち時間の変化に基づいて判定されてもよい。いくつかの実施形態では、待ち時間の変化が待ち時間差異閾値を超過したと判定された時に、通知メッセージ（２１５）、（２１６）が生成されてもよい。場合によっては、新しい間隔（２２７）が、通知メッセージの生成時に始まってもよい。場合によっては、新しい間隔（２２７）が、輻輳状態の検出時に始まってもよい。いくつかの場合には、新しい間隔が、以前の間隔からの最後のデータパケット（２１１）の受信時間または到着時間（例えばＴ２）で始ってもよい。間隔は、マイクロ秒、ミリ秒、秒などの、任意の長さの時間を有することができる。

【0028】

図に示されるように、間隔における第１のデータパケットの待ち時間（２２１）が計算されてもよい。受信者（２０３）による第１のデータパケットの受信時に、受信者は、受信者におけるローカルクロックの現在値Ｔ４から、データパケット中のタイムスタンプ値Ｔ３を減算してもよい。待ち時間値が、送信者から受信者に送信される、１以上のメッセージまたはデータパケット（２１７）について計算されてもよい。待ち時間の差異または変化が、２以上のデータパケット間で計算されてもよい。

【0029】

場合によっては、待ち時間の変化は、現在待ち時間値と以前の待ち時間値との間の再差として計算されてもよい。以前の待ち時間値は、単一のパケットまたは多数の以前に取得されたパケットの平均の待ち時間値であってもよい。場合によっては、以前の待ち時間値は、間隔（２２７）の第１のパケット（２１３）の待ち時間値（２２１）であってもよい。場合によっては、以前の待ち時間値は、最小待ち時間値であってもよい。場合によっては、以前の待ち時間値は、第１の多数のパケットなどの多数の以前に取得された待ち時間値の平均であってもよく、または多数のパケットの移動平均であってもよい。場合によっては、以前の待ち時間値は、以前の間隔からのデータに基づいて生成されてもよい。以前の待ち時間値は、固定されていてもよく、または間隔（２２７）中に変動してもよい。例えば、受信者（２０３）によってトラッキングされた最小待ち時間値が以前の待ち時間値として得られる場合、以前の待ち時間値は、最小値が更新される時に、変動してもよい。例えば、データパケット（２１７）は、その後のデータパケットに対してその間隔中の最小待ち時間値（２２３）を有していてもよく、待ち時間の変化は、それぞれの待ち時間値と最小待ち時間値との間の差として計算されてもよい。同様に、第１のパケットの待ち時間値（２２１）が、間隔中のその後のデータパケットの全てに対して、以前の待ち時間値として得られる場合、待ち時間の変化は、それぞれの待ち時間値と第１のパケットの待ち時間値との間の差異として計算されてもよい。

【0030】

場合によっては、待ち時間の変化は、現在待ち時間値と以前の待ち時間値との間の差異として判定される。現在待ち時間値は、単一のパケットの待ち時間値であり得る。現在待ち時間値は、多数のパケットの移動平均であり得る。このことは、待ち時間測定中の瞬時スパイクを回避するという利点を提供してもよい。様々な他の方法またはアルゴリズムは、スパイクをフィルタリングするために使用することができる。場合によっては、待ち時間の変化は、現在待ち時間値と以前の待ち時間値とから導出された値であり得る。例えば、待ち時間の変化は無次元であるかもしれず、それは、以前の待ち時間値で除算された現在待ち時間値と（現在待ち時間値）によって除算された以前の待ち時間値との間の差である。

【0031】

場合によっては、間隔（２１９）中の最後のパケットは、待ち時間差異閾値を超える待ち時間の変化を有するパケットである。最後のパケットの現在待ち時間は、移動平均であってもよく、移動平均でなくてもよい。変化は、現在待ち時間値と以前の待ち時間値との間の差異の絶対値であってもよい。差異は、正であってもよく、負であってもよい。待ち時間差異閾値が充足される時に、通知メッセージ（２１６）が生成されてもよい。

【0032】

いくつかの実施形態では、待ち時間の変化は、受信者によって判定されてもよい。代替的に、待ち時間の変化は、送信者によって判定されてもよい。いくつかの実施形態では、ネットワーク輻輳の状態は、受信者によって判定されてもよい。代替的に、ネットワーク輻輳の状態は、送信者によって判定されてもよい。

【0033】

いくつかの実施形態では、通知メッセージは、受信者によって生成されてもよい。通知メッセージは、受信者から送信者に送信されてもよい。待ち時間の変化が待ち時間差異閾値を越えていると判定された時、通知メッセージが直ちに送信されてもよい（例えばＴ２で送信されたメッセージ（２１５））。通知メッセージは、間隔の終点よりも後の時点で送信されてもよい（例えばＴ９で送信されたメッセージ（２１６））。通知メッセージは、遅延キューの輻輳状態の増減を示す複数の変数を含んでもよい。いくつかの実施形態では、通知メッセージに含まれる情報の少なくともいくらかは、さらなる輻輳管理のために、送信者によって使用される。

【0034】

図３は、イーサネットリンクなどのデータリンク中の輻輳管理の方法のためのフロー図を示す。フロー図は、初期設定フェーズ、高速開始フェーズ、移行フェーズ、および調整フェーズを含む。方法は、送信者（１０１）と受信者（１０５）との間のデータ送信と共に、図１の環境で実装されてもよい。

【0035】

初期設定フェーズ（３１０）では、送信者と受信者は、互いのクロック速度とライン速度に関する情報を共有してもよい。この情報は、送信者と受信者が許容可能な待ち時間を判定することを可能にし、従って、変則的に大きな待ち時間値（例えば、特定の送信者と受信者との間のデータフローに対する特定の閾値を上回る値）を登録することによって、輻輳イベントを検出することができるようにする。

【0036】

高速開始フェーズ（３２０）では、送信者は、データを初速度で受信者に送信する。高速開始フェーズ（３２０）は、ウィンドウ成長フェーズに先行してもよく、ここで、送信者は、データパケットを送信するための初期ウィンドウサイズを設定してもよく、そしてネットワーク内に輻輳が検知されない限り、ウィンドウのサイズを増加させてもよい。初期ウィンドウサイズは、例えば、ライン速度にネットワーク内の最小伝播遅延時間を積算した、帯域遅延積に設定されてもよい。ウィンドウサイズが増加するにつれて、受信者は、輻輳を検知していないことを、周期的に、例えば受信データ５０キロバイトごとに、送信者にパケットを送信することによって、通知してもよい。ウィンドウが成長し得る最大サイズは、そのリンク速度にネットワーク内の伝播遅延の最大値を積算することによって、判定されてもよい。受信者は、送信者から受信するデータパケットに対して、一方向の待ち時間中のスパイクを観察することによって、輻輳イベントを検出してもよい。一方向の待ち時間中のスパイクは、パケットのラウンドトリップタイムより大きな遅延に相当してもよい。例えば、１５～２５マイクロ秒の遅延によって、受信者が輻輳イベントを登録してもよい。いくつかの実施形態では、受信者は、輻輳イベントを登録するために、最小待ち時間に対する待ち時間を測定してもよい。これらの実施形態では、受信者は、閾値待ち時間を構成してもよく、それを超えると、検出された待ち時間を輻輳イベントとして登録してもよい。

【0037】

送信者は、ウィンドウサイズを指数関数的に増加させてもよい。送信者はまた、一次の線形的に、対数的に、または階段的に、サイズを増加させてもよい。ウィンドウサイズは、閾値サイズが達成されるまで増加されてもよい。パケットは、ビットを使用してウィンドウサイズを増加するように、送信者にシグナルを送ってもよい。

【0038】

高速開始フェーズ（３２０）内のウィンドウ成長後に、送信者は初速度を設定する。初速度は、２５ＧＢｉｔ／ｓまたは１００ＧＢｉｔ／ｓなどのライン速度であってもよい。初速度は、送信者と受信者とを接続する物理的ネットワークのタイプ、送信者と受信者との間の物理的距離、および送信者と受信者の動作構成などの要因によって、影響を受けるかもしれない。送信者は、ウィンドウがオーバーロード状態でない限り、フルスピードでデータ転送量（ｔｒａｆｆｉｃ）を送信してもよい。受信者は、ＣＮＰパケットを使用して、送信者と通信してもよい。例えば、受信者は、ＣＮＰ－Ｗパケットを送って、受信者がライン速度でパケットを送信し続けることを通知してもよく、あるいは、輻輳イベントが検出される時に、ＣＮＰ－Ｒパケットを送信してもよい。

【0039】

受信者が輻輳イベントを検出する時、システムは、移行フェーズ（３３０）に入る。受信者は、送信者がデータ送信の速度を最小速度に引き下げるべきであることを示すビットを伴うパケットを、送信者に送信してもよい。最小速度は、初速度よりも著しく小さくてもよい。例えば、最小速度は、初速度よりも２桁～４桁小さくてもよい。システムは、１以上の期間にわたって移行状態にとどまっていてもよい。期間は、パケットのラウンドトリップタイム（ＲＴＴ）に基づいていてもよい。例えば、期間は、２５マイクロ秒であってもよい。このことは、システム中の輻輳を低下させるために実施される。特定の数の期間にわたって最小速度にとどまった後、システムは、データ転送速度を、初期転送速度の２分の１に増加させてもよい。受信者はまた、送信者と受信者との間のスループットを測定してもよい。スループットが初速度の２分の１の割合未満である場合、受信者は、測定されたスループットの半分で送信するように送信者に通知するパケットを、送信者に送信してもよい。送信者は、当該パケットを受信すると、送信速度を落としてもよい。

【0040】

システムは、２つの更新期間のための移行段階にとどまった後、調整段階（３４０）に移る。調整フェーズは、フィードバック制御アルゴリズムと加法増加乗法減少（ＡＩＭＤ）とを使用して、データ転送速度を修正してもよい。

【0041】

フィードバック制御アルゴリズムは、比例積分（ＰＩ）アルゴリズムであってもよい。フィードバック制御アルゴリズムはまた、比例アルゴリズムまたは比例－積分－微分（ＰＩＤ）アルゴリズムを使用して、実装されてもよい。ＰＩアルゴリズムは、効率と低待ち時間とを確実化してもよい。データ転送速度の計算は、現在待ち時間が閾値値（例えば最小待ち時間値）からどれほど離れているか、および、待ち時間キューが現在上方傾向なのか、または下方傾向なのかに基づいて、周期的に更新されてもよい。アルゴリズムの「比例」アスペクト（”ｐｒｏｐｏｒｔｉｏｎａｌ” ａｓｐｅｃｔ）は、待ち時間が高い場合に、アルゴリズムがデータ送信速度を低下させる可能性を高め、他方、アルゴリズムの「積分」アスペクト（”ｉｎｔｅｇｒａｌ” ａｓｐｅｃｔ）は、待ち時間キューが上方傾向にある場合に、データ送信速度を低下させる可能性を高めるように機能する。

【0042】

フィードバック制御ループは、次の式を使用して説明されてもよい。
Ｒ（ｎ＋１）＝Ｒ（ｎ）－α（Δ（ｎ）－θ）－β（Δ（ｎ）―Δ（ｎ－１））

【0043】

この式では、更新された速度Ｒ（ｎ＋１）は、現在速度Ｒ（ｎ）から比例項α（Δ（ｎ）－θ）と積分項β（Δ（ｎ）－Δ（ｎ－１））を減算することによって計算される。比例項は、現在待ち時間Δ（ｎ）と閾値待ち時間θとの間の差異に定数を積算して説明される。積分項は、現在待ち時間Δ（ｎ）と以前の待ち時間Δ（ｎ－１）との間の差異に異なる定数を積算して説明され、式に、待ち時間の上方傾向または下方傾向を組み込む。

【0044】

ＡＩＭＤアルゴリズムは、フィードバック制御アルゴリズムと共に作動して、システム中のフェアネスを確実化する。ＡＩＭＤアルゴリズムは、待ち時間が減少する場合に、データ転送速度に対して加法増加を実施してもよく、そして、待ち時間が増加する場合に、乗法減少を実施してもよい。この処理はデータフロー中のリンクにフェアネスを加え、また、待ち時間を制御するのに必要とされる尺度よりも長い尺度にわたって実施されてもよい。例えば、システムは、輻輳イベントが受信者によって検出されるまで、異なるデータフローの速度に対して加法増加を実施してもよい。その点で、システムは、輻輳を止めるために、乗法減少をデータ速度上で実施してもよい。この処理は、フローが等しいデータ速度を有するようになるまで、繰り返されてもよい。

【0045】

いくつかの実施形態では、加法増加は、システムが調整段階にある間、絶えず実施されてもよい。このことが生じている間、受信者は、ＣＮＰ－Ｒパケットなどのパケットを送信者に送信して、速度に対して加法増加を行ってもよい。乗法減少は、周期的に実施されてもよい。いくつかの実施形態では、システムは、特定回数の調整サイクル後に、乗法減少を実施してもよい。他の実施形態では、乗法増加は、「コイントス」などの確率イベントに応じて実施されてもよい。システムは、乗法減少の確率を「コイン」に割り当てて、パケット到着のたびに「コインを投げ」て、そのサイクル中に、速度に対して乗法減少を実施するか否かを判定してもよい。例えば、乗法減少の確率が３０％である場合、１０回のパケット送信中３回において、乗法減少が実施されるであろうことが期待されてもよい。

【0046】

システムは、フィードバック制御ループとＡＩＭＤループとを共同実施してもよい。ＡＩＭＤ処理は、フェアネスが長時間尺度にわって達成され得るため、フィードバック制御ループより低い周波数で実施されてもよい。ＡＩＭＤを周期的に、制御ループを実施するよりも低い頻度で実施することで、データフローがリバランスし、キューに到着するパケットの混乱を低下させることができるようになる。

【0047】

調整段階（３４０）は、データ送信が初期データ速度に戻るまで継続してもよい。システムが多数の期間にわたって初速度に戻る場合、システムは、高速開始処理（３２０）を再び始めてもよい。

【0048】

図４は、通信の効率性グラフ（４００）を示す。図は、リンク層のパケット負荷が増加するにつれて、グッドプット（単位時間あたりに送達された有用情報ビットの数）と輻輳バッファサイズ（４２０）がどのように増加するかを示す。図は、データ負荷がゼロから増加するにつれて、グッドプット（４１０）も一次の線形状に増加することを示す。パケット負荷（４５０）が増加して、容量（４４０）を超えると、曲線が一次の線形状から平坦状（ｆｌａｔ）に移行し、膝様屈折部（ｋｎｅｅ）を形成する。これは、最大のグッドプットと無視できる程度のキューを伴う、システムの最適作動点（４３０）である。下のグラフは、パケット負荷が増加して膝様屈折部を超える際のキューの積み上がりを示し、その理由は、この点の後は、全てのパケットがシステムによって送信される得るわけではないためである。グラフは、キューが積み上がるにつれて、大負荷であってすらなお、グッドプット（４１０）が高いままであることを示す。システムは、小さな行列キューで、最適に操作され得る。キューは、負荷が増加するにつれて指数関数的にサイズ増加するかもしれず、その理由は、待機状態のパケットは、新しいパケットがキューに追加される前には送信されないかもしれないからである。特定の負荷では、システムがそのような大きなキューの維持に対応することができないかもしれないため、パケットがドロップされてもよい。グラフは、開示される方法では、システムが膝様屈折部の近くで作動することを示す。

【0049】

図５は、開示される方法の待ち時間の、ＤＣＱＣＮとの比較（５００）を、両方法で実施された実験からのデータを使用して示す。図５の実験では、ＤＣＱＣＮと開示される方法の両方について、２０，０００のデータフローが、ポアソン過程として受信者に到着する。フローは、１６の異なるポートから様々なラウンドトリップタイム（ＲＴＴ）で入信し、全て宛先は受信者である。受信者へのパケットの到着速度は、実験を実施するために制御され、ここで、送信者と受信者との間のリンクは、２０％、４０％、６０％、および８０％の負荷がかかる。ＤＣＱＣＮと当該方法の両方におけるこれらの１６のポートについて、イーサネットフレームの最小ポーズ時間、平均ポーズ時間、および最大ポーズ時間が測定される。グラフから確認できるように、高負荷では、ＤＣＱＣＮは、開示される方法と比較して性能が落ちる。実際、ＤＣＱＣＮのポーズ時間は、高負荷で指数関数的に悪化する。高負荷で比較すると、開示される方法では、高負荷であってもポーズフレームは生成されない。

【0050】

図６Ａと図６Ｂは、図５の実験からのネットワークにおける、データフローの図を示す。図６Ａの図（６００）は、開示される方法からのスループットを示し、他方、図６Ｂの図（６５０）は、ＤＣＱＣＮからのスループットを示す。図（６５０）は、顕著な犠牲フロー（ｖｉｃｔｉｍ ｆｌｏｗ）を示す。犠牲フロー、または低下スループットのフローは、データセンターネットワークにわたる輻輳の広がりを示す。従って、図６Ａと図６Ｂは、ＤＣＱＣＮが使用される時には顕著な輻輳の広がりを示すが、開示される方法が使用される時には無視できる程度の輻輳を示す。

【0051】

図７Ａと図７Ｂは、開示される方法（７００）とＤＣＱＣＮ（７５０）との間のキュー占有率の比較を示す。グラフは、システムで、ＤＣＱＣＮを使うよりも、キュー状態のデータが少ないことを示す。図７Ａと図７Ｂのチャートは、実験の結果を反映する。実験では、３段のデータセンターネットワークに６４０のノードが存在している。各ノードは、１対のトップオブラック（ｔｏｐ－ｏｆ－ｒａｃｋ）（ＴｏＲ）スイッチに接続された、２つの２５Ｇｂｐｓリンクを有する。ノード間のラウンドトリップ伝播遅延は、１２マイクロ秒である。ＰＦＣは有効化されている。６４０のノードは、１対のＴｏＲスイッチの下、データパケットを３２のノードの１グループに継続的に送信する。３２のノードの各々はまた、データパケットを他の６３９のノードに送信する。実験は、シミュレーションの途中で、３２のノードの１つに向かう１つのリンクを除去し、そしてそのリンクの除去が他のサーバにどのように影響するかを観察する。図７Ａと図７Ｂは、この実験からの輻輳リンクのキュー占有率を、開示される方法下とＤＣＱＣＮ下とで比較し、そして、開示される方法は、キュー占有率を、ＤＣＱＣＮ下でのもののわずか１０分の１に低下させることを示す。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6A】

【図6B】

【図7A】

【図7B】

【国際調査報告】