JP4233884B2 - サービス品質のプロービングを行う方法 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、サービス品質（以下、ＱｏＳ：Quality Of Serviceという）のプロービング（probing）およびネットワーク解析のシステムおよび方法に関し、より詳細には、オンラインゲーミングアプリケーションにおけるピアツーピア（以下、Ｐ２Ｐ：Peer to Peerという）ＱｏＳのプロービングおよび解析のシステムおよび方法に関する。
【０００２】
【従来の技術】
ユーザの数およびトラフィック量がインターネット上で増大し続けるにつれて、ネットワークパフォーマンスの測定規準および測定方法を利用できるようにすることが重要になる。これは、ユーザおよびネットワークサービスプロバイダの両方に、所与のインターネットパスのパフォーマンスおよび信頼性について正確な共通の理解を有することができるようにする。ユーザの側では、ネットワークパフォーマンス測定規準および測定ツールを装備すると、異なるコネクションを介してどの種類のサービスが利用できるかについて、正確な知識を有することがはるかに容易となる。この情報により、ユーザは、様々なネットワークサービスプロバイダおよびピア（Peer）の相対的なパフォーマンスを比較することができるようになる。次に、ユーザは、最良のネットワークパフォーマンスおよびオンライン体験が得られるであろうコネクションについて気の利いた決定をすることができる。同様に、ネットワークパフォーマンスの測定値からの知識は、ネットワークプロバイダ自体が、より強力なスイッチを効果的に配置してネットワーク容量を高めることができるようになる。同じく、コンテンツベースのサービスプロバイダは、この情報を使用して、自分のサービスサーバを効果的に配置しかつ管理することができる。
【０００３】
すなわち、このパフォーマンス情報を使用して、多数のインターネットサービスおよびシステムにより、Ｐ２Ｐのシステムまたはアプリケーションレベルのマルチキャストツリーに対して、強固なオーバーレイの生成を可能にすることができ、ユーザにより、多数のサーバミラーの中でサーバの選択を可能にすることができ、および、サービスプロバイダにより、サーバレプリカの配置を決定して、コンテンツ配信ネットワークのパフォーマンスを向上させることができる。オンラインのＰ２Ｐゲーミング環境では、この情報を使用してどこに追加のコネクション・サーバを配置するかを決定することができ、コンテンツプロバイダにより、追加のゲーム・サーバを効率的に配置することができる。研究団体からのインターネット測定基盤の構築における多数の提案があるにもかかわらず、このような基盤を完全に配備し、近い将来に動作可能にすることは困難である。これは、インターネットの規模および複雑さのためである。
【０００４】
オンラインＰ２Ｐゲーミング環境では、この規模および複雑さが明白である。具体的には、現在または近い将来、数百万ものゲームコンソールまたはボックスが世界中で配備される。このようなゲームボックスで、本願の出願人によって販売されるものが、Microsoft Xbox（登録商標）である。しかし、多数のゲームボックスが配備されているが、比較的少数のコネクション・サーバしか配備されておらず、これによりマルチプレイヤーゲーミングサーバおよび所望のゲームを実行する他のピアの場所およびそれらへのコネクションを容易にする。
【０００５】
コネクションの決定、すなわち、使用可能なピアおよびゲーム・サーバとしてはたらくピアのうち、プレイヤーがいずれに接続するべきかについては、プレイヤーとゲーム・サーバまたはピアとの間のネットワークパフォーマンスまたはＱｏＳを知ることが必要となる。いくつかの種類のＱｏＳパラメータがあることが知られ、こりはエンドツーエンドの遅延、帯域幅、パケット損失率などである。これらのすべての測定規準は、トレードオフを有し、そのために１つを注目するのではなく、状況を全体的に得るべきである。実際に、トレードオフは、ネットワーク上で実行する特定のゲーミングアプリケーションの要件に依存する可能性がある。
【０００６】
【発明が解決しようとする課題】
ゲーミングアプリケーションにおいて、待ち時間は、ＱｏＳ選択のための最も重要なパラメータである。ブロードバンドネットワークの配備により、ますます多くのゲームが、マルチメディア技術を利用して表現能力を向上させている。結果として、ネットワークパフォーマンス監視システムもまた、帯域幅および他のＱｏＳ要素に注意を払うべきである。しかし、現在の低レベルのネットワークパフォーマンス監視技術は、不適当である。これは、いくつかのＩＳＰ（Internet Service Provider）が、ネットワーク内でトラフィックフィルタリング技術を使用するからであり、例えば、ＩＣＭＰ（Internet Control Message Protocol）エコーパケットをブロッキングすることにより行われる。このようなパケットを使用した測定（例えば、ピング（ping）、ルートトレース（traceroute）など）は、むしろ低い精度しか達成することができず、したがって受け入れることができない。
【０００７】
さらにこの問題を複雑にするように、多数のゲームボックスが、ＮＡＴ（Network Address Translator）の背後のネットワークに配備されている。したがって、これらピア間のネットワークＱｏＳパフォーマンスを決定するために、これらピア間のプロービング・コネクションを確立しなければならない。残念ながら、ＮＡＴの特性は、それらの能力およびコネクションを快く与えることについて大きく変わる。しかし、オンラインゲーミングユーザは、異なるプロービング技術を試みる間、長い遅延を許容せず、これらピアに対するネットワークパフォーマンスを決定する。ゲームをプレイするため、あるいは所望のアプリケーションを実行するためのコネクションを生成する前のいかなる長い遅延も、ユーザの体験を損なうようになる。加えて、潜在的に数百万ものピアがネットワークで使用可能であり、各ピアが他のピアに対するネットワークパフォーマンスを決定しようと試みるときに生成される可能性のある莫大な量のプロービングトラフィックは、ネットワーク遅延を導入する可能性が非常に高い。さらに、このようなプローブの結果として生じるであろうプロービングデータの量は、ゲームボックスの使用可能なメモリを急速に満たす可能性があり、さらにゲーミングパフォーマンスを損なう。
【０００８】
【課題を解決するための手段】
上記に鑑みて、本発明は、ネットワークにおけるピア間の待ち時間を管理する、新しく改善されたシステムおよび方法を提示する。オンラインＰ２Ｐゲーミング環境では、本発明のシステムおよび方法は、よりよいゲーミング体験を提供する。これは、ネットワークの待ち時間を管理すること、およびユーザがゲーミングセッションを、最良のネットワークパフォーマンスを提供するピアおよび／またはゲーム・サーバとともに確立できるようにすることにより行う。好ましくは、本発明のシステムおよび方法は、ユーザに、受け入れ可能なパフォーマンス基準を満たすいくつかのピアまたはゲーム・サーバを提供する。提供される選択の数およびこの数が決定される時間も、本発明のシステムおよび方法において管理される。
【０００９】
多数のピアがＮＡＴの背後からネットワークに接続できることを認識して、本発明の基盤は、いくつかのサーバ、本明細書ではコネクション・サーバ（以下、ＣＳという）を提供し、これにピアがオープンコネクションを開始かつ維持して、外部ＩＰアドレスを有することができるようにする。数百万ものピアがネットワークに存在するようになることが想定されるが、比較的に少数のＣＳのみが、これらピアにサービスする必要がある。この基盤において、ＣＳは、接続されたピアの知識を有し、これらピアに、接続されたピアおよびゲーム・サーバ（以下、ＧＳという）のうちどれが受け入れ可能なＱｏＳで利用できるかに関する情報を提供する。
【００１０】
この機能を提供するために、本発明のシステムおよび方法は、２フェーズの操作、すなわちＱｏＳプロービングと監視フェーズ、およびＱｏＳ解析と予測フェーズとして考慮することができるものを利用する。第１のフェーズにおいて、ＵＤＰ（User Data Protocol）ベースのツールを、ネットワーク内のコネクションの決定に必要とされるＱｏＳパラメータをプロービングするために利用する。このＵＤＰベースのツールにより、ＮＡＴの背後からあるいは直接ネットワークに接続されるピアのＱｏＳプロービングが可能となる。ゲーミング環境において、ネットワーク待ち時間は、最も重要なＱｏＳパラメータであるが、エンドツーエンドの遅延、帯域幅、パケット損失率など他のパラメータも計算することができる。多数のＩＳＰが、トラフィックフィルタリング技術をそれらのネットワーク内で使用する（例えば、ＩＣＭＰエコーパケットをブロッキングすることなどによる）ことを認識して、本発明のツールは、好ましくは、アプリケーションレベルの測定を提供する。
【００１１】
第１フェーズの操作において、本発明のシステムおよび方法は、ネットワークにおけるＱｏＳを４つのステージで測定する。第１のステージは、ログインステージであり、コネクションをピアとＣＳとの間で確立する。ピアとそのＮＡＴとの間の待ち時間、およびピアとＣＳとの間の待ち時間は、ピアによって測定され、ＣＳに格納される。第２のステージは、データ解析と事前選択ステージであり、ピアに、ピアの要件を満たす潜在的な候補のリストを提供する。このリストはＣＳによって、ピアによって行われた以前のプローブからＣＳに格納された以前および現在のデータの解析から生成される。第３のステージは、プローブと測定ステージであり、好ましくは、ピアは並行して、第２のステージで返されたピアまたはサーバをプローブする。最後に、第４のステージは、ログおよびフィードバックステージであり、ピアによって得られたＱｏＳ測定値を、第２のフェーズ（ＱｏＳ解析と予測フェーズ）で使用するためにＣＳに返される。これらの４つの各ステージでは、ピアとＣＳとの間、複数のＣＳの間、および複数のピアの間における通信のためのプロトコルが、ともに使用する統一されたパケットフォーマットとともに定義される。
【００１２】
プローブと測定ステージにおいて、ＵＤＰベースのプロービングツール（本明細書ではuProbeと称する）を、Ｐ２Ｐのプロービングのために使用する。このツールは、好ましくは、修正されたパケットペアのプロービング方式を利用する。これによりエンドツーエンドの待ち時間、ボトルネック帯域幅の推定値、およびパケット損失率の決定が可能となる。ログとフィードバックステージにおいて、統計モデルが選択され、これはプローブされたＱｏＳの結果を表わし、ＱｏＳ解析と予測フェーズにおいて使用するためにＣＳに返される。
【００１３】
ピアが、例えば極度に大きいＲＴＴ（Round Trip Time）、宛先未達などの異常なプロービング結果に直面するとき、ピアは、このような結果を返すためにホップバイホップの診断を各ピアについて実行する。このホップバイホップの解析は、パケット列を利用してホップバイホップのパスり特性をプローブする。ＤＤＭ（Differential destination measurement）を使用して、パケット列のパケット中の協調から、リンク特性を推論することが可能となる。フィルタリングおよび統計上の定義を使用して、ＱｏＳ解析と予測フェーズにおいて使用するために、ＣＳに結果を送信する前に、リンク特性が推定される。
【００１４】
ＱｏＳ解析と予測フェーズでは、ＣＳは、第１のフェーズにおいてピアによって収集され、ＣＳに送信されたＱｏＳ情報を利用する。ＣＳは、様々なピアからの関連する情報をグループ化し、クリティカルパスのＱｏＳパラメータを特徴付けることができる識別可能な特徴を得て、有用な時間情報をデータから抽出する。この情報は結合されて、ネットワークの統計モデルが得られる。この情報を使用して、ピアからのリクエストが受信された後、そのコネクションに適切なピアのリストを返す。異なる統計モデルを様々なパラメータに基づいて使用することができ、これらモデルは、ピアが第１のフェーズでＱｏＳプロービングを実行した後に更新される。
【００１５】
本発明の追加の特徴および利点は、以下の例示的実施形態の詳細な説明から明らかとなり、この説明は添付の図面を参照して進行するものである。
【００１６】
特許請求の範囲は本発明の特徴を詳細に述べるが、本発明はその目的および利点とともに、以下の詳細な説明を添付の図面とともに得ることにより最良に理解することができる。
【００１７】
【発明の実施の形態】
図面では、同様の参照番号は同様の要素を指し、本発明が適切なコンピューティング環境において実施されるものとして例示される。必要とはされないが、本発明を一般に、プログラムモジュールなど、パーソナルコンピュータによって実行されるコンピュータ実行可能命令に関連して記載する。一般に、プログラムモジュールには、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などが含まれ、これらが特定のタスクを実行するか、あるいは特定の抽象データ型を実施する。さらに、本発明を他のコンピュータシステム構成により実施することができ、これにはハンドヘルドデバイス、マルチプロセッサシステム、マイクロプロセッサベースまたはプログラマブルなコンシューマエレクトロニクス、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、ビデオゲームボックスなどが含まれることは、当業者に理解されよう。本発明はまた分散コンピューティング環境において実施することもでき、ここでは、タスクが、通信ネットワークを通じてリンクされるリモート処理デバイスによって実行される。分散コンピューティング環境では、プログラムモジュールがローカルおよびリモートのメモリストレージデバイスに位置することができる。
【００１８】
以下の記載では、本発明を、他に示されない限り、１つまたは複数のコンピュータによって実行されるオペレーションの動作および記号表現を参照して記載する。このようにして、このような動作およびオペレーションは、時にはコンピュータにより実行されるものと称し、データを構造化形式で表現する電気信号を用いたコンピュータの処理装置による操作を含むことは理解されよう。この操作は、データを変換し、またはデータをコンピュータのメモリシステムにおける格納場所に維持し、コンピュータのオペレーションを、当業者によく理解される方法で再構成し、あるいはそうでない場合は変更する。データが維持されるデータ構造は、データのフォーマットによって定義された特定の属性を有するメモリの物理的場所である。しかしながら、本発明を上述に関して記載するが、これは限定とする意味ではなく、以下に記載する様々な動作およびオペレーションをハードウェアにおいても実施できることは当業者には理解されよう。
【００１９】
オンラインのＰ２Ｐゲーミング環境は、Microsoft Xbox（登録商標）とともに動作するように配置され、図１に例示される。ここでは、現在または間もなく数百万のゲームボックス１００〜１１０が配置され、ゲーミングネットワークを介して、互いにおよびＧＳに接続するために使用可能である。しかし、これらゲームボックス１００〜１０８の多数は、ＮＡＴ１１２〜１１８を通じて接続する可能性が高く、個々のゲームボックスのための外部ＩＰアドレスを確立し、維持するためにサーバを必要とする。これらＣＳ１２０〜１２４は、ＮＡＴ１１２〜１１８を通じて、コンタクトしているゲームボックス１００〜１０８へのオープンコネクションを維持するようになる。このようにして、ピアリングおよびプロービング関係を、ネットワークのゲームボックス間で確立することができる。しかし、本発明の好ましい実施形態では、比較的に少数の、例えば３〜５個のＣＳが配備され、ゲームボックスにサービスする。したがって、適切なゲーム候補を、多数のゲームボックスにおいて妥当な時間内で見つけるために、本発明のシステムは、ＱｏＳプロービングと監視、およびＱｏＳ解析と予測に同時に注目して、システムのユーザの必要性を満たす必要がある。
【００２０】
本発明のシステム操作の第１フェーズ、本明細書ではＱｏＳプロービングと監視フェーズと称し、各ゲームボックス（ピア）１００〜１０８が、ＮＡＴ１１２〜１１８の背後にある可能性のあることが認識される。このようにして、本発明のシステムが、２つのピア間（例えば、ピア１０６とピア１０８との間）でＱｏＳパラメータをプローブすることが可能なように、これらピア間のコネクションが確立されなければならない。Ｐ２ＰのＵＤＰコネクションを開く方法は知られているが、ＮＡＴを通じて接続する２つのピアのＴＣＰコネクションを構築することは困難である。このようにして、本発明の好ましい実施形態は、ピアに存在するＵＤＰベースのツールを、本発明のネットワーク内のＱｏＳパラメータをプローブするために利用する。
【００２１】
いくつかのタイプのＱｏＳパラメータがあることが知られており、これらは、エンドツーエンド遅延、帯域幅、パケット損失率などである。このようなすべての測定規準は、トレードオフを有することを考慮して、本発明のシステムは、１つの特定のパラメータに注目するのではなく、全体の状況を見て、コネクション決定の基礎とする。実際には、本発明のシステムは、好ましくは、これらのパラメータを、ネットワークで実行中であるアプリケーションの要件に基づいてトレードオフする。ゲーミングアプリケーションでは、待ち時間が、典型的にはＱｏＳ選択のための最も重要なパラメータである。しかし、ブロードバンドネットワークの配置により、ますます多くのゲームがマルチメディア技術を利用して、その表現能力を向上させている。これを考慮して、本発明の一実施形態は、帯域幅および他のＱｏＳコンポーネントも考慮して、以下に十分に論じる。
【００２２】
通常のＱｏＳ監視技術（例えば、ピング、ルートトレースなど）は、低レベルのパケットをプロービングパケットとして使用する。しかし、いくつかのＩＳＰは、今日、トラフィックフィルタリング技術をネットワーク内で使用しており、例えば、ＩＣＭＰエコーパケットのブロッキングなどを行うことができる。結果として、このようなパケットを使用した測定は、むしろ低い精度しか達成することができない。これを考慮して、本発明のシステムは、その代わりに、ネットワーク化されたアプリケーションの実際のパフォーマンスを測定することを試みる。アプリケーションレベルの測定は、アプリケーションのパフォーマンス全体を明確に見るために必要とされ、これを低レベルのデータから容易に合成することはできない。
【００２３】
アプリケーションレベルの測定は、ネットワーク上のアプリケーションのパフォーマンスの最良の全般的考察を与えるが、このようなプロービングは結果として過度のネットワークオーバーヘッドを生じる可能性がある。本発明のシステムは、制限時間内にピアの要件を満たすネットワーク上のピアのサブセットをで決定することが必要であるので、並行プロービングが本発明のシステムのための論理的候補である。しかし、並行プロービングによって引き起こされるオーバーヘッドを考慮して、本発明のプロービングツールが、測定しようと試みているそのパラメータと干渉しないようにしなければならない。
【００２４】
このようにして、所与のピアについて対応するオーバーヘッドを、以下のようにおよそ解析することができる。Ｎが、ピアリング関係を確立するための最良の候補を決定するためにピアによってプローブされるピアの数に等しいと仮定する。本発明の一実施形態では、この数Ｎが５０に設定される。また、Ｏが、各ピアの出力プローブの数に等しいと仮定する。この数は、プローブの結果の精度に影響を及ぼし、そのために適切な制限が与えられるべきである。本発明の好ましい実施形態では、この数は、３０から５０まで変化する。文字Ｐは、出力プローブパケットの長さに等しい。例えば１００バイト、２００バイト、５００バイト、１２００バイトなど異なるサイズのパケットが、本発明のシステムの実施形態において、ボトルネック帯域幅をプローブするために使用される。文字Ｉは、同じピアの２つの連続した出力プローブの間隔に等しい。より正確なプロービングの結果は、連続するプロービングパケットの間の間隔が、ポアソン過程を満たすときに達成される。一実施形態では、簡単にするため、およそのオーバーヘッド解析を得るために、Ｉを１００ｍｓに設定する。オーバーヘッドのもう１つの要素はＳであり、出力パケットについての損失率である。パケットがネットワーク内で失われるとき、本発明のシステムは、このパケットを再度送信し、これによりネットワーク上の負荷が増す。この解析のために、２つの値である０または０．００１が使用される。Ｔの値は、ピア選択ステージにおいて使用される時間であり、好ましい実施形態では３または５秒以下に制限される。最後に、ゲーミング環境における２つのピア間の待ち時間は、異なるゲームジャンルに応じて、１００ｍｓ、２００ｍｓまたは５００ｍｓ以下であると仮定される。この情報から、選択ステージにおいて、送信されるバイト数および追加されるオーバーヘッドについての推定値を、表１に例示する。
【００２５】
【表１】

【００２６】
このＱｏＳプロービングと監視フェーズの手順全体が検討されるとき、ある追加の負荷がネットワークに追加される可能性が高く、これはIPSecネゴシエーション、双方向の接続確立などの機能によることに留意されたい。したがって、表１に例示した推定値は、単なる推定値であると認識される。
【００２７】
ＱｏＳプロービングおよび監視フェーズの詳細を論じる前に、操作におけるＱｏＳ解析と予測フェーズにおいて提示される課題もあることに留意されたい。詳細には、多数のピアがネットワークにおいて配置されているので、各ピアは、それ自身のプロービング結果を有することができる。どの程度の量のデータを格納するべきか、およびどの種類の情報を格納するべきかは、困難な問題となる。プロービング結果を、例えば５秒で得るために、本発明のシステムは、履歴情報を参照として使用する。以下に論じる推定技術も使用して、ＱｏＳパラメータを予測する。システムのこのフェーズにおける重要な問題は、履歴データをどのように解析して統計情報を即座に得るか、および、ＱｏＳパラメータの予測のためにどの種類の推定技術を使用するべきであるかが含まれる。
【００２８】
本発明のシステムにおける操作の２つのフェーズを簡単に導入したが、ここでより詳細に、操作におけるＱｏＳプロービングと監視フェーズ、およびその中で使用するツールに注目する。以下の考察を可能な限り正確にするため、いくつかの用語および命名規則をここで定義する。ＮＡＴの背後にあるピア、例えばXbox（登録商標）は、ローカルＩＰアドレスおよびローカルポートを有する。ピアが出力コネクションを維持するとき、ＮＡＴ ＩＰアドレスおよびＮＡＴポートも有する。このピアのローカルアドレスおよびローカルポートを指すために、以下の考察では、従来のXB1.LIPおよびXB1.LPを使用する。ピアのＮＡＴアドレスおよびポートを指すために、XB1.NIPおよびXB1.NPという指示を使用する。時として、この考察では、単にピアの外部ＩＰアドレスおよび外部ポートについて述べる。これにより、コンピュータが直接インターネットに接続した（ＮＡＴを通過しない）ＩＰアドレスが、パケットをピアに到達するようにアドレス指定できることを意味する。直接インターネットに接続したピアでは、XB1.LIPおよびXB1.LPを意味する。ＮＡＴを通過中であるピアでは、XB1.NIPおよびXB1.NPを意味する。問題を簡単にするため、ピアの外部ＩＰアドレスおよび外部ポートを考えるとき、XB1.XIPおよびXB1.XPを使用する。またこの考察では、ＣＳがコネクション・サーバを表し、ＧＳがゲーム・サーバを表し、これを、ＧＳとして動作することを望むことを示すピアにすることができる。さらに、ＣＳまたは他のいずれかのサーバが、決してＮＡＴの背後にならないことが仮定される。このようにして、ローカル対外部のアドレス指定の潜在的な混乱はない。サーバのＩＰアドレスおよびポートについて述べるとき、この考察では、例えばCS1.IPおよびCS1.Pと指す。
【００２９】
上で採用した命名規則に加えて、以下の考察ではまた以下のようなあるＱｏＳ用語も利用する。Ｌ１はピアとそのＮＡＴの間の待ち時間を指す。Ｌ２はピアとそのＣＳの間の待ち時間を指す。Ｌ３はピアと宛先ピアの間の待ち時間を指す。Ｌ４はピアとそのＧＳの間の待ち時間を指す。Ｂ１はピアと宛先ピアの間の帯域幅を指す。
【００３０】
命名規則を導入したが、ここでの考察は、図１に例示した例示的ゲーミングフレームワークにおけるＱｏＳを測定するためのシステムおよび方法に注目する。上述したように、これは本発明のシステムのＱｏＳプロービングと監視フェーズである。このフェーズは、４ステージの操作に分割されるものとして、最良に理解することができる。これらのステージには、ログインステージ、データ解析と事前選択ステージ、プローブと測定ステージ、およびログとフィードバックステージが含まれる。本発明のシステムの応用を、Microsoft XBox（登録商標）用のゲーミングネットワークに適用するものとして、各ステージを詳細に以下で論じ、本発明のシステムおよび方法を、等しい効力により他のＰ２Ｐのネットワークにも適用できることを認識する。
【００３１】
引き続き図１を参照ながら図２に例示したように、ログインステージが１２６で開始すると、ピア１０６は、ＣＳ１２０を領域において発見し、ＣＳ１２０が提供する周期的な「キープアライブ」パケットのためのコネクションを、１２８で確立する。ログインステージにおいて、ピア１０６は、ステップ１３０において、Ｌ１およびＬ２をいずれかの従来の技術によって測定する。次に、これらの値は、１３２においてＣＳ１２０に送信され、その中に格納される。その間に、１３６においてピア１０６がＧＳとして動作することを望む場合、ピア１０６は、１３８においてＣＳ１２０に、「ハブアンドスポーク」ゲームタイプのためのＧＳとして動作することを望むことを伝える。一実施形態では、１３４においてＵＤＰポートが登録され、第３のステージにおいて以下に論じる測定プロセスのために使用される。以下でより十分に論じるように、ピア１０６は、１４２においてこのステージが終了する前に、１４０において他のパラメータをＣＳ１２０に登録することもできる。
【００３２】
図３の簡素化された流れ図の形式で例示したデータ解析と事前選択ステージ１４４において、ＣＳ１２０は、１４６において、ピア１０６からプローブするためのピアおよび／またはＧＳのリストについてのリクエストを受信する。一実施形態では、ピア１０６は、XnetRetrieveXBoxListコマンドをそのＣＳ１２０に送信する。このプローブの目的は、ピア１０６が、ピアが加わるために最速または最寄りのゲームセッションまたはＧＳを発見できるようにすることである。最初に、ＣＳ１２０は、１４８において、以前および現在のＱｏＳデータを解析する。これは、そのデータベース１５０に格納され、そのピアまたは他のピアまたは他のネットワークプローブエンティティから受信されている。１５２において、完全リストを形成するために十分なデータがない場合、ＣＳ１２０は、１６０において、他のＣＳ１２２、１２４へ追加のデータについてのリクエストを送信し、次に１６２において、このデータはデータベース１５０に格納される。データベース１５０におけるデータから、ＣＳ１２０は、適切なピアリストを決定する（ＧＳリストは特殊なピアセットであり、その中で各アイテムがログインステージにおいて、「ハブアンドスポーク」ゲームタイプのための「ハブ」として動作することを望むことを請求する）。次に、ＣＳ１２０は、１５４において対応するリストを作成かつソートし、１５８においてこのステージを終了する前に、１５６においてこのリストを要求するピア１０６に送信する。
【００３３】
ＣＳ１２０が導出し、要求するピア１０６に返すリストは、いくつかの要件を満たすことが好ましい。第１に、このリストに含まれるピアの数は、パラメータによって制限されるべきである。このパラメータは、出力プローブの最大数である。１０００などの静的な数に、またはピア１０６またはＣＳ１２０によって割り当てられた数にすることができる。これをあまり大きくするべきではない。第２に、リストにおけるすべてのピアは、現在アクティブであるべきである。第３に、リストに含まれたすべてのピアは、より多くの入力プローブを許可しなければならない。ピアのパフォーマンスおよびＤｏＳ（Denial of Service）攻撃を考慮すると、ピアは、無限の入力プローブを許可するべきではない。したがって、各ピアは、その入力プローブの最大および現在の数を、図２のステップ１４０においてＣＳに登録する。この情報を使用して、ＣＳは、これらの「ハングリー」なピアのみを含むように選択することができる。第４に、ソースピアとリストにおけるピアとの間の待ち時間は、異なるゲームジャンルおよびユーザ体験に応じて、ソースピアによって割り当てられたパラメータ未満になるように予想されるべきである。ＣＳは、１５４において待ち時間をソートし、１５６においてソースピアに最良の結果で応答する。一実施形態では、リスト上に含まれたいくつかのアイテムに、不適当であるとしてマークが付けられる。最後に、ＧＳリストには、ログインステージにおいて、ＧＳとして動作することを望むことを主張したピアのみが含まれるようになる。
【００３４】
図４に例示したプローブおよび測定ステージは、１６４から開始し、ピア１０６が１６６においてＣＳ１２０からリストを受信した後、ピア１０６が多数のネットワークプローブを並行して所定の期間内で実行し、ステップ１６８で開始する。好ましくは、この時間を３〜５秒未満に設定して、過度の遅延がユーザ体験を損なうことを防止する。これらプローブが、標準のネットワークパフォーマンスに不都合な影響を及ぼすべきではなく、そのため本発明のシステムは、これらのプローブを、１つのプローブリクエストを通じて多数のＱｏＳパラメータの解析を可能にするような方法で実行する。最初のＰ２Ｐのプロービングは、好ましくは並行して実行され、１７０において成功した場合、この結果は、１７２において解析かつフィルタリングされ、必要とされたＱｏＳパラメータが導出される。この結果が１７２において成功ではなかった場合、uProbeは、１７４においてホップバイホップのプロービングプロセスを開始する。次に、このプロセスからの結果は、１７６において解析かつフィルタリングされて、ＱｏＳパラメータが導出される。この情報をピアが使用して、１７８においてセッションを確立するために最適なピアを選択する。次に、１８０においてこのステージが終了する。
【００３５】
オンラインゲーミングフレームワークをより緊密に結合し、プローブパフォーマンスを向上させるために、本発明のシステムは、ＵＤＰベースの、ＮＡＴに適した測定ツールを使用し、これを本明細書ではuProbeと称する。ピアの測定ツールへのコネクションを作成するために、ピアは、そのＵＤＰポートをそのＣＳに、上述したログインステージで登録する。代替実施形態では、静的な周知のポートは、ＱｏＳ測定の使用のためにのみ定義される。プロービング機能の実行に加えて、各ピアにおけるuProbe測定ツールは、１８４において別のピアからの各入力プローブの受信に即時に応答して、以下、図５を参照して論じるように、１８６において、ＱｏＳをより正確に測定できるようにする。これは、ピアシステムにおけるＱｏＳプロセスのプロセス優先度を上げることによって保証される。
【００３６】
プロービングの後、ピアは、ＱｏＳ測定結果をそのＣＳへ、図５に例示するログとフィードバックステージで送達する。１８２から開始し、１９０においてＱｏＳパラメータが完全であった場合、ピアは、１９２においてこれらをそのＣＳへ送信する。これら測定結果は、ＣＳの重要なソースデータとなり、これについては以下に論じる。加えて、１８４において、ピアが、別のピアからの入力プローブパケットを受信するとき、１８８において、XnetRegisterIncomingProbesコマンドをそのＣＳに送信する。このフィードバック情報をＣＳが使用して、そのピアに送信されるプローブの数を、この数がその制限に達するときに制限する。これは、単にこのピアを、上述したXnetRetrieveXBoxListコマンドに応答して送信される将来のリストに含めないことによって実施される。
【００３７】
上述した４つの各ステージでは、ピアとＣＳとの間、ＣＳと他のＣＳとの間、および複数の異なるピア間の通信が、インタラクションプロトコルを利用する。便宜上かつ効率のため、これらプロトコルは、図６に例示するような統一パケットフォーマットを利用する。このパケットにおいて、「コマンドタイプ」フィールド１９６は、一実施形態では以下の種類を有する列挙可能な変数を含み、これは、CT_KeepAlive、CT_XboxList、CT_uProbePort、CT_IncomingProbe、CT_DataForCS、CT_QosProbeなどである。「ペイロード長」フィールド１９８は、ペイロードの長さを３２ビット（４バイト）で指定する。「オフセット」フィールド２００は、あるパケットがコマンド全体を搬送できないとき、ペイロードにおけるオフセットを指示する。「シーケンス番号」フィールド２０２は、重複、応答およびシーケンスを回避するなど、特定の目的を満たすために使用される。「送信元／送信先エンティティ」フィールド２０４、２０６は、パケットの送信元／送信先エンティティの識別子を含む。最後に、「ペイロードデータ」フィールド２０８は、特定のタイプのパケットについて必要とされる可能性のあるいずれかのペイロードデータを含み、これについては以下で論じる。これらのすべてのプロトコルは、「要求応答」ＵＤＰベースのプロトコルである。このようにして、リクエストパケットを受信するエンティティは、同じ種類のパケットによりリクエストに応答する。
【００３８】
ＣＳ１２０とピア１０６との間の通信プロトコルは、主として、ピア１０６へのコネクションを、特にピア１０６がＮＡＴ１１６を通じて接続する場合に、生きた状態に保つことが必要である。したがって、CT_KeepAliveパケットが周期的に送信かつ受信される必要がある。このパケットは、主としてピアへのコネクションを生きた状態に保つために使用されるので、パケットのペイロード２０８をゼロにすることができる。このプロトコルはまた、上述した事前選択リストについてのリクエストおよび応答のためにも使用される。上述したように、ピア１０６は、ＣＳ１２０からのリストを、ゲームセッションを開始することを望むときに求める。CT_XBoxListパケットをこの機能のために使用することができる。ピア１０６とそのＣＳ１２０との間のプロトコルは、ＱｏＳ測定ツール用のＵＤＰポートを登録するためにも使用される。ログインステージでは、ピア１０６は、このＵＤＰポートをＣＳ１２０へ、CT_uProbePortパケットにより通知する。ピア１０６は、ピアリストの生成においてＣＳ１２０による使用を可能にする入力プローブの数も登録する。現在の入力プローブの数が変化するとき、ピア１０６は、この変化をそのＣＳ１２０へ、CT_IncomingProbeパケットにより通知する。最後に、ピア１０６がそのプローブを完了した後、ＱｏＳの結果をそのＣＳ１２０へ、CT_DataForCSパケットを使用することによって送達する。
【００３９】
いずれか２つのＣＳ間のプロトコルを使用して、主としてＱｏＳデータベースを更新する。このプロトコルは、別のＣＳがコンタクトされてピアリストに追加のピアが供給されることが可能であるとき、事前選択リストのリクエストおよび応答も含む。上述したように、このＣＳとＣＳとの通信は、ローカルＣＳが、そのピアのうち１つのリクエストを満たすピアについての情報を有しておらず、およびＣＳがピアリストを完成させるために他のＣＳから追加の情報をリクエストする必要があるときに、実施される。このプロトコルは２種類のパケット、CT_DataForCSおよびCT_XBoxListを使用する。
【００４０】
Ｐ２Ｐのプロトコルが、以下でより十分に論じるuProbeツールにおいて実施さて、通信における２つのピア間のリンクのＱｏＳがフェッチされる。これは一般に、CT_QosProbeパケットをuProbeツールによって送信かつ受信することによって実施される。
【００４１】
本発明のＱｏＳプロービングの実施では、このようなプロービングが成功となり、すなわち応答がプロービングリクエストに対して受信され、あるいはこれが不成功となり、すなわち無応答または極度に低速の応答がプロービングリクエストに対して受信される。これらの成功したプロービング結果および異常（不成功）のプロービング結果を包括的に解析するため、２つの別々のプロービング方式を、本発明のuProbeツールによって利用する。一方がＰ２Ｐのプロービング用であり、他方がホップバイホップのプロービング用である。以下の考察では、本発明のシステムが、ネットワークにおけるＱｏＳ測定規準をプローブする方法を説明し、大きい範囲のゲーミング候補が与えられる、オンラインゲーミングフレームワークについての一実施形態に注目する。
【００４２】
このようなＱｏＳプロービングのためのプロセスは、図４で例示したように、簡単に述べたように４つのステージに分割される。ステージ１、並行したＰ２Ｐのプロービング１６８において、ピアは、多数のネットワークプローブを並行して所定の時間、例えば５秒未満で生成する。上述したように、これらプローブは、標準のネットワークパフォーマンスに影響を及ぼすべきではない。プローブされたピアにおけるuProbeツールは、各入力プローブに即時に応答して、ＱｏＳの測定の精度を向上させる。ステージ２、成功したプロービング結果のフィードバック１７２において、ピアは、プローブされたＱｏＳの結果を表わすために適切な統計モデルを選択する。次に、ピアは、これをそのＣＳへ送達する。上述したように、この情報は、ＣＳで実行されるさらなるデータ解析のための重要なデータのソースとなる。
【００４３】
ステージ３、ホップバイホップのプロービング１７４は、ステージ１で検出されるいかなる異常な結果についても実行される。異常なプロービング結果、例えば極度に大きいＲＴＴ、宛先未達などに直面すると、ピアは、それぞれについて詳細なホップバイホップの診断を実行する。このプロセスでは、以下で詳細に論じるように、重み付けされたＱｏＳ測定規準が、ピアと、送信元と送信先ピア間の各中間ノードとの間で測定される。ステージ４、異常プロービング結果フィードバックステージ１７６は、ステージ２に類似している。すなわち、ホップバイホップのプロービングが実行された後、ピアは、プローブされたＱｏＳ結果を表わすために適切な統計モデルを選択する。次に、これらがＣＳに送達され、ＣＳで実行されるデータ解析と候補選択のための重要なソースデータとしての機能する。
【００４４】
成功したプロービング結果をＣＳに移送するためのインタラクションメッセージフォーマットを図７に例示する。このインタラクションメッセージは、現在のピアのＩＤを含む。このアドレスは、ＮＡＴ ＩＰアドレス（４バイト）およびポート番号（２バイト）を含む。このメッセージは、プローブが成功したピアの数の指示（１バイト）も含む。各プローブされたピアのＱｏＳ測定規準情報も含まれる。この情報は、プローブされたピアのＩＤ（６バイト）、ＲＴＴ（２バイト）、ボトルネック帯域幅（２バイト）およびパケット損失率（１バイト）を含む。
【００４５】
異常プロービング結果をＣＳに移送するためのインタラクションメッセージフォーマットを図８に例示する。このインタラクションメッセージは、現在のピアのＩＤを含み、ＮＡＴ ＩＰアドレス（４バイト）およびポート番号（２バイト）を含む。このメッセージは、ホップバイホップの方法によってプローブが成功したピアの数の指示（１バイト）も含む。各プローブされたピアのＱｏＳ測定規準情報も含まれる。この情報は、プローブされたピアのＩＤ（６バイト）、ＲＴＴ（２バイト）、ボトルネック帯域幅（２バイト）およびパケット損失率（１バイト）を含む。
【００４６】
本発明のシステムおよび方法によって提供されたＰ２Ｐプロービングの一般原理の理解とともに、本発明のＰ２ＰのＱｏＳプロービング方式によって使用されるプロービングメカニズムおよび解析アルゴリズムのより詳細な考察を行う。上述したように、本明細書で提示したＰ２ＰのＱｏＳプロービングの一目的は、可能な限り多数のパラメータを、１つのプロービングツールuProbeを使用して、公衆網に多すぎるトラフィックを注入することなく測定することである。エンドツーエンドの待ち時間およびボトルネック帯域幅の推定のために、修正されたパケットペア方式を使用し、これを図９に例示する。このパケットペアプロービングは以下のように動作する。送信元ピア２１０は、２つのパケット２１２、２１４を続けざくに送信先ピア２１６に送信する。パケットが、ルータ２２０、２２２間のパスのボトルネック２１８を通過する率は、ボトルネック２１８の後のパケット２１２’、２１４’のスペーシングを決定する。パケット２１２’、２１４’は、ボトルネック２１８の後の新しいスペーシングを保ち、これは、以下のように計算することができる。
【００４７】
【数１】

【００４８】
ここで、ｓ_２は第２のプロービングパケットのサイズであり、B_bottleneckはボトルネック帯域幅である。
【００４９】
非対称ルートは、バックボーンネットワークにおいて一般的であることが知られている。しかし、プローブするピア２１０およびプローブされたピア２１６の助けにより、本発明のシステムは、フォワードおよびリターンパスについてのボトルネック帯域幅を別々に測定することができる。上述したアプリケーションレベル測定要件を考慮すると、同じサイズのPSizeを有する２つのＵＤＰプロービングパケット２１２、２１４は、続けざまにプローブするピア２１０で送出される。各プロービングパケット２１２、２１４は、このパケットがアプリケーションレイヤを去る瞬間を示すタイムスタンプ（T_ProbingLeave）を含む。プローブされたピア２１６では、プロービングパケットペア２１２’、２１４’を受信すると、フォワードパスのボトルネック帯域幅を以下のように計算することができる。
【００５０】
【数２】

【００５１】
ここで、T_{ProbedPairArrived1}およびT_{ProbedPairArrived2}は、それぞれプローブされたピア２１６における第１の２１２’パケットおよび第２の２１４’パケットの到着タイムスタンプである。
【００５２】
プローブされたピア２１６は、これらの到着タイムスタンプをプロービングパケット２１２’’、２１４’’に追加し、プローブされたピア２１６おいて、これらをプローブするピア２１０へ続けざまにに再送する。これらのパケットがプローブされたピア２１６を去る瞬間を示すタイムスタンプ（T_ProbedLeave）は、各出力プロービングパケット２１２’’、２１４’’に記録される。次に、プローブするピア２１０において、この返送されたプロービングパケットペア２１２’’ ’、２１４’’’を受信すると、リターンパスのボトルネック帯域幅を以下のように計算することができる。
【００５３】
【数３】

【００５４】
ここで、T_{ProbingPairArrived1}およびT_{ProbingPairArrived2}は、それぞれプローブするピア２１０における第１の２１２’’’ パケットおよび第２の２１４’’’パケットの到着タイムスタンプである。
【００５５】
これらの６つのタイムスタンプを有すると、エンドツーエンド遅延の２つの例（ラウンドトリップタイム−ＲＴＴ）を以下のように計算することができる。
RTT₁= (T_{ProbingPairArrived1}-T_ProbingLeave)-(T_ProbedLeave-T_{ProbedPairArrived1}) (4)
RTT₂= (T_{ProbingPairArrived2}-T_ProbingLeave)-(T_ProbedLeave-T_{ProbedPairArrived2}) (5)
【００５６】
本発明のプロービング方式において、プローブするピアから伝送されたパケットの数およびプローブされたピアで受信されたパケットの数に基づいて、フォワードパスにおけるパケット損失率を計算することができる。同様に、プローブされたピアから伝送されたパケットの数およびプローブするピアで受信されたパケットの数に基づいて、リターンパスにおけるパケット損失率を計算することができる。パケット損失特性について２つの異なる量がある。最もしばしば使用される量の１つは、平均パケット損失または無条件損失確率（ｕｌｐ）である。これを計算するため、ブール変数ｌ_ｎを、パケットが失われた場合に１として示し、そうでない場合に０として示す。平均損失は、l_n:ulp=E[l_n]の予想された値に等しい。連続するパケット損失間の相関を取り込むため、条件つき損失確率（ｃｌｐ）を使用して、パケットが、以前のパケットが失われる、すなわちclp=P[l_n+1=1|l_n=1]が与えられる損失である条件付き確率を考慮することができる。伝送されたパケットの数が、例えば２０未満など非常に小さい場合、パケット損失率を計算することにあまり意味がなくなることに留意されたい。
【００５７】
本発明のＰ２ＰのＱｏＳプロービングアルゴリズムの一実施形態において、両方向におけるプロービングパケットペアのサイズおよび数が考慮される。プロービング方式の数学的モデルを実施する前に、ハードウェアおよびソフトウェアの物理的容量が考慮され、数学的モデルを物理モデルに正確にマップできるようにする。このようなマッピングの前に、ハードウェア、ソフトウェアおよびオペレーティングシステムなど、すべての物理コンポーネントの特性の理解が探究される。関係する主な問題はタイミングである。上の式（２）および（３）におけるT_{ProbedPairArrived1}-T_{ProbedPairArrived2}は、クロック分解能およびハードウェア、デバイスドライバおよびコンテキストスイッチによって導入された他のタイミングの要素である。Intel（登録商標）ベースのＣＰＵでは、分解能が約０．８μｓｅｃであることが知られている。システムクロック分解能の特性に留意して、この実施形態におけるパケットサイズは、２００バイトとして選択される。より高いクロック分解能を有するシステムカーネルレベルで動作する場合、より小さいパケットサイズを選択して、より多くのプロービングパケットをより低いアクセスのコネクション実施形態において生成することができる。
【００５８】
プロービングパケットペアの数を決定するため、Ｎはプローブされるべきピアの数であると仮定し、例えば一実施形態では５０とする。また、Ｐは出力プローブパケットの長さであると仮定し、一実施形態では２００バイトとして選択され、ＴはＱｏＳプロービングステージにおいて使用された時間である。プローブするピア（UpBW_probing/DownBW_probing）およびプローブさけるピア（UpBW_probed/DownBW_probed）のアップリンクおよびダウンリンクアクセス帯域幅の情報を有すると、両方向のプロービングパケットペアの数（NPair_forward、NPair_return）を以下のように決定することができる。
【００５９】
【数４】

【００６０】
ここで、NPair_maxは、正確なＱｏＳ測定のために送達される必要のあるプロービングペアの最大数であり、一実施形態では２０に設定される。
【００６１】
プローブされるピアにあまり多くのオーバーヘッドを与えないようにするために、以下の制約が各プローブされるピアについて満たされるべきである。
【００６２】
【数５】

【００６３】
これは、プロービングパケットペア間の間隔を決定するためにも重要である。ピアが多数のピアを並行してプロービングしているとき、送出するパケットおよび返送されてくるパケットは自己同期し、および互いに干渉する可能性がある。本発明のuProbeツールは、ポアソン分布を使用してあるピアの各パケットペア間の間隔を記述し、異なるピアが異なる到着率を有する可能性があることを認識する。
【００６４】
アクセス帯域幅が十分に大きいとき、プロービングパケットペアを、間隔をあけずに１つずつ送信する必要はない。このとき、ポアソン過程に従う間隔が決定される。これは、最小帯域幅UpBW_minを計算することによって行われ、これは、以下のように十分なプロービングパケット（NPair_max）を送出するために必要とされるものである。
【００６５】
【数６】

【００６６】
例えば一実施形態では、NPair_maxを２０とし、Ｎを５０とし、Ｐを２００バイトとし、Ｔを５ｓとして設定すると、UpBW_minは、６４０ｋｂ／ｓより大きくするべきである。次に、各ペア間の送信間隔を以下のように計算する。
【００６７】
【数７】

【００６８】
ここで、ｘは、帯域幅がUpBW_minであるときにパケットペアを送信するための時間である。この実施形態では、ｘを以下のように計算することができる。
【００６９】
【数８】

【００７０】
次に、ポアソン過程が、基本パラメータを含み、間隔情報を使用して生成される。
【００７１】
【数９】

【００７２】
０と１の間で一様に分布する乱数Ｕ１、．．．、Ｕｎ、およびポアソン過程に従うＥ_ｉは、以下による。
【００７３】
【数１０】

【００７４】
詳細には、これらのステップは、Ｅ_１の生成およびＥ_１の待機、プロービング測定の実行（第１のパケットペアの送信）、および測定持続時間Ｍ_１の計算を含む。次に、Ｅ_２の生成およびＥ_２−Ｍ_１の待機、プロービング測定の実行（次のパケットペアの送信）、および測定持続時間Ｍ_２の計算などとなる。
【００７５】
プロービングパケット自体のフォーマットを図１０に例示する。このフォーマットにおいて、「パケットタイプ」フィールド２２４は、パケットタイプを示し、これを、例えばデータパケット、フォワードプロービングパケット、リターンプロービングパケットなどにすることができる。「ペア数」フィールド２２６は、プロービングパケットペアの数を示し、「ペアオフセット」フィールド２２８は、このプロービングパケットペアにおける現在のパケットのオフセットを示す。「リターンペア数」フィールド２３０は、フォワードパケットペアを受信するとプローブされたピアに送り戻される必要のあるペアの数を示す。「インタレースされたパケット数」フィールド２３１は、フォワードプロービングパケットペア間でインタレースしたパケットの数を示す。これは受信側によって設定される。最後に、T_ProbingLeave２３２、２３２’、T_{ProbedPairArrived1}２３４、２３４’、T_{ProbedPairArrived2}２３６、２３６’およびT_ProbedLeave２３８、２３８’フィールドは、上述の対応するタイムスタンプを格納する。
【００７６】
明らかなように、本発明のプロービング方式のいくつかの重要な特性がある。このような特性の１つは、本発明が、制限されたプロービングパケットを使用して、可能な限り多数のＱｏＳ測定規準を導出することである。プローブされたピアにおいて受信することができるフォワードパスのいかなるパケットも、そのプローブドピアが、リターンパスの帯域幅の推定、およびラウンドトリップタイムの測定にパケットペアを生成する結果となる。このメカニズムは、タイムスタンプのみを追加しなければならないので、低いオーバーヘッドをプローブされたピアに与えるだけである。このようにして、プロービングペアの第１のパケットを格納するために小さいバッファのみを必要とする。
【００７７】
成功したプロービング結果が上述したように達成された後、本発明のシステムは、プロービング結果の統計解析を実行する。どのネットワーク測定規準が存在するか、およびこれらを測定する方法が理解されると、結果を表わす方法が決定されなければならない。異なるネットワーク測定規準のための適切な統計値を選択するための配慮が必要とされる。特に、要約中のデータを生成するプロセスについての仮定を作成する統計値は、回避されるべきである。プロービングアルゴリズムおよび異なるネットワーク測定規準の特性に基づいて、異なる種類の統計技術を、エンドツーエンド遅延の測定およびボトルネック帯域幅の測定のために利用する。
【００７８】
ＲＴＴのための統計定義では、「中央値」が使用され、測定されたＲＴＴが表わされる。中央値は、ロバストな統計値であり、事前分布を知ることに関係なく、データセットの中心傾向を推定する。中央値を、データセットの中心点、または第５０番目の百分位数と見なすことができる。データポイントが昇順にソートされる場合、すべてのデータポイントの半分は、中央値より上であり、半分が中央値より下である。中央値は、奇数のデータポイントでは中央のデータポイントによって、偶数のデータポイントでは２つの中央データポイントの平均によって決定される。ほとんどの目的では、中央値（第５０番目の百分位数）がよい選択であり、これは少数の特異値の値によって多くの影響を受けないからである。
【００７９】
本発明のシステムは、ボトルネック帯域幅のためのフィルタリングおよび統計の定義を含む。すなわち、基本のパケットペアアルゴリズムの主な問題は、時間圧縮および拡張されたパケットによって引き起こされたノイズをフィルタリングしてどのように除くかであると知られている。したがって、第１の例では、本発明のシステムは、他のパケットによりインタレースされたパケットペアをフィルタリングして除く。これらの連結されたペアについて、システムは、核密度推定値（kernel density estimator）を使用して時間圧縮および拡張の問題を克服する。すなわち、システムは核関数Ｋ（ｔ）を以下の属性により定義する。
【００８０】
【数１１】

【００８１】
次に、いずれかのポイントｘでの密度が以下のように定義される。
【００８２】
【数１２】

【００８３】
ここで、ｈは核の幅であり、ｎはｘのｈ内のポイントの数であり、ｘ_ｉはｉ番目のポイントである。ここで使用する核関数は、以下の通りである。
【００８４】
【数１３】

【００８５】
この関数は、望ましい属性を有し、この関数が、より大きい重みを、システムが密度を推定することを望むポイントにより近いサンプルに与えること、および、この関数の計算が簡単かつ高速であることである。核密度推定アルゴリズムは、統計的に有効であることが知られており、最も重要なことには、それが作用する分布に仮定を作らず、他のデータセットとまさに同程度に正確である。
【００８６】
式（１８）では、より大きい値の核の幅が、より正確な密度の結果を与えるが、また計算上高価でもある。この実装の一実施形態では、核の幅は、ボトルネック帯域幅の範囲全体として設定され、すなわちx_max-x_minである。その場合、いずれかのポイントｘで、密度を以下のように簡約することができる。
【００８７】
【数１４】

【００８８】
連結されたペアがない場合、ＱｏＳプロービングの精度が減じる。これを排除するための１つの方法は、プロービング期間を延長して、連結されたペアが発生する確率を増すことである。もう１つの方法は、「ボトルネックスペーシング間隔」をダウンリンクアクセス帯域幅、パケットペアの中央におけるパケットの数、およびこのペアにおける２つのパケット間の分離時間間隔に基づいて推定することである。一実施形態では、線形回帰法を、ボトルネック帯域幅の推定に使用する。推定ボトルネック帯域幅が計算された後、好ましくは、核密度推定アルゴリズムを使用して、最終的なボトルネック帯域幅を計算する。
【００８９】
前の考察ではＰ２ＰのＱｏＳプロービング方式および成功したプロービング結果の解析に注目したが、ここでは、上述の異常な結果について使用されるホップバイホップのプロービングおよび結果の解析方式に注意を向ける。上述したように、このような異常な結果は、例えば極度に長いＲＴＴ、宛先未達などの形式となる可能性がある。以下の考察では、最初にプロービング手順を記載し、次に、プロービングアルゴリズムを詳細に提示し、最後に、統計解析手法を使用して得られた結果の導出を論じる。
【００９０】
ホップバイホップのＱｏＳプロービングの既存の解法は、pathchar, pchar, clinkなどであり、ただ１つの測定パケットを考慮してすべてのリンク特性、特にパスに沿った帯域幅を推論する決定論的モデルから構築される。結果として、これらの技術は、ＩＣＭＰパケットを一貫して処理するルータ、および応答の適時な送達に依拠する。しかし、これらの解法にはいくつかの欠点がある。第１に、ＩＣＭＰをルータにおけるＤｏＳ攻撃の一形式として使用できることが知られている。このリスクを減らすため、多数のルータが非常に低い優先度をＩＣＭＰパケットの生成において、ルータのＣＰＵに負荷をかけ過ぎることを回避する。これは、ルータがＩＣＭＰエラーメッセージを生成するために要する時間によって引き起こされる待ち時間が存在することを意味する。第２に、いくつかのルータは、異なるサイズのパケットを異なるように処理する。これは、帯域幅を計算するために使用される傾きの計算に、誤差を導入する。加えて、これらの技術は、著しい量のネットワーク帯域幅を使用してそれらの測定を実行し、アプリケーションのいくつかでは非実用的になるほど低速になる可能性がある。
【００９１】
本発明のホップバイホップのプロービング方式は、リンク容量測定値を得て、単一パケット技術にある制限要素のうち少なくともいくつかを回避することを目的とする。基本的な測定技術を、図１１に例示する。図を見るとわかるように、プローブするピア２４０は、４つのパケット２４２〜２４８を含むパケット列を生成する。従来のパケット列の技術とは異なり、これら４つのパケット２４２〜２４８は、２つのパケットペアからなる。短い遅延であるdelay 1は、これら２つのペアの間にある。各パケットペアにおける２つのパケットは、続けざまに送出される。第１のパケット２４８は、スモールパケットであり、そのパケットサイズは４０バイトなど様々である。第２のパケット２４６は、第１のパケットよりはるかに大きく、一実施形態ではＭＴＵ（１５００バイト）をそのパケットサイズとして取る。
【００９２】
第１のペアにおけるラージパケット２４２は、測定中のリンク（ｋ番目のルータ２５０）で終了するように設定される（インクリメンタルＴＴＬを１から送信先まで使用する）。第２のペアにおけるラージパケット２４６は、測定中のリンク２５０の次のホップ（（ｋ＋１）番目のルータ２５２）で終了するように設定される（インクリメンタルＴＴＬを２から送信先まで使用する）。両方のペアにおけるスモールパケット２４４、２４８は、送信先であるプローブされるピア２５４へ送達される。伝送中に、スモールパケット２４４、２４８は、これらの２つのラージパケット２４２、２４６に「追いつく」状態を保つ。これは大きい方のパケットの伝送遅延が小さい方のパケットの伝送遅延より大きいからである。第１の大きい方のパケット２４２が測定中のリンク２５０で終了する場合、後に続く小さい方のパケット２４４は、大きい方のパケットの背後になることによって引き起こされた遅延から「解放」されるようになる。その間に、２つのＩＣＭＰ時間超過エラーメッセージ２５６、２５８が、プローブするホスト側２４０に戻る。小さい方のパケットによって体験される待ち時間は、大きい方のパケットが終了するように設定されるリンクが変わる場合に、変わる。
【００９３】
中間ノード２５０、２５２からのＩＣＭＰ時間超過パケット２５６、２５８が測定のために利用されるが、本発明の方式は、これらパケット２５６、２５８をルータ２５０、２５２の識別のためにのみ使用し、これら適時な送達に依拠しないことに留意されたい。加えて、中間ルータがＩＣＭＰエラーメッセージを遅延させ、異なるサイズのパケットを異なるように処理する場合でも、これは方向２の測定における結果に影響を及ぼさない。これは、時間差のみが帯域幅の推定において使用されるからである。
【００９４】
本発明のこのホップバイホップのプロービングを通じて、各リンクの特性を測定することができる。上述したように、本発明のシステムは、リンク特有の特性を、特定のリンクでパケットのキューイングを起こすことによって取り込む。各リンクについて、プローブするホストが、４つのパケットを有するパケット列を送信する。ＴＴＬ（time-to-live）がそのリンクおよび連続するリンクで終了するように設定された２つのラージパケットの後に、２つの非常に小さいパケットが続き、これらは、ラージパケットの背後で、ラージパケットが終了するリンクまで連続的にキューイングする。次に、リンク特性を、プロービング列における２番目、３番目および４番目のパケット間の関係から、以下で論じるＤＤＭ使用して推論することができる。
【００９５】
ＤＤＭにおいて、本発明のシステムは、最大の非断片化可能なパケットであるパケット（ｋ_１−１）２４２を、ｉのＩＰ ＴＴＬフィールドで送信する。このパケット２４２の直後に、最小の可能なパケットであるパケットｋ_１２４４が続く。小さい方のパケット２４４は、ほとんど常に、次のリンクにおいて大きい方のパケットの伝送遅延より低い伝送遅延を有する。これにより、小さい方のパケット（パケットｋ_１２４４）を、大きい方のパケット（パケットｋ_１−１ ２４２）の後に、連続的にキューイングさせる。短い時間間隔であるdelay 1の後、もう１つの最大の非断片化可能なパケットであるパケットｋ_２−１ ２４６が、ｉ＋１のＩＰ ＴＴＬフィールドで送信される。この直後に最小の可能なパケットであるパケットｋ_２２４８が続く。同様に、小さい方のパケット（パケットｋ_２２４８）を、大きい方のパケット（パケットｋ_２−１ ２４６）の後に、連続的にキューイングさせる。パケットｋ_１−１ ２４２のためのＴＴＬにより、これがリンクｉ２５０でドロップされる。これにより、パケットｋ_１２４４が、送信先２５４へのキューイングなしに継続することができる。同様に、パケットｋ_２−１ ２４６のためのＴＴＬにより、これがリンクｉ＋１ ２５２でドロップされ、パケットｋ_２２４８が、送信先２５４へのキューイングなしに継続することができる。宛先２５４で、プローブされたピア２５４は、パケットｋ１ ２４４およびパケットｋ２ ２４８を、delay 2の時間間隔により連続的に受信する。このようにして、パケットｋ_１２４４がリンクｉ２５０でキューイングされないが、パケットｋ_２はリンクｉ２５０でキューイングされる。これは、引き続きラージパケットｋ_２−１ ２４６がこのリンクで存在するためである。次に、本発明のシステムは、この差を利用することによってリンクｉの特性を推論する。
【００９６】
例えば、Lai and Baker, Measuring Link Bandwidths Using a Deterministic Model of Packet Delay, ACM Sigcomm 2000など、その教示および開示が全体として参照により本明細書に組み込まれる、マルチパケット遅延式を使用して、時間パケットｋ１が送信先リンクｎに到着するために要することを以下のように推論することができる（表２に定義された変数による）。
【００９７】
【数１５】

【００９８】
上の式をさらに以下のように簡約することができる。
【００９９】
【数１６】

【０１００】
同様に、時間パケットｋ１が送信先リンクｎに到着するために要することを以下のように推論することができる。
【０１０１】
【数１７】

【０１０２】
s^k1=s^k2, s^k1-1=s^k2-1である場合、２つの式を比較すると以下のようになる。
【０１０３】
【数１８】

【０１０４】
すなわち
【０１０５】
【数１９】

【０１０６】
b_lq+1を解くと、以下のようになる。
【０１０７】
【数２０】

【０１０８】
【表２】

【０１０９】
これは、キューイングが起こるリンクの帯域幅
【０１１０】
【外１】

【０１１１】
を、２つのパケットのサイズ
【０１１２】
【外２】

【０１１３】
と、パケットｋ_１とｋ_２との間の時間変化(delay2-delay1)と、前のリンクの帯域幅
【０１１４】
【外３】

【０１１５】
とから計算できることを示す。送信側と受信側の間のタイマは、異なるものにすることができるが、差の計算に影響を及ぼすものではないことに留意されたい。
【０１１６】
このときリンク帯域幅の結果を推定しており、核密度推定法を使用して推定ノイズをフィルタリングする。最大密度の値は、リンク帯域幅として選択される。本発明のシステムは、最初に、以下の特性を有する核関数Ｋ（ｔ）を定義する。
【０１１７】
【数２１】

【０１１８】
次に、いずれかのポイントｘでの密度が以下のように定義される。
【０１１９】
【数２２】

【０１２０】
ここで、ｈは核の幅であり、ｎはｘのｈ内のポイントの数であり、ｘ_ｉはｉ番目のポイントである。核関数は以下のようになる。
【０１２１】
【数２３】

【０１２２】
見るとわかるように、より大きい値の核の幅が、より正確な密度の結果を与えるが、また計算上高価でもある。本発明の好ましい実施形態では、核の幅は、ボトルネック帯域幅の範囲全体として設定され、すなわちx_max-x_minである。その場合、いずれかのポイントｘで、密度を以下のように簡約することができる。
【０１２３】
【数２４】

【０１２４】
上述したように、本発明のシステムは、ＱｏＳプロービングと監視、およびＱｏＳ解析と予測に注目して、適切なゲーム候補が発見されることを保証する。ＱｏＳプロービングと監視フェーズの考察を完了しており、ここで第２のフェーズ、すなわちＱｏＳ解析と予測フェーズに注意を向ける。
【０１２５】
図１２に例示するＣＳ２６０が、リクエストをピアから受信したときに、適切なピアをより効果的に選択するために、ＣＳ２６０は、以前のプローブから様々なネットワークプローブ結果を、ネットワーク状態データベース２６４に格納する。このようにして、ＣＳ２６０は、満足のいく結果を適時な方法で返すことができる。計算の複雑さと測定精度との間のトレードオフを考慮して、オフラインデータ解析およびオンラインデータ予測は、反復的にＣＳ２６０において実行される。オフラインデータ解析を実行するため、バックグラウンドデータアナライザモジュール２６２は、特徴抽出およびデータ結合を利用する。特徴抽出の機能性は、異なるピアの関連情報をグループ化すること、クリティカルパスのＱｏＳパラメータを特徴付けることができる区別できる特徴を得ること、および、有用な時間情報をデータから抽出することが含まれる。結合機能がすべての情報を結合して、統計モデルを得る。
【０１２６】
上述したように、ＱｏＳプロービングと監視フェーズにおいて決定されるネットワークプローブの結果には、Ｌ１、Ｌ２、Ｌ３、Ｌ４およびＢ１が含まれ、これらは、アクティブプロービング結果モジュール２６６によって受信される。Ｌ１およびＬ２をログインステージで測定することができ、Ｌ３／Ｌ４およびＢ１／Ｂ２をプロービングステージで決定することができる。２６８のフィルタリングの後、Ｌ１およびＬ２は、各ピアのコネクション・レコードとともにＣＳ２６０に格納される。この情報は、そのピアがアクティブであるかどうかを伝える。しかし、Ｌ３／Ｌ４およびＢ１／Ｂ２は、好ましくは、別々のレコードにおいて、対応するXB.NAT.IPおよびタイムスタンプとともに格納される。この情報により、エバリュエータ２７０、これらのレコードおよびネットワーク状態データベース２６４からの他のネットワークプローブの結果を解析して、より正確な推定値をプレディクタ２７２から現行リンクについて導出することができる。例えば、ＸＢ１がそのＣＳから最速のピアを探索することを望むとき、ＣＳ２６０は、そのデータベース２６４を解析し、ＸＢ２を選択する。これは、XB2.NAT.IPとXB1.NAT.IP間のリンクについての最良のＱｏＳを有する。さらに、ＣＳ２６０は、XB1.NAT.ISPとXB2.NAT.ISP間のリンクについて、最良のＱｏＳを有するレコードも検索する。
【０１２７】
個々のピアからのリクエストを受信すると、ＣＳ２６０は、オンラインデータ予測機能を実行する。測定する必要のあるパラメータおよびオフライン解析結果に応じて、異なる予測モデル２７４をプレディクタ２７２に使用することができる。可能なモデル候補には、重み付け移動平均モデル、自己回帰統合移動平均モデル、自己回帰部分統合移動平均モデルなどが含まれる。測定結果は、ピアからフィードバックされた後、ＣＳが予測モデルを再適合させる。その間に、時刻、ネットワーク状況および他の情報に基づいて、ＣＳは、予測モデルをそれに応じて調整する。オンラインデータ解析およびオフラインデータ予測は、プローブ効率を向上させる。これは、ピアがそのプロービングを完了するとき、同じソースに位置する他のピアおよび送信先ＮＡＴ／ＩＳＰドメインが、これらのプロービング結果を候補の事前選択のために使用することができるからである。データ解析および予測機能もこの情報を使用して、ＣＳのデータベースを能率化する。
【０１２８】
このとき、本発明のシステムおよび方法によって提供されたプロービングアルゴリズムおよび結果解析の前述の考察から明らかになるように、uProbeツールおよびそのアルゴリズムは、エンドツーエンド遅延、ボトルネック帯域幅、パケット損失率など、いくつかのＱｏＳ測定規準を同時に測定することができる。さらに、アップリンクおよびダウンリンクのための非対称ネットワーク状態を別々に、Ｐ２ＰのＱｏＳプロービング方式の一実施形態を使用して測定することができる。ネットワークのＲＴＴは、長期依存特性を有し、したがってＲＴＴの分布が低速で変化する。すなわち、短期におけるＲＴＴの変化は小さい。密度推定方式を使用して、ボトルネック帯域幅の測定結果が表わされる。このようにして、プロービングパケットペアの数が非常に少なく、すなわち１または２に等しいとき、測定結果は、ランダムに分布する。プロービングパケットペアの数が増え、すなわち３以上であると、最終的なボトルネック帯域幅の値は、測定された最高密度の帯域幅である。プロービングパケットペアの数がしきい値、すなわちネットワーク輻輳レベルを許容することができる値より大きくなるとき、プロービングの精度および増大するプロービング時間の間に強い相関はない。
【０１２９】
当業者には理解されるように、ピアがネットワークの背後に接続することができる標準のＮＡＴに加えて、いくつかの他の非標準ＮＡＴタイプがある。例えば、いくつかのＮＡＴは、単に最後のコネクションをアドレス／ポートマッピングテーブルにおいて維持し、これにより、通信プロセスの一実施形態をそのＮＡＴの背後にあるマシンについて実施することが不可能となる。このような状況では、本発明の代替実施形態は、同じＮＡＴの背後にある２つのピア間の通信効率を、ローカルＩＰおよびローカルポートについての情報をログインステージで記録することによって改善する。次に、システムは、これらの間でローカルＩＰおよびポートを通じたコネクションをセットアップしようと試みる。
【０１３０】
本発明の原理を適用させることができる多数の可能な実施形態に鑑みて、図に関して本明細書に記載された実施形態が例示的なものとしてのみ意味され、本発明の範囲を制限するものとして取られるべきでないことを理解されたい。例えば、ソフトウェアにおいて示す、例示した実施形態の要素をハードウェアにおいて実施することができ、逆もまた同じであること、または、本発明の精神から逸脱することなく、例示した実施形態を構成および詳細において修正できることは、当業者には理解されよう。したがって、本明細書に記載した本発明は、特許請求の範囲およびその均等物の範囲内に入る可能性のあるようなすべての実施形態を企図する。
【図面の簡単な説明】
【図１】本発明のシステムおよび方法が特定の関連を見出すＰ２Ｐの基盤を例示する簡素化されたネットワークブロック図である。
【図２】本発明の一実施形態にかかる操作のログインステージを例示する簡素化された流れ図である。
【図３】本発明の一実施形態にかかる操作のデータ解析と事前選択ステージを例示する簡素化された流れ図である。
【図４】本発明の一実施形態にかかる操作のプローブと測定ステージを例示する簡素化された流れ図である。
【図５】本発明の一実施形態にかかる操作のログとフィードバックステージを例示する簡素化された流れ図である。
【図６】図２〜５の操作ステージにおいて使用される統一パケットフォーマットを例示するデータ構造図である。
【図７】本発明の一実施形態における、成功したプロービング結果を通知するために使用されるメッセージフォーマットを例示する簡素化されたメッセージフォーマット図である。
【図８】本発明の一実施形態における、ホップバイホップのプロービング結果を通知するために使用されるメッセージフォーマットを例示する簡素化されたメッセージフォーマット図である。
【図９】本発明の一実施形態において使用される、修正されたパケットペアのプロービング方式を例示する簡素化された通信流れ図である。
【図１０】本発明の一実施形態における、Ｐ２Ｐのプロービングに使用されるプロービングパケットフォーマットを例示するデータ構造図である。
【図１１】本発明の一実施形態において使用される、ホップバイホップのパケット列プロービング方式を例示する簡素化された通信流れ図である。
【図１２】本発明の一実施形態における、コネクション・サーバによって実行されるオフラインデータ解析およびオンラインデータ予測を例示する簡素化された機能ブロック図である。
【符号の説明】
１００、１０２、１０４、１０６、１０８、１１０ ゲームボックス
１１２、１１４、１１６、１１８ ネットワークアドレストランスレータ
１２０、１２２、１２４ コネクション・サーバ

Claims (26)

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. 少なくとも第１のピアと第２のピアとの間のピアツーピアネットワークにおいてサービス品質パラメータをプローブする方法をコンピュータに実行させるためのコンピュータ実行可能命令を有するコンピュータ読み取り可能な記録媒体であって、前記コンピュータ実行可能命令は、
    前記第１のピアによって第１および第２のプロービングパケットを生成する第１１ステップであって、各プロービングパケットは、第１のタイムスタンプを含む第１１ステップと、
    前記第１のプロービングパケットおよび前記第２のプロービングパケットをプロービングパケットペアとして前記第２のピアに送信する第１２ステップであって、各プロービングパケットの前記第１のタイムスタンプは、該プロービングパケットが送信される時間を示し、
    アクセス帯域幅が十分大きいときに、前記プロービングパケットペアの間隔を決定するステップと、
    ポアソン分布を使用してあるピアに対して送信する前記プロービングパケットペアの前記間隔を記述し、異なるピアにおいては異なる到着率を有することを認識するステップとを含む第１２ステップと、
    前記第２のピアから、前記第１のプロービングパケットおよび前記第２のプロービングパケットに対応する第１の応答パケットおよび第２の応答パケットを受信する第１３ステップであって、前記各応答パケットは、前記応答パケットに対応する前記プロービングパケットの前記第１のタイムスタンプを含み、第２のタイムスタンプは、前記対応するプロービングパケットが前記第２のピアに到着した時間を示し、および、第３のタイムスタンプは、前記応答パケットが前記第２のピアによって送信された時間を示す第１３ステップと、
    前記ネットワークのサービス品質パラメータを、前記第１の応答パケットおよび前記第２の応答パケットの前記第１のタイムスタンプ、前記第２のタイムスタンプおよび前記第３のタイムスタンプの関数として計算する第１４ステップと
    を備えたことを特徴とするコンピュータ読み取り可能な記録媒体。

Images