JP4267988B2 - パケット送信量制御方法、通信システム、通信装置及びプログラム - Google Patents

Description

本発明は、パケット送信量の制御に関し、特に、TCP（Transport Control Protocol）を用いてパケット送信量を制御するパケット送信量制御方法、通信システム、通信装置及びプログラムに関する。

従来、TCPを用いて、パケット送信量を制御する方式として、TCP RenoなどのReactiveな方式や、TCP VegasなどのProactiveな方式が実現されている。

TCP Renoでは、送信側の通信装置が、パケット送信量を徐々に増加させ、ネットワークの輻輳によるパケットロスを検出すると、パケット送信量を大きく低下させる。したがって、TCP Renoでは、パケットロスが発生する程度まで、ネットワークを輻輳させてしまうことが問題となる。

一方、TCP Vegasでは、送信側の通信装置が、受信側の通信装置との間のRound Trip Time（以下、RTT）を用いてネットワークが輻輳しているか否かを監視し、RTTが増加し始めると、パケット送信量を低下させる（例えば、非特許文献１）。このため、TCP Vegasでは、パケットロスが発生する前に、送信側の通信装置のパケット送信量を制御することができる。

ここで、TCP Vegasの動作原理について概説する。図７は、TCP Vegasが用いられるネットワークの構成例を示している。

TCPでは、送信側の通信装置であるサーバ２００が、所定のデータパケット数によって構成されるウィンドウサイズを変更することによって、パケット送信量を制御する。

また、サーバ２００から送信されたデータパケットに対して、受信側の通信装置である受信端末３００から送信されるAck（Acknowledgement）パケットは、サーバ２００がデータパケットを送信してからRTT経過後にサーバ２００に到着すると考えられるため、ウィンドウサイズが（win）の場合におけるデータパケットの転送速度（T）は、（式１）のように表される。

また、ネットワーク１０が輻輳していない場合におけるRTTをRTTbaseとすると、転送速度（T）は、（式２）のように表される。

TCP Vegasでは、通常、サーバ２００がRTTを繰り返し測定し、測定したRTTの最小値をRTTbaseとして用いる。

一方、ネットワーク１０が輻輳し始めると、ネットワーク１０を構成するルータ１１ａ，１１ｂのキューイング遅延量（Dq）、つまり遅延時間が増加するため、ネットワーク１０の輻輳時におけるデータパケットの転送速度（T'）は、（式３）のように表される。

さらに、TCP Vegasでは、ネットワーク１０の輻輳によるデータパケットの転送速度の変化（Diff）が、（式４）を用いて算出される。

Diff = T - T' …（式４）
また、（Diff）を用いて、Diff×RTTbaseを計算すると（式５）のようになる。

ここで、（T'）は現在のデータパケットの転送速度であり、（Dq）は、ルータ１１ａ，１１ｂのキューイング遅延量（遅延時間）であるから、T'×Dqは、ルータ１１ａ，１１ｂにキューイングされたデータパケットの量を示していることとなる。

TCP Vegasでは、サーバ２００が、Diff×RTTbaseに基づいて、１RTT毎にウィンドウサイズを1データパケットサイズ分ずつ増減することにより、ルータ１１ａ，１１ｂにキューイングされるデータパケットの量を調整する。

具体的には、Diff×RTTbase＜α（αは、デフォルトでは1データパケットサイズ）の場合、ウィンドウサイズを1データパケットサイズ分増大させる。また、β＜Diff×RTTbase（βは、デフォルトでは３データパケットサイズ）の場合、ウィンドウサイズを1データパケットサイズ分減少させる。

しかしながら、TCP Vegasでは、RTTを用いてサーバ２００のパケット送信量を制御するため、下りリンク、つまり、サーバ２００から受信端末３００へのリンク（経路）、或いは、上りリンク、つまり受信端末３００からサーバ２００へのリンクの何れのリンクで輻輳が発生しているのかを区別できないことが問題として指摘されている。なお、以下の説明において、リンク（経路）とは、ネットワーク１０を介して通信装置間を接続する物理的な通信路を指すものとする。

すなわち、上りリンクのみが輻輳している場合においてもRTTが増加するため、サーバ２００は、受信端末３００宛てのデータパケットの送信量、つまり、下りリンクへのパケット送信量を低下させてしまうこととなる。特に、上りリンクの通信帯域が、下りリンクの通信帯域よりも狭い、ADSLやCATVなどの非対象ネットワークにおいて、このような問題が発生し易い。

そこで、このような問題に鑑みて、"Delayed Ack"を用い、上りリンクの輻輳を抑制する方法が提案されている（例えば、非特許文献２、３）。

図８（ａ）及び（ｂ）は、"Delayed Ack"が用いられない場合と、"Delayed Ack"が用いられる場合とのTCPの通信シーケンスの概略をそれぞれ示している。"Delayed Ack"が用いられない場合、受信端末３００は、サーバ２００から送信されたデータパケットのシーケンス（Seq#3〜#5）毎に、Ackパケットをサーバ２００に送信する。

一方、"Delayed Ack"が用いられる場合、受信端末３００は、サーバ２００から送信されたデータパケットのシーケンス毎にはAckパケットを送信せず、複数のシーケンス分ごとに、Ackパケットをサーバ２００に送信する。このように、Ackパケット数を低減することにより、上りリンクの輻輳を抑制することができる。
Lawrence S. Brakmo, Sean W. O'Malley, and Larry L. Peterson、"TCP Vegas: new techniques for congestion detection and avoidance"、ACM SIGCOMM、1994年10月 長谷川 剛、村田 正幸、宮原 秀夫、"非対称なネットワークにおけるTCPの性能評価"、電子情報通信学会技術研究報告、(CQ97−68)、pp. 69-76、1997年12月 R. Braden、"Requirements for Internet Hosts -- Communication Layers"、IETF RFC1122、1989年10月

しかしながら、TCP Vegasでは、上述した"Delayed Ack"を用いてAckパケット数を低減した場合でも、他のトラフィックに起因する上りリンクの輻輳が発生すると、サーバ２００が、データパケットの送信量を低下させてしまい、下りリンクの通信帯域を効率的に利用することができないという問題があった。

例えば、図７に示すように、サーバ２１０から受信端末３１０へのトラフィックにより、ルータ１１ｂからルータ１１ａの方向のリンクにおいて輻輳が発生した場合、サーバ２００が測定するRTTが増加するため、ルータ１１ａからルータ１１ｂの方向のリンクにおいては輻輳が発生していなくても、サーバ２００は、増加したRTTに応じてパケット送信量を低下させてしまうこととなる。

ここで、上述したTCP Vegasの問題の原因について説明する。サーバ２００と受信端末３００との間のRTTを下りリンクと上りリンクとに分離すると、ネットワーク１０が輻輳していない場合におけるRTTbaseは、（式６）のように表される。

RTTbase = RTTbase_down + RTTbase_up …（式６）
ここで、RTTbase_down、RTTbase_upは、ネットワーク１０が輻輳していない場合の下りリンクの伝播時間と、上りリンクの伝播時間とをそれぞれ表している。

次に、下りリンクのキューイング遅延量を（Dq_down）、上りリンクのキューイング遅延量を（Dq_up）とすると、（Dq）は、（式７）のように表される。

Dq = Dq_down + Dq_up …（式７）
次に、上述した（式６）及び（式７）を用いると、（式２）、（式３）は以下のように表される。

なお、転送速度（T）は、ネットワーク１０が輻輳していない場合において、サーバ２００から送信されたデータパケットの転送速度である。また、転送速度（T'）は、ネットワーク１０が輻輳し始めた場合において、サーバ２００から送信されたデータパケットの転送速度である。

次に、（式２'）及び（式３'）を用いると、（式５）は以下のように表される。

Diff×RTTbase = T'×（Dq_down + Dq_up） …（式５'）
ここで、（式５'）の内容に着目すると、転送速度（T'）は、下りリンク、つまりサーバ２００から受信端末３００へのデータパケットの転送速度であるにも拘わらず、上りリンクのキューイング遅延量（Dq_up）を含んでおり、下りリンクの転送速度を正確に算出することができないこととなる。

すなわち、TCP Vegasでは、（式６）及び（式７）において、上りリンクのキューイング遅延量（Dq_up）を含めて転送速度（T'）が決定されるため、下りリンクと、上りリンクとの輻輳を区別することができない。

さらに他の問題として、上述した"Delayed Ack"では、受信端末３００が、上りリンクの輻輳の状態に応じて、Ackパケットの送信の頻度を動的に調整することができないという問題があった。

そこで、本発明は、以上の点に鑑みてなされたもので、TCPを用いてパケット送信量を制御する場合において、上りリンクならびに下りリンクへのパケット送信量を各リンクの輻輳の状態に応じて、それぞれ独立して制御することができるパケット送信量制御方法、通信システム、通信装置及びプログラムを提供することをその目的とする。

上述した課題を解決するため、本発明は、次のような特徴を有している。まず、本発明の第１の特徴は、第１の通信装置が、第２の通信装置からパケットを受信したパケット受信時刻と、前記第２の通信装置において付加された前記パケットの送信時刻を示すパケット送信時刻情報とに基づいて、前記第２の通信装置によって送信された前記パケットが前記第１の通信装置に到達するまでの遅延量を測定するステップと、前記第１の通信装置が、測定した複数の前記遅延量の中から、最小遅延量を決定するステップと、前記第１の通信装置が、前記遅延量と、前記最小遅延量との差に基づいて、前記第２の通信装置から前記第１の通信装置への経路において発生している変動遅延量を決定するステップと、前記第２の通信装置が、前記第１の通信装置から受信したパケットに付加されている前記変動遅延量を示す変動遅延量情報に基づいて、前記第１の通信装置に送信するパケットの送信量を制御するステップとを備えるパケット送信量制御方法であることを要旨とする。

本発明の第２の特徴は、第１の通信装置と、第２の通信装置とによって構成される通信システムであって、前記第１の通信装置が、前記第２の通信装置からパケットを受信したパケット受信時刻と、前記第２の通信装置において付加された前記パケットの送信時刻を示すパケット送信時刻情報とに基づいて、前記第２の通信装置によって送信された前記パケットが前記第１の通信装置に到達するまでの遅延量を測定する遅延量測定部と、測定した複数の前記遅延量の中から、最小遅延量を決定する最小遅延量決定部と、前記遅延量と、前記最小遅延量との差に基づいて、前記第２の通信装置から前記第１の通信装置への経路において発生している変動遅延量を決定する変動遅延量決定部とを備え、前記第２の通信装置が、前記第１の通信装置から受信したパケットに付加されている前記変動遅延量を示す変動遅延量情報に基づいて、前記第１の通信装置に送信するパケットの送信量を制御するパケット送信量制御部とを備えることを要旨とする。

かかる特徴によれば、第１の通信装置が備える変動遅延量決定部が、第２の通信装置から第１の通信装置の方向において発生している変動遅延量（キューイング遅延量）を決定し、第２の通信装置が備えるパケット送信量制御部が、変動遅延量に基づいて、第１の通信装置に送信するパケットの送信量を制御するため、逆方向、つまり、第１の通信装置から第２の通信方向において発生している変動遅延量に影響されることなく、第１の通信装置に送信するパケットの送信量を制御することができる。

すなわち、かかる特徴によれば、上りリンクと下りリンクの輻輳を区別できないという従来のTCP Vegasの問題点が解決され、通信装置が、上りリンクならびに下りリンクへのパケット送信量を各リンクの輻輳の状態に応じてそれぞれ独立して制御することにより、各リンクの実効通信帯域を常に最大限に利用することができる。

本発明の第３の特徴は、本発明の第２の特徴において、前記パケット送信量制御部が、前記第１の通信装置において付加された前記変動遅延量情報と、一度に前記第１の通信装置から送信されたパケットの数を示す送信パケット数情報とに基づいて、前記第２の通信装置に送信する応答パケットの送信量を制御することを要旨とする。

かかる特徴によれば、パケット量送信量制御部が、変動遅延量情報と、送信パケット数情報とに基づいて、応答パケット、つまりAckパケットの送信量を制御するため、通信装置は、ネットワークの輻輳の状態に応じつつ、送信側の通信装置から送信されたデータパケットの数に対して、送信するAckパケットの数を調整することができる。

すなわち、かかる特徴によれば、上りリンクの輻輳の状態に応じて、Ackパケットの送信の頻度を動的に調整しつつ"Delayed Ack"を用いることができる。この結果、通信装置は、上りリンクの輻輳を発生させない範囲で、できるだけ多くのAckパケットを送信することにより、"Delayed Ack"を用いない場合と同等の精度でパケット送信量の制御（フロー制御）を行うことができる。

本発明の第４の特徴は、通信システムにおいて用いられる通信装置であって、相手先通信装置からパケットを受信したパケット受信時刻と、前記相手先通信装置において付加された前記パケットの送信時刻を示すパケット送信時刻情報とに基づいて、前記相手先通信装置によって送信された前記パケットが前記通信装置に到達するまでの遅延量を測定する遅延量測定部と、測定した複数の前記遅延量の中から、最小遅延量を決定する最小遅延量決定部と、前記遅延量と、前記最小遅延量との差に基づいて、前記相手通信装置から前記通信装置への経路において発生している変動遅延量を決定する変動遅延量決定部とを備えることを要旨とする。

本発明の第５の特徴は、通信システムにおいて用いられる通信装置であって、前記通信装置から相手先通信装置への経路において発生している変動遅延量に基づいて、前記相手先通信装置に送信するパケットの送信量を制御するパケット送信量制御部を備えることを要旨とする。

本発明の第６の特徴は、本発明の第５の特徴において、前記パケット送信量制御部が、前記変動遅延量と、一度に前記相手先通信装置から送信されたパケットの数を示す送信パケット数情報とに基づいて、前記相手先通信装置に送信する応答パケットの送信量を制御することを要旨とする。

本発明の第７の特徴は、通信装置において実行されるプログラムであって、前記通信装置に、相手先通信装置からパケットを受信したパケット受信時刻と、前記相手先通信装置において付加された前記パケットの送信時刻を示すパケット送信時刻情報とに基づいて、前記相手先通信装置によって送信された前記パケットが前記通信装置に到達するまでの遅延量を測定する遅延量測定処理と、測定した複数の前記遅延量の中から、最小遅延量を決定する最小遅延量決定処理と、前記遅延量と、前記最小遅延量との差に基づいて、前記相手通信装置から前記通信装置への経路において発生している変動遅延量を決定する変動遅延量決定処理とを実行させることを要旨とする。

本発明の第８の特徴は、通信装置において実行されるプログラムであって、前記通信装置に、前記通信装置から相手先通信装置への経路において発生している変動遅延量に基づいて、前記相手先通信装置に送信するパケットの送信量を制御するパケット送信量制御処理を実行させることを要旨とする。

本発明の第９の特徴は、本発明の第８の特徴において、前記パケット送信量制御処理では、前記変動遅延量と、一度に前記相手先通信装置から送信されたパケットの数を示す送信パケット数情報とに基づいて、前記相手先通信装置に送信する応答パケットの送信量が制御されることを要旨とする。

本発明によれば、TCPを用いてパケット送信量を制御する場合において、上りリンクならびに下りリンクへのパケット送信量を各リンクの輻輳の状態に応じて、それぞれ独立して制御することができるパケット送信量制御方法、通信システム、通信装置及びプログラムを提供することができる。

以下、図面を参照しながら、本発明の実施形態について説明する。まず、図１及び図２を参照して、本発明の実施形態に係る通信システムの構成、及びパケット送信量を制御するために用いられる数式などについて説明する。

（通信システムの構成）
図１は、本実施形態に係る通信システムの構成を示している。同図に示すように、本実施形態に係る通信システムは、サーバ２０と、受信端末３０とから構成され、サーバ２０と、受信端末３０とは、ルータ１１ａ及びルータ１１ｂによって構成されるネットワーク１０を介して接続されている。また、本実施形態において、サーバ２０と受信端末３０とは、通信装置を構成する。なお、通信装置としては、ネットワークに接続することができるサーバコンピュータ、PC、携帯情報端末（PDA）、携帯電話端末などを用いることができる。

サーバ２０は、ネットワーク１０を介して受信端末３０に向けてIPパケット（データパケット）を送信するものであり、受信端末３０との間において、TCPを用いてIPパケットの送信量を制御する機能を有している。

受信端末３０は、ネットワーク１０を介して、サーバ２０から送信されたIPパケットを受信し、TCPを用いてAckパケット（応答パケット）を送信する機能を有している。

また、本実施形態では、サーバ２０と受信端末３０とが、下りリンクの輻輳と、上りリンクとの輻輳とを区別し、各リンクの輻輳の状況に応じて、各リンクへのパケット送信量を制御する。

（下りリンクへのパケット送信量の制御）
次に、上述した通信システムにおいて、サーバ２０のパケット送信量を制御するために用いられる数式、及び変数などについて説明する。

図２は、サーバ２０のパケット送信量を制御するために用いられる主要な変数などを示している。同図に示すように、本実施形態では、サーバ２０のパケット送信量を制御するために、下り方向、つまり受信端末３０へのデータパケットの送信時刻（t_down）、受信端末３０が当該データパケットを受信したパケット受信時刻（s_down）、下りリンクのRelative Time Delay(RTD_down)、ネットワーク１０の輻輳によって発生する下りリンクのキューイング遅延量（Dq_down）などが用いられる。

まず、上述したように、TCP Vegasでは、上りリンクのキューイング遅延量（Dq_up）を含めて、転送速度（T'）が決定されるため、下りリンクと、上りリンクとの輻輳を区別することができない。

そこで、かかる問題を解決するためには、上述した（式６）、（式７）を以下のように変更すればよい。

RTTbase_proposal = RTTbase_down + RTTbase_up + Dq_up …（式６"）
Dq_proposal = Dq_down …（式７"）
すなわち、上りリンクのキューイング遅延量（Dq_up）を、RTTに含めて扱うようにする。（式６"）、（式７"）を用いると、（式２）、（式５）は以下のように表される。

上述した式を用いれば、下りリンクの輻輳の状態のみを評価することができる。

次に、（RTTbase_proposal）と（Dq_proposal）の算出方法について説明する。上りリンクと下りリンクとの輻輳を区別するためには、（RTTbase_down）、（RTTbase_up）、（Dq_down）、（Dq_up）などの変数を直接測定することが望ましいが、一般に送信側の通信装置（サーバ２０）と、受信側の通信装置（受信端末３０）とのそれぞれの時計が計時する時刻の不一致が問題となり、上述した変数を直接測定することは困難である。

例えば、サーバ２０がデータパケットを送信した時刻（t_down）と、受信端末３０が当該データパケットを受信した時刻（s_down）とに基づいて、サーバ２０から受信端末３０までのデータパケットの伝播時間（RTT_down）を測定する際に、受信端末３０の時計が、サーバ２０の時計よりもΔt進んでいる場合、（式８）に示すように、（RTT_down）を測定することができない。

s_down―t_down = RTT_down + Δt …（式８）
そこで、本実施形態では、サーバ２０と受信端末３０とが、（RTTbase_proposal）を間接的に測定する。まず、（式６"）は、（式９）のように変更することができる。

RTTbase_proposal = RTTbase_down + RTTbase_up + Dq_up
= RTT - Dq_down …（式９）
ここで、RTTは、サーバ２０が、従来の方法を用いて測定することができる。したがって、（式７"）、（式９）より、（Dq_down）が測定できれば、下りリンクの輻輳の状態を評価することができる。

本実施形態では、（Dq_down）を測定するため、Relative Time Delay（RTD）が用いられる。サーバ２０と、受信端末３０とのそれぞれの時計が計時する時刻は一致していないが、それぞれの時計が正確であれば、計時する時刻のずれ幅Δtは、常に一定である。

そこで、サーバ２０は、送信するデータパケットに、当該データパケットの送信時刻（t_down）を付加する。次に、受信端末３０は、（t_down）と、当該データパケットの受信時刻（s_down）とを用いて、（式８）による計算を行う。

すなわち、下りリンクのRelative Time Delay（RTD_down）は、（式１０）のように表される。なお、（t_down）は、例えば、RFC1323 "TCP Extension for High Performance"において規定されるTimestampオプションを用いてデータパケットに付加することができる。

RTD_down = s_down - t_down = RTT_down + Δt …（式10）
受信端末３０は、（RTD_down）を繰り返し測定する。さらに、測定された（RTD_down）の中で、最小の値を有する（RTD_down）をMin（RTD_down）とすると、以下のような関係があると考えられる。

Min(RTD_down) = Min(RTT_down) + Δt
= RTTbase_down + Δt …（式11）
RTT_down = RTTbase_down + Dq_Downであるため、（式１０）、（式１１）を用いれば、（式１２）により、（Dq_down）を算出することができる。

Dq_down = RTT_down - RTTbase_down
= RTD_down - Min(RTD_down) …（式12）
上述した手順により、RTTと、（Dq_down）とが決定されるため、下りリンクの輻輳の状態を正確に評価することができる。

（上りリンクへのパケット送信量の制御）
次に、上述した通信システムにおいて、受信端末３０のパケット送信量、具体的には、"delayed Ack"を用いつつ、上りリンクの輻輳の状態に応じてAckパケットの送信頻度を調整するために用いられる数式、及び変数などについて説明する。

図２に示すように、本実施形態では、受信端末３０のパケット送信量を制御するために、上り方向、つまりサーバ２０へのAckパケットの送信時刻（t_up）、サーバ２０が当該Ackパケットを受信したパケット受信時刻（s_up）、上りリンクのRelative Time Delay(RTD_up)、ネットワーク１０の輻輳によって発生する上りリンクのキューイング遅延量（Dq_up）などが用いられる。

受信端末３０のパケット送信量を制御する手順は、上述したサーバ２０のパケット送信量を制御する手順と同様である。但し、上りリンクの輻輳の状態を評価する場合、上りリンクの変動遅延をネットワーク１０の輻輳による遅延と見なすために、（式６"）、（式７"）は、以下のように変更される。

RTTbase_proposal = RTTbase_down + RTTbase_up + Dq_down
Dq_proposal = Dq_up
次に、上りリンクの輻輳の状態に応じて、Ackパケットの送信頻度を動的に調整するために用いられる数式などについて説明する。本実施形態では、TCP Vegasに基づいて、Ackパケットの送信量、つまり、上りリンクへのパケット送信量が制御される。上りリンクの場合、Ackの送信速度（T'）は、Ackパケットのサイズを（AckSize）、受信端末３０が１ウィンドウ中に送信するAckパケットの数を（M）とすると、（式１３）のように表される。

受信端末３０が、（式１３）を用いてAckパケット送信速度（T'）を算出し、上述したサーバ２０のパケット送信量の制御する手順を用いれば、（式５"）により、ルータ１１ａ，１１ｂのキューイングされているAckパケットの量を算出することができる。

また、サーバ２０は、1ウィンドウ中にN個のデータパケットを送信しており、受信端末３０は、N個のデータパケットに対して、M個のAckパケットを送信するものとする（0＜M＜N）。また、サーバ２０は、常に現在のウィンドウ内データパケット数（N）を受信端末３０に通知する。

受信端末３０は、上りリンクの輻輳の状況を評価するために、（式１３）を用いてAckパケット送信速度（T'）と、（式５"）を用いて、Diff×RTTbaseとを算出する。TCP Vegasでは、Diff×RTTbaseの値に応じて、ウィンドウサイズを1データパケットサイズ分ずつ増減する。上りリンクにおいても、TCP Vegasの動作に準じて、以下のようにAckパケットの送信頻度が制御される。

（1） Diff×RTTbase＜α（αは、デフォルトでは1データパケットサイズ）
Mを"１"増加
（2）β＜Diff×RTTbase（βは、デフォルトでは3データパケットサイズ）
Mを"１"減少
受信端末３０は、Ackパケットの送信頻度を上述したように調整することにより、上りリンクの輻輳を発生させない範囲で、できるだけ多くのAckパケットを送信することができ、サーバ２０と受信端末３０とは、"Delayed Ack"を用いない場合と同等の精度でパケット送信量の制御（フロー制御）を行うことができる。

なお、上りリンクにおいては、下りリンクにおいて用いられる（α）、（β）の値と異なる値が選択されることも考えられる。例えば、情報伝達という観点からは、Ackパケットよりもデータパケットが重要であるとも考えられるため、そのような場合には、上りリンクの（α）、（β）の値を、下りリンクの（α）、（β）の値よりも小さくすればよい。上りリンクの（α）、（β）の値が小さくなると、Ackパケット送信個数（M）が小さくなり易くなるため、送信されるAckパケットの送信頻度が低下する。

上述した手順によれば、受信端末３０は、上りリンクの輻輳の状態に応じてAckパケットの送信頻度を制御することができる。また、図７に示したように、サーバ２００と受信端末３００との間における上りリンクとして使用されているリンクが、サーバ２１０と受信端末３１０との間における下りリンクとして使用されている場合が発生し得る。このようなボトルネックリンクが、複数の通信装置によって共用されている場合、各通信装置が協調してパケットの送信量を制御し、ボトルネックリンクが輻輳しないようにすることが重要である。上述した手順によれば、このようなボトルネックリンクにおいても、各通信装置が、リンクの輻輳の状態に応じて、適切にパケット送信量を制御することができる。

さらに、上述した手順によれば、上りリンクが複数の通信装置によって共用されている場合においても、Ackパケットが、他のトラフィックの疎通を妨げるという従来技術の問題点が解決される。

なお、"Delayed Ack"により、Ackパケットの送信頻度が低下すると、受信端末３０からサーバ２０への応答の頻度が減り、また、１つのAckパケットで大量のデータパケットの到達が確認されるため、サーバ２０が、Ackパケットを受信次第、大量のデータパケットをバースト的に送信する可能性が高まる。ネットワーク１０に多数のサーバや端末などの通信装置が接続されている場合、Ackパケットの受信に伴うバースト的なデータパケットの送信が、ネットワーク１０に一時的に過大な負荷をかけ、ネットワーク１０が輻輳することがある。したがって、Ackパケットの送信頻度が連続して低下しないように、Ackパケットの送信頻度を適切に制御する必要がある。

（サーバ２０及び受信端末３０の論理ブロック構成）
次に、上述したパケット送信量の制御を実行するサーバ２０及び受信端末３０の論理ブロック構成について、図３を参照しながら説明する。

同図に示すように、サーバ２０は、パケット送信部２１と、パケット受信部２２と、付加情報挿入部２３と、遅延計算部２４と、ウィンドウサイズ制御部２５とを備えている。

パケット送信部２１は、ネットワーク１０を介して、IPパケット（データパケット）を受信端末３０に送信するものである。また、パケット送信部２１は、ウィンドウサイズ制御部２５による制御に基づいて、1ウィンドウに含まれるIPパケット数を変更する。

パケット受信部２２は、ネットワーク１０を介して、IPパケット（Ackパケット）を受信端末３０から受信するものである。また、パケット受信部２２は、Ackパケットに付加されている下りリンクキューイング遅延量（Dq_down）情報や上りリンクへのパケット送信時刻（t_up）情報を、Ackパケットの受信時刻（s_up）とともに遅延計算部２４に転送する。

付加情報挿入部２３は、下り方向へのデータパケットの送信時刻（t_down）情報と、上りリンクのキューイング遅延量（Dq_up）情報と、送信パケット数（N）情報とをデータパケットに付加するものである。なお、送信パケット数（N）は、サーバ２０が、1RTT内に送信するデータパケットの個数であり、現在のウィンドウサイズをデータパケットのサイズで除算することにより、算出することができる。

遅延計算部２４は、Ackパケット受信時刻（s_up）と、Ackパケット送信時刻（t_up）情報とに基づいて、受信端末３０によって送信されたAckパケットがサーバ２０に到達するまでの遅延量（RTD_up）を測定するものである。

また、遅延計算部２４は、測定した複数の（RTD_up）の中から、最小遅延量（Min(RTD_up)）を決定するものである。さらに、遅延計算部２４は、（RTD_up）と、（Min(RTD_up)）との差に基づいて、受信端末３０からサーバ２０へのリンクにおいて発生している変動遅延量、すなわちキューイング遅延量（Dq_up）を決定するものである。また、遅延計算部２４は、（t_down）と（s_up）とからRTTを計算する。

なお、本実施形態において、遅延計算部２４は、遅延量測定部と、最小遅延量測定部と、変動遅延量決定部とを構成する。

ウィンドウサイズ制御部２５は、受信端末３０から受信したAckパケットに付加されているキューイング遅延量（Dq_down）情報に基づいて、受信端末３０に送信するパケットの送信量を制御するものである。なお、パケットの送信量の制御は、上述した手順に基づいて実行される。また、本実施形態において、パケット送信部２１とウィンドウサイズ制御部２５とは、パケット送信量制御部を構成する。

さらに、付加情報挿入部２３と、遅延計算部２４と、ウィンドウサイズ制御部２５とは、通信ネットワークを介してダウンロードしたり、CD-ROMなどの記憶媒体に記憶したりすることができるプログラムとしても提供することができる。

受信端末３０は、パケット受信部３１と、パケット送信部３２と、付加情報挿入部３３と、遅延計算部３４と、Ackパケット送信回数決定部３５とを備えている。

パケット受信部３１は、ネットワーク１０を介して、IPパケット（データパケット）をサーバ２０から受信するものである。また、パケット受信部３１は、データパケットに付加されている上りリンクキューイング遅延量（Dq_up）情報や下りリンクへのパケット送信時刻（t_down）情報を、データパケットの受信時刻（s_down）とともに遅延計算部３４に転送する。

パケット送信部３２は、ネットワーク１０を介して、IPパケット、特に本実施形態では、Ackパケットをサーバ２０に送信するものである。また、パケット送信部３２は、Ackパケット送信回数決定部３５による制御に基づいて、Ackパケットの送信頻度を変更する。

付加情報挿入部３３は、上り方向へのデータパケットの送信時刻（t_up）情報と、下りリンクのキューイング遅延量（Dq_down）情報とをAckパケットに付加するものである。

遅延計算部３４は、データパケット受信時刻（s_down）と、データパケット送信時刻（t_down）情報とに基づいて、サーバ２０によって送信されたデータパケットが受信端末３０に到達するまでの遅延量（RTD_down）を測定するものである。

また、遅延計算部３４は、測定した複数の（RTD_down）の中から、最小遅延量（Min(RTD_down)）を決定するものである。さらに、遅延計算部３４は、（RTD_down）と、（Min(RTD_down)）との差に基づいて、サーバ２０から受信端末３０へのリンクにおいて発生している変動遅延量、すなわちキューイング遅延量（Dq_down）を決定するものである。また、遅延計算部３４は、（t_up）と（s_down）とからRTTを計算する。

なお、本実施形態において、遅延計算部３４は、遅延量測定部と、最小遅延量測定部と、変動遅延量決定部とを構成する。

Ackパケット送信回数決定部３５は、サーバ２０から受信したデータパケットに付加されているキューイング遅延量（Dq_up）情報に基づいて、サーバ２０に送信するパケットの送信量を制御するものである。具体的には、Ackパケット送信回数決定部３５は、キューイング遅延量（Dq_up）情報と、一度にサーバ２０から送信されたパケットの数、すなわち1ウィンドウ内のデータパケット数を示す送信パケット数（N）情報とに基づいて、サーバ２０に送信するAckパケットの送信量を制御する。

なお、Ackパケットの送信量の制御は、上述した手順に基づいて実行される。また、本実施形態において、パケット送信部３２とAckパケット送信回数決定部３５とは、パケット送信量制御部を構成する。

さらに、付加情報挿入部３３と、遅延計算部３４と、Ackパケット送信回数決定部３５とは、通信ネットワークを介してダウンロードしたり、CD-ROMなどの記憶媒体に記憶したりすることができるプログラムとしても提供することができる。

（下りリンクへのパケット送信量の制御方法）
次に、図４を参照して、下りリンクへのパケット送信量の制御方法、つまり、サーバ２０から受信端末３０に対して送信されるデータパケットの送信量を制御する方法について説明する。本制御方法では、1RTTごとに、Relative Time Delay（RTD）を測定するための情報を付加する形態を例として説明する。

まず、ステップＳ１０において、サーバ２０は、送信パケット数（N）情報と、データパケットの送信時刻（t_down）情報とをデータパケットに付加する。

ステップＳ２０において、サーバ２０は、ステップＳ１０において情報が付加されたデータパケットを受信端末３０に送信する。

ステップＳ３０において、サーバ２０は、データパケットの送信時刻（t_down）情報を保持する。

ステップＳ４０において、受信端末３０は、サーバ２０によって送信されたデータパケットを受信する。

ステップＳ５０において、受信端末３０は、受信したデータパケットに付加されている送信パケット数（N）情報と、データパケットの送信時刻（t_down）情報とを取得する。

ステップＳ６０において、受信端末３０は、データパケットの受信時刻（s_down）と、データパケットに付加されている送信時刻（t_down）情報から、下りリンクのRTD（RTD_down）を上述した（式１０）を用いて計算する。

ステップＳ７０において、受信端末３０は、下りリンクのキューイング遅延量（Dq_down）を上述した（式１２）を用いて計算する。なお、本実施形態では、受信端末３０は、下りリンクのRTD（RTD_down）の最小値（Min(RTD_down)）を保持しているものとする。

ステップＳ８０において、受信端末３０は、下りリンクのキューイング遅延量（Dq_down）情報と、Ackパケットの送信時刻（t_up）情報をAckパケットに付加する。なお、Ackパケットの送信時刻（t_down）は、上述したように、Timestampオプションを用いてAckパケットに付加することができる。

ステップＳ９０において、受信端末３０は、ステップＳ８０において情報が付加されたAckパケットを受信端末３０に送信する。なお、当該情報が付加されたAckパケットは、"Delayed Ack"を用いることなく、直ちにサーバ２０に送信される。

ステップＳ１００において、サーバ２０は、受信端末３０によって送信されたAckパケットを受信する。

ステップＳ１１０において、サーバ２０は、ステップＳ３０において保持したデータパケットの送信時刻（t_down）情報と、Ackパケットの受信時刻からRTTを計算する。

ステップＳ１２０において、サーバ２０は、Ackパケットに付加されている下りリンクのキューイング遅延量（Dq_down）情報を取得する。

ステップＳ１３０において、サーバ２０は、Diff×RTTbaseを上述した（式５"）及び（式９）を用いて計算する。

ステップＳ１４０において、サーバ２０は、ステップＳ１３０において計算された結果に基づいて、送信ウィンドウサイズを制御する。具体的には、サーバ２０は、上述したTCP Vegasによる方法を用い、Diff×RTTbase＜α（αは、デフォルトでは1データパケットサイズ）の場合、ウィンドウサイズを1データパケットサイズ分増大させる。また、β＜Diff×RTTbase（βは、デフォルトでは3データパケットサイズ）の場合、ウィンドウサイズを1データパケットサイズ分減少させる。

（上りリンクへのパケット送信量の制御方法）
次に、図５を参照して、上りリンクへのパケット送信量の制御方法、つまり、受信端末３０からサーバ２０に対して送信されるAckパケットの送信頻度を、"Delayed Ack"を用いつつ調整する方法について説明する。本制御方法では、上述した下りリンクへのパケット送信量の制御方法と同様に、1RTTごとに、RTDを測定するための情報を付加する形態を例として説明する。

ここでは、上述したステップＳ９０の処理、すなわち、受信端末３０が、サーバ２０にAckパケットを送信する処理から説明する。ステップＳ９０において、受信端末３０が、サーバ２０に送信するAckパケットには、上述したステップＳ８０において、下りリンクのキューイング遅延量（Dq_down）情報と、Ackパケットの送信時刻（t_up）情報とが付加されている。

ステップＳ９１において、受信端末３０は、Ackパケットの送信時刻（t_up）情報を保持する。

ステップＳ１００において、サーバ２０は、受信端末３０によって送信されたAckパケットを受信する。

次に、ステップＳ２００において、サーバ２０は、受信したAckパケットに付加されているAckパケットの送信時刻（t_up）情報を取得する。

ステップＳ２１０において、サーバ２０は、Ackパケットの受信時刻（s_up）と、データAckパケットに付加されている送信時刻（t_up）情報から、上りリンクのRTD（RTD_up）を上述した（式１０）と同様の式を用いて計算する。

ステップＳ２２０において、サーバ２０は、上りリンクのキューイング遅延量（Dq_up）を上述した（式１２）と同様の式を用いて計算する。なお、本実施形態では、サーバ２０は、上りリンクのRTD（RTD_up）の最小値（Min（RTD_up））を保持しているものとする。

ステップＳ２３０において、サーバ２０は、送信パケット数（N）情報と、データパケットの送信時刻（t_down）情報と、上りリンクのキューイング遅延量（Dq_up）情報とをデータパケットに付加する。

ステップＳ２４０において、サーバ２０は、ステップＳ２３０において情報が付加されたAckパケットを受信端末３０に送信する。

ステップＳ２５０において、サーバ２０は、データパケットの送信時刻（t_down）情報を保持する。

ステップＳ２６０において、受信端末３０は、サーバ２０によって送信されたデータパケットを受信する。

ステップＳ２７０において、受信端末３０は、受信したデータパケットに付加されている送信パケット数（N）報報に基づいて、上述したステップＳ５０において取得した送信パケット数（N）報報を更新する。

ステップＳ２８０において、受信端末３０は、ステップＳ９１において保持したAckパケットの送信時刻（t_up）情報と、データパケットの受信時刻（s_down）からRTTを計算する。

ステップＳ２９０において、受信端末３０は、データパケットに付加されている上りリンクのキューイング遅延量（Dq_up）情報を取得する。

ステップＳ３００において、受信端末３０は、Diff×RTTbaseを上述した（式５"）及び（式９）と同様の式を用いて計算する。

ステップＳ３１０において、受信端末３０は、ステップＳ３００において計算された結果に基づいて、Ackパケットの送信頻度を調整する。具体的には、受信端末３０は、上述した手順を用い、Diff×RTTbase＜α（αは、デフォルトでは1データパケットサイズ）の場合、サーバ２０から送信されたN個のデータパケットに対してM個のAckパケットを送信するとしている場合、Mの値を"1"増加させる。また、β＜Diff×RTTbase（βは、デフォルトでは3データパケットサイズ）の場合、Mの値を"1"減少させる。

上述した制御方法によれば、（Dq）などの情報が付加されたパケットが、サーバ２０と受信端末３０との間でキャッチボールのように送受されるため、1RTTに1回の頻度でサーバ２０と受信端末３０とが、パケット送信量を制御することができる。また、当該情報が付加されたパケットが、ネットワーク１０上において破棄されると、RTTやRTDが測定できなくなるため、1RTT内において送信される複数のパケットに（Dq）などの情報を付加して、サーバ２０と受信端末３０との間で送受するようにすることも勿論可能である
さらに、"Delayed Ack"を用いた場合において、受信端末３０がAckパケットを送信するまでの待ち時間や、破棄されたAckパケットの次のAckパケットを受信するまでの時間が、サーバ２０によって測定されるRTTに含まれると、正確な転送速度（T'）が算出できなくなることが問題点として指摘（例えば、Chengpeng Fu and Soung C. Liew、"A Remedy for Performance Degradation of TCP Vegas in Asymmetric Networks"、IEEE communication letter 2002）されている。

上述した制御方法によれば、（Dq）などの情報が付加されたAckパケットは、ステップＳ９０において説明したように、"Delayed Ack"を用いることなく、直ちにサーバ２０に送信されるため、Ackパケットを送信するまでの待ち時間や、破棄されたAckパケットの次のAckパケットを受信するまでの時間が、サーバ２０によって測定されるRTTに含まれることを回避することでき、サーバ２０と受信端末３０とは、正確な転送速度（T'）を算出することができる。

（作用・効果）
本実施形態によれば、上りリンクと下りリンクの輻輳を区別できないという従来のTCP Vegasの問題点が解決され、サーバ２０と受信端末３０が、上りリンクならびに下りリンクへのパケット送信量を各リンクの輻輳の状態に応じてそれぞれ独立して制御することにより、各リンクの実効通信帯域を常に最大限に利用することができる。

本実施形態によれば、受信端末３０が、（Dq_up）と、送信パケット数（N）情報とに基づいて、Ackパケットの送信頻度を調整するため、受信端末３０は、ネットワーク１０の輻輳の状態に応じつつ、サーバ２０から送信されたデータパケットの数に対して、送信するAckパケットの数を調整することができる。

（変更例）
上述した本発明の実施形態においては、サーバ２０と受信端末３０とが、それぞれパケットの送信量を制御する形態について説明したが、本発明は、図６に示すような通信システムにおいても適用することができる。

同図に示すように、ネットワーク１０には、ネットワーク１２を介してサーバ２６と、ネットワーク１３を介して、サーバ２７とがそれぞれ接続されている。また、サーバ２６には受信端末３６が、サーバ２７には受信端末３７が、それぞれ接続されている。

同図に示すような通信システムでは、サーバ２６とサーバ２７との間において、上述したようなパケット送信量の制御方法を用いることができる。また、サーバ２６と受信端末３６との間や、サーバ２７と受信端末３７との間において、かかる制御方法を用いることも勿論可能である。

さらに、ルータ１１ａ，１１ｂが、TCP層の処理を実行することができる場合、例えば、マルチレイヤスイッチである場合、ルータ１１ａとサーバ２６との間や、ルータ１１ｂとサーバ２７との間において、かかる制御方法を用いてもよい。

すなわち、本発明は、TCP層の処理を実行することができる通信装置、機器、端末、ノードなどに適用することができる。

本発明の実施形態に係る通信システムの構成を示す図である。 本発明の実施形態に係る通信システムにおいてパケット送信量を制御するために用いられる変数などを示す図である。 本発明の実施形態に係る通信システムの論理ブロック構成を示す図である。 本発明の実施形態に係るパケット送信量の制御フローを示す図である。 本発明の実施形態に係るパケット送信量の制御フローを示す図である。 本発明の変更例に係る通信システムの構成を示す図である。 従来の通信装置によって構成される通信システムを示す図である。 従来の"Delayed Ack"の処理の概念を示す図である。

符号の説明

１０…ネットワーク、１１ａ，１１ｂ…ルータ、１２，１３…ネットワーク、２０…サーバ、２１…パケット送信部、２２…パケット受信部、２３…付加情報挿入部、２４…遅延計算部、２５…ウィンドウサイズ制御部、２６，２７…サーバ、３０…受信端末、３１…パケット受信部、３２…パケット送信部、３３…付加情報挿入部、３４…遅延計算部、３５…Ackパケット送信回数決定部、３６，３７…受信端末、２００，２１０…サーバ、３００，３１０…受信端末

Claims (7)

1. 第１の通信装置が、第２の通信装置からパケットを受信したパケット受信時刻と、前記第２の通信装置において付加された前記パケットの送信時刻を示すパケット送信時刻情報とに基づいて、前記第２の通信装置によって送信された前記パケットが前記第１の通信装置に到達するまでの遅延量を測定するステップと、
   前記第１の通信装置が、測定した複数の前記遅延量の中から、最小遅延量を決定するステップと、
   前記第１の通信装置が、前記遅延量と、前記最小遅延量との差に基づいて、前記第２の通信装置から前記第１の通信装置への経路において発生している変動遅延量を決定するステップと、
   前記第２の通信装置が、前記第１の通信装置から受信したパケットに付加されている前記変動遅延量を示す変動遅延量情報に基づいて、前記第１の通信装置に送信するパケットの送信量を制御するステップと
   を備えることを特徴とするパケット送信量制御方法。
2. 第１の通信装置と、第２の通信装置とによって構成される通信システムであって、
   前記第１の通信装置は、
   前記第２の通信装置からパケットを受信したパケット受信時刻と、前記第２の通信装置において付加された前記パケットの送信時刻を示すパケット送信時刻情報とに基づいて、前記第２の通信装置によって送信された前記パケットが前記第１の通信装置に到達するまでの遅延量を測定する遅延量測定部と、
   測定した複数の前記遅延量の中から、最小遅延量を決定する最小遅延量決定部と、
   前記遅延量と、前記最小遅延量との差に基づいて、前記第２の通信装置から前記第１の通信装置への経路において発生している変動遅延量を決定する変動遅延量決定部と
   を備え、
   前記第２の通信装置は、
   前記第１の通信装置から受信したパケットに付加されている前記変動遅延量を示す変動遅延量情報に基づいて、前記第１の通信装置に送信するパケットの送信量を制御するパケット送信量制御部と
   を備えることを特徴とする通信システム。
3. 前記パケット送信量制御部は、前記第１の通信装置において付加された前記変動遅延量情報と、一度に前記第１の通信装置から送信されたパケットの数を示す送信パケット数情報とに基づいて、前記第１の通信装置に送信する応答パケットの送信量を制御することを特徴とする請求項２に記載の通信システム。
4. 通信システムにおいて用いられる通信装置であって、
   相手先通信装置からパケットを受信したパケット受信時刻と、前記相手先通信装置において付加された前記パケットの送信時刻を示すパケット送信時刻情報とに基づいて、前記相手先通信装置によって送信された前記パケットが前記通信装置に到達するまでの遅延量を測定する遅延量測定部と、
   測定した複数の前記遅延量の中から、最小遅延量を決定する最小遅延量決定部と、
   前記遅延量と、前記最小遅延量との差に基づいて、前記相手通信装置から前記通信装置への経路において発生している変動遅延量を決定する変動遅延量決定部と
   を備えることを特徴とする通信装置。
5. 通信システムにおいて用いられる通信装置であって、
   前記通信装置から相手先通信装置への経路において発生している変動遅延量に基づいて、前記相手先通信装置に送信するパケットの送信量を制御するパケット送信量制御部を備え、
   前記パケット送信量制御部は、前記変動遅延量と、一度に前記相手先通信装置から送信されたパケットの数を示す送信パケット数情報とに基づいて、前記相手先通信装置に送信する応答パケットの送信量を制御することを特徴とする通信装置。
6. 通信装置において実行されるプログラムであって、前記通信装置に、
   相手先通信装置からパケットを受信したパケット受信時刻と、前記相手先通信装置において付加された前記パケットの送信時刻を示すパケット送信時刻情報とに基づいて、前記相手先通信装置によって送信された前記パケットが前記通信装置に到達するまでの遅延量を測定する遅延量測定処理と、
   測定した複数の前記遅延量の中から、最小遅延量を決定する最小遅延量決定処理と、
   前記遅延量と、前記最小遅延量との差に基づいて、前記相手通信装置から前記通信装置への経路において発生している変動遅延量を決定する変動遅延量決定処理と
   を実行させることを特徴とするプログラム。
7. 通信装置において実行されるプログラムであって、
   前記通信装置に、
   前記通信装置から相手先通信装置への経路において発生している変動遅延量に基づいて、前記相手先通信装置に送信するパケットの送信量を制御するパケット送信量制御処理を実行させ、
   前記パケット送信量制御処理では、前記変動遅延量と、一度に前記相手先通信装置に送信したパケットの数を示す送信パケット数情報とに基づいて、前記相手先通信装置に送信する応答パケットの送信量が制御されることを特徴とするプログラム。

Images