JP2013232851A

JP2013232851A - 可用帯域測定装置及び方法及びプログラム

Info

Publication number: JP2013232851A
Application number: JP2012104964A
Authority: JP
Inventors: Kenji Kugimoto; 健司釘本; Shigeki Miyake; 茂樹三宅; Mitsuru Maruyama; 充丸山
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 2012-05-01
Filing date: 2012-05-01
Publication date: 2013-11-14
Anticipated expiration: 2032-05-01
Also published as: JP5739373B2

Abstract

【課題】パケット交換網における、可用帯域を精度よく測定する。
【解決手段】本発明は、カーネル内において、アプリケーションによるパケットの送信に応じて、受信側からのACKパケットを受信し、ACKパケット受信する毎に、該ACKパケットに格納されている受信側に到達した受信データ量を積算し、受信したACKパケットの総数が所定のパケット数に到達するまで測定する測定ステップを行い、ACKパケットの総数が所定のパケット数に到達した場合に、該所定のパケット数に到達するまでの測定期間が、所定の時間以上であるかを判定し、該所定の時間未満である場合には、該所定のパケット数を増加させて、測定ステップを繰り返し、該所定時間以上であった場合は、該測定ステップで積算された累積の受信データ量を該測定期間で除算することにより可用帯域を算出する。
【選択図】図３

Description

本発明は、可用帯域測定装置及び方法及びプログラムに係り、特にパケット交換網における、任意のホスト間を結ぶネットワークパスに流すことのできるトラフィックの最大値である可用帯域を測定するための可用帯域測定装置及び方法及びプログラムに関する。

可用帯域とは、任意のホスト間を結ぶネットワークパスに流すことのできるトラフィックの最大値のことである。ネットワークパスの可用帯域は、ネットワークトポロジやノードの転送能力、リンクの容量や、その時点でネットワークに流れている背景トラフィックの様相によって決まる。可用帯域はネットワーク管理制御やアプリケーションのレート制御等において重要なパラメータである。

従来の可用帯域測定手法のうち、試験パケットを使うアクティブ方式と呼ばれるものは、直接測定法と間接測定法に分類できる。直接測定法とは、ある程度まとまったデータ量を含んだパケットを送信側から受信側に向けてホストが送信可能案最大のレートで送出し、受信側で受け取ったデータ量と受信にかかった時間から可用帯域を測定するもので、代表的な測定ツールとしてTTCP（非特許文献１）、iperf（非特許文献２）などがある。

一方、間接測定法とは、直接に可用帯域を測定するのではなく、パケットの遅延の増大を捉えて間接的に可用帯域を推定するものである。送信側がパケットの送信レートを変化させていくと、可用帯域を超えたときに輻輳が発生して遅延が生じる。この遅延の発生した時点での送信レートが可用帯域である。代表的な測定ツールの例として、IGI/PTR(Initial Gap Increasing/Packet Transmission Rate)（非特許文献３）やpathChirp（非特許文献４）、pathload（非特許文献５）がある。これらのツールでは、ホストが送信可能な最大の送信レートでパケットを送るのではなく、送信間隔を調整しながらパケットを送り、遅延の増大という形で輻輳の兆候が現れた時点で可用帯域を見積もるため、送信パケットを少なくすることができ、直接測定法に比べてネットワークへの負荷を小さくできるとされる。

前述の可用帯域測定ツールは、アプリケーションとして実装されているために正確な時刻を得ることが難しかった。そのため、
(1) 測定精度が低く、
(2) 大量の試験パケットを送信してネットワークに大きな負荷がかかる、
(3) 可用帯域の瞬時値を測れない
という問題があった。可用帯域の測定機能をカーネルの拡張機能として実装すれば、コンテキストスイッチなどの影響を少なくして正確な時刻を得ることができるため、アプリケーションで実装した測定ツールに比べて精度の高い測定が可能となる。

可用帯域測定機能をカーネルの拡張機能として実装したものに、ImTCP（非特許文献６）、ICIM（非特許文献７）がある。これらはpathChirpと同様の測定機構をカーネル内部に実装したものである。

"The Story of the TTCP Program", website at http://ftp.arl.mil/~mike/ttcp.html Iperf website at http://iperf.sourceforge.net/ IGI/PTR(Initial Gap Increasing / Packet Transmission Rate) website at http://www.cs.cmu.edu/~hnn/igi/ Vinay J. Ribeiro, Rudolf H. Riedi, Jiri Navratil, Les Cottrell, and Richard G. Baraniuk: "pathChirp: Efficient Available Bandwidth Estimation for Network Paths" Workshop on Passive and Active Measurement PAM2003, 2003 M. Jain and C. Dovrolis: "End-to-end available bandwidth: measurement methodology, dynamics, and relation with TCP throughput", ACM SIGCOMM, 2002. C. Man, G. Hasegawa, and M. Murata: "Available bandwidth measurement via TCP connection," IFIP/IEEE Workshop on End-to-End Monitoring Techniques and Services, Oct. 2004. C. Man, G. Hasegawa, and M. Murata: "ICIM: An inline network measurement mechanism for high-speed networks", IEEE/IFIP Workshop on End-to-End Monitoring Techniques and Services, Apr. 2006.

しかしながら、上記従来のTTCP、iperf、IGI/PTR、pathChirp、pathloadなどの可用帯域測定ツールは、アプリケーションとして実装されているため、正確な時刻を得ることが難しい。そのため、(1) 測定精度が低く、(2) 精度を高めようとすれば大量の試験パケットを送信することになるためにネットワークに大きな負荷がかかり、(3) 可用帯域の瞬時値を測れないという問題があった。カーネル内部ではアプリケーションの動作するユーザー空間よりも正確な時刻が得られるので、可用帯域測定機能をカーネル内に実装することによって、この問題は解消することができる。

ImTCP、ICIMは、pathChirpと同様の測定機構をカーネル内部に実装することで、精度の高い測定を可能とすることを狙ったものである。

しかし、パケットの送信間隔を精密に制御しなければならないため、(1) 仕組みが複雑になる、(2) インターフェイス速度が速くなるにつれて正確な時間間隔でパケットを送信することが難しくなるため、精度の高い測定ができなくなるという問題があった。また、輻輳の発生に由来するパケット遅延の増大と、システムの負荷の変動などに由来する遅延の増大を区別できず、可用帯域の推定に失敗するという原理的にpathChirpと同様の問題があった。また、これらの実装には可用帯域の測定結果を簡易にアプリケーションに提供する機能がなかった。カーネル内部での可用帯域の測定結果をアプリケーションが容易に得ることができれば利便性が向上する。

本発明は上記の点に鑑みなされたもので、仕組みが複雑でネットワークにかかる高負荷をかける割に、測定精度が低いという、従来の遅延観測型の可用帯域測定ツールが持っていた問題を回避して精度の高い測定を行うことが可能な可用帯域測定装置及び方法及びプログラムを提供することを目的とする。

上記の課題を解決するため、本発明（請求項１）は、パケット交換網における、任意のホスト間を結ぶネットワークパスに流すことのできるトラフィックの最大値である可用帯域を測定するための可用帯域測定装置であって、
アプリケーションによるパケットの送信に応じて、受信側からのACKパケットを受信し、該ACKパケットを受信する毎に、該ACKパケットに格納されている受信側に到達した受信データ量を積算し、受信した前記ACKパケットの総数が所定のパケット数に到達するまで測定する測定手段と、
前記ACKパケットの総数が前記所定のパケット数に到達した場合に、該所定のパケット数に到達するまでの測定期間が、所定の時間以上であるかを判定し、該所定の時間未満である場合には、該所定のパケット数を増加させて、前記測定手段を繰り返し、該所定時間以上であった場合は、前記測定手段で積算された累積の受信データ量を、該測定期間で除算することにより可用帯域を算出する可用帯域算出手段と、をカーネル内部に具備する。

また、本発明（請求項２）は、前記可用帯域算出手段において、
getsockopt()関数を用いて測定結果である前記可用帯域を、前記カーネル内部のソケットを介してアプリケーションに通知する手段を含む。

また、本発明（請求項３）は、前記可用帯域算出手段において、
前記測定期間が前記所定の時間の２倍を超えている場合は、前記所定のパケット数を減少させる手段を含む。

本発明の可用帯域測定機能は、測定機能をカーネル内に実装することにより、正確な時刻を得て測定精度を上げることができる。また、測定に必要なパケット数を可用帯域のレンジに合わせて自動的に調整することにより、ネットワークにかかる負荷の低減をはかることができる。また、getsockopt()関数を通して測定結果を簡易にアプリケーションに渡すことができる。

また、上記の効果のみならず、本発明による可用帯域測定機能は、実装が簡易であり、また送信側だけの実装で済むため、ソフトウェアの保守性に優れる。個別のアプリケーションが実際に使用しているTCPコネクションを利用して可用帯域を測定するため、試験パケットの要らないパッシブ方式の良さを併せ持つ。

本発明のACKパケットの観測による可用帯域測定を説明するための図である。受信間隔のゆらぎと測定精度の模式図である。本発明の一実施の形態における可用帯域測定機能のカーネル内部のネットワーク関連部の構成図である。本発明の一実施の形態における可用帯域測定部のアルゴリズム（その１）である。本発明の一実施の形態における可用帯域測定部のアルゴリズム（その２）である。

まず、本発明の概要を説明する。

本発明では、正確な時刻を利用するために、測定機能をカーネル内部のネットワーク関連部に実装する。また、pathchirpのように送信パケットの間隔の精密な調整を必要とする複雑な実装を避けて、より簡易な、ACK(確認応答)パケットの受信に基づく可用帯域測定方式を採用した。ACKパケットの観測に基づく可用帯域測定原理を輻輳回避アルゴリズムの動作に利用したものが過去に提案され、実装も試みられている（例えば、文献１「釘本健司, 天海良治, 帯域見積りに基づく輻輳回避アルゴリズム, 情報処理学会論文誌, Vol.39, No.2, pp228-238, 1998.」、文献２「Casetti, C.; Geria, M.; Lee, S.S.; Mascolo, S.; Sanadidi, TCP with faster recovery, M., MILCOM 2000. 21st Century Military Communications Conference Proceedings, pp.320-324, vol.1, 2000.」、文献３「Gerla, M.; Sanadidi, M.Y.; Ren Wang; Zanella, A.; Casetti, C.; Mascolo, S., TCP Westwood: congestion window control using bandwidth estimation, Global Telecommunications Conference, pp1698-1702, vol.3, 2001」）。本発明でも同様の測定原理を用いている。以下では測定原理について詳述する。

本発明では、パケットの送信/受信ともに通常のTCP（Transmission Control Protocol）のアルゴリズムを利用する。可用帯域の測定はACKパケットによって送達が確認されたバイト数とパケットの到着時刻の間隔を利用してネットワークパスの可用帯域を測定する。TCPでは、信頼性のある通信を行うために、送信側からのデータパケットに対して、受信側からACKパケットを送り返す。このACKパケットにより到着が確認されたデータの転送量が通知される。このとき、ACKパケットの到着の時間間隔はネットワークパスの可用帯域を反映しているので、送信側では到着間隔を基に可用帯域を推定することが可能である。なお、一般に往路と復路は同時刻に同程度の可用帯域を持つと考えてよい。ACKパケットのサイズは往路のデータパケットのサイズよりも小さいため、復路のACKの転送レートは十分な可用帯域を持ち、ACKの転送レートに与える影響は無視できると考えてよい。

図１に示すように、あるTCPコネクションにおいて、送信側から送られたデータパケットがネットワークパスを通過して受信側に届く時には、転送レートはそのパス上の最も狭い可用帯域に律速される。すなわち受信側の受信レートはネットワークパスの可用帯域に等しくなる。受信側にパケットが到着したとき、到着したパケットに対するACKパケットが直ちに送信側に送り返されるとすると、ACKの返送時刻の間隔はネットワークの可用帯域を反映したものとなる。そこで、送信側において、ある2つのACKパケットP_n-1およびP_nの受信が完了した時間を、それぞれT_n-1、T_nとし、P_nのACKパケットによって送達が確認されたデータ量をV_nとすれば、受信側での受信レートの瞬時値R_nは次式で表せる。

この受信レートR_nがネットワークパスの可用帯域の瞬時値に等しくなる。このように、原理的には2つのACKパケットの到着間隔を送信側で観測することにより、ネットワークパスの可用帯域を推定することができる。ただし、様々な要因によるカーネル内部での取得時刻の揺らぎ、ネットワークの遅延揺らぎ、時刻の精度の問題などにより、カーネル内で観測される時刻は必ずしも信頼できるものではない。よって、現実的には、2つのパケットの到着間隔を観測するだけでは正確に帯域を推定することは難しい。例えば2つのパケットの受信時刻の間隔に真の値の10%のずれが生じれば、可用帯域の推定値も真の値から10%ずれてしまう。

図２は、観測されるACKパケットの間隔の揺らぎを模式的に表したものである。図からも明らかなように、パケット間隔が揺らいでいるとしても、複数のACKパケットをまとめて測定すれば、時刻のゆらぎを相対的に小さくできる。この時に必要となるN（まとめる数）は、測定しようとする可用帯域B(bps)、パケット到着時刻の揺らぎd(sec)、測定値の許容誤差p(%)、平均パケットサイズs(bytes)に基づいて以下のように決定される。

既に述べたように、以上の原理に基づく可用帯域推定アルゴリズムは既に知られているが、測定された可用帯域は、輻輳回避の指標としてDBP(Delay Bandwidth Product、遅延帯域積可用帯域)を算出するために用いられているものであり、可用帯域の測定結果を陽にアプリケーション層に提供する機能は持っていない。本発明では、カーネル内部での可用帯域の測定結果をアプリケーションに簡易に提供する。

以下、図面と共に本発明の実施の形態を説明する。

図３は、本発明の一実施の形態における可用帯域測定機能のカーネル内部のネットワーク関連部の構成を示す。

同図に示すカーネル内部のネットワーク関連部は、アプリケーション１０、ソケット２０、TCP１００、IP３０から構成される。

TCP１００は、可用帯域測定部１１０とTCP_INFO構造体１２０を有する。なお、図示しないが、後述するデータ量の積算値、受信したパケット数、測定期間等の変数や、受信すべきパケット数等の所定の値を一時的に格納するメモリを有するものとする。

帯域推定のためのコードの改造は、主としてTCPコード内のtcp_ack()関数に対して行っている。既に述べたように、ACKパケットをN個受信する毎に、受信側ホストの受信レートが計算される。その値が可用帯域の瞬時値であり、それをソケット２０に紐づけられたTCP_INFO構造体１２０に登録する。

可用帯域測定部１１０における、可用帯域の測定はACKの受信間隔を基に行う。ACKの受信間隔はネットワークパスの可用帯域を反映したものになっている。

図４は、本発明の一実施の形態における可用帯域測定部のアルゴリズムを示す。

ステップ１０１）可用帯域測定部１１０は、まず変数を初期化する。ACK_CNTは1回の測定期間において受信するACKパケットをカウントする変数、TAB(Total Acked Bytes)は1回の測定期間において受信側に到達したデータ量を積算する変数であり、それぞれ0で初期化する（ACK_CNT=0、TAB=0）。

PKT_PER_MESは1回の測定期間において受信すべき最少のパケット数であり、初期値はNである。Nの値はシステム起動時にインターフェイスから読み出された速度情報とシステム時刻の揺らぎd(sec)、許容誤差p(%)から上記の式（２）により決定される(PKT_PER_MES=N)。

MULTIは1回の測定期間において受信すべきパケット数をPKT_PER_MES単位で増減するための変数であり、1で初期化する(MULTI=1)。

ステップ１０２）初期化後、通信が始まると、アプリケーション１０からリクエストがあったタイミングでパケットの送信が行われ、それに応じて、このパケットを受信した受信側から返信されたACKパケットが受信される。このときACKパケットには受信側に到達したことが確認されたデータ量ACKED_BYTES(バイト数)が格納されている。

ACKパケットを受信すると、TABにACKED_BYTESを加算する(TAB=TAB+ACKED_BYTES)。ACK_CNTに1を加算する（ACK_CNT=ACK_CNT+1）。

ステップ１０３）また、1回の測定期間の最初にACKパケットを受信した時には、システムの時計から現在の時刻TIME_NOWを取得し、当該測定期間の先頭の時刻を示す変数であるTIME_PREVに格納しておく（TIME_PREV=TIME_NOW）。

ステップ１０４）１回目以降、ACKパケットを受信するたびにTABにACKED_BYTESを加算する(TAB=TAB+ACKED_BYTES)。ACK_CNTに1を加算する（ACK_CNT=ACK_CNT+1）。これにより、TABは1回の測定期間において受信側に到達した累積のデータ量、ACK_CNTは1回の測定期間において受信したACKパケットの総数となる。

ステップ１０５）そして、受信したACKパケットの総数ACK_CNTが、ACK_CNT≧PKT_PER_MES×MULTIとなったとき、ステップ１０６に進み、可用帯域の計算を行うかどうかを決める。ACK_CNT＜PKT_PER_MES×MULTIの場合はステップ１０４に戻る。

ステップ１０６）まず、現在の時刻TIME_NOWを取得し、測定の開始からの経過時間DELTA＝TIME_NOW−TIME_PREVを計算する。

ステップ１０７） DELTAが測定に必要な最低限の時間MIN_TIME_MESに達しているかどうかを調べる。MIN_TIME_MESはシステム時刻の揺らぎに応じてあらかじめ決められる変数で、たとえば1msの時刻の揺らぎがあるシステムで、揺らぎの影響を10%以内に抑えたければ10msとする。DELTA＞MIN_TIME_MESでなければステップ１０８に移行する。DELTA＞MIN_TIME_MESであれば、ステップ１０９に移行する。

ステップ１０８） MULTIを1増加させてステップ１０４に戻る。

ステップ１０９）前述の式（１）に従って、可用帯域TCP_ABW＝TAB/DELTAを計算するとともに、ACK_CNT＝0、TAB＝0とし、1回の測定期間における測定を終える。

ステップ１１０）そして、次の測定期間における測定に移る前に、実際の可用帯域に対して測定時間がかかり過ぎていないかどうかを調べ、時間がかかり過ぎているなら1回の測定期間を短縮する補正を行う。具体的には、DELTA＞MIN_TIME_MES×2であれば、DELTAが大きくなり過ぎたと判断して、ステップ１１１に移行する。

ステップ１１１）ステップ１１０において、DELTAが大きくなりすぎたと判断された場合は、MULTI＞2の場合にMULTIの値を1/2に短縮する補正を行い、ステップ１０２に移行し、次の測定期間における測定を開始する。その後、同様の手順により測定を繰り返す。

可用帯域の測定値のアプリケーション１０への受渡しには、Linux（登録商標）のgetsockopt()関数の拡張オプションを利用する。具体的には、図３において、アプリケーションプログラム１０が、使用中のTCPコネクションに対応するソケット２０に対し、TCP_INFOオプションをつけてgetsockopt()関数を呼び出すと、カーネル内部の可用帯域測定部１１０ではtcp_get_info()関数が呼び出されて、可用帯域の測定値がtcp_info構造体１２０のTCP_ABWにコピーされ、さらにそれがアプリケーション２０に側に引き渡される。カーネル内部のパラメータなどの情報は、通常はデバッガなどを起動しなければ取得できないが、我々の実装であれば、カーネル内部の可用帯域測定部１１０で測定された個別のTCPコネクションの可用帯域を簡単に取得することができる。たとえば、任意のホスト間の可用帯域を知るためには、ホスト間にTCPコネクションを張って適当なデータを流しながら、getsockopt()を使用してtcp_info構造体１２０にアクセスすればよい。具体的には、オプションとしてTCP_INFOをセットしてgetsockopt()関数を呼び出すと、可用帯域の測定値を取得できる。

本発明では、個別のアプリケーションが実際に使用しているTCPコネクションを利用して可用帯域を測定するため、試験パケットの要らないパッシブ方式の良さを併せ持つ。

なお、上記の図４，５に示すカーネル内部の可用帯域測定部の動作をプログラムとして構築し、可用帯域測定部として利用されるコンピュータにインストールして実行させる、または、ネットワークを介して流通させることが可能である。

本発明は、上記の実施の形態に限定されることなく、特許請求の範囲内において、種々変更・応用が可能である。

１０アプリケーション
２０ソケット
３０ＩＰ(Internet Protocol)
１００ TCP
１１０可用帯域測定部
１２０ TCP_INFO構造体

Claims

パケット交換網における、任意のホスト間を結ぶネットワークパスに流すことのできるトラフィックの最大値である可用帯域を測定するための可用帯域測定装置であって、
アプリケーションによるパケットの送信に応じて、受信側からのACKパケットを受信し、該ACKパケットを受信する毎に、該ACKパケットに格納されている受信側に到達した受信データ量を積算し、受信した前記ACKパケットの総数が所定のパケット数に到達するまで測定する測定手段と、
前記ACKパケットの総数が前記所定のパケット数に到達した場合に、該所定のパケット数に到達するまでの測定期間が、所定の時間以上であるかを判定し、該所定の時間未満である場合には、該所定のパケット数を増加させて、前記測定手段を繰り返し、該所定時間以上であった場合は、前記測定手段で積算された累積の受信データ量を、該測定期間で除算することにより可用帯域を算出する可用帯域算出手段と、
をカーネル内部に具備することを特徴とする可用帯域測定装置。
前記可用帯域算出手段は、
getsockopt()関数を用いて測定結果である前記可用帯域を、前記カーネル内部のソケットを介してアプリケーションに通知する手段を含む
請求項1記載の可用帯域測定装置。
前記可用帯域算出手段は、
前記測定期間が前記所定の時間の２倍を超えている場合は、前記所定のパケット数を減少させる手段を含む
請求項１記載の可用帯域測定装置。
パケット交換網における、任意のホスト間を結ぶネットワークパスに流すことのできるトラフィックの最大値である可用帯域を測定するための可用帯域測定方法であって、
カーネル内において、
測定手段が、アプリケーションによるパケットの送信に応じて、受信側からのACKパケットを受信し、前記ACKパケット受信する毎に、該ACKパケットに格納されている受信側に到達した受信データ量を積算し、受信した前記ACKパケットの総数が所定のパケット数に到達するまで測定する測定ステップと、
可用帯域算出手段が、前記ACKパケットの総数が前記所定のパケット数に到達した場合に、該所定のパケット数に到達するまでの測定期間が、所定の時間以上であるかを判定し、該所定の時間未満である場合には、該所定のパケット数を増加させて、前記測定ステップを繰り返し、該所定時間以上であった場合は、該測定ステップで積算された累積の受信データ量を該測定期間で除算することにより可用帯域を算出する可用帯域算出ステップと、
を行うことを特徴とする可用帯域測定方法。
前記可用帯域算出ステップにおいて、
getsockopt()関数を用いて測定結果である前記可用帯域を、前記カーネル内部のソケットを介してアプリケーションに通知する
請求項４記載の可用帯域測定方法。
前記可用帯域算出ステップにおいて、
前記測定期間が前記所定の時間の２倍を超えている場合は、前記所定のパケット数を減少させ、次回の測定ステップを実行させる
請求項４記載の可用帯域測定方法。
コンピュータを、
請求項４乃至６のいずれか1項に記載の可用帯域測定方法の各ステップとして機能させるための可用帯域測定プログラム。