(57)【要約】【課題】ネットワークへの測定負荷を削減しつつ、ＴＣＰスループットを推定するＴＣＰ通信品質推定方法を提供する。【解決手段】送信元から着信先への順方向のＴＣＰ通信の通信品質を推定するＴＣＰ通信品質推定方法において、ある時点での、前記測定された前記逆方向のＴＣＰ通信のＴＣＰスループットをTCP_thruput_rev(t)、前記送信元と前記着信先との間の往復遅延時間をRTT(t)、パケット損失率をp_loss(t)とするとき、前記送信元において、前記往復遅延時間RTT(t)とパケット損失率p_loss(t)から、関数Ｆ（RTT(t)，p_loss(t)）を用いてＴＣＰスループットTCP_estl(t)を推定し、前記順方向のＴＣＰスループットTCP_thruput_est(t)を、関数Ｇ（TCP_estl(t)，TCP_thruput_rev(t)）を用いて推定する。【選択図】図１
2010233272.tif 000002
【特許請求の範囲】
【請求項１】
送信元から着信先への順方向のＴＣＰ通信の通信品質を推定するＴＣＰ通信品質推定方法において、
前記送信元において、前記着信先から前記送信元への逆方向のＴＣＰ通信のＴＣＰスループットと、前記送信元と前記着信先との間の往復遅延時間とパケット損失率とを測定し、
当該測定された前記逆方向のＴＣＰ通信のＴＣＰスループットと、前記送信元と前記着信先との間の往復遅延時間とパケット損失率とを用いて、順方向のＴＣＰ通信のＴＣＰスループットを推定することを特徴とするＴＣＰ通信品質推定方法。
【請求項２】
ある時点での、前記測定された前記逆方向のＴＣＰ通信のＴＣＰスループットをTCP_thruput_rev(t)、前記送信元と前記着信先との間の往復遅延時間をRTT(t)、パケット損失率をp_loss(t)とするとき、
前記送信元において、前記往復遅延時間RTT(t)とパケット損失率p_loss(t)から、関数Ｆ（RTT(t)，p_loss(t)）を用いてＴＣＰスループットTCP_estl(t)を推定し、
前記順方向のＴＣＰスループットTCP_thruput_est(t)を、関数Ｇ（TCP_estl(t)，TCP_thruput_rev(t)）を用いて推定することを特徴とする請求項１に記載のＴＣＰ通信品質推定方法。
【請求項３】
前記関数Ｇは、パケット損失率p_loss(t)が予め定めた閾値よりも大きければ、前記順方向のＴＣＰスループットTCP_thruput_est(t)として、TCP_estｌ(t)を出力し、パケット損失率p_loss(t)が予め定めた閾値以下の場合、前記順方向のＴＣＰスループットTCP_thruput_est(t)として、TCP_thruput_rev(t)を出力することを特徴とする請求項２に記載のＴＣＰ通信品質推定方法。
【請求項４】
送信元から着信先への順方向のＴＣＰ通信の通信品質を推定するＴＣＰ通信品質推定装置において、
前記送信元は、パケットを受信するパケット受信部と、
ある時点での、前記着信先から前記送信元への逆方向のＴＣＰ通信のＴＣＰスループットTCP_thruput_rev(t)と、前記送信元と前記着信先との間の往復遅延時間RTT(t)と、パケット損失率p_loss(t)とを測定し、前記測定された前記往復遅延時間RTT(t)とパケット損失率p_loss(t)から、関数Ｆ（RTT(t)，p_loss(t)）を用いてＴＣＰスループットTCP_estl(t)を推定し、前記順方向のＴＣＰスループットTCP_thruput_est(t)を、関数Ｇ（TCP_estl(t)，TCP_thruput_rev(t)）を用いて推定するスループット推定部とを有することを特徴とするＴＣＰ通信品質推定装置。
【請求項５】
前記関数Ｇは、パケット損失率p_loss(t)が予め定めた閾値よりも大きければ、前記順方向のＴＣＰスループットTCP_thruput_est(t)として、TCP_estｌ(t)を出力し、パケット損失率p_loss(t)が予め定めた閾値以下の場合、前記順方向のＴＣＰスループットTCP_thruput_est(t)として、TCP_thruput_rev(t)を出力することを特徴とする請求項４に記載のＴＣＰ通信品質推定装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＴＣＰ通信品質推定方法およびＴＣＰ通信品質推定装置に係り、特に、ＩＰネットワークの通信品質状態を管理する技術に関する。
【背景技術】
【０００２】
ＩＰネットワークが広く利用されてくるに伴って、ＩＰネットワーク上での通信品質保証に対する要求が高まっている。それに伴い、ネットワークを流れるトラヒックを測定して現在の通信品質状態を把握することが重要になってきている。特に、ユーザの体感する品質を直接表すユーザフローレベル（ここでのフローとは、ＴＣＰコネクションを指す）で品質測定する技術が着目されている。
しかしながら、ユーザフロー通信品質を測定するためには、回線を流れるパケットを全てキャプチャしてパケットヘッダ情報の解析、およびフロー情報の解析が必要となるが、回線速度が高速になるにつれて全てのパケットをキャプチャして処理することが困難になってきている。
【０００３】
なお、本願発明に関連する先行技術文献としては以下のものがある。
【非特許文献１】IETF Packet Sampling(psamp) Working Group,        http:／／www.ietf.org／html.charters／psamp-charter.html.
【非特許文献２】T.Mori,T.Takine,J.Pan,R.Kawahara,M.Uchida,and S.Goto,“Identifying heavy-hitter flows from sampled flow statistics,” IEICETrans.Commun.,vol.E90-B,no.11,pp.3061-3072,Nov.2007..
【非特許文献３】C.Estan and G.Varghese,“New Directions in Traffic Measurement and Accounting,”ACM SIGCOMM2002,Aug.2002.
【非特許文献４】N.Duffield,C.Lured,and M.Thorup,“Properties and Prediction of Flow Statistics from Sampled Packet Streams,”ACM SIGCOMM Internet Measurement Conference 2002,Nov.2002.
【非特許文献５】N.Duffield,C.Lund,and M.Thorup,“Estimating Flow Distributions from Sampled Flow Statistics,”In Proceedings of ACM SIGCOMM,pp.325-336,Aug.2003.
【非特許文献６】J.Padhye et al.,“Modeling TCP Reno performance: a simple model and its empirical validation,”IEEE／ACM Tansactions on Netwoking,2000.
【非特許文献７】S.Rewaskar and J.Kaur,“Testing the Scalability of Overlay Routing Infrastructures,”Proc.PAM 2004.April 2004.
【発明の開示】
【発明が解決しようとする課題】
【０００４】
近年、パケットサンプリングを実施することによってフロー管理に必要とされる処理を軽減する手法が着目されている（前記非特許文献１参照）。例えば、Ｎ個に１個のパケットを周期的に参照し、サンプルされたパケットから元のフロー統計情報を推定する。
また、前記非特許文献２では、パケットサンプリングを用いてリンク帯域の占有率が高いフローを特定する方法を提案している。また、前記非特許文献３では、フローサイズが大きいフローの統計を精度よく得る方法を提案している。
しかしながら、前述の非特許文献２，３は、サイズの大きい、あるいは帯域の占有率が高いフローを特定し、それらフローを過剰に発生するユーザを迅速に切り分けることを目的としており、あるリンク上のフロー全体の通信品質や、フロー全体の統計情報（フローレートの分布等）の把握を可能にするものではなかった。
この方法で、元のフロー情報に関する分布を推定すると、分布がフローサイズの大きいフローに偏ってしまい、適切に推定できないという問題点があった。その理由は、Ｎ個に１個のパケットを抽出するといった通常のパケットサンプリングでは、サイズの大きいフローがサンプルされやすく、サイズの小さいフローが無視される確率が高くなってしまうからである。
前述の非特許文献４、５では、Ｎ個に１個のパケットを抽出する通常のパケットサンプリングにおいて、サンプルされたパケットのうち、ＳＹＮパケット（ＴＣＰフラグの一つで、通信開始を意味する）の数を用いて、サンプルされていない全体のフロー発生数やフローサイズの平均や分布を推定する方法を提案している。
しかしながら、フローサイズに関する統計情報を推定するに留まっており、ユーザの品質を表すフローレート（ＴＣＰスループットに相当する）やフロー持続時間（ファイル転送時間に相当）に関する推定を可能にするものではなかった。
【０００５】
一方、別のアプローチとして、着目する送信元−着信先ノード間において試験トラヒックを用いてＴＣＰスループットを測定する方法が考えられる。
しかしながら、この方法では、試験トラヒック自体がネットワークを輻輳させてしまい他のユーザに影響を及ぼしてしまう点、並びに、試験トラヒック自身の負荷でネットワークの状況が変わってしまい、本当に知りたいＴＣＰ品質を正確に把握できない点が問題であった。
他方、軽量な試験トラヒックでＴＣＰスループットを推定する方法として、前述の非特許文献６で提案している方法がある。前述の非特許文献６では、着目するホスト間でパケット損失率と、往復遅延時間を測定し、それらからＴＣＰスループットを推定する。
しかしながら、この方法では、推定がうまくできる領域とそうでない領域があると考えられ、推定値が実測値と合わないケースもあるという問題点があった。
本発明は、前記従来技術の問題点を解決するためになされたものであり、本発明の目的は、ネットワークへの測定負荷を削減しつつ、ＴＣＰスループットを推定するＴＣＰ通信品質推定方法およびＴＣＰ通信品質推定装置を提供することにある。
本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述及び添付図面によって明らかにする。
【課題を解決するための手段】
【０００６】
本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、下記の通りである。
本発明のＴＣＰ通信品質推定方法においては、推定したい送信元−着信先との間で実際に順方向のＴＣＰ転送を行う代わりに、送信元において、着信先から送信元への逆方向のＴＣＰ通信のＴＣＰスループットと、送信元と着信先との間の往復遅延時間とパケット損失率とを測定し、当該測定された逆方向のＴＣＰ通信のＴＣＰスループットと、送信元と着信先との間の往復遅延時間とパケット損失率とを用いて、順方向のＴＣＰ通信のＴＣＰスループットを推定することを特徴とする。
推定したい順方向のＴＣＰ通信とは逆方向のＴＣＰ通信（即ち、着信先から送信元への方向のＴＣＰ通信）であっても、ある時点での往復遅延時間RTTは順方向のＴＣＰ通信と同じであるため、往復遅延時間RTTが順方向のＴＣＰウィンドウ制御にどのような影響を与えるかは、逆方向のＴＣＰウィンドウの振る舞いをみても把握可能と考えられる。そこで、逆方向のＴＣＰ通信のＴＣＰスループットを用いて、順方向のＴＣＰ通信のＴＣＰスループットを推定する。逆方向のＴＣＰ通信を利用することにより、順方向へ余分な負荷を加えることを回避することできる。
【０００７】
このように、逆方向のＴＣＰ通信の挙動は、往復遅延時間RTTがＴＣＰ通信へどのような影響を与えるか、という点に関しては、順方向と同じであるが、パケット損失率p_lossについては、順方向と逆方向では必ずしも挙動は一致しない。
例えば、送信元から着信先の順方向において輻輳が発生してパケットが損失する場合を考える。その際、順方向のＴＣＰ通信においては、データパケットが損失することになり、逆方向通信においては、Ａｃｋパケットが損失することになる。
データパケットが一つでも損失した場合には、必ず再送制御が働き、それに関連してウィンドウサイズも変更される可能性がある。一方、Ａｃｋパケットが損失した場合は必ずしも再送制御を伴うとは限らない。例えば、あるＡｃｋが損失したとしてもその次のＡｃｋパケットが無事送信元へ到達すれば、送信元へはどのデータパケットまで届いているかという情報を伝えることが可能であるため、前者のＡｃｋが損失した影響はＴＣＰの振る舞いに影響を与えない。前述の非特許文献［６］で提案しているＴＣＰスループット推定法は、パケット損失の影響をモデルに取り組んでいる。
そこで、本発明の第２のＴＣＰ通信品質推定方法では、逆方向ＴＣＰスループットと、順方向での推定ＴＣＰスループットの結果を、パケット損失率の値に応じてうまく使い分けることによって、順方向のＴＣＰスループットを推定している。
【０００８】
具体的には、本発明のＴＣＰ通信品質推定方法では、ある時点での、測定された逆方向のＴＣＰ通信のＴＣＰスループットをTCP_thruput_rev(t)、送信元と着信先との間の往復遅延時間をRTT(t)、パケット損失率をp_loss(t)とするとき、往復遅延時間RTT(t)とパケット損失率p_loss(t)から、関数Ｆ（RTT(t)，p_loss(t)）を用いてＴＣＰスループットTCP_estl(t)を推定し、順方向のＴＣＰスループットTCP_thruput_est(t)を、関数Ｇ（TCP_estl(t)，TCP_thruput_rev(t)）を用いて推定する。
ここで、関数Ｇは、パケット損失率p_loss(t)が予め定めた閾値よりも大きければ、順方向のＴＣＰスループットTCP_thruput_est(t)として、TCP_estｌ(t)を出力し、パケット損失率p_loss(t)が予め定めた閾値以下の場合、順方向のＴＣＰスループットTCP_thruput_est(t)として、TCP_thruput_rev(t)を出力する。
また、本発明は、前述の第１のＴＣＰ通信品質推定方法と、第２のＴＣＰ通信品質推定方法を実行するＴＣＰ通信品質推定装置である。
【発明の効果】
【０００９】
本願において開示される発明のうち代表的なものによって得られる効果を簡単に説明すれば、下記の通りである。
本発明のＴＣＰ通信品質推定方法およびＴＣＰ通信品質推定装置によれば、ネットワークへの測定負荷を削減しつつ、ＴＣＰスループットを推定することが可能となる。
【図面の簡単な説明】
【００１０】
【図１】本発明が適用されるＩＰネットワークの基本構成の一例を示す構成図である。
【図２】図１に示す送信側装置の概略構成を示すブロック図である。
【図３】図１に示す受信側装置の概略構成を示すブロック図である。
【図４】本願発明の参考例のＴＣＰ通信品質推定方法によってＴＣＰスループットを推定した結果を示したグラフである。
【図５】ＴＣＰスループット推定値を用いて迂回制御を行った際の結果を示すグラフである。
【発明を実施するための最良の形態】
【００１１】
以下、図面を参照して本発明の実施例を詳細に説明する。
なお、実施例を説明するための全図において、同一機能を有するものは同一符号を付け、その繰り返しの説明は省略する。
［参考例］
図１は、本発明が適用されるＩＰネットワークの基本構成の一例を示す構成図である。
図１において、１は送信側装置、２は受信側装置、３は端末装置、４はＬＡＮ、５はインターネット、６はエッジノード、７はアクセス回線、８はインターネットサービスプロバイダである。
本発明の実施例のＴＣＰ通信品質推定装置は、送信側装置１と受信側装置２とで構成される。図１に示すように、本実施例の通信品質推定装置は、ネットワーク上の推定したい区間の両端に、送信側装置１と受信側装置２とを設置する形態で利用される。図１では、送信側装置１は、インターネット５と、アクセス回線７を介して、ＬＡＮ４に配置された受信側装置２とＴＣＰ通信を行う。なお、この送信側装置１と受信側装置２とは、サーバあるいは端末装置内に設けてもよい。
図２は、図１に示す送信側装置１の概略構成を示すブロック図である。
送信側装置１は、試験パケットを生成する試験パケット生成部１０と、ＴＣＰ動作模擬部１１とを有する。
図３は、図１に示す受信側装置２の概略構成を示すブロック図である。
受信側装置２は、パケット受信部２０と、スループット推定部２１とを有する。
【００１２】
以下、本発明の参考例のＴＣＰ通信品質推定方法について説明する。
本発明の参考例のＴＣＰ通信品質推定方法では、送信側装置１の試験パケット生成部１０において、試験したいデータサイズ分に相当する試験パケットを生成する。
例えば、『１MBのデータをパケットサイズMSS＝1500byte（＝ヘッダ40byte＋データ部分1460byte）で転送した場合』を模擬したいとする。また、ここでの試験用パケットサイズを、MSS’＝40byteに設定したとする（40byteとは、ＩＰヘッダ＋ＴＣＰヘッダで最低限必要なサイズ）。
この場合、試験パケット生成部１０では、１MB／1460byte＝685個（N＝685）の試験パケットを生成し、このパケットサイズを40byteとして、ＴＣＰ動作模擬部１１に受け渡す。
ＴＣＰ動作模擬部１１は、その受け渡されたN個のパケットをアクセス速度r×MSS’／MSS[bps]で、ＴＣＰ通信に従って転送する。ここで、送信側装置１の通信網へのアクセス回線速度がｒ[bps]であるとする。
図３に示す受信側装置２では、パケット受信部２０において試験パケットを受信し、通常のＴＣＰ動作に従ってＡｃｋパケットを返送する。同時に、受け取ったパケットをスループット推定部２１に渡す。
ＴＣＰスループット推定部２１では、予め定めた測定周期τごとに正しく届けられたパケット数をカウントし、その値をＣとする。そのＣを用いてＴＣＰスループットをC×MSS×8／τ[bps]として推定する。
ここでは、送信側装置１から送信されたN個のパケットを全てを受信するまでの時間T’を測定し、推定したい本来の転送時間T（＝実際にr[bps]のアクセス回線速度で、MSSのパケットサイズで、N個のパケットを送るのに必要となる時間）を、T＝T’として推定する。また、N個全てを送るためのＴＣＰスループットをN×MSS×8／T’[bps]として推定する。
【００１３】
［実施例］
前述の参考例のように、送信側装置１から受信側装置２へ試験パケットを送信し、ＴＣＰスループットを推定する代わりに、受信側から送信側への方向（送信側から受信側への順方向と逆方向）でＴＣＰスループットが測定されている状況を考える。
本実施例では、送信側装置１が、図３に示すパケット受信部２０と、スループット推定部２１とを有する。
本実施例のＴＣＰ通信品質推定方法では、送信側装置１のパケット受信部２０において、受信側から送信側への逆方向のパケットを受信し、通常のＴＣＰ動作に従ってＡｃｋパケットを返送する。同時に、受け取ったパケットをスループット推定部２１に渡す。
ＴＣＰスループット推定部２１では、予め定めた測定周期τごとに正しく届けられたパケット数をカウントし、その値をＣとする。そのＣを用いてＴＣＰスループットをC×MSS×8／τ[bps]として推定し、ある時点ｔでのその値を、TCP_thruput_rev(t)とする。
また、同時に、着目する送信元−着信先との間において、往復遅延時間RTT(t)とパケット損失率p_loss(t)を測定しておき、往復遅延時間RTT(t)とパケット損失率p_loss(t)とを入力して推定されるＴＣＰスループットを、TCP_estl(t)とする。
【００１４】
つまり、TCP_estl(t)は、TCP_estl(t)＝Ｆ（RTT(t)、p_loss(t)）という関数で与えられる。ここで、今着目する送信元から着信先への順方向のＴＣＰスループットTCP_thruput_estを、関数Ｇ（TCP_estl(t)、TCP_thruput rev(t)）で推定する。
ここで、TCP_estl(t)の関数Ｆの候補としては、下記（１）式がある。
［数１］
Ｆ（RTT(t)、p_loss(t)）＝min｛W／RTT(t)，MSS／(RTT(t)×{2／3×p_loss(t)｝１／２）｝
・・・・・・・・・・・・・・・・・・・・・  （１）
ここで、Ｗはウィンドウ関数であり、（１）式は、前述の非特許文献６で提案している方法である。
一方、関数Ｇとしては、下記（２）式がある。
［数２］
Ｇ（TCP_estl(t),TCP_thruput_rev(t)）
＝TCP_estl(t)  if ploss(t)＞閾値
（即ち、TCP_thruput_est(t)＝TCP_estl(t) ）
Ｇ（TCP_estl(t),TCP_thruput_rev(t)）
＝TCP_thruput rev(t)  if ploss(t)≦閾値
（即ち、TCP_thruput_est(t)＝TCP_thruput rev(t)）
・・・・・・・・・・・・・・・・・・・・・  （２）
【００１５】
以下、参考例のＴＣＰ通信品質推定方法の有効性をシミュレーションにより評価した結果について説明する。
本シミュレーションでは、10MbpsのリンクにＴＣＰフローを多重し、ある片方向においてリンクを輻輳させる。ここで背景トラヒックとして、ボアソン過程に従ってＴＣＰフローが生起し、ある分布に従うサイズを持つファイルを発生させてそれをＴＣＰに従って転送させる。
以上の背景負荷とは別に、実際にファイル転送し続けるＴＣＰフローを１本（ここでのパケットサイズは1500byte）、参考例のＴＣＰ通信品質推定方法により、パケットサイズを小さく設定してＴＣＰを模擬するフローを１本ずつ用意し、そのＴＣＰスループットを測定した。
その結果を図４に示す。図中、actualが実際にファイル転送し続けるＴＣＰのスループット、tcpがパケットサイズを40byteにしてＴＣＰを模擬して、参考例のＴＣＰ通信品質推定方法でＴＣＰスループットを推定した結果である。
また、参考として、ボトルネックリンクでのキュー長（Qucue length）およびパケット損失発生時点（Loss）も併せて図示している。
図４から、キュー長の増加やパケット損の発生に伴い、ＴＣＰスループットが劣化していることと、実際の値と推定値がほぼ同じような挙動を示していることが確認できる。
以上説明したように、本実施例のＴＣＰ通信品質推定方法では、ネットワークへの負荷を低減しつつ、ＴＣＰスループットを精度よく推定可能である。本実施例のＴＣＰ通信品質推定方法により、着目する端末間のネットワーク品質を推定管理することが可能となり、効率的な品質管理が可能となる。
【００１６】
別の応用例としては、オーバーレイネットワークによって品質のよい迂回経路を探すという方法が前述の非特許文献７等で検討されているが、その際に必要となるノード間の品質を推定可能とする。
参考として図５に、迂回制御を行った際のＴＣＰスループットを示す。
図５で、defaultが迂回制御を行わなかった場合、optimalが制御を行った場合である。なお、Ｘ軸がＴＣＰスループットｘ、Ｙ軸がスループットがｘ以下である通信ペアの割合を表す。
ここでは、あるノード間の往復遅延時間RTTと、パケット損失率p_lossのみの情報を用いた結果であり、前述の非特許文献６の方法でＴＣＰスループットを推定した結果である。このように、ＴＣＰスループットを推定できればより品質のよい迂回経路を精度よく選択可能となる。
以上、本発明者によってなされた発明を、前記実施例に基づき具体的に説明したが、本
発明は、前記実施例に限定されるものではなく、その要旨を逸脱しない範囲において種々変更可能であることは勿論である。
【符号の説明】
【００１７】
１  送信側装置
２  受信側装置
３  端末装置
４  ＬＡＮ
５  インターネット
６  エッジノード
７  アクセス回線
８  インターネットサービスプロバイダ
１０  試験パケット生成部
１１  ＴＣＰ動作模擬部
２０  パケット受信部
２１  スループット推定部
【図１】
2010233272.tif 000003
【図２】
2010233272.tif 000004
【図３】
2010233272.tif 000005
【図４】
2010233272.tif 000006
【図５】
2010233272.tif 000007