JP4487793B2

JP4487793B2 - 通信ボトルネック判定装置および方法

Info

Publication number: JP4487793B2
Application number: JP2005037775A
Authority: JP
Inventors: 洋平長谷川
Original assignee: NEC Corp
Current assignee: NEC Corp
Priority date: 2005-02-15
Filing date: 2005-02-15
Publication date: 2010-06-23
Anticipated expiration: 2025-02-15
Also published as: JP2006229314A

Description

本発明は、クライアント／サーバ型の通信のようにネットワークを介して接続された装置間にて通信中の通信ボトルネックを判定する手法に関し、特に、コネクション型通信によるセッションにおいて前記判定を行う手法に関する。

従来、通信装置間にてコネクション型通信を行うにあたっては、その通信プロトコルに、例えば、RFC793（RFC：Request For Comment）により規定されているTCP（Transmission Control Protocol）が用いられる。TCPによるセッションの通信性能を判定する手法として、後述の特許文献１に記載のものがある。特許文献１に記載の手法は、送信端末及び受信端末となる通信端末の間に、ネットワークの通信遅延やパケットロス率等を計測する測定装置を挿入し、この測定装置が、TCPセッションにおけるトラヒックを観察することにより計測した各値を用いてTCPの理論スループットを算出する。そして、スループットの理論値と実測値とを比較し、実測値が理論値よりも低い場合に、通信性能が低下したと判定する方法である。
特許第３６０２９７２号

ところで、例えば動画像配信のセッションのように、端末側の送信制御によりパケットの伝播が間欠的となるセッションの場合、セッション中のスループット値が一時的に低下することがある。このようにパケットの送出が端末により意図的に中断される場合は、端末側が、スループット低下をもたらした通信ボトルネックとなるが、通信性能をスループット値により判定する特許文献１の手法を適用すると、上述のような状況が、一概に、ネットワークの通信性能の低下と判定される。そうすると、通信性能が低下した原因を解析する際、実際には端末が通信ボトルネックとなっているにも拘らず、通信ボトルネックの所在をネットワーク側にて探索するという不適正な処理を行うおそれがある。

本発明は、上記課題に鑑みてなされたものであり、コネクション型通信における通信ボトルネックの所在を効率よく特定するための通信ボトルネック判定装置及び方法を提供することを目的とする。

本発明に係る通信ボトルネック判定装置は、コネクション型通信によりデータを授受する送信装置および受信装置間に接続された通信ボトルネック判定装置であって、前記送信装置が出力した送信パケットから該送信パケットに含まれるデータを識別するためのシーケンス番号を記録し、且つ、前記受信装置が前記送信パケットの受信時に出力した応答パケットに設定されている広告ウィンドウサイズおよび前記送信装置へ要求すべきデータのシーケンス番号の加算値を該受信装置が受信可能なデータ範囲を示す受信許容量として記録する手段と、前記受信許容量から最新のシーケンス番号を減算した値を差分とし該差分が予め設定した閾値以下のとき前記受信装置が通信ボトルネックであると判定する手段とを備える。

本発明に係る通信ボトルネック判定方法は、コネクション型通信によりデータを授受する送信装置および受信装置間に接続された通信ボトルネック判定装置が、前記送信装置が出力した送信パケットから該送信パケットに含まれるデータを識別するためのシーケンス番号を記録し、前記受信装置が前記送信パケットの受信時に出力した応答パケットに設定されている広告ウィンドウサイズおよび前記送信装置へ要求すべきデータのシーケンス番号の加算値を該受信装置が受信可能なデータ範囲を示す受信許容量として記録し、該受信許容量から最新のシーケンス番号を減算した値を差分とし該差分が予め設定した閾値以下のとき前記受信装置が通信ボトルネックであると判定するという方法である。

本発明によれば、コネクション型通信によりデータを授受する送信装置および受信装置間に接続された通信ボトルネック判定装置により、受信装置が通信ボトルネックであるか否かを判定することから、セッション中のスループットが低下したとき、その要因となる通信ボトルネックの所在を効率よく特定することができる。

本発明の実施の形態について図面を参照して詳細に説明する。図１を参照すると、本発明の一実施の形態は、LAN、WANあるいはインターネットのようなネットワーク１００を介して送信装置２００と受信装置３００とが接続されたシステムにおいて、本発明に係る通信ボトルネック判定装置としての判定装置４００を送信装置２００とネットワーク１００との間に配備した構成を持つ。図示の例では、送信装置２００と判定装置４００とが直結されているが、両者が通信可能に接続されていれば、両者間に任意のネットワークが介在していてもよい。

本実施形態の送信装置２００は、ネットワーク１００を介して各種のサービス情報となるデータを提供するサーバ装置としてのコンピュータであり、また、受信装置３００は、送信装置２００が提供するデータを取得するクライアント装置としてのコンピュータである。送信装置２００及び受信装置３００は、従来知られたTCPを使用したコネクション型通信によりデータを授受する。

TCPセッションでは、従来知られているように、データを含む送信パケットを受信した装置が、送信側に対し、応答パケットであるACKパケットを送信する。これにより、受信側にて送信パケットを受信した旨が送信側へ通知される。送信パケットのヘッダには、このパケットに含まれるデータを識別するためのシーケンス番号が記述されている。シーケンス番号は、送信側にて分割されたデータブロックの相対的な位置を示すために、予め各ブロックに対し連続的な番号にて付与されるものである。一方、受信側から出力されるACKパケットのヘッダには、何れの送信パケットに対する受信確認であるかを識別するためのACK番号、及び、その時点で受信可能なデータ量を示す広告ウィンドウのウィンドウサイズ等が含まれる。ACK番号としては、既に受信したデータに引き続いて受信すべきデータのシーケンス番号が設定される。

判定装置４００は、送信装置２００と受信装置３００との間で確立されたTCPセッションにおいて送受信されるパケットを監視する。図２に、判定装置４００の構成を示す。判定装置４００は、ネットワーク処理部４１０と、計測部４２０と、判定部４３０とを備える。

ネットワーク処理部４１０は、送信装置２００とネットワーク１００との間でやりとりされるパケットの中継機能、及び、判定部４３０から指定されたセッション上のパケットを検知し計測部４２０に出力する機能を有する。図３に、ネットワーク処理部４１０の構成を示す。ネットワーク処理部４１０は、送受信部４１０１及び送受信部４１０２と、設定メモリ４１０３と、パケット検知部４１０４とを有する。

送受信部４１０１は、送信装置２００に対しパケットを送受信し、また、送受信部４１０２は、ネットワーク１００を介して受信装置３００に対しパケットを送受信する機能を果たす。送受信部４１０１は、送信装置２００から受信装置３００宛てのパケットを受信すると、これを、送受信部４１０２を介してネットワーク１００へ転送すると同時に、そのコピーをパケット検知部４１０４へ供給する。また、送受信部４１０２が受信装置３００から送信装置２００に宛てたパケットを受信したとき、これを、送受信部４１０１を介して送信装置２００へ転送すると同時に、そのコピーをパケット検知部４１０４へ供給する。

設定メモリ４１０３は、監視対象となるセッションを特定するための情報を判定部４３０から取得して保持する。この情報としては、ネットワーク上のセッションを一意に識別可能なものを採用し、例えば、本実施形態のようなTCP/IPの場合、IPアドレスおよびポート番号の組み合わせを用いる。パケット検知部４１０４は、送受信部４１０１または送受信部４１０２が受けたパケットが設定メモリ４１０３に設定されたセッション上のものかどうかを判定し、そのセッション上のパケットのみを計測部４２０へ送出する。

計測部４２０は、読み書き可能な記憶部４２１と、TB計算部４２２とを備える。TB計算部４２２は、ネットワーク処理部４１０が送信装置２００からの送信パケットを受けたとき、このパケットに記述されているシーケンス番号を記憶部４２１に記録し、受信装置３００からのACKパケットを受けたとき、このパケットのACK番号およびウィンドウサイズを記録する。また、計測部４２０は、記録したACK番号とウィンドウサイズとを加算することにより、受信装置３００における受信許容量を示すAW値を求め、さらに、求めたAW値と、記憶部４２１における最新のシーケンス番号との差分をTB値として求め、これらを記憶部４２１に格納する。

図４は、記憶部４２１の記憶内容を示す。記憶部４２１は、ネットワーク処理部４１０から供給されるパケットを保存するパケット保存領域４２１１と、計測部４２０による上述の記録内容および後述する判定部４３０による判定結果を保存する判定情報保存領域４２１２とを有する。なお、パケット保存領域４２１１へ保存するパケットは、必ずしもパケット全体のコピーをである必要はなく、ヘッダなど、パケットの一部分のコピーであってもよい。

判定部４３０は、記憶部４２１に格納されたTB値に基づき、受信装置３００が通信ボトルネックとなっているか否かを判定する。受信装置３００が通信ボトルネックとなる状況とは、その時点において実現可能とされるスループットに対し、ACKパケットにより通知された広告ウィンドウのサイズが十分でない状況を指し、具体的には、受信装置３００が決定した広告ウィンドウサイズがその理想的な値よりも小さいことを意味する。ウィンドウサイズの理想値は、従来知られているように、ネットワーク１００の通信遅延時間と回線帯域とから求められる。

なお、受信装置３００にて広告ウィンドウサイズが理想値よりも小さく設定される原因としては、例えば、受信装置３００が高負荷状態あるいは装置の性能自体が比較的低いものであるために、処理速度を維持することができず、ウィンドウを縮小させたことが考えられる。また、他の原因として、広告ウィンドウのサイズを理想値に対し意図的に低くするよう設定したことが考えられる。

図５及び図６は、計測部４２０及び判定部４３０の処理手順を示すフローチャートである。まず、図５に示すフローチャートに沿って計測部４２０の処理手順を説明すると、計測部４２０は、ネットワーク処理部４１０からパケットを受信したとき、そのパケットを記憶部４２１に格納する(ステップＳ１)。そして、格納したパケットを参照し、それが送信装置２００からの送信パケットであるのか、あるいは受信装置３００からのACKパケットであるのかを判定する(ステップＳ２)。

TB計算部４２２は、記憶部４２１へ格納されたパケットが送信装置２００からの送信パケットであった場合には、パケットに設定されているシーケンス番号を記憶部４２１へ記録する (ステップＳ３)。また、格納されたパケットが受信装置３００からのACKパケットであった場合には、パケットに設定されているACK番号及び広告ウィンドウサイズを参照し、それらを足し合わせることでAW値を算出して記録する（ステップＳ４）。さらに、記録したAW値および最新のシーケンス番号の差分をTB値として求め、これを記憶部４２１へ記録し（ステップＳ５）、TB値を記録した旨を判定部４３０へ通知する（ステップＳ６）。

次に、判定部４３０の処理手順を図６のフローチャートに沿って説明する。判定部４３０は、TB計算部４２２からTB値の記録通知を受けると、記録されたTB値を参照し、その値が予め設定されている閾値よりも低下しているか否かを判定する（ステップＳ１１）。TB値が閾値よりも低下している場合は、受信装置３００が通信ボトルネックになっていると判定する (ステップＳ１２)。また、TB値が閾値よりも高い場合は、通信ボトルネックの発生は無いと判定する(ステップＳ１３)。そして、判定の結果を示す結果フラグ値を出力し記憶部４２１へ保存する（ステップＳ１４）。

＜具体例１＞
ここで、上述した本実施形態の動作手順について、具体例を用いて詳細に説明する。図７は、TCPセッション開設後に、送信装置２００にて１０００バイト単位でシーケンス番号（Seq）を付されたデータブロックが、シーケンス番号（Seq）「11000」から順次、受信装置３００へ配信される様子を示したシーケンス図である。また、図８は、送信装置２００又は受信装置３００から出力されるパケットが判定装置４００を通過する時点を計測タイミングとし、各タイミングにおいて判定装置４００が記憶部４２１の判定情報保存領域４２１２に記録する情報を一覧にしたものである。

図８に示す例は、判定部４３０が用いる閾値としてTB値「1000」を設定した例であり、記録されたTB値が「1000」を超える場合は、受信装置３００が通信ボトルネックになっていないことを示す結果フラグ「0」が記録され、また、「1000」以下であれば、通信ボトルネックの発生を示す結果フラグ「1」が記録される。

まず、判定装置４００は、送信装置２００からシーケンス番号「Seq：11000」、「Seq：12000」、「Seq：13000」及び「Seq：14000」のデータを含む各送信パケットが順次到着するごとに（t1〜t4）、それらのシーケンス番号を記録する。

図７に示すように、受信装置３００が、前述の「Seq：12000」の送信パケットを受信後、ACK番号「13000」及び広告ウィンドウサイズ「6000」を記述したACKパケットを出力し、このACKパケットが判定装置４００に到着すると（t5）、計測部４２０は、ACK番号「13000」及び広告ウィンドウサイズ「6000」の加算値「19000」をAW値として記録する。そして、このAW値「19000」と最新のシーケンス番号との差分をTB値として記録する。ここでは、図８に示すように、計測タイミング「t5」における最新のシーケンス番号は「14000」であることから、TB値としては、AW値「19000」から「14000」を差し引いた「5000」が記録される。

判定部４３０は、記録されたTB値「5000」を、予め設定されている閾値「1000」と比較し、その比較結果を示す結果フラグを出力する。ここでは、記録されたTB値「5000」が閾値「1000」を超えることから、図８に示すように、受信装置３００が通信ボトルネックになっていないことを示す「0」が記録される。

その後、送信装置２００から判定装置４００に「Seq：15000」の送信パケットが到着すると（t6）、計測部４２０がそのシーケンス番号「15000」を用いてTB値を算出し、判定部４３０が通信ボトルネックの判定を行う。具体的には、図８に示すように、この時点（t6）で有効なAW値「19000」から、今回得たシーケンス番号「15000」を差し引いた値「4000」をTB値とし、このTB値「4000」と閾値「1000」との比較結果を記録する。ここでは、TB値が閾値を超えることから、結果フラグとして再び「0」が記録される。

続いて、送信装置２００から判定装置４００に「Seq：16000」の送信パケットが到着すると（t7）、そのシーケンス番号「16000」を用いて、上記手順と同様にしてTB値を算出し、算出したTB値「3000」を閾値と比較する。その結果、結果フラグ値「0」が記録される。

以降、判定装置４００が、送信装置２００からの送信パケットまたは受信装置３００からのACKパケットを受けるごとに（t8〜t11）、上述の手順と同様にして通信ボトルネックの判定を行うことにより、図８に示すような一連の判定結果が得られる。図示の結果から分かるように、上述の具体例における計測タイミング「t1」〜「t11」では、結果フラグ値が全て「0」であることから、この期間においてTCPセッションのスループットが低下していたとしても、それをもたらした通信ボトルネックは、少なくとも受信装置３００ではないと判断することができる。

＜具体例２＞
以下に説明する具体例では、図９のシーケンス図および図１０の一覧を用いて、受信装置３００が通信ボトルネックと判定される事例を説明する。なお、図１０に示す一覧を構成する項目、及び、判定部４３０に設定される閾値は、図８のものと同様であり説明を省略する。

送信装置２００から出力された「Seq：11000」の送信パケットが判定装置４００を通過し（t21）、その後、この送信パケットに対するACKパケットが判定装置４００に到着すると（t22）、計測部４２０は、図１０に示すように、受信したACKパケットのACK番号「12000」とウィンドウサイズ「2000」との加算値「14000」をAW値として記録し、このAW値「14000」から最新のシーケンス番号「11000」を差し引いた値「3000」をTB値として記録する。判定部４３０は、記録されたTB値「3000」を閾値「1000」と比較し、結果フラグ値を出力する。ここでは、記録されたTB値が閾値を超えることから、受信装置３００が通信ボトルネックとなっていないことを示す「0」が記録される。

その後、送信装置２００から「Seq：12000」の送信パケットが判定装置４００へ到着すると（t23）、計測部４２０が、そのシーケンス番号「12000」とAW値「14000」とを用いてTB値「2000」を算出し、判定部４３０が閾値「1000」との比較により結果フラグ値として「0」を出力する。

続いて、送信装置２００から「Seq：13000」の送信パケットが判定装置４００に到着したとき（t24）、計測部４２０は、上述の手順と同様にして算出したTB値「1000」を記録する。ここで、判定部４３０は、記録されたTB値が、閾値であるTB値「1000」以下であるとの判定のもとに、図１０に示すように、受信装置３００が通信ボトルネックになっていることを示す結果フラグ値「1」を出力する。

その後、前述の「Seq：13000」の送信パケットに対する受信装置３００からのACKパケットが判定装置４００に到着すると（t25）、計測部４２０は、このACKパケットに基づき算出したAW値「16000」を用いてTB値「3000」を算出して記録する。判定部４３０は、記録されたTB値「3000」と閾値「1000」との比較により通信ボトルネック発生は無いと判断し、結果フラグ値「0」を出力する。

以降、同様にして判定装置４００が通信ボトルネックの判定を行うことにより、図１０に示すような一連の判定結果が得られる。図示の結果では、計測タイミング「t24」及び「t27」にて、結果フラグ値にそれぞれ「1」が記録されていることから、これらのタイミングにてTCPセッションのスループットが低下していたのであれば、それをもたらした通信ボトルネックが受信装置３００であると特定することができる。

また、図１０に示す例のように、通信ボトルネックの発生を示す結果フラグ値「1」の出現が一時的なものである場合、上記通信ボトルネックが比較的軽度である、あるいは送信制御による間欠的なパケット送信に起因するものであると推測し、また、仮に、結果フラグ値「1」が所定期間連続的に出現した場合は、受信装置３００に対し早急な対処を要する事態であると推測するというように、結果フラグ値「1」の出現頻度に応じて、受信装置３００の状況を推測することができる。

判定部４３０が通信ボトルネックの判定に用いる閾値は、その値を高く設定するほど判定の感度が高められ、また、低く設定するほど判定の感度が緩められる。よって、判定装置４００に与える監視レベルに応じて閾値を適宜設定することが望ましい。例えば、受信装置３００の処理能力やウィンドウサイズに比較的余裕があり、受信装置３００が通信ボトルネックとなる可能性が低いと予め推測される場合は、「0」のように極力低い閾値を設定することにより、通信ボトルネック発生に対する過剰反応を避けることができる。また、このような低い値を閾値に設定した状況において通信ボトルネック発生と判定されたのであれば、それが一時的なものであっても、早急に対処が必要な事態であると推測することができる。

なお、判定部４３０が通信ボトルネックの判定に用いる閾値は、予め管理者が決定した固定値を採用する他に、次の方法により算出した値を採用することができる。その一つは、帯域遅延積を閾値とする方法である。ここで言う帯域遅延積とは、判定装置４００に対し、送信装置２００からの送信パケットが到着してから、この送信パケットに対する受信装置３００からのACKパケットが到着するまでの期間に通過したデータ量を指す。例えば、判定装置４００にて「Seq：1000」の送信パケットが通過してから、そのACKパケットが帰ってくるまでの間に、「Seq：2000」及び「Seq：3000」の送信パケットが通過した場合、帯域遅延積は、これらのデータの総量である「3000」となる。帯域遅延積は、判定装置４００及び受信装置３００間のパケット往復時間、すなわち送信パケットの到着から当該ACKパケットの到着までの期間と、その期間のスループット値との積により求めることができる。

また、閾値を決定する他の方法として、TB値の最大値を用いる方法がある。これは、TB値の最大値を、TB値の算出ごとに検出、あるいは定期的に検出して保持しておき、この最大値に対し、「90％」や「50％」のような所定の比率を持つ値を閾値とするというものである。特に、閾値が最大値に近い値となる比率を採用することにより、判定の感度として比較的高い感度を維持することができる。

以上説明した本実施形態によれば、TCPセッションを行う送信装置２００及び受信装置３００間に接続された判定装置４００により、受信装置３００が通信ボトルネックであるか否かを判定することから、この通信ボトルネック発生との判定結果が出たタイミングと、セッション中のスループットが低下したタイミングとが対応する場合、スループット低下をもたらした通信ボトルネックが受信装置３００にあると特定することができる。これにより、例えば、受信装置３００の広告ウィンドウサイズが十分でないことが要因となってスループットが低下した状況に対し、ネットワーク１００の何れかの回線に通信ボトルネックが存在するとの誤った判断が下されることを回避できる。

一般的に、TCPセッションのスループットを改善するためには、広告ウィンドウサイズを拡大させることが最も効果が高いと考えられている。よって、判定装置４００による判定結果を用いることにより、速やかにスループットの改善を図ることができる。また、判定装置４００により得られる判定結果を、セッションの通信性能を解析する他の装置に供給することにより、この装置における解析処理に寄与することができる。

さらに、本実施形態によれば、判定装置４００により上記判定を行うにあたり、送信パケットのシーケンス番号やACKパケットのACK番号及びウィンドウサイズといった、TCPにて規定されている既存の情報を利用することから、送信装置２００及び受信装置３００間で送受信するパケットに、TCPで規定されていない特別な情報を付加する必要がない。よって、上記判定を簡便に実施することができる。

図１に示す実施形態の構成は、判定装置４００が送信装置２００に外部接続されたものであるが、これに代えて、送信装置２００と一体化された判定装置４００が送信装置２００の送受信するパケットを監視する構成としてもよい。

また、上記実施形態では、本発明をTCPセッションに適用した例を説明したが、本発明の適用範囲はTCPに限らず、コネクション型通信を行うプロトコルであれば、例えば、RFC2960にて規定されているSCTP（Stream Control Transfer Protocol）に適用することも可能である。

本発明の実施形態の構成を示すブロック図である。実施形態の判定装置の構成を示すブロック図である。実施形態のネットワーク処理部の構成を示すブロック図である。実施形態の記憶部を説明するための説明図である。実施形態の計測部の処理手順を示すフローチャートである。実施形態の判定部の処理手順を示すフローチャートである。実施形態の具体例１の処理手順を示すシーケンス図である。具体例１における判定結果を説明するための説明図である。実施形態の具体例２の処理手順を示すシーケンス図である。具体例２における判定結果を説明するための説明図である。

符号の説明

１００ネットワーク
２００送信装置
３００受信装置
４００判定装置
４１０ネットワーク処理部
４１０１、４１０２送受信部
４１０３設定メモリ
４１０４パケット検知部
４２０計測部
４２１記憶部
４２２ TB計算部
４３０判定部

Claims

コネクション型通信によりデータを授受する送信装置および受信装置間に接続された通信ボトルネック判定装置であって、
前記送信装置が出力した送信パケットから該送信パケットに含まれるデータを識別するためのシーケンス番号を記録し、且つ、前記受信装置が前記送信パケットの受信時に出力した応答パケットに設定されている広告ウィンドウサイズおよび前記送信装置へ要求すべきデータのシーケンス番号の加算値を該受信装置が受信可能なデータ範囲を示す受信許容量として記録する手段と、
前記受信許容量から最新のシーケンス番号を減算した値を差分とし該差分が予め設定した閾値以下のとき前記受信装置が通信ボトルネックであると判定する手段と
を備えることを特徴とする通信ボトルネック判定装置。
過去に求めた前記差分のうちの最大値に対し所定の比率を持つ値を前記閾値とすることを特徴とする請求項１記載の通信ボトルネック判定装置。
前記受信装置との間のパケット往復時間と当該期間のスループット値との積を前記閾値とすることを特徴とする請求項１記載の通信ボトルネック判定装置。
コンピュータを、請求項１乃至３記載の通信ボトルネック判定装置として機能させることを特徴とするプログラム。
コネクション型通信によりデータを授受する送信装置および受信装置と、該両装置間に接続された通信ボトルネック判定装置とを備え、
前記通信ボトルネック判定装置は、
前記送信装置が出力した送信パケットから該送信パケットに含まれるデータを識別するためのシーケンス番号を記録し、且つ、前記受信装置が前記送信パケットの受信時に出力した応答パケットに設定されている広告ウィンドウサイズおよび前記送信装置へ要求すべきデータのシーケンス番号の加算値を該受信装置が受信可能なデータ範囲を示す受信許容量として記録する手段と、
前記受信許容量から最新のシーケンス番号を減算した値を差分とし該差分が予め設定した閾値以下のとき前記受信装置が通信ボトルネックであると判定する手段と
を備えることを特徴とする通信ボトルネック判定システム。
コネクション型通信によりデータを授受する送信装置および受信装置間に接続された通信ボトルネック判定装置が、
前記送信装置が出力した送信パケットから該送信パケットに含まれるデータを識別するためのシーケンス番号を記録し、前記受信装置が前記送信パケットの受信時に出力した応答パケットに設定されている広告ウィンドウサイズおよび前記送信装置へ要求すべきデータのシーケンス番号の加算値を該受信装置が受信可能なデータ範囲を示す受信許容量として記録し、該受信許容量から最新のシーケンス番号を減算した値を差分とし該差分が予め設定した閾値以下のとき前記受信装置が通信ボトルネックであると判定する
ことを特徴とする通信ボトルネック判定方法。
前記通信ボトルネック判定装置が、過去に求めた前記差分のうちの最大値に対し所定の比率を持つ値を前記閾値とすることを特徴とする請求項６記載の通信ボトルネック判定方法。
前記通信ボトルネック判定装置が、前記受信装置との間のパケット往復時間と当該期間のスループット値との積を前記閾値とすることを特徴とする請求項６記載の通信ボトルネック判定方法。