JP2003249958A - 大規模ネットワークのためのピアツーピアベースのネットワーク性能測定および分析システムおよび方法 - Google Patents

Abstract

(57)【要約】 【課題】 インターネットなどの大規模ネットワークに
対して、スケーラブルであるが、大きい測定オーバヘッ
ドによる負担のない、ネットワーク性能分析アーキテク
チャを提供する。 【解決手段】 デバイスの自己組織化されたプロービン
ググループに基づく、大規模ネットワークのためのネッ
トワーク性能(たとえば、待ち時間や帯域幅)測定インフ
ラストラクチャ。デバイスの各グループが、ネットワー
ク特性を測定するリードデバイスを有し、次いで、その
測定情報を他のデバイスと共有する。このグルーピング
方法では、十分な測定のために必要なネットワーク帯域
幅の量が減少するが、それでも個々のデバイスに対して
必要な情報が提供される。本システムは、グループ内お
よびグループ間性能測定の両方に採用される新規なマル
チキャストベースのアルゴリズムを利用する。測定グル
ープ(MeGroup)は、動的であり自己形成的であり、1セッ
トの発見的アルゴリズムを使用して、動的なグルーピン
グを最適化する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、一般に、ネットワ
ーク性能測定システムに関し、より詳細には、たとえ
ば、インターネットなどの大規模ネットワークのための
分散型性能測定インフラストラクチャに関する。

【０００２】

【従来の技術】インターネット上のユーザの数やトラフ
ィック量が増すにつれて、ユーザおよびネットワークサ
ービスプロバイダの両者が共に、所与のインターネット
経路の性能および信頼性についての正確かつ共通の理解
ができるようになるための、1セットのネットワーク性
能メトリクスおよび測定方法が入手可能であることが最
も重要なこととなってきた。このような理解すべきもの
のなかには、所与のインターネット経路のうちのどのセ
グメントが、その性能および信頼性を制限しているのか
についての情報が含まれていなければならない。ユーザ
の側から見ると、いったん1セットのネットワーク性能
メトリクスおよび測定ツールが整備されれば、自身がど
のような種類のサービスを受けているのかについての正
確な知識を持つことが極めて容易になる。この情報によ
り、ユーザは、さまざまなネットワークサービスプロバ
イダの相対性能を比較できるようになる。同様に、ネッ
トワーク性能測定からの知識により、ネットワークプロ
バイダ自身も、ネットワークキャパシティを向上させる
ためにより強力な交換機をインテリジェントに配備する
ことができるようになる。同じように、コンテンツベー
スのサービスプロバイダが、この情報を使用して、その
ウェブサーバを最適な形で配備し管理することができ
る。

【０００３】つまり、この性能情報が、多くのインター
ネットサービスおよびシステムによって使用されると、
ピアツーピアシステムまたはアプリケーションレベルの
マルチキャストツリーのための頑強なオーバーレイの生
成が可能となり、ユーザによって使用されると、多くの
サーバミラー間から1つのサーバの選択が可能となり、
サービスプロバイダによって使用されると、サーバのレ
プリカの配置を判断して、コンテンツ配信ネットワーク
の性能を向上することができる。しかし、調査団体か
ら、インターネット測定インフラストラクチャを構築す
るためのプロポーザルが多く出されているにもかかわら
ず、インターネットの規模と複雑性の両方により、この
ようなインフラストラクチャを、近い将来に十分に配備
し動作可能にするのは困難である。

【０００４】クライアントからの所与のサービス要求
を、いくつかのインターネットサーバの1つによって満
たすことができるような状況が、ますます増加してきて
いる。その例は、ウェブサーバへの単一のウェブページ
のアクセスなどの一時的なインタラクションから、2つ
のニュース(NNTP)サーバ間の長期的なピアリング関係ま
で及ぶ。他のすべての条件が同じ場合、このようなすべ
てのインタラクションでは、低い待ち時間または高い帯
域幅を有する、最も近いサーバにアクセスするのが有利
である。たとえ他の条件がすべて同じわけではない場合
でも、たとえば、異なるウェブサーバが異なる応答時間
を有する場合に、選択を行う際の要因として、各候補ホ
ストまでの距離を含めることは、やはり有益である。

【０００５】ネットワーク性能測定および分析につい
て、いくつかの調査活動が行われてきており、その教示
および開示全体を、参照により本明細書に組み込んであ
る。上記教示および開示は、たとえば、非特許文献１〜
４を含む。これらのすべての活動の結果、インターネッ
ト性能測定インフラストラクチャの確立が、インターネ
ットの最適なオペレーションおよび健全な成長のための
究極のソリューションであるとの共通の理解に達した。

【０００６】

【非特許文献１】P. Francis et al., "An Architectur
e for a Global Internet HostDistance Estimation Se
rvice," Proc. of IEEE INFOCOM 1999. March 1999

【０００７】

【非特許文献２】Sandra G. Dykes, Clinton L. Jeffer
y, and Kay A. Robbins. "An Empirical Evaluation of
Client Side Server Selection Algorithms," Proc. o
f IEEE INFOCOM '2000, 2000

【０００８】

【非特許文献３】James D. Guyton and Michael F. Sch
wartz," Locating Neaby Copies of Replicated Intern
et Servers," Proc. of ACM SIGCOMM '95, pp. 288-29
8, 1995

【０００９】

【非特許文献４】A. Myers, P. Dinda, and H. Zhang,
"Performance Characteristicsof Mirror Servers on
the Internet", Proc. of IEEE INFOCOM '99, Mar. 199
9

【００１０】

【発明が解決しようとする課題】ネットワーク性能情報
を得るための1つの方法が、各起動ホストが、ユニキャ
ストまたはマルチキャストツールを使用して、ネットワ
ーク性能自体を測定することである。しかし、多数のホ
ストが、独立した測定を頻繁にする場合は、このこと
は、インターネットに厳しい影響を及ぼすことになる。
残念なことに、現在のシステムにおいては、1つのホス
トによってなされた測定は、他のホストが入手できな
い。その情報を必要とする各ホストが、独立して、それ
を測定しなければならないため、このようなシステムの
測定オーバヘッドが増加する。その結果、インターネッ
トの規模および複雑性の両方により、このような規模の
測定インフラストラクチャが、近い将来に配備され、十
分に動作可能となる可能性は低い。この問題は、インタ
ーネットがなお指数関数的速度で増加し続けている事実
によって、さらに、深刻化する。

【００１１】したがって、当技術分野では、インターネ
ットなどの大規模ネットワークに対して、スケーラブル
であるが、大きい測定オーバヘッドによる負担のない、
ネットワーク性能分析アーキテクチャが必要とされてい
る。

【００１２】

【課題を解決するための手段】本発明によるシステムお
よび方法は、大規模ネットワークのための新しくて改良
された測定インフラストラクチャを提供することであ
る。より詳細には、本発明によるシステムおよび方法
は、大規模ネットワークにおける測定オーバヘッドを減
少させるために、分散型グループおよび共有性能評価を
利用する、新しくて改良された測定インフラストラクチ
ャを提供することである。

【００１３】より具体的には、本発明による一実施形態
が、大規模ネットワークのための、本明細書で、gMeasu
reと称する、測定インフラストラクチャを提供する。こ
のインフラストラクチャは、ネットワーク内に分散して
配備され、測定したネットワーク性能情報を有効に共有
する、自己組織化されたプロービンググループ(測定グ
ループまたはMeGroup)に基づいている。本発明によるイ
ンフラストラクチャの1つの特徴は、測定している個々
のホストから収集されたデータおよびにその隣接のグル
ープによって収集されたデータを最大限活用することに
より、それがネットワーク全体の性能を推定/推論する
ことである。ホストが、MeGroupに自己組織化されて、
スケーラブルな階層構造を形成する。新規なマルチキャ
ストベースのアルゴリズムが、グループ内およびグルー
プ間の両方の性能測定に採用される。さらに、1セット
の発見的アルゴリズムを使用して、グループ組織を最適
化し、推定精度を向上させる。隣接間の共有作業によ
り、測定オーバヘッドを非常に低く保ち、大規模ネット
ワークに対するスケーラビリティを可能にする。

【００１４】gMeasureインフラストラクチャのいくつか
の自己組織化された測定グループ(MeGroup)のそれぞれ
に、グループリードがある。これらの性能プロービング
グループの各グループリードは、そのグループ内および
その隣接のグループ間のデータ配布を担当する。このグ
ループリードは、グループ間性能測定の代表として働く
ために動的に選ばれる。ホストが、ネットワーク性能を
ローカル規模でアクティブに測定し、次いで、この測定
した情報を同じグループ内の他のホストと共有すること
により、ネットワーク性能を得る。グループリードはま
た、その隣接である他のMeGroupからのグループリード
と、測定した情報を交換する。

【００１５】一実施形態では、gMeasureインフラストラ
クチャに、3つの一次機能が含まれている。データ収集
機能は、待ち時間や帯域幅などのネットワーク状態を測
定する。データ共有機能を使用すると、同じプロービン
ググループ内の他のホストから得られた測定したネット
ワーク性能情報と、隣接のグループから得られた性能情
報とを共有することに基づいて、ネットワーク状態の予
測ができるようになる。最後に、データ配布機能は、測
定したネットワーク性能情報を同じグループ内の他のホ
ストおよび隣接するグループと共有する。測定アーキテ
クチャの一特徴は、それが一部アクティブプロービング
に頼っており、データ共有およびデータ予測からのネッ
トワーク性能統計を活用して、最小オーバヘッドでネッ
トワーク性能判断を達成する本発明による一実施形態で
は、ネットワーク性能測定サービスを構築し、関係する
機能を分散されたアプリケーションに提供するために、
gMeasureが、ホストの自己組織化しているプロービング
グループに、集約可能識別子を有するグループとネット
ワーク性能ベースのグループに対して主な焦点をあてる
ようにする。インフラストラクチャはまた、測定したネ
ットワーク性能のためにプロービンググループ間で選定
を実施するためのグループ選択メカニズムを含む。これ
らのメカニズムはまた、動的グループ再生をサポートす
る。本発明によるインフラストラクチャによって提供さ
れるデータ配布は、プロービンググループを使用して、
測定したデータ分布を最適化する。最後に、本発明によ
るインフラストラクチャは、データ配布ツールと統合性
能モニタツールの上に構築されたキャパシティ監視メカ
ニズムを提供する。このメカニズムは、現在入手可能な
ネットワーク性能のリアルタイムレポートを提供する。

【００１６】本発明によるgMeasureインフラストラクチ
ャの実施形態には、以下の設計機能の1つまたは複数が
組み込まれている。このような特徴の1つが、インフラ
ストラクチャが分散されていることである。つまり、プ
ロービンググループと測定サービスを、インターネット
を経由して多くの場所に配備できる。インフラストラク
チャはまた、非集中型にもなる。すなわち、測定した情
報が局所的に収集され分析される。決定も局所的に行わ
れ、中央の権限を必要としない。完全非集中型システム
は困難であるが、本発明による実施形態では、データ配
布や性能予測などの、分散された極めて重要なアクショ
ンを行い、これは、やはりシステム全体にとって極めて
有益なことである。さらに、本発明による実施形態が、
自分自身を段に組織化する、協力構成要素を有する段に
分かれる。各段が、システムの残りの部分知識のビュー
範囲、精度、詳細、適時性の異なるトレードオフを表
す。

【００１７】本発明によるインフラストラクチャの実施
形態はまた、有機的でもある。ホストがネットワークに
追加されると、ホストは、自動的に統合され、ネットワ
ーク測定インフラストラクチャは、再構成される。さら
に、本発明によるインフラストラクチャは、ネットワー
クトラフィック分析と予測精度との間にトレードオフが
あることを認識し、良いバランスを示す。一般に、測定
データを多く集めれば集めるほど、より良い精度を得る
ことができる。ネットワークを、1時間毎に測定した場
合と比べ、5分毎に測定した場合の方が、分析がより正
確となるが、バランスが悪くならざるを得ない。そうで
ない場合は、各ホストによるネットワークの頻繁なプロ
ービングにより、プロービング自体が、測定しようとし
ている、まさにネットワーク性能自体を遅らせるトラフ
ィックソースとなる。これが、測定オーバヘッドとトラ
フィックプロービングの精度とバランスを発見するため
の分析とのトレードオフである。最後に、ネットワーク
性能測定が、効率的な方法で行われる。

【００１８】本明細書に組み込まれ、その一部を形成す
る添付図面は、本発明のいくつかの態様を示し、詳細な
説明とともに、本発明の原理を説明するのに役立つ。

【００１９】本発明をある好ましい実施形態とともに記
述するが、本発明はこれらの実施形態に限定されるもの
ではない。その反対に、本発明の趣旨および範囲には、
特許請求の範囲で定義したように、すべての代替形態、
修正形態、均等物を含むものとする。

【００２０】次に図面を参照すると、同様の参照番号
は、同様の要素を表し、本発明は、適切な計算環境内で
実施されるものとして示してある。必要とされるもので
はないが、本発明を、パーソナルコンピュータによって
実行される、プログラムモジュールなどの、コンピュー
タ実行可能命令の一般的な状況下で記述する。一般的
に、プログラムモジュールには、特定のタスクを行い、
特定の抽象データタイプを実施する、ルーチン、プログ
ラム、オブジェクト、構成要素、データ構造などが含ま
れる。その上、本発明が、ハンドヘルドデバイス、マル
チプロセッサシステム、マイクロプロセッサベースのま
たはプログラマブルの大衆消費電子製品、ネットワーク
PC、ミニコンピュータ、メインフレームコンピュータな
どを含む、他のコンピュータシステム構成とともに実践
できることは、当業者なら理解されるであろう。本発明
はまた、タスクが通信ネットワークを介してリンクされ
たリモート処理デバイスによって行われる、分散型計算
環境内でも実践できる。分散型計算環境においては、プ
ログラムモジュールを、ローカルとリモートの両方の記
憶装置デバイス内に置くことができる。

【００２１】

【発明の実施の形態】図1は、本発明を実施できる、適
切な計算システム環境100の一例を示す図である。計算
システム環境100は、適切な計算環境の一例に過ぎず、
本発明の使用法および機能の範囲を限定するものではな
い。また、計算環境100は、オペレーティング環境100の
例で示した構成要素のいずれか1つ、またどれかの組合
せに関係した依存性または必要条件を有するものとは解
釈されない。

【００２２】本発明は、他の数々の汎用または専用計算
システム環境または構成とともに動作可能である。本発
明とともに使用するのに適切であり得る、周知の計算シ
ステム、環境および/または構成の例には、パーソナル
コンピュータ、サーバコンピュータ、ハンドヘルドまた
はラップトップデバイス、マルチプロセッサシステム、
マイクロプロセッサベースのシステム、セットトップボ
ックス、プログラマブル大衆消費電子製品、ネットワー
クPC、ミニコンピュータ、メインフレームコンピュー
タ、上記のシステムまたはデバイスのいずれかを含む分
散型計算環境などが含まれるが、これらに限定されるも
のではない。

【００２３】本発明を、コンピュータによって実行され
る、プログラムモジュールなどの、コンピュータ実行可
能命令の一般的な状況下で記述する。一般的に、プログ
ラムモジュールには、特定のタスクを行うかまたは特定
の抽象データタイプを実施する、ルーチン、プログラ
ム、オブジェクト、構成要素、データ構造などが含まれ
る。本発明はまた、タスクが通信ネットワークを介して
リンクされたリモート処理デバイスによって行われる、
分散型計算環境内でも実践できる。分散型計算環境にお
いては、プログラムモジュールを、記憶装置デバイスを
含むローカルとリモートの両方のコンピュータ記憶装置
媒体内に置くことができる。

【００２４】図1を参照すると、本発明を実施するため
のシステムの例に、コンピュータ110の形式の汎用計算
デバイスが含まれている。コンピュータ110の構成要素
には、処理ユニット120、システムメモリ130、システム
メモリを含むさまざまなシステム構成要素を処理ユニッ
ト120に連結するシステムバス121が含まれるが、これら
に限定されるものではない。システムバス121は、さま
ざまなバスアーキテクチャのどれかを使用する、メモリ
バスまたはメモリコントローラ、周辺バス、ローカルバ
スを含む、いくつかのタイプのバス構造のいずれでもあ
り得る。例示として、このようなアーキテクチャには、
業界標準アーキテクチャ(ISA)バス、マイクロチャネル
アーキテクチャ(MCA)バス、エンハンスISA(EISA)バス、
ビデオ電子装置規格化協会(VESA)ローカルバス、メザニ
ンバスとしても周知の周辺構成要素(PCI)バスが含まれ
るが、これらに限定されるものではない。

【００２５】コンピュータ110には、通常、さまざまな
コンピュータ読取り可能媒体が含まれる。コンピュータ
読取り可能媒体は、コンピュータ110からアクセスでき
る、どの入手可能な媒体でも良く、揮発性および不揮発
性媒体、取外し可能および取外し不可能媒体の両方を含
む。例示として、コンピュータ読取り可能媒体には、コ
ンピュータ記憶媒体と通信媒体とを備える場合がある
が、これらに限定されるものではない。コンピュータ記
憶媒体には、コンピュータ読取り可能命令、データ構
造、プログラムモジュールまたは他のデータなどの情報
を格納するための、どのような方法または技術でも実施
される、揮発性および不揮発性、取外し可能および取外
し不可能媒体の両方が含まれる。コンピュータ記憶媒体
には、RAM、ROM、EEPROM、フラッシュメモリまたは他の
メモリ技術、CD-ROM、ディジタルビデオディスク(DVD)
または他の光学ディスク記憶装置、磁気カセット、磁気
テープ、磁気ディスク記憶装置または他の磁気記憶装置
デバイス、または所望の情報を格納しコンピュータ110
からアクセスできる、他のどのような媒体でも含まれる
が、これらに限定されるものではない。通信媒体には、
通常、搬送波または他のトランスポートメカニズムなど
の変調データ信号内にコンピュータ読取り可能命令、デ
ータ構造、プログラムモジュールまたは他のデータが包
含され、どのような情報配信媒体も含まれる。用語"被
変調データ信号"は、その特性セットの、1つまたは複数
を有するか、または信号内の情報を符号化するような方
式で変更された信号を意味する。例示として、通信媒体
には、ワイヤードネットワークまたは直接ワイヤード接
続などのワイヤード媒体と、音響、RF、赤外および他の
ワイヤレス媒体などのワイヤレス媒体とを含むが、これ
らに限定されるものではない。上述したもののいずれの
組合せも、コンピュータ読取り可能媒体の範囲内に含ま
れるものである。

【００２６】システムメモリ130は、読取専用メモリ(RO
M)131やランダムアクセスメモリ(RAM)132などの揮発性
および/または不揮発性メモリの形式のコンピュータ記
憶媒体を含む。基本入出力システム133(BIOS)が、スタ
ートアップ中などに、コンピュータ110内の素子間で情
報を転送するのに役立つ基本ルーチンを含み、通常、RO
M131内に格納されている。RAM132には、通常、処理ユニ
ット120にただちにアクセス可能なかつ/または処理ユニ
ット120内で現在動作可能な、データおよび/またはプロ
グラムモジュールが含まれる。例示として、図1は、オ
ペレーティングシステム134、アプリケーションプログ
ラム135、他のプログラムモジュール136、プログラムデ
ータ137を示すが、これらに限定されるものではない。

【００２７】コンピュータ110はまた、他の取外し可能/
取外し不可能、揮発性/不揮発性コンピュータ記憶媒体
を含む。単なる例示として、図1に、取外し不可能、不
揮発性磁気媒体から読み取りそこに書き込むハードディ
スクドライブ141と、取外し可能、不揮発性磁気ディス
ク152から読み取りそこに書き込む磁気ディスクドライ
ブ151と、CD ROMまたは他の光学媒体などの、取外し可
能、不揮発性光学ディスク156から読み取りそこに書き
込む光学ディスクドライブ155とを示す。オペレーティ
ング環境の例において使用できる、他の取外し可能/取
外し不可能、揮発性/不揮発性コンピュータ記憶媒体に
は、磁気テープカセット、フラッシュメモリカード、デ
ィジタルビデオディスク、ディジタルビデオテープ、ソ
リッドステートRAM、ソリッドステートROMなどが含まれ
るが、これらに限定されるものではない。ハードディス
クドライブ141は、通常、インターフェイス140などの取
外し不可能メモリインターフェイスを介してシステムバ
ス121に接続し、磁気ディスクドライブ151と光学ディス
クドライブ155は、通常、インターフェイス150などの取
外し可能メモリインターフェイスによってシステムバス
121に接続する。

【００２８】上述し、図1に示した、ドライブおよびそ
れに関連するコンピュータ記憶媒体は、コンピュータ11
0のための、コンピュータ読取り可能命令、データ構
造、プログラムモジュールおよび他のデータの記憶装置
を提供する。たとえば、図1には、ハードディスクドラ
イブ141が、オペレーティングシステム144、アプリケー
ションプログラム145、他のプログラムモジュール146、
プログラムデータ147を格納して示してある。これらの
構成要素が、オペレーティングシステム134、アプリケ
ーションプログラム135、他のプログラムモジュール13
6、プログラムデータ137と同じまたは異なるもののどち
らでも良いことに留意されたい。オペレーティングシス
テム144、アプリケーションプログラム145、他のプログ
ラムモジュール146、プログラムデータ147には、所与の
異なる数字を付けてあるが、これは、最小限、異なるも
のであることを示す。ユーザが、コマンドおよび情報
を、キーボード162や、通常マウス、トラックボールま
たはタッチパッドと称するポインティングデバイス161
などの入力デバイスを介してコンピュータ110に入力で
きる。他の入力デバイス(図示せず)には、マイクロホ
ン、ジョイスティック、ゲームパッド、衛星放送用パラ
ボラアンテナ、スキャナなどを含むことができる。これ
らのおよび他の入力デバイスは、しばしば、システムバ
スに結合されたユーザ入力インターフェイス160を介し
て処理ユニット120に接続するが、パラレルポート、ゲ
ームポート、ユニバーサルシリアルバス(USB)などの、
他のインターフェイスおよびバス構造にも接続できる。
モニタ191または他のタイプのディスプレイデバイスも
また、ビデオインターフェイス190などのインターフェ
イスを経由してシステムバス121に接続する。モニタに
加えて、コンピュータにはまた、出力周辺インターフェ
イス195を介して接続できる、スピーカ197やプリンタ19
6などの他の周辺出力デバイスも含むことができる。

【００２９】コンピュータ110は、リモートコンピュー
タ180などの、1つまたは複数のリモートコンピュータへ
の論理接続を使用する、ネットワークされた環境内で動
作できる。リモートコンピュータ180は、別のパーソナ
ルコンピュータ、サーバ、ルータ、ネットワークPC、ピ
アデバイスまたは他の共通ネットワークノードであり
得、通常、パーソナルコンピュータ110に関して上述し
た素子の多くまたはすべてを含むが、図1には、記憶装
置デバイス181のみを示してある。図1に図示した論理接
続は、ローカルエリアネットワーク(LAN)171とワイドエ
リアネットワーク(WAN)173とを含むが、他のネットワー
クも含むことができる。このようなネットワーキング環
境が、オフィス、全社的コンピュータネットワーク、イ
ントラネット、インターネット内で、一般化している。

【００３０】LANネットワーキング環境内で使用される
場合、パーソナルコンピュータ110は、ネットワークイ
ンターフェイスまたはアダプタ170を介してLAN17lに接
続する。WANネットワーキング環境内で使用される場
合、コンピュータ110は、通常、インターネットなどのW
AN173を経由して通信を確立するためのモデム172または
他の手段を含む。モデム172は、内部でも外部でもあり
得るが、ユーザ入力インターフェイス160または他の適
切なメカニズムを経由してシステムバス121に接続でき
る。ネットワークされた環境において、パーソナルコン
ピュータ110に関して図示されたプログラムモジュー
ル、またはその一部を、リモート記憶装置デバイス内に
格納できる。例示として、図1には、メモリデバイス181
に常駐して、リモートアプリケーションプログラム185
を示してあるが、これに限定されるものではない。示し
たネットワーク接続は例示のためであり、コンピュータ
間で通信リンクを確立する他の手段も使用できることを
理解されるであろう。

【００３１】以下の記述においては、特にそれ以外のこ
とが示されていない限り、1つまたは複数のコンピュー
タによって行われる作用、およびオペレーションの記号
表示を参照しながら、本発明を記述していく。そのた
め、時に、コンピュータ実行と称する、このような作用
およびオペレーションには、構造化形式でデータを表す
電気信号のコンピュータの処理ユニットによる操作が含
まれることを理解されるであろう。この操作が、コンピ
ュータのメモリシステム内の複数の場所で、データを変
換し維持し、当業者には良く理解されている方式でコン
ピュータのオペレーションを再構成しまたはその他の変
更をする。データが維持されているデータ構造は、その
データのフォーマットによって定義された特定のプロパ
ティを有するメモリの物理的な場所である。しかし、本
発明を上記の状況下で記述していくが、当業者なら理解
されるであろうが、以下に記述するさまざまな作用およ
びオペレーションがハードウェア内でも実施されること
に限定されるものではない。

【００３２】本発明によるネットワーク測定インフラス
トラクチャにおいて、ネットワーク性能情報、距離が、
待ち時間(たとえば、ラウンドトリップ遅延)、そして可
能な場合には、帯域幅の面で提供される。待ち時間が、
提供するのに最も容易な種類の情報であり、通常、一般
的に最も有用である。待ち時間情報が、提供するのに最
も容易であるのには、2つの理由がある。まず最初に、
ネットワーク待ち時間のおおまかだが良い推定を出すた
めに、ほんの少数のパケットしか必要としないという点
で、測定が容易である。第2に、ネットワークを介して2
つの異なる経路が、同じ待ち時間を有することがあるた
め、待ち時間判断のために使用されるプロービングパケ
ットが、ユーザのデータパケットによって実際にとられ
た経路と同じ経路を進まない場合があるが、報告される
待ち時間はやはり有用であることである。

【００３３】帯域幅もまた、多くのアプリケーションに
とって明らかに重要であるが、待ち時間と比較すると、
帯域幅の方が、提供するのにより困難である。帯域幅は
また、測定するのが高価であり、正確な経路に対してよ
りセンシティブである。実際、ネットワーク経路内の単
一の低い帯域幅リンクが、経路全体のための帯域幅を決
定づける。また、待ち時間と帯域幅の間にラフなやりと
りがあるようである。つまり、2つのホスト間の待ち時
間が低ければ低いほど、帯域幅が高くなる可能性があ
る。このやりとりにより、高い帯域幅を必要とするアプ
リケーションが、第1の概算として最小化された待ち時
間を有するサービス/サーバ/経路を選択できるようにな
る。大規模ネットワークにおいて帯域幅メトリックを測
定するのは難しいが、本発明によるシステムは、以下に
詳細に記載するように、TCPプロービングパケットを利
用して、このような測定を達成する。

【００３４】距離推定値を導出するために、本発明によ
る一実施形態が、三角法技術を利用する。この技術を理
解するために、大規模ネットワーク内のホストが、頂点
Vのセットを有するグラフGを構築すると想定する。費用
関数Cが、グラフ内のすべての頂点A、B、Cのための三角
不式を満足すると言われている。 C(A,C)≦C(A,B)+C(B,C) 式1 ネットワークメトリクスC(A,B)およびC(B,C)が周知であ
る場合は、式1の三角不式から、ネットワークメトリッ
クC(A,C)が、C(A,B)+C(B,C)だけ上に、また│C(A,B)-C
(B,C)?だけ下に限られることが分かる。つまり、 │C(A,B)-C(B,C)│≦C(A,C)≦C(A,B)+C(B,C) 式2 特に、C(A,B)が非常に小さい場合は、C(B,C)を使用し
て、C(A,C)=C(B,C)である、C(A,C)を推定することがで
きる。ここで、C(A,B)<<C(B,C)である。以下の記述で
は、C(A,B)を表すために(A,B)を使用する。この境界か
ら距離推定値を導出することは、P. Francis et al., "
An Architecture for a Global Internet Host Distanc
e Estimation Service," Proc. of IEEE INFOCOM 1999,
March 1999"の中で三角法"と称されている。その教示
および開示全体を参照により本明細書に組み込んであ
る。この想定は、効率的なルーティングであるというさ
らなる想定に基づいている。効率的なルーティングと
は、インターネットルーティングが、低待ち時間経路を
懸命に捜そうとし、2つの近接のホストによって使用さ
れるルートが、互いに劇的に異ならないということであ
る。幸いなことに、大抵、ルーティング状況が、このよ
うな想定の良い基礎を提供する。

【００３５】本発明によるシステムはまた、近接のホス
トが、他のホストと同様の待ち時間を有すると想定す
る。本インフラストラクチャの一実施形態において、A
からBへのラウンドトリップ時間が、T未満、すなわち、
RTT(A,B)<Tの場合は、2つのホスト、AおよびBが、互い
に"近接"している。ここで、Tは、閾値として働く、小
さい値である。Tは、本明細書の以下に記載する、プロ
ービンググループ形成手順における重要なパラメータで
ある。これは、システム全体の精度および性能に影響す
る。定義したように、すべての近接のホストが、特定の
ホストに対し低い待ち時間を有し、三角法の想定から、
それぞれが互いに小さい待ち時間を有するため、各近接
のホストが、他のすべての近接のホストに対し、同様の
RTTを有さなければならないことが示される。

【００３６】これらのコンセプトを明確に頭に入れた上
で、次に、本発明によるインフラストラクチャ(gMeasur
e)に、直接、注意を向けることとする。このインフラス
トラクチャは、主に、インターネット上のいずれか2つ
の有効なIPアドレス間などの、大規模ネットワーク内の
いずれか2つのホスト間のネットワーク性能の推定値を
提供する。この機能は、gMeasureを、これも、ネットワ
ーク性能情報、すなわち、 M. Stemm, R. Katz, and S. Seshan, "A Network Measu
rement Architecturefor Adaptive Applications," Pro
c. of IEEE INFOCOM '00, pp. 2C-3, Mar. 2000 C. Labovitz et al., "Internet performance measurem
ent and analysis project," url:http://www.merit.ed
u/ipma/, 1998 V. Paxson, J. Mahdavi, A. Adams, and M. Mathis, "A
n Architecture for Large-Scale Internet Measuremen
t," IEEE Communications Magazine, vol. 36,no. 8, p
p. 48-54, August 1998および A. Adams et al., "The Use of End-to-End Multicast
Measurements for Characterizing Internal Net-work
Behavior," IEEE Communications Magazine, pp. 152-1
58, May 2000 で議論されているSPAND、IPMA、NIMI、M1NCプロジェク
ト(例えば、非特許文献6、7、8、9参照)を提供する、他
のサービスから著しく区別する。これらのプロジェクト
は、一般的なインターネットの特徴付け、維持、故障分
離、エンドシステム距離評価などの、さまざまな目的に
役立つ。しかし、本発明による測定インフラストラクチ
ャは、大規模ネットワーク、たとえばインターネット内
のいずれか2つの任意のポイント間でネットワーク性能
情報を提供する分散型測定アーキテクチャである。

【００３７】アプリケーション適合ポリシを進めるため
のネットワーク測定サービスを生成する以前の試みにお
いて、主に、分離したネットワーク統計測定に焦点を合
わせていた。分離した測定とは、アプリケーションが、
個々に、ネットワークの状態の測定を行い、この測定情
報を他のホストとは共有しないということである。ピア
ツーピアファイル共有およびクライアントホステッドマ
ルチプレイヤゲームなどの、距離情報を必要とするアプ
リケーションの増加とともに、この分離した集中型ネッ
トワーク測定の集合した負荷が、ほぼN²程度で拡大す
る。ここで、Nは、ネットワーク内のホストの数であ
る。この結果、大量の測定トラフィックが生じ、実際
に、ネットワークが過負荷となる。

【００３８】このような従来の方法とは全く反対に、本
発明によるインフラストラクチャは、プロービンググル
ープコンセプトに基づいてネットワーク性能を測定する
が、これは、ネットワークに大きい負荷を与えない。プ
ロービンググループが、近接のホストによって構築され
る。プロービンググループの、この"近接"特性は、性能
測定および予測のための良い環境を提供する。上述した
ように、2つのホストがネットワークトポロジの面で互
いに近接している場合、それらが、リモートサイトに対
して同じボトルネックリンクを共有する可能性が高い。
その結果、このサイトに対して測定するネットワーク性
能が同様になる可能性が高い。したがって、これらのホ
ストのそれぞれが、独立してネットワークをプローブ
し、この情報を発見することは、不必要でありかつ望ま
しくもない。本発明によるインフラストラクチャにおい
ては、多くの近接のホストが、測定情報を互いに共有し
て、必要なプロービングを最小限に押さえ、それによ
り、このようなプロービングの結果生じるネットワーク
負荷を最小限に押さえる。

【００３９】プロービンググループ、または測定グルー
プ(MeGroup)が、グループのリーダと呼ばれる、特定の
ホストに近接している1セットのホストとして定義され
る。この定義には、いくつかの利点がある。まず最初
に、MeGroupの"近接"特性が、測定および予測のために
良い環境を提供する。これは、独立したプロービングと
比べて、より効率的である。なぜなら、多くのホスト
が、互いに測定情報を共有できるからである。第2に、
以下に詳細に記載する、MeGroupの動的特性により、本
発明によるアーキテクチャが、異種のインターネットに
対してよりスケーラブルになる。

【００４０】各MeGroupが、通常、いくつかのホストを
持ち、その1つが、リーダである。MeGroup内のリーダ
は、各グループのリーダ間の距離を測定する、グループ
間測定を行う責任がある。次いで、この測定結果が、各
グループメンバに配布される。さらに、MeGroupのリー
ダは、そのリーダのMeGroup内のホスト間の距離を測定
する、グループ内測定の責任がある。本明細書の以下に
詳細に記載するように、本発明による一実施形態が、こ
の測定を行うためにマルチキャスト方法を利用する。実
際、この方法は、両測定(グループ間およびグループ内)
に適用して、フルメッシュネットワーク性能情報を効率
的に得ることができる。したがって、好ましくは、ネッ
トワーク全体の中の各ホストが、グループ全体のフルメ
ッシュ性能情報である、グループ内ネットワーク性能を
認識している。実際、これは、各グループ内で頻繁に測
定される。ネットワーク全体の中の各ホストがまた、好
ましくは、グループリーダ間のフルメッシュ性能情報で
ある、グループ間ネットワーク性能も認識している。こ
れは、以上に記載した近接特性に基づく隣接のグループ
間のネットワーク性能を表す。この情報は、一実施形態
においては、グループリーダ間で情報を交換することに
より測定される。

【００４１】図2は、大規模ネットワークl98内の本発明
によるプロービンググループの簡単な例を示す図であ
る。この図2には、6つのプロービンググループ200-2l0
があり、それぞれがグループリーダ212-222を持ち、そ
のグループリーダが、同じグループ内および隣接のグル
ープの中のホスト間のデータ共有を取り扱う。グループ
202内のホスト224が、アクティブプロービングによって
グループ208内のリモートホスト226間のネットワーク性
能を得ると、ホスト224は、同じグループ202内の他のホ
スト214、228、230のすべてに、その情報を配布する。
次いで、グループ202のためのグループリーダ214は、そ
の隣接のグループ200、204内のグループリーダ212、216
のすべてに、この性能情報を配布する。このグループ20
2の別のホスト230が、自分自身230とリモートホスト226
の間のネットワーク状態を知る必要があるかまたは推定
することを望む場合も、どのようなアクティブプロービ
ングも行う必要はない。実際、ホスト230は、元々ホス
ト224によって得られそれから通信された共有情報に基
づいて、ネットワーク性能を予測することができる。

【００４２】しかし、2つのリモートグループ内のホス
ト間のネットワーク性能を判断する第1の実例で、すな
わち、使用できる、このような性能の事前共有情報がな
い場合は、ホストは、性能自体を判断しなければならな
い。一例として、グループ202内のホスト224が、グルー
プ208内の自分自身224とリモートホスト226間のネット
ワーク状態を推定することを望むと想定する。グループ
202内のホストのどれもが、グループ208内の宛先(いず
れかのホスト)に対するネットワーク性能を測定しなか
ったため、同じグループ202内で共有できる履歴情報は
ない。しかし、本発明によるインフラストラクチャは、
共有知識を使用して、アクティブ性能測定をする必要を
未然に防ごうとし、したがって、ネットワークの負荷と
オーバヘッドを最小限に押さえる。

【００４３】この特徴に従って、隣接のグループ200、2
04から存在するネットワーク性能情報を使用して、ネッ
トワーク性能を推定または予測する。図3は、この段に
分かれたデータ共有を示す図である。プロービンググル
ープ202とその隣接のグループ200および204は、場当た
り的に第2の段グループ232を動的に形成する。この第2
の段グループ232では、グループ200と208間およびグル
ープ204と208間の測定したネットワーク状態が、グルー
プ200および204のグループリーダ212、216を介して、グ
ループ202のグループリーダ214に配布される。次いで、
グループ202のリーダ214は、その情報をグループ202内
のホスト224、228、230に配布する。このようにして、
ホスト224は、この第2の段グループ232内のグループか
らの情報を階層的かつ有機的に共有することにより、ネ
ットワーク性能を予測することができる。有意義な情報
がこのようにして得られなかった場合にのみ、ホスト22
4は、ネットワーク性能自体を判断しなければならな
い。

【００４４】次に図4を参照すると、新しいホスト234が
ネットワーク198に入り、その結果、MeGroup改正が生じ
るものとして、MeGroupsの有機的な性質が記載してあ
る。新しいホスト234がネットワークl98の一部になる
と、そのホスト234は、既存の近接のグループに結合す
るかまたは新しいグループを確立することができる。そ
のための判断は、新しいホスト234が、まず最初に、結
合すべき近接のグループを発見するために、既存のグル
ープリーダ212-222のすべてに対して、プロービングを
行うことによってなされる。このような近接のグループ
が存在しない場合は、ホスト234は、新しいプロービン
ググループを確立し、グループリーダとして働く。図4
では、新しいホスト234が、グループ206が近接のグルー
プとしての資格があることを発見する。次いで、このホ
スト234は、再生されたグループ206'として指定され
た、このグループに結合するが、このプロセスについて
は、本明細書の以下にさらに十分に記載する。

【００４５】新しいホスト234がグループ206'に結合し
た後、このグループ206'内に3つのホスト218、234、236
がいて、ホスト218が、グループリーダとして仕える。
しかし、現在グループ206'を構成する、これらのホスト
218、234、236間で、たとえば、ホスト218が、現在のグ
ループメンバに対する物理場所のせいで、グループリー
ダとしてもはや最良の候補ではない場合がある。グルー
プリーダは、このグループ内のすべてのメンバホスト間
にすべての共有情報を配布する必要を有するホストであ
り、したがって、すべてのメンバの中心にいなければな
らない。この中心ということはまた、リーダによって共
有される待ち時間情報が、そのグループメンバのどれか
1つによって見られる待ち時間に最も近似しているた
め、重要である。この場合、以下に記載するグループ再
生ポリシに従って、ホスト236は、グループリーダとし
ての責任を果たす。このグループ206'の再生の後、隣接
のグループ204、208内のホストは、グループリーダの変
更についての通知を受ける。

【００４６】いったんこの情報が配布されると、現在他
のグループ内のメンバとなっているホストのなかに、現
在の自分のメンバーシップがもはや適切ではないことを
発見するものがある。これは、恐らく、再生されたグル
ープ206'の新しいグループリーダ236が、その現在のグ
ループリーダより接近しているからである。このような
状況が図5に示してあるが、ここでは、ホスト238は、ホ
スト236をグループリーダにすることがより適している
ことを発見する。この場合、ホスト238は、グループ204
を去り、再生されたグループ206"として示してあるグル
ープに結合する。このことにより、新しいグループ204'
内にはホスト216および240が残り、2つのメンバのみを
有する。この動的特性により、本発明による測定アーキ
テクチャが、異種のインターネット198に対してよりス
ケーラブルになる。例示したこれらのプロセスは、新し
いホストがネットワークに入り、古いホストがネットワ
ークを去る時、連続して起きる。ネットワークに入った
りまたはそこから去ったりするホストがない場合でさえ
も、これらのプロセスは、ネットワーク状態が変化した
場合にも起こる場合がある。

【００４７】上記の記載は、MeGroupsの有機形成および
改正をグラフ的に示したものである。以下の記載では、
これらの機能の各詳細について検討していく。MeGroup
の形成に関して、このようなグループのそれぞれが"近
接"ホストからなることを繰り返す価値がある。そのた
め、MeGroupの形成するプロセスは、このような近接の
ホストを発見することに関係する。近接の概念について
は、マルチキャストソリューションが実際的でありかつ
効率的である。本発明による一実施形態では、グループ
リーダのすべてが、一意マルチキャストグループMに結
合するが、これは、ホストによって使用されて、測定グ
ループを形成する。上記に記載したように、新しいホス
トがネットワークに来ると、それは、既存のグループに
結合するかまたは新しいグループを確立することができ
る。図6に示すように、いったんこのプロセスが開始す
る242と、新しいホストは、グループを見つけようとす
る課程で、マルチキャストグループMに結合する244。次
いで、新しいホストは、近接のグループを発見するため
に十分に大きいTTL(活動時間(Time to Live))を有する
要求メッセージを送出する246。いったんグループリー
ダが要求メッセージを受け取ると、ただちに応答メッセ
ージで応答する。この応答メッセージには、好ましく
は、新しいホストに有益な、たとえば、グループIDやグ
ループメンバのIPアドレスなどの、MeGroup情報が含ま
れる。新しいホストが、MeGroup、たとえば、MeGroupX
からTの定義済み待ち時間内に応答メッセージを受け取
る248と、マルチキャストグループMを去り250、MeGroup
Xと結合252し始めるが、この詳細については、以下に説
明する。新しいホストが、Tの定義済み待ち時間内にど
の応答メッセージも受け取らない248場合は、このホス
トは、新しいMeGroupを形成し256、グループリーダとし
て働く。次いで、このプロセスが終了する254。

【００４８】図7に示したように、いったん開始する258
と、MeGroupXが新しいホストを有するなどの、グループ
に結合するプロセスが、そのMeGroupXのマルチキャスト
グループに結合する260。ホストは、マルチキャストを
使用して、少なくともそのlPアドレス情報を送る262こ
とにより、グループ全体に自己紹介する。新しいホスト
は、紹介マルチキャストに対する、その応答からMeGrou
pX内の他のメンバホストについて知る264。しかし、新
しいホストが、新しいグループをセットアップすること
を決定すると、図8のプロセスが開始する268。まず最初
に、ホストは、マルチキャストグループMに結合270し、
自分自身をグループリーダとして識別する。次いで、ホ
ストは、この新しいグループのリーダとして働き、新し
いホストが結合してくるのを待つ272。ホストは、測定
データの効率的な転送のために、MeGroup内のすべての
メンバが結合する、MeGroup内でマルチキャストグルー
プを確立する274。次いで、このプロセスが終了する27
6。

【００４９】上述したように、本発明によるインフラス
トラクチャはまた、有機的な自己組織化により、MeGrou
pの改正を提供する。ここで記載した基本グループ形成
アルゴリズムは、むしろ安定したグループを形成する。
言い換えれば、いったんホストがグループに結合する
と、その存続期間中、このグループを去ることはない。
しかし、この特性は、本発明によるシステムの測定およ
び評価ステージに対して効率的ではない。グループのメ
ンバーシップが、ネットワーク上のホストの存続期間に
わたる場合、そのグループがもはやホストの1つに適し
てしないせいで、グループメンバが損害を受ける場合が
ある。つまり、基本グループ結合アルゴリズムによれ
ば、初期のステージでは、新しいホストが、その時の最
良のグループである、結合すべきグループを発見する。
しかし、時が経つにつれて、そのホストに対して、元の
グループより適切な、新しいグループがいくつか生成さ
れる場合がある。以下のセッション、発見的方法では、
ホストジャンピングを本発明に導入して、このような場
合のシステム性能を向上させる。

【００５０】さらに、リーダがもはやそのグループに適
していないせいで、この停滞グループ内のホストが、損
害を受ける場合がある。基本グループ形成アルゴリズム
のグループリーダは、最初にネットワークに入って来た
時に、近接のグループを発見することのできないホスト
である。いったんホストがグループリーダになると、基
本アルゴリズムの下では、その存続期間にわたって、そ
れが変更されい。グループメンバが変化するにつれてデ
ータ配布および共有に役立つための、最良のホストでは
ない場合があるため、これは、最適なソリューションで
はない。たとえば、それが、もはやグループの中心にい
ない場合がある。このことにより、グループ内の待ち時
間の想定が破壊され、グループ間の共有待ち時間情報が
不正確になる。以下のセッション、発見的方法では、リ
ーダの改選を本発明に導入して、このような場合のシス
テム性能を向上させる。

【００５１】さらに、グループがあまりに小さすぎて効
率的にデータを共有できないために、停滞グループ内の
ホストが、損害を受ける場合がある。小さいプロービン
ググループは、分散型性能測定に対して、それ程効率的
ではない。極端な場合が、そのグループ内にメンバがい
ないという、孤立したグループリーダがいる場合であ
る。このような場合は、このようなグループリーダは、
そのネットワーク性能情報をいずれかの他のホストと共
有することによる効率が得られないため、別のグループ
に結合する方が良い。したがって、本発明によるインフ
ラストラクチャの好ましい実施形態では、より良い性能
を達成するために、MeGroupが、その存続期間中、動的
に再生できるようになる。以下のセッション、発見的方
法では、グループの組合せを本発明に導入して、このよ
うな場合のシステム性能を向上させる。

【００５２】本発明による実施形態では、プロービング
グループを再生するために、いくつかの発見的方法を利
用する。一実施形態では、発見的ホストジャンピングを
用いて、上述の問題を回避する。ホストが、そのグルー
プがもはやそれに適していないことを発見すると、それ
は、より適切なグループにジャンプする。上記に記載し
たように、費用関数C(A,B)は、ホストAとB間の距離とし
て定義される。ホストAの現在のグループリーダGが、図
9に示すように、グループiのグループリーダであり、ホ
ストAが、費用関数C(A,G_i)を判断する280ことによって
開始する278。ホストAが、グループxに対する新しいグ
ループリーダG_xを見つけると、それは、費用関数C(A,
G_x)を計算する282。いったんこれらを計算すると、 C(A,G_x)<C(A,G_i) 式3 の場合に、グループi内のホストAが、それ対するより適
切なグループxを発見する284。

【００５３】別の書き方をすると、ホストAは、自分自
身のグループリーダと比べて、他のグループのリーダに
より近い場合に、新しいグループに結合する286。この
ようにして、共有ネットワーク性能情報の使用を可能に
する上記の想定が有効に保たれるか、またはその有効性
が最大限に活用される。いったんホストが他のグループ
に結合すると、このプロセスが終了する288。

【００５４】残念なことに、本発明によるいくつかの実
施形態では、いずれかの特定のMeGroup内のホストが、
自分自身から他のグループリーダまでの距離を知らない
場合がある。このような実施形態では、図10のプロセス
が開始する290。ホストは、自分自身とそれ自身のグル
ープリーダの距離を知っているかまたは計算する292こ
とができる。このプロセスでは、ホストはまた、ステッ
プ294で、そのグループリーダと他のグループリーダ間
の距離についての知識を活用し、その情報を共有する。
この情報で、ホストは、より適切な(ホスト自身よりも
そのグループリーダに接近している)潜在グループを判
断できる。三角不式から、 C(G_i,G_x)≦C(G_i,A)+C(A,G_x) 式4 以下の不式が決定できる。 C(G_i,G_x)-C(G_i,A)≦C(A,G_x) 式5 式3と比較して、以下の条件が満足される場合、 C(G_i,G_x)-C(G_i,A)>C(A,G_x) 式6 つまり、 C(G_i,G_x)>2C(G_i,A) 式7 次いで、ホストは、ステップ296で、そのグループiがも
はやホストAに対する適切なグループではないことを演
繹でき、終了する300前に、グループxに結合する298。
言い換えれば、 C(G_i,G_x)≦2C(G_i,A) 式8 の場合、グループxが、ホストAに対する潜在グループで
あり、これは、現在グループi内にある。

【００５５】C(G_i,G_x)およびC(G_i,A)の性能情報がホス
トAに対して周知であるため、いずれかのホストがその
潜在グループを発見するための、式8の不等号を形成す
ることが可能である。いったんホストがその潜在グルー
プを知ると、各グループリーダにプローブして、式3に
基づいて、このグループが本当により適切なグループか
どうかを検証する。第1の適切なグループを発見した
後、それは、現在のグループを去り、上記に記載した結
合タスクを行う。

【００５６】上記に示したように、グループリーダが、
グループの論理中心であるべきである。しかし、特定の
メンバおよびあるグループの規模が、個々のホストの結
合するおよび去る挙動により、時間が経つにつれて変化
する。そのため、元のグループリーダは、常にそのグル
ープのこの論理中心にいるとは限らない。したがって、
リーダを変更するために、再構築プロセスを使用する必
要がある。このプロセスを十分に理解するためには、ま
ず最初に、論理グループの中心の概念を定義する必要が
ある。自然な考え方として、他のグループメンバに対し
て最小距離を有するホストを発見することである。具体
的には、論理グループの中心は、グループ内の他のホス
トに対する最大距離が最小であるホストである。この判
断には、有利なことに、どの追加のネットワーク測定も
必要としない。

【００５７】理想的な状況においては、グループ内の各
ホストがメンバ間のすべてのグループ内の距離を知って
いるため、グループ内の各ホストは、どのホストがその
グループにとって適切なリーダであるかを知る。しか
し、十分な距離情報を有していないホストがある場合が
ある。予期せずにリーダ改選を試みることを回避するた
めに、一実施形態では、元のリーダが、新しいリーダを
推奨する責任をもつ。推奨するプロセスは、図11に示し
てある。いったん開始する302と、元のリーダが、各ホ
スト間の距離を計算し304、どのホストが、新しいリー
ダとしてグループに推奨すべき、最も適切なホストであ
るかを判断する306。元のリーダは、新しいリーダにな
る気があるかどうかを、その候補ホストに尋ねる308。
そのホストが同意する310と、それが新しいリーダとな
り、選択のプロセスが終了する312。そのホストが同意
しない310場合、かつ現在のリーダよりグループリーダ
としてより適切なホストが1つを超える数いる314場合
は、現在のリーダは、次に最も適切な候補ホストに新し
いリーダになるかを尋ねる308。以下、同じことが続行
される。しかし、これ以上適切なホストがいない314場
合、かつ現在のリーダがリーダに留まることができる31
6場合は、そのホストがリーダに留まったままで、プロ
セスが終了する312。316の場合は、現在のリーダは、リ
ーダに留まっていることができず、MeGroupは、このプ
ロセスを終了する前に、解散する318。この時点で、ホ
ストは、結合すべき新しいMeGroup発見することを試み
るか、または、上記に記載したようにそれ自身で形成す
る。

【００５８】リーダ再構築プロセスは、グループ内のす
べてのホストの性能に影響を及ぼし、そのため、リーダ
を頻繁に変更することは望ましくない。ここに記載した
基準の下に、グループの中心にいるホストが同時にいく
つかいる場合にのみ、リーダを頻繁に変更することがで
きる。本発明による一実施形態では、再構築プロセスを
行うまで、リーダが一定期間その位置に留まることが必
要な場合に、別の基準を使用する。リーダ改選が必要な
別の状況に、リーダが、予期せずにネットワークを去ら
なければならない場合がある。測定グループ内のほとん
どすべてのホストが、ネットワーク状態についてのフル
メッシュ情報を有しているため、一定期間、グループ内
測定情報を受け取らなかった各ホストが、このリーダ再
構築プロセスを発動する。

【００５９】上記で明らかとなったであろうが、MeGrou
pの効率は、各グループのサイズに関係する。小さいグ
ループは、共有測定情報も小さいため、効率的ではな
い。小さいグループのリーダが近接のグループを発見し
た場合は、グループ全体が近接のグループに結合する
と、効率的であろう。このプロセスは、図12に示してあ
る。いったん開始すると320、グループリーダは、その
グループがあまりに小さすぎて効率的でないことを判断
する232。次いで、グループリーダは、結合すべき"近
接"グループを探索する。リーダがこのような近接のグ
ループを発見した234場合、グループA(小さいグループ)
のグループリーダG_Aが、グループB(近接のグループ)の
グループリーダG_Bに、グループAが結合することを受け
入れるかどうかを尋ねる236。G_Bが同意した238場合は、
G_Aは、グループBに結合するよう、グループA内のすべて
のメンバに、メッセージを送る240。元々グループA内に
いた各グループメンバが、グループに結合するタスクを
行い、上記に記載したように、グループBのメンバに自
己紹介する。G_Bが同意しない238場合は、グループAのリ
ーダは、そのグループとのグループの組合せ要求を取り
消し、結合すべき適切な他の近接のグループがあるかど
うか234を監視する。結合すべき他のグループがない場
合は、グループA(小さく非効率的な)が、終了する242前
に、そのメンバを放逐し、グループを解散する244。こ
の結果、放逐されたグループ内の各ホストが、上記に記
載したように、適切なグループに結合する。もちろん、
この方法により、ネットワークに対してより多くのトラ
フィックが生じるが、長期的には、インフラストラクチ
ャに対してより多くの効率をもたらすこととなる。

【００６０】これまでグループ形成/改正プロセスにつ
いて記載してきたが、次に、グループ内およびグループ
間性能測定のための、本発明によるネットワーク性能測
定インフラストラクチャで使用される、アルゴリズムに
注意を向けることとする。ホストメンバ間のグループ内
での測定は、グループ内測定として分類され、グループ
とグループの間の測定は、グループ間測定として分類さ
れる。それらのプロパティに従って、2つの測定分類の
ために異なるアルゴリズムが使用される。

【００６１】グループ内およびグループ間測定の基本要
求事項は、いずれか2つのホスト間のネットワーク性能
を測定することである。これを行うために、以前のシス
テムでは、各ホストが、ユニキャストベースのプロービ
ングを使用して、他のすべてのホストに対する状態を周
期的に測定することを必要とする簡単な方法を使用して
きた。しかし、これらの以前のシステムが、Nホストの
フルメッシュプローブを行うためには、O(N²)プロービ
ングパケットを必要とし、これは、Nがインターネット
の場合のように大きい場合には、大量のトラフィックを
生成する。

【００６２】この問題を解決するために、本発明による
一実施形態が、マルチキャストベースの測定方法を利用
する。マルチキャストは、ユニキャストと比べて、ソー
スからおよびネットワークにはるかに少ないトラフィッ
クを導入することが周知である。マルチキャスティング
は、ビデオオンデマンドやテレビ会議などのグループ通
信で広く使用されてきたし、本発明によるグループ内測
定でも非常に有益である。パケットがさまざまな形で経
路選択されるため、場合によっては、ユニキャストおよ
びマルチキャストベースの距離測定の結果が等しくなら
ないことに留意されたい。それにもかかわらず、本測定
は、大きい問題とはならない。なぜなら、以下に示すよ
うに、本発明によるアーキテクチャで重要なことは、絶
対距離ではなく、異なるホスト対の距離間の関係だから
である。

【００６３】このマルチキャストベースのRTT測定方法
には、2つの段階がある。第1の段階では、1つのホスト
が、パケットをグループにマルチキャストすることによ
り、測定を起動する。パケットを受け取った各ホスト
が、元のホストにフィードバックを送る。したがって、
元のホストは、他のホストのいずれに対してもRTTを計
算することができる。すべてのフィードバックも、マル
チキャストを使用して送られることに留意されたい。こ
れは、この段階の後、各ホストが、マルチキャストの結
果として、いくつかの余分のネットワーク性能情報を他
のホストから受け取るため、有利である。たとえば、4
つのホスト、A、B、C、Dのグループを考えてみる。A
が、マルチキャストプローブを起動すると想定する。他
のホストがこのプローブに応答した後、各ホストが、以
下のテーブルに示すように、パケットを受け取る。

【００６４】

【表１】

【００６５】テーブルでは、A-Xが、ホストAからホスト
Xに送ったプローブパケットを表す。各ホストが、マル
チキャストを使用してプロービングパケットに応答する
ため、Aのプローブに対するホストXの応答が、他のすべ
てのホストによっても受け取られる。したがって、テー
ブル1では、ホストAのプローブに対する応答としてホス
トXからマルチキャストされ、ホストYによって受け取ら
れた応答パケットは、A-X-Yとして表される。テーブル
から、1つのパケットが(ホストAから)送られ、3つのパ
ケットが各ホストによって受け取られることが容易に分
かる。

【００６６】いったんホストAが、他のホスト(パケット
A-B-A、A-C-A、A-D-A)のそれぞれから応答パケットを受
け取ると、ホストAは、これらの他のホストに対するRTT
性能を知る。しかし、他のホストは、各受け取ったパケ
ット間の時間間隔のみを知る(パケットを送る時間が、
プロービングパケットが受け取られた時間と同時である
として扱われることが好ましい)。そのため、各ホスト
は、それに関係する部分的な性能情報のみを知る。した
がって、第2の段階では、各ホストが、他のすべてのホ
ストに対してその情報をマルチキャストし、その結果、
グループのフルメッシュのネットワーク性能情報を計算
できるようになる。このことは、三角法アルゴリズムを
使用して完成される。

【００６７】簡単な例で、このコンセプトを示す。この
例では、(X,Y)は、送信側Xから受信側Yへのワンウェイ
トリップとして定義される。この第2の段階の前に、以
下の情報が、それぞれ、4つのホストで入手可能とな
る。 ホストA: A.1:(A,B)+(B,A) A.2:(A,C)+(C,A) A.3:(A,D)+(D,A) ホストB: B.1:(A,C)+(C,B)-(A,B) B.2:(A,D)+(D,B)-(A,B) ホストC: C.1:(A,B)+(B,C)-(A,C) C.2:(A,D)+(D,C)-(A,C) ホストD: D.1:(A,B)+(B,D)-(A,D) D.2:(A,C)+(C,D)-(A,D) しかし、第2の段階では、この情報が、ホストのすべて
に対してマルチキャストされる。したがって、第2の段
階の後、上述の情報が、すべてのホストで入手可能とな
り、すべてのホスト対のRTTを計算することが容易とな
る。たとえば、B.1とC.1を合計すると、 [(A,C)+(C,B)-(A,B)]+[(A,B)+(B,C)-(A,C)]=(C,B)+(B,C) 式9 を得る。これは、BとC間のRTTである。同様の計算を適
用して、B.2+D.l=RTT(B,D)およびC.2+D.2=RTT(C,D)であ
ることを発見することができる。A.l、A.2、A.3のプロ
ービング結果で、すべてのホスト対のRTTが計算でき
る。このアルゴリズムを、任意の数のホストを有するグ
ループに簡単に拡げることができる。

【００６８】本発明による一実施形態では、ネットワー
ク性能測定データが、好ましくは、同じグループ内の他
のすべてのホストに配布される。一実施形態では、この
性能情報を配布するために使用される測定データ構造に
は、ソースホストIP、宛先ホストIP、宛先グループID、
測定が行われる時間が含まれる。

【００６９】好ましくは、測定データを配布するための
メカニズムが、IPマルチキャストである。このメカニズ
ムにより、各ホストが、他のホストとの調整をする必要
がなく、その測定データを送信することができるように
なる。実際、同じグループ内のホストも、転送するため
に接続される必要がない。本発明によるインフラストラ
クチャでは、この測定データは、エラーフリーである必
要もなく、またホスト間で同期されている必要もない。
このため、IPマルチキャストの保証されていない配信特
性は、問題とならない。この意味で、IPマルチキャスト
が、価値ある発見メカニズムとしても分布メカニズムと
しても役立つ。

【００７０】グループ内のホスト間でこのようなマルチ
キャストグループを形成することが適切でない、または
不可能である場合は、本発明による一実施形態により、
測定データをピアツーピアデータ転送モードで配信す
る。たとえば、スパニングツリー構造または強力な拡散
構造を利用できる。

【００７１】残されている重要な問題点は、共有測定情
報を使用して、ネットワーク性能を、どのように推定し
予測するかである。上記に記載したように、グループ内
の各ホストが、ネットワークについての以下の情報、す
なわち、グループ内のすべてのホストによってプローブ
されたIPアドレス、グループ内のすべてのホストによっ
てプローブされたグループID、行われた各プローブの時
間、プローブの結果を認識するようになる。測定データ
拡張の原理は、近接のホストが同様のネットワーク条件
を有することを想定している。そのため、この原理は、
グループ内で、すべてのホストが、宛先のホストに関係
するプローブデータを有効なデータとして使用して、自
分自身から宛先のホストへのRTTを推定できることを示
す。本発明による原理に従って、この原理の範囲を、さ
らに拡張できる。つまり、本発明によるインフラストラ
クチャでは、宛先のホストに対するRTTに関係するプロ
ーブ結果データが、宛先のホストを含むグループ内のい
ずれのホストに対するRTT、すなわち、グループX内のい
ずれかのホストからグループY内のいずれかのホストま
でのRTT、または単にグループXからグループYまでのRTT
と同様であると想定され、したがって、それとして使用
できる。

【００７２】本発明による評価および予測方法を適用す
る際に、いくつかの簡単な線形方法が良い結果を有する
ように、ネットワークステータスが基本的に安定してい
なければならないことが想定される。このアーキテクチ
ャでは、どのような評価および予測方法も、データに適
用できる。たとえば、平均ベースの方法、メジアンベー
スの方法、自己回帰方法が良い。さらに、ネットワーク
性能データが、計算を行う前に、ホストに"プッシュ"さ
れるため、データ不足の問題はない。すなわち、ホスト
が、測定データについて他のホストに相談する必要がな
い。以前のシステムとは異なり、ネットワーク内のホス
トの数が大きくなればなる程、より多くの測定データを
共有でき、性能予測において、より高い精度および効率
が達成される。

【００７３】本発明による一実施形態では、測定結果が
重み付けされる。一実施形態は、さまざまなタイプのプ
ロービングデータのそれぞれを等しく取り扱うが、この
実施形態は、すべてのデータが必ずしも同等ではないこ
とを認識する。つまり、ホスト自体によるプロービング
によって得られたデータは、他のホストから共有された
プロービングデータと比べて、そのホストに対してより
正確である。これはまた、プロービング結果および予測
結果についても、同様である。そのため、この実施形態
は、異なる測定結果、または測定結果の異なる分類を、
さまざまな形で重み付けする。一実施形態では、ホスト
距離を使用して、測定データに適用すべき重み付けを判
断する。距離が長ければ長い程、重み付けの値が小さく
なる。

【００７４】代替実施形態では、測定データの三角重み
付けを適用する。これを証明するために、ホストAが評
価を行うホストであり、ホストCが宛先であり、ホストB
が、ホストAが常駐するグループのリーダであり、ホス
トDが、ホストCが常駐するグループのリーダであると想
定する。上記の記述に基づいて、ホストBが、先にホス
トDに対して性能測定を行った。ホストBは、(B,D)と(C,
D)の情報により、自分自身とホストC、(B,C)の間のネッ
トワーク性能を推定できる。次に、ホストAについて考
える。ホストAは、ホストC、(B,C)に対する性能情報を
受け取り、自分自身とホストC、(A,C)間の性能を推定し
た、自分自身とホストB、(A,B)間のネットワーク性能に
ついて知る。上記に記載した三角不式から、(A,C)が、
上に(A,B)+W^*(B,C)だけ、下に|(A,B)-W^*(B,C)|だけ限ら
れ、ここで、Wは、重み付け値である。

【００７５】本発明によるシステムはまた、測定ツール
(gMeasure)を提示して、ここで記載したネットワーク性
能測定を行う。インターネットの現在の状態が与えられ
たとすると、本発明によるgMeasureツールの好ましい実
施形態が、インターネット制御メッセージプロトコル(I
CMP)を使用しない。これは、ICMPパケットが、しばし
ば、ろ過されたり、落ちたり、またはそのクライアント
の代りにISPによって返答されたりするためである。ま
た、いくつかのオペレーティングシステム(たとえば、
ソラリス)が、ICMP応答のレートを制限する。その結
果、ICMPの使用により、ネットワークについての間違っ
た性能情報が出る可能性が起きる。したがって、好まし
い実施形態では、gMeasureツールが、TCPパケットを使
用する。gMeasureはまた、UDPパケットを使用して、ア
クティブプロービングを行うことができるが、詳細につ
いては、別の適用形態で分かるであろう。

【００７６】TCPパケットを有する非協力的な環境で性
能を測定した場合、gMeasureは、TCPプロトコルの活用
に頼って、上述したパケット交換のシーケンスを行う。
TCPプロトコルでは、リモートマシンの非活動ポートに
送ったSYNパケット対が、RSTパケット対によって返答さ
れる。正規SYNパケットは、40バイトパケットであり、
ペイロードデータを有さない。gMeasureツールは、大き
いペイロード(たとえば、1460バイト)をそれぞれ送った
SYNパケットにアペンドする。しかし、返答されたRSTパ
ケットは、小さいパケット(40バイト)であり、逆経路上
のボトルネックリンクで待ち行列に入れられている可能
性は低い。ローカルホストで、gMeasureツールは、受け
取ったRSTパケット対の時間分散を、SYNパケット対のリ
モートホスト時間分散に対する概算として使用する。こ
のパケット交換が、リモートホストでの正しいTCPの実
施のみに頼り、ダウンストリームのボトルネック帯域幅
を測定するのに十分であることに留意されたい。あるネ
ットワークリンク(たとえば、モデム回線)で、パケット
は、リンクをトラバースする前に、圧縮される。この影
響により、パケットサイズが変わり、パケット対測定の
精度が損なわれる。したがって、gMeasureツールは、事
前圧縮されたペイロードをSYNパケットにアペンドし
て、パケットサイズに対する圧縮の影響を最小限に押さ
える。

【００７７】gMeasureツールは、そのプロービングトラ
フィックを形作って、測定したネットワーク経路の状態
についての情報を明らかにする。図13に示すように、本
発明によるgMeasureツールは、その途中に大きいパケッ
ト対250_a-d(たとえば、約1500バイト)が置かれている、
小さい40バイトのSYNパケット248_a-dのトレーン246を送
る。リモートエンドホスト252は、RSTパケットの同じサ
イズトレーン254で返答する。gMeasureツールは、トレ
ーン254内のパケット264-274の時間分散を分析し、クロ
ストラフィックリンク、再順序付けリンク、またはマル
チチャネルリンクの存在を判断する、2つの発見的方法
を使用する。

【００７８】第1の発見的方法では、プロービングホス
ト256でgMeasureツールは、RSTパケットのシーケンスナ
ンバを使用して、送ったSYNパケットの順序付けに対し
て、受け取ったパケットの順序付けが、保存されている
かどうかを判断する。パケットが再順序付けされた場合
は、gMeasureツールは、測定を捨て、未知の推定値を返
す。第2の発見的方法では、RSTパケットが再順序付けさ
れていない場合、トレーンの途中にある、2つのRSTパケ
ット268、270の時間分散258は、小さい方の40バイトパ
ケット対264および266と、272および274のいずれかの分
散260および262より大きくなければならない。そうでな
い場合は、良くないパケットが、40バイトパケット対の
間に置かれる可能性が高い。このことは、プロービング
オペレーションのプロービング中のクロストラフィック
の存在を示している。次いで、gMeasureツールは、測定
を捨て、未知の推定値を返す。

【００７９】本発明によるさまざまな実施形態について
の上記の記述は、例示および説明がその目的である。本
発明を、開示されている正確な実施形態に限定したり、
制限したりするものではない。上記の教示から見て、数
々の修正形態や変形形態が可能である。記載した実施形
態は、本発明の原理および実際的な適用形態を最も良く
例示するために選び、記述したものであり、それによ
り、当業者は、本発明を、想定される特定の使用に合っ
たさまざまな実施形態およびさまざまな修正形態で利用
できるようになる。このようなすべての修正形態および
変形形態は、公正に、法的に、公平に権利を有する範囲
内において解釈される場合に、特許請求の範囲で定めら
れるように本発明の範囲に包含される。

【図面の簡単な説明】

【図１】本発明が常駐するコンピュータシステムの例を
一般に示すブロック図である。

【図２】本発明の教示に従って、組織化され動作してい
る、分散型プロービンググループを簡単に示す図であ
る。

【図３】本発明の教示に従って、段に分かれた方式で組
織化され動作している、図2に示した分散型プロービン
ググループを簡単に示す図である。

【図４】本発明の教示に従って、新しいホストを含むた
めに組織化され動作している、図2に示した分散型プロ
ービンググループを簡単に示す図である。

【図５】本発明の教示に従って、新しいホストを含んだ
後、プロービンググループを再生するために組織化され
動作している、図4に示した分散型プロービンググルー
プを簡単に示す図である。

【図６】本発明の教示に従って、既存のプロービンググ
ループを置く方法を簡単に示すフローチャートである。

【図７】本発明の教示に従って、プロービンググループ
に結合する方法を簡単に示すフローチャートである。

【図８】本発明の教示に従って、プロービンググループ
を形成する方法を簡単に示すフローチャートである。

【図９】本発明の教示に従って、ホストが新しいプロー
ビンググループにジャンプする方法を簡単に示すフロー
チャートである。

【図１０】本発明の教示に従って、ホストが新しいプロ
ービンググループにジャンプする代替方法を簡単に示す
フローチャートである。

【図１１】本発明の教示に従って、プロービンググルー
プのための新しいリーダを推奨する方法を簡単に示すフ
ローチャートである。

【図１２】本発明の教示に従って、効率を向上するため
に、小さいプロービンググループをより大きいプロービ
ンググループと併合する方法を簡単に示すフローチャー
トである。

【図１３】本発明の教示に従って、パケットトレーンプ
ロービングアプローチを簡単に示す通信フローチャート
である。

【符号の説明】

100 計算システム環境 110 コンピュータ 120 処理ユニット 121 システムバス 130 システムメモリ 131 読取専用メモリ(ROM) 132 ランダムアクセスメモリ(RAM) 133 基本入出力システム(BIOS) 134、144 オペレーティングシステム 135、145 アプリケーションプログラム 136、146 他のプログラムモジュール 137 プログラムデータ 140 インターフェイス 141 ハードディスクドライブ 147 プログラムデータ 152 取外し可能、不揮発性磁気ディスク 156 取外し可能、不揮発性光学ディスク 155 光学ディスクドライブ 160 ユーザ入力インターフェイス 161 ポインティングデバイス 162 キーボード 170 アダプタ 171 ローカルエリアネットワーク(LAN) 172 モデム 173 ワイドエリアネットワーク(WAN) 180 リモートコンピュータ 181 記憶装置デバイス 185 リモートアプリケーションプログラム 190 ビデオインターフェイス 191 モニタ 195 出力周辺インターフェイス 197 スピーカ 196 プリンタ l98 大規模ネットワーク 200-2l0 プロービンググループ 212-222 グループリーダ 224 ホスト 226 リモートホスト 214、228、230 他のホスト 232 第2の段グループ 206' 再生されたグループ 242 プロセスが開始する 244 マルチキャストグループMに結合する 246 要求メッセージを送出する 248 応答メッセージを受け取る 250 マルチキャストグループMを去る 252 MeGroupXと結合する 248 応答メッセージを受け取らない 256 新しいMeGroupを形成する 254 プロセスが終了する 258 開始する 260 MeGroupXのマルチキャストグループに結合する 264 MeGroupX内の他のメンバホストについて知る 268 プロセスが開始する 270 マルチキャストグループMに結合する 272 新しいホストが結合してくるのを待つ 274 マルチキャストグループを確立する 276 プロセスが終了する 280 費用関数C(A,G_i)を判断する 278 プロセスが開始する 282 費用関数C(A,G_x)を計算する 284 より適切なグループxを発見する 286 新しいグループに結合する 288 プロセスが終了する 290 プロセスが開始する 292 計算する 300 終了する 298 グループxに結合する 304 ホスト間の距離を計算する 306 最も適切なホストであるかを判断する 308 新しいリーダになる気があるかどうかを、その候
補ホストに尋ねる 310 同意する 312 選択のプロセスが終了する 310 ホストが同意しない 314 より適切なホストが1つを超える数いる 308 最も適切な候補ホストに新しいリーダになるかを
尋ねる 314 これ以上適切なホストがいない 316 現在のリーダがリーダに留まることができる 312 プロセスが終了する 318 解散する 320 開始する 232 判断する 234 近接のグループを発見する 236 結合することを受け入れるかどうかを尋ねる 238 同意する 240 メッセージを送る 238 同意しない 242 終了する 244 グループを解散する 250_a-d 大きいパケット対 248_a-d SYNパケット 252 リモートエンドホスト 254 RSTパケットの同じサイズトレーン 264-274 パケット 254 トレーン 256 プロービングホスト 268、270 RSTパケット 258、260、262 時間分散 264および266、272および274 バイトパケット対

───────────────────────────────────────────────────── フロントページの続き (72)発明者 ツァン キアン 中華人民共和国 430070 フベイ ウハン フジアポ ロード ザ コール オフィ ス オブ フベイ プロビンス（番地な し) (72)発明者 シュ ウェンウ アメリカ合衆国 07920 ニュージャージ ー州 バスキン リッジ クィーンベリー ウェイ 11 (72)発明者 リュ ジャンチュアン 中華人民共和国 香港 クーロン ザ ホ ンコン ユニバーシティ オブ サイエン ス アンド テクノロジー 512ディー タワー ビー (72)発明者 ツァン シンヤン 中華人民共和国 ジャンス ナンジン リ ュ ヘ フェン ファン ナン ル 17 Ｆターム(参考） 5K030 JA10 LD01 MB03 MB06 MC02

Claims (50)

【特許請求の範囲】
1. 【請求項１】 ネットワークにわたって分散されている
   ある数のホストを有する大規模ネットワークのためのネ
   ットワーク性能測定インフラストラクチャであって、近
   接の複数のホストから自己組織化された複数の測定グル
   ープを有し、各測定グループがグループリーダを含み、
   各グループリーダが第1のマルチキャストグループに結
   合して、測定グループ間のグループ間ネットワーク性能
   情報を共有し、各グループリーダがその測定グループ内
   の第2のマルチキャストグループをさらに形成して、そ
   の測定グループ内のグループ内ネットワーク性能情報を
   共有することを特徴とするネットワーク性能測定インフ
   ラストラクチャ。
2. 【請求項２】 各前記ホストが、そのそれぞれの測定グ
   ループ内で、リモートホストに対して有するネットワー
   ク性能情報を共有し、各前記測定グループ内のホスト
   が、アクティブに前記ネットワーク性能を測定すること
   なく、前記そのそれぞれの測定グループ内で共有される
   前記ネットワーク性能情報を利用して、前記リモートホ
   ストに対するネットワーク性能を推定することを特徴と
   する請求項1に記載のインフラストラクチャ。
3. 【請求項３】 前記測定グループ内の1つのホストが、
   パケットを第2のマルチキャストグループにマルチキャ
   ストすることによりグループ内性能測定を起動し、前記
   グループ内の各ホストが、前記パケットに対する応答を
   前記第2のマルチキャストグループにマルチキャストす
   ることによって応答し、その後、前記1つのホストが、
   その測定グループ内の自分自身と他のすべてのホスト間
   のラウンドトリップ時間(RTT)性能を測定することを特
   徴とする請求項1に記載のインフラストラクチャ。
4. 【請求項４】 前記測定グループ内のホストが、前記第
   2のマルチキャストグループからの、前記1つのホストか
   ら受け取ったパケットおよび各ホストから受け取った前
   記応答に関係する情報を、さらにマルチキャストし、前
   記ホストが、その後、それらの測定グループ内のいずれ
   かの2つのホスト間の前記RTT性能を計算することを特徴
   とする請求項3に記載のインフラストラクチャ。
5. 【請求項５】 各前記グループリーダが、リモートホス
   トに対して有するネットワーク性能情報を、近接の測定
   グループのグループリーダと共有し、各測定グループ内
   のホストが、近接の測定グループから共有される前記ネ
   ットワーク性能情報を利用して、このようなネットワー
   ク性能情報がそのホストの測定グループ内の別のホスト
   から入手可能でない場合に、前記ネットワーク性能をア
   クティブに測定することなく、前記リモートホストに対
   するネットワーク性能を推定することを特徴とする請求
   項1に記載のインフラストラクチャ。
6. 【請求項６】 前記このようなネットワーク性能情報が
   前記測定グループ内からおよび前記近接の測定グループ
   から共有されない場合に、前記ホストが、リモートホス
   トに対する前記ネットワーク性能をアクティブに測定す
   ることを特徴とする請求項5に記載のインフラストラク
   チャ。
7. 【請求項７】 前記ホストが、パケットトレーンをリモ
   ートホストに送り、それに対する前記ネットワーク性能
   を判断し、前記パケットトレーンが、2つの小さいSYNパ
   ケット、それに続き2つの大きいSYNパケット、それに続
   き2つの小さいSYNパケットを有することを特徴とする請
   求項1に記載のインフラストラクチャ。
8. 【請求項８】 前記リモートホストからRSTパケットの
   応答パケットトレーンを受け取り、前記ホストが前記RS
   Tパケットが前記SYNパケットに対して再順序付けされて
   いる場合に、前記ホストが、前記応答パケットトレーン
   を捨てることを特徴とする請求項7に記載のインフラス
   トラクチャ。
9. 【請求項９】 前記ホストが、前記リモートホストから
   6つのRSTパケットの応答パケットトレーンを受け取り、
   第3と第4のRSTパケット間の時間分散が、第1と第2、第5
   と第6のパケット間の時間分散より短い場合に、前記ホ
   ストが、前記応答パケットトレーンを捨てることを特徴
   とする請求項7に記載のインフラストラクチャ。
10. 【請求項１０】 前記ホストが、自分自身とネットワー
    ク性能情報が共有される別のホストの間の距離に基づい
    て、ネットワーク性能情報を逆に重み付けすることを特
    徴とする請求項1に記載のインフラストラクチャ。
11. 【請求項１１】 前記ホストがネットワークに入ったり
    去ったりする時、またはネットワーク状態が変化する時
    に、前記測定グループが、動的に再生することを特徴と
    する請求項1に記載のインフラストラクチャ。
12. 【請求項１２】 動的に再生された前記測定グループの
    グループリーダが、前記動的に再生された測定グループ
    のほぼ論理中心にいるホストであることを特徴とする請
    求項11に記載のインフラストラクチャ。
13. 【請求項１３】 前記動的に再生された測定グループの
    前記グループリーダがその現在のグループリーダより前
    記ホストに接近している場合に、測定グループ内のホス
    トが、その測定グループを去り、前記動的に再生された
    測定グループに結合することを特徴とする請求項12に記
    載のインフラストラクチャ。
14. 【請求項１４】 前記動的に再生された測定グループの
    前の、前記測定グループの前記グループリーダが、動的
    再生後に、前記測定グループ内のすべてのホスト間の距
    離を計算し、前記グループリーダが、その後、動的再生
    後に前記測定グループの論理中心にいるホストに、グル
    ープリーダの役割を引き受けるよう要求することを特徴
    とする請求項11に記載のインフラストラクチャ。
15. 【請求項１５】 小さい前記測定グループが、近接の測
    定グループと併合して、共有ネットワーク性能情報を介
    してネットワーク性能を判断する効率を増加させること
    を特徴とする請求項1に記載のインフラストラクチャ。
16. 【請求項１６】 ネットワークにわたって分散されてい
    る複数のホストを有する大規模ネットワークのためのネ
    ットワーク性能を判断する方法であって、 近接の複数のホストから少なくとも1つの測定グループ
    を形成するステップと、 前記少なくとも1つの測定グループ内のそれぞれの内
    で、1つのホストが、その関連の測定グループ内の他の
    ホストにパケットをマルチキャストして、グループ内ネ
    ットワーク性能を判断するステップと、 前記測定グループ内の他のホストが、その測定グループ
    内のホストに前記パケットに対する応答をマルチキャス
    トするステップと、 前記1つのホストが、その測定グループ内の自分自身と
    他のすべてのホスト間のラウンドトリップ時間(RTT)性
    能を計算するステップとを含むことを特徴とする方法。
17. 【請求項１７】 前記少なくとも1つの測定グループ内
    の他のホストが、前記1つのホストから受け取ったパケ
    ットに関係し、かつ前記他のホストのそれぞれから受け
    取った応答に関係する情報をマルチキャストするステッ
    プと、 前記他のホストのそれぞれが、それらの測定グループ内
    のいずれかの2つのホスト間のRTT性能を計算するステッ
    プとをさらに含むことを特徴とする請求項16に記載の方
    法。
18. 【請求項１８】 前記少なくとも1つの測定グループを
    形成するステップが、 第1のマルチキャストグループに結合するステップと、 要求メッセージを前記第1のマルチキャストグループに
    送るステップとを含み、前記要求メッセージが長い有効
    期間(TTL)を有し、 さらに、所定の待ち時間内に応答が受け取られない場合
    に、新しい測定グループを形成するステップと、 前記新しい測定グループのリーダの役割を引き受けるス
    テップと、 グループ内通信のための第2のマルチキャストグループ
    を形成するステップとを含むことを特徴とする請求項16
    に記載の方法。
19. 【請求項１９】 新しいホストからマルチキャスト要求
    メッセージを受け取るステップと、 前記要求メッセージに応答するステップと、 前記第2のマルチキャストグループ上の新しいホストか
    らマルチキャストされた新しいホスト情報を受け取るス
    テップと、 前記第2のマルチキャストグループ上の新しいホストに
    応答するステップとをさらに含むことを特徴とする請求
    項18に記載の方法。
20. 【請求項２０】 前記グループリーダが、前記測定グル
    ープ内の各ホスト間の距離を計算するステップと、 前記測定グループ内のどのホストが、前記測定グループ
    の論理中心であるかを判断するステップと、 前記測定グループの論理中心であるホストがグループリ
    ーダの役割を引き受けるよう要求するステップとをさら
    に含むことを特徴とする請求項19に記載の方法。
21. 【請求項２１】 測定グループ内の1つのホストが、自
    分自身とリモートホスト間のネットワーク性能を判断す
    るステップと、 前記測定グループ内の他のホストが使用するために、そ
    の関連の測定グループ内の前記他のホストに対するネッ
    トワーク性能をマルチキャストして、前記リモートホス
    トとアクティブに通信することなく、前記リモートホス
    トに対するネットワーク性能を推定するステップとをさ
    らに含むことを特徴とする請求項16に記載の方法。
22. 【請求項２２】 近接の測定グループが使用するため
    に、前記近接の測定グループのグループリーダに前記リ
    モートホストに対するネットワーク性能をマルチキャス
    トして、前記リモートホストとアクティブに通信するこ
    となく、前記リモートホストに対するネットワーク性能
    を推定するステップをさらに含むことを特徴とする請求
    項21に記載の方法。
23. 【請求項２３】 前記測定グループ内の1つのホスト
    が、自分自身とリモートホスト間のネットワーク性能を
    判断するステップが、 SYNパケットのパケットトレーンを前記リモートホスト
    に送信するステップと、 前記リモートホストからのRSTパケットのリターンパケ
    ットトレーンを分析するステップとを含むことを特徴と
    する請求項21に記載の方法。
24. 【請求項２４】 前記送信するステップが、2つの小さ
    いSYNパケット、それに続き2つの大きいSYNパケット、
    それに続き2つの小さいSYNパケットを含む6つのSYNパケ
    ットのパケットトレーンを送信するステップを含むこと
    を特徴とする請求項23に記載の方法。
25. 【請求項２５】 前記分析するステップが、前記RSTパ
    ケットの順序付けを分析するステップと、前記RSTパケ
    ットが前記SYNパケットに対して再順序付けされている
    場合に、前記RSTパケットトレーンを捨てるステップと
    を含むことを特徴とする請求項23に記載の方法。
26. 【請求項２６】 前記分析するステップが、RSTパケッ
    ト間の時間分散を分析するステップと、第1と第2のRST
    パケット、および第5と第6のRSTパケット間の少なくと
    も1つの時間分散が、第3と第4のRSTパケット間の時間分
    散以上である場合に、前記RSTパケットトレーンを捨て
    るステップとを含むことを特徴とする請求項23に記載の
    方法。
27. 【請求項２７】 前記少なくとも1つの測定グループを
    形成するステップが、小さい測定グループを近接の測定
    グループに併合するステップを含むことを特徴とする請
    求項16に記載の方法。
28. 【請求項２８】 前記少なくとも1つの測定グループを
    形成するステップが、小さい測定グループを解散し、そ
    の結果、その中の前記ホストが近接の測定グループに結
    合できるようになるステップを含むことを特徴とする請
    求項16に記載の方法。
29. 【請求項２９】 第2の複数の測定グループに組織化さ
    れた第1の複数のホストを有する大規模ネットワークに
    おいて、各前記測定グループが、前記第2の複数の測定
    グループのグループリーダ間のグループ間通信のための
    第1のマルチキャストグループに、および前記グループ
    リーダの測定グループ内のホスト間のグループ内通信の
    ための第2のマルチキャストグループに属するグループ
    リーダを有し、結合すべき近接の測定グループを探索す
    る方法が、 前記第1のマルチキャストグループに結合するステップ
    と、 長い有効期間を有する要求メッセージをマルチキャスト
    するステップと、 応答が、所定の待ち時間内に近接の測定グループから受
    け取られた場合に、 前記第1のマルチキャストグループを去るステップと、 前記近接の測定グループに結合するステップとを含むこ
    とを特徴とする方法。
30. 【請求項３０】 前記近接の測定グループに結合するス
    テップが、 前記近接の測定グループの前記第2のマルチキャストグ
    ループに結合するステップと、 前記第2のマルチキャストグループ上のホスト情報をマ
    ルチキャストするステップと、 前記第2のマルチキャストグループ上の近接の測定グル
    ープ内の他のホストから応答を受け取るステップとを含
    むことを特徴とする請求項29に記載の方法。
31. 【請求項３１】 応答が、前記所定の待ち時間で近接の
    測定グループから受け取られない場合に、新しい測定グ
    ループを形成するステップと、 前記新しい測定グループのグループリーダの役割を引き
    受けるステップとをさらに含むことを特徴とする請求項
    29に記載の方法。
32. 【請求項３２】 前記所定の待ち時間内に第1の近接の
    測定グループから第1の応答を受け取るステップと、 第2の近接の測定グループから第2の応答を受け取るステ
    ップと、 前記第1と前記第2の近接の測定グループの接近している
    方を判断するステップと、 前記第1と前記第2の近接の測定グループの前記接近して
    いる方に結合するステップとをさらに含むことを特徴と
    する請求項29に記載の方法。
33. 【請求項３３】 第1のグループリーダを有する少なく
    とも第1の測定グループと第2の測定グループとを有する
    大規模ネットワークにおいて、前記第1の測定グループ
    内のホストのグループメンバーシップを変更する方法で
    あって、 前記第2の測定グループの新しいグループリーダからメ
    ッセージを受け取るステップと、 前記新しいグループリーダが前記第1のグループリーダ
    より近い場合に、前記第2の測定グループに結合するス
    テップとを含むことを特徴とする方法。
34. 【請求項３４】 前記新しいグループリーダが前記第1
    のグループリーダより近い場合に、前記第2の測定グル
    ープに結合するステップが、 前記第1の測定グループの前記第1のグループリーダに対
    する第1の距離推定値を計算するステップと、 前記第2の測定グループの前記新しいグループリーダに
    対する第2の距離推定値を計算するステップと、 前記第2の測定グループの前記新しいグループリーダに
    対する前記第2の距離推定が、前記第1の測定グループの
    前記第1のグループリーダに対する前記第1の距離推定値
    未満である場合に、前記第2の測定グループに結合する
    ステップとを含むことを特徴とする請求項33に記載の方
    法。
35. 【請求項３５】 前記新しいグループリーダが前記第1
    のグループリーダより近い場合に、前記第2の測定グル
    ープに結合するステップが、 前記第1の測定グループの前記第1のグループリーダに対
    する第1の距離推定値を計算するステップと、 前記第1のグループリーダと前記新しいグループリーダ
    の間の第2の距離推定値を受け取るステップと、 前記第1のグループリーダと前記新しいグループリーダ
    の間の前記第2の距離推定値が、前記第1の測定グループ
    の前記第1のグループリーダに対する前記第1の距離推定
    値の2倍以下である場合に、前記第2の測定グループに結
    合するステップとを含むことを特徴とする請求項33に記
    載の方法。
36. 【請求項３６】 ネットワークにわたって分散されてい
    る複数のホストを有する大規模ネットワークのためのネ
    ットワーク性能を判断する方法であって、 近接の複数のホストから少なくとも1つの測定グループ
    を形成するステップと、 前記測定グループ内の1つのホストが、自分自身とリモ
    ートホスト間のネットワーク性能を判断するステップ
    と、 前記測定グループ内の他のホストが使用するために、そ
    の関連の測定グループ内の前記他のホストに対する前記
    ネットワーク性能をマルチキャストして、前記リモート
    ホストとアクティブに通信することなく、前記リモート
    ホストに対する前記ネットワーク性能を推定するステッ
    プとを含むことを特徴とする方法。
37. 【請求項３７】 前記近接の測定グループが使用するた
    めに、前記近接の測定グループのグループリーダに前記
    リモートホストに対する前記ネットワーク性能をマルチ
    キャストして、前記リモートホストとアクティブに通信
    することなく、前記リモートホストに対する前記ネット
    ワーク性能を推定するステップをさらに含むことを特徴
    とする請求項36に記載の方法。
38. 【請求項３８】 前記測定グループ内の1つのホスト
    が、自分自身とリモートホスト間のネットワーク性能を
    判断するステップが、 SYNパケットのパケットトレーンを前記リモートホスト
    に送信するステップと、 前記リモートホストからのRSTパケットのリターンパケ
    ットトレーンを分析するステップとを含むことを特徴と
    する請求項36に記載の方法。
39. 【請求項３９】 前記送信するステップが、2つの小さ
    いSYNパケット、それに続き2つの大きいSYNパケット、
    それに続き2つの小さいSYNパケットを含む6つのSYNパケ
    ットのパケットトレーンを送信するステップを含むこと
    を特徴とする請求項38に記載の方法。
40. 【請求項４０】 前記分析するステップが、前記RSTパ
    ケットの順序付けを分析するステップと、前記RSTパケ
    ットが前記SYNパケットに対して再順序付けされている
    場合に、前記RSTパケットトレーンを捨てるステップと
    を含むことを特徴とする請求項38に記載の方法。
41. 【請求項４１】 前記分析するステップが、RSTパケッ
    ト間の時間分散を分析するステップと、第1と第2のRST
    パケット、および第5と第6のRSTパケット間の少なくと
    も1つの時間分散が、第3と第4のRSTパケット間の時間分
    散以上である場合に、前記RSTパケットトレーンを捨て
    るステップとを含むことを特徴とする請求項38に記載の
    方法。
42. 【請求項４２】 そこにわたって分散される第1の複数
    のホストを有する大規模ネットワークにおいて、その少
    なくともいくつかが、互いに近接し、測定グループに組
    織化され、前記測定グループ内の前記ホストがネットワ
    ーク性能情報を共有し、前記測定グループ内のホスト
    が、前記測定グループからリモートのホストに対するネ
    ットワーク性能を判断する方法であって、 前記リモートホストに対する前記ネットワーク性能が、
    以前に前記ホストによってアクティブに計算されている
    かどうかを判断するステップと、 前記リモートホストに対する前記ネットワーク性能が、
    前記測定グループ内の別のホストによってアクティブに
    計算され、前記測定グループ内で共有されているかどう
    かを判断するステップと、 以前に前記ホストによってアクティブに計算され、前記
    測定グループと別のホストから共有されている入手可能
    なネットワーク性能情報に基づいて、前記リモートホス
    トに対する前記ネットワーク性能を推定するステップと
    を含むことを特徴とする方法。
43. 【請求項４３】 前記推定するステップが、前記入手可
    能なネットワーク性能情報を重み付けするステップを含
    むことを特徴とする請求項42に記載の方法。
44. 【請求項４４】 前記重み付けするステップが、前記ネ
    ットワーク性能を共有した前記測定グループ内のホスト
    までの距離に基づいて重み付けするステップを含むこと
    を特徴とする請求項43に記載の方法。
45. 【請求項４５】 前記重み付けするステップが、前記ネ
    ットワーク性能が判断される時間に基づいて重み付けす
    るステップを含むことを特徴とする請求項43に記載の方
    法。
46. 【請求項４６】 第2の測定グループが、前記測定グル
    ープの近接にあり、以前に前記ホストによってアクティ
    ブに計算された入手可能なネットワーク性能情報がな
    く、前記測定グループと別のホストから共有される入手
    可能なネットワーク性能情報がない場合に、前記リモー
    トホストに対する前記ネットワーク性能が、前記近接の
    測定グループ内の別のホストによってアクティブに計算
    され、前記測定グループと共有されているかどうかを判
    断するステップをさらに含み、前記推定するステップ
    が、前記近接の測定グループから共有される入手可能な
    ネットワーク性能情報に基づいて、前記リモートホスト
    に対する前記ネットワーク性能を推定するステップを含
    むことを特徴とする請求項42に記載の方法。
47. 【請求項４７】 前記近接の測定グループから共有され
    る入手可能なネットワーク性能情報がなく、 前記リモートホストにSYNパケットのパケットトレーン
    を送信するステップと、 前記リモートホストからのRSTパケットのリターンパケ
    ットトレーンを分析して、前記リモートホストに対する
    前記ネットワーク性能を判断するステップと、 前記ネットワーク性能を前記測定グループ内の前記他の
    ホストと共有するステップとをさらに含むことを特徴と
    する請求項46に記載の方法。
48. 【請求項４８】 前記送信するステップが、2つの小さ
    いSYNパケット、それに続き2つの大きいSYNパケット、
    それに続き2つの小さいSYNパケットを有する6つのSYNパ
    ケットのパケットトレーンを送信するステップを含むこ
    とを特徴とする請求項47に記載の方法。
49. 【請求項４９】 前記分析するステップが、前記RSTパ
    ケットの順序付けを分析するステップと、前記RSTパケ
    ットが前記SYNパケットに対して再順序付けされていた
    場合は、前記RSTパケットトレーンを捨てるステップと
    を含むことを特徴とする請求項47に記載の方法。
50. 【請求項５０】 前記分析するステップが、RSTパケッ
    ト間の時間分散を分析するステップと、第1と第2のRST
    パケット、および第5と第6のRSTパケット間の前記時間
    分散の少なくとも1つが、第3と第4のRSTパケット間の時
    間分散以上である場合に、前記RSTパケットトレーンを
    捨てるステップとを含むことを特徴とする請求項47に記
    載の方法。