JP4448341B2 - 帯域制御プログラム、方法およびエンド・システム - Google Patents

Description

本発明は、一般的にはネットワーク通信に関し、詳細にはネットワーク通信における使用帯域幅の制御に関する。

ビデオやオーディオプレーヤといったストリーミングのような、現在のマルチメディア・アプリケーションの多くは、元々は接続されたローカルの記憶装置（たとえば、ＣＤまたはハードディスク）から、または高品質低遅延のネットワーク（たとえば、負荷が僅かなローカルエリアネットワークまたはＬＡＮ）上で実行するように設計されている。

しかし、ＷＡＮ（wide-area network）のような低品質のネットワーク上で実行する場合には、ネットワークの輻輳から生じるパケットロスまたは遅延が、マルチメディア・アプリケーションの十分なリアルタイム実行を阻害し、しばしば粗末なユーザ・エクスペリエンス（user experience）を提供し、しばしばサービス品質（ＱｏＳ：Quality of Service）が悪いと評される。たとえば、ビデオフレームが損失し、またはビデオとオーディオの同期が崩れ、品質の悪いマルチメディア性能の結果となる。

これらの問題を解決するために、現在のマルチメディア・アプリケーションの一部は、ネットワークの状態に応じた送信レートに適合するように開発されている。一つの解決策は、パケットロスの検出に応答して送信レートを変更する。特に、マルチメディアのストリーミングのようなリアルタイム・アプリケーションについては、リアルタイム・プロトコル（ＲＴＰ：Real Time Protocol）が、リアルタイム制御プロトコル（ＲＴＣＰ：Real Time Control Protocol）とともに指定され、パケットロス検出に基づいてＱｏｓを監視し関連する情報を運ぶ。他の解決策は、データ損失を防止または低減を期待してネットワーク装置内にバッファされるパケットの数を増加させる。これらのバッファ機構と共に誤り訂正（ＦＥＣ：Forward Error Correction）もまた採用されている。さらに他の解決策では、「ボトルネック」となるリンクの見込帯域幅を推定し、それにしたがって送信レートの固定的な設定を試みる。

しかしながら、これらの既存の解決策では不十分である。なぜなら、最初の解決策は、パケットロスの検出を前提とするため、最初のパケットロスが発生してから、問題の解決を試みるまでに時間がかかり、粗末なユーザ・エクスペリエンスを避けることができない。バッファを増やす２番目の解決策は、データロスを、大きな送信キューに起因して増加する遅延に置換する。さらに、２番目の解決策は、音響・映像関連の携帯電話や腕時計など制限されたバッファメモリを備えた装置に対して問題となる。３番目の解決策は、本質的に（無線リンクのような）可変帯域幅のボトルネックまたは複数のアプリケーションがボトルネックの利用可能な帯域幅を共有することによって発生する輻輳の動的変化を解決しない。

さらに、詳細には受動的な帯域幅制御であって、リアルタイム通信の初期輻輳に応答し、マルチメディア・アプリケーション内に一般的に採用されている帯域幅制御を扱う既存の解決策は存在しない。

本発明の実施形態は、変動する遅延に敏感なマルチメディア（elastic-delay-sensitive multimedia）に適したフィードバックを用いて、利用可能なネットワーク帯域幅についての重み付け公平割当（weighted fair-share）を追跡することによって、前述の問題を解決する。システムが、ネットワークの初期輻輳を検出し送信側へ情報をフィードバックすることで、送信側がネットワーク内の初期輻輳に適応する。初期輻輳は、まだ起こっていない（たとえば、まだパケットロスまたは許容外の遅延に至っていない）輻輳を対象とする。この情報に基づき、送信レートは適切に変更される。制御アルゴリズムは、重みパラメータ、利得パラメータおよび輻輳レポートからの情報に基づいて変更後の送信レートを計算する。変更後の送信レートは、送信側の利用可能な帯域幅の使用を改善し、受信側の許容サービス品質を守る。

本発明の実施において、製品と同種物（articles）がコンピュータプログラムとして提供される。コンピュータプログラムの一実施形態は、コンピュータによって読み取り可能なコンピュータプログラム記憶媒体を含み、中間装置によって検出された資源の初期輻輳の指示に基づき、利用可能資源に対する資源利用者による資源要求を調整するコンピュータプログラムが符号化されている。コンピュータプログラムの別の実施形態は、コンピュータシステムによって搬送波中に具現化されたコンピュータデータ信号中に提供されることができ、利用可能資源に対する資源利用者による資源要求を調整するコンピュータプログラムが符号化されている。

コンピュータプログラムにより、中間装置によって検出された資源の初期輻輳の指示に基づいて、利用可能資源に対する資源利用者による資源要求を調整するためのコンピュータ処理をコンピュータシステム上で実行する。重みパラメータは、資源利用者と関連付けられた利用可能資源の公平な割り当ての関係を決定する。資源の初期輻輳の指示は受信される。利得パラメータは、中間装置を通じて資源利用者によって送信される資源要求の調整の大きさに関係し、資源の初期輻輳の指示に基づいて決定される。新たな資源要求は、重みパラメータおよび利得パラメータに基づいて計算され、利用可能資源の資源消費者による使用が調整される。

別の実施形態では、利用可能資源に対する資源消費者による資源要求の調整方法は、中間装置によって検出された資源の初期輻輳の指示に基づいて提供される。重みパラメータは、資源消費者と関連付けられた利用可能資源の公平な割り当ての関係を決定する。資源の初期輻輳の指示は受信される。利得パラメータは、中間装置を通じて資源利用者によって送信される資源要求内の調整の大きさに関係し、資源の初期輻輳の指示に基づいて決定される。新たな資源要求は、重みパラメータおよび利得パラメータに基づいて計算され、利用可能資源の資源消費者による使用が調整される。

さらに別の実施形態は、資源の初期輻輳の指示をネットワーク内の送信側へ提供する方法に関する。資源の初期輻輳の指示は、ネットワーク内の中間装置によって提供されたＥＣＮマーキング情報（Explicit Congestion Notification）を基盤とする。中間装置から受信したＥＣＮマーキング情報は追跡される。ＥＣＮマーキング情報を複号し、追跡動作に反応する、資源の初期輻輳を示す輻輳レポートを生成する。輻輳レポートは、送信側へ通信される。

別のコンピュータプログラムの実施形態は、ネットワーク内の送信側へ資源の初期輻輳の指示を提供する。資源の初期輻輳の指示は、ネットワーク内の中間装置によって提供されたＥＣＮマーキング情報に基づく。中間装置から受信したＥＣＮマーキング情報は追跡される。ＥＣＮマーキング情報を復号し、追跡動作に応答して、資源の初期輻輳を示す輻輳レポートを生成する。輻輳レポートは、送信側へ通信される。

さらに別の実施形態では、エンドシステム（end system）は、受動帯域幅制御（reactive bandwidth control）を備え、中間装置によって検出された資源の初期輻輳の情報に基づいて、利用可能資源に対する資源消費者による資源要求を調整する。ネットワークトランスポート層モジュールは、資源の初期輻輳の指示を受信する。ＷＴＰ（weight-per-mark）モジュールは、資源利用者と関連付けられた利用可能資源の公平割当に関係する重みパラメータを決定する。ＷＴＰモジュールはまた、資源の初期輻輳の指示に基づいて、中間装置を通じて資源利用者によって送信された資源要求内の調整の大きさに関係する利得パラメータを決定する。ＷＴＰモジュールはさらに、重みパラメータおよび利得パラメータに基づいて新たな資源要求を計算し、利用可能資源の資源消費者による使用を調整する。

さらに別の実施形態では、エンド・システムは、ネットワーク内の送信側へ資源の初期輻輳の指示を提供する。資源の初期輻輳の指示は、ネットワーク内の中間装置によって提供されたＥＣＮマーキング情報に基づく。マーキングフィードバックコーデックは、ＥＣＮマーキング情報を復号し、資源の初期輻輳を示す輻輳レポートを生成する。マーキング追跡モジュールは、中間装置から受信したＥＣＮマーキング情報を追跡し、ＥＣＮマーキング情報をマーキングフィードバックコーデックへ導く。

本発明を特徴づけるこれらおよび様々な他の機能および他の利点は、続く詳細な説明および対応する図面を精読することにより明らかにされる。

ネットワーク上のリアルタイム通信は調整され、初期輻輳状態におけるＱｏＳを改善する。システムは、ネットワークの初期輻輳を検出し、初期輻輳に関する情報を送信側へフィードバックする。この情報に基づき、送信レートは、制御アルゴリズムを用いて適切に変更される。制御アルゴリズムは、重みパラメータ、利得パラメータおよび輻輳レポートからの情報に基づいて変更後の送信レートを計算する。変更後の送信レートは、送信側の利用可能な帯域幅の使用を改善し、受信側の許容サービス品質を守る。受動帯域幅制御は、これらに限定するものではないが、無線ネットワークにおける送信電力の制御、分散コンピューティングアプリケーションの処理要求の調整、およびストレージアプリケーションにおける記憶要求の調整を含む、種々のシナリオに適用し得ると理解されるべきである。一般的に、汎用資源の使用を、資源の初期輻輳（たとえば、過負荷）の指示に応じて制御することができる。

多くのネットワーク通信を、「リアルタイム」または「非リアルタイム」通信に分類することができる。たとえば、ＨＴＭＬ（Hyper Text Markup Language）文書を転送するＨＴＴＰ（Hyper Text Transfer Protocol）レスポンスのように、ファイル転送は非リアルタイム通信と考えることができる。ＴＣＰ（Transmission Control Protocol）は、多くの非リアルタイム・アプリケーションにおいて、通信を十分に制御できる。ＴＣＰは、最も一般的なトランスポート層のプロトコルであり、その下の層に位置しているＩＰ（Internet Protocol）上に配置されている。それにより、ＴＣＰ／ＩＰとは、「Transmission Control Protocol over Internet Protocol」を意味する。ＴＣＰはコネクション型で、ＩＰパケット交換ネットワーク上で信頼性のある通信を提供する。ネットワークの輻輳または他の通信イベントによってパケットロスが発生する場合は、ＴＣＰはパケットロスを検出し、パケットロスについての情報をフィードバックし、送信側が損失したパケットを所期の受信側へ再送信するためのアルゴリズムを指定する。この方法で、ＴＣＰは、送信側と受信側との間の１００％信頼できる通信を目標とし、これはファイル転送アプリケーションについては重要である（たとえば、損失したパケットの通信に失敗すると、受信側では破損したファイルを受信したことになる）。

しかし、多くのマルチメディア・アプリケーションは、リアルタイム・ストリーミングメディア・アプリケーションであり、タイムリーにデータパケットを受信することが、アプリケーションの適切な実行のためには重要となる。加えて、１００％の信頼は要求されない。パケットの遅延到着または再送を見越してマルチメディア・アプリケーションを遅らせるよりも、送信されたパケットあるいは大幅に遅延したパケットを失う方が一般的に好ましい。たとえば、ビデオストリームのパケットが送信中に損失または大幅に遅れた場合に、受信側が最終的にエラーパケットを受信できるようにビデオデータの再生を中断するよりも、後に続くデータのストリーミングを続けることの方がより重要である。

これにより、多くのリアルタイムネットワーク通信は、ＵＤＰ（User Datagram Protocol）に依存している。ＵＤＰは、インターネットのネットワーク層、トランスポート層、およびセッション層に対応する通信プロトコルである。ＴＣＰ同様、ＵＤＰはＩＰと共に使用される。しかし、ＴＣＰと異なり、ＵＤＰはコネクションレスであり、信頼性のある通信を保証しない。エラーの処理および配信の信頼性のチェックは、必要に応じて、受信するアプリケーションに委ねられている。

図１は、本発明の実施形態における例示的なエンド・エンド・システムの概要を示す図である。ＷＡＮ１００が示されているが、本発明の実施形態は、ＬＡＮを含む他の種類のネットワークに適用できる。ＷＡＮの帯域幅使用は、通常ネットワークのバックボーンに向かって減少する。一般的に、ボトルネックは、一方のリンクと他方のリンクとの間の帯域幅に大きな不均衡があるところでしばしば見られる。この不均衡は典型的に、帯域幅のより狭いリンクが過負荷となる場合に、過度のパケットキューイングをもたらす。したがって、ボトルネックはしばしば、アクセス・リンク（access link）（たとえば、ＬＡＮが比較的混雑していないネットワーク・セグメントまたは基幹ネットワークとＷＡＮの接続点）に存在する。たとえば、企業のイントラネット内のＤＳＬ（Digital Subscriber Line）コネクションまたは細い専用線が、典型的なボトルネックである。

第１のエンド・システム１０１は、ネットワーク１００に結合されており、カメラ１０４から被写体１０８のビデオデータを受信している。ディスプレイ１１２は、エンド・システム１０２から受信したビデオデータストリームから被写体１１０を表示する。第２のエンド・システムは、ネットワーク１００に結合されており、カメラ１０６から被写体１１０のビデオデータを受信している。ディスプレイ１１４は、エンド・システム１０１から受信したビデオデータストリームから被写体１０８を表示する。例示的なエンド・システムは、汎用コンピュータまたは携帯型装置（handheld device）とすることができるが、キヨスク通信（communication kiosks）、携帯電話および他の特定用途装置を含む他のエンド・システムも、本発明の範囲内であると予定している。さらに、ネットワーク１００は、２以上のエンド・システムを相互に通信的に接続し、複数の送信エンド・システムおよび受信エンド・システムを所与の通信セッションに参加させることができる。

続く説明は、ビデオデータストリームが送信エンド・システム１０１から発生し、受信エンド・システム１０２上で被写体１０８が表示されるまでに焦点を当てる。しかし、逆方向のビデオデータストリームがエンド・システム１０２から発生し、エンド・システム１０１上で被写体１１０が表示され、本発明にしたがって制御されることも理解されるべきである。また、本発明にしたがって制御されている対応するオーディオデータストリームが、ビデオデータストリームと対をなしてエンド・システム間で通信されていることも理解されるべきである。

ネットワーク１００上で、２つのエンド・システム１０１と１０２との間で、少なくとも１つのルータ１１６が動作し、ネットワークの初期輻輳を検出する。図示の実施形態において、ルータ１１６は輻輳を検出する中間ネットワーク装置の例である。他の例示的中間ネットワーク装置は、限定するものではないが、ゲートウェイ（gateway）、ファイアウォール（firewall）、およびプロキシサーバ（proxy server）を含むことができる。参照符号１１８のような線図は、ルータ１１６が他のネットワーク装置を含む他の通信フローから発生するデータを受信および転送することができることを示している。このような通信フローの全ては、ルータ１１６によって検知される輻輳に影響を与える。

図示の実施形態では、ルータ１１６は、ＥＣＮ（Explicit Congestion Notification）マーキングをサポートし、ＥＣＴ（ECN Capable Transport）データ・フローのためにパケットにマーキングする。実施形態の一部において、ＥＣＴデータ・フローは、ＩＰフロー基盤上に指定される。したがって、エンド・システム１０１とエンド・システム１０２との間のＥＣＴデータ・フローを識別するための通知プロトコルが、エンド・システム１０１のような送信エンド・システムとエンド・システム１０２のような受信エンド・システムとの間に存在する。送信動作は、ネットワーク内の利用可能な帯域幅（即ち、資源）を消費するため、送信エンド・システム１０１は、「資源消費者（resource consumer）」と称される場合がある。

マルチメディアストリームの送信側の能力として、送信エンド・システム１０１は、自身がＥＣＴ装置であることを示すことで、初期輻輳に反応することができることを告知する。応答内で、受信エンド・システム１０２は、自身もＥＣＴ装置であることを告知する。このように、受信エンド・システム１０２は、入力ビデオデータストリームから検出されるＥＣＮ情報をフィードバックすることに合意する。その合意によって、それらのエンド・システムがビデオデータストリームの受動帯域幅制御に順応することが可能になる。それ以降、送信エンド・システム１０１は、ＥＣＴフラグをそのセッションの全ての送信ＩＰパケット上に設定して、ルータ１１６がＥＣＴデータ・フローのためにパケットにマーキングすることができる旨をルータ１１６へ通知する。

あるいはまた別の実施形態では、送信エンド・システムからの全ＥＣＮ通知は、ＥＣＴとしてマーキングされている。この実施形態では、送信エンド・システム１０１は、受信したいずれの輻輳レポートにも反応することができる。輻輳レポートを受信していない場合、送信エンド・システム１０１は、輻輳が無いためまたはＥＣＴの受信側が無いために間隔があいているかどうかを識別する必要ない。送信側の部分での振舞いに変更を要しない。

一実施形態では、ルータ１１６が初期輻輳を検出すると、ルータ１１６は、ＥＣＮフラグを設定することでＩＰパケットにマーキングし、「輻輳発生中（ＣＥ：congestion Experienced）」を指示する。ＥＣＮマーキングは、ＩＰヘッダ中の予約された２ビットを使用する。２つのＥＣＮビットは、ＩＰｖ６のクラスオクテットに対応する旧Ｔｏｓバイト（Ｔｙｐｅ ｏｆ Ｓｅｒｖｉｃｅ ｂｙｔｅ）中に正式に予約されたフィールドである。ＴｏＳバイトは、現在はＤｉｆｆＳｅｒｖ（ＤＳ：Differentiated Services）フィールドとして定義されていて、最初の６ビットがＤＳフィールドを形成し、最後の２ビットは試験的使用が認められている。これら最後の２ビットが用いられて、輻輳通知が符号化される。２ビットのうち本質的に、１ビットが現時点の可能性を示す輻輳情報のために符号化され、不正ＥＣＮ（ECN cheating）が検出されることを可能にするある形式を可能にする（たとえば、不正には輻輳通知の取り消しを含む）。本実施形態では、符号化は、以下のように定義される、１ビットのみまたは２ビット以上を含む方法で符号化することを含む他の特定の符号化が本発明の範囲から逸脱するものではない。
１．送信エンド・システム１０１は、ＥＣＮビットを（００）にセットし、送信側がＥＣＮ対応ではないことを示す。
２．送信エンド・システム１０１は、ＥＣＮビットを（０１）または（１０）に設定し、送信がＥＣＮ対応であることを示し、つまり「ＥＣＴフラグを設定」する。エンド・システムは、特別ストラタジを呼び出し特定のビット（０１）または（１０）を選択することができる。たとえば、
ａ．常に（１，０）を選択し、（０，１）を他の用途に認める。
ｂ．擬似ランダムアルゴリズムを起動して、（１，０）と（０，１）との間でランダムに選択し、可能性無しの状態を作り出す。
３．ルータ１１６はＥＣＮビットを（１，１）に設定し、初期輻輳の検出を指示する。

パケットがルータ１１６の出力キューに到達すると、ルータ１１６は、現在の輻輳状態に基づき３つの可能な転送動作の内の１つを実行することを決定する。
１．パケットを変更せず転送する。
２．ＥＣＮビットを（１１）へ変更してパケットを転送する。
３．パケットを廃棄する。

ルータ１１６は輻輳指示の閾値を超えた場合、ネットワークの初期輻輳を検出したとみなす。このＣＥ状態が存在している間は、ルータ１１６は、各パケットを受信側へ向けて転送する前に、ＩＰパケットに「マーキング」してＣＥ状態であることを指示する。例示的なＥＣＮ対応のルータは、Ｃｉｓｃｏ社のＩＯＳリリース１２．２．８（４）またはそれ以降を含む。検出およびマーキングの実装は、限定するものではなく、ランダム初期検知（ＲＥＤ：Random Early Detection）または仮想キュー（Virtual Queue）のような種々のアクティブキュー管理方法（ＡＱＭ：Active Queue Management）を含む種々の技術を包含する。

マーキングされたパケットを受信すると、受信エンド・システム１０２は、一定期間フィードバックを送信エンド・システム１０１へ送信し輻輳のマーキングを受信していることを示す。このフィードバック（たとえば、輻輳レポート）に基づき、ルータ１１６の帯域幅使用をより最適化する試みのなかで、送信エンド・システム１０１は伝送速度を変更（高くまたは低く）する。この変更の最終目標は、ルータ１１６でのネットワークの輻輳によって発生するパケットロスを最小になるかまたはパケットロスがない、最も高い送信レートを発見することである。

図２は、本発明の実施形態における例示的なエンド・システムを示す。エンド・システム２００は、ネットワーク２２０を介して、他のエンド・システム（図示しない）と結合される。少なくとも１つのネットワーク中間装置（図示しない）が２つのエンド・システムの間に論理的に配置されている。エンド・システムは、ユーザインタフェース２０２を通じてマルチメディア情報を描画する描画部（renderer）２１６、およびアナログのマルチメディア情報をデジタル化するデジタイザ２１８を含む。マルチメディアコーデック２０４は、デジタイザ２１８からデジタル化されたマルチメディア情報のほか、ネットワーク２２０および別のエンド・システムからＲＴＰ（Real Time Protocol）モジュール２０８を通じて受信したマルチメディア情報も受信する。さらに、マルチメディアコーデック２０４は、マルチメディアデータをＲＴＰモジュール２０８およびネットワーク２２０を通じて別のエンド・システムへ送信する。

ネットワークトランスポート層モジュール２２２は、マーキング／マーキング追跡モジュール２２４を含み、送信エンド・システムが送信するＩＰパケットにＥＣＴとしてマーキングし、受信エンド・システムが入力パケットからＥＣＮのマーキングを追跡し、それらをマーキングフィードバックコーデック２１２へ導く。

ＲＴＣＰ（Real Time Control Protocol）モジュール２１０は、ＥＣＴパケットを復号するためおよび送信エンド・システムへ送り返すための輻輳レポートを符号化するためのマーキングフィードバックコーデック２１２を含む。マーキングフィードバックコーデック２１２によって復号されたマーキング情報は、ＷＴＰ（weight-per-mark）モジュールによって受信され、マーキング情報に基づいて利用可能な帯域幅を推定する。推定された利用可能な帯域幅の値はメディア・コントローラへ渡され、推定利用可能帯域幅および発見的（heuristics）手法に基づいて、ネットワークのデータの負荷を変更するためにメディアに特別の動作をさせる。図示の実施形態では、メディア・コントローラは、マルチメディアコーデック２０４を通じて送信レートを、または送信レートに関係するデジタイザ２１８を通じて送信レートに対する描画の正確さを推定された利用可能帯域幅に合わせて調整することができる。

メディア・コントローラは、送信レートを調整するために種々の方法を使用する。たとえば、一実施形態では、コーデックは、直接に量子化レベルを変更して質を調整し、これによって送信レートを変更することができる。別の実施形態では、ある階層符号化方式が用いられている場合、メディア・コントローラは、レイヤを増減して、送信レートを変更することができる。他の実施形態では、頻繁な送信レートの変更を避けるため、メディア・コントローラは、推定利用可能帯域幅が前回の推定と十分に異なる場合にのみ、送信レートの変更を決定する場合がある。

図３は、本発明の実施形態における例示的中間装置を示す。ルータのような中間装置は、一般的に、入力ＥＣＴパケットを受信し、可能であればそれらにマーキングして、それらを宛先のシステムへ転送する。ネットワークの輻輳が破棄を正当化する場合、中間装置はパケットを破棄することもできる。

中間装置３００は、メモリ中のキューのような物理的パケット・キュー３０２を備える。入力パケット３０８は物理的パケット・キュー３０２内に受信される。また、中間処理装置３００は、パケットマーキング仮想キュー３０４を備え、物理的パケット・キュー３０２内の入力パケットを追跡する。仮想キュー３０４中のパケット３１０の数が事前に設定された輻輳の閾値３１２を超過する場合、パケット管理モジュール３０６は、閾値３１２を超えて受信されるパケットに、それらを宛先のシステムへ転送する前に、マーキングする。また、本発明の範囲内で、他のマーキングのアルゴリズムを初期輻輳の信号として採用することもできると理解されるべきである。

図４は、本発明の実施形態において、種々の装置間のメッセージ送信および動作を示す。図４は、送信エンド・システム、中間装置および受信エンド・システムを解して通信されるように示されている。中間装置は、ルータ、ゲートウェイなどを含む複数の中間装置を一まとめにして示されていると理解されなければならない。

示されたＲＴＣ（Real Time Control）セッション４２０において、ＥＣＴ指示動作４００は、１つまたは複数の受信側に、送信エンド・システムがＥＣＴ装置であることを広報する。これは、上述したように最初のスタートアップの間にＥＣＴフラグを設定することによって行われる。受信エンド・システムにおけるＥＣＴ受信動作４０２は、送信エンド・システムからＥＣＴ広報を受信し、ＥＣＴ指示動作４０４の中で応答し、送信エンド・システムへ受信エンド・システムもＥＣＴ装置であることを通知する。この通知は、ＥＣＴ受信動作４０６中で送信エンド・システムによって受信される。先に述べたように、あるいはまた送信エンド・システムは、動作４００、４０２、４０４および４０６を省略することによって受信エンド・システムが特定のデータ・フローの状態にあると仮定することができる。

送信エンド・システムが、ＥＣＴ受信動作４０６中でこの信号を受信エンド・システムから受信すると、送信エンド・システムは、受信エンド・システムとＥＣＴデータ・フローが確立されたと判定し、特定のＩＰデータ・フローがＥＣＴデータ・フローであるとの理解のもとに先に進む。その後、送信動作４０８は、伝送されるＩＰパケット中のＥＣＴビットを（１０）または（０１）に設定することによって、１つまたは複数のＥＣＴパケットを送信する。これらのＥＣＴパケットは、最初の送信レートで伝送される（すなわち、「資源要求」の種類に応じた）。一実施形態では、最初の送信レートは、最初の推定利用可能帯域幅、ユーザの入力、およびシステムの設定あるいはポリシーのうちの少なくとも１つに基づく。他の例示的な資源要求は、限定するものではないが、（無線システムでは）電力要求、メモリまたは処理要求などを含む。関連したオーディオとビデオのような２つのＲＴＰフローがある場合は、各フローのパケットは、この方法でマーキングされる。一部の実施形態では、ＲＴＣＰ帯域幅の使用を、ＲＴＣによって管理することができ、ＲＴＣＰ制御フローが「ＥＣＮを意識して」マーキングされることを可能にする。

マーキング動作４１０では、資源の初期輻輳を検出すると、中間装置は、ＥＣＴパケットにマーキングして「輻輳発生中」を指示し、受信エンド・システムへパケットを転送する。受信動作４１２では、受信エンド・システムは、マーキングされたパケットを受信する。編集動作４１３において、受信エンド・システムは、マーキングされたパケットから輻輳レポートを生成する。フィードバック動作４１４では、受信エンド・システムは輻輳レポートを送信エンド・システムへ送信する。動作４０８、４１０および４１２は、フィードバック動作４１４が起こった後に、複数回起動することができる（すなわち、輻輳レポートが送信エンド・システムへ伝送する前に、マーキングされた複数のパケットからの情報を編入することができる）。これらの動作におけるエンド・システム間のＥＣＴ通信の潜在的（かつ有望な）多様性は、図のデータ・フロー中の太い矢印で示されている。さらに、種々の実施形態において、編集動作４１３は、マーキングされたパケットの各々の受信とともに起動するか、または種々の間隔で起動することができる。

受信エンド・システムは、ＲＴＣＰ制御チャネルを通じて輻輳レポートを送信エンド・システムへ送信する。一実施形態では、輻輳レポートは、次表の形態とすることができる。

輻輳レポートは、受信エンド・システムで受信レポート（ＲＲ：Receiver Report）が宛先ＲＴＣセッションによって生成されると、送信される。この拡張ＥＣＮは、ＲＲ間隔中の変化に対して強く、固定のＲＲ間隔に束縛されず、帯域幅の利用可能性が増したことを迅速にレポートすることを確保する。別の実施形態では、Marks、Id_num、Proto、およびDestportフィールドを削除して、ＲＴＣＰ受信レポートのための１６バイトの現実のオーバヘッドを与えることができる。

受信動作４１６は、輻輳レポートを受信して、（マーキングフィードバックコーデック内で）輻輳レポートを復号して、帯域幅を推定するＷＴＰモジュールへ受信した情報を渡す。推定動作４１７で、ＷＴＰ（weight-per-mark）モジュールは、最初の推定、輻輳レポート内で報告された状態、および種々の他の接続パラメータに基づいて、新しい推定利用可能帯域幅を計算する。この新しい推定利用可能帯域幅は、関連したＳＳＲＣ（Synchronization Source）のためにメディア制御モジュールへ報告される。ＳＳＲＣは、新しい推定利用可能帯域幅および発見的手法に基づいて（変更後の送信レートの形で）メディアに特別の動作をさせて資源要求を変更させる。本明細書中では送信エンド・システムが計算を行うが、別の実施形態では、新しい推定利用可能帯域幅および新たな資源要求を、受信エンド・システム、中間装置、もしくは個別の調整装置または輻輳マネージャで計算してもよい。

ＷＴＰモジュールは、ＷＴＰアルゴリズムを実行して輻輳レポートに応じた新しい推定利用可能帯域幅を推定する。送信エンド・システム（たとえば、トラヒック源あるいは送信側）は、測定時間間隔ｎ^ｔｈの間に平均ｘ_ｎの固定レートでＥＣＴパケットを送信する。ここで、測定時間間隔（Measurement Time Interval）の長さはＭＴＩである。受信エンド・システム（たとえば、トラヒックの宛先あるいは受信側）は、マーキングされたパケットの数ｍ_ｎおよび測定時間間隔に送信されたパケットの数ｓ_ｎの双方を送信側へレポートする。輻輳レポート情報から読み出されるそれら２つの比は、マーキングに対応している確からしさの推定（ｐ_ｎ）を表す。

一実施形態では、仮想キューマーキングアルゴリズムを採用する。実際の資源の量よりも小さな量をもつ仮想キューが模造される。少なくともＢ個のパケットが仮想キューに待機していると入力パケットはマーキングされる。本発明の範囲内でＢの別の値が考えられるが、たとえばＢの値は１０である。

変更後の送信レートは、輻輳レポート中に適宜受信側から送信されるフィードバックとともに、重みパラメータｗおよび利得パラメータｋを用いて送信レートを調整する制御アルゴリズムによって決定される。一実施形態では、重みパラメータｗ（ＷＴＰパラメータと称される場合もある）は、送信エンド・システムと関連付けられ、マーキングが予想される確率ｐ_{ｅｘｐｅｃｔｅｄ}に基づいて得られる目標の送信レートに影響を与える。

このように、重みパラメータは、送信エンド・システムによって予想された利用可能帯域幅の重み付け公平割当を表す。あるいはまた、重みパラメータは、次のようになる。所定の数ＮのＴＣＰ（Transmission Control Protocol）コネクションによって予想されたレートを真似てｘ_{ｔａｒｇｅｔ}を設定することによって決定することができる。以下の３つのシナリオが考えられる。ＭＳＳは、ＩＥＴＦ（Internet Engineering Task Force）のＲＦＣ８７９で定義されるように、ＴＣＰに対する最大セグメントサイズをバイト単位で表し、これはＩＰの最大データグラムのサイズから４０を引いたサイズである。このＭＳＳパラメータは、ＴＣＰのオプションとして設定することができ、その結果、ＭＳＳは送信側と受信側との間のＴＣＰコネクションのＭＳＳに関連させることができる。ＭＳＳのデフォルト値は、ＴＣＰのオプションを設定しない場合は５３６である。

重みパラメータは、アプリケーション毎またはシステム毎のポリシーによって設定することができる。また、ユーザの入力を含む他の実行パラメータによっても影響を受ける場合がある。

この重みパラメータに基づいて、新しい送信レートｘ_ｎ＋１が次式のように計算される。

利得パラメータｋが次の２つの条件を満たす場合、上記のアルゴリズムは目標のレート近傍で、局所的に安定した新しい送信レートを提供する。

ここで、ｒはＭＴＩ間隔のＲＴＴ（Round Trip Time：往復時間）間隔に対する比である。したがって、ｋの許容値は次式で計算することができる。

利得パラメータは、資源の初期輻輳の指示に基づいて中間装置を通じて送信エンド・システムによってなされる資源要求における調整の大きさ（つまり、送信レート）に影響を与える。

より小さい送信レートに対しては、上記式によって返されるｘ_ｎ＋１の最大値および予め決められた最小のレートを用いることよって、より良い新しい送信レートが得られる。

図５は、本発明の実施形態におけるデータストリーミング環境の受動帯域幅制御の動作を示す。関係確立動作５００は、送信エンド・システムと受信エンド・システムとの間にＥＣＴ関係を確立する。他の実施形態では、この関係確立動作５００を完全に省略し、送信エンド・システムは単にＥＣＴ装置である受信エンド・システムが送信内容を受信して、何らかの初期輻輳の問題をフィードバックして報告するものと仮定することができる。

重みパラメータ決定動作５０２は、重みパラメータを決定する。使用動作５０４は、指定された資源要求で利用可能資源を使用する（たとえば、送信側は指定された初期の送信レートで送信する）。その後は、受信動作５０６は、輻輳レポートのような資源の初期輻輳の指示を受信する。利得パラメータ決定動作５０８は、利得パラメータを決定する。計算動作５１０は、新たな資源要求を計算し、それを使用動作５０４へ適用する。

図６は、本発明の実施形態において利得パラメータを設定する動作を示す。計算動作６０８は、輻輳レポートの受信に応答して新しい増加要因を計算するための複数の入力を受信する。決定動作６００は、ＲＴＰパケットが中間ネットワーク装置のキューに入ると見込まれるパケットの数を表すマーキングパラメータＢを決定する。推定動作６０２は、ＲＴＴを推定する（ＲＴＴについての凡その推定が一般的に受け入れられる）。一実施形態では、ＲＴＴは、たとえばＲＴＣＰを用いて、受信側、送信側あるいは制御チャネルの特別の手段によって推定される。別の実施形態では、ＲＴＴ推定は、指数重み付け移動平均を用いて現在の推定を先の推定と結合させるような、ＴＣＰのＲＴＴ推定方法内で用いられるのと同じ方式を基礎とすることができる。本発明の別の実施形態では、ＲＴＴを推定する他の方法を採用してもよい。

受信動作６０４は、（輻輳レポートのような）制御パケットを受信する。別の推定動作６０６は、測定時間間隔（すなわち、２つの連続する輻輳レポートの受信の間の時間）を推定する。計算動作６０８は新しい増加要因を計算し、新しい増加要因はリターン動作６１０の結果として返される。新しい利得パラメータを決定するために用いられるアルゴリズムの例が図４に関連して述べられており、利得パラメータｋは次式で解かれる。

図７は、本発明の実施形態において送信レートを更新する動作を示す。計算動作７０６および７０８は、輻輳レポートの受信に応答して新たな資源要求を計算するための複数の入力を受信する。決定動作７００は、初期の資源要求（たとえば、初期の送信レート）を決定する。たとえば、送信エンド・システムは、その値を記憶しているメモリロケーションへアクセスすることで初期の送信レートを決定することができる。

別の決定動作７０２は、現在の利得パラメータおよび重みパラメータを決定する。現在の利得パラメータは、図４および６に関して述べたように計算されことができ、重みパラメータは、事前に計算されまたは記憶された値があるメモリロケーションへアクセスするなど、ポリシーまたは他の方法によって決定される。

受信動作７０４は、輻輳レポートのような、制御パケットを受信する。制御パケットは、マーキングされたパケットの数ｍ_ｎおよびＭＴＩの間に送信されたパケットの数ｓ_ｎの双方を含むことができる。その後、計算動作７０６は、制御パケット内の情報に基づいて、新しいマーキングの基準ｐ_ｎ（すなわち、新しいマーキングの可能性の推定値）を計算する。新たな利得パラメータを決定するために使用されるアルゴリズムの例が図４に関連して述べられており、新しいマーキングの基準ｐ_ｎは次式で解かれる。

別の計算動作７０８は、新たな資源要求ｘ_ｎ＋１（たとえば、新しい送信レート）を計算する。新たな利得パラメータの決定に用いられるアルゴリズムの例が図４に関連して述べられており、新たな資源要求ｘ_ｎ＋１は次式で解かれる。

図示の実施形態の制限動作７１０では、資源要求制限、たとえばｘ_ｎ+１＝Ｍａｘ（ｘ_ｎ+１，ｘ_ｍｉｎ）が適用される。ここでｘ_ｍｉｎはエンド・システムによって認められている現在の最小資源要求を表す。リターン動作７１２は、ｘ_ｎ＋１の値を新たな資源要求の結果として返す。

図８に示す本発明の実施のための例示的なハードウェアおよび実行環境は、汎用コンピューティングデバイスをコンピュータ２０の構成に含み、処理ユニット２１、システムメモリ２２、およびシステムメモリを含む種々のシステムコンポーネントを処理ユニット２１と結合するシステムバス２３を含む。処理ユニット２１が１つしかないものあるいは複数の処理ユニットものがあり、これらは、コンピュータ２０が単一の中央処理ユニット（ＣＰＵ）を備えているまたは一般的に並列処理環境と称される複数の処理ユニットを備えているようなものである。コンピュータ２０は、従来のコンピュータ、分散コンピュータ、または他の種類のコンピュータの何れかとすることができ、本発明はこれらに限定されない。

システムバス２３は、種々のバスアーキテクチャを使用するメモリバスまたはメモリコントローラ、パラレルバス、およびローカルバスを含む幾つか種類のバス構造の何れであってもよい。システムメモリは、単にメモリと称する場合があり、ＲＯＭ（Read Only Memory）２４およびＲＡＭ（Random Access Memory）２５を含むことができる。スタートアップ時などコンピュータ２０内のエレメント間の情報転送を助けるＢＩＯＳ（Basic Input/Output System）２６はＲＯＭ２４に記憶されている。更に、コンピュータ２０は、ハードディスク（図示しない）の読み書きをするディスクドライブ２７、取り外し可能な磁気ディスク２９の読み書きをする磁気ディスクドライブ２８、およびＣＤ−ＲＯＭ（Compact Disc ROM）あるいは他の光学媒体のような取り外し可能な光ディスク３１の読み書きをする光ディスクドライブ３０を備える。

ハードディスクドライブ２７、磁気ディスクドライブ２８、および光ディスクドライブ３０は、それぞれハードディスクドライブインタフェース３２、磁気ディスクドライブインタフェース３２、および光ディスクドライブインタフェース３０によって、システムバス２３に結合されている。ドライブおよびそれらに関連するコンピュータ可読媒体は、コンピュータ２０に関するコンピュータ可読命令、データ構造、プログラムモジュールおよび他のデータの不揮発性の記憶を提供する。コンピュータによってアクセス可能なデータを記憶することができるコンピュータ可読媒体は、本発明の実施形態において、磁気カセット、フラッシュメモリカード、デジタルビデオディスク、ベルヌーイカートリッジ（Bernoulli cartridge）、ＲＡＭ、ＲＯＭなど何れの種類を使用することができると当業者によって理解されるべきである。

多くのプログラムモジュールが、ハードディスク、磁気ディスク２９、光ディスク３１、ＲＯＭ２４，ＲＡＭ２５に格納され、オペレーティングシステム３５、１つまたは複数のアプリケーションプログラム３６、他のプログラムモジュール３７およびプログラムデータ３８を含む。ユーザは、キーボード４０およびポインティングデバイス４２のような入力デバイスを通じてパーソナルコンピュータ２０へ命令および情報を入力することができる。他の入力デバイス（図示しない）は、マイクロフォン、ジョイスティック、ゲームパッド、衛星アンテナ、スキャナなどを含むことができる。これらおよび他の入力デバイスは通常、システムバスに結合されたシリアルポート４６を通じて処理ユニット２１と結合されるが、パラレルポート、ゲームポート、ＵＳＢ（Universal Serial Bus）などの他のインタフェースによって結合されることもできる。モニタ４７または他の種類の表示装置も、ビデオアダプタ４８を介してシステムバス２３へ結合されている。モニタに加えて、コンピュータは典型的に、スピーカおよびプリンタのような他の周辺出力装置（図示しない）を含む。

コンピュータ２０は、リモートコンピュータ４９のような１つまたは複数のリモートコンピュータとの論理接続を使用するネットワーク環境で作動する。これらの論理接続は、コンピュータ２０に結合されたまたはその一部となっている通信装置によって達成されるが、本発明は特定の種類の通信装置に限定されない。リモートコンピュータ４９は、別のコンピュータ、サーバ、ルータ、ネットワークＰＣ、クライアント、ピアデバイスあるいは他の一般的なネットワークノードとすることができ、図８には記憶装置５０のみが示されているが、典型的にはコンピュータ２０に関連して上述した要素の多くまたはすべてを含む。図８に示された論理接続は、ＬＡＮ（Local Area Network）５１およびＷＡＮ（Wide Area Network）５２を含む。そのようなネットワーク環境は、オフィスネットワーク、企業ネットワーク、イントラネットおよびインターネットで一般的であり、すべての種類のネットワークを含むものである。

ＬＡＮネットワーク環境で使用する場合、コンピュータ２０は、通信装置の種類の１つであるネットワークインタフェースまたはアダプタ５３を通じてＬＡＮ５１へ接続される。ＷＡＮネットワーク環境で使用する場合、コンピュータ２０は典型的に、ＷＡＮ上で通信を確立するために通信装置の種類の１つであるモデム５４あるいは他の種類の通信装置を含む。内臓あるいは外付けのモデム５４は、シリアルポートインタフェース４６を介してシステムバス２３へ接続される。ネットワーク環境では、パーソナルコンピュータ２０に関連する図示のプログラムモジュールまたはその一部は、リモートの記憶装置に記憶されることができる。示されたネットワーク接続は例示であり、コンピュータ間の通信リンクを確立する別の手段および通信装置を使用することができると理解されたい。

本発明の実施形態では、マーキングフィードバックコーデック、ＷＴＰモジュールまたはマーキング／マーキング追跡モジュールを、オペレーティングシステム３５、アプリケーションプログラム３６あるいは他のプログラムモジュール３７の一部として取り込むことができる。重みパラメータ、資源要求値、輻輳レポートおよびパケットを、プログラムデータ３８として記憶することができる。

本明細書中で述べた本発明の実施形態は、１つまたは複数のコンピュータシステム内で論理ステップとして実行される。本発明の論理的動作は、（１）１つまたは複数のコンピュータシステムで実行するプロセッサによって実行されるステップのシーケンスとして、（２）１つまたは複数のコンピュータシステム内の相互に結合されたコンピュータモジュールとして実現される。実現方法は、選択の問題であり、本発明を実施するコンピュータシステムの実行必要条件に依存する。したがって、本明細書中で述べた本発明の実施形態を示している論理的動作は、実行（オペレーション）、ステップ、オブジェクトまたはモジュール等など様々に称される。

上記の詳細、例、およびデータは、構成の完全な説明および本発明の例示的な実施形態の使用法を教示している。本発明の要旨および範囲から逸脱することなく多数の本発明の実施の形態がなされ得るから、本発明は添付の特許請求の範囲に記載している。

本発明の実施形態における例示的なエンド・エンドシステムの概観を示す図である。 本発明の実施形態における例示的エンド・システムを示す図である。 本発明の実施形態における例示的な中間装置を示す図である。 本発明の実施形態において、種々の装置間のメッセージ送信および動作を示す図である。 本発明の実施形態のデータストリーム環境における、受動帯域幅制御を示す図である。 本発明の実施形態における利得パラメータを設定するための動作を示す図である。 本発明の実施形態において、送信レートを更新するための動作を示す図である。 本発明の実施形態を実施するために有用な例示的なシステムを示す図である。

符号の説明

１００ ネットワーク
１０１、１０２ エンド・システム
１０４、１０６
１０８、１１０ 被写体
１１２、１１４ ディスプレイ
１１６ ルータ
２００ エンド・システム
２０２ ユーザインタフェース
２０４ コーデック
２０８ ＲＴＰモジュール
２１０ ＲＴＣＰモジュール
２１２ マーキングフィードバックコーデック
２１４ ＷＴＰモジュール
２１６ 描画部
２１８ デジタイザ
２２０ ネットワーク
２２２ ネットワークトランスポート層モジュール
２２４ ＥＣＴマーキング／追跡モジュール
３００ 中間装置
３０２ パケット・キュー
３０４ パケットマーキング仮想キュー
３０６ パケット管理モジュール
３０８ 入力パケット
３１０ パケット
３１２ 閾値
４２０ ＲＴＣセッション
２０ コンピュータ
２１ 処理ユニット
２２ システムメモリ
２３ システムバス
２４ ＲＯＭ
２５ ＲＡＭ
２６ ＢＩＯＳ
２７ ハードディスクドライブ
２８ 磁気ディスクドライブ
２９ 磁気ディスク
３０ 光ディスクドライブ
３１ 光ディスク
３２ ハードディスクドライブインタフェース
３３ 磁気ディスクドライブインタフェース
３４ 光ディスクドライブインタフェース
３５ オペレーティングシステム
３６ アプリケーションプログラム
３７ 他のプログラムモジュール
３８ プログラムデータ
４０ キーボード
４２ ポインティングデバイス
４６ シリアルポートインタフェース
４７ モニタ
４８ ビデオアダプタ
４９ リモートコンピュータ
５０ 記憶装置
５１ ローカルエリアネットワーク
５２ ワイドエリアネットワーク
５３ ネットワークインタフェース
５４ モデム

Claims (24)

1. 中間装置によって検出された資源の初期輻輳の指示に基づいて、利用可能な資源に対する資源消費者による資源要求を調整するためのコンピュータ処理をコンピュータシステムで実行するためのコンピュータプログラムであって、該コンピュータ処理は、
   資源消費者に関連付けられた利用可能な資源の公平割り当てに関係する重みパラメータを決定すること、
   資源の初期輻輳の指示を受信すること、
   前記資源の初期輻輳の指示に基づいて、中間装置を通じて前記資源消費者によって送信される資源要求内の調整の大きさに関係する利得パラメータｋを
   

   

   を計算して決定することであって、Ｂは中間装置のキューに入ると見込まれるパケットの数であり、ＭＴＩは２つの連続する資源の初期輻輳の指示の間の時間である測定時間間隔であり、ＲＴＴは往復時間である、こと、
   前記利用可能な資源の前記資源消費者による使用を調整するために、前記重みパラメータおよび前記利得パラメータに基づいて新たな資源要求を計算すること、および
   前記計算された新たな資源要求に基づいて前記利用可能な資源の前記資源消費者による使用を調整すること
   を含むことを特徴とするコンピュータプログラム。
2. 前記重みパラメータを決定することが、
   送信エンド・システムと関連付けられた目標資源要求に基づいて前記重みパラメータを決定すること
   を含むことを特徴とする請求項１に記載のコンピュータプログラム。
3. 前記重みパラメータを決定することが、
   予め定められた数の１つまたは複数のＴＣＰコネクション上で予測される資源要求に基づいて前記重みパラメータを決定すること
   を含むことを特徴とする請求項１に記載のコンピュータプログラム。
4. 前記資源の初期輻輳の指示を受信することが、
   輻輳レポートを受信すること
   を含むことを特徴とする請求項１に記載のコンピュータプログラム。
5. 前記資源の初期輻輳の指示を受信することが、
   測定時間間隔に受信エンド・システムによって受信されたパケット数を受信すること、および
   測定時間間隔に受信エンド・システムによって受信されたマーキングされたパケット数を受信すること
   を含むことを特徴とする請求項１に記載のコンピュータプログラム。
6. 前記新たな資源要求を計算することが、
   前記利得パラメータ、前記重みパラメータ、初期の資源要求、および前記資源の初期輻輳の指示に基づいて前記新たな資源要求を計算すること
   を含むことを特徴とする請求項１に記載のコンピュータプログラム。
7. 前記資源消費者は前記送信エンド・システムを含み、および前記資源要求は前記送信エンド・システムの送信レートを表すことを特徴とする請求項１に記載のコンピュータプログラム。
8. 前記新たな資源要求は、受信エンド・システムの能力に依存することを特徴とする請求項１に記載のコンピュータプログラム。
9. 前記コンピュータ処理は、マーキングが予測される確率を決定することを更に含むことを特徴とする請求項１に記載のコンピュータプログラム。
10. 前記マーキングが予測される確率を決定することは、前記資源の初期輻輳の指示に基づいて前記マーキングが予測される確率を推定することを含むことを特徴とする請求項９に記載のコンピュータプログラム。
11. 中間装置によって検出された資源の初期輻輳の指示に基づいて、利用可能な資源に対する資源消費者による資源要求を調整する方法であって、
    資源消費者に関連付けられた利用可能な資源の公平割り当てに関係する重みパラメータｗを
    

    

    を計算して決定することであって、ｘ _{ｔａｒｇｅｔ} は所定の数ＮのＴＣＰコネクションによって予想された送信レートであり、ｐ _{ｔａｒｇｅｔ} はマーキングが予想される確率である、こと、
    資源の初期輻輳の指示を受信すること、
    前記資源の初期輻輳の指示に基づいて、中間装置を通じて前記資源消費者によって送信される資源要求内の調整の大きさに関係する利得パラメータを決定すること、
    前記利用可能な資源の前記資源消費者による使用を調整するために、前記重みパラメータおよび前記利得パラメータに基づいて新たな資源要求を計算すること、および
    前記計算された新たな資源要求に基づいて前記利用可能な資源の前記資源消費者による使用を調整すること
    を含むことを特徴とする方法。
12. 前記ｘ _{ｔａｒｇｅｔ} は、送信エンド・システムと関連付けられていること
    を含むことを特徴とする請求項１１に記載の方法。
13. 前記ｘ _{ｔａｒｇｅｔ} は、予め定められた数の１つまたは複数のＴＣＰコネクション上で予測される資源要求に基づいていることを含むことを特徴とする請求項１１に記載の方法。
14. 前記資源の初期輻輳の指示を受信することが、
    輻輳レポートを受信すること
    を含むことを特徴とする請求項１１に記載の方法。
15. 前記資源の初期輻輳の指示を受信することが、
    測定時間間隔に受信エンド・システムによって受信されたパケット数を受信すること、および
    測定時間間隔に受信エンド・システムによって受信されたマーキングされたパケット数を受信すること
    を含むことを特徴とする請求項１１に記載の方法。
16. 前記利得パラメータを決定することが、
    マーキングパラメータ、ランドトリップ時間パラメータ、および測定時間間隔パラメータに基づいて決定すること
    を含むことを特徴とする請求項１１に記載の方法。
17. 前記新たな資源要求を計算することが、
    前記利得パラメータ、前記重みパラメータｗ、初期の資源要求、および前記資源の初期輻輳の指示に基づいて前記新たな資源要求を計算すること
    を含むことを特徴とする請求項１１に記載の方法。
18. 前記資源消費者は前記送信エンド・システムを含み、および前記資源要求は前記送信エンド・システムの送信レートを表すことを特徴とする請求項１１に記載の方法。
19. 前記新たな資源要求は、受信エンド・システムの能力に依存することを特徴とする請求項１１に記載の方法。
20. マーキングが予測される確率を決定することを更に含むことを特徴とする請求項１１に記載の方法。
21. 前記マーキングが予測される確率を決定することは、前記資源の初期輻輳の指示に基づいて前記マーキングが予測される確率を推定することを含むことを特徴とする請求項２０に記載の方法。
22. 中間装置によって検出された資源の初期輻輳の指示に基づいて、利用可能な資源に対する資源消費者による資源要求を調整することができる受動帯域幅制御を備えるエンド・システムであって、
    資源の初期輻輳の指示を受信するネットワークトランスポート層モジュールと、
    資源消費者と関連付けられた利用可能な資源の公平割当に関係する重みパラメータを決定し、前記資源の初期輻輳の指示に基づいて、中間装置を通じて資源利用者によって送信された資源要求内の調整の大きさに関係する利得パラメータを決定し、ならびに前記重みパラメータおよび前記利得パラメータに基づいて新たな資源要求ｘ _ｎ＋１ を計算し、前記計算された新たな資源要求ｘ _ｎ＋１ に基づいて前記利用可能な資源の前記資源消費者による使用を調整するＷＴＰモジュールと
    を備え、
    前記新たな資源要求ｘ _ｎ＋１ の計算は、
    

    

    を計算することを含み、ｘ _ｎ はｎ番目の測定時間間隔での資源要求であり、ｋは前記利得パラメータであり、ｗは前記重みパラメータであり、ｐ _ｎ は前記ｎ番目の測定時間間隔でマーキングされる確率の推定値であることを特徴とするエンド・システム。
23. 前記新たな資源要求を前記資源消費者に適用するメディア・コントローラをさらに備えることを特徴とする請求項２２に記載のエンド・システム。
24. 送信するＩＰパケットにＥＣＴ対応としてマーキングするマーキングモジュールをさらに備えることを特徴とする請求項２２に記載のエンド・システム。

Images