知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2024-02-26
(54)【発明の名称】プッシュ型データ通信のためのシステム及び方法
(51)【国際特許分類】
H04L 45/85 20220101AFI20240216BHJP
H04L 43/0876 20220101ALI20240216BHJP
H04L 43/0864 20220101ALI20240216BHJP
H04L 12/66 20060101ALI20240216BHJP
H04L 47/50 20220101ALI20240216BHJP
H04L 43/0805 20220101ALI20240216BHJP
【ＦＩ】
H04L45/85
H04L43/0876
H04L43/0864
H04L12/66
H04L47/50
H04L43/0805
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2023542986
(86)(22)【出願日】2022-01-19
(85)【翻訳文提出日】2023-09-13
(86)【国際出願番号】 CA2022050077
(87)【国際公開番号】W WO2022155738
(87)【国際公開日】2022-07-28
(31)【優先権主張番号】63/139,286
(32)【優先日】2021-01-19
(33)【優先権主張国・地域又は機関】US
(81)【指定国・地域】
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｌｉｎｕｘ
２．ＦＲＡＭ
(71)【出願人】
【識別番号】517351983
【氏名又は名称】デジェロ ラブス インコーポレイテッド
(74)【代理人】
【識別番号】110001036
【氏名又は名称】弁理士法人暁合同特許事務所
(72)【発明者】
【氏名】ジー ダビッド プイ キョング
(72)【発明者】
【氏名】アザーム イマド
(72)【発明者】
【氏名】ジョーンズ ジョージ リチャード
【テーマコード（参考）】
5K030
【Ｆターム（参考）】
5K030GA02
5K030GA03
5K030GA11
5K030GA19
5K030HA08
5K030HD03
5K030JA11
5K030LB05
5K030MB02
5K030MB06
5K030MB09
5K030MB16
(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】
複数のネットワークコネクションを用いるパケット通信のためのシステムであって、１つ以上の監視されるパケット通信イベントを検知することに応答して、
前記複数のネットワークコネクションの各々の伝送容量を定義し、
入力キューが伝送に利用可能な未割り当てデータパケットを含むか、又は前記複数のネットワークコネクションのうちの１つ以上の更新された伝送容量が使い尽くされていないと判定することに応答して、
前記入力キューから前記未割り当てデータパケットのうちの１つ以上のデータパケットを要求し、
前記１つ以上のデータパケットを、利用可能な伝送容量を有する前記複数のネットワークの１つ以上の対応する出力キューに割り当て、
前記割り当てられた１つ以上のデータパケットを反映するように前記伝送容量を更新し、かつ
前記複数のネットワークの各ネットワークに対応する前記出力キューからの前記割り当てられたデータパケットを宛先デバイスに伝達するように構成された受信機と、
前記伝達された割り当てられたデータパケットを受信し、かつ
前記受信されたデータパケットを再構築するように構成された受信機と、を備える、システム。
【発明の詳細な説明】
【技術分野】
【0001】
相互参照
本出願は、２０２１年１月１９日及び２０２１年５月４日に出願された、両方ともＳＹＳＴＥＭＳ ＡＮＤ ＭＥＴＨＯＤＳ ＦＯＲ ＰＵＳＨ－ＢＡＳＥＤ ＤＡＴＡ ＣＯＭＭＵＮＩＣＡＴＩＯＮＳと題された、米国特許出願第６３／１３９２８６号及び第６３／１８３９５２号の非仮出願であり、これらの優先権を含む全ての利益を主張するものであり、これらは、参照によりその全体が本明細書に組み込まれる。
本出願は、２０２１年１月１９日及び２０２１年５月４日に出願された、両方ともＳＹＳＴＥＭＳ ＡＮＤ ＭＥＴＨＯＤＳ ＦＯＲ ＰＵＳＨ－ＢＡＳＥＤ ＤＡＴＡ ＣＯＭＭＵＮＩＣＡＴＩＯＮＳと題された、米国特許出願第６３／１３９２８６号及び第６３／１８３９５２号の非仮出願であり、これらの優先権を含む全ての利益を主張するものであり、これらは、参照によりその全体が本明細書に組み込まれる。
【0002】
本出願は、参照により、以下の出願全体を組み込むものである：
「ＰＡＣＫＥＴ ＴＲＡＮＳＭＩＳＳＩＯＮ ＳＹＳＴＥＭ ＡＮＤ ＭＥＴＨＯＤ」と題された、２０１７年１２月２１日に出願された、ＰＣＴ出願第ＰＣＴ／ＣＡ２０１７／０５１５８４号。
「ＰＡＣＫＥＴ ＴＲＡＮＳＭＩＳＳＩＯＮ ＳＹＳＴＥＭ ＡＮＤ ＭＥＴＨＯＤ」と題された、２０１７年１２月２１日に出願された、ＰＣＴ出願第ＰＣＴ／ＣＡ２０１７／０５１５８４号。
【0003】
「ＳＹＳＴＥＭ ＡＮＤ ＭＥＴＨＯＤ ＦＯＲ ＡＳＳＥＳＳＩＮＧ ＣＯＭＭＵＮＩＣＡＴＩＯＮ ＲＥＳＯＵＲＣＥＳ」と題された、２０１８年８月２２日に出願された、ＰＣＴ出願第ＰＣＴ／ＣＡ２０１８／０５１０１２号。
【0004】
「ＳＹＳＴＥＭＳ ＡＮＤ ＭＥＴＨＯＤＳ ＦＯＲ ＭＡＮＡＧＩＮＧ ＤＡＴＡ ＰＡＣＫＥＴ ＣＯＭＭＵＮＩＣＡＴＩＯＮＳ」と題された、２０２０年８月７日に出願された、ＰＣＴ出願第ＰＣＴ／ＣＡ２０２０／０５１０９０号。
【0005】
本開示の実施形態は、電子データパケット通信の分野に関し、より具体的には、実施形態は、複数のネットワークコネクションが利用可能であるプッシュ型データパケット通信のためのデバイス、システム、及び方法に関する。
【0006】
序論
複数の利用可能なネットワークコネクションを介したデータパケットの伝送のための既存のデータパケット通信ソリューションは、コネクションを通してデータパケットをどのように伝達するかを決定するための静的ルーティングロジックに依拠している。例えば、システムは、利用可能なコネクションの各々に対してタイマを採用することができ、それぞれのタイマを使用して、タイマに関連付けられたコネクション上での伝送のために、入力キューからパケットをいつプルするかを決定する。これらのソリューションは、これらのコネクションが、実装の単純さのために性能を交換する同様の動作特性及び可用性を有し、直近に計時終了したタイマとのコネクションを介した伝送について次の利用可能なデータパケットをスケジュールすることを仮定している。タイマ手法は単純であるが、特定の状況では計算効率が損なわれる可能性がある。
複数の利用可能なネットワークコネクションを介したデータパケットの伝送のための既存のデータパケット通信ソリューションは、コネクションを通してデータパケットをどのように伝達するかを決定するための静的ルーティングロジックに依拠している。例えば、システムは、利用可能なコネクションの各々に対してタイマを採用することができ、それぞれのタイマを使用して、タイマに関連付けられたコネクション上での伝送のために、入力キューからパケットをいつプルするかを決定する。これらのソリューションは、これらのコネクションが、実装の単純さのために性能を交換する同様の動作特性及び可用性を有し、直近に計時終了したタイマとのコネクションを介した伝送について次の利用可能なデータパケットをスケジュールすることを仮定している。タイマ手法は単純であるが、特定の状況では計算効率が損なわれる可能性がある。
【0007】
複数のネットワークコネクションを同様の動作特性を有するコネクションの複数のインスタンスとして扱う通信システム（例えば、ＬＡＣＰ、ＭＬ－ＰＰＰ）は、特定のネットワークが十分に利用されない場合があるか、又は過度に利用される場合があるため、複数のネットワークが異なる動作特性を有する場合、複数のコネクションのあまり効果的でない使用につながり得る。この使用の不的確さは、データパケット配信のより大きなレイテンシ、より信頼性の低いデータパケット配信、より高価なデータパケット配信、スループットの低下などをもたらし得る。
【0008】
コネクション管理ソリューションはまた、利用可能なコネクション又はこれらのコネクションの動作特性が経時的に変化するアプリケーションを処理する困難さに遭遇する。例えば、タイマベースのシステムは、各コネクションについてのタイマが独立して発動することから、ネットワーク性能の変化に不感応であり得るため、他の全てのコネクションのネットワーク性能を正確に見ているわけではない可能性がある。
【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】
ここで、実施形態は、例としてのみ、添付の図面を参照して説明される。
【図1A】プル通信システムの概略図である。
【図1B】いくつかの例示的な実施形態による、プッシュ通信システムの概略図である。
【図1C】いくつかの例示的な実施形態による、可用性に基づいて複数のネットワークにパケットをプッシュするためにデータパケットを伝送するための方法のフローチャートである。
【図1D】いくつかの例示的な実施形態による、コネクションメタデータに基づいてコネクションを順序付けるためのデータパケットを伝送するための別の方法のフローチャートである。
【図1E】いくつかの例示的な実施形態による、ネットワークにパケットを割り当てるためのネットワークの選択された順序に基づいてデータパケットを伝送するための更なる方法のフローチャートである。
【図1F】いくつかの例示的な実施形態による、データパケットのルーティングを制御するためのネットワークコネクションをソートするために使用されるディメンションを例示するプロセスフローである。
【図2】いくつかの例示的な実施形態による、異なる優先順位レベルのデータパケットをスケジューリングする概略図である。
【図6A】例示的な実施形態による、データパケット伝送を管理するためのインターフェースの対応するスクリーンショットを示す。
【図6B】例示的な実施形態による、データパケット伝送を管理するためのインターフェースの対応するスクリーンショットを示す。
【図6C】例示的な実施形態による、データパケット伝送を管理するためのインターフェースの対応するスクリーンショットを示す。
【図6D】例示的な実施形態による、データパケット伝送を管理するためのインターフェースの対応するスクリーンショットを示す。
【図6E】例示的な実施形態による、データパケット伝送を管理するためのインターフェースの対応するスクリーンショットを示す。
【図7】いくつかの例示的な実施形態による、データパケット伝送の図である。
【図8A】いくつかの例示的な実施形態による、単方向データパケット伝送の２つの図である。
【図8B】いくつかの例示的な実施形態による、確認応答に応答して行われるデータパケット伝送の２つの図である。
【図8C】いくつかの例示的な実施形態による、更なるデータパケットを送信するための確認応答を必要とせずに行われるデータパケット伝送の２つの更なる図である。
【図9A】いくつかの例示的な実施形態による、インフライトグッドプットデータの図である。
【図9B】いくつかの例示的な実施形態による、インフライトグッドプットデータの別の図である。
【図9C】いくつかの例示的な実施形態による、インフライトグッドプットデータの更なる図である。
【図10A】いくつかの例示的な実施形態による、コネクションが輻輳に遭遇しているデータパケット伝送を示す一連の図である。
【図10B】いくつかの例示的な実施形態による、コネクションが輻輳に遭遇することに応答した伝送容量の調整後のデータパケット伝送を示す一連の図である。
【図11】いくつかの実施形態による、コンピューティングデバイスの例示的な概略図である。
【発明を実施するための形態】
【0047】
伝送のための複数のコネクションが利用可能であり、代替的に混合されたルータ又は混合されたシステムと称される、データパケットを伝送するためのシステム、方法、及びデバイスが記載される。
【0048】
伝送のために複数の利用可能なコネクションを介してデータパケットを伝送するための既存のソリューションは、典型的には、「プル」型アーキテクチャとして実装され、データパケットは、複数の利用可能なコネクションに関連付けられた内部タイマなどの、デバイス又はシステムによって生成又は定義されるイベントに応答して伝送される。
【0049】
内部タイマは、様々なコネクションパラメータ（例えば、再送されたパケットの回復時間を低減するように構成されたタイマ持続時間）に応答し得るが、他の利用可能なコネクションのコネクションパラメータには応答しない。
【0050】
タイマイベントの独立性の結果として、プル型システムは、利用不足（例えば、タイマ値が長すぎる場合、アイドルコネクションをもたらす）、又は利用過剰（例えば、不十分な性能にもかかわらず、低信頼性のコネクションにデータパケットが割り当てられ得る）に悩まされる可能性があり、これにより、データパケットの配信におけるより大きなレイテンシ、低減されたスループット、低信頼性のデータパケット配信、より高価なデータパケット配信などがもたらされ得る。
【0051】
複数の利用可能なコネクションを介してデータパケットを伝送するためにプッシュ型アーキテクチャに従ってデータパケットを伝送する方法、システム、及びデバイスが本明細書で提案される。開示された方法、システム、及びデバイスは、監視される通信イベントに応答して、複数のコネクションの各々の動作特性（監視される特性）のサブセットを取得し、これらのコネクションの監視される特性に基づいて、伝送容量を有するように決定されたコネクションのいずれかへの伝送に利用可能なデータパケットを反復して割り当てるように構成されたスケジューラを含む。例示的な実施形態では、ネットワークの他の監視される特性を、データパケットに関連付けられた伝送要件と併せて使用して、データパケットをデータパケットの伝送要件にマッチするコネクションに割り当て得る。
【0052】
複数のコネクションが利用可能であるプッシュ型アーキテクチャでデータパケットをスケジューリングすることは、使用されてこなかった。典型的なマルチパスシステム（代替的に、混合されたコネクションシステムと称される）は、コネクションのフロー要件又は動作特性を考慮しないため、静的ベースでコネクションにパケット及びフローを割り当てる。例えば、マルチホーム型インターネットプロトコル（ＩＰ）ルータは、このルータの宛先ルーティングテーブルに対してマッチングする、パケットヘッダ内の宛先ＩＰアドレスに純粋に基づいて、コネクションにパケットを割り当てる。コネクション割り当てが頻繁に変化しない場合、プル型アーキテクチャを実装する方が簡単である。例えば、プッシュスケジューラによってコネクションにパケットの大規模なキューが割り当てられたが、コネクションがオフラインになったためにリコール又は再割り当てされなければならなくなった場合を処理する必要はない。
【0053】
提案された方法、システム、及びデバイスは、入力コネクションを通して入力ネットワークから１つ以上のデータパケットを含むデータフローを受信する。
【0054】
提案された方法、システム、及びデバイスは、リモートピアへの混合されたコネクションのセットを介してデータパケットを伝送する３ステージのデータパイプラインを含む。複数のコネクションを宛先とする新しいデータは、第１のパイプラインステージに渡され、そこで新しいデータがキューイングされ、その後、混合されたコネクションの各コネクションに関連付けられた第２のパイプラインステージに渡される。第２のパイプラインステージは、第２のパイプラインステージの基礎となるコネクションに関する統計をまとめ、パケットを第３のパイプラインステージに渡す。第２のステージは、パケットが次のパイプラインステージに利用可能であることを確実にするために、輻輳制御機能性及びパケットバッファリングを提供し得る。次いで、第３のステージは、場合によっては第２のステージによって提供されるペーシング又はタイミングヒントに従って、パケットをネットワークインターフェースに書き込む。
【0055】
別の実施形態は、次いでパケットを第３のステージのインスタンスに提供する単一の第２のステージインスタンスを有してもよく、第３のステージの各々は、物理インターフェースカードを共有するネットワークインターフェースのセットでパケットの伝送を管理する。パイプラインステージの各々の異なる数のインスタンスを伴う他の実施形態が存在し得る。
【0056】
図１Ａは、いくつかの例示的な実施形態による、プル通信システム１００Ａの概略図である。
【0057】
各コネクションタイマ（例えば、コネクション１１０Ａ、１１０Ｂ、及び１１０Ｎにそれぞれ関連付けられたタイマ１０８Ａ、１０８Ｂ、及び１０８Ｎ）がウェイクアップすると、コネクションタイマは、プルスケジューラ１３０を呼び出し、データパケットの入力キュー１０２からの伝送のためのデータパケットを要求する。データパケットを、バーストで要求することができ、バーストサイズは、各タイマの対応するコネクションの推定されるビットレートで２０ｍｓ（１／５０Ｈｚ）相当のバイトを公称上反映する。そのようなプルタイマに関連付けられた制限は、各タイマのウェイクアップ時に要求されたバイト数が、コネクションの完全な輻輳ウィンドウ（例えば、「容量」を表す）を反映しないことである。
【0058】
各タイマは独立して発動することから、プルスケジューラ１３０は、グローバルに最適なスケジューリング決定を行うために、全体的な伝送状態への可視性を有していない。例えば、コネクション１１０Ａは、地上ブロードバンドコネクションであってもよく、コネクション１１０Ｂは、帯域幅オンデマンド（ＢｏＤ）衛星コネクションであってもよい。コネクション１１０Ａは、経費、レイテンシなどの結果として、コネクション１１０Ｂよりも好ましい場合があるが、コネクション１１０Ｂタイマ１０８Ｂがウェイクしてプルスケジューラ１３０を呼び出すときに、プルスケジューラ１３０は、コネクション１１０Ａタイマ１０８Ａの次のウェイクアップ時間に対する可視性を有していない（タイマ１０８Ａは独立して発動することから）。プルスケジューラ１３０は、コネクション１１０Ａが入力キュー１０２内のデータパケットの全てを処理することができるかどうか、又は伝送を完了するためにコネクション１１０Ｂに更なるデータパケットを割り当て付けるべきかどうかを判定するための基礎を有していない。
【0059】
コネクション１１０Ｂが役立つ場合、プルスケジューラ１３０は、プルスケジューラ１３０のみがタイマへの可視性を含むため、伝送に利用可能なデータパケットのうちのいずれを伝送するためにいずれのコネクションが使用されるべきかを判定する手段を有していなくてもよい。
【0060】
データパケットは、コネクション全体にわたって伝送され、その後、コネクション１１４を介して受信機１１６によって受信される。受信機１１６は、伝送されたデータパケットを組み立てるためのシーケンサ１１８を含み、ローカルエリアネットワーク（ＬＡＮ）１２０を介して、組み立てられたデータパケットを更に伝送し得る。
【0061】
プル型アーキテクチャとは対照的に、提案されたシステムは、効率的なコネクション利用率を増加させるために特定のコネクションにデータパケットをスケジューリングすることが可能であり得る。
【0062】
図１Ｂは、いくつかの例示的な実施形態による、プッシュ通信システム１００Ｂの概略図である。例示的な実施形態では、システム１００Ｂは、多重化技法を使用して共有通信チャネルに多元接続（ＭＡ）を提供するコネクションタイプを集約するように設計されている。例えば、符号分割多元接続（ＣＤＭＡ）ネットワークにおける各ノードに割り当てられた直交符号は、それらのノードが周波数のセットを共有し、かつ互いに干渉することなく同時に伝送することを可能にする。
【0063】
これらの多重化技法を使用するコネクションタイプの特性は、ネットワークにおけるノードへの利用可能な容量の再割り振りが迅速であり、典型的には、何十～何百ミリ秒のオーダーであることである。例示的な実施形態では、システム１００Ｂは、この特性を念頭において設計されており、この時間スケールで利用可能なＷＡＮコネクションの間でトラフィックを再割り振りする。
【0064】
対照的に、帯域幅オンデマンド（ＢｏＤ）としても知られる、要求割り当て多元接続（ＤＡＭＡ）技法を使用するコネクションは、ノードに一定期間チャネルへのアクセスをネゴシエートさせることによって、通信チャネルを共有する。割り振られると、ノードは、ネゴシエートされた部分を専用に使用する。したがって、利用可能な容量の共有は、チャネルのネゴシエートされた部分を使用してシーケンシャルにノードを介して行われる。
【0065】
ＢｏＤコネクションを用いると、このネゴシエーションとその後のノード間の容量の再割り振りとは、典型的には、完了するのに秒のオーダー（一桁台中盤～二桁台前半）を要する。例示的な実施形態では、システム１００Ｂは、これらのタイプのコネクションを効果的に使用するための変更（本明細書に記載される）を必要とするであろう。
【0066】
長い再割り振り時間（関連付けられたパケット損失及び／又はレイテンシの増加を伴う）は、現在の実装態様では輻輳として解釈され、典型的な輻輳制御方法は、輻輳が検出されたコネクションに関する使用を減らして、これらのコネクションを過負荷にすることを回避する。しかしながら、ＢｏＤコネクションは、実際には、容量の増加した割り振りを要求し、かつ場合によっては取得するために、（少なくとも一時的に）反対の挙動を必要とする。
【0067】
システム１００Ｂは、伝送のために入力ネットワークから１つ以上のデータパケットを含むデータフローを受信する入力キュー１０２を含む。データフローの例は、ファイル転送、ビデオファイル転送、オーディオファイル転送、ボイスオーバーインターネットプロトコル（ＶｏＩＰ）通話、又は仮想プライベートネットワーク（ＶＰＮ）に関連付けられたデータパケットであり得る。
【0068】
入力キュー１０２はまた、（本明細書に記載されるような）スケジューラがＬＡＮ側クライアントから新しいパケットが到達するのと同じレートで入力キュー１０２にサービス提供することができない場合に、パケットにドロップポリシーを適用することを担う。このことは、典型的には、ＬＡＮクライアントが集約ＷＡＮ伝送容量よりも高いレートで伝送している場合に発生する。
【0069】
システム１００Ｂは、プッシュ型アーキテクチャに従って、に混合されたコネクションセットを介してリモートピアにデータパケットを伝送するための３つのステージを含み、ステージは、代替的に、パイプライン又はパイプラインステージと称される。
【0070】
第１のステージ１０４は、フロー分類エンジン１０４Ａ、スケジューラ１０４Ｂ（以降では、代替的に、プッシュスケジューラ１０４と称される）を含み、入力キュー１０２からデータパケットを受信し、第２のステージ１０６へと渡すためにデータパケットをキューイングする。例示的な実施形態では、第１のステージ１０４は、入力キュー１０２、フロー分類エンジン１０４Ａ、及びスケジューラ１０４Ｂの全てを含む。
【0071】
入力キュー１０２は、送信者のＬＡＮ側でクライアントから受信されたパケットをバッファリングし、場合によってはフロー分類エンジン１０４Ａを利用するか、又はフロー分類エンジン１０４Ａと協働することによって、データパケットをフローに分類する（代替的に、データパケットをフローにマッピングすると称される）ことを担う。入力キュー１０２は、データフローが第１のステージ１０４のスケジューラによって公正にサービス提供されることを確実にする。
【0072】
例示的な実施形態では、第１のステージ１０４、又は第１のステージ１０４の支援フロー分類エンジン１０４Ａは、コネクションへのデータパケットの割り当てに関連付けられたユーザ構成の設定の変更を監視するか、又は通知される。ユーザ構成の設定は、コネクションが優先順位レベルに、それらの優先順位レベルがアクティブになるべきであるときに、どのように割り当てられるべきかに関する情報、並びにフローに属するパケットに、特定の監視される特性を有するコネクションを好ませ得るユーザ構成可能なフロー分類ルールを含む（例えば、ビデオストリームクラスに属するパケットは、低レイテンシを有するコネクションを好み得るのに対して、ファイルダウンロードクラスに属するパケットは、より低い金銭的コストを有するコネクションを好み得る）。
【0073】
第１のステージ１０４は、混合されたリンクを含むＷＡＮコネクションに対応する（本明細書に記載されるように）複数のコネクション監視インスタンスの各々について、現在のメタデータ（例えば、動作特性）を定期的に通知される。このメタデータは、監視インスタンス１０６によって収集され、コネクションの推定されるボトルネック帯域幅、推定される最小ラウンドトリップ時間、最近の実際のラウンドトリップ時間、コネクションについての現在の輻輳ウィンドウ、及び以前に次のステージに送信されたパケットについての受信／損失ステータスを含み得る。このメタデータを使用して、第１のステージ１０４はまた、メタデータを拡張して、第１のステージ１０４がこのコネクション上でインフライトとしてスケジュールしたバイトの推定を追跡し、その合計を新しいバイト、再送バイト、又はダミー／プロービングバイトとして更に細分化してもよい。第１のステージ１０４によって収集及び追跡されたメタデータの全ては、監視される特性と称される。
【0074】
次いで、全ての利用可能な監視される特性を使用して、第１のステージ１０４は、パケットを次のステージに送信するべきかどうか、及びそうであれば、いずれのコネクションがパケットを受信するべきかを判定することとなる。コネクション監視インスタンスに提供されるパケットのセットは、（同じコネクション監視インスタンス又は異なるコネクション監視インスタンスのいずれかに）以前に送信されたパケットの複製を含み得る。代替的に、スケジューラは、所与のコネクション監視インスタンスが、そのインスタンスのコネクションが現在容量を有する場合であっても、パケットを受信するのに現在適格ではないと判定してもよい。特定のステージ３インスタンスへのパケットの割り当ては、この文書の他の箇所で議論される。
【0075】
第２のステージ１０６は、複数の利用可能なコネクションの各コネクションについてのコネクション監視インスタンス（例えば、コネクション１１０Ａ、１１０Ｂ、及び１１０Ｎにそれぞれ関連付けられたコネクション監視インスタンス１０６Ａ、１０６Ｂ、及び１０６Ｎ）を含む。第２のステージ１０６のコネクション監視インスタンスは、関連付けられたコネクションを監視し、動作特性と呼ばれるコネクションの性能（例えば、レイテンシ）に関連付けられた統計を判定又は取得する。第２のステージ１０６は、パケットが次のステージに利用可能であることを確実にするために、輻輳制御機能性及びパケットバッファリングを提供し得る。第２のステージ１０６は、各コネクション（例えば、出力キュー１０８Ａ、１０８Ｂ、及び１０８Ｎ）についての出力キューを含む第３のステージ１０８にパケットを渡す。次いで、第３のステージ１０８は、場合によっては第２のステージ１０６によって提供されるペーシング又はタイミングヒントに従って、パケットをネットワークインターフェースに書き込む。
【0076】
いくつかの実施形態では、第２のステージ１０６は、ＢｏＤコネクションのための帯域幅割り振りプロセスをよりよくサポートするために、１つ以上のＲ２ＲＩプロトコル（例えば、ＰＰＰｏＥ（ＲＦＣ５５７８）、Ｒ２ＣＰ、ＤＬＥＰ（ＲＦＣ８１７５））を実装し得る。
【0077】
第２のステージ１０６は、第１のステージ１０４からパケットを受信し、これらのパケットをローカルにキューイングし、かつパケットのグループをバーストとして次のパイプラインステージに提供することを担う。第２のステージ１０６はまた、ピア又は受信者から受信された確認応答に基づいて、第２のステージ１０６の関連付けられたコネクションについてのメタデータを追跡する。
【0078】
第２のステージ１０６におけるキューの目的は、伝送のためにネットワークデバイスに書き込むために次のパイプラインステージに利用可能なパケットが常にあることを確実にすることである。いくつかの実施形態は、各パケット情報の一部として優先順位メタデータを含んでもよく、その結果、第１のステージ１０４から到達する新しいパケットは、より高い優先順位のパケットにプリファレンスを提供するためにキュー内で再順序付けされてもよい。
【0079】
第２のステージ１０６が十分なパケットをバッファリングして、パケットが第３のステージ１０８に提供され得ることを確実にするために、第２のステージ１０６は、改変されたメタデータを第１のステージ１０４に提供し得る。例えば、いくつかの例示的な実施形態によれば、第２のステージ１０６は、第１のステージ１０４が、第３のステージ１０８が実際の輻輳ウィンドウパケットの書き込みを完了するときのために第２のステージ１０６でバッファリングされ得る追加のパケットを提供するように、より大きな輻輳ウィンドウを報告する（すなわち、「過度にアドバタイズする」）ことを選定し得る。
【0080】
第２のステージ１０６はまた、ＢｏＤコネクションにおける容量の割り振りの変更を容易にするために、改変されたメタデータを第１のステージ１０４に提供してもよい（すなわち、より高い容量を割り振るためにＢｏＤコネクションをトリガするために、第１のステージ１０４に、第１のステージ１０４がより高い容量を有するかのように、このコネクション上のパケットをスケジューリングさせる）。この改変されたメタデータは、より高い容量を異なる要求されたタイプ／優先順位に分解する情報を含み得る。例えば、ＢｏＤコネクションをプローブするために使用されるより高い増分容量は、プローブパケットがＢｏＤコネクションによってドロップされる可能性が高いことから、典型的には、冗長／ダミーパケットで構成されている。
【0081】
第２のステージ１０６から第１のステージ１０４への容量のアドバタイズ又は過度のアドバタイズは、必ずしも即時により高い増分容量についてのプロービングをもたらす必要はない。第１のステージ１０４は、最終的には、パケットがコネクションにどのように割り当てられるかについての決定を依然として行う。一実施形態は、第２のステージ１０６にＤＡＭＡ再割り振りプロセスを開始するように指示する前に、全ての非ＢｏＤコネクション上のＣＷＮＤが完全に消費される（又は完全な消費に近づく）まで待ち得る。
【0082】
第２のステージ１０６におけるキューはまた、基礎となるネットワークコネクションに何かが起こった場合に、前のステージへの障害の高速通知を可能にする。第３のステージ１０８に提供され、かつネットワークに書き込まれたパケットは、ネットワークインターフェースがその後ダウンを報告した場合でも、転送中であると仮定されなければならず、それらのパケットが失われたとマークされ得る前にタイムアウトが発生しなければならないことを意味する。しかしながら、依然として第２のステージ１０６でキューイングされているパケットは、コネクションがもはや利用可能ではないことが第２のステージ１０６に通知されると、即時に失われたとしてマークされ得、これにより、これらのパケットは、優先された再送のために即時に適格となる。
【0083】
第３のステージ１０８に渡される前に、いくつかの実施形態は、次のステージがいつコネクションを介して当該パケットを送信することを試みるべきかを示す公称タイムスタンプを各パケットに割り当てることによって、パケット伝送のレートを明示的にペーシングすることを試み得る。そのようなタイムスタンプは、ネットワークボトルネックリンクにおいて、又はネットワークボトルネックリンクの前に、ネットワーク輻輳を防止するために、コネクション（例えば、パケットが割り当てられているコネクション）の推定されるボトルネック帯域幅、及びパケットサイズに基づいて決定され得る。
【0084】
図２は、２００において、第２のステージ１０６が優先されるパケットをサポートする実施形態の一例を示す。図２では、キューの先頭が右側に表示され、キューの末尾が左側に表示されている。図２の上部（例えば、第１のステップ）では、第１のステージ１０４は、第２のステージ１０６のコネクション監視インスタンスに、優先順位付けされたパケットの新しいリストを提供する。図２の下部（例えば、第２のステップ）は、これらの新しいパケットが優先順位順に優先順位キューに追加されたことを示し、それにより、全ての優先順位１のパケットは、任意の優先順位２のパケットがデキューされる前にデキューされる。同じ優先順位のパケットは、シーケンス順序で保持される。
【0085】
図示されていない例示的な実施形態では、第２のステージ１０６は、次いでパケットを第３のステージのインスタンスに提供する単一のコネクション監視インスタンスを有し得、これらのインスタンスの各々は、物理インターフェースカードを共有するネットワークインターフェースのセットでパケットの伝送を管理する。パイプラインステージの各々の異なる数のインスタンスを伴う他の実施形態が存在し得る。
【0086】
メタデータ又はコールバックの形態のフィードバックが、ステージから前のステージに送信され得るか、又はステージが、システムの異なる部分から通知を受信し得る。これらのアクションのいずれかが、次のステージにパケットを送信するステージをトリガ（すなわち、プッシュ）し得る。
【0087】
第３のステージ１０８は、１つ以上のコネクション伝送インスタンス（例えば、コネクション１１０Ａ、１１０Ｂ、及び１１０Ｎにそれぞれ関連付けられたコネクション伝送インスタンス１０８Ａ、１０８Ｂ、及び１０８Ｎ）を介して、第２のステージ１０６からパケットを受信し、これらのパケットをネットワーク１１２に書き込む。いくつかの実施形態では、全ての第２のステージ１０６のコネクション監視インスタンスが、単一のコネクション伝送インスタンスにパケットを提供するか、又は各コネクション監視インスタンスが、コネクション伝送インスタンスに関連付けられ得る。
【0088】
第３のステージ１０８のいくつかの実施形態は、キューイングメカニズムを使用して、前のステージがパケットをいつ送信するべきかに関するヒントを提供することを可能にし得る。例えば、ヒントは、メタデータとしてパケットに関連付けられた「公称送信時間」の形態で生じ得る。送信される次のパケットが以後の公称送信時間を有する場合、第３のステージ１０８は、そのパケットを送信する前にその時間まで待つこととなる。緊急パケットは、緊急パケットを他のキューイングされたパケットよりも先に送信させ得る即時タイムスタンプでフラグ付けされ得る。非緊急パケットの飢餓を防止するために、いくつかの実施形態は、過去の公称送信時間を有する非緊急パケットの後に緊急パケットをキューイングし得る。
【0089】
いくつかの実施形態は、パケットが送信されたことを示すために第２のステージ１０６に対して通知をトリガするために使用され得るパケットメタデータの一部としてコールバック機能を含み得る。そのような通知を使用して、第２のステージ１０６から第３のステージ１０８にプッシュされるパケットの新しいバッチをトリガし得る。
【0090】
図３は、３００において、第２のステージ１０６によって提供されたパケットが、指定された時間の前に送信されないことを要求する「送信時」ヒント（公称送信時間）を含む実施形態の経時的な進行を示す。「送信時」が０の時間のパケットは、できるだけ早く送信されるべきである。図３は、これらのケースの全てについての例を例示している（例えば、緊急パケットについての過去の公称送信時間の使用、及びシステムが非緊急パケットの飢餓をどのように回避するか）。
【0091】
ｔ＝１で描示された状態では、第３のステージ１０８のインスタンスのパケットキューは、４つのパケットを含み、そのうちの３つは、現在、送信するのに適格であり、第２のステージ１０６のインスタンスは、４つの新しいパケットを提供するところであり、そのうちの第１のパケットは、シーケンス５（シーケンス順序５）を有し、即時に送信されるべきである。
【0092】
ｔ＝２で描示された状態では、新しいパケットは、第３のステージ１０８の優先順位キューに追加されている。この実施形態は、シーケンス５がキューイングされた時点で、シーケンス２が既に送信するのに適格であったため、シーケンス２を有するパケットの後に送信するためにシーケンス５でパケットをキューイングすることを選定したことに留意されたい。このようにして、パケットキューの先頭でパケットの順序をフリーズさせることは、即時に送信される新しい緊急パケットの一定のストリームが、最新の即時送信緊急パケットが到達するずっと前に送信するのに適格になった可能性があるにもかかわらず、非即時パケットが送信されるのを防止することができる場合に、飢餓を防止する。
【0093】
ｔ＝３で描示された状態では、第３のステージ１０８は、出力キューから最初の４つのパケットをデキューし、これらのパケットをネットワークインターフェースに提供した。現在、時間ｔ＝４まで送信するのに適格であるパケットがないため、第３のステージ１０８インスタンスは、ネットワークインターフェース上に現在書き込み容量がある場合であっても、時間がｔ＝４に進むまで、又は即時に又は時間ｔ＝３に送信されるべき新しいパケットが到達するまで、より多くのパケットを送信するのを待つ必要があろう。
【0094】
パケットは、各ステージが最適であると判定する時点で順番に、あるステージから次のステージに渡され得る。
【0095】
図１Ａと同様に、データパケットは、コネクション全体にわたって伝送され、その後、コネクション１１４を介して受信機１１６によって受信される。受信機１１６は、伝送されたデータパケットを組み立てるためのシーケンサ１１８を含み、ローカルエリアネットワーク（ＬＡＮ）１２０を介して、組み立てられたデータパケットを更に伝送し得る。
【0096】
システム１００Ａとは対照的に、プッシュ通信システム１００Ｂは、各コネクションに関連付けられた独立したタイマを含まず、代わりに、コネクション上へのパケットのスケジューリングは、集中したロケーションで行われ、各コネクションの監視される特性にアクセスするプッシュスケジューラ１０４を含み、タイマに基づく以外で発生する１つ以上の監視されるイベントに応答してアクティブ化されるプッシュスケジューラ１０４を含む。例えば、１つ以上の監視される通信イベントは、以前に伝送されたデータパケットの受信者からの確認応答／否定確認応答（ＡＣＫ／ＮＡＣＫ）、又は入力キュー１０２への新しいデータパケットの到達などを含み得る。
【0097】
例示的な実施形態では、伝送されているパケットの２０ｍｓのみではなく、コネクション（輻輳ウィンドウ）ＣＷＮＤ全体が、潜在的に、プッシュスケジューラ１０４によって消費されるか、又は割り付けられ得る。
【0098】
各コネクションの監視される特性へのアクセスを用いて、プッシュスケジューラ１０４は、パケットスケジューリング決定を最適化するように構成され得る。例えば、特定の伝送要件を有するデータフローは、タイマのウェイク順序に大部分基づいて割り当てられるのではなく、データフローに関連付けられた要件を満たすことができるコネクションに優先的に割り当てられ得る。例示的な一例では、第１のデータフローは、５０ｍｓ未満のレイテンシを有する伝送を必要とする。
【0099】
コネクション１１０Ａ、１１０Ｂ、及び１１０Ｎは、それぞれ、５ｍｓ、４５ｍｓ、及び８０ｍｓのレイテンシを有する。プルスケジューラ１３０を用いて、コネクション１１０Ｂ（４５ｍｓレイテンシ）のための５０Ｈｚタイマが最初にウェイクアップするとした場合、当該タイマは、コネクション１１０Ｂ上へのこの第１のデータフローのためのパケットをスケジューリングすることが可能になっているであろう。プッシュスケジューラ１０４を用いて、コネクション１１０ＡのＣＷＮＤがコネクション１１０Ｂ（４５ｍｓレイテンシ）上にオーバーフローする前に完全に消費されるまで、データフローをコネクション１１０Ａ（５ｍｓレイテンシ）上で優先的にスケジュールすることができる。
【0100】
双方向通信を可能にするために、マルチパスエンドポイントの単一のインスタンスは、図１Ｂに記載される全てのコンポーネントを含むことができる。具体的には、他のマルチパスエンドポイントへのアップストリーム通信をサポートするための送信者１００の１つ以上のインスタンスと、他のマルチパスエンドポイントからのダウンストリーム通信をサポートするための受信機１１６の１つ以上のインスタンスと、を含み得る。
【0101】
いくつかの実施形態によれば、例えば、利用可能なコネクションのうちの１つ以上は、ＢｏＤコネクションであり、プッシュスケジューラ１０４は、以下のような基準に基づいて、ネットワークからより多くの容量を要求するために、より多くのデータをＢｏＤコネクションに割り振ることができる。
【0102】
コネクション１１０ＡのＣＷＮＤが完全に消費されている（又は完全な消費に近づいている）一方、より多くのパケットが、（例えば、フローごとのルールに基づいて）コネクション１１０Ｂ上で伝送されるのに適格である入力キュー１０２で利用可能である。
【0103】
例示的な実施形態では、プッシュ通信システム１００Ｂは、入力キュー１０２に適用される、より正確／公正なサービス品質（ＱｏＳ）及びアクティブキュー管理（ＡＱＭ）パケットドロッピングルールを可能にすることができる。前述の例を再び参照すると、５０ｍｓのレイテンシ要件を有するフローは、決して８０ｍｓのコネクションを利用することができない。プッシュスケジューラ１０４は、システム全体の一貫したスナップショットを有することから、８０ｍｓのコネクションを除くフローの部分的な使用量及び総容量の公正なシェアを計算することができる。
【0104】
プッシュ型スケジューリング手法の潜在的な利点は、ターゲットコネクションに最適にパケットを割り当てるために、混合されたリンクを含む複数のコネクションについてのメタデータの完全なセットがプッシュスケジューラ１０４に利用可能であることである。
【0105】
図１Ｃは、いくつかの例示的な実施形態による、システム１００Ｂ又は他のプッシュ通信システムを使用してデータパケットを伝送するための方法１１０Ｃのフローチャートである。
【0106】
ブロック１１３０において、方法１００Ｃは、入力キューが伝送に利用可能な未割り当てデータパケットを含むときを検知する。
【0107】
ブロック１１３２において、方法１００Ｃは、未割り当てデータパケットの１つ以上のデータパケットを、好適な監視される特性を有する複数のネットワークの１つ以上の対応する出力キューに割り当てることを含む。
【0108】
ブロック１１３４において、方法１００Ｃは、割り当てられた１つ以上のデータパケットを反映するように、対応する複数のネットワークの監視される特性を更新することを含む。
【0109】
ブロック１１３６において、方法１００Ｃは、複数のネットワークの各ネットワークに対応する出力キューから割り当てられたデータパケットを宛先デバイスに伝達する。
【0110】
例示的な実施形態では、システム１００Ｂでデータパケットを伝送するための方法は、プッシュスケジューラ１０４が外部イベントによってトリガされるたびに、以下のステップのループを含む。
１．入力キュー１０２からのデータパケットを要求し、
２．受信されたパケットを伝送のためのコネクションに割り当て、
３．ａ）入力キュー１０２で利用可能なパケットがなくなるまで、又はｂ）アクティブなコネクションのいずれかに（例えば、輻輳ウィンドウ（ＣＷＮＤ）メトリックによって定義されるような）利用可能な伝送容量がなくなるまで、ステップ１～２を繰り返す。
１．入力キュー１０２からのデータパケットを要求し、
２．受信されたパケットを伝送のためのコネクションに割り当て、
３．ａ）入力キュー１０２で利用可能なパケットがなくなるまで、又はｂ）アクティブなコネクションのいずれかに（例えば、輻輳ウィンドウ（ＣＷＮＤ）メトリックによって定義されるような）利用可能な伝送容量がなくなるまで、ステップ１～２を繰り返す。
【0111】
記載される方法は、プッシュスケジューラ１０４が任意のデータフロー固有の要件を考慮しないように実装され得る。そのような実施形態では、システム１００Ｂは、コネクションの順序付けに基づいて、受信されたパケットを割り当てる。
【0112】
順序付けは、コネクションの監視される特性に基づくことができ、例えば、輻輳制御アルゴリズムによって推定される動作特性のサブセットを含み得る。一実施形態では、ＢＢＲｖ１アルゴリズムが使用されるが、他の実施形態は、ＢｏＤなどの特定のコネクションタイプを処理するための、ＢＢＲｖ２、ＴＣＰ Ｒｅｎｏ、ＴＣＰ ＬＥＤＢＡＴ、独自の実装態様などの例を含み得る。ＢＢＲｖ１に特有の動作特性に関する後続の議論では、例示的な目的のみで、２つのエンドポイントが一連の相互接続されたパイプとしてモデル化され、各パイプセグメントが異なる直径及び長さを有することができる、パイプアナロジーに言及する。
【0113】
動作特性は、伝送されたパケットが宛先エンドポイント（例えば、受信機）に到達し、（例えば、受信機から送信機へのＡＣＫメッセージを介して）確認応答されるのに必要とされる最小時間の尺度であり得る。この持続時間は、「ラウンドトリップ伝播遅延」（「ＲｔＰｒｏｐ」と略される）という名称であり、時間の単位（例えば、ミリ秒）で測定される。パイプアナロジーの観点では、この値は、送信機から受信機までの全てのパイプセグメントの全長を表す。
【0114】
動作特性は、最小の直径を有するパイプセグメントに沿ってエンドポイント間でデータが移動することができる最大レートであり得る。「ボトルネック」セグメントと称される最小のパイプ直径は、データが送信機と受信機との間で移動することができる最大レートを決定し、これは「ボトルネック帯域幅」（「ＢｔｌＢｗ」と略される）とも称される。例えば、ＢｔｌＢｗを推定するために使用される手法は、ＩＥＴＦドラフトに記載されている：ｈｔｔｐｓ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｄｒａｆｔ－ｃｈｅｎｇ－ｉｃｃｒｇ－ｄｅｌｉｖｅｒｙ－ｒａｔｅ－ｅｓｔｉｍａｔｉｏｎ－００。
【0115】
表１は、ＷＡＮコネクション及びＷＡＮコネクションの特性の例示的なセット、監視される特性になるようにスケジューラ１０４によって選定される動作特性の例示的なサブセット、並びに結果として生じるソート順序を示す。
表１：例示的なＷＡＮコネクション及びＷＡＮコネクションのソート順序
表１：例示的なＷＡＮコネクション及びＷＡＮコネクションのソート順序
【表1】
【0116】
この例示的な方法は、以下のディメンションにわたってコネクションをソートし、現在のディメンションがコネクション間で等しいと比較された場合にのみ、次のディメンションに移動する。
１．嗜好優先順位レベルを増加させる
２．ＲｔＰｒｏｐを増加させる
３．ＢｔｌＢｗを減少させる
４．インターフェース名を増加させる。
１．嗜好優先順位レベルを増加させる
２．ＲｔＰｒｏｐを増加させる
３．ＢｔｌＢｗを減少させる
４．インターフェース名を増加させる。
【0117】
ソートディメンションが頻繁に変更されることが期待されない全てのパラメータであることから、ソート操作の結果がどのようにコネクションの順序を比較的安定に保つかに留意されたい。
【0118】
この安定なソート順序は意図的なものであるため、入力キューに到達するパケットは、同じコネクションセット（リストの上部にソートされたもの）に対して「スティッキー」になる傾向があり、入力された要求が、より高くソートされたコネクションの総ＣＷＮＤを超える場合にのみ、ソート順序がより低いコネクションに上に「オーバーフロー」する。
【0119】
この例におけるソート基準がどのようにフロー固有でないかに留意されたい。例えば、管理者又はエンドユーザは、高優先順位のアプリケーションフローが計測されたセル１コネクション及びセル０コネクション（伝送要件の一例）を介して伝送されることのみを望む場合があり、それらのフローは、セル１及びセル０をリストのより下位に配置する、結果として生じるソート順序を望むであろうことを意味する。同様に、最大レイテンシ制限を有するいくつかのフローが存在してもよく、例えば、レイテンシが１５０ｍｓを超える場合、エンドユーザが対話型会話のために最大レイテンシ制限を使用不可能とみなすＶｏＩＰコールなどである。これらのフローについては、ＲｔＰｒｏｐを一次ソートディメンションとして使用する、結果として生じるソート順序を有することが望ましい場合がある。フロー特有であるようにソート基準を拡張する実施形態については、後続の段落で議論する。
【0120】
スケジューラはまた、パケットの再送信ポリシーを決定することを担う。例示的な実施形態では、システム１００Ｂは、パケットが受信機によって欠落していると報告された場合、スケジューラが常にパケットを再送のためにマーキングするように、構成されている。このことは、多くのフローにとって望ましいが、他のフローは、このことをまったく望まない場合がある（追加のレイテンシ又は潜在的に順不同で到達するパケットがアプリケーションによってパケットを使用不可能にするため）か、又は特定の期間内の再送試行のみを望む場合がある。
【0121】
図１Ｄは、いくつかの例示的な実施形態による、データパケットを伝送するための別の方法のフローチャートである。
【0122】
単純なスケジューリングループの一実施形態は、以下のとおりである。
１．コネクションメタデータの更新に必要な任意のアカウンティングを実行し、アクティブなコネクションのセットを判定する。
２．コネクションメタデータ（監視される特性）に基づいて、コネクションの好ましい順序付けを判定する。
３．送信するパケットがあり、アクティブなコネクションのセットに利用可能なネットワーク容量がある間：
ａ．送信される次のパケットを取得する。
ｂ．利用可能な容量を有する順序付けにおける最初のコネクションで送信されるパケットをキューイングする。
ｃ．スケジューリングされたパケットを反映するようにコネクションメタデータ（監視される特性）を更新する。
ｄ．繰り返す。
４．キューイングされたパケットを有する各コネクションについて、そのコネクションについての次のパイプラインステージにそれらのパケットを送信する。
１．コネクションメタデータの更新に必要な任意のアカウンティングを実行し、アクティブなコネクションのセットを判定する。
２．コネクションメタデータ（監視される特性）に基づいて、コネクションの好ましい順序付けを判定する。
３．送信するパケットがあり、アクティブなコネクションのセットに利用可能なネットワーク容量がある間：
ａ．送信される次のパケットを取得する。
ｂ．利用可能な容量を有する順序付けにおける最初のコネクションで送信されるパケットをキューイングする。
ｃ．スケジューリングされたパケットを反映するようにコネクションメタデータ（監視される特性）を更新する。
ｄ．繰り返す。
４．キューイングされたパケットを有する各コネクションについて、そのコネクションについての次のパイプラインステージにそれらのパケットを送信する。
【0123】
そのような実施形態は、コネクションの好ましい順序付けの目的で、全てのパケットを同等のものとして扱う。この場合、パケットを、フローの同じクラスに属すると考えることができる（別個のパケットが論理的に別個のフローに属し得るとしても、スケジューラの観点からは、コネクション割り当ての目的でこれらのフロー間に区別はない）。
【0124】
図１Ｅは、いくつかの例示的な実施形態による、データパケットを伝送する更なる方法のフローチャートである。
【0125】
異なるクラスのフロー（すなわち、ＩＣＭＰエコー要求／応答対ビデオストリーム対ファイル転送）間、及び更には同じクラス内の個々のフロー（ホストＡとホストＢとの間のビデオストリーム対ホストＡとホストＣとの間のビデオストリーム）間を区別することができるスケジューラの実施形態は、以下のように提供され得る。
１．ブロック１１０２において、コネクションメタデータの更新（監視される特性）について任意の必要なアカウンティングを実行し、アクティブなコネクションのセットを判定する。
２．アクティブなコネクションセットが容量を有する間（ブロック１１１４）、
ａ．ブロック１１０３において、現在アクティブなコネクションセットに基づいて、セレクタを構築する。
ｂ．ブロック１１０５において、セレクタを使用して、利用可能なコネクションのうちの１つを介して送信するパケットを選定する。パケットが選択されていない場合、ループを抜ける。
ｃ．ブロック１１０７において、コネクションメタデータ（監視される特性）と組み合わせて、パケットのフロー及びフロー分類に基づいて、アクティブなコネクションの順序付けを決定する。
ｄ．ブロック１１１０において、利用可能な容量を有する順序付けにおける最初のコネクションで送信されるパケットをキューイングする。
ｅ．ブロック１１１２において、スケジューリングされたパケットを反映するようにコネクションメタデータを更新する。
ｆ．繰り返す。
３．ブロック１１１６において、キューイングされたパケットを有する各コネクションについて、そのコネクションについての次のパイプラインステージにそれらのパケットを送信する。
１．ブロック１１０２において、コネクションメタデータの更新（監視される特性）について任意の必要なアカウンティングを実行し、アクティブなコネクションのセットを判定する。
２．アクティブなコネクションセットが容量を有する間（ブロック１１１４）、
ａ．ブロック１１０３において、現在アクティブなコネクションセットに基づいて、セレクタを構築する。
ｂ．ブロック１１０５において、セレクタを使用して、利用可能なコネクションのうちの１つを介して送信するパケットを選定する。パケットが選択されていない場合、ループを抜ける。
ｃ．ブロック１１０７において、コネクションメタデータ（監視される特性）と組み合わせて、パケットのフロー及びフロー分類に基づいて、アクティブなコネクションの順序付けを決定する。
ｄ．ブロック１１１０において、利用可能な容量を有する順序付けにおける最初のコネクションで送信されるパケットをキューイングする。
ｅ．ブロック１１１２において、スケジューリングされたパケットを反映するようにコネクションメタデータを更新する。
ｆ．繰り返す。
３．ブロック１１１６において、キューイングされたパケットを有する各コネクションについて、そのコネクションについての次のパイプラインステージにそれらのパケットを送信する。
【0126】
【0127】
第１の方法は、単一のフロークラスを定義し、かつ全てのパケットにマッチするセレクタを定義することによって、第２の方法に変換され得る。このことを考慮して、第２の方法（図１Ｅ）をより詳細に議論し、同じ議論が、上記の制限に従って、第１の方法（図１Ｄ）に適用可能であろう。
【0128】
第１のステップは、アクティブなコネクションのセットを判定するために、任意の保留中のメタデータアカウンティング（監視される特性）を更新することである。一実施形態では、アクティブなコネクションのセットは、信頼性がないコネクションバックオフ（すなわち、パケットを確実に配信するために、最近の失敗のために使用が制限されているコネクション）の対象とならないコネクションである。
【0129】
他の実施形態は、例えば、メタデータ（監視される特性）が現在定義されているフロークラス要件のいずれにもマッチしないコネクションを排除することによって、アクティブなコネクションのセットを更に制限し得る（すなわち、全てのパケットが１つの定義されるフロークラスにマッチしなければならないと仮定すると、コネクションが任意のフロークラスによって選択されることがない場合には、コネクションは、非アクティブとみなされ得、例えば、全てのフロークラスが最大５００ｍｓのＲＴＴを指定した場合、ＲＴＴ＞５００ｍｓのコネクションは、非アクティブとみなされ得る）。
【0130】
アクティブなコネクションのセットは、セット内の少なくとも１つのコネクションが、利用可能なＣＷＮＤ（輻輳ウィンドウ）を有する場合、パケットを送信する容量を有し、このコネクションについてスケジューラによって現在追跡されているインフライトバイト数が、このコネクションについて決定されたＣＷＮＤを超えないことを意味する。一実施形態では、コネクションのためのＣＷＮＤは、次のパイプラインステージによって報告されたＣＷＮＤであってもよいし、スロットリング又は優先順位ルーティングが有効である場合、スケジューラは、報告されたＣＷＮＤを低減することを選定してもよい。
【0131】
一実施形態では、特定のレートにスロットルされているコネクションは、ボトルネック帯域幅にわたってスロットルレートと同じ係数によってコネクションのＣＷＮＤを減少させる（又は、スロットルレートが帯域幅推定値よりも高い場合、ＣＷＮＤは、変更されない）。同様に、コネクションのＣＷＮＤは、このＣＷＮＤが優先順位ルーティングの対象となる場合、低減され得る（ここで、この実施形態は、より高い優先順位レベルの全てのコネクションの総グッドプット（オーバーヘッドを除くスループット）が、アクティブ化されるレベルのための構成された閾値を下回るときにアクティブ化される優先順位レベルへのコネクショングループ化をサポートする）。これらのシナリオにおけるＣＷＮＤ低減を決定するための様々な方法については、図８及び図９に関連して後述する。
【0132】
非アクティブである優先順位レベルに割り当てられたコネクション（より高い優先順位レベルの全てのコネクションについての総グッドプット＋未使用ビットレートは、優先順位レベルについてのアクティブ化ビットレートを満たすか、又は超える）は、ゼロの有効なＣＷＮＤを有し、非一次である優先順位レベルのコネクションは、現在アクティブな優先順位レベルのセット内の全てのコネクションの推定される総グッドプットビットレートが、最も低いアクティブな優先順位のアクティブ化閾値を満たすか、又は超える場合、これらのコネクションのＣＷＮＤをゼロに設定する。
【0133】
優先順位ルーティングを使用する他の実施形態では、非一次レベルのコネクションは、これらのコネクションが、構成されたアクティブ化閾値へのギャップを閉じるのに十分に寄与するだけであるように、これらのコネクションのボトルネック帯域幅よりも低いレートでキャップされ得る。このことを、例えば、非一次コネクションが緊急時にのみ使用されることを意図したより高価なコネクションである場合、コスト削減のために行うことができる。スロットリングと同様に、ＣＷＮＤは、これらのコネクションが送信されるべきキャップされたレートを反映するように低減される。
【0134】
方法のステップ２におけるループは、アクティブなセット内のコネクションが容量を有する限り、実行動作することができる。
【0135】
ステップ２ａ（ブロック１１０３）は、アクティブな容量を有するアクティブなコネクションのうちの１つで送信されるのに適格であるパケットを見つけるために使用されるセレクタを構築する。いくつかの実施形態では、セレクタは、容量を有する現在のアクティブなコネクションのセットと同等であるフロークラスのセットからなる。
【0136】
例えば、フロークラスが５００ｍｓの最大レイテンシを有するコネクションを必要とし、かつ利用可能な容量を有するアクティブなコネクションが全て５００ｍｓを上回るレイテンシを有する場合には、そのフロークラスは、セレクタから除外されるであろう。いくつかの実施形態は、実施形態が、そのようなパケットの基準を満たすコネクション（利用可能な容量の有無にかかわらず、アクティブ又は非アクティブ）が現在存在しないと判定することができる場合、アクティブなコネクションの基準に通常はマッチしないであろうフロークラスをセレクタに含めることを選定し得る。その場合、実施形態は、パケットがタイムアウトしてドロップされるまでパケットを保持するのではなく、パケットを送信することを支持するマッチ基準に違反することを選定し得る。他の実施形態は、適格なコネクションを有していないフロークラスにマッチするパケットが送信されることはない厳密なマッチポリシーを執行することを選定し得る。
【0137】
図１Ｆのプロセスフローにおける例示的なソート順序で示される別の実施形態では、様々なネットワークコネクションへのデータパケットのルーティングを制御するためのソート順序を計算で決定又は確立するための代替手法を利用することができる。
【0138】
入力パラメータのうちのいくつか又は全てを、ソート順序決定で使用される前に丸める／バケット化することができる。丸め及びバケット化からの技術的改善は、ソート順序の変化が常には発生しないように、ソート順序を可能な限り「安定」に保つことである（例えば、丸め及びバケット化がないと、２つのクローズ値は、それらの値が経時的に変動するにつれてソート変化を連続的に有することによって「ジッタ」を引き起こし得る。
【0139】
ソート順序の決定に影響を与える要因には、パケットが複数のＷＡＮコネクションに不必要に分割されないように、ソート順序を可能な限り「安定」に保つこと（分割は、自己誘発の順不同イベント及びジッタイベントの機械を増加させる）と、コネクションの測定される特性と測定されない外部ディレクティブとの両方を考慮することと、を含む。
【0140】
丸めるための値として、以下のものが挙げられ得る：。
●レイテンシ関連値（ＲｔＰｒｏｐ、ＲＴＴ）は、丸めから１ｍｓ後のフロアを施されて、５０ｍｓの最も近い倍数に丸められる。
●スループット関連値（ＢｔｌＢｗ）は、「最も近い桁」に丸められる。
●パケット損失（３つのスライディングウィンドウの間の最悪の値）は、最も近い桁に丸められる。ここでの未加工値は、範囲［０，１００］に制限されているため、出力値は、セット（０，１，２，３，４，５，６，７，８，９，１０，２０，３０，４０，５０，６０，７０，８０，９０，１００）に制限されていることに留意されたい。
●レイテンシ関連値（ＲｔＰｒｏｐ、ＲＴＴ）は、丸めから１ｍｓ後のフロアを施されて、５０ｍｓの最も近い倍数に丸められる。
●スループット関連値（ＢｔｌＢｗ）は、「最も近い桁」に丸められる。
●パケット損失（３つのスライディングウィンドウの間の最悪の値）は、最も近い桁に丸められる。ここでの未加工値は、範囲［０，１００］に制限されているため、出力値は、セット（０，１，２，３，４，５，６，７，８，９，１０，２０，３０，４０，５０，６０，７０，８０，９０，１００）に制限されていることに留意されたい。
【0141】
最も近い桁に丸める一例が、以下の表に提供されている。未加工値、未加工値の計算された桁数、次いで、結果として得られる丸め値が示されている。
【表2】
【0142】
ネットワークインターフェースの使用を制御するためのネットワーキングルーティング順序を改善することに基づく具体的な改善が、ラウンドトリップ時間（ＲＴＴ）及びパケット損失の複合特性を利用して、ＲＴＴ、パケット損失、及びＭＳＳを与えられたＴＣＰスループットの上限を確立するためのＭａｔｈｉｓ式に基づくスループットを予測するいくつかの実施形態に記載されている。Ｍａｔｈｉｓ係数を利用して、ネットワーク化されたパケットをルーティングするためのソート順序を修正することができる。
【0143】
測定される特性は、３つの別個のスライディングウィンドウ（５００ｍｓ、３ｓ、３０ｓ）の間のパケット損失（３つのウィンドウの間の最悪の値として更にまとめられる）、現在のネットワークラウンドトリップ時間（ＲＴＴ）、帯域幅ラウンドトリップ伝播時間（ＢＢＲｖ１）パラメータ、ＲｔＰｒｏｐ（ネットワーク伝播遅延）、及びＢｔｌＢｗ（スループット推定値）を含むことができる。外部ディレクティブは、とりわけ優先順位（ＰＲ）ルールを含むことができるが、フロー固有のルール／要件を含むこともできる。
【0144】
いくつかの実施形態では、ＢＢＲｖ１の測定される特性は、元のＢＢＲｖ１ ＩＥＴＦドラフトにおけるこれらの特性の設計とは異なる。例えば、実施形態の実行時間に一貫性に欠けるシステム上で実行され得る実施形態を考慮するために、ＢｔｌＢｗを計算するために使用されるスライディングウィンドウのサイズは、長い持続時間をカバーするために増加され得る（実行非一貫性に起因する可変性を隠す）が、ネットワーク損失又はレイテンシ増加イベントが発生した場合、それらのイベントは、ＢｔｌＢｗが実際に変更され得、かつスライディングウィンドウにおける任意の長い履歴を忘れなければならないことを示すことから、ウィンドウ持続時間もまた即時に短縮され得る。
【0145】
同様の実行非一貫性の理由で、ＲｔＰｒｏｐを測定するために使用される入力パラメータは、ネットワーク伝播遅延よりも多くを含むように変更され、実行／処理時間の一部分を追加し得、それは、その時間が、些末でない可能性があり、かつパケットを伝送して応答を待つときに遭遇する実際の遅延に一貫して寄与することによるいくつかの実施形態では、このことは、ネットワーク伝播遅延のみからなる「ネットワークＲｔＰｒｏｐ」とは対照的に、「システムＲｔＰｒｏｐ」と称される。これらの実施形態では、「システムＲｔＰｒｏｐ」及び「ネットワークＲｔＰｒｏｐ」は、意図された目的に応じて、様々な計算のために使用され得る。例えば、ＣＷＮＤを計算する際、パイプラインが処理遅延を考慮するのに十分なデータインフライトに含むように、「システムＲｔＰｒｏｐ」が適切である。しかしながら、パケットルーティングを決定するためにネットワークコネクションをソートする場合、好ましいルーティング決定がシステム実行遅延とは独立していることから、「ネットワークＲｔＰｒｏｐ」がより適切である。
【0146】
パケット損失、レイテンシ、及びスループットは、完全に独立した変数ではない。それらの３つの組み合わせは、アプリケーションの輻輳制御挙動に応じて互いに影響する。これは、例えば、ＴＣＰを用いると、より高いパケット損失は、送信者がＤＵＰ ＡＣＫ又はＲＴＯが発生するのを待つ際に、より長期間の無線「沈黙」（利用不足のチャネル）をもたらすからである。
【0147】
したがって、いくつかの複合属性が決定され、最終的なソート手法で使用される。具体的には、
Ｍａｔｈｉｓ係数：この複合属性は、ＲＴＴ及びパケット損失を考慮してスループットを予測し、ＲＴＴ、パケット損失、及びＭＳＳを考慮したＴＣＰスループットの上限を与えるＭａｔｈｉｓ関係（Ｍａｔｈｉｓ Ｒｅｌａｔｉｏｎ）に基づく。任意の２つのネットワークコネクションの属性を比較してこれらのネットワークコネクションのソート順序を決定する場合、ＭＳＳを定数とみなすことができるため、この関係は、期待されるスループットが（ＲＴＴ＊ｓｑｒｔ（パケット損失））の逆数に比例することを示している。この関係は、この例では、ネットワークコントローラ又はルータの動作を直接制御する際に利用される係数を確立するための実用的な実装態様として利用される。各コネクションについて、システムは、Ｍａｔｈｉｓ係数を以下のように決定する：ＭＡＸ（丸められたＲｔｔ，１ｍｓ）＊ｓｑｒｔ（丸められたまとめられたパケット損失）Ｍａｔｈｉｓ係数値が小さいコネクションほど良いとみなされる。計算は、２つの独立に測定される特性の関数であるため、これらの特性の間の関係は、コネクションが互いをどのように比較するかを決定する。Ｍａｔｈｉｓ係数は、各コネクションに関連付けられた対応するＭａｔｈｉｓ係数データ値などのデータオブジェクトに保持及び格納され、例えば、他の監視される特性とともにデータ値の配列に格納され得る。
Ｍａｔｈｉｓ係数：この複合属性は、ＲＴＴ及びパケット損失を考慮してスループットを予測し、ＲＴＴ、パケット損失、及びＭＳＳを考慮したＴＣＰスループットの上限を与えるＭａｔｈｉｓ関係（Ｍａｔｈｉｓ Ｒｅｌａｔｉｏｎ）に基づく。任意の２つのネットワークコネクションの属性を比較してこれらのネットワークコネクションのソート順序を決定する場合、ＭＳＳを定数とみなすことができるため、この関係は、期待されるスループットが（ＲＴＴ＊ｓｑｒｔ（パケット損失））の逆数に比例することを示している。この関係は、この例では、ネットワークコントローラ又はルータの動作を直接制御する際に利用される係数を確立するための実用的な実装態様として利用される。各コネクションについて、システムは、Ｍａｔｈｉｓ係数を以下のように決定する：ＭＡＸ（丸められたＲｔｔ，１ｍｓ）＊ｓｑｒｔ（丸められたまとめられたパケット損失）Ｍａｔｈｉｓ係数値が小さいコネクションほど良いとみなされる。計算は、２つの独立に測定される特性の関数であるため、これらの特性の間の関係は、コネクションが互いをどのように比較するかを決定する。Ｍａｔｈｉｓ係数は、各コネクションに関連付けられた対応するＭａｔｈｉｓ係数データ値などのデータオブジェクトに保持及び格納され、例えば、他の監視される特性とともにデータ値の配列に格納され得る。
【0148】
例えば、一方の極端な場合、パケット損失が０％の２つのコネクションは、常に同じＭａｔｈｉｓ係数を有するようになっており、これらのコネクションの実際のＲＴＴ値は、関係ない。このシナリオでは、Ｍａｔｈｉｓ係数は、ソート順序に影響せず、後続の測定される属性と複合属性との比較によって決定される。
【0149】
他方の極端な場合、２つのコネクションが１００％のパケット損失を有する（丸められたまとめられたパケット損失＝１．０）場合、これらのコネクションの丸められたＲｔｔ値のみが互いを比較する方法を決定するようになっている。いくつかの実施形態では、これは望ましくないため、パケット損失が１００％のコネクションは、より早い段階で利用可能な選定からフィルタリングされる。
【0150】
２つの極端の間で、低ＲＴＴ及び低パケット損失の両方を有するコネクションは、より高い値を有するコネクションよりも良好であると比較されるようになっている。しかしながら、損失が高パーセンテージであるコネクションは、依然として低いＲＴＴを有することによって補償することが可能であり、損失が低パーセンテージであるコネクションと同じＭａｔｈｉｓ係数を有することができる。例えば、
コネクションＡ：１００ｍｓＲＴＴ、０．０１（１％）損失＝＞Ｍａｔｈｉｓ係数＝１０
コネクションＢ：１９ｍｓＲＴＴ、０．２５（２５％）損失＝＞Ｍａｔｈｉｓ係数＝９．５
コネクションＡ：１００ｍｓＲＴＴ、０．０１（１％）損失＝＞Ｍａｔｈｉｓ係数＝１０
コネクションＢ：１９ｍｓＲＴＴ、０．２５（２５％）損失＝＞Ｍａｔｈｉｓ係数＝９．５
【0151】
この例では、コネクションＢが著しく高い損失（１％に対して２５％）を有していても、コネクションＢのより低いＲＴＴは、それを補償し、コネクションＡよりも良好なＭａｔｈｉｓ係数に匹敵させる。このための説明は、コネクションＢのより低いＲＴＴは、失われたパケットについてのパケット確認応答（肯定及び否定）を交換し、かつコネクションＡがより小さいパーセンテージの損失を有していても、より高いＲＴＴを有するコネクションＡよりも速く、任意の必要なパケット再送を完了することを可能にする。
【0152】
容量係数：この複合属性は、ＢｔｌＢｗ及びＲｔＰｒｏｐを考慮し、以下のように決定される：丸められたＢｔｌＢｗ／ＭＡＸ（丸められたＲｔＰｒｏｐ、１ｍｓ）。単位は、「ミリ秒当たりのバイト／秒」であり、物理的な意味はないが、ＲｔＰｒｏｐの単位当たりにコネクションが達成することができる帯域幅を正規化する方途を提供する。言い換えれば、コネクションのＲｔＰｒｏｐのミリ秒当たりにより多くの帯域幅を達成することができるコネクションは、より少ない帯域幅を達成するコネクションよりも効率的であるとみなされる。このコンテキストにおける効率的な伝送は、伝播遅延（ＲｔＰｒｏｐ）のミリ秒当たりにより多くの帯域幅を達成するコネクションを意味する。
【0153】
未加工入力の全てが処理され、かつ上述したように複合プロパティが計算されると、実際のソートメカニズムは、以下のように連続的に実行動作することができる。
【0154】
ある比較から次の比較への移行は、前の行の全てが等しいと比較された場合にのみ行われる。比較が等しくない場合、比較の残りは、無関係であり、省略される。いくつかの実施形態では、比較の選定は、フロー分類ベースで行われ（例えば、ＶＰＮ対ＶｏｉＰ対ｐｉｎｇパケット対ＦＥＣパケット）、各異なるフローについて、比較基準リストは、異なり得る（例えば、各々は、異なる予め定義された最も重要な特性、第２の最も重要な特性、第３の最も重要な特性などを有し得る）。コネクション自体をソートして順序シーケンスに入れることができるまで、これらの特性の各々を、最も重要なものなどから次々に反復することができる。いくつかの実施形態では、フロー分類に応じて、第１の事前ステップは、フロー分類におけるデータパケットのタイプを送信するのに好適であるコネクションのサブセットを選択することであり、次いで、パケット割り当てが実行される前に順序がそれらに付与される。
１．完全にダウンしているコネクション（１００％のまとめられた損失）は、１００％未満のまとめられた損失を有するコネクションよりも悪いコネクションとみなされる。
２．ＰＲ優先順位（優先順位が高いほど良好である）
３．Ｍａｔｈｉｓ係数（低いほど良好である）
４．丸められたＲＴＴ（低いほど良好である）
５．容量係数（高いほど良好である）
６．丸められたＲｔＰｒｏｐ（低いほど良好である）
７．丸められたＢｔｌＢｗ（高いほど良好である）
８．コネクションＩＤ（低いほど良好である）
１．完全にダウンしているコネクション（１００％のまとめられた損失）は、１００％未満のまとめられた損失を有するコネクションよりも悪いコネクションとみなされる。
２．ＰＲ優先順位（優先順位が高いほど良好である）
３．Ｍａｔｈｉｓ係数（低いほど良好である）
４．丸められたＲＴＴ（低いほど良好である）
５．容量係数（高いほど良好である）
６．丸められたＲｔＰｒｏｐ（低いほど良好である）
７．丸められたＢｔｌＢｗ（高いほど良好である）
８．コネクションＩＤ（低いほど良好である）
【0155】
ソートメカニズムのレンダリングを図１Ｆに示す。例示的なソートメカニズムでは、リアルタイムフローは、最初にＲＴＴ／ＲｔＰｒｏｐの比較を含み、次いで、等しい比較を含み、次いで、リアルタイムフローは、信頼性を比較し、次いで、やはり等しい場合には、伝送レートなどを比較する。フロータイプに応じて、異なるソート順序があり得る。例えば、スループットを望むフローは、最初に伝送レートを比較し得る。等しい場合には、信頼性で比較する。やはり等しい場合、リアルタイムフローは、他に何も評価せず、かつ単に随意に選定することを決定し得る。
【0156】
いくつかの実施形態では、フロー要件（例えが、リアルタイム対スループット）は、比較の順序及び数を決め得る。例えば、リアルタイムフローは、他の全ての属性を無視して、丸められたＲＴＴ及び丸められたＲｔＰｒｏｐのみを比較することを優先し得る。スループットフローは、Ｍａｔｈｉｓ係数と容量係数とのみを比較することを決定し得る。
【0157】
上述の手法は、明示的なソートディメンションに関する。また、典型的なアプリケーショントラフィックパターンの副産物として発生する傾向がある暗黙のソートディメンションもある。
【0158】
ほとんどのアプリケーショントラフィックは、バースト性又は適応性がある傾向があるため、全てのＷＡＮコネクションの使用を必要としない。このことは、現在ソート順序の最下位にあるコネクションは、これらのコネクションでトラフィックを伝送されない場合があることを意味する。これらのコネクションがそうではない場合、これらのコネクションの明示的なソートディメンションは更新されないため、これらのコネクションは、ソート順序の最下位近くにこれらのコネクションの位置を維持する傾向がある。
【0159】
いくつかの実施形態では、一定の期間にわたって、プッシュスケジューリングを、１つ以上の暗黙的なソートディメンションに沿ったソート順序を暗黙的に引き起こすように構成することもできる。暗黙的なソートディメンションは、周期的な不良イベント（例えば、輻輳に起因するレイテンシスパイク）に遭遇したコネクションを強制的にリストの最下位にバブルさせる。挙動に一貫性があるコネクションは、自然に最上位にバブルし、最上位付近に留まる。
【0160】
このことは、一般に、アルゴリズムの良い属性とみなされるが、将来的に外部要因によって影響されるように修正され得る。例えば、フローが、現在ソート順序の最上位に近いコネクションによって満たすことができない特定の要件を有する場合、最下位に近いコネクションでプロービングトラフィックを生成して、これらコネクションの明示的なソートディメンションをリフレッシュすることは理にかなっている場合がある。
【0161】
図４Ａは、４００Ａにおいて、予め定義されたフロークラス及び現在のコネクション状態を使用してセレクタが生成される実施形態を描示している。
【0162】
この例では、監視される特性のセットを各々が有する３つのコネクションがあり、マッチ基準及びマッチ基準を満たすコネクションをソートするためのプリファレンスを各々が定義する３つの予め定義されたフロークラスがある。
【0163】
この実施形態では、セレクタは、マッチ基準が利用可能な容量を有する少なくとも１つのコネクションにマッチするフロークラスのセットからなる。この例では、フロークラス１及びフロークラス２は、両方とも、コネクション１及びコネクション２にマッチするマッチ基準を有する一方、フロークラス３は、いずれのコネクションにもマッチせず、セレクタに含まれない。
【0164】
コネクション１及びコネクション２の両方がマッチしても、コネクション２は、利用可能な輻輳ウィンドウを有しておらず、現在パケットを送信することができないため、セレクタから除外される。セレクタを構築する際に、利用可能な輻輳ウィンドウを有するマッチするコネクションが見つかるとすぐにフロークラスを含めることができるため、一実施形態は、コネクション１のみを調べて、コネクション２がマッチすることを確認する必要なく、フロークラス１及びフロークラス２をセレクタに含めることができると判定し得る。
【0165】
ステップ２ｂ（ブロック１１０５）は、ステップ２ａからのセレクタを使用して、容量を有するアクティブなコネクションで（再）送信されるのに適格である再送キュー又は送信キュー上のパケットを見つける。そのようなパケットが見つからない場合には、ループが終了する。いくつかのアクティブなコネクションが容量を有し、入力キュー又は再送キュー上にパケットが存在する場合でも、このことが発生する可能性がある。
【0166】
図４Ｂは、４００Ｂにおいて、順序付けられたフローのセットである優先順位入力キューを有する一実施形態を示しており、ここで、キューの右側のフローは、左側のフローの前にパケットを送信すべきである。各フローは、フローＩＤを有し、各フローは、予め定義されたフロークラスのうちの１つに属する。各フローはまた、順序付けられたパケットのキューを含むため、フローが選定された場合には、キューの先頭にあるパケットが除去される。
【0167】
この例では、図４Ａからのセレクタを使用して、入力キュー内のフローを右から左に評価し、セレクタは、セレクタにリストされているフロークラスを有する最初のフローを選定する。この場合、ＩＤ５及びＩＤ２を有するフローは、これらのフローが両方とも、セレクタからのフロークラスのうちの１つではないフロークラス３を有するため、評価及び拒否される。次いで、フロー７が評価され、フロー７はセレクタにおけるフロークラスのうちの１つであるフロークラス１に属するため、マッチする。次いで、フロー７のパケットキューの先頭からパケットが抽出され、フローメタデータでスタンプされる。
【0168】
パケットが選択されると、ステップ２ｃ（ブロック１１０５）は、アクティブなコネクションの順序付けを構築する。選定される順序付けは、実施形態がそれをサポートする場合、又はそうでなければ一般に許容される順序付けで、フロークラスの定義で提供されるルールに基づくようになっている。いくつかの実施形態は、フロークラスにマッチする全てのフローについて同じ順序付けを使用し得、いくつかの実施形態は、順序付けをフロー依存にし得る（例えば、全てのフローが同じコネクションにスティッキーであることを必要とせずに、フロー内の全てのパケットを所与のコネクションにスティッキーにする）。順序付けは、ステップ２におけるループの各反復で必要に応じて構築されてもよいし、いくつかの実施形態は、順序付けを構築するために使用される基準が変更された場合（すなわち、メタデータ更新で）、順序付けをキャッシュし、かつキャッシュをクリアすることを選定してもよい。
【0169】
一実施形態は、コネクション上のパケットをスケジューリングすることによって容量をゼロに低減し得るか、又は異なるコネクション上のパケットをスケジューリングすることが、以前に使用されなかった優先順位レベルでコネクションのセットをアクティブ化するのに十分にメタデータミックスを変更することを起こす場合、ゼロの現在の値を上回って容量を増加させ得ることから、コネクションが現在容量を有するかどうかを無視して順序付けを構築する。このようにして順序付けを構築することで、変化する唯一の項目がコネクションについての有効なＣＷＮＤ及びインフライトバイトカウントである場合、順序付けをキャッシュ及び再利用することが可能になる。
【0170】
システム１００Ｂを横断するフローは、そのフローのパケットが可能なときはいつでも同じＷＡＮコネクションを横断する場合に、より良く挙動する傾向がある。したがって、一実施形態は、コネクションのうちの１つ以上の監視される特性が著しく変化しない限り、同じフローに対して作成された順序付けが一貫しているように、安定なソート基準を使用して順序付けを構築するのがよい。したがって、ＲＴＴ及びＲｔＰｒｏｐなどの動作特性、並びに帯域幅は、それらが短期間にわたって変動して、ソート順序を不安定にし得るため、不十分な選定である。
【0171】
「ノイズが多い」未加工の動作特性から監視される特性への変換は、統計的フィルタリング方法を使用して行われ得る。統計的フィルタリング方法は、平均、分散、ＡＮＯＶＡなどの従前の尺度から、（量子化された）ランク順序統計（ランク順序フィルタリング）の分野まで及び得る。例えば、監視される特性は、未加工の動作特性の範囲であり得、その範囲は、特定の値（例えば、１～１００ｍｓ）、又は桁数などによって定義され得る。具体的な例は、表２に示される例を含む、後続の段落に続く。
【0172】
いくつかの実施形態は、機械学習技法を使用して、動作特性から監視される特性に変換することができる。例えば、訓練されたモデルは、コネクションの差し迫った障害を予測するために開発され得、その結果、リストの最後にマッチするコネクションをソートする順序付けを構築することができる。別の例示的なモデルを使用して、コネクションのタイプ（例えば、有線、セルラ、ＷｉＦｉ、衛星、ＢｏＤなど）を検出し、それを使用して、リアルタイムで容易に測定することができない新しい監視される統計（例えば、バッファ肥大化に対する感受性）の基礎を形成することができる。
【0173】
一実施形態は、全てのパケットについて以下の順序を使用する（後の基準は、以前の全ての基準が等しい場合にのみ使用される）。
【0174】
「バケット化」されたドロップ確率。コネクションは、パケットカウントベース又はサイズベース（例えば、バイト単位）のドロップ確率の範囲によって定義されるバケットにグループ化され得る。ドロップ確率範囲がより小さいバケット内のコネクションは、順序付けの最初に現れ、ドロップ確率範囲がより大きいバケット内のコネクションは、順序付けの後の方に現れる。
【0175】
コネクション優先順位グループ（管理者又はエンドユーザによって提供される）。より高い優先順位のコネクションは、より早くランク付けされます（一次＞二次＞三次など）
【0176】
「バケット化された」ＲＴＴ。レイテンシは、５０ｍｓの最も近い倍数に丸められる。レイテンシ値のバケット化により、レイテンシの通常の変動を順序付けから隠すことが可能になると同時に、レイテンシの大幅な変化を順序付けに反映させることが可能になる。
【0177】
「容量係数」。これは、「１ミリ秒当たりの１秒当たりのバイト」で測定される集約値であり、ボトルネック帯域幅推定値を最も近い桁数又は最も近い桁数の整数倍に丸め（例えば、１から１に丸める、１０及び１１から１０に丸める、１５から２０に丸める、８６０００から９００００に丸める）、それを最も近い５０ｍｓにバケットされたＲｔＰｒｏｐで除算することによって計算される。ＲｔＰｒｏｐの１ｍｓ当たりのより高い帯域幅を達成するコネクションは、ＲｔＰｒｏｐの１ｍｓ当たりのより低い帯域幅を有するコネクションよりも良好であるとみなされる。
【0178】
未加工のＢｔｌＢＷ及びＲｔＰｒｏｐ値の容量係数を決定することは、高度に可変であるが、ＢｔｌＢＷを最も近い桁数又は最も近い桁数の整数倍に丸め、かつＲｔＰｒｏｐをバケット化することによって容量係数を安定化することは、大きな変化が観察されない限り、経時的に値を安定化する。表２は、バケット化、丸め、及び容量係数計算のいくつかの例を示す。この実施形態では、容量係数は、最も近い整数に丸められ、容量係数の計算の目的で、０のバケット化されたＲｔＰｒｏｐ値は、１として扱われることに留意されたい。
【0179】
「バケット化された」ＲｔＰｒｏｐ。最も近い５０ｍｓにバケット化されたＲｔＰｒｏｐのより低い値は、より高い値よりも好ましい。
【0180】
「丸められた」ＢｔｌＢＷ。より低い値よりも、最も近い桁数又は最も近い桁数の整数倍に丸められたＢｔｌＢＷのより高い値が好ましい。
【0181】
前述の基準の全てが等しいと比較される場合、コネクションＩＤ（コネクションが列挙されたときに割り当てられた）を使用して、決定論的に均衡を破る。他の実施形態は、より複雑なタイブレイクメカニズム、例えば、フローの属性を均衡するコネクションの数の整数モジュロにハッシュ化することを使用し得る。
表２：バケット化、桁数丸め、及び容量係数の例
表２：バケット化、桁数丸め、及び容量係数の例
【表3】
【0182】
フロータイプどうしを区別する一実施形態は、例えば、フロータイプの伝送要件に応じて、上記の順序を修正して、ファイル転送フローのためのより低レイテンシのコネクションよりも、高容量係数のコネクションを優先し、ビデオストリームのための高帯域幅コネクションよりも低レイテンシコネクションを優先し得る。
【0183】
コネクション（又はコネクションのセット）への厳密なフローピニングを実行する一実施形態は、コネクションＩＤの完全マッチのみを許可することを選定し得る（場合によっては、他のコネクションを順序付けから完全に除外する）。このようなピニングルールは、典型的には、管理者又はエンドユーザによって提供され、監視される特性によって決定される全ての順序付け決定をオーバーライドすることが意図されている。したがって、監視される特性が、コネクションが使用不可能であるか、又は失敗したことを示す場合であっても、フローは、同じ順序付けを継続することとなり、したがって、マルチパスシステム１００Ｂを通したコネクティビティを有さなくなる。
【0184】
いくつかの実施形態は、他の監視される特性又は動作特性の複合体である監視される特性を作成し、これらの複合材料を使用して、順序付けを決定し得る。例えば、バケット化されたドロップ確率、（実行中の）レイテンシ（ＲｔＰｒｏｐ）分散、及び（実行中の）スループットを組み合わせて、コネクションについての全体的な信頼性を表す重み付けメトリックにする複合信頼性メトリックを作成し得る。このメトリックで高ランクとなるコネクションであれば、高信頼性を必要とするフローに確保されるであろう（高信頼性は、高速を意味しない場合がある）。
【0185】
一般に、パケットを選定することを可能にするセレクタが生成される場合には、そのパケットは、セレクタを生成するために使用されたいくつかのコネクション上でパケットをスケジュールすることを可能にする順序付けを生成するべきである。
【0186】
図４Ｃは、４００Ｃにおいて、パケットのフロークラスをどのように使用してコネクションの順序を構築することができるかの一例を示す。描示される実施形態では、パケットのメタデータにおけるフロークラスを使用して、フロークラス定義を参照する。フロークラスのマッチ基準は、いずれのコネクションを構築された順序付けに含めるべきであるかを選定するために使用され（言い換えれば、フロークラスは、特定のフロークラスに関連付けられ得る一連の伝送要件を定義する）、この場合、コネクション１及びコネクション２が両方ともマッチする一方、コネクション３は、マッチしない。コネクション２は、利用可能な輻輳ウィンドウを有していない（すなわち、現在、パケットを送信するのに適格でない）にもかかわらず、含まれることに留意されたい。このことは、順序付けをキャッシュし、かつ利用可能な輻輳ウィンドウの状態が変化すべき場合でも順序付けを再利用することを可能にすることを容易にする（例えば、スケジューラが、コネクションの優先順位が低いためにコネクションでの送信を初期に阻止しているが、その後、有効なコネクション上の現在のデータミックスが最小システムスループットを満たしていないために、コネクションを再度有効にすることを決定した場合）。
【0187】
コネクションのセットが選定されると、フロークラスからの順序付け基準（例えば、フロークラスに関連付けられた伝送要件のサブセット）を使用して、マッチするコネクションを順序付きリストにソートする。この例では、第１の基準は、容量係数である。両方のコネクションは、同じ容量係数を有する。第２の基準は、ＲＴＴであり、両方のコネクションは、同じＲＴＴを有する。第３の基準は、ＢｔｌＢＷ（ボトルネック帯域幅）であり、コネクション２は、より高い値を有するため、順序付けにおいてコネクション１の前に現れる。
【0188】
フロークラスにおける順序基準のセット（例えば、伝送要件）は、属するフローのタイプに対して最も最適である利用可能なコネクション上でパケットをスケジュールすることを可能にする。例えば、「ビデオエンコーダ」フロークラスに属するパケットは、最も低いレイテンシを有するコネクションを優先的に使用することができる一方、「ファイル転送」フローに属するパケットは、レイテンシが高いか、又は高度に可変である場合でも、高スループットコネクションを優先し得る。
【0189】
コネクションについて順序付けが決定されると、ステップ２ｄ（ブロック１１０７）は、順序付けを使用して、利用可能な帯域幅を有するコネクションにパケットを割り当てる。パケットは、コネクションのための送信キュー上に配置される。
【0190】
図４Ｄは、４００Ｄにおいて、図４Ｃからの順序付けを使用して所与のパケットについてのコネクションを選択することを示す。この例では、順序付けにおける第１のコネクションは、コネクション２であるが、コネクション２は、利用可能な輻輳ウィンドウを有していないため、現在、パケットを送信するのに適格ではない。次いで、コネクション１がチェックされ、パケットを送信することができるため、コネクション１が選択され、パケットは、コネクション１についてのステージ３パイプラインに送信されるためにキューイングされる。
【0191】
次いで、インフライトバイトのコネクションメタデータ（監視される特性）は、ステップ２ｅの一部として調整される。いくつかの実施形態では、これは、コネクションについてのＣＷＮＤ消費を追跡するときに、グッドプットバイトと再送／ダミー／プロービングバイトとを区別することを含む。そのような調整は、ステップ２におけるループの次の反復で次の優先順位レベルのコネクションをアクティブ化し得る、優先順位グループについてのグッドプット及び／又は潜在的なグッドプットに影響を与え得る。ボリュームの単位（ＣＷＮＤバイト）からレート（グッドプット）への変換のための様々な方法が、図８及び図９についての説明に続いて議論される。
【0192】
ステップ３に達すると、各コネクションについての利用可能なＣＷＮＤが満杯であるか、又は伝送に適格なパケットがないかのいずれかである。ステップ２でコネクションごとの出力キューにキューイングされたパケットは、次いで、パイプラインの次のステージの適切なインスタンスに送信される。
【0193】
いくつかの実施形態では、明示的な目標関数を使用して、同じ優先順位を有するが、競合する要件を有するフロークラスに属する複数のフローがあるときに、所望のトレードオフを決定することができる。
【0194】
【0195】
この実施形態における公正な実装態様は、ＲＦＣ８２９０に記載された不足ラウンドロビンスケジューリングアルゴリズムを使用する。このアルゴリズムの簡単な概要は、このアルゴリズムが「バイトクレジット」スキームを利用し、キュー全体にわたるラウンドの反復の各ラウンドにおける各キューにバイトクレジットのクォンタムを割り当てることである。
【0196】
各ラウンドにおける各キューからの伝送のために取得され得るバイト数は、公称上、キューが有する利用可能なクレジット数に制限される。各キューについてのバイトクレジットクォンタムが等しい場合、公正性が自然に生じる。
【0197】
いくつかの実施形態では、目標関数は、管理者又はエンドユーザによって意図的な不公正性が構成されることを可能にし得る。例えば、マッチングフロー上に重みが構成され得、このことは、最終的に、各反復でキューに与えられる等しくないバイトクレジットクォンタムをもたらし得る。
【0198】
例えば、５つの異なる重みレベルがあり得る：
●最高（５）
●高（４）
●標準（３）
●低（２）
●最低（１）
●最高（５）
●高（４）
●標準（３）
●低（２）
●最低（１）
【0199】
各重みに割り当てられた値は、これらのキューのバイトクレジットクォンタム間の比率を表す。例えば、標準に対応するクォンタムが３０ＫＢである場合、低とマークされたフローであれば、各ラウンドで（２／３）＊３０ＫＢ＝２０ＫＢのクォンタムを受け取るであろう。最高にマークされたフローであれば、（５／３）＊３０ＫＢ＝５０ＫＢを受け取るであろう。
【0200】
この例における絶対数は重要ではないことに留意されたい。標準クォンタムが３０ＫＢではなく５ＫＢであるとした場合、重みは、依然として他の優先順位レベルについての相対クォンタムを適切にスケーリングするであろうし、最終的な結果は、全体的な公正性の点で同じとなろう。
【0201】
他の実施形態は、重みは、上記の例における５つの固定値ではなく、随意の整数であることを可能にし得る。これにより、管理者又はエンドユーザは、必要に応じて、目標関数にフロー間の更に大きな不公正性を構成することが可能になるであろう。
【0202】
また、全てのサービス品質（ＱｏＳ）と同様に、これらの重み設定は、利用可能なＷＡＮ容量についての競合がある場合にのみ重要であることに留意されたい。競合がない場合、全てのキュー内のデータが利用可能な容量内に完全に収まることを意味するため、キューの使用量間の比率は、アプリケーションが異なるボリュームのデータを生成することからの自然な比率である。
【0203】
他の実施形態は、公正性をまったく考慮しない、完全に異なる目標関数を有し得る。例えば、
●最大数のフローが利用可能なＷＡＮ容量によって満たされることを保証するか、
●サービス提供されたフローによって達成された総スループットを最大化するか、又は
●ＢｏＤコネクション上の現在の帯域幅割り振りの変更を最小限に抑える。
●最大数のフローが利用可能なＷＡＮ容量によって満たされることを保証するか、
●サービス提供されたフローによって達成された総スループットを最大化するか、又は
●ＢｏＤコネクション上の現在の帯域幅割り振りの変更を最小限に抑える。
【0204】
いくつかの実施形態では、ＷＡＮコネクションが使用される方途は、ＷＡＮコネクションの属性を改変することができ、ＷＡＮコネクションを、特定のフロークラスにサービス提供するのに不適格にすることができる。例えば、いくつか部のタイプのコネクションは、高スループットを達成することができるが、より高いＲＴＴを引き起こすことを犠牲にする。
【0205】
スループットを最大化しようとする目標関数を有する実施形態であれば、高スループット要件を有するフローにサービス提供することを選定するであろうし、このことは、ＷＡＮコネクションＲＴＴを増加させ、ＷＡＮコネクションを、低レイテンシ要件を有するフロークラスにサービス提供するのに不適格にするであろう。
【0206】
逆に、最大数のフローにサービス提供しようとする目標関数を有する実施形態であれば、低レイテンシフロークラスがこのＷＡＮコネクションによってサービス提供され続け得るように、反対のトレードオフを選定し得る。
【0207】
いくつかの実施形態では、個別のスケジューラのコネクションソート順序は、全てのフローについてグローバルではなく、フローごとに維持される。
【0208】
このことは、フローのパケットがコネクションのニーズを満たす方途でコネクションに割り当てられるように、フロー固有の要件がソート順序に影響を与えることを可能にする。
【0209】
例えば、１５０ｍｓの好ましい最大レイテンシ公差許容値を有するＶｏＩＰフローは、リストの最下位に１５０ｍｓを超えるＲＴＴを有するコネクションを配置するソート基準を望むであろう。逆に、特定のレイテンシ要件を有していないＴＣＰフローは、代わりに、ＲＴＴを完全に無視するか、又はＲＴＴを多くの二次基準のうちの１つとしてのみ使用するかのいずれかで、このＴＣＰフローのソート基準においてコネクションスループットを優先することを望むであろう。
【0210】
いくつかの実施形態では、これらのフロー要件及びプリファレンスは、マッチ基準及び結果的な挙動からなるルールの形態で構成されている。
【0211】
例えば、マッチ基準は、ＩＰ３タプル（プロトコル、送信元ＩＰ、及び宛先ＩＰ）又はＩＰ５タプル（プロトコル、送信元ＩＰ、送信元ポート、宛先ＩＰ、及び宛先ポート）の形態をとることができる。挙動は、レイテンシ又はスループットについての明示的なプリファレンスの形態をとり、いずれかについてのターゲットの好ましい値を有する。
【0212】
他のヒューリスティックベースのマッチ基準の例としては、以下のものが挙げられ得る：
●ＤＳＣＰタグ
●ＩＰ（ｖ４又はｖ６）ヘッダで利用可能な他のヘッダフィールドのいずれか
●ＴＣＰヘッダ又はＵＤＰヘッダ内の他のヘッダフィールドのいずれか
●伝送されたデータの累積ボリューム、例えばボリューム閾値を超えるＴＣＰフローは、「バルクデータ転送」としてマッチする可能性があるのに対して、そうでないものは、インタラクティブなＳＳＨ／ｔｅｌｎｅｔセッションとしてマッチしない可能性がある
●フローの累積持続時間
●パケットペイロードに対する正規表現マッチ
●ＴＬＳハンドシェイクから抽出されたクリアテキストパラメータ（例えば、ＳＮＩ、ＣＮ、ＳｕｂｊｅｃｔＡｌｔＮａｍｅ）
●ＤＳＣＰタグ
●ＩＰ（ｖ４又はｖ６）ヘッダで利用可能な他のヘッダフィールドのいずれか
●ＴＣＰヘッダ又はＵＤＰヘッダ内の他のヘッダフィールドのいずれか
●伝送されたデータの累積ボリューム、例えばボリューム閾値を超えるＴＣＰフローは、「バルクデータ転送」としてマッチする可能性があるのに対して、そうでないものは、インタラクティブなＳＳＨ／ｔｅｌｎｅｔセッションとしてマッチしない可能性がある
●フローの累積持続時間
●パケットペイロードに対する正規表現マッチ
●ＴＬＳハンドシェイクから抽出されたクリアテキストパラメータ（例えば、ＳＮＩ、ＣＮ、ＳｕｂｊｅｃｔＡｌｔＮａｍｅ）
【0213】
スケジューラソート順序に影響を与える可能性がある他の動作の例としては、以下のものが挙げられる：
●コネクション順序についての特定のプリファレンス（例えば、ユーザは、低優先順位フローについて、リストの最下位に高価なコネクションをソートすることを優先し得る）
●ジッタ許容公差
●最大レイテンシ許容公差
●所望の冗長性の量（例えば、ＦＥＣ）
●失われたパケットの再送が所望されるかどうか、及びその場合に、再送の試みが停止するべき最大時間制限があるかどうか
●明示的なパケットペーシングが所望されるかどうか
●例えば、毎秒３０フレームでビデオを伝送するリアルタイムビデオアプリであれば、ビデオのビデオフレームを正確に３３．３ミリ秒間隔で伝送し得、マルチパスシステム１００Ｂがペーシングを変更することを望まないであろう。
●対照的に、バーストアプリケーションであれば、スケジューラに集約ＷＡＮレートでビデオのバーストを明示的にペーシングさせることから利益を受け得る。
●所望のスループット（例えば、最小、ターゲット、最大）
●コネクション順序についての特定のプリファレンス（例えば、ユーザは、低優先順位フローについて、リストの最下位に高価なコネクションをソートすることを優先し得る）
●ジッタ許容公差
●最大レイテンシ許容公差
●所望の冗長性の量（例えば、ＦＥＣ）
●失われたパケットの再送が所望されるかどうか、及びその場合に、再送の試みが停止するべき最大時間制限があるかどうか
●明示的なパケットペーシングが所望されるかどうか
●例えば、毎秒３０フレームでビデオを伝送するリアルタイムビデオアプリであれば、ビデオのビデオフレームを正確に３３．３ミリ秒間隔で伝送し得、マルチパスシステム１００Ｂがペーシングを変更することを望まないであろう。
●対照的に、バーストアプリケーションであれば、スケジューラに集約ＷＡＮレートでビデオのバーストを明示的にペーシングさせることから利益を受け得る。
●所望のスループット（例えば、最小、ターゲット、最大）
【0214】
トラフィックパターンを分析する機械学習技法を使用して、ルール（マッチ基準及び動作の両方）が自動生成され得る。
【0215】
ＭＬ法への入力（特徴量）としては、以下のものが挙げられ得る：
ｉ．伝送されたデータの累積ボリューム
ｉｉ．パケットのサイズ分布（ヒストグラム）
ｉｉｉ．パケット間の間隔（ペーシング及びジッタの両方）
ｉｖ．パケットの頻度及びグループ化
ｖ．パケットヘッダフィールド（イーサネット、ＩＰ、ＴＣＰ、ＵＤＰなど）
ｖｉ．パケットの内容（ペイロード）
ｖｉｉ．ＩＰアドレッシングだけでなく、パケットの意図された宛先（例えば、ＴＬＳハンドシェイク及び交換された証明書におけるＳＮＩ、ＣＮ、及びＳｕｂｊｅｃｔＡｌｔＮａｍｅフィールド）
ｖｉｉｉ．フローの累積持続時間
ｉｘ．時刻
ｘ．同じ宛先への、又は同じ送信元からの同時フロー数
ｘｉ．同じ宛先への、又は同じ送信元からの任意の同時フローの現在又は履歴の予測（ラベル）（例えば、いくつかのアプリケーションは、複数のフローを開き、１つを制御プレーンとして、別の１つをデータプレーンとして開き、既存の制御プレーンフローが存在することを知ることは、データプレーンフローの予測に役立ち得る）
ｉ．伝送されたデータの累積ボリューム
ｉｉ．パケットのサイズ分布（ヒストグラム）
ｉｉｉ．パケット間の間隔（ペーシング及びジッタの両方）
ｉｖ．パケットの頻度及びグループ化
ｖ．パケットヘッダフィールド（イーサネット、ＩＰ、ＴＣＰ、ＵＤＰなど）
ｖｉ．パケットの内容（ペイロード）
ｖｉｉ．ＩＰアドレッシングだけでなく、パケットの意図された宛先（例えば、ＴＬＳハンドシェイク及び交換された証明書におけるＳＮＩ、ＣＮ、及びＳｕｂｊｅｃｔＡｌｔＮａｍｅフィールド）
ｖｉｉｉ．フローの累積持続時間
ｉｘ．時刻
ｘ．同じ宛先への、又は同じ送信元からの同時フロー数
ｘｉ．同じ宛先への、又は同じ送信元からの任意の同時フローの現在又は履歴の予測（ラベル）（例えば、いくつかのアプリケーションは、複数のフローを開き、１つを制御プレーンとして、別の１つをデータプレーンとして開き、既存の制御プレーンフローが存在することを知ることは、データプレーンフローの予測に役立ち得る）
【0216】
ＭＬ法からの予測（ラベル）としては、訓練コーパスの挙動に基づいて決定された、前述の挙動のうちのいずれかが挙げられるであろう。
【0217】
いくつかの実施形態では、ルールは、依然として親ルールによって管理されながら、更なるマッチ基準及びより具体的な挙動を適用する従属ルールの概念を有することができる。例えば、
●ＩＰ５タプルによって識別されるＶＰＮフローであれば、マッチ基準及び動作で定義されたルールを有し得る。これは、「親」ルールとみなされるであろう。
●ＶＰＮは、ＶＰＮ内で、ＶＰＮによって保護されているアプリケーションからの多くの内部フローを搬送するであろう。通常、これらの内部フローは、（ＶＰＮによって暗号化された）マッチ基準から完全に隠されるであろう。
●ただし、いくつかのＶＰＮは、内部（クリアテキスト）パケットのプリファレンスに対応する暗号化されたパケット上にＤＳＣＰタグを設定することにより、内部フローに関する限られた情報セットを公開することを選定し得る。
●ＩＰ５タプルによって識別されるＶＰＮフローであれば、マッチ基準及び動作で定義されたルールを有し得る。これは、「親」ルールとみなされるであろう。
●ＶＰＮは、ＶＰＮ内で、ＶＰＮによって保護されているアプリケーションからの多くの内部フローを搬送するであろう。通常、これらの内部フローは、（ＶＰＮによって暗号化された）マッチ基準から完全に隠されるであろう。
●ただし、いくつかのＶＰＮは、内部（クリアテキスト）パケットのプリファレンスに対応する暗号化されたパケット上にＤＳＣＰタグを設定することにより、内部フローに関する限られた情報セットを公開することを選定し得る。
【0218】
ＤＳＣＰタグにマッチする従属ルールを作成し得るが、結果として得られる利用可能な挙動は、依然として親ルールによって管理されるであろう。例えば、
ａ．一般に、ＶＰＮは、パケットを順番に配信することを必要とする（ＶＰＮは、順序の誤りを許容することができるが、小さなウィンドウまでである）。
ｂ．ＤＳＣＰタグにマッチする従属ルールで構成された挙動は、親ルールが著しく順不同でパケットを配信する結果となってはならない。
ａ．一般に、ＶＰＮは、パケットを順番に配信することを必要とする（ＶＰＮは、順序の誤りを許容することができるが、小さなウィンドウまでである）。
ｂ．ＤＳＣＰタグにマッチする従属ルールで構成された挙動は、親ルールが著しく順不同でパケットを配信する結果となってはならない。
【0219】
例えば、１５０ｍｓの最大レイテンシ制限を要求する従属ルール、及び最大スループットを要求する第２の従属ルールは、これらの２つの従属ルールからのインターリーブされたパケットが大幅に異なるレイテンシを有するコネクションに割り当てられる可能性があることから、親ルールの順序付け要件に違反する可能性がある。
【0220】
図５Ａは、それぞれのルール及び挙動が完全に独立している２つの独立したフローを例示している。この例では、ＳＩＰフローは、低レイテンシを必要とするため、挙動は、スケジューラ１０４Ｂにコネクション１でＳＩＰフローのパケットのみを伝送させる。逆に、ＦＴＰフローは、高スループットを必要とするため、スケジューラ１０４Ｂは、コネクション２でＦＴＰフローのパケットのみを伝送する。
【0221】
これらの２つのフローについてパケットが無線で伝送され、シーケンサ１１８に到達すると、これらのパケットは、順序通りに戻され、最終的な宛先に独立に伝送される。この例では、シーケンサ１１８は、パケットが依然として無線を介して伝送中であるＦＴＰフローの状態にかかわらず、既に到達しており、かつ正しい順序であるＳＩＰフローに属するパケットを伝送している。
【0222】
図５Ｂは、従属フローの概念を例示している。この例では、同じＳＩＰフロー及びＦＴＰフローが存在するが、スケジューラ１０４Ｂがこれらのフローを見る前に、これらのフローは、暗号化及びカプセル化のためにＶＰＮクライアントを通過する。
【0223】
ＶＰＮクライアントから出てくると、両方のフローからのパケットは、同じＩＰ５タプルを有するため、スケジューラ１０４Ｂ及びシーケンサ１１８は、これを親フローとして扱い、親フローの要件によって制約される。
【0224】
従属フロー（ＳＩＰ及びＦＴＰ）の存在は、ＤＳＣＰタグを使用して伝達され、ＤＳＣＰタグは、スケジューラ１０４Ｂが伝送のためにコネクション１及び２にどのようにパケットを割り当てるかを制御する。この例では、割り当ては、図５Ａにおけるものと同じである。
【0225】
しかしながら、親フロー制約は、パケットがスケジューラ１０４Ｂに到達したのと同じ順序でシーケンサ１１８から伝送されることを必要とする。したがって、この例では、従属ＳＩＰフローに属するパケットがシーケンサ１１８に既に到達していても、従属ＦＴＰフローに属するパケットが到達し、かつ最初に伝送されるまで、従属ＳＩＰフローに属するパケットを伝送することができない。
【0226】
図６Ａは、６００Ａにおいて、ルール管理ページのサンプル実施形態である。構成されたルールを表に表示し、各行が、マッチ基準及び挙動をまとめている。ルールがリストされている順序は、パケットがルールとマッチする順序である。図６Ｂは、６００Ｂにおいて、ルールの順序を変更するためのワークフローを示す。
【0227】
図６Ｃは、６００Ｃにおいて、マッチ基準及び挙動の詳細、並びにこのルールにマッチするシステムを通過する現在アクティブなフローを示すために、テーブル内の各行をどのように拡張することができるかを示す。
【0228】
表における各ルールは、編集及び削除のアイコンを含む。
【0229】
図６Ｄは、６００Ｄにおいて、編集ボタンがクリックされたときに現れるダイアログを示す。ルールについてのマッチ基準及び挙動を、このダイアログで変更することができる。
【0230】
メインのルール管理画面には、別個の［ルール追加］リンクがあり、図６Ｅは、６００Ｅにおいて、クリックすると現れるモードダイアログを示す。
【0231】
いくつかの実施形態では、ルールは、送信機側で構成されるようになっており、受信機に自動プッシュされるようになっている。デフォルトでは、ルールは、対称かつ双方向となっている。つまり、ルールが追加され、かつルールの挙動が構成されると、マッチするペアルールが透過的に追加されるようになっているが、送信元及び宛先のマッチ基準はスワップされるようになっている。高度な構成画面を介して、非対称ルール（同じフローのいずれかの方向に対して異なる挙動）を追加することが可能であろう。
【0232】
一実施形態では、スケジューラは、複数のコネクションの様々なネットワーク特性をプローブし（各コネクションについての測定される特性を判定するために）、測定される特性を伝送要件と組み合わせて使用して、パケット伝送に関する決定を行う。
【0233】
例えば、１つのそのような決定は、特定のコネクションで伝送するパケットの数及びこれらのパケットをいつ伝送するかを決定することである。
【0234】
いくつかの実施形態は、ボリュームベースである。そのような実施形態は、特定のコネクションで伝送され得るデータのボリュームに対する制限（例えば、バイト又はパケットの単位）を決定することによって動作する。そのボリュームの量で十分なパケットが伝送されると、これらのパケットに関するいくつかのフィードバックが受信されるまで伝送が停止する。完全なボリューム制限が伝送される前にフィードバックが受信された場合、フィードバックが受信されていない送信されたデータのボリュームが決定されたボリューム制限を超えない限り、伝送を停止せずに継続することができる。
【0235】
一実施形態では、データのボリュームは、コネクションの輻輳ウィンドウ（ＣＷＮＤ）となるように選定される。簡単に言えば、ＣＷＮＤは、任意のフィードバックを受信する前に、コネクションで、そのコネクションに著しい輻輳を引き起こさずに送信することができる最大のデータのボリュームである。ＣＷＮＤを推定するための多数の方法が存在する。スケジューラは、１つのそのような方法にアクセスし、その方法を介してＣＷＮＤの推定値を受け取ることができると仮定される。
【0236】
いくつかの実施形態では、スケジューラは、（例えば、１秒当たりのバイトの単位で）データが伝送されているレートを決定することが必要とされる。次いで、このレートを使用して、パケット伝送に関する他の決定を行うことができる。
【0237】
例えば、一実施形態では、現在アクティブなネットワークコネクション（複数可）で伝送されているデータのレートが、伝送のために送信元アプリケーションから受信されているデータのレートよりも小さい場合、スケジューラは、より多くのコネクションをアクティブ化して、アプリケーションレートに対応するために集約伝送レートを増加させることを決定することができる。
【0238】
別の例では、一実施形態は、保証された伝送レートの観点から表すことができるサービス品質（ＱｏＳ）要件を満たさなければならない場合がある。集約レートが必要とされるレベルを下回った場合、スケジューラは、ＱｏＳ要件を満たすために集約伝送レートを増加させるために、より多くのコネクションをアクティブ化することを決定することができる。
【0239】
また別の例では、一実施形態が、アプリケーション性能レベルを保証し、性能を最適化し、報告するなどの目的で、グッドプット（すなわち、アプリケーションデータがネットワークを正常に通過するレート）を測定するために必要とされ得る。
【0240】
一実施形態では、ＴＣＰ性能は、複数のコネクションによって達成される集約レートで、送信されるパケットをペーシングすることによって最適化され得る。例えば、ＰＣＴ出願第ＰＣＴ／ＣＡ２０２０／０５１０９０号を参照されたい。
【0241】
いくつかの機能にレートが必要とされる実施形態では、ボリュームベースのスケジューラは、伝送されるデータのボリュームをレートに変換する方法を必要とする。
【0242】
ボリュームを伝送された時間の持続時間で除算することによってボリュームをレートに変換する些末な手法は、一般に、不正確な結果をもたらす。そのような手法は、実際のレートデータではなく、送信機での伝送レートがネットワークを通して移動していることを測定する。データがネットワークを通して移動する実際のレートは、一般にネットワークのボトルネックと称されるマルチリンクネットワークの最も遅いリンクでのレートによって真に判定される。
【0243】
ネットワークのボトルネックリンクの特性は、特にマルチリンクネットワークがいつでも、送信機及び受信機に対して透過的に使用されるリンクの組み合わせを変更することができることを知っている送信機又は受信機には利用可能でない。しかしながら、輻輳制御方法は、送信機及び受信機で観測された性能に基づいて、推定値を生成することができる。
【0244】
いくつかの実施形態では、輻輳制御方法は、ボトルネックリンクの伝送レートの推定を提供することができる。これは、ネットワークのボトルネック帯域幅ＢｔｌＢｗと称されることがある。
【0245】
いくつかの実施形態では、ネットワークのラウンドトリップ伝播時間ＲｔＰｒｏｐを、パケットが送信されるときとパケットに関するフィードバックが受信されるときとの間の時間をサンプリングすることによって推定することができる。
【0246】
ＢｔｌＢｗとＲｔＰｒｏｐとの組み合わせを使用して、以下のように、帯域幅遅延積ＢＤＰと称されるネットワーク属性を判定することができる。
ＢＤＰ＝ＢｔｌＢｗ×ＲｔＰｒｏｐ
ＢＤＰ＝ＢｔｌＢｗ×ＲｔＰｒｏｐ
【0247】
ＢＤＰについての最も一般的な単位は、バイトである。これらの量については、以下の単位が仮定される：（ｉ）ＢｔｌＢｗについては１秒当たりのバイト、（ｉｉ）ＲｔＰｒｏｐについては秒、及びしたがって（ｉｉｉ）ＢＤＰについてはバイト。
【0248】
ＢＤＰは、データが常に送信に利用可能であると仮定して、理想的な条件で動作している場合にネットワーク（インフライト）に存在するであろうデータの量を意味する。このネットワークは、ネットワークの公称レートＢｔｌＢｗでデータを転送し、そのパケットを送信するＲｔＰｒｏｐ時間のちょうど後に、あらゆるパケットに関するフィードバックを提供するであろう。図７は、７００において２つの例を示す。図７の上半分は、ＢＤＰが１６個の等サイズのパケットからなる例を使用して、この概念を例示している。実際には、総サイズがＢＤＰを使用して計算される値に等しい限り、パケットの量及びサイズは、異なり得る。
【0249】
いくつかのボリュームベースの実施形態では、ＢＤＰを使用して、様々なデータ転送レートを推定することができ、そのうちのいくつかの例については、先述した。
【0250】
検討中のインフライトボリュームについて、理想的な条件を仮定して、ボリュームがＢＤＰよりも小さい場合、ネットワークの公称レートの分数値であるＢｔｌＢｗを達成することができるにすぎない。この分数値を、ＢＤＰに対するボリュームの比として計算することができる。結果として得られる達成レートは、以下のように決定される：
インフライトボリュームに対応する達成レート＝ボリューム／ＢＤＰ×ＢｔｌＢｗ
インフライトボリュームに対応する達成レート＝ボリューム／ＢＤＰ×ＢｔｌＢｗ
【0251】
実際には、ネットワークが理想的な状況下で動作することはめったにない。例えば、パケットが、受信端に配信される前に一時的にバッファリングされる場合があるし、フィードバックが、受信機で又はネットワークによって遅延し得る。いくつかの場合では、パケットが失われ、受信側に到達することがなく、それによって、フィードバックがトリガされない場合がある。他の場合では、フィードバック自体が失われる場合がある。損失は、例えば、新しいパケットのフィードバックが受信されたとき、又はタイマ期限切れに基づいて推定され得る。
【0252】
遅延したフィードバック（到達してもしなくてもよい）が次の伝送イベントをトリガするのを待つことは、ネットワークでの達成可能なレートを人為的に制限し得る。
【0253】
【0254】
図８Ｂは、図８００Ｂにおいて、例えば、確認応答の集約が、全体的なスループットがネットワークの能力よりも小さいことをどのようにもたらすかを続いて例証している。送信者は、次のパケットグループの送信を開始するまで、より長い時間待つ。全体として、送信機は、最終的に、図７の理想的な場合と同じ量のパケットを送信するが、より長い期間にわたって送信するため、スループットの低下をもたらす。
【0255】
一実施形態では、この人工的な制限は、以前に送信されたパケットのフィードバックがまだ受信されていない場合でも、送信するデータの追加の許容量を指定することによって克服される。このことは、インフライトのデータのボリュームがＢＤＰを超え得ることを意味する。しかしながら、そのような場合、上記の達成されたレート式の適用が示唆し得るように、ネットワークは、実際にはより高いレートではデータを転送していない。追加の許容量は、送信機がより長い期間にわたってＢｔｌＢｗに等しい一定のレートを維持することを単に可能にする。したがって、手元のボリュームの推定される転送レートは、ＢｔｌＢｗにキャップされる。
【0256】
図８Ｃは、図８００Ｃにおいて、例えば、確認応答が受信される前に、送信機がパケットを送信し続けるためにそのような追加の送信許容量をどのように使用するかを続いて例証している。インフライトのデータのボリューム、１９パケットは、１６パケットのＢＤＰを超えている。しかしながら、実際のレートは、ネットワークの能力とマッチし、計算されたレートのキャッピングは、インフライトのボリュームの最小値とＢＤＰとを使用することによって、同じ結果を達成する。
【0257】
いくつかの実施形態では、同様の手法を使用して、以後、潜在的なグッドプットと称される、場合によってはネットワーク上で達成され得るグッドプットを推定することができる。
【0258】
データの特定のボリュームを、グッドプット部分と他の部分とに分割することができる。グッドプット部分は、新しく伝送されたアプリケーションデータを含む。他方の部分は、新しく伝送されたアプリケーションデータとしてカウントすることができないデータ、例えば、以前に失われたデータ、制御データ、プロービングデータなどの再送を含む。
【0259】
データの全ボリュームがＢＤＰよりも大きい場合、パケット及び／又はフィードバック遅延は、上記のように仮定される。追加のグッドプットに利用可能な余分なスペースはないと仮定する。結果として得られる（潜在的な）グッドプットレートは、以下のように推定される：
グッドプットレート＝グッドプット部分／全ボリューム×ＢｔｌＢｗ
グッドプットレート＝グッドプット部分／全ボリューム×ＢｔｌＢｗ
【0260】
例えば、図９Ａは、９００Ａにおいて、１６パケットのＢＤＰを有するネットワークを示す。ネットワークの能力に等しいスループットを達成するために、インフライトとされたボリュームは、１９パケットである。しかしながら、１４個のパケットのみがグッドプットであり、ネットワークの能力の７／８のグッドプットレートをもたらす。データのボリュームがＢＤＰよりも小さい場合、差は、追加のグッドプットに利用可能と仮定される余分なスペースであるとみなされる。
【0261】
図９Ｂは、９００Ｂにおいて、３パケットのみがインフライトであり、潜在的なグッドプットレートを計算するときにグッドプットであると仮定することができる１３パケットの余分なスペースをもたらす一例を示す。この余分なスペースは、輻輳制御方法が決定するＣＷＮＤによって制限されなければならない。任意の時点で、輻輳制御が許容する追加のボリュームは、ＣＷＮＤと全ボリュームとの間の差である。グッドプットの余分なスペースがこの輻輳制御許容量を超える場合、スペースは、単に輻輳制御許容量に制限される。
【0262】
図９Ｃは、９００Ｃにおいて、ＣＷＮＤが１１パケットに低減された例を示しており、これは、追加のグッドプットに利用可能と仮定される余分なスペースを８パケットに制限する。
【0263】
結果として得られる潜在的なグッドプットレートは、以下のように推定される：
潜在的なグッドプットレート＝（グッドプット部分＋制限されたグッドプットの余分なスペース）／ＢＤＰ×ＢｔｌＢｗ
潜在的なグッドプットレート＝（グッドプット部分＋制限されたグッドプットの余分なスペース）／ＢＤＰ×ＢｔｌＢｗ
【0264】
上記の例を続けると、図９Ｂ及び図９Ｃは、上記の潜在的なグッドプット式が、図９Ｃにおけるシナリオについてのより低い潜在的なグッドプットレートをどのようにもたらすかを示しており、これは、輻輳制御方法によって執行されるＣＷＮＤ低減を考慮して期待されるとおりである。
【0265】
上記の手法は、グッドプット及び潜在的なグッドプットレートについて記載されているが、この手法を、全ボリュームを部分的に構成する任意のタイプのデータのレート又は潜在的なレートを計算するように容易に修正することができる。
【0266】
以下は、ＬＴＥセルラネットワークを介して遭遇するものに典型的な属性を有するネットワークに先述の式を適用する数値例である。
ＢｔｌＢｗ＝１０Ｍｂｐｓ
ＲｔＰｒｏｐ＝６０ｍｓ
ＢＤＰ＝１０Ｍｂｐｓ＊６０ｍｓ＝７５ＫＢ
ＣＷＮＤ＝６０ＫＢ
グッドプット部分＝２５ＫＢ
他の部分＝１０ＫＢ
全ボリューム＝２５ＫＢ＋１０ＫＢ＝３５ＫＢ
グッドプットの余分なスペース＝ＢＤＰ－全ボリューム＝７５ＫＢ－３５ＫＢ＝４０ＫＢ
輻輳制御許容量＝ＣＷＮＤ－全ボリューム＝６０ＫＢ－３５ＫＢ＝２５ＫＢ
制限されたグッドプットの余分なスペース＝
Ｍｉｎ（グッドプットの余分なスペース，輻輳制御許容量）＝
Ｍｉｎ（４０ＫＢ，２５ＫＢ）＝２５ＫＢ
潜在的なグッドプットレート＝
（グッドプット部分＋制限されたグッドプットの余分なスペース）／ＢＤＰｘＢｔｌＢｗ＝
（２５ＫＢ＋２５ＫＢ）／７５ＫＢｘ１０Ｍｂｐｓ＝５０／７５ｘ１０Ｍｂｐｓ＝６．６７Ｍｂｐｓ
ＢｔｌＢｗ＝１０Ｍｂｐｓ
ＲｔＰｒｏｐ＝６０ｍｓ
ＢＤＰ＝１０Ｍｂｐｓ＊６０ｍｓ＝７５ＫＢ
ＣＷＮＤ＝６０ＫＢ
グッドプット部分＝２５ＫＢ
他の部分＝１０ＫＢ
全ボリューム＝２５ＫＢ＋１０ＫＢ＝３５ＫＢ
グッドプットの余分なスペース＝ＢＤＰ－全ボリューム＝７５ＫＢ－３５ＫＢ＝４０ＫＢ
輻輳制御許容量＝ＣＷＮＤ－全ボリューム＝６０ＫＢ－３５ＫＢ＝２５ＫＢ
制限されたグッドプットの余分なスペース＝
Ｍｉｎ（グッドプットの余分なスペース，輻輳制御許容量）＝
Ｍｉｎ（４０ＫＢ，２５ＫＢ）＝２５ＫＢ
潜在的なグッドプットレート＝
（グッドプット部分＋制限されたグッドプットの余分なスペース）／ＢＤＰｘＢｔｌＢｗ＝
（２５ＫＢ＋２５ＫＢ）／７５ＫＢｘ１０Ｍｂｐｓ＝５０／７５ｘ１０Ｍｂｐｓ＝６．６７Ｍｂｐｓ
【0267】
ＩＰネットワークを介して通信するシステムは、多くの場合、同様の輻輳制御メカニズムを採用する全てのネットワークノードによる公正なネットワーク利用を達成しようとする輻輳制御メカニズムを実装する。
【0268】
輻輳制御メカニズムは、多くの場合、ネットワーク上で発生する通信を監視し、場合によっては、必要に応じてネットワークをプロービングし、かつその結果に基づいてネットワーク属性を導出することによって動作する。ネットワークを表すモデルが作成され、このモデルに基づいて以後の通信が導かれる。例えば、このモデルは、達成された現在の最大スループット、パケットの現在及び最小のラウンドトリップ時間、パケット損失イベントなどのネットワーク属性を追跡することができる。
【0269】
作成されたモデル及び追跡された情報に基づいて、輻輳制御メカニズムは、ネットワークが輻輳に遭遇している可能性があることを示す、ネットワークが性能不足であるときを判定することができる。次いで、輻輳制御メカニズムは、ネットワーク輻輳を低減又は除去し、かつ望ましいネットワーク性能を復元することを目的とする是正措置を講じ得る。
【0270】
従前の輻輳制御実施形態（例えば、ＴＣＰ）では、パケット損失は、ネットワーク輻輳の指標として使用され、損失に応答して是正措置（例えば、ＣＷＮＤを低減する）が行われる。
【0271】
一実施形態では、パケットのレイテンシ、すなわち、パケットが送信機から受信機までネットワークを通過するのに必要とされる時間は、ネットワーク性能の指標である。高レイテンシのパケットは、場合によっては、受信機にとって役に立たず、破棄され、これらのパケットの伝送が無駄になる可能性がある。例えば、参加者間の低い会話遅延を必要とするリアルタイムＶｏＩＰアプリケーションは、最大許容会話遅延よりも古い音声データを搬送するパケットを使用しないようになっている。
【0272】
そのような実施形態では、輻輳制御メカニズムは、パケットのレイテンシが許容レベルを超えないように、パケットのレイテンシを監視し、レイテンシを制御しようとし得る。
【0273】
一実施形態では、パケットについて測定される最低レイテンシは、ベースライン値を形成することができ、以後の測定値をこのベースライン値と比較することができる。以後の測定値がベースライン値の関数である閾値を超える場合、輻輳制御メカニズムは、ネットワークが輻輳に遭遇しているとみなす。
【0274】
別の実施形態では、同様の手法が、レイテンシの代わりに、パケットを送信することと、そのことに関する確認応答を受信することと、の間で経過する時間であるパケットのラウンドトリップ時間を使用する。
【0275】
一実施形態では、輻輳制御メカニズムが、増加したパケット遅延に基づいてネットワークが輻輳に遭遇していると判定すると、輻輳ウィンドウ（ＣＷＮＤ）は、何らのフィードバックも受信することなくこのネットワークで送信され得るデータの量を制限するように低減される。目的は、パケット遅延の増加の一般的な原因である、ネットワークによってバッファリングされることとなるか、又は現在バッファリングされているデータのボリュームを低減することである。
【0276】
一実施形態では、輻輳ウィンドウは、ネットワークの帯域幅遅延積（ＢＤＰ）に低減される。理論的には、ＢＤＰは、パケットがネットワークのスループット（ＢｔｌＢｗ）を反映する一定のペースで送信機によって伝送されると仮定して、そのバッファ内にパケットの動きのないキューを形成することなく、ネットワークが配信することができるはずであるデータのボリュームを表す。したがって、これは、ネットワークが少なくとも部分的に回復し、パケット遅延を許容レベルに低減し戻すことを可能にすると期待される。
【0277】
例えば、１６パケットのＢＤＰを有するネットワークと、確認応答集約を考慮するために２４パケットのＣＷＮＤを決定した輻輳制御メカニズムと、を仮定する。図１０Ａは、１０００Ａにおいて、他のネットワークノードからの輻輳が、どのようにして送信機にネットワークを制するようにさせることができるかを例示している。この場合、送信機は、送信機の輻輳ウィンドウを低減せず、全量をインフライトにする。これにより、ネットワークバッファが満杯になり、バッファリングできない余分なパケットがドロップされる。輻輳が解消され、かつネットワークバッファの通常の排出が継続した後でも、図１０Ａは、どのようにすれば、以後の全てのパケットのラウンドトリップ時間を増加させ、かつネットワークバッファを満杯にすることをより容易にする動きのないキューがネットワークバッファの内部に形成されたであろうかを例示している。
【0278】
この例を続けると、図１０Ｂは、１０００Ｂにおいて、送信機の輻輳ウィンドウをＢＤＰに低減する送信機が、どのようにしてパケットドロップと動きのないキューの形成との両方を回避するかを例示している。送信機は、例えば、送信機が過去の伝送で測定したフィードバックについてのベースライン持続時間を超える期間フィードバックが受信されていないことを検出することによって、輻輳が発生していると判定することができる。別の例では、送信機は、過去の伝送で遭遇したベースライン損失を超える以前に送信されたパケットの量が受信機に配信されていないことを示すフィードバックを受信することによって、輻輳が発生していると判定することができる。この輻輳の判定に応答して、ＢＤＰにマッチする輻輳ウィンドウの低減は、インフライトとされることとなるパケットの量を低減する。結果的に、このことは、以前はパケットドロップにつながっていたネットワークバッファを満杯にする可能性を低減する。更に、ＢＤＰパケットのみをインフライトにすることは、送信機からの新しいパケットが再びネットワークのバッファに到達する前に、ネットワークは、ネットワークのバッファを完全に排出することを可能にする（ネットワーク属性が変更されていないと仮定する）。
【0279】
別の実施形態では、輻輳ウィンドウは、現在インフライトのパケットのボリュームに等しくなるように低減される。
【0280】
輻輳制御メカニズムが許容レベルの性能が復元されたと判定すると、ネットワークは輻輳に遭遇しなくなったとみなされる。
【0281】
一実施形態では、閾値を下回るパケット遅延の低減は、ネットワーク性能が復元されたという指標である。
【0282】
一実施形態では、その閾値は、ベースライン遅延値の関数として決定される。
【0283】
別の実施形態では、何らの損失を招くことなく特定のボリュームのデータを伝送することは、ネットワーク性能が復元されたという指標である。
【0284】
一実施形態では、そのデータのボリュームは、ＢＤＰに等しい。
【0285】
別の実施形態では、そのデータのボリュームは、輻輳に応答して輻輳制御メカニズムによって低減される前の輻輳ウィンドウの元の値に等しい。
【0286】
プッシュ型アーキテクチャは、最も一般的なアプリケーションタイプの非ＢｏＤコネクションでのシステム性能を改善する。表３は、実験的に観測された改善をまとめたものである。
表３：プッシュ型スケジューラに起因するアプリケーション性能改善
表３：プッシュ型スケジューラに起因するアプリケーション性能改善
【表4】
【0287】
プッシュ型スケジューリング方法はまた、優先順位ルーティング挙動をより直感的にする。例えば、一実施形態では、より低い優先順位のコネクションを係わらせるかどうかの決定は、これらのコネクションのＢｔｌＢｗが構成された閾値とどのように比較されるかにのみ依存する。
【0288】
例えば，以下のシナリオを考える：
ｗａｎ０
●優先順位：一次
●ターゲット閾値：該当なし
●ＢｔｌＢｗ：１０Ｍｂｐｓ
ｗａｎ１
●優先順位：二次
●ターゲット閾値：１５Ｍｂｐｓ
●ＢｔｌＢｗ：３０Ｍｂｐｓ
ｗａｎ０
●優先順位：一次
●ターゲット閾値：該当なし
●ＢｔｌＢｗ：１０Ｍｂｐｓ
ｗａｎ１
●優先順位：二次
●ターゲット閾値：１５Ｍｂｐｓ
●ＢｔｌＢｗ：３０Ｍｂｐｓ
【0289】
プル型スケジューラを用いると、ｗａｎ１の５０Ｈｚタイマがウェイクアップしてパケットを要求するたびに、スケジューラは、所望のターゲット閾値（１５Ｍｂｐｓ）はｗａｎ０が単独で提供することができる閾値（１０Ｍｂｐｓ）よりも大きいことがスケジューラに分かることから、ｗａｎ１に伝送用のパケットを提供する。
【0290】
しかしながら、スケジューラは、パケットが入力に到達するレートにかかわらず、このことを行う。例えば、入力レートが１０Ｍｂｐｓを超えない場合、トラフィックがｗａｎ０単独で完全に収まることができることから、ｗａｎ１が関わらなかった場合に、より最適となろう。
【0291】
プッシュ型スケジューラを用いると、ｗａｎ０は、リストの最上位にソートされることとなり、閾値が、ｗａｎ１がアクティブであるべきことを示していても、ｗａｎ０ ＣＷＮＤが完全に消費された後にのみパケットがｗａｎ０上にスケジューリングされる。結果として、より低い優先順位のコネクションの期待されない使用が少なくなり、性能が改善する。
【0292】
まとめると、マルチパスシステムのスケジューラは、プル型（１００Ａ）又はプッシュ型（１００Ｂ）のいずれかとして実装され得る。スケジューラは、ターゲットコネクションが伝送する準備ができているレートによって駆動されるのではなく、自己決定の律動でパケットスケジューリング決定を行うことができるため、プッシュ型が優れている。この自己決定の律動は、パケットを生成したアプリケーション、及び／又はシステムのユーザにとって重要である全ての要因を考慮することを可能にする。
【0293】
例えば、最大のスループットを必要とするＴＣＰベースのアプリケーションによって生成されたパケットは、そのパケットが最良のＭａｔｈｉｓ係数から最悪のＭａｔｈｉｓ係数まで順序付けられたコネクション上にスケジューリングされることを優先するであろう。
【0294】
また、同じＴＣＰベースのアプリケーションを用いるより複雑な例を考え、ただし、ユーザは、優先順位ルーティングルールでマルチパスシステム１００Ｂを構成しており、１１０Ｂで達成可能なグッドプットが５Ｍｂｐｓを下回って降下しない限り、他の全てのコネクション１１０Ｎよりもコネクション１１０Ｂを優先する。１１０Ｂが高スループット、低レイテンシ、ただし高パケット損失を有する仮定のシナリオでは、１１０Ｂは、他の全てのコネクション１１０Ｎよりも悪いＭａｔｈｉｓ係数を有するであろう。
【0295】
プッシュ型スケジューラ１００Ｂは、最初にコネクション１１０Ｂを使用するためのユーザプリファレンスを尊重する複雑なスケジューリング決定を行い、また、コネクション１１０ＢのインフライトＣＷＮＤをビットレートに変換し、かつそれを使用してコネクション１１０Ｂの利用可能なグッドプットを推定することによって、１１０Ｂで達成可能なグッドプットを計算することができるであろう。この可用性が、構成された５Ｍｂｐｓ閾値を下回って降下する場合、１１０Ｂは、最良のＭａｔｈｉｓ係数から最悪のＭａｔｈｉｓ係数まで順序付けられた残りのコネクション１１０Ｎ上にパケットをスケジュールすることができる。
【0296】
図１１は、一実施形態による、システム１００Ｂを実装するために使用され得るコンピューティングデバイス１１００の概略図である。
【0297】
描写されるように、コンピューティングデバイス１１００は、少なくとも１つのプロセッサ１１０２、メモリ１１０４、少なくとも１つのＩ／Ｏインターフェース１１０６、及び少なくとも１つのネットワークインターフェース１１０８を含む。
【0298】
各プロセッサ１１０２は、例えば、マイクロプロセッサ又はマイクロコントローラ（例えば、専用のマイクロプロセッサ又はマイクロコントローラ）、デジタル信号処理（ＤＳＰ）プロセッサ、集積回路、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、リコンフィギュラブルプロセッサ、プログラマブル読み取り専用メモリ（ＰＲＯＭ）、又はそれらの様々な組み合わせであり得る。
【0299】
メモリ１１０４は、例えば、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、コンパクトディスク読み取り専用メモリ（ＣＤＲＯＭ）、電気光学メモリ、磁気光学メモリ、消去可能プログラマブル読み取り専用メモリ（ＥＰＲＯＭ）、及び電気消去可能プログラマブル読み取り専用メモリ（ＥＥＰＲＯＭ）、強誘電性ＲＡＭ（ＦＲＡＭ）などの内部又は外部のいずれかに位置する様々なタイプのコンピュータメモリの組み合わせを含み得る。
【0300】
各Ｉ／Ｏインターフェース１１０６は、コンピューティングデバイス１１００が、キーボード、マウス、カメラ、タッチスクリーン、及びマイクロフォンなどの１つ以上の入力デバイス、又はディスプレイ画面及びスピーカなどの１つ以上の出力デバイスと相互接続することを可能にする。
【0301】
各ネットワークインターフェース１１０８は、コンピューティングデバイス１１００が、インターネット、イーサネット、プレーンオールドテレフォンサービス（ＰＯＴＳ）回線、公衆交換電話ネットワーク（ＰＳＴＮ）、統合サービスデジタルネットワーク（ＩＳＤＮ）、デジタル加入者回線（ＤＳＬ）、同軸ケーブル、光ファイバ、衛星、モバイル、無線（例えば、Ｗｉ－Ｆｉ、ＷｉＭＡＸ）、ＳＳ７信号通信ネットワーク、固定回線、ローカルエリアネットワーク、ワイドエリアネットワーク、及びこれらの様々な組み合わせを含む他のものを含むデータを搬送し得るネットワーク（又は複数のネットワーク）にコネクションすることによって、他の構成要素と通信し、他の構成要素とデータを交換し、ネットワークリソースにアクセス及びコネクションし、アプリケーションを提供し、他のコンピューティングアプリケーションを実行することを可能にする。
【0302】
単純化のみのために、１つのコンピューティングデバイス１１００が示されているが、システム１００Ｂは、複数のコンピューティングデバイス１１００を含んでもよい。コンピューティングデバイス１１００は、同じ又は異なるタイプのデバイスであり得る。コンピューティングデバイス１１００は、直接結合される、ネットワークを介して間接的に結合される、広地理的領域にわたって分散される、ネットワーク（「クラウドコンピューティング」と称され得る）を介して接続されることを含む様々な方法で接続され得る。
【0303】
例えば、限定されないが、コンピューティングデバイス１１００は、サーバ、ネットワークアプライアンス、セットトップボックス、組み込みデバイス、コンピュータ拡張モジュール、パーソナルコンピュータ、ラップトップ、パーソナルデータアシスタント、携帯電話、スマートフォンデバイス、ＵＭＰＣタブレット、ビデオディスプレイ端末、ゲームコンソール、又は本明細書に記載される方法を実行するように構成することが可能な様々な他のコンピューティングデバイスであり得る。
【0304】
出願人は、記載された実施形態及び実施例が例示的であり、非限定的であることを強調しておく。特徴の実用的な実装態様は、態様のいくつか又は全ての組み合わせを組み込んでもよく、本明細書に記載される特徴は、将来的又は既存の製品計画の指標と捉えられるべきではない。
【0305】
「接続された」又は「結合された」という用語は、直接結合（互いに結合された２つの要素が互いに接触する）及び間接結合（少なくとも１つの追加の要素が２つの要素の間に位置する）の両方を含み得る。
【0306】
実施形態は詳細に説明されているが、本明細書では、範囲から逸脱することなく、種々の変更、置換、及び改変を行うことができることを理解されたい。更に、本出願の範囲は、本明細書に記載されるプロセス、機械、製造、物質の組成、手段、方法及びステップの特定の実施形態に限定されることを意図しない。
【0307】
前述の説明を通して、パケットコントローラ、サーバ、インスタンス、インターフェース、ポータル、プラットフォーム、又はコンピューティングデバイスから形成された他のシステムに関して、多数の参照がなされ得る。そのような用語の使用は、コンピュータ可読有形非一時的媒体に記憶されたソフトウェア命令を実行するように構成された少なくとも１つのプロセッサを有する１つ以上のコンピューティングデバイスを表すとみなされることを理解されたい。例えば、パケットコントローラは、ソフトウェア製品の形態で、記載された実施形態の技術的ソリューションを実装し得る。ソフトウェア製品は、ＣＤ－ＲＯＭ、ＵＳＢフラッシュディスク、又はハードディスク（リムーバブル又はその他）であり得る不揮発性又は非一時的記憶媒体に記憶され得る。ソフトウェア製品は、コンピュータデバイス（例えば、パケットコントローラ、又はネットワークデバイス）が実施形態によって提供される方法を実行することを可能にするいくつかの命令を含む。
【0308】
理解され得るように、上記に記載され、例示される実施例は、例示的なものにすぎないことが意図される。
【図1A】
【図1B】
【図1C】
【図1D】
【図1E】
【図1F】
【図2】
【図3】
【図4A】
【図4B】
【図4C】
【図4D】
【図5A】
【図5B】
【図6A】
【図6B】
【図6C】
【図6D】
【図6E】
【図7】
【図8A】
【図8B】
【図8C】
【図9A】
【図9B】
【図9C】
【図10A】
【図10B】
【図11】
【国際調査報告】