JP4147534B2 - 通信装置および通信方法 - Google Patents

Description

本発明は、ネットワークを介して通信セッションを実行する通信装置および通信方法に関し、特に、TCP(Transmission Control Protocol)のように輻輳制御機能を持つ通信プロトコルを用いる通信装置および通信方法に関する。

インターネットにおけるデータ通信用の第四層プロトコルとして知られているTCPは、コネクション型の通信により信頼性の高い通信を提供するプロトコルである。このTCPは、ネットワークの輻輳状況に応じて輻輳ウインドを適切に調整する輻輳制御機能を備え、ネットワークに輻輳がない間は、輻輳ウインドを拡大することにより送信帯域を増大させ、また、ネットワークが輻輳している場合には、輻輳ウインドを縮小することで送信帯域を減少させる。

従来、TCPに関し提案されているバージョンのうち、上述の輻輳制御機能について規定した後述の非特許文献１に記載の早期回復アルゴリズムを採用したバージョンに、いわゆる「TCP-Reno」がある。この「TCP-Reno」において、輻輳ウインドを拡大させる際の動作としては、予め設定された閾値に達するまで急速に輻輳ウインドを拡大させるスロースタートと、ウインドサイズが閾値に達した後にスロースタート期間よりも緩やかに輻輳ウインドを拡大させる輻輳回避とがある。

上記の輻輳回避動作においてパケット廃棄を検出したとき、通信装置は、ネットワークが輻輳状態にあるとの判断のもとに輻輳ウインドを現状の半分に縮小し、これにより送信帯域を減少させる。一方、パケット廃棄が検出されない間は、ネットワークが輻輳状態にないとの判断のもとに、輻輳ウインドを１MSS（Maximum Segment Size）ずつ線形に拡大することにより、送信帯域を緩やかに増大させる。本制御は、一般的にAIMD (Additive Increase Multiple Decrease)制御と呼ばれる。

ところで、「TCP-Reno」を適用中は、パケット廃棄が発生すると、いったん輻輳ウインドのサイズを半減させることから、その後ウインドサイズが十分な大きさに増加するまでの間は、本来期待されるスループットが得られないという問題がある。これは特に、高速通信を提供する回線、あるいは元来の往復伝播遅延時間(以下、「RTT」（Round Trip Time）と称す。)が長い回線、もしくは輻輳以外の原因でもパケット廃棄が発生し得る無線回線等にとっては深刻な問題であった。この問題に対して、従来、以下のような技術が提案されている。

第一の従来技術は、パケット廃棄が発生した際、ネットワークから端末に対してパケット廃棄が輻輳によるものであるか否かに関する何らかの情報を与えるものである。この技術に関し、例えば、後述の特許文献１には、回線のエラーによりパケット廃棄が発生した際、受信端末から送信端末に対してELN (Explicit Loss Notification)情報を送信し、送信端末は、パケット廃棄が輻輳によるものでない場合には不必要に輻輳ウインドを減少させないという技術が記載されている。また、後述の特許文献２にも同様の技術が記載されている。さらにまた、後述の特許文献３には、無線回線の品質情報を送信端末に与え、無線回線の品質が悪いときには無線回線に適した輻輳ウインド制御方式に切り替えることにより、不必要に輻輳ウインドを減少させないという技術が記載されている。

第二の従来技術は、パケット廃棄の発生を直ちに輻輳発生と判断することに代えて、TCP送信端末が持つ情報を用いて輻輳判断を行うものである。この技術に関し、例えば、後述の特許文献４には、回線のRTTを計測し、そのRTTが一定値以下である場合には輻輳で無いと判定することにより、パケット廃棄を検出した場合でも輻輳ウインドを減少させないという技術が記載されている。

第三の従来技術は、「TCP-Reno」と同様のAIMD制御による輻輳ウインド制御を行いながら、その動作パラメータを変更するものである。この技術に関し、例えば、後述の非特許文献２には、パケット廃棄が発生しない間は、輻輳ウインドの増加幅を「TCP-Reno」に比べて大きく設定し、また、パケット廃棄が発生したときは、輻輳ウインドの減少幅を「TCP-Reno」に比べて小さく設定することで、パケット廃棄が頻発する環境であっても高いスループットを得られるようにするという技術が記載されている。

第四の従来技術は、「TCP-Reno」のAIMD制御ではなく、目標とする理想的な輻輳ウインドの大きさを計算し、輻輳ウインドをその値へと誘導するように制御するものである。この技術に関し、例えば、後述の非特許文献３には、現在のRTTと現在の輻輳ウインドとを用いて理想的な輻輳ウインドの値を計算し、その値と現在の輻輳ウインドとの差分に基づき輻輳ウインドの増加幅あるいは減少幅を決定するという技術が記載されている。この非特許文献３の技術によれば、現在の輻輳ウインドが理想的な輻輳ウインドよりも大幅に小さい場合は、増加させるべき輻輳ウインドのサイズも大きくなることから、結果、高速にスループットを増加させることができる。
特開２００４−８０４１３号公報 特開平１１−２４３４１９号公報 特開２０００−２５３０９６号公報 特開２００１−１６０８２４号公報 W.Stevens、"TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms"、［online］、１９９７年１月、Network Working Group／RFC2001、［平成１７年１月２１日検索］、＜URL:http://www.faqs.org/rfcs/rfc2001.html＞ S.Floyd、"HighSpeed TCP for Large Congestion Windows"、［online］、 ２００３年１２月、Network Working Group／RFC3649、［平成１７年１月２１日検索］、＜URL:http://www.faqs.org/rfcs/rfc3649.html＞ Cheng Jin, David X. Wei and Steven H.Low、"FAST TCP for High-Speed Long-Distance Networks"、［online］、２００３年６月、Internet Engineering Task Force／INTERNET DRAFT／draft-jwl-tcp-fast-01.txt、［平成１７年１月２１日検索］、＜URL:http://netlab.caltech.edu/pub/papers/draft-jwl-tcp-fast-01.txt＞ R.Wang, M.Valla, M.Y.Sanadidi, B.K.F.Ng and M.Gerla、"Efficiency/Friendliness Tradeoffs in TCP Westwood"、［online］、 ２００２年５月１５日、UCLA Computer Science Department、［平成１７年１月２１日検索］、＜URL: http://www.cs.ucla.edu/NRL/hpi/tcpw/tcpw_papers/tcpw-crb-iscc02.pdf＞

第一の従来技術の問題点は、端末に対してパケット廃棄の原因や無線回線の状態を通知する機構がネットワークに必要であるため、導入が難しいことである。特に、無線回線に接続された端末と、その無線回線に接続されていない不特定多数の端末とが通信を行う場合、後者の不特定多数の端末全てに対して前記機構を導入することは容易ではない。また、同様な機構を有線回線に適用することは困難である。

第二の従来技術の問題点は、RTTに基づく輻輳判断の不確かさである。RTTが取り得る値の範囲はルータのバッファ容量に依存することから、輻輳判断に用いる最適なRTT閾値は一意に決定し難い。すなわち、ルータのバッファ容量が大きいほどRTTが取り得る値の範囲が広がるので、端末に一定のRTT閾値を設定しても、バッファ容量が比較的大きいルータの回線を使用するときよりも、ルータのバッファ容量が比較的小さい回線を使用するときのほうが、輻輳発生と判断され易くなる。そうすると、実際は軽度の輻輳であるにも拘らず輻輳発生と判断する可能性があり、結果、不必要な輻輳ウインドの減少制御によりスループットが低下することとなる。また逆に、バッファ容量が比較的大きい場合、輻輳発生と判断すべき状態に対し、未だ輻輳ではないと判断する可能性があり、その場合、減少させるべき輻輳ウインドが減少されず、結果、輻輳を回避することができないという問題が生じる。

第三の従来技術の問題点は、ネットワークにおいて、この技術によるセッションを既存の「TCP-Reno」セッションと共存させることが難しいことであり、「TCP-Reno」セッションと競合する場合には、「TCP-Reno」セッションのスループットが低下するという問題がある。すなわち、第三の従来技術では、パケット廃棄が検出されない間の輻輳ウインドの増加幅は「TCP-Reno」よりも大きく設定し、また、パケット廃棄検出時の輻輳ウインドの減少幅は「TCP-Reno」よりも小さくするため、輻輳ウインドサイズが常に「TCP-Reno」よりも大きくなり、結果、「TCP-Reno」のスループットを低下させてしまうこととなる。

第四の従来技術の問題点は、上記第三の従来技術と同様に、ネットワークを共有する既存の「TCP-Reno」セッションとの共存が難しいことであり、「TCP-Reno」セッションと競合する場合には、スループットが「TCP-Reno」セッションよりも小さくなる。本従来技術では、RTTが大きくなるに従って、理想的な輻輳ウインドの値が現在の輻輳ウインドの値よりも小さくなるため、この間、たとえパケット廃棄が検出されなかったとしても、輻輳ウインドの増加幅は負となる。一方、「TCP-Reno」では、RTTの大きさに拘らず、パケット廃棄が検出されるまでは常に輻輳ウインドを増加させ続ける。そのため、これらが競合した場合、本従来技術によるTCPセッションのスループットが低下するという問題がある。

本発明は、上記課題に鑑みてなされたものであり、ネットワークの輻輳状態を考慮しつつ、通信セッションにおける輻輳回避動作中のスループットの向上を図る手法を提供することを目的とする。

上記目的を達成するため、本発明に係る通信装置は、ネットワークへ連続的に送出可能な信号量を規定する輻輳ウインドに基づき通信セッションを実行する通信装置であって、適用すべき輻輳ウインドのサイズを決定する手段と、通信セッションにおける信号伝播時間を用いてボトルネック回線の利用率を推定する手段と、推定した回線利用率に基づき輻輳回避動作における輻輳ウインドの増加幅を決定する手段とを有し、推定した回線利用率が増大するに従い、より小さい値を前記増加幅に決定する。

本発明に係る通信方法は、ネットワークへ連続的に送出可能な信号量を規定する輻輳ウインドに基づき通信セッションを実行する通信装置が、通信セッションにおける信号伝播時間を用いてボトルネック回線の利用率を推定し、推定した回線利用率に基づき輻輳回避動作における輻輳ウインドの増加幅を決定し、輻輳ウインドを拡大させるとき、適用すべき輻輳ウインドのサイズを前記増加幅に基づき決定し、前記輻輳ウインドの増加幅を決定するとき、回線利用率が増大するに従い、より小さい値を前記増加幅に決定するという方法である。

本発明によれば、信号伝播時間を用いて推定したボトルネック回線の利用率に基づき輻輳回避中の輻輳ウインドの増加幅を決定することから、現時点におけるボトルネック回線の状況に適したウインドサイズを設定することができる。これにより、輻輳回避動作におけるパケット廃棄の頻発を防止でき、ひいては、スループットを円滑に向上させることができる。

［第１の実施形態］
図１は、本発明の第１の実施形態の構成を示すブロック図である。本発明に係る通信装置としての端末１は、図１に示すように、送信データを発生するデータ発生部１−１と、送信データをネットワ−クに出力するデータ送信制御部１−２とを備える。本実施形態の端末１は、第四層の通信プロトコルであるTCPに基づきコネクション型の通信を行う通信装置である。

データ送信制御部１−２は、ネットワ−クに対してパケットを送信するパケット送信部１−３と、ネットワ−クからパケットを受信するパケット受信部１−４と、パケット廃棄の有無を判定する輻輳判定部１−５と、輻輳ウインドのサイズを決定する輻輳ウインド決定部１−６と、通信セッションにおいてボトルネックとなっている回線の帯域を推定する帯域推定部１−７と、本発明における信号伝播時間としてのRTTを計測するRTT計測部１−８と、計測したRTTから現在のボトルネック回線の利用率を推定する利用率推定部１−９と、推定した回線帯域及び利用率に基づき輻輳回避動作中の輻輳ウインドの増加幅を決定する輻輳ウインド増加幅決定部１−１０とを有する。

なお、TCPにおける輻輳回避動作とは、従来知られているように、スロースタート期間において輻輳ウインドが所定のサイズまで急速に拡大した後、スロースタート時よりも緩やかに輻輳ウインドを拡大させる動作であり、特に、「TCP−Reno」による輻輳回避動作では、１RTT周期ごとに１MSSの増加幅にて輻輳ウインドのサイズを増加させる。

図２は、本実施形態の動作手順を示すフローチャートである。図１及び図２を参照して、本実施例の動作について説明する。

端末１は、自端末と通信相手となる端末との間にTCPコネクションを開設し（ステップＡ１）、データ発生部１−１において発生させた送信データの送信を開始する（ステップＡ２）。パケット送信部１−３は、発生したデータをパケット化し、これらを現在の輻輳ウインドの値に従ってネットワ−クに出力する。端末１から送信したパケットに対し、受信側の端末（図示略）より受信確認パケット(ACKパケット)が送り返されると、これをパケット受信部１−４が受信する（ステップＡ３）。

帯域推定部１−７は、受信したACKパケットを用いてボトルネック回線の帯域を推定する（ステップＡ４）。推定の方法としては、例えば、連続的に受信した２つのACKパケットが示す２つの送信パケットのデータ量を、ACKパケットの到着時間間隔で割ったものから推定するという方法を用いることができる。この方法については、例えば、非特許文献４に詳しく述べられており、ここではその詳細についての説明は省略する。

次に、端末１は、RTT計測部１−８において、パケットを送信した時刻と該パケットに対するACKパケットを受信した時刻との差分からRTTを求め（ステップＡ５）、過去に求めたRTTのうち最も小さい値を最小RTTとして保持する。この最小RTTは、その時点では輻輳が無かったことを示唆するものであり、また、後述する手順により求められる最大RTTは、その時点で輻輳が発生したことを示唆するものである。

利用率推定部１−９は、現時点のRTT、最小RTTおよび最大RTTにより定義される次の数式１により、回線利用率を推定する（ステップＡ６）。

上記数式１において、「p」は、回線利用率が１００％未満である確度であり、「p」が「０」であれば回線利用率は１００％、「p」が「１」であれば回線利用率が１００％未満であることを示す。また、数式１において「p」の値がほぼ「０」、又はほぼ「１」となるように、定数「A」には、「e^A」を十分に大きくする値が設定されている。ここで、RTTが最小RTTに等しいときには「p＝１」となり、回線利用率が１００％未満であると判断される。また、RTTが最大RTTに等しいときには「p≒０」となり、回線利用率が１００％であると判断される。

なお、回線利用率を推定するための関数は、数式１のような特性、すなわちRTTが最小RTTに等しいとき回線利用率が１００％未満であり、RTTが最大RTTに等しいときは回線利用率１００％となる特性をもつ関数であれば、上記の数式１に限らず適宜採用することができる。また、計測したRTTに誤差成分が多く含まれる場合には、誤差を除去するために、RTTの代わりにRTTの移動平均を用いても良い。

輻輳判定部１−５は、送信パケットに対してACKパケットが適正に到着したか否かを確認し、適正に到着した場合は、送信パケットが廃棄されていないと判断する（ステップＡ７：No）。この場合、輻輳ウインド決定部１−６は、スループットを増加可能であるとの判断のもとに、輻輳ウインド増加幅決定部１−１０が次の方法により決定した増加幅に従って輻輳ウインドを増加させる。

輻輳ウインド増加幅決定部１−１０は、上記の帯域推定部１−７が推定したボトルネック回線の帯域、および、利用率推定部１−９が推定した回線利用率（p）を用いた次の数式２により輻輳ウインドの増加幅（I）を求める。

ここで、「I」は、１RTT周期あたりの輻輳ウインドの増加幅であり、「B」は増加幅を決定する係数である。数式２によれば、回線利用率が１００％未満（p＝１）である場合は（ステップＡ８：＜１００％）、輻輳ウインド増加幅（I）として、「１MSS」よりもセグメント単位で大きな値を得る（ステップＡ９）。また、回線利用率が１００％（p＝０）である場合（ステップＡ８：＝１００％）、輻輳ウインド増加幅（I）は、「TCP−Reno」にて規定されている増加幅と同様の「１MSS」となり、結果、１RTT周期ごとに「１MSS」ずつ輻輳ウインドが拡大する（ステップＡ１０）。

輻輳ウインドの増加幅を決定する際、上記数式２のようにボトルネック回線の帯域を利用することにより、その帯域に適した増加幅を求めることができる。すなわち、数式２によれば、帯域が比較的小さな場合には、輻輳ウインドが緩やかに拡大される増加幅が算出される。これにより、パケット廃棄の頻発を防ぐことができる。また、帯域が大きいほど、より高速に拡大される増加幅が算出され、これにより、高いスループットを実現でき、結果、回線帯域を有効に活用することが可能となる。なお、輻輳ウインドの増加幅を決定するにあたっては、本実施形態で用いたボトルネック回線の帯域に代えて、固定値、RTT、現時点の輻輳ウインドのサイズあるいはルータのバッファ容量等、考慮すべき対象に適した値を用いることができる。

一方、送信パケットに対して正しくACKパケットが到着しない場合、すなわち同じACK番号を持つACKパケットを３つ以上続けて受信した場合、輻輳判定部１−５は、パケット廃棄が発生したと判断する（ステップＡ７：Yes）。この場合、輻輳判定部１−５は、「TCP−Reno」によるパケット廃棄発生時の輻輳ウインドの減少手順と同様に、輻輳ウインドのサイズを現状の半分に減少させる（ステップＡ１１）。

さらに、端末１は、RTT計測部１−８により最大RTTの値の更新を行う（ステップＡ１２）。更新に用いる最大RTTとしては、例えば、パケット廃棄を検出する直前のRTTの値、あるいはその近辺のRTT値の平均値を最大RTTとして保持する。なお、ここで求めた最大RTTが、予め定められた閾値よりも小さい場合には、その閾値を最大RTTとして用いる。この閾値としては、例えば、現時点のRTTもしくは最小RTTの値に一定値を加えたもの、あるいは帯域推定部１−７で求めた推定帯域に比例して増減する値を加えたものを用いることができる。

端末１は、送信すべきデータが終了するまで上記手順を繰り返し（ステップＡ１３）、最後に、TCPコネクションを切断して通信を終了する（ステップＡ１４）。

以上説明した第１の実施形態によれば、輻輳回避動作中であってもボトルネック回線の利用率が低い場合には高速に輻輳ウインドを増加させることから、輻輳回避動作におけるスループットの低下を防止することができる。また、回線利用率が高い場合は「TCP−Reno」と同様の輻輳ウインド制御を行うので、「TCP−Reno」セッションと競合した場合のスループットの低下も防止することができる。また、ネットワークから端末１に対し特別な情報を通知する機構が不要であり、しかも、ルータのバッファ容量等、ネットワーク側の仕様に因ることなく輻輳ウインドを制御することから、比較的容易にスループットの向上を図ることが可能となる。

［第２の実施形態］
図３は、本発明の第２の実施形態の構成を示すブロック図である。図３において、図１に示す構成と対応する部分には、図１の符号に関連する符号が付されている。本実施形態の端末２は、図１の端末１の構成に加え、パケット廃棄検出時の輻輳ウインド減少率を動的に変更する輻輳ウインド減少率決定部２−１１をデータ送信制御部２−２に備える。

図４は、本実施形態の動作手順を示すフローチャートである。図３及び図４を参照して、本実施形態の動作について説明する。なお、図４に示す手順において、端末２が通信相手とのTCPコネクションを開設後、回線利用率を算出するまでの手順（ステップＢ１〜Ｂ６）は、図２に沿って説明した第１の実施形態における手順（ステップＡ１〜Ａ６）と同様であり、また、通信セッションにおいてパケット廃棄が検出されない間は（ステップＢ７：No）、第１の実施形態と同様の手順により輻輳ウインドを増加する（ステップＢ８）。ここでは、第１の実施形態の手順と同様な手順については説明を省略する。

端末２は、パケット廃棄を検出したとき（ステップＢ７：Yes）、輻輳ウインド減少率決定部２−１１において、RTT、最小RTT、及び最大RTTにより定義される次の数式３により輻輳ウインドの減少率を決定する。

上記数式３によれば、パケット廃棄検出時にRTTが最小RTTに等しいとき（ステップＢ９：Yes）、すなわちパケット廃棄を検出したが輻輳は無いと推測されるとき、減少率として「１」を得る。この場合、輻輳ウインドは縮小されず、現状のサイズが維持される（ステップＢ１０）。一方、RTTが最大RTTに等しいとき（ステップＢ１１：Yes）、すなわち輻輳発生の可能性が高いとき、輻輳ウインド減少率は「TCP−Reno」によるパケット廃棄検出時の減少率と同様の「０.５」、すなわち現状の輻輳ウインドのサイズを半減させる減少率を得る。また、RTTが最小RTTから最大RTTに向けて増大する間は（ステップＢ１０：No、ステップＢ１１：No）、輻輳ウインドの減少率として「１」から「０．５」の間の値が得られ、すなわちRTTが増大するに従い輻輳ウインドの減少量が増大する。

以上説明した第２の実施形態によれば、パケット廃棄検出時の輻輳ウインドの減少幅を最適化されることから、第１の実施形態による効果に加え、特に、輻輳以外の原因によるパケット廃棄が発生する場合のスループットを向上させることできる。また、パケット廃棄の原因が輻輳発生にある場合には、「TCP−Reno」と同様の制御にて輻輳ウインドを減少させるため、「TCP−Reno」との公平性を確保することができる。

［第３の実施形態］
図５は、本発明の第３の実施形態の構成を示すブロック図である。図５において、図１に示す構成と対応する部分には、図１の符号に関連する符号が付されている。本実施形態の端末３は、図１の端末１の構成に加え、輻輳ウインドと並列的に設けられた参照輻輳ウインドのサイズを算出する参照輻輳ウインド決定部３−１１をデータ送信制御部３−２に備える。

参照輻輳ウインドとは、回線利用率あるいはRTTの値にかかわらず、輻輳回避動作において、そのサイズが「TCP−Reno」と同様の手順により増減される仮想の輻輳ウインドである。参照輻輳ウインド決定部３−１１は、TCPコネクションの開始時である初期状態またはスロースタート動作中は、参照輻輳ウインドのサイズをその時点の輻輳ウインドのサイズと等しい値に設定する。

図６は、本実施形態の動作手順を示すフローチャートである。図５及び図６を参照して、本実施形態の動作について説明する。なお、図６に示す手順において、図２に沿って説明した第１の実施形態の手順と同様な手順については説明を省略し、以下、パケット廃棄の判定（ステップＣ７）以降の手順を説明する。

端末３は、パケット廃棄を検出したとき（ステップＣ７：Yes）、「TCP−Reno」の手順と同様に輻輳ウインドのサイズを半減させる（ステップＣ８）。このとき参照輻輳ウインド決定部３−１１は、参照輻輳ウインドのサイズが、半減された輻輳ウインドのサイズと等しくなるよう設定する（ステップＣ９）。

一方、輻輳回避動作においてパケット廃棄が検出されない間は（ステップＣ７：No）、第１の実施形態と同様な手順にて輻輳ウインドの増加幅を決定し、その増加幅に基づき輻輳ウインドのサイズを決定する（ステップＣ１１）。この間、参照輻輳ウインド決定部３−１１は、輻輳ウインド側のサイズの推移に関与することなく、参照輻輳ウインドのサイズを「TCP−Reno」と同様に１RTT周期ごとに１MSSずつ増加させ、そのウインドサイズを逐次記録する（ステップＣ１２）。

輻輳ウインド決定部３−６は、輻輳ウインドのサイズを決定するとき、現行の輻輳ウインドのサイズと参照輻輳ウインドのサイズとを比較し（ステップＣ１３）、輻輳ウインドの値よりも参照輻輳ウインドの値が上回った場合、参照輻輳ウインドの値を新たな輻輳ウインドの値として決定し、その値まで輻輳ウインドを拡大させる（ステップＣ１４）。

上述したように、本実施形態では、輻輳ウインドのサイズを決定する際に参照輻輳ウインドを参照することにより、「TCP−Reno」よりもスループットが下回ることを防ぐことができる。本実施形態において輻輳ウインドの増加幅を決定するにあたっては、例えば、既述した数式２のように増加幅に１MSSの下限を設定しない、次の数式４を用いることができる。

上記数式４を用いた場合、RTTが最大RTTに近くなり且つ回線利用率を１００％と推定している状況（p≒０）では、輻輳ウインドの増加幅（I）はほぼ「０」となり、輻輳ウインドのサイズが現状のものに維持される。すなわち、回線利用率が高いときには輻輳ウインドの増加を停止して「TCP−Reno」による参照輻輳ウインドが増加するのを待つことができるため、「TCP−Reno」との公平性がさらに向上する。

また、次の数式５のように、RTTの関数を加えることも可能である。

ここで、上記数式５における関数「f(RTT)」を、単調増加する傾きを持ち且つf(最大RTT)=１MSSとなるような増加関数とすることにより、増加幅（I）に、図９に示すような特性を与えることができる。図９から分かるように、上記数式５によれば、回線利用率が比較的低いとき（p＝１）、すなわちRTTが比較的小さいときには（RTT≒RTTmin）、輻輳ウインドを高速に拡大させる増加幅が算出される。また、RTTが増大するに従って（RTT＞RTTmin）増加幅が減少し、さらにRTTが増大することにより回線利用率が１００％となると（RTT≒RTTmax、p＝０）、輻輳ウインドの増加幅を「TCP−Reno」と同様の制御により決定することとなる（I＝１MSS）。このように、数式５を用いた制御は、パケット廃棄が発生する程度に輻輳度が高まったときには「TCP−Reno」と同様の動作を行うよう制御することにより、「TCP−Reno」との公平性をさらに向上させることを意図したものである。

また、輻輳ウインドの増加幅および減少率を決定するにあたっては、非特許文献３に記載の手順を採用することも可能である。この場合、非特許文献３の手順のように高スループットが達成可能であり、さらに参照輻輳ウインドを併用することで「TCP−Reno」との競合時のスループット低下を防ぐことも可能となる。

さらにまた、本実施形態においては、ウインドサイズに関し輻輳ウインドおよび参照輻輳ウインドのうちの大きいほうを輻輳ウインドに適用するが、この方法に限らず、例えば、RTTが比較的小さいときは、高速に増加する輻輳ウインドの値を用い、RTTが大きくなるに従って参照輻輳ウインドの値を用いるようにしてもよい。

以上説明した第３の実施形態によれば、第１の実施形態による効果に加え、「TCP−Reno」と同様の制御によって得られる参照輻輳ウインドを併用することにより、「TCP−Reno」との公平性を更に向上させることができる。

［第４の実施形態］
図７は、本発明の第４の実施形態の構成を示すブロック図である。本実施形態の端末４は、図５に示す第３の実施形態と同様な構成であり、すなわち第１の実施形態の構成に加え、参照輻輳ウインドのサイズを算出する参照輻輳ウインド決定部４−１１をデータ送信制御部４−２に備える。

図８は、本実施形態の動作手順を示すフローチャートである。本実施形態の動作手順は、以下の点を除き、図６に沿って説明した第３の実施形態のものと同様であり、同様な部分については説明を省略する。

本実施形態では、輻輳ウインドの増加幅を決定する際に、第３の実施形態で説明した数式４又は数式５における係数「B」を、輻輳ウインドおよび参照輻輳ウインドの差分に基づき動的に設定する（ステップＤ１１）。これは、RTTが最大RTTに近づくほど係数「B」の値を大きくする設定であり、例えば、次の数式６に示す条件を満たす関数により「B」を決定することができる。

第４の実施形態によれば、第３の実施形態と同様な効果に加え、輻輳ウインドの増加幅を回線の状態に合わせて柔軟に設定することができる。

上記説明した各実施形態では、本発明における信号伝播時間として、端末間の往復の信号伝播時間に相当するRTTを用いたが、本発明を実施するにあたっては、RTTに代えて、端末間の片道の信号伝播時間を用いることも可能である。その場合、例えば、一方の端末から送信するパケットに現在時刻を記述しておき、これを受けた他方の端末が、受信時刻とそのパケットに記述されている時刻との差分を算出し、差分の時間を片道の信号伝播時間として保持する。そして、保持した値を回線利用率の算出に用いる。

本発明の適用範囲は、上記説明した端末（１）に限らず、例えば図１０に示すように、通信システム１００においてネットワーク２０を介して接続された端末１Ａ及び端末１Ｂ間のセッションを中継するセッション中継装置１０に本発明を適用してもよい。このセッション中継装置１０は、両端末間の通信セッションにおいて、一方の端末と間でセッションを一旦終端した後、他方の端末との間で新たなセッションを行うことにより、両端末間を中継するものである。

本発明を実施するうえで好適な通信プロトコルは、上記実施形態で説明したTCPであるが、このTCPに限らず、輻輳制御を行うものであれば他の通信プロトコルであってもよい。

本発明の第１の実施形態の構成を示すブロック図である。 第１の実施形態の動作手順を示すフローチャートである。 本発明の第２の実施形態の構成を示すブロック図である。 第２の実施形態の動作手順を示すフローチャートである。 本発明の第３の実施形態の構成を示すブロック図である。 第３の実施形態の動作手順を示すフローチャートである。 本発明の第４の実施形態の構成を示すブロック図である。 第４の実施形態の動作を示すフローチャートである。 実施形態における輻輳ウインドの増加幅の算出に関する説明図である。 本発明の他の実施形態の構成を示すブロック図である。

符号の説明

１ 端末
１−１ デ−タ発生部
１−２ デ−タ送信制御部
１−３：パケット送信部、１−４：パケット受信部、１−５：輻輳判定部、１−６：輻輳ウインド決定部、１−７：帯域推定部、１−８：RTT計測部、１−９：利用率推定部、１−１０：輻輳ウインド増加幅決定部

Claims (33)

1. ネットワークへ連続的に送出可能な信号量を規定する輻輳ウインドに基づき通信セッションを実行する通信装置であって、
   適用すべき輻輳ウインドのサイズを決定する手段と、通信セッションにおける信号伝播時間を用いてボトルネック回線の利用率を推定する手段と、推定した回線利用率に基づき輻輳回避動作における輻輳ウインドの増加幅を決定する手段とを有し、
   推定した回線利用率が増大するに従い、より小さい値を前記増加幅に決定することを特徴とする通信装置。
2. 前記増加幅の下限を１パケット分の信号量とすることを特徴とする請求項１記載の通信装置。
3. さらに、前記ボトルネック回線の帯域を推定する手段を有し、推定した帯域を用いて前記増加幅を決定する請求項１又は２記載の通信装置。
4. 現時点の信号伝播時間が過去の信号伝播時間の最大値に近づくほど回線利用率が高くなることを示す指数関数により前記回線利用率を推定することを特徴とする請求項１乃至３のいずれか１項に記載の通信装置。
5. 前記最大値として、パケット廃棄が発生する直前の信号伝播時間を用いることを特徴とする請求項４記載の通信装置。
6. 前記最大値として、既存の最大値と過去の信号伝播時間の最小値に所定値を加算した値とのうちの大きいほうを用いることを特徴とする請求項４記載の通信装置。
7. 前記所定値として、ボトルネック回線の帯域に比例して増減する値を用いることを特徴とする請求項６記載の通信装置。
8. さらに、過去の信号伝播時間の最小値および最大値と現時点の信号伝播時間とに基づき輻輳回避動作における輻輳ウインドの減少率を決定する手段を有することを特徴とする請求項１乃至７のいずれか１項に記載の通信装置。
9. 現時点の信号伝播時間が増大するに従い輻輳ウインドをより小さくする値を前記減少率として決定することを特徴とする請求項８記載の通信装置。
10. 前記減少率として、現時点の信号伝播時間が前記最小値に等しいとき輻輳ウインドの減少を停止させる値を決定し、現時点の信号伝播時間が前記最大値に等しいとき輻輳ウインドを半減させる値を決定することを特徴とする請求項８又は９記載の通信装置。
11. さらに、前記輻輳ウインドと並列的に設けられ且つ増加幅が１パケット分の信号量である参照輻輳ウインドのサイズを算出する手段を有し、参照輻輳ウインドのサイズおよび前記増加幅に基づくサイズのうちの大きいほうのサイズを前記輻輳ウインドのサイズに決定することを特徴とする請求項１乃至１０のいずれか１項に記載の通信装置。
12. 現時点の信号伝播時間が前記最大値に等しいとき、前記輻輳ウインドの増加を停止させる値を前記輻輳ウインドの増加幅として決定することを特徴とする請求項１１記載の通信装置。
13. 現時点の信号伝播時間が前記最大値に等しいとき、１パケット分の信号量を前記輻輳ウインドの増加幅に決定することを特徴とする請求項１１記載の通信装置。
14. 前記輻輳ウインドのサイズと前記参照輻輳ウインドのサイズとの差分に応じて前記輻輳ウインドの増加幅を変化させることを特徴とする請求項１１記載の通信装置。
15. ネットワークへ連続的に送出可能な信号量を規定する輻輳ウインドに基づき通信セッションを実行する通信装置であって、
    適用すべき輻輳ウインドのサイズを決定する手段と、通信セッションにおける信号伝搬時間に基づいて前記輻輳ウインドの増加幅を決定する手段と、前記輻輳ウインドと並列的に設けられ且つ増加幅が１パケット分の信号量である参照輻輳ウインドのサイズを算出する手段とを備え、
    参照輻輳ウインドのサイズおよび前記増加幅に基づくサイズのうちの大きいほうのサイズを前記輻輳ウインドのサイズに決定することを特徴とする通信装置。
16. 複数の端末装置間において実行される通信セッションを中継するセッション中継装置であることを特徴とする請求項１乃至１５のいずれか１項に記載の通信装置。
17. コンピュータを、請求項１乃至１６のいずれか１項に記載の通信装置として機能させることを特徴とするプログラム。
18. それぞれが請求項１乃至１６のいずれか１項に記載の通信装置である複数の端末装置を備えることを特徴とする通信システム。
19. ネットワークへ連続的に送出可能な信号量を規定する輻輳ウインドに基づき通信セッションを実行する通信装置が、
    通信セッションにおける信号伝播時間を用いてボトルネック回線の利用率を推定し、推定した回線利用率に基づき輻輳回避動作における輻輳ウインドの増加幅を決定し、輻輳ウインドを拡大させるとき、適用すべき輻輳ウインドのサイズを前記増加幅に基づき決定し、前記輻輳ウインドの増加幅を決定するとき、回線利用率が増大するに従い、より小さい値を前記増加幅に決定することを特徴とする通信方法。
20. 前記通信装置が、前記増加幅の下限を１パケット分の信号量とすることを特徴とする請求項１９記載の通信方法。
21. 前記通信装置が、さらに、前記ボトルネック回線の帯域を推定し、推定した帯域を用いて前記増加幅を決定する請求項１９又は２０記載の通信方法。
22. 前記通信装置が、現時点の信号伝播時間が過去の信号伝播時間の最大値に近づくほど回線利用率が高くなることを示す指数関数により前記回線利用率を推定することを特徴とする請求項１９乃至２１のいずれか１項に記載の通信方法。
23. 前記通信装置が、前記最大値として、パケット廃棄が発生する直前の信号伝播時間を用いることを特徴とする請求項２２記載の通信方法。
24. 前記通信装置が、前記最大値として、既存の最大値と過去の信号伝播時間の最小値に所定値を加算した値とのうちの大きいほうを用いることを特徴とする請求項２２記載の通信方法。
25. 前記通信装置が、前記所定値として、ボトルネック回線の帯域に比例して増減する値を用いることを特徴とする請求項２４記載の通信方法。
26. 前記通信装置が、さらに、過去の信号伝播時間の最小値および最大値と現時点の信号伝播時間とに基づき輻輳回避動作における輻輳ウインドの減少率を決定し、輻輳ウインドを縮小させるとき、前記減少率に基づき輻輳ウインドのサイズを決定することを特徴とする請求項１９乃至２５のいずれか１項に記載の通信方法。
27. 前記通信装置が、現時点の信号伝播時間が増大するに従い輻輳ウインドをより小さくする値を前記減少率として決定することを特徴とする請求項２６記載の通信方法。
28. 前記通信装置が、前記減少率として、現時点の信号伝播時間が前記最小値に等しいとき輻輳ウインドの減少を停止させる値を決定し、現時点の信号伝播時間が前記最大値に等しいとき輻輳ウインドを半減させる値を決定することを特徴とする請求項２６又は２７記載の通信方法。
29. 前記通信装置が、さらに、前記輻輳ウインドと並列的に設けられ且つ増加幅が１パケット分の信号量である参照輻輳ウインドのサイズを算出し、参照輻輳ウインドのサイズおよび前記増加幅に基づくサイズのうちの大きいほうのサイズを前記輻輳ウインドのサイズに決定することを特徴とする請求項１９乃至２８のいずれか１項に記載の通信方法。
30. 前記通信装置が、現時点の信号伝播時間が前記最大値に等しいとき、前記輻輳ウインドの増加を停止させる値を前記輻輳ウインドの増加幅として決定することを特徴とする請求項２９記載の通信方法。
31. 前記通信装置が、現時点の信号伝播時間が前記最大値に等しいとき、１パケット分の信号量を前記輻輳ウインドの増加幅に決定することを特徴とする請求項２９記載の通信方法。
32. 前記通信装置が、前記輻輳ウインドのサイズと前記参照輻輳ウインドのサイズとの差分に応じて前記輻輳ウインドの増加幅を変化させることを特徴とする請求項２９記載の通信方法。
33. ネットワークへ連続的に送出可能な信号量を規定する輻輳ウインドに基づき通信セッションを実行する通信装置が、
    通信セッションにおける信号伝搬時間に基づいて輻輳ウインドの増加幅を決定し、前記輻輳ウインドと並列的に設けられ且つ増加幅が１パケット分の信号量である参照輻輳ウインドのサイズを算出し、輻輳ウインドを拡大させるとき参照輻輳ウインドのサイズおよび前記増加幅に基づくサイズのうちの大きいほうのサイズを前記輻輳ウインドのサイズに決定することを特徴とする通信方法。

Images