(57)【特許請求の範囲】
【請求項１】
ネットワーク上のエンティティ間のパケット通信を通信デバイスを通して実行する方法であって、
前記方法は、
１組のパケットを送信側のエンティティから受信側のエンティティに送信するステップであって、該１組のパケットは、連続して送信される２つのパケットを含み、該２つのパケットは同じサイズであり、該１組のパケットは、送信側のエンティティと受信側のエンティティの間のバンド幅を測定するための複数のバンド幅測定パケットであり、該送信するステップはＯＳＩ参照モデルのアプリケーション層において実施される、ステップと、
前記１組のパケットを送信した後に続けて少なくとも１つのプッシュパケットを送信して、該１組のパケットにおけるパケット間の伝送遅延を避けるステップであって、該プッシュパケットのサイズは、前記通信デバイスに実装されているＮａｇｌｅアルゴリズムによって規定されるセグメントサイズと同じサイズ、またはより大きいサイズになるように前記送信側のエンティティにより選択され、前記通信デバイスによる該１組のパケットの伝送が前記ネットワーク上の前記通信デバイスによって行われるパケットバッファリングにより生じる伝送遅延を回避するように構成される、ステップと
を有することを特徴とする方法。
【請求項２】
前記通信デバイスはプロキシサーバであることを特徴とする請求項１に記載の方法。
【請求項３】
前記ネットワークはＴＣＰであることを特徴とする請求項１に記載の方法。
【請求項４】
プログラムモジュールであって、
コンピュータによって実行されたとき、請求項１に記載の方法をＯＳＩ参照モデルに準拠するアプリケーション層でコンピュータに実行させる、コンピュータ読み取り可能な記憶媒体に格納されているコンピュータ実行可能命令を含むことを特徴とするプログラムモジュール。
【請求項５】
前記プッシュパケットは前記送信側のエンティティから送信されることを特徴とする請求項１に記載の方法。
【請求項６】
前記伝送遅延を生じるパケットバッファリングは、１つまたは複数のパケットをパケットバッファに格納するバッファリングアクションであって、当該パケットバッファリングにより伝送遅延が生じるバッファリングアクションであることを特徴とする請求項１に記載の方法。
【請求項７】
ネットワーク上のエンティティ間のバンド幅測定を通信デバイスを通して実行するシステムであって、
送信側のエンティティと受信側のエンティティの間のバンド幅を測定するための１組のバンド幅測定パケットを送信側のエンティティから受信側のエンティティに送信する手段であって、該１組のバンド幅測定パケットは連続して送信される２つのパケットを含み、該２つのパケットは同じサイズであり、該送信することはＯＳＩ参照モデルのアプリケーション層において実施される、手段と、
前記１組のバンド幅測定パケットを送信した後に続けて少なくとも１つのプッシュパケットを送信して、該１組のパケットにおけるパケット間の伝送遅延を避ける手段であって、該プッシュパケットのサイズは、プロキシデバイスに実装されているＮａｇｌｅアルゴリズムによって規定されるセグメントサイズと同じサイズ、またはより大きいサイズになるように前記送信側のエンティティにより選択され、該プロキシデバイスによる該１組のパケットの伝送が前記ネットワーク上の前記プロキシデバイスによって行われるパケットバッファリングにより生じる伝送遅延を回避するように構成される、手段と
を有することを特徴とするシステム。
【請求項８】
前記１組のパケットに関連する測定に基づいたバンド幅計算結果を受信する手段をさらに備えたことを特徴とする請求項７に記載のシステム。
【請求項９】
前記プッシュパケットは前記送信側のエンティティから送信されることを特徴とする請求項７に記載のシステム。
【請求項１０】
前記プロキシデバイスは前記送信側のエンティティおよび前記受信側のエンティティ以外のデバイスを含むことを特徴とする請求項７に記載のシステム。
【請求項１１】
前記伝送遅延を生じるパケットバッファリングは、１つまたは複数のパケットをパケットバッファに格納するバッファリングアクションであって、当該パケットバッファリングにより伝送遅延が生じるバッファリングアクションであることを特徴とする請求項７に記載のシステム。
【請求項１２】
コンピュータによって実行される時、ネットワーク上のエンティティ間のパケット通信を通信デバイスを通して実行する方法をコンピュータに実行させるコンピュータ実行可能命令を格納したコンピュータ読み取り可能な記憶媒体であって、
前記方法は、
１組のパケットを送信側のエンティティから受信側のエンティティに送信するステップであって、該１組のパケットは、連続して送信される２つのパケットを含み、該２つのパケットは同じサイズであり、該１組のパケットは、送信側のエンティティと受信側のエンティティの間のバンド幅を測定するための複数のバンド幅測定パケットであり、該送信するステップはＯＳＩ参照モデルのアプリケーション層において実施される、ステップと、
前記１組のパケットを送信した後に続けて少なくとも１つのプッシュパケットを送信して、該１組のパケットにおけるパケット間の伝送遅延を避けるステップであって、該プッシュパケットのサイズは、前記通信デバイスに実装されているＮａｇｌｅアルゴリズムによって規定されるセグメントサイズと同じサイズ、またはより大きいサイズになるように前記送信側のエンティティにより選択され、前記通信デバイスによる該１組のパケットの伝送が前記ネットワーク上の前記通信デバイスによって行われるパケットバッファリングにより生じる伝送遅延を回避するように構成される、ステップと
を有することを特徴とするコンピュータ読み取り可能な記憶媒体。
【請求項１３】
プロセッサを有する装置であって、
１組のパケットを送信側のエンティティから受信側のエンティティに通信デバイスを通して送信することであって、該１組のパケットは、連続して送信される２つのパケットを含み、該２つのパケットは同じサイズであり、該１組のパケットは、送信側のエンティティと受信側のエンティティの間のバンド幅を測定するための複数のバンド幅測定パケットであり、該送信することはＯＳＩ参照モデルのアプリケーション層において実施される、ことと、
前記１組のパケットを送信した後に続けて少なくとも１つのプッシュパケットを送信して、該１組のパケットにおけるパケット間の伝送遅延を避けることであって、該プッシュパケットのサイズは、前記通信デバイスに実装されているＮａｇｌｅアルゴリズムによって規定されるセグメントサイズと同じサイズ、またはより大きいサイズになるように前記送信側のエンティティにより選択され、前記通信デバイスによる該１組のパケットの伝送がネットワーク上の前記通信デバイスによって行われるパケットバッファリングにより生じる伝送遅延を回避するように構成される、ことと
をプロセッサ上で実行可能な伝送遅延回避器を有することを特徴とする装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ＴＣＰネットワーク環境上のエンティティ間のコネクションのための最大バンド幅を動的に検出することに関する。具体的には、本発明は、あるパケット集合の伝送を効果的に遅延させる可能性のある、ネットワーク環境のフロー制御機能に対する対応策に関する。
【０００２】
【従来の技術】
インターネット  （ｔｈｅ  Ｉｎｔｅｒｎｅｔ）  の成熟に伴って、インターネット上で利用可能なコンテキストの特性が変化している。現在では、サウンドとビデオコンテンツが従来のテキストコンテンツに組み込まれている。しかし、インターネット上のこの新コンテンツでは、数年前までは普通に利用可能であったものよりも、コネクション速度（つまり、バンド幅）の高速化が要求されている。
【０００３】
図１は、代表的なインターネットの構成の例を示す。この構成には、サーバ（メディアサーバ２０など）が含まれ、このサーバはインターネット３０に結合されている。サーバには、１つまたは２つ以上の物理的サーバコンピュータ２２が置かれているのが代表的であり、サーバコンピュータは１つまたは２つ以上の物理的ストレージデバイスおよび／またはデータベース２４を装備している。インターネット伝送の反対側には、クライント９０、９２が存在し、これは多数の利用可能なインターネットサービスプロバイダ  （Ｉｎｔｅｒｎｅｔ  Ｓｅｒｖｉｃｅ  Ｐｒｏｖｉｄｅｒ  （ＩＳＰ））  ８０の１つを通して接続されている。ここでは、サーバはデータを送信するネットワークエンティティであり、クライアントはデータを受信するネットワークエンティティになっている。
【０００４】
クラウド（集団、ｃｌｏｕｄ）３０はインターネットと明記されているが、理解されているように、このクラウドは、図示のものだけを含んでいるインターネット部分を表している。このクラウドの内側には、ルータ、伝送回線、コネクション、および他の通信デバイスが置かれていて、クライアントとサーバの間でデータがほとんど正常に伝送されるようにしている。例示のインターネットクラウド３０の内側には、ルータ３２〜４４、２つのサテライトディッシュ  （ｓａｔｅｌｌｉｔｅ  ｄｉｓｈ）  ４６、５０およびサテライト４８が存在している。これらのデバイス間のリンクは取り得る経路  （ｐａｔｈ）  を表し、データパケットは、その経路を通ってサーバとクライアント間を伝送されるようになっている。
【０００５】
一般的に、ネットワーク（インターネットなど）上の通信デバイスは、ネットワークを利用した２エンティティ間のコミュニケーションを容易にするデバイスになっており、そこには、２つのエンティティが含まれている。そのようなエンティティの例としては、サーバ２０とクライント９０がある。
【０００６】
ＯＳＩモデルの層
開放型システム間相互接続  （Ｏｐｅｎ  Ｓｙｓｔｅｍ  Ｉｎｔｅｒｃｏｎｎｅｃｔｉｏｎ  （ＯＳＩ））  モデルは、世界的規模のコミュニケーションのためのＩＳＯ標準であり、そこでは、プロトコルを７層で実装するためのネットワーキングフレームワークが定義されている。コントロールは、あるステーション（局）に置かれたアプリケーション層から始まって、ある層から次の層へ渡され、最下層に移った後、チャネルを通って次のステーションに渡され、階層の上方に向かって戻るようになっている。当業者ならば、このＯＳＩモデルは周知である。
【０００７】
ＯＳＩモデルに含まれる機能の大部分は、２または３つのＯＳＩ層が１つに統合されていることがあっても、すべての通信システムに存在している。これらの層は「レベル」とも呼ばれている。
【０００８】
一般的に、物理層はハードウェアで実現されている。そのようなハードウェアとしては、ネットワークカード、モデム、またはある種の他の通信デバイスがある。代表例として、トランスポート層は、オペレーティングシステム  （ｏｐｅｒａｔｉｎｇ  ｓｙｓｔｅｍ    ＯＳ）  のカーネルで実現されている。
【０００９】
スタックの最上層はアプリケーション層であり、そこにはアプリケーションが置かれている。ここには、Ｗｅｂブラウザやメディアプレイヤ、ｅメールプログラムのように、コンピュータの外側に置かれたエンティティと通信するアプリケーションが置かれている。アプリケーション層では、インターネットのようなネットワーク上のエンティティ間のコミュニケーション詳細に対する制御権は、最小になっている。
【００１０】
バンド幅
バンド幅  （ｂａｎｄｗｉｄｔｈ）  とは、一定時間内に伝送できるデータ量のことである。例えば、図１に示すメディアサーバ２０とメディアクライアント９０間のバンド幅は、ある時間単位（例えば、１秒）内に両者間で伝送できるデータ量（例えば、１０００ビット）で計算される。もっと具体的に説明すると、データは、概算で秒当たり５６，０００ビットのレートでデバイス間を伝送することができる。このレートは、毎秒５６キロビット  （Ｋｂｐｓ）  で表すこともできる。
【００１１】
図１に示すように、インターネット上の伝送は複数のリンクを通り抜けてから、そのデスティネーション（目的地）に到達する。各リンクは独自のバンド幅をもっている。チェーン（鎖）はその最も弱いリンクと同じ強度しかないのと同じように、サーバ２０とクライント２０間の最大バンド幅は、最低速バンド幅をもつリンクで両者間を結んでいることになる。代表的には、これはクライアント９０とそのＩＳＰ  ８０間のリンクになっている。その最低速バンド幅は、事実上の最大バンド幅  （ｍａｘｉｍｕｍ  ｄｅ  ｆａｃｔ  ｂａｎｄｗｉｄｔｈ）  である。
【００１２】
ここでは、コンテキストから明らかである場合を除き、ネットワークエンティティ（サーバ２０とクライアント９０のような）間のバンド幅というときは、これらエンティティ間の事実上の最大バンド幅であるものと想定される。
【００１３】
バンド幅は、「コネクション速度（ｃｏｎｎｅｃｔｉｏｎ  ｓｐｅｅｄ）」、「速度」、または「レート」とも呼ばれる。本明細書の中でバンド幅というとき、それが毎秒ビット数で表されているときは、「ビット・レート（ｂｉｔ  ｒａｔｅ）」または「ビットレート（ｂｉｔｒａｔｅ）」とも呼ばれる（なお、本明細書では「ビットレート」ということにする）。
【００１４】
ストリーミングメディア
ストリーミング  （ｓｔｒｅａｍｉｎｇ）  は、一定で連続するストリームとして処理できるような形でマルティメディアデータを転送する手法である。ストリーミングテクノロジの重要度がインターネントの成長と共に高まっているのは、大部分のユーザによるアクセスが十分に高速でないため、大量のマルチメディアファイルを高速にダウンロードできないからである。ストリーミングを使用すると、クライアントブラウザまたはプラグインは、ファイル全体の伝送が完了する前にデータ表示を開始することができる。
【００１５】
ストリーミングが働くためには、データを受信するクライアント側は、データを収集し、そのデータを一定のストリームとしてアプリケーションに送信し、そのアプリケーションでデータを処理し、それをサウンドやピクチャに変換できるようになっていなければならない。このことは、ストリーミングクライアントが必要以上の高速でデータを受信したとき、余分のデータをバッファに置いておく必要があることを意味する。逆に、データが十分に高速で受信されないときは、データのプレゼンテーションはスムーズに行われないことになる。
【００１６】
オーディオおよび／またはビジュアルプレゼンテーションのコンテキスト内では、「メディア」と「マルティメディア」は、本明細書では同じ意味で用いられている。メディアとは、テキスト、グラフィックス、ビデオ、アニメーション、および／またはサウンドを統合化して提示することを意味している。
【００１７】
「ストリーミングメディア」とは、ネットワーク（インターネットなど）を利用してエンドユーザに伝送されるオーディオおよび／またはビジュアルプレゼンテーションである。このような伝送は、プレゼンテーションが相対的にスムーズで、ジャーク  （ｊｅｒｋｙ）  が生じないように行われる。追加のフレームがユーザにダウンロードされている間のポーズ  （ｐａｕｓｅ）  が長いと、ユーザにとっては煩わしくなっている。このような煩わしさは、ユーザが将来のストリーミングメディアを見ることを断念させる原因になっている。
【００１８】
ストリーミングメディアのスムーズな伝送
クライアントがデータを受信するときのレートはバンド幅によって決まるので、ストリーミングメディアプレゼンテーションが提示されるときのレートは、バンド幅が許容するレートまでに制限されている。例えば、メディアサーバ２０が、ストリーミングメディアプレゼンテーションをスムーズに「プレイ」するためには、データを５０Ｋｂｐｓでクライアント９０に送信する必要があるとする。しかし、クライアントとサーバ間のバンド幅は３０Ｋｂｐｓに制限されている。その結果は、メディアプレゼンテーションがジャークし、ジャンプすることになる。
【００１９】
この問題を緩和する試みとして、ストリーミングメディアプレゼンテーションは、品質度の異なる複数のフォーマットに符号化（エンコード）されている。
【００２０】
最低品質のフォーマット（例えば、小サイズ、低解像度、小カラーパケット）は、一定時間にクライアントにプッシュ  （ｐｕｓｈ）  されるデータ量が最小になっている。従って、低速リンク上のクライアントはストリーミングメディアプレゼンテーションをスムーズに提示できるが、プレゼンテーションの品質が犠牲になっている。
【００２１】
最高品質のフォーマット（例えば、フルスクリーンサイズ、高解像度、大カラーサイズ）は、一定時間にクライアントにプッシュされるデータ量が最大になっている。従って、高速リンクをもつクライアントは、ストリーミングメディアプレゼンテーションをスムーズに提示できると共に、高品質のプレゼンテーションが得られることになる。
【００２２】
バンド幅選択アプローチ
サーバはストリーミングメディアをクライアントに送信するとき、どのようなフォーマットを使用するかを知っていなければならない。従って、正しいフォーマットを選択するためには、サーバはサーバとクライアント間のバンド幅を知っていなければならない。
【００２３】
これを行う最も簡単な方法は、どのようなバンド幅であるかをクライアントのユーザに尋ねることである。インターネットへのクライアントのリンクは、バンド幅にボトルネックがあるのが代表的であるので、このリンクのバンド幅が分かると、実際のバンド幅が分かるのが一般的である。
【００２４】
図２は、クライアントのコンピュータに表示されるＷｅｂページの１部分（カッタウェイ）１００を示す。このカッタウェイ１００の内部には、そのコネクション速度についてユーザに尋ねるために使用できる代表的なユーザインタフェースがある。ユーザは、ユーザインタフェース１１０によって提供される、３つのボタン１１２、１１４、１１６をクリックする。ユーザがボタン１１２をクリックすると、サーバは、２８．８  Ｋｂｐｓで伝送する設計になったフォーマットでストリーミングメディアを収めているファイルからデータを送出する。同様に、ユーザがボタン１１４をクリックすると、データは、５６．６  Ｋｂｐｓで伝送する設計になったフォーマットでストリーミングメディアを収めているファイルから送信される。ユーザがボタン１１４をクリックすると、サーバは、５６．６  Ｋｂｐｓ以上であって、Ｔ１コネクションの代表的速度までのレートで伝送する設計になったフォーマットでストリーミングメディアを収めているファイルからデータを送信する。
【００２５】
しかし、「バンド幅選択」アプローチによると、ユーザに慎重な選択が要求されるという大きな問題がある。このアプローチによると、選択エラーが起こりやすくなっている。
【００２６】
ユーザはコネクション速度に注意し、理解し、知識があることが要求されている。よくあることは、ユーザがどのボタンを押すべきかに特別な注意を払わないことである。ユーザが分かっていることは、ユーザがボタンの１つを押すと、メディアプレゼンテーションが表示されることだけである。従って、ユーザはボタンのどれかを押している。
【００２７】
また、よくあることは、ユーザがバンド幅の概念を理解していないことである。ユーザがボタン１１６を選択するのは、プレゼンテーションを最高品質で見たいからである。プレゼンテーションを最高品質で表示すると、インターネットコネクションは、インターネットコネクションを通してデータが送信されるときのレートを処理できないので、プレゼンテーションがスムーズでなくなるということがこのユーザに分かっていない。
【００２８】
ユーザはバンド幅の概念を理解していても、自分のバンド幅が分かっていないことがある。ユーザは自分のバンド幅に無知だけのこともある。さらに、ノイズの度合が変化すると、ユーザがインターネットに接続するたびにコネクション速度が変化することがある。さらに、コネクションのタイプによっては（ケーブルモデムなど）、多数の要因によってコネクション速度が広範囲に変化するものもある。
【００２９】
さらに、ユーザは、選択が正しくないと、どのようなことが起こるかを理解している必要がある。ユーザは、スムーズなプレゼンテーションを得るためには自分のバンド幅と同じか、あるいはそれ以下のオプションを選択する必要があることを理解できるだけの教育が必要である。しかし、ユーザは、自分のバンド幅より大幅に低いオプションを選択してはならない。そのようにすると、利用できる、もっと高いバンド幅で表示できるはずのスムーズなプレゼンテーションが、低品質で表示されることになってしまう。
【００３０】
以上の説明から理解されるように、このマニュアル（手動操作）による方法は、多くのユーザを混乱させ、脅威になっていることがよくある。そのため、選択を誤ることがよく起こっている。
【００３１】
さらに、多数のファイル（バンド幅ごとに１ファイル）をメディアサーバに置いておくと、Ｗｅｂサイトを維持するオーバヘッドが増加することになる。
【００３２】
自動バンド幅検出
上記問題を解消するために、メディアサーバはシングルファイルを使用し、複数のバンド幅用のサブファイルをそこに収めておくことができる。さらに、メディアサーバは、バンド幅を自動的に検出することができる。
【００３３】
このシングルファイルは、ＭＢＲ（ｍｕｌｔｉｐｌｅ  ｂｉｔ  ｒａｔｅ：複数ビットレート）ファイルと呼ばれている。ＭＢＲファイルは、複数の異なる「バンド」または「ストリーム」を収めているのが代表的である。これらのバンドは「サブファイル」と呼ばれている。ユーザは１つのリンクをクリックするだけである。すると、サーバは、クライアントに送信するときの正しい速度のバンドを、自動的に判断する。なお、これはユーザには見えないように行われる。
【００３４】
この自動速度検出は時間がかかることがある。このことは、プレゼンテーションが始まるまでに、ユーザはさらに５秒または１分（またはそれ以上）待たされることを意味している。既存の自動速度検出にこのような遅れがあるのは、速度判断が進行中のときの「ハンドシェ−キング」時間が長いことによる。
【００３５】
ある既存自動速度検出手法では、サーバとクライアント間の速度を測定するために複数のデータパケットが送信されている。この手法は、以下の「複数測定パケット手法」の個所に詳しく説明されている。
【００３６】
バンド幅測定パケット
代表例として、自動バンド幅検出手法では、既知サイズの１または２以上のパケットを送信することによって、ネットワーク上のエンティティ間のバンド幅を測定している。
【００３７】
図３は、送信側（例えば、サーバ）と受信側（例えば、クライアント）間の２つのパケット（ＰｘとＰｙ）の伝送をたどって行く時間グラフを示す。サーバ側とクライアント側はそのように示されている。グラフ上では、時間は下に向かって進んでいる。
【００３８】
時刻ｔａは、Ｐｘの伝送が開始されるサーバ側の時刻を示している。時刻ｔｂは、Ｐｘの伝送が終了するサーバ側の時刻を示している。同様に、時刻ｔ０は、クライアントがＰｘの受信を開始する時刻を示している。時刻ｔ１は、クライアントがＰｘの受信を完了する時刻を示している。ｔ１時に、ネットワークハードウェアは、通信層を上方に向かってパケットを渡していき、アプリケーション層に到達するものと想定されている。
【００３９】
パケットＰｙは、図３の時間グラフ上に同じように示されている。ｔｃは、Ｐｙの伝送が開始されるサーバ側の時刻である。ｔｄは、Ｐｙの伝送が終了するサーバ側の時刻である。同様に、ｔ２は、Ｐｙの受信を開始するクライアント側の時刻である。ｔ３は、Ｐｙの受信を完了するクライアント側の時刻である。ｔ３時に、ネットワークハードウェアは、通信層を上方に向かってパケットを渡していき、アプリケーション層に到達するものと想定されている。
【００４０】
シングルパケットを使用したバンド幅測定。研究所のように制御された環境では、ネットワーク上の２エンティティ間のバンド幅測定は簡単である。この計算を行うために、既知サイズのパケットが一方のエンティティから他方のエンティティに送信され、伝送レイテンシが測定されている。ここで、伝送レイテンシ  （ｔｒａｎｓｍｉｓｓｉｏｎ  ｌａｔｅｎｃｙ）  とは、パケットがソース（発信元）からデスティネーション（宛先）まで走行して行くのに要する時間量のことである。このようなシナリオが与えられているとき、パケットが送信された時間とパケットが到着した時間が分かっていなければならない。
【００４１】
この手法は、研究所以外ではほとんど非実用的である。この手法は、クライアントとサーバ間が同期している必要があるので、非同期ネットワーク（インターネットなど）では使用できない。クライアントとサーバのどちらも、同じクロックを使用している必要がある。
【００４２】
別の手法として、クライアントは、パケットの受信を開始した時刻（Ｐｘではｔ０）と、パケットの受信が完了した時刻（Ｐｘではｔ１）をたどって行くことができる。
【００４３】
図３は、サーバからクライアントに送信されるパケットＰｘを示している。Ｐｘは、パケットサイズＰＳは既知サイズ（ビット数）になっている。バンド幅  （ｂｗ）  の計算式は次の通りである。
【００４４】
【数１】
0004806141.tif 000002
【００４５】
この手法は理論的には有効であるが、残念ながら実用には適していない。パケットがいつ初めて受信されるかは、ハードウェアだけが分かっている。従って、ｔ０がいつであるかは、ハードウェアだけが分かっている。
【００４６】
その他の通信層（トランスポート層とアプリケーション層など）が分かっているのは、パケットがハードウェアによって完全に受信された時刻だけである。これは、ハードウェアがパケットをこれらの層に渡したときである。パケットＰｘの完了時刻はｔ１である。ある時点が分かっているだけでは、バンド幅を計算することは不可能である。
【００４７】
パケットペア。パケットペア  （ｐａｃｋｅｔ−ｐａｉｒ）  と呼ばれる手法は、非同期ネットワークでの上記問題を解消するために使用されている。パケットペアによると、２つの同一パケットはバックツーバック  （ｂａｃｋ−ｔｏ−ｂａｃｋ）  で送信される。サーバは、一方が他方の直後に続くように、ペアのパケットを送信する。両パケットは同じであるので、同一サイズ  （ＰＳ）  になっている。バンド幅は、パケットサイズを各パケットの受信の時間差で除することによって求められている。
【００４８】
各パケットは固有の測定可能特性をもっている。具体的には、これらの特性としては、そのパケットサイズ  （ＰＳ）  とパケット到着といった測定時間（例えば、図３中のｔ０ ３）がある。ある種の特性（パケットサイズなど）は、測定されるよりも指定されることがあるが、測定することが望ましければ、測定することも可能である。
【００４９】
図３に示すように、サーバはパケットＰｘを送信する。クライアント側ハードウェアはｔ０時にパケットの受信を開始する。パケットの受信がｔ１時に完了すると、ハードウェアは通信層を上方に向かってパケットを渡していく。最終的には、パケットはほぼｔ１時にデスティネーション層（例えば、アプリケーション層）によって受信される。
【００５０】
サーバはＰｘを送信したあと（これはｔｂ時に完了している）、ｔｃ時にパケットＰｙを即時に送信する。重要なことは、１）  ｔｂとｔｃの間に測定可能な遅延が絶対に存在しないか、あるいは２）  ｔｂとｔｃの間に存在する遅延の長さが分かっていることである。ここでは、説明を簡単にするために、ｔｂとｔｃの間に測定可能な遅延が存在しないものとしている。
【００５１】
クライアント側ハードウェアはｔ２時にＰｙの受信を開始する。このパケットの受信がｔ３時に完了すると、ハードウェアは通信層の上方に向かってパケットを渡していく。最終的に、パケットはほぼｔ３時にデスティネーション層（例えば、アプリケーション層）によって受信される。
【００５２】
図３は、ｔ１（Ｐｘの受信完了時刻）とｔ２（Ｐｙの受信開始時刻）の間に遅延が存在しないことを示している。理論的には、このことが常に起こるのは、ＰｘとＰｙが同じ条件で伝送されたときである。実際には、このことがよく起こるのは、ＰｙがＰｘの直後に送信されるからである。
【００５３】
パケットペアを使用したときの、バンド幅  （ｂｗ）  の計算式は次の通りである。
【００５４】
【数２】
0004806141.tif 000003
【００５５】
この手法は理論的にも、実用面でも有効である。しかし、これが有効に働くのは、比較的静的なネットワークに限られている。
【００５６】
例えば、図１に示す想定では、ネットワークはサーバ２０、ルータ３２、３４、３６、ＩＳＰ８０の中の特定ＩＳＰ、およびクライアント９０から構成されている。さらに、この静的ネットワーク上の各ノード間のリンクは固定され、一定のバンド幅をもっていることが想定されている。このような状況では、パケットペア手法によると、正確で、効果的なバンド幅測定が得られる。
【００５７】
パケットペアをインターネット上で使用したときの問題。しかし、パケットペア手法は、インターネットのような動的ネットワークでは有効な働きをしない。動的ネットワークとは、パケットが先行パケットとは異なるか、後続パケットとは異なる方法で処理される可能性があるようなネットワークである。具体的には、ＴＣＰネットワークで問題が起こっている。
【００５８】
図１は、動的ネットワーク上で見られる差異を処理する例を示している。ここでは、すべてのパケットはサーバからクライアントへ（図１の左から右へ）走行するものと想定されている。また、パケット６０〜６８は、サーバ２０によってバックツーバックでクライアントに送信されたものと想定されている。
【００５９】
図１を見れば明らかなように、パケットは異なるルートを通ることが可能になっている。さらに、ルートによっては、パケット伝送を大幅に遅延させるものがある。このことが起こるのは、特に、パケットが、ワイヤレス伝送のような見かけ上異常な（必ずしも、通常でないとは限らない）ルートを経て伝送され、海底ケーブル、サテライト伝送（ディッシュ４６、５０とサテライト４８で図示）などを経て海外に伝送されるときである。ルータ（ルータ４２のような）は、パケットをメモリ（バッファ４３のような）に一時的に置いておくことにより、別のルータよりも１または２以上のパケット（６３と６４のような）を遅延させることがある。
【００６０】
複数測定パケット手法
上述した問題を解消するために、従来の自動バンド幅測定手法では、複数のパケットが使用されている。サーバは複数のパケット（３以上のパケット）を送信し、各パケットの速度を計算している。バンド幅測定の従来の考え方から明らかであるように、正確な測定を得るためには、複数のペアのパケットを、数秒間から数分間にわたって繰り返し送信する必要がある。ここでは、上述した「パケットペア」手法と区別するために、この手法は「複数パケット」と呼ぶことにする。
【００６１】
代表例として、最終的バンド幅は、多数のバンド幅測定の平均を求めることによって判断されている。このように平均をとると、各パケットの遅延のばらつきは平滑化されるが、伝送中のパケット圧縮は補償されない。２測定のうち一方が非常に不正確であると、平均はゆがむことになる。
【００６２】
残念ながら、この手法は、クリックしてからメディアプレゼンテーションまでユーザが待たされていた時間に比べて待ち時間が長くなっている。この待ち時間は、データと状況に応じて５秒から数分間にわたっている。このような待ちがあると、メディアプレゼンテーションを体験することを望んでいるユーザにとっては、煩わしが増加することになる。この遅延は望ましくない。従来の手法では、利用できる他のオプションがないために、ユーザはこれらの遅延に我慢せざるを得なくなっている。
【００６３】
どの既存自動バンド幅測定手法も、インターネット上のバンド幅を、ペアのパケットを使用してほぼ瞬時に測定することが不可能である。また、どの既存自動バンド幅測定手法も、この測定をアプリケーション層で行うことが不可能である。そのために、オペレーティングシステムを修正することが回避されている。どの既存自動バンド幅測定手法も、パケット圧縮が原因で起こる測定ひずみを扱っていない。
【００６４】
トランスポート層の実装
従来のアプローチでは、自動バンド幅測定を行うためにオペレーティングシステム  （ＯＳ）  のカーネルを修正しているのが代表的である。具体的に説明すると、これらのアプローチでは、ＯＳＩモデルのトランスポート層を修正しているが、この層はＯＳのカーネルに置かれていることが多い。一般的に、このような修正は、ＯＳを修正していない実装に比べて、全体的に安定性が低下し、高価になるので望ましくない。
【００６５】
これらのアプローチはアプリケーション内に（従って、アプリケーション層に）実装できないので、このような修正は不可能になる。しかし、どの既存パケットペアによる手法も、アプリケーション層でバンド幅を測定していない。これは、ネットワーク上で実際に行われるコミュニケーション詳細に対する制御権が、アプリケーション層では、他の層に比べて低いためである。具体的には、アプリケーションは、ＴＣＰ使用による制御権が、ＵＤＰ（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ：ユーザデータグラムプロトコル）による場合よりも、はるかに低くなっている。
【００６６】
ＴＣＰとＵＤＰは、以下の「ＴＣＰとＵＤＰ」の個所に詳しく説明されている。トランスポート層とアプリケーション層は、以下で説明するＯＳＩモデルの７層の一部になっている。
【００６７】
ＴＣＰとＵＤＰ
インターネット（および他のネットワーク）上では、データパケットは、ＴＣＰまたはＵＤＰプロトコルを使用して送信されるのが通常である。ＴＣＰはインターネットでは広く認められ、理解されている。
【００６８】
ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ：伝送制御プロトコル）は、ＴＣＰ／ＩＰネットワーク（インターネットなど）における主要プロトコルの１つである。ＩＰプロトコルはパケットだけを扱っているのに対し、ＴＣＰは２つのホストがコネクションを確立し、データストリームをやりとりすることを可能にしている。ＴＣＰは、データの配達を保証し、パケットがその送信時と同じ順序で配達されることを保証している。
【００６９】
ＵＤＰ（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ：ユーザデータグラムプロトコル）はコネクションレス型プロトコル  （ｃｏｎｎｅｃｔｉｏｎｌｅｓｓ  ｐｒｏｔｏｃｏｌ）  であり、（ＴＣＰと同じように）ＩＰネットワークの上で走行する。ＴＣＰ／ＩＰとは異なり、ＵＤＰ／ＩＰは提供するエラー回復サービスが非常に少ないが、その代わりに、ＩＰネットワーク上のパケット（つまり、データグラム）の送受信を直接的方法で行うことができる。
【００７０】
パケットは、アプリケーションプログラムによって提供されるデータの塊  （ｃｈｕｎｋ）  である。ＵＤＰでは、シングル「アプリケーションレベルデータ」はシングルＵＤＰパケットとして送信されるのが代表的である。これに対し、ＴＣＰでは、シングルアプリケーションレベルパケットは、もっと小さな、複数のＴＣＰ「セグメント」に分割され、その各々はＴＣＰ層で別々の「パケット」として扱われるようになっている。Ｎａｇｌｅ  アルゴリズム（下述する）は、上記とは逆のことを行う。つまり、複数の、小さなアプリケーションパケットを受け取り、それらを結合してもっと大きな、１つのＴＣＰセグメントにする。
【００７１】
Ｎａｇｌｅ  ＴＣＰ／ＩＰ  アルゴリズム
Ｎａｇｌｅ  アルゴリズムは、低速ネットワーク上で小さなＴＣＰセグメント（「タイニグラム（ｔｉｎｙｇｒａｍ）」と呼ばれることもある）に起こる問題を回避する設計になっている。このアルゴリズムの規定によれば、まだ受信確認（ＡＣＫ）  されていないで未処理のまま、ＴＣＰ／ＩＰコネクションに残っているタイニグラムは１つに限られている。タイニグラムの定義サイズは実装によって決まる。しかし、そのサイズは、一般的に、代表的なＴＣＰセグメントのサイズより小さくなっている。
【００７２】
Ｎａｇｌｅ  アルゴリズムのよれば、状況によっては、データが送信される前の待ち時間は約２００ミリ秒  （ｍｓｅｃ）  であることが規定されている。Ｎａｇｌｅ  アルゴリズムは、スイッチ経由のトラフィックに対して次のようなパラメータを使用している。
・  セグメントサイズ  ＝  ＭＴＵまたはｔｃｐ＿ｍｓｓｄｆｌｔまたはＭＴＵ経路検出値
・  ＴＣＰウィンドウサイズ  ＝  ｔｃｐ＿ｓｅｎｄｓｐａｃｅ値とｔｃｐ＿ｒｅｃｖｓｐａｃｅ値のうち小さい方
・  データサイズ  ＝  アプリケーションデータバッファサイズ
【００７３】
以下は、データをいつ送信するかを判断するときＮａｇｌｅ  アルゴリズムによって使用される、具体的ルールである。
・  パケットがセグメントサイズと同じか、それより大きく、ＴＣＰウィンドウが一杯になっていなければ、ＭＴＵサイズのバッファを即時に送信する。
・  インタフェースがアイドル中であるか、ＴＣＰ＿ＮＯＤＥＬＡＹフラグがセットされていて、ＴＣＰウィンドウが一杯になっていなければ、バッファを即時に送信する。
・  ＴＣＰウィンドウに未処理のまま残っているデータがウィンドウの半分以下であれば、バッファを即時に送信する。
・  送信するセグメントサイズがバッファ未満であり、ウィンドウに未処理のまま残っているデータがウィンドウの半分以上であって、ＴＣＰ＿ＮＯＤＥＬＡＹがセットされていなければ、残りデータについて２００  ｍｓｅｃまで待ってからバッファを送信する。
【００７４】
送信側のソケットでＴＣＰ＿ＮＯＤＥＬＡＹをセットすると、Ｎａｇｌｅ  アルゴリズムは非アクチベートされる。送信される全データは、データサイズに関係なく即時に送出される。
【００７５】
Ｎａｇｌｅ  アルゴリズムは、広い意味では、「タイニグラムバッファリング」機能と呼ぶことができるが、これはタイニグラムがバッファリングされるからである。
【００７６】
ＴＣＰ  Ｓｌｏｗ  Ｓｔａｒｔアルゴリズム
“Ｓｌｏｗ  Ｓｔａｒｔ”（スロースタート）を使用しないＴＣＰネットワークでは、デバイスは、受信側が公表しているウィンドウサイズに達するまで、複数のパケットをネットワークに投入することによって送信側とのコネクションを開始している。２ホストが同じＬＡＮ上にあるときは、これは許されるが、送信側と受信側の間にルータや低速リンクがあると、問題が発生する可能性がある。中間ルータの一部はパケットを待ち行列（キュー）に置いておく可能性があるので、そのようなルータは、メモリ不足のためパケットを待ち行列に置くことができないことが起こり得る。従って、このナイーブなアプローチによると、ＴＣＰコネクションのスループットが大幅に低下するおそれがある。
【００７７】
これを回避するアルゴリズムは”Ｓｌｏｗ  Ｓｔａｒｔ”  と呼ばれている。このアルゴリズムは、新パケットがネットワークに投入されるときのレートが、受信確認通知が他方のエンドから戻されるときのレートであることを観察する働きをする。
【００７８】
このＳｌｏｗ  Ｓｔａｒｔアルゴリズムでは、送信側のＴＣＰに別のウィンドウが追加されている。つまり、輻輳  （ｃｏｎｇｅｓｔｉｏｎ）  ウィンドウであり、”ｃｗｎｄ”と名付けられている。別のネットワーク上のホストとの間で新しいコネクションが確立されると、輻輳ウィンドウは１パケットに初期化される。受信確認通知（つまり、”ＡＣＫ”）が受信されるたびに、輻輳ウィンドウは１パケットずつ増加して行く。送信側は、「輻輳ウィンドウ」と「公表（ａｄｖｅｒｔｉｓｅｄ）ウィンドウ」の最小限まで送信することができる。「輻輳ウィンドウ」は、送信側によって課されたフロー制御である。「公表ウィンドウ」は、受信側によって課されたフロー制御である。前者は、ネットワーク輻輳がどの程度であるかを送信側が評価することに基づいている。後者は、そのコネクションのために利用できるバッファスペースが、受信側にどれだけ残っているかに関係している。
【００７９】
送信側は、１パケットを送信し、そのＡＣＫ（受信確認通知）を待つことからスタートする。そのＡＣＫが受信されると、輻輳ウィンドウは１から２にインクリメントされる。これらの２パケットの各々が受信確認されると、輻輳ウィンドウは４に増加する。以下、同様である。
【００８０】
いずれかの時点で、送信側と受信側間のコネクションの容量まで到達することになる。容量まで到達すると、いずれかの中間ルータはパケットを破棄することを開始する。輻輳ウィンドウが限界まで達したことは、この廃棄によって送信側は知ることになる。
【００８１】
プロキシ
プロキシ  （ｐｒｏｘｙ）（つまり、プロキシサーバ）は、クライアントアプリケーション（Ｗｅｂブラウザなど）と実サーバ  （ｒｅａｌ  ｓｅｒｖｅｒ）の間に置かれたデバイスである。一般的に、プロキシは、実サーバとの間でやりとりされるすべての要求をインターセプト  （ｉｎｔｅｒｃｅｐｔ）  し、自身で要求を満たすことができるかどうかを確かめる。満たすことができなければ、要求を実サーバに転送する。プロキシは、主に次の２目的のために採用されている。すなわち、パフォーマンス向上と要求のフィルタリングである。
【００８２】
プロキシは、複数のクライアントのための中央コミュニケーションポイントとなることが多いので、そのコミュニケーションを可能な限り効率化することを試みている。従って、プロキシは、Ｎａｇｌｅ  アルゴリズムの一種を実装しているのが代表的である。すべての新コネクションはＳｌｏｗ  Ｓｔａｒｔから開始する。クライアントとサーバの間にプロキシが置かれているときは、Ｓｌｏｗ  Ｓｔａｒｔは、２つのコネクションで実行される。すなわち、サーバとプロキシ（ｓｅｒｖｅｒ−ｐｒｏｘｙ）  間コネクションとプロキシとクライアント  （ｐｒｏｘｙ−ｃｌｉｅｎｔ）  間コネクションである。従って、プロキシを使用すると、パケットペアの試みはさらに複雑化することになる。
【００８３】
【発明が解決しようとする課題】
背景の要約
アプリケーション（アプリケーション層に置かれている）は、ＴＣＰパケットの処理に対する制御が制限されている。従って、従来のバンド幅測定では、アプリケーションレベルでのＴＣＰバンド幅測定が回避されている。
【００８４】
パケットペア手法では、少なくとも２つのパケットはバックツーバックで送信されることが保全性の要件となっている。しかし、これらのパケットは、Ｎａｇｌｅ  アルゴリズムとＳｌｏｗ  Ｓｔａｒｔ  アルゴリズムの影響のためにそのような形で到着しないことがある。このことが、ＴＣＰネットワーク上のバンド幅測定にパケットペア手法を使用することの妨げとなっている。
【００８５】
そこで、本発明の目的は、パケットペア手法を使用することの可能なＴＣＰネットワーク環境におけるバンド幅の高速動的測定方法を提供することにある。
【００８６】
【課題を解決するための手段】
概要
ＴＣＰネットワーク環境における高速動的バンド幅測定では、ネットワーク（インターネットなど）上の２エンティティ間のバンド幅を計算するために、シングルペアのパケットが利用されている。この計算はパケットペア手法に基づいている。このバンド幅測定は非常に高速である。
【００８７】
パケットがネットワークを走行している途中で、通信デバイスはパケットペアを遅延させることがある。具体的には、ＴＣＰネットワークでは、ネットワークの総スループットを向上することを目標として、ある種のパケットを遅延させる設計になった２つのアルゴリズムが使用されている。しかし、これらのアルゴリズムは、バンド幅を測定することを目的としたパケットペアを事実上遅延させる可能性がある。従って、これらのアルゴリズムを使用すると、測定にひずみが起こっている。そのアルゴリズムとは、”Ｎａｇｌｅ”と”Ｓｌｏｗ  Ｓｔａｒｔ”である。
【００８８】
高速動的バンド幅測定では、これらのアルゴリズムに課されている遅延を解消するための対応策が実装されている。その対応策とは、Ｎａｇｌｅ  アルゴリズムの適用を禁止すること、「プッシュ」パケットをパケットペアの直後に送信することによってパケットのバッファリングを最小限にすること、およびダミーパケットで初期化（プライミング）することによってＳｌｏｗ  Ｓｔａｒｔ  アルゴリズムを回避することである。
【００８９】
【発明の実施の形態】
以下では、ＴＣＰネットワーク環境におけるバンド幅の高速動的測定の具体的実施形態について説明するが、そこには請求項に記載されているエレメントが組み込まれている。この実施形態は、法律上の要件、使用可能性の要件、および最良形態の要件に合致するように具体的に説明されている。しかし、その説明自体は、本発明の範囲を限定するものではない。むしろ、本発明によるＴＣＰネットワーク環境における高速動的バンド幅測定は、他の現存および将来のテクノロジと併用して他の方法でも実現可能であり、それが本発明者の意図する目的である。
【００９０】
例示のＴＣＰネットワーク環境におけるバンド幅の高速動的測定（つまり、「バンド幅メータ」または「ｂｗ−ｍｅｔｅｒ」。なお、以下では、「バンド幅メータ」という）はＴＣＰネットワーク（インターネットなど）で使用されたときでも、高速であり、強固である。例示のバンド幅メータは、通信ネットワーク上の２エンティティ間で利用可能なネットワークバンド幅を自動的に測定する低レイテンシ手法が実装されている。これは、インターネット（または他のＴＣＰネットワーク）上で利用すると、特に有用であることが判明している。
【００９１】
従来のアプローチとは異なり、例示のバンド幅メータによると、困難なネットワーク条件下でも、起こり得る遅延を最小にして最善努力のバンド幅測定が得られる。例示のバンド幅メータは、ＬＡＮ、ケーブル、ＤＳＬ、およびモデムコネクションを含む、大部分の既存ＴＣＰネットワークにおいて１秒未満で妥当な出力が得られる設計になっている。
【００９２】
さらに、例示のバンド幅メータは、アプリケーション層に実装されている。例示のバンド幅メータは他の層でも実装可能であるが、ここで説明されているものはアプリケーション層に実装されている。具体的には、これは、その一部をＷｅｂブラウザまたはメディアプレイヤで実現することが可能である。
【００９３】
例示のバンド幅メータによって実現可能なパケットペア手法の他の側面は、米国での特許出願、発明の名称「コネクションバンド幅の高速動的測定（ＦａｓｔＤｙｎａｍｉｃ  Ｍｅａｓｕｒｅｍｅｎｔ  ｏｆ  Ｃｏｎｎｅｃｔｉｏｎ  Ｂａｎｄｗｉｄｔｈ）」、Ｍｉｃｒｏｓｏｆｔ  Ｃｏｒｐｏｒａｔｉｏｎに譲渡済み）に詳しく説明されている。なお、この米国特許出願の内容は引用により、本明細書の一部になっている。
【００９４】
パケットペア手法
例示のバンド幅メータでは、上述し、図３に示されている、確立されたパケットペア手法が利用されている。例示のバンド幅メータは、上述したパケットペア公式（式２）を使用して、通信ネットワーク（インターネットなど）上の２エンティティ間の、事実上の最大バンド幅を計算している。
【００９５】
複数のパケットを使用している、既存自動バンド幅測定手法とは異なり、例示のバンド幅メータは、インターネット上のバンド幅を測定するためにシングルペアのパケットを使用している。例示のバンド幅メータでは、バンド幅測定と計算は、シングルペアの測定パケットだけが送信されるので、「ほぼ瞬時」に行われる。ここで「ほぼ瞬時に（ｎｅａｒｌｙ  ｉｎｓｔａｎｔａｎｅｏｕｓｌｙ）」とは、ペアのパケットがクライアントに到着するのと同時にバンド幅が求められることを意味している。
【００９６】
例示のバンド幅メータは、Ｎａｇｌｅ  アルゴリズムとＳｌｏｗ  Ｓｔａｒｔアルゴリズムに対する対応策を実装することによって、ＴＣＰネットワーク（インターネットなど）上でパケットペアを使用するときの欠点と制約を解消している。
【００９７】
パケットペアが通るルート。例示のバンド幅メータのパケットペア手法によるパケットは、送信側エンティティ（例えば、サーバ）から受信側エンティティ（例えば、クライアント）に走行する。図４は、そのような走行ルートの例を示す。図４に示す環境は、図１に示す環境に類似している。
【００９８】
図４は、代表的なインターネット（ＴＣＰネットワーク）構成の例を示す図である。そこには、サーバ（メディアサーバ２２０など）が含まれ、これはインターネット２３０に結合されている。サーバは、１または２以上の物理的サーバコンピュータ２２２が実装され、コンピュータは１または２以上の物理的ストレージデバイスおよび／またはデータベース２２４を装備している。インターネット伝送の反対側には、クライアント２９０、２９２が置かれており、これは、インターネットサービスプロバイダ  （Ｉｎｔｅｒｎｅｔ  Ｓｅｒｖｉｃｅ  Ｐｒｏｖｉｄｅｒ    ＩＳＰ）  ２８０である、プロキシサーバ２８４を経由して接続されている。
【００９９】
インターネットはクラウド２３０で示されているが、理解されるように、このクラウドは、そこに示されているものだけが置かれているインターネット部分を表している。このクラウドの内側には、ルータ、伝送回線、コネクション、および他のデバイスが置かれ、クライアントとサーバ間のデータ伝送が、ほぼ正常に行われるようにしている。例示のインターネットクラウド２３０の内側には、ルータ２３２〜２４４、２つのサテライトディッシュ２４６、２５０、およびサテライト２４８が置かれている。これらは、データパケットがサーバとクライアント間を走行する途中で取り得る経路を表している。
【０１００】
図４は、例示のバンド幅メータに従って送信されるペアの、連続するパケット２６０、２６２を示している。サーバ２２０は、パケット２６０の直後にパケット２６２を送信する。
【０１０１】
プロキシサーバ２８４は、リンク２８２を通してそのＩＳＰ２８０に接続されている。クライアント２９０とクライアント２９２はプロキシサーバを使用して、インターネットと通信する。
【０１０２】
アプリケーションレベルでのバンド幅測定
従来のバンド幅測定アプローチは、アプリケーション層の下のトランスポート層または他の、なんらかの層に実装されているのが代表的である。しかるに、例示のバンド幅メータはアプリケーション層に実装されている。アプリケーションレベルでＴＣＰパケットペアバンド幅を測定する方法には、少なくとも２つの大きな利点がある。
【０１０３】
第一は、下位レベル（トランスポート層など）にパケットペア手法を実装することは、不利であることである。ＯＳのカーネルの変更が必要になり、段階的（増分的）展開に役立たないからである。アプリケーションレベル実装とは異なり、下位パケットペア実装はその開発、初期展開、将来の開発、および将来の展開に多大な費用を要している。
【０１０４】
第二は、ある研究によれば、バンド幅測定の恩恵を受けるのは、研究対象のＴＣＰコネクションのうち１／４にすぎないことである。従って、使用されるコネクションがその１／４未満にすぎないときは、このバンド幅測定を下位レベルに実装することはコスト効果的でない。従って、このバンド幅は、それを必要とするアプリケーションに組み込んでおくのが最良である。アプリケーションは、オペレーティングシステムの新しいカーネルよりも、段階的（増分的）展開がはるかに容易である（低コストである）。
【０１０５】
一般的に、受信側クロックが十分な精度であり、ＩＰデータグラム（つまり、パケット）が受信側ネットワークスタック（ＯＳ層）を上方に向かって通り抜けてアプリケーションに妨害を受けることなく渡されるようにする考え方が安全な方法である。Ａｍｅｒｉｃａ  Ｏｎｌｉｎｅバージョン４  （ＡＯＬｖ４）およびそれ以前のソフトウェアのように、タイマだけでデータがアプリケーションに渡されるように振る舞っていた、ある種のアプリケーションの場合には、この考え方に反することになる。従って、測定には人工的クロックの細粒性が要求されていた。幸いなことに、ＡＯＬソフトウェアのバージョン５（およびそれ以降）では、このような妨害は起こっていない。
【０１０６】
パケットペア使用による効果的測定の条件
パケットペア手法を使用してバンド幅を測定するとき、良好な測定を得るためには２つの条件を満足しなければならない。
【０１０７】
第一の条件は、パケットがバックツーバックで送信されなければならないことである。ここでは、これを「バックツーバック」条件と呼ぶことにする。パケットがバックツーバックで送信されないときは、パケット間のタイミング測定にひずみが生じることになる。Ｎａｇｌｅ  アルゴリズムとＳｌｏｗ  Ｓｔａｒｔ  アルゴリズムはどちらも、この条件に反するおそれがある。どちらも、２番目の測定パケットの配達を遅延させる潜在性をもっている。パケットペアを使用してバンド幅を測定する場合は、実際のバンド幅の測定にひずみが生じるので、パケット間に起こることが避けられない遅延は耐えられないものになっている。
【０１０８】
第二の条件は、パケットのサイズは保たれていなければならないことである。つまり、パケットは他のパケットと結合してはならない。ここでは、これを「サイズ保持」条件と呼ぶことにする。Ｎａｇｌｅ  アルゴリズムは、この条件に反するおそれがある。
【０１０９】
Ｎａｇｌｅ  アルゴリズムによると、複数のアプリケーション層パケットはシングルＴＣＰパケットとして送信されることがある。従って、アプリケーションは２またはそれ以上のパケットを送信しているつもりでいても、実際には、ＴＣＰ層はシングルパケットだけを送信している。
【０１１０】
Ｎａｇｌｅ  アルゴリズムに対する対応策
Ｎａｇｌｅ  アルゴリズムの興味のある振る舞いは、小さなパケットのとき、未処理のまま残っているＡＣＫは１つだけであることである。従って、ペアになった小さなパケットは、Ｎａｇｌｅ  アルゴリズムではバックツーバックで送信することができない。Ｎａｇｌｅ  アルゴリズムでは、ＡＣＫを待っている小さなパケットは結合されることになる。これは、「バックツーバック」条件にも、「サイズ保持」条件にも影響を与えている。
【０１１１】
例示のバンド幅メータでは、Ｎａｇｌｅ  アルゴリズムがこれら２条件を妨げる傾向を解消するための対応策が講じられている。あるエンティティ（図４中のサーバ２２０など）はコマンドを送信し、通信デバイス（ルータ２３０−２５０など）がＮａｇｌｅ  アルゴリズムを使用禁止  （ｄｉｓａｂｌｅ）  にするように指示する。一般的に、サーバは「ディレイディスエーブル（ｄｅｌａｙ−ｄｉｓａｂｌｅ）」コマンドと総称されるコマンドを渡している。具体的には、サーバはＴＣＰ＿ＮＯＤＥＬＡＹをＳｅｔＳｏｃｋＯｐｔ（）に渡している。
【０１１２】
輻輳ウィンドウがオープンしている限り、Ｎａｇｌｅ  アルゴリズムをオフにすると、ＴＣＰはｐａｃｋｅｔ−ｐａｉｒパケットのいずれも結合する試みが禁止されるので、ＴＣＰは即時にパケットをネットワークに書き出すことになる。
【０１１３】
言い換えれば、Ｎａｇｌｅ  アルゴリズムを「ディレイディスエーブル」コマンドで使用禁止にすると、ｐａｃｋｅｔ−ｐａｉｒのどちらのパケットも、Ｎａｇｌｅが複数パケットを収集するとそれが原因で起こる遅延なしで、ルータを通過していくことになる。
【０１１４】
Ｓｌｏｗ  Ｓｔａｒｔ  アルゴリズムに対する対応策
例示のバンド幅メータでは、Ｓｌｏｗ  Ｓｔａｒｔ  アルゴリズムが「バックツーバック」条件を妨げる傾向を解消するための対応策が講じられている。これは、サーバの輻輳ウィンドウ（これは具体的には”ｃｗｎｄ”と名付けられている）を少なくとも３パケットにオープンすることによって行われる。
【０１１５】
これは、輻輳ウィンドウを「プライミング（ｐｒｉｍｉｎｇ）」（初期化）することによって行われる。輻輳ウィンドウをプライミング（初期化）するために、サーバは少なくとも１つのパケットを送信し、ＡＣＫを受信してから、ｐａｃｋｅｔ−ｐａｉｒのペアのパケットを送信するようにしている。従って、サーバは、少なくとも１つの「プライミング」パケットをクライアントに送信するが、そのパケットはバンド幅計算のためには使用されない。１つまたは２つ以上のプライミングパケットが送信されたあと、サーバは、バンド幅計算のために実際に使用されるｐａｃｋｅｔ−ｐａｉｒを送信する。この時点では、Ｓｌｏｗ  Ｓｔａｒｔ  アルゴリズムでは、少なくとも２パケットが遅延することなく、続けて通り抜けるようにしている。
【０１１６】
Ｓｌｏｗ  Ｓｔａｒｔ  アルゴリズムは、特定のＴＣＰコネクションの後半でバンド幅測定を行うようにすると、完全に回避することができる。しかし、これは、２つの理由で望ましいオプションではない。遅延とオーバヘッドが増加し、誤った測定の原因となるからである。
【０１１７】
測定が後半で行われる場合は、組み込まれた遅延があるため、Ｓｌｏｗ  Ｓｔａｒｔ  アルゴリズムが全コースを走行するまで待たされることになる。回避できる遅延ならば、ない方がよい。例示のバンド幅メータによると、この遅延を回避することができる。
【０１１８】
バンド幅測定をＴＣＰコネクションの先頭で行うと、コネクションの進行と共に累積して行く、多数の不確実性が除去される。例えば、ＴＣＰコネクションが制御層とデータトランスポート層の両方で共有されているときは、送信側の輻輳ウィンドウにパケットがバケットツーバックで送信される余裕があるかどうかを、セッションの後半で予測することは不可能である。
【０１１９】
プロキシでの遅延に対する対応策
プロキシで動作しているＮａｇｌｅ  アルゴリズムは、同じように、ｐａｃｋｅｔ−ｐａｉｒのバンド幅測定にひずみを生じさせる可能性がある。一般的に、プロキシは「ディレイディスエーブル」コマンドを認識しない。クライアントとサーバのどちらのアプリケーションも、コネクションが回線レベルのプロキシを通るように行われているかどうかを、事前に通知することができない。
【０１２０】
プロキシに置かれたＮａｇｌｅ  アルゴリズムにアドレスするためには、ペアの測定パケットのあとに大きな第３パケットが送信されている。プロキシがｐａｃｋｅｔ−ｐａｉｒの第２パケットを保持していると、この第３パケットは第２パケットをプッシュ（押し出す）ことになる。従って、この第３パケットは「プッシュ（ｐｕｓｈ）」パケットと呼ばれている。
【０１２１】
さらに、第１パケットと第２パケットは、プロキシで結合するこが可能である。このようにすると、人工的に得られる測定は高くなるが、いずれにしても、プロキシユーザの圧倒的多数は高バンド幅コネクションをもつことなる。
【０１２２】
方法による実装
図５は、例示のバンド幅メータを方法で実現した例を示す。これは、サーバ側から見た図である。３００で、例示のバンド幅メータによる動的バンド幅測定が開始される。代表例として、クライアントのユーザは、Ｗｅｂページ上でオプションを選択すると、メディアプレゼンテーションを体験することになる。別の方法として、このバンド幅測定を、クライアントに置かれたアプリケーションで開始することも可能である。そのようなアプリケーションとしては、Ｗｅｂブラウザ、メディアプレイヤなどがある。
【０１２３】
一般的に、図５の３０２で、サーバは、一方が他方の直後に続くように、ペアのパケットをクライアントに送信する。このブロック３０２での具体的な実装詳細は、図６、図７、および８に示されている。これらの図については、下述する。
【０１２４】
３０６で、サーバはクライアントからの応答を待っている。時間制限内に応答が受信されなければ、このプロセスは元に戻り、３０２で別のペアのパケットが送信される。フローチャートには図示されていないが、このプロセスによれば、これは一定の回数繰り返されたあと、終了し、エラーを生成する。応答が時間制限内に受信されたときは、プロセスは３０８で次のブロックに進む。
【０１２５】
応答には、サーバから送られてきたペアのパケットを使用してクライアントによって、３０４で判断されたバンド幅測定が含まれている。３０８で、サーバは、応答から特定のバンド幅を抽出する。
【０１２６】
図９の３１０で、サーバは、特定のバンド幅に等しいか、それ以下のバンド幅用にフォーマットされたファイル（またはその一部）を選択する。３１２で、サーバはそのファイル（またはその一部）をクライアントに送信する。
【０１２７】
それがメディアファイルであれば、クライアントのユーザは、プレイが即時に開始されるメディアプレゼンテーションを楽しむことができる。プレイは、測定されたバンド幅で可能な限り最高品質でスムーズに行われる。プロセスは３１４で終了する。
【０１２８】
Ｎａｇｌｅ  アルゴリズムに対する対応策。図６は、Ｎａｇｌｅ  アルゴリズムに対する対応策として、例示のバンド幅メータを方法で実現した具体例を示す。４０２で、サーバは「ディレイディスエーブル」コマンドを送信し、Ｎａｇｌｅ  アルゴリズムの使用を禁止する。４０４で、サーバはペアのバンド幅測定パケットをクライアントに送信する。４０６で、プロセスは図５のブロック３０６に戻る。
【０１２９】
プロキシ遅延に対する対応策。図７は、プロキシ遅延に対する対応策として、例示のバンド幅メータを方法で実現した具体例を示す。４１２で、サーバはペアのバンド幅測定パケットをクライアントに送信する。４１４で、サーバは「プッシュ」パケットを送信し、通信デバイスによってパケットがストアされている可能性のあるバッファからペアを押し出す。４１６で、プロセスは図５のブロック３０６に戻る。
【０１３０】
Ｓｌｏｗ  Ｓｔａｒｔ  アルゴリズムに対する対応策。図８は、Ｓｌｏｗ  Ｓｔａｒｔ  アルゴリズムに対する対応策として、例示のバンド幅メータを方法で実現した具体例を示す。４２２で、サーバは「プライミング」パケットを送信し、Ｓｌｏｗ  Ｓｔａｒｔ  アルゴリズムを解消する。
【０１３１】
この「プライミング」パケットはバンド幅測定には使用されない。このパケットはネットワークをオープンさせ（つまり、輻輳ウィンドウをオープンさせる）、同時に２つのパケットを遅延なしで可能にする。４２４で、サーバはペアのバンド幅測定パケットをクライアントに送信する。４２６で、プロセスは図５のブロック３０６に戻る。
【０１３２】
その他の実装の詳細
実装アプリケーション。例示のバンド幅メータは、ネットワーク上の２エンティティ間のバンド幅を高速に測定することを望んでいるエンティティによって実装させることが可能である。具体的には、ネットワークは、インターネットなどのＴＣＰネットワークである。
【０１３３】
そのようなエンティティは、この例示のバンド幅メータをアプリケーション層に実装することができる。この例示のバンド幅メータを実装できるアプリケーションレベルのプログラムモジュールの例としては、サーバ側に置かれていて、Ｍｉｃｒｏｓｏｆｔ  Ｍｅｄｉａ  Ｓｅｒｖｅｒ  （ＭＭＳ）  プロトコルまたはＲｅａｌ  Ｔｉｍｅ  Ｓｔｒｅａｍｉｎｇ  Ｐｒｏｔｏｃｏｌ  （ＲＴＳＰ）  のどちらかを使用するストリーミングメディアサーバアプリケーションがある。
【０１３４】
ＭＭＳとＲＴＳＰのどちらも、非常に類似した基本的手法を共有し、例示のバンド幅メータを使用して正常な測定を行うための条件を示している。しかし、ＲＴＳＰを使用した例示のバンド幅メータの実装は、ＭＭＳプロトコルを使用した実装よりも扱いづらくなっている。
【０１３５】
ＲＴＳＰパケットペアの構文。ＲＴＳＰをＭＭＳよりも扱いづらくしている１つは、３つのパケットをＲＴＳＰコマンドに対する応答であるかのように見せて、クライアントのＲＴＳＰパーサがそれらのパケットを処理できるようにする必要があるからである。ＲＴＳＰ  ＧＥＴ＿ＰＡＲＡＭＥＴＥＲコマンドは、パケットペアの実験を要求するために使用される。応答の第１パケットの先頭には、代表的なＲＴＳＰ応答ヘッダが置かれている。
【０１３６】
次に示したものは、クライアントからのパケットペア要求のヘッダの例である。
【０１３７】
【数３】
0004806141.tif 000004
【０１３８】
次に示したものは、サーバからのパケットペア応答のヘッダの例である。
【０１３９】
【数４】
0004806141.tif 000005
【０１４０】
ＴＣＰの問題。前述したように、輻輳ウィンドウは、少なくとも３パケットがサーバから送られてくる時点までにその３パケットのためにオープンしている必要がある。初期輻輳ウィンドウは２であるので、３またはそれ以上のパケットのためにウィンドウをオープンするためにはＤＥＳＣＲＩＢＥ応答が使用される。ＤＥＳＣＲＩＢＥ応答が３パケットを要求していれば、これは、３番目のパケットはクライアントからのＡＣＫを待ってからでなければ送信できないことを意味する。
【０１４１】
サーバのＴＣＰが最初の２パケットの一方または両方のＡＣＫを待っている間に、ＧＥＴ＿ＰＡＲＡＭＥＴＥＲが到着し、アプリケーションがＧＥＴ＿ＰＡＲＡＭＥＴＥＲに対する応答をソケットに書くことを始めたときは、パケットペアのパケットはＤＥＳＣＲＩＢＥ応答の３番目である最終パケットと結合され、相互に結合されることになる。従って、クライアントは、ＤＥＳＣＲＩＢＥ応答が完全な形で受信されるまではＧＥＴ＿ＰＡＲＡＭＥＴＥＲを送信してはならない。
【０１４２】
このようにすると、パケットペアのパケットが送信されるとき輻輳ウィンドウがサーバ側でオープンすることが保証される。その結果、どのパケットも結合されることはない。ＤＥＳＣＲＩＢＥ応答は１またはそれ以上のパケットのことがあるので、輻輳ウィンドウは、パケットペアの実行時に３またはそれ以上になる。パケットペアの前に他のトラッフィクが行われることがないことは、もちろんである。
【０１４３】
到着時間の測定。（アプリケーションレベルで）例示のバンド幅メータのパケットペア測定を実行するということは、クライアントアプリケーションが２パケットの到着時間を測定することを意味している。ＲＴＳＰでは、正確な測定のために要求される細粒性に比べて応答ヘッダはその処理に時間がかかるため、これは余計な難題になっている。従って、クライアントは、応答の処理が終わるのを待ってからでなければ、パケットペアの第１パケットがタイムスタンプされる前にそれがパケットペア要求に対する応答であることを知ることができない。
【０１４４】
このタイムスタンプは、クライアントがどのタイプの応答であるかを知る前に行われていなければならない。従って、クライアントがパケットペア要求を行うとき、着信するすべてのコマンド応答はパケットペアの受信前にタイムスタンプされる。そのあと、このプレタイムスタンプモード  （ｐｒｅ−ｔｉｍｅｓｔａｍｐ  ｍｏｄｅ）  から出ることになる。
【０１４５】
このモードから出ても、クライアントは、第１パケットのヘッダを処理してからでなければ第２パケットを読み取ることができない。従って、ボトルネックをどの高さまで測定できるかには上限があり、これは、クライアントがＲＴＳＰ応答ヘッダをどれだけ高速に処理できるかによって決まる。例えば、ヘッダを処理するのに要する時間が５ｍｓであれば、測定できる最大速度は８００  ｋｂ／ｓ前後である。従って、ハイエンドにおけるＲＴＳＰ測定は、ＲＴＳＰ応答をパース（ｐａｒｓｅ：構文解析）するのに要する時間が低くなければ、ＭＭＳほどには良好にならない。
【０１４６】
例示のコンピューティング環境
図９は、例示のバンド幅メータを実現するのに適しているコンピューティング環境９２０の例を示す。
【０１４７】
例示のコンピューティング環境９２０は、適したコンピューティング環境の一例にすぎず、例示のバンド幅メータが使用される範囲または機能する範囲が限定されることを意味するものではない。また、コンピューティング環境９２０は、例示のコンピューティング環境９２０に図示のコンポーネントまたはその組み合わせに関して依存性または要求条件があるものと解釈してはならない。
【０１４８】
例示のバンド幅メータは、他の多数の汎用または専用コンピューティングシステム環境または構成で動作可能になっている。例示のバンド幅メータで使用するのに適している周知のコンピューティングシステム、環境、および／または構成の例としては、パーソナルコンピュータ、サーバコンピュータ、シンクライアント  （ｔｈｉｎ  ｃｌｉｅｎｔ）、シッククライアント  （ｔｈｉｃｋ  ｃｌｉｅｎｔ）、ハンドヘルドまたはラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサベースシステム、セットトップボックス  （ｓｅｔ  ｔｏｐ  ｂｏｘ）、プログラマブルコンシューマエレクトロニクス、ワイヤレス電話、ワイヤレス通信デバイス、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上述したシステムまたはデバイスのいずれかを含んでいる分散コンピューティング環境、などがあるが、これらに限定されるものではない。
【０１４９】
例示のバンド幅メータは、プログラムモジュールのように、コンピュータによって実行されるコンピュータ実行可能命令という広い意味でとらえて説明することもできる。一般的に、プログラムモジュールには、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などがあり、これらは特定のタスクを実行し、あるいは特定の抽象データ型を実装している。例示のバンド幅メータは、通信ネットワークを通してリンクされているリモート処理デバイスによってタスクが実行されるような分散コンピューティング環境で実施することも可能である。分散コンピューティング環境では、プログラムモジュールは、メモリストレージデバイスを含む、ローカルとリモートの両方のコンピュータ記憶媒体に置いておくことができる。
【０１５０】
図９に示すように、コンピューティング環境９２０は、汎用コンピューティングデバイスをコンピュータ９３０の形で含んでいる。コンピュータ９２０のコンポーネントとしては、１または２以上のプロセッサまたは処理ユニット９３２、システムメモリ９３４、およびシステムメモリ９３４を含む、種々のシステムコンポーネントをプロセッサ９３２に結合するバス９３６があるが、これらに限定されるものではない。
【０１５１】
バス９３６は、数種タイプのバス構造のいずれかの１つまたは２つ以上を表しているが、そのようなものとしては、メモリバスまたはメモリコントローラ、ペリフェラルバス、高速グラフィックスバス、およびプロセッサまたはローカルバスがあり、これらは種々バスアーキテクチャのどれかを採用している。そのようなアーキテクチャの例をいくつか挙げると、ＩＳＡ（Ｉｎｄｕｓｔｒｙ  Ｓｔａｎｄａｒｄ  Ａｒｃｈｉｔｅｃｔｕｒｅ：業界標準アーキテクチャ）バス、ＭＣＡ（Ｍｉｃｒｏ  Ｃｈａｎｎｅｌ  Ａｒｃｈｉｔｅｃｔｕｒｅ：マイクロチャネルアーキテクチャ）バス、ＥＩＳＡ（Ｅｎｈａｎｃｅｄ  ＩＳＡ：拡張ＩＳＡ）バス、ＶＥＳＡ（Ｖｉｄｅｏ  Ｅｌｅｃｔｒｏｎｉｃｓ  Ｓｔａｎｄａｒｄｓ  Ａｓｓｏｃｉａｔｉｏｎ）  ローカルバス、およびＭｅｚｚａｎｉｎｅバスとしても知られているＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ  Ｃｏｍｐｏｎｅｎｔ  Ｉｎｔｅｒｃｏｎｎｅｃｔｓ：ペリフェラルコンポーネント相互接続）バスがあるが、これらに限定されない。
【０１５２】
コンピュータ９３０は、種々のコンピュータ読取可能媒体を装備しているのが代表的である。そのような媒体としては、コンピュータ９３０によってアクセス可能ならば、どの利用可能な媒体にすることも可能であり、その中には、揮発性媒体と不揮発性媒体、取り外し可能媒体と取り外し不能（固定）媒体が含まれている。
【０１５３】
図９に示すように、システムメモリに装備されているコンピュータ読取可能媒体は、ランダムアクセスメモリ  （ｒａｎｄｏｍ  ａｃｃｅｓｓ  ｍｅｍｏｒｙＲＡＭ）９４０などの揮発性、および／またはリードオンリメモリ  （ｒｅａｄ  ｏｎｌｙ  ｍｅｍｏｒｙ    ＲＯＭ）９３８などの不揮発性の形体になっている。スタートアップ時のときのように、コンピュータ９３０内のエレメント間で情報を転送するのを支援する基本ルーチンからなる、基本入出力システム  （ｂａｓｉｃ  ｉｎｐｕｔ／ｏｕｔｐｕｔ  ｓｙｓｔｅｍ）  ９４２は、ＲＯＭ９３８に格納されている。ＲＡＭ  ９４０は、プロセッサ９３２によって即時にアクセス可能である、および／または現在操作可能であるデータおよび／またはプログラムモジュールを格納しているのが代表的である。
【０１５４】
コンピュータ９３０は、さらに、他の取り外し可能／取り外し不能、揮発性／不揮発性コンピュータ記憶媒体を装備することも可能である。図９には、取り外し不能、不揮発性磁気媒体との間で読み書きするハードディスクドライブ９４４（これは、図には示されていないが、「ハードドライブ」とも呼ばれている）、取り外し可能、不揮発性磁気ディスク９４８（例えば、「フロッピディスク」）との間で読み書きする磁気ディスクドライブ９４６、およびＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、その他の光媒体などの取り外し可能、不揮発性光ディスク９５２との間で読み書きする光ディスクドライブ９５０が示されているが、これらは一例にすぎない。ハードディスクドライブ９４４、磁気ディスクドライブ９４６、および光ディスクドライブ９５０は、それぞれ１または２以上のインタフェースを通してバス９３６に接続されている。
【０１５５】
これらのドライブおよびその関連コンピュータ読取可能媒体は、コンピュータ読取可能命令、データ構造、プログラムモジュール、および他のデータを、コンピュータ９３０のために永続的（不揮発性）に保存している。ここで説明している例示の環境は、ハードディスク、取り外し可能磁気ディスク９４８および取り外し可能光ディスク９５２を採用しているが、この分野の精通者ならば当然に理解されるように、コンピュータがアクセスできるデータを、他のタイプのコンピュータ読取可能媒体に保管しておくことも可能である。そのようなものとしては、磁気カセット、フラッシュメモリカード、デジタルビデオディスク、ランダムアクセスメモリ  （ＲＡＭ）、リードオンリメモリ  （ＲＯＭ）などがあり、これらも例示の動作環境で使用することができる。
【０１５６】
いくつかのプログラムモジュールを、ハードディスク、磁気ディスク９４８、光ディスク９５２、ＲＯＭ  ９３８またはＲＡＭ  ９４０に格納しておくことも可能であり、そのようなものの例としては、オペレーティングシステム９５８、１または２以上のアプリケーションプログラム９６０、他のプログラムモジュール９６２、およびプログラムデータ９６４があるが、これらに限定されない。
【０１５７】
ユーザは、キーボード９６６やポインティングデバイス９６８（「マウス」など）などの入力デバイスを通してコマンドおよび情報をコンピュータ９３０に入力することができる。その他の入力デバイス（図示せず）としては、マイクロホン、ジョイスティック、ゲームパッド、サテライトディッシュ、シリアルポート、スキャナなどがある。上記および他の入力デバイスは、バス９３６に結合されたユーザ入力インタフェース９７０を通して処理ユニット９３２に接続されているが、パラレルポート、ゲームポート、ユニバーサルシリアルバス  （ｕｎｉｖｅｒｓａｌ  ｓｅｒｉａｌ  ｂｕｓ  −  ＵＳＢ）  などの、他のインタフェースおよびバス構造で接続することも可能である。
【０１５８】
モニタ９７２や他のタイプのディスプレイデバイスも、ビデオアダプタ９７４などのインタフェースを通してバス９３６に接続されている。モニタのほかに、パーソナルコンピュータは、スピーカやプインタなどの他の周辺出力デバイス（図せず）を装備しているのが代表的であり、これらは出力周辺インタフェース９７５を通して接続可能になっている。
【０１５９】
コンピュータ９３０は、リモートコンピュータ９８２などの、１または２以上のリモートコンピュータとの論理的コネクションを使用したネットワーキング環境で動作させることができる。リモートコンピュータ９８２は、コンピュータ９３０に関連して上述したエレメントと特徴の多くまたはすべてを具備することができる。
【０１６０】
図９に示す論理的コネクションとは、ローカルエリアネットワーク  （ｌｏｃａｌ  ａｒｅａ  ｎｅｔｗｏｒｋ    ＬＡＮ）  ９７７と一般的な広域ネットワーク  （ｗｉｄｅ  ａｒｅａ  ｎｅｔｗｏｒｋ    ＷＡＮ）  ９７９である。このようなネットワーキング環境は、オフィス、企業内コンピュータネットワーク、イントラネット、およびインターネット  （ｔｈｅ  Ｉｎｔｅｒｎｅｔ）  で普及されている。
【０１６１】
ＬＡＮネットワーキング環境で使用されるときは、コンピュータ９３０はＬＡＮ９７７のネットワークインタフェースまたはアダプタ９８６に接続されている。ＷＡＮネットワーキング環境で使用されるときは、コンピュータは、ＷＡＮ９７９上のコミュニケーションを確立するためのモデム９７８または他の手段を装備しているのが代表的である。モデム９７８は内蔵されているものと、外付けのものとがあるが、どちらも、ユーザ入力インタフェース９７０または他の該当メカニズムを通してシステムバス９３６に接続可能になっている。
【０１６２】
図９に示したのは、インターネットを通したＷＡＮの構築例である。インターネット上では、コンピュータ９３０は、インターネット９８０上のコミュニケーションを確立するためのモデム９７８または他の手段を装備しているのが代表的である。モデム９７８は内蔵されているものと、外付けのものとがあるが、どちらも、インタフェース９７０を通してバス９３６に接続されている。
【０１６３】
ネットワーキング環境では、パーソナルコンピュータ９３０に関連して示されているプログラムモジュールまたはその一部は、リモートのメモリストレージデバイスに格納しておくことができる。一例として、図９に示されているリモートアプリケーションプログラムは、リモートコンピュータ９８２のメモリデバイスに置かれているが、これに限定されない。理解されるように、図示し、上述してきたネットワークコネクションは例示であり、コンピュータ間の通信リンクを確立する他の手段を使用することも可能である。
【０１６４】
例示の動作環境
図９は、例示のバンド幅メータを実現するのに適している動作環境９２０の例を示す。具体的には、例示のバンド幅メータは、図９では、任意のプログラム９６０−９６２またはオペレーティングシステム９５８によって実現されている。
【０１６５】
この動作環境は、適している動作環境の一例にすぎず、ここで説明されているバンド幅メータが使用される範囲または機能する範囲が限定されることを意味するものではない。バンド幅メータで使用するのに適している、他の周知のコンピューティングシステム、環境、および／または構成としては、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドまたはラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサベースシステム、プログラマブルコンシューマエレクトロニクス、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記システムまたはデバイスを含んでいる分散コンピューティング環境などがあるが、これらに限定されない。
【０１６６】
コンピュータ実行可能命令
例示のバンド幅メータの実装は、プログラムモジュールのように、１または２以上のコンピュータまたは他のデバイスによって実行されるコンピュータ実行可能命令を広い意味でとらえて説明することができる。一般的に、プログラムモジュールとしては、特定のタスクを実行する、または特定の抽象データ型を実装しているルーチン、プログラム、オブジェクト、コンポーネント、データ構造などがある。代表例として、プログラムモジュールの機能は、種々の実施形態において必要に応じて結合し、あるいは分散化することができる。
【０１６７】
コンピュータ読取可能媒体
例示のバンド幅メータの実装は、ある種のコンピュータ読取可能媒体に保管しておくことも、媒体間で受け渡しすることも可能である。コンピュータ読取可能媒体は、コンピュータによってアクセス可能であれば、どのような利用可能な媒体にもすることができる。例を挙げると、コンピュータ読取可能媒体としては、コンピュータ記憶媒体と通信媒体があるが、これに限定されない。
【０１６８】
コンピュータ読取可能媒体には、コンピュータ読取可能命令、データ構造、プログラムモジュール、他のデータなどの情報を格納するためにいずれかの方法またはテクノロジで実現された揮発性と不揮発性、取り外し可能と取り外し不能媒体がある。コンピュータ記憶媒体としては、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリや他のメモリテクノロジ、ＣＤ−ＲＯＭ、デジタルバーサタイルディスク  （ｄｉｇｉｔａｌ  ｖｅｒｓａｔｉｌｅ  ｄｉｓｋ    ＤＶＤ）や他の光ストレージ、磁気カセット、磁気テープ、磁気ディスクストレージや他の磁気ストレージデバイス、または必要とする情報を保管しておくために使用でき、コンピュータによってアクセス可能な他の媒体があるが、これらに限定されない。
【０１６９】
通信媒体は、コンピュータ読取可能命令、データ構造、プログラムモジュール、あるいは他のデータを、搬送波などの変調データ信号または他のトランスポートメカニズムの形で具現化しているのが代表的であり、その中には、情報配達媒体が含まれている。ここで「変調データ信号（ｍｏｄｕｌａｔｅｄ  ｄａｔａ  ｓｉｇｎａｌ）」とは、その特性１つまたは２つ以上が、信号の中の情報を符号化（エンコード）するような形でセットまたは変更されている信号のことである。例を挙げると、通信媒体には、ワイヤドネットワークや直接ワイヤドコネクションなどのワイヤド媒体、音響、ＲＦ、赤外線、その他のワイヤレス媒体のようなワイヤレス媒体があるが、これらに限定されない。上記を任意に組み合わせたものも、コンピュータ読取可能媒体の範囲に含まれている。
【０１７０】
結論
ＴＣＰネットワーク環境におけるバンド幅の高速動的測定を、構造上の特徴および／または方法で表したステップに特有の表現で説明してきたが、当然に理解されるように、請求項に明確化されている、ＴＣＰネットワーク環境におけるバンド幅の高速動的測定は、必ずしも上述した具体的特徴またはステップに限定されるものではない。むしろ、具体的特徴とステップは、請求項に記載の、ＴＣＰネットワーク環境におけるバンド幅の高速動的測定を実現する好適形態として開示されている。
【０１７１】
【発明の効果】
以上説明したように、本発明によれば、Ｎａｇｌｅ  アルゴリズムの適用を禁止すること、「プッシュ」パケットをパケットペアの直後に送信することによってパケットのバッファリングを最小限にすること、およびダミーパケットで初期化（プライミング）することによってＳｌｏｗ  Ｓｔａｒｔ  アルゴリズムを回避する。
【図面の簡単な説明】
【図１】代表的な公衆ネットワーキング環境（インターネットなど）およびサーバからクライアントに送信されるデータパケットのルーティングと遅延を示す図である。
【図２】Ｗｅｂページのカッタウェイ部分を示す図であり、このカッタウェイには、バンド幅を選択するためのメカニズムをユーザに提供するユーザインタフェースが示されている。また、そこには、バンド幅を判断するための従来の手法が示されている。
【図３】時間ドメインでグラフ化されたパケットペア（サーバからクライアントに送信される）を示す図である。
【図４】代表的な公衆ネットワーキング環境（インターネットなど）を示す図であり、そこには、バックツーバックで送信されるペアのパケットが示されている。
【図５】例示のバンド幅測定を方法で実現した例を示すフローチャートである。
【図６】図６は、例示のバンド幅測定の異なる側面を方法で実現した具体例の詳細を示すフローチャートである。
【図７】例示のバンド幅測定の異なる側面を方法で実現した具体例の詳細を示すフローチャートである。
【図８】例示のバンド幅測定の異なる側面を方法で実現した具体例の詳細を示すフローチャートである。
【図９】例示のバンド幅測定の実現を可能にするコンピューティング動作環境の例を示す図である。
【符号の説明】
２２０  メディアサーバ
２２２  サーバコンピュータ
２２４  データベース
２３０  インターネット
２３２−２４４  ルータ
２４６、２５０  サテライトディッシュ
２４８  サテライト
２６０、２６２  パケット
２８０  インターネットサービスプロバイダ  （ＩＳＰ）
２８２  リンク
２８４  プロキシサーバ
２９０、２９２  クライアント
【図１】
0004806141.tif 000006
【図２】
0004806141.tif 000007
【図３】
0004806141.tif 000008
【図４】
0004806141.tif 000009
【図５】
0004806141.tif 000010
【図６】
0004806141.tif 000011
【図７】
0004806141.tif 000012
【図８】
0004806141.tif 000013
【図９】
0004806141.tif 000014