JP4429982B2

JP4429982B2 - 輻輳制御方法およびその通信端末

Info

Publication number: JP4429982B2
Application number: JP2005194573A
Authority: JP
Inventors: 正義鍋島
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 2005-07-04
Filing date: 2005-07-04
Publication date: 2010-03-10
Anticipated expiration: 2025-07-04
Also published as: JP2007013823A

Description

本発明はトランスポート層に実装される輻輳制御アルゴリズムにおいて、ネットワークの輻輳度に応じて、どの程度ウインドウサイズを増加させるかを計算する技術に関する。

現在のインターネットで使用されている端末はトランスポートプロトコルにＴＣＰ（Transmission Control Protocol）を実装している。ＴＣＰにおける輻輳制御アルゴリズムは、スロースタート段階と輻輳回避段階に分けることができる（非特許文献１）。ここでは本発明に関係のある輻輳回避段階におけるアルゴリズムについてのみ述べる。

ＴＣＰを使用している送信端末はパケットを送信する時、各パケットにシーケンス番号を付与する。受信端末はパケットを正しく受信すると、次に受信を期待するパケットのシーケンス番号が付与された受信確認パケットを送信する。図１はパケットに付与されるシーケンス番号を説明するための図であり、長方形がパケットを表し、その中の数字がシーケンス番号を表している。図１の例では、シーケンス番号１００或いは１０１のパケットを受信すると、受信端末は次に受信を期待するパケットのシーケンス番号１０１或いは１０２が付与された受信確認パケットを送信している。

また送信端末は、輻輳ウインドウ（ｃｗｎｄ）と呼ばれる変数を管理しており、ｃｗｎｄの値だけパケットを受信端末からの受信確認パケットの到着なしに送信することができる。例えばｃｗｎｄの値が１００の時、送信端末は１００個のパケットを受信確認パケットの到着なしに送信することができる。送信端末はｃｗｎｄ個の受信確認パケットを受信すると、ネットワークが輻輳状態ではないと判断し、ｃｗｎｄの値を１だけ増加させる。つまり先程の例では１００個のパケットに対する受信確認パケットを受信すると、ｃｗｎｄの値を１だけ増加させ、１０１にする。一方、次に受信を期待するパケットのシーケンス番号が同じである受信確認パケットを３回連続して受信すると、ネットワークが輻輳状態であると判断し、ｃｗｎｄの値を半分にし、そのシーケンス番号のパケットを再送する。図２はパケットが再送される条件を説明するための図である。図２ではシーケンス番号１０１のパケットがネットワーク内で廃棄され、送信端末は次に受信を期待するパケットのシーケンス番号が１０１である受信確認パケットを３回受信したので、シーケンス番号が１０１のパケットを再送している。

上記がＴＣＰにおける輻輳制御アルゴリズムの基本的動作であるが、近年このアルゴリズムでは、往復伝播遅延時間が長い場合、ギガビットレベルのスループットが実現不可能であることが報告され、新しくＣＵＢＩＣ−ＴＣＰが提案されている（非特許文献２）。ＣＵＢＩＣ−ＴＣＰでは、次に受信を期待するパケットのシーケンス番号が同じである受信確認パケットを３回連続して受信すると、ネットワークが輻輳状態であると判断し、ｃｗｎｄの値をｂ倍に減少する。一方、３回連続して受信していない場合はネットワークが輻輳状態でないと判断し、現在、ウインドウサイズが減少した後、再び増加し始めてからｔ時間経過しているとすると、ウインドウサイズｃｗｎｄ（ｔ）を

に設定する。ここでＣは定数、Ｋは（（ｂ＊Ｗ_ｍａｘ）／Ｃ）^１／３、Ｗ_ｍａｘは前回輻輳状態にあると判断した時のｃｗｎｄの値である。「＊」は乗算を表す。図３は、ＣＵＢＩＣ−ＴＣＰにおいて、ウインドウサイズが減少した後、再び増加し始めてからｔ時間経過した時のウインドウサイズ示したものである。

ＣＵＢＩＣ−ＴＣＰは従来のＴＣＰに比べて、ｃｗｎｄの増加率を高くし、且つ減少率を低くすることにより、往復遅延時間が長い場合でも、ギガビットレベルのスループットが実現可能であるようにしている。

しかしＣＵＢＩＣ−ＴＣＰには様々な問題点がある。その中の１つは、あるフローがウインドウサイズが大きい状態で通信を行っている時に、別のフローが通信を始めると、通信を開始したフローのウインドウサイズがなかなか増加しないという問題である。以下にこの問題を確認するシミュレーションを行った結果を示す。図４にシミュレーションモデルを示す。送信端末、受信端末はそれぞれ２つで、リンク帯域は６００Ｍｂｐｓであり、送信・受信端末間の伝播遅延時間を５０ミリ秒、パケットサイズを１５００バイトとした。送信端末は常に送信するパケットを有しており、１つ目の送信端末は時刻０秒に通信を開始し、２つ目の送信端末は時刻１００秒に通信を開始するとした。図５に時間毎の輻輳ウインドウサイズの変化を示す。図５において、縦軸はウインドウサイズであり、横軸は時間である。図５より、１００秒に通信を開始したフローのウインドウサイズ（図５の点線）は、時刻が３００秒になっても既に通信を開始してるフローのウインドウサイズ（図５の実線）と等しくなっていないことが確認できる。つまりＣＵＢＩＣ−ＴＣＰでは、新たに通信を開始したフローは広帯域のスループットを得るまでかなりの時間がかかるという問題がある。

ＣＵＢＩＣ−ＴＣＰとは別にＴＣＰＷｅｓｔｗｏｏｄ＋と呼ばれる方式が提案されている（非特許文献３）。Ｗｅｓｔｗｏｏｄ＋では、パケット送信時に現在の時刻ｎｏｗ１をパケットに書き込み、受信端末はパケットを受信した時、パケットに書き込まれているｎｏｗ１を読み取り、受信したパケットに対する受信確認パケットを送信する際、ｎｏｗ１を受信確認パケットに書き込み、送信端末は受信確認パケットを受信した時、現在の時刻ｎｏｗからｎｏｗ１を減算した値を計算し、その最小値ＲＴＴ_ｍｉｎを記憶し、また往復遅延時間内に受信した受信確認パケットから利用可能帯域ＡＢＥを次のように計算する。

ここでｌａｓｔ_ｔは前回ＡＢＥを計算した時刻、ｄは（ｎｏｗ−ｌａｓｔ_ｔ）の間に受信確認されたパケット数、αは定数である。

Ｗｅｓｔｗｏｏｄ＋では、次に受信を期待するパケットのシーケンス番号が同じである受信確認パケットを３回連続して受信すると、ネットワークが輻輳状態であると判断し、ｃｗｎｄの値をＲＴＴ_ｍｉｎ＊ＡＢＥに減少する。一方、３回連続して受信していない場合はネットワークが輻輳状態でないと判断し、従来のＴＣＰと同様な方式を用いてウインドウサイズを増加させる。

Ｗｅｓｔｗｏｏｄ＋はこのように、ネットワークが輻輳状態であると判断した場合にウインドウサイズを減少させる時、値ＲＴＴ_ｍｉｎ＊ＡＢＥを基にして、ウインドウサイズの減少幅を決定している。しかしながら、ウインドウサイズを増加する時には、ＡＢＥの値を用いていない。

村山他、"トランスポートプロトコル"、岩波書店、２００１年４月６日、Ｐ１７４〜１７６ I. Rhee, L. Xu,"CUBIC: A New TCP Friendly High-Speed TCP Variant", PFLDnet 2005, Feb. 2005, [online], インターネット＜http://www.ens-Iyon.fr/LIP/RESO/pfIdnet2005/＞ L. A. Grieco, S. Nascolo,"Performance Evaluation and Comparion of Westwood+, New Reno. and Vegas TCP Congestion Control", ACM SIGCOMM Computer Communication Review, PP.25-38, April 2004

本発明はＣＵＢＩＣ−ＴＣＰの輻輳制御方式において、ウインドウサイズを減少し再び増加し始めてからｔ時間経過した時刻におけるウインドウサイズｃｗｎｄ（ｔ）の値を決定する時、値ＲＴＴ_ｍｉｎ＊ＡＢＥとＲＴＴ_ｍａｘ＊ＡＢＥを基にしてその値を決定することにより、ＣＵＢＩＣ−ＴＣＰが持つ様々な問題点、例えば、新たに通信を開始したフローが広帯域のスループットを得るまでの時間が長くなるという問題を解決することを目的としている。

本発明は、値ＲＴＴ_ｍｉｎ＊ＡＢＥとＲＴＴ_ｍａｘ＊ＡＢＥを計算し、それら値を基にして、ウインドウサイズの増加幅を決定するものである。
すなわち、本発明は、送信端末が、パケット送信時に現在の時刻ｎｏｗ１をパケットに書き込むステップと、受信端末が、前記パケットを受信した時、前記パケットに書き込まれているｎｏｗ１を読み取るステップと、前記受信端末が、受信した前記パケットに対する受信確認パケットを送信する際、ｎｏｗ１を受信確認パケットに書き込むステップと、前記送信端末が、前記受信確認パケットを受信した時、現在の時刻ｎｏｗから前記受信確認パケットに書き込まれているｎｏｗ１を減算した値を計算し、その最小値である最小往復遅延時間ＲＴＴ_ｍｉｎ、及びその最大値である最大往復遅延時間ＲＴＴ_ｍａｘを記憶するステップと、前記送信端末が、前回利用可能帯域ＡＢＥを計算した時刻から最小往復遅延時間ＲＴＴ_ｍｉｎを経過する時間の間に受信した確認応答されたパケット数を基にして利用可能帯域ＡＢＥを計算するステップと、前記送信端末が、ネットワークが輻輳状態でないと判断した場合にウインドウサイズを増加させる時、ＲＴＴ_ｍｉｎ＊ＡＢＥとＲＴＴ_ｍａｘ＊ＡＢＥを基にして、ウインドウサイズを決定するステップと、を有し、前記送信端末が、前記ウインドウサイズを決定するステップにおいて、現在、ウインドウサイズが減少した後、再び増加し始めてからｔ時間経過しているとすると、ウインドウサイズｃｗｎｄ（ｔ）を、Ｃ（ｔ−Ｋ） ^３＋ＲＴＴ_ｍａｘ＊ＡＢＥ、（Ｃは定数、Ｋは（ＡＢＥ＊（ＲＴＴ_ｍａｘ−ＲＴＴ_ｍｉｎ）／Ｃ） ^１／３である）に決定するものである。

本発明と従来の技術との差異は次の通りである。本発明では、ウインドウサイズを減少し再び増加し始めてからｔ時間経過した時刻におけるウインドウサイズｃｗｎｄ（ｔ）の値を決定する時、値ＲＴＴ_ｍｉｎ＊ＡＢＥとＲＴＴ_ｍａｘ＊ＡＢＥを基にしてその値を決定している。しかし従来のＣＵＢＩＣ−ＴＣＰではそれらの値を用いていない。またＷｅｓｔｗｏｏｄ＋は、ウインドウサイズを減少する時は値ＲＴＴ_ｍｉｎ＊ＡＢＥを用いているが、増加する時はそれらの値を用いていない。

本発明を用いれば、ギガビットレベルのスループットが実現可能なＣＵＢＩＣ−ＴＣＰの性能を向上させることができる。例えば公平な帯域を得るまでの時間を短縮することができる。

以下、本発明の実施例を図を参照して説明する。
実施例における送信端末の構成図を図６に、受信端末の構成図を図７に示す。図６（Ａ）に示すように、送信端末６００は現在時刻書込部６０１と時刻読取部６０２と往復遅延時間計算部６０３とシーケンス番号読取部６０４と利用可能帯域計算部６０５とウインドウサイズ決定部６１０とを備える。図６（Ｂ）に示すように、ウインドウサイズ決定部６１０は、サイズ増減判断部６１１とサイズ増加部６１２とサイズ減少部６１３とを備える。また、図７に示すように、受信端末７００は時刻読取部７０１と情報書込部７０２とを備える。なお、図６、図７は本実施例を説明するために必要な部分のみを図示したものであり、本実施例の送信端末、受信端末が送信端末、受信端末として通常必要とされる手段を有することは当然である。

送信端末６００はパケットＡを送信する時、現在時刻書込部６０１で現在の時刻ｎｏｗ１を書き込んだ後、パケットＡを送信する。受信端末７００はパケットＡを受信すると時刻読取部７０１でパケットＡに書き込まれている時刻情報ｎｏｗ１を読み取り、その値を情報書込部７０２に通知する。受信端末７００はパケットＡに対する受信確認パケットを送信する時、情報書込部７０２で、パケットＡに書き込まれていた時刻情報ｎｏｗ１を書き込み、パケットＢを送信する。送信端末６００はパケットＢを受信すると時刻読取部６０２でパケットＢに書き込まれている時刻情報ｎｏｗ１を読み取り、現在の時刻ｎｏｗ（パケットＢを受信した時刻）と読み取ったｎｏｗ１（パケットＡを送信した時刻）を往復遅延時間計算部６０３に通知する。往復遅延時間計算部６０３は図８に示すフローチャートに従って、最小往復遅延時間（ＲＴＴ_ｍｉｎ）、最大往復遅延時間（ＲＴＴ_ｍａｘ）を計算する。送信端末６００はまたシーケンス番号読取部６０４でパケットに付与されている次に受信を期待するパケットのシーケンス番号を読み取り、その結果を利用可能帯域計算部６０５、及びウインドウサイズ決定部６１０に通知する。利用可能帯域計算部６０５では、図９に示すフローチャートに従って、利用可能帯域（ＡＢＥ）を計算する。ウインドウサイズ決定部６１０は、サイズ増減判断部６１１、サイズ増加部６１２、サイズ減少部６１３から構成される。サイズ増減判断部６１１は、図１０−１に示すフローチャートに従って、ウインドウサイズを増加するか減少するかを決定する。サイズ増加部６１２は、図１０−２に示すフローチャートに従って、ウインドウサイズを増加する。サイズ減少部６１３は、図１０−３に示すフローチャートに従って、ウインドウサイズを減少する。

図８に、往復遅延時間計算部６０３におけるアルゴリズム（フローチャート）を示す。往復遅延時間計算部６０３は次のようにして最大往復遅延時間（ＲＴＴ_ｍａｘ）、最小往復遅延時間（ＲＴＴ_ｍｉｎ）を得て、これらを記憶装置に記憶する。まず、現在の時刻ｎｏｗと時刻読取部６０２が受信したパケットから読み取ったｎｏｗ１の差すなわちそのパケットの往復遅延時間Ｔ＝ｎｏｗ−ｎｏｗ１を計算する（ステップ８０１）。Ｔ＞ＲＴＴ_ｍａｘの場合すなわちそのパケットの往復遅延時間がそれまで記憶されていた最大往復遅延時間より大きい場合は（ステップ８０２でＹＥＳ）、ＲＴＴ_ｍａｘにＴの値を代入して、そのパケットの往復遅延時間を最大往復遅延時間として記憶する（ステップ８０３）。Ｔ＜ＲＴＴ_ｍｉｘの場合すなわちそのパケットの往復遅延時間がそれまで記憶されていた最小往復遅延時間より小さい場合は（ステップ８０４でＹＥＳ）、ＲＴＴ_ｍｉｎにＴの値を代入して、そのパケットの往復遅延時間を最小往復遅延時間として記憶する（ステップ８０５）。

図９に、利用可能帯域計算部６０５におけるアルゴリズム（フローチャート）を示す。図９において、ｌａｓｔ_ｔ_は前回ＡＢＥを計算した時刻である。Ｘはシーケンス番号読取部６０４から通知された番号である。Ｃはシーケンス番号読取部６０４から前回通知された番号である。ｄは確認応答されたパケット数である。ここで確認応答されたパケットとは、受信端末７００が受信確認したパケットのことを指す。シーケンス番号Ｘを持った受信確認パケットは、この受信確認パケットを送る原因となったパケットによって（Ｘ−Ｃ）個のパケットを受信端末７００が正しく受信したことを伝えている。よってそれらを加算したｄはその間に受信確認されたパケット数となる。αは定数である。図９のステップ９０４のＡＢＥの式は背景技術の欄で述べたＴＣＰＷｅｓｔｗｏｏｄ＋のＡＢＥの式と同じ式であり、また、図９全体のアルゴリズムもＴＣＰＷｅｓｔｗｏｏｄ＋のアルゴリズムと同じである。したがって、図９の定数αもＴＣＰＷｅｓｔｗｏｏｄ＋における定数αと同じであり、ＴＣＰＷｅｓｔｗｏｏｄ＋において定数αの推奨値として０．９が使われているので、図９の定数αの推奨値も０．９である。

利用可能帯域計算部６０５は次のようにして利用可能帯域（ＡＢＥ）を計算する。まず、利用可能帯域計算部６０５は、現在の時刻ｎｏｗと前回ＡＢＥを計算した時刻ｌａｓｔ_ｔ_との差すなわち前回ＡＢＥを計算した時刻から現在の時刻までの時間Ｔ＝ｎｏｗ−ｌａｓｔ_ｔ_を計算する（ステップ９０１）。次に、確認されたパケット数ｄにｄ＋（Ｘ−Ｃ）を代入する（ステップ９０２）。前回ＡＢＥを計算した時にｄ＝０とされているから（ステップ９０５）、ｄは前回ＡＢＥを計算したときからカウントした確認応答されたパケット数である。Ｔ≧ＲＴＴ_ｍｉｎの場合すなわち前回ＡＢＥを計算した時刻から現在の時刻までの時間が最小往復遅延時間以上の場合は（ステップ９０３でＹＥＳ）、利用可能帯域ＡＢＥ＝α＊ＡＢＥ＋（１−α）＊ｄ／Ｔを計算する（ステップ９０４）。ｄに０を代入してｄ（確認応答されたパケット数）をリセットし、ｌａｓｔ_ｔ_に現在の時刻ｎｏｗを代入してｌａｓｔ_ｔ_（前回ＡＢＥを確認した時刻）をセットする（ステップ９０５）。ＣにＸの値を代入してＣ（シーケンス番号読取部６０４から前回通知された番号）を更新し（ステップ９０６）、終了する。一方、ステップ９０３においてＮＯの場合はＣにＸの値を代入してＣ（シーケンス番号読取部６０４から前回通知された番号）を更新し（ステップ９０６）、終了する。

図９のフローチャートからわかるように、ステップ９０３でＴ≧ＲＴＴ_ｍｉｎの場合にステップ９０４でＡＢＥを計算しているので、前回利用可能帯域ＡＢＥを計算した時刻から最小往復遅延時間ＲＴＴ_ｍｉｎを経過する時間の間に受信した確認応答されたパケット数を基にして利用可能帯域ＡＢＥを計算していることになる。

次に、ウインドウサイズ決定部６１０におけるアルゴリズム（フローチャート）について詳細に説明する。
図１０−１に、サイズ増減判断部６１１におけるアルゴリズム（フローチャート）を示す。Ｃはシーケンス番号読取部６０４から前回通知された番号であり、ｎｕｍは同じ番号のシーケンス番号を受信した回数である。図１０−１に示すようにサイズ増減判断部６１１は、シーケンス番号読取部６０４から番号を通知されると（ステップ１０１１）、その値Ｘとメモリに記録してある値Ｃを比較する（ステップ１０１２）。もしＸとＣが等しくなければ（ステップ１０１２でＮＯ）、シーケンス番号が同じ受信確認パケットを連続して受信していないということなので、ｎｕｍ（同じ番号のシーケンス番号を受信した回数）を１に、Ｃ（シーケンス番号読取部６０４から前回通知された番号）をＸの値に更新し（ステップ１０１３）、ｎｕｍとＣの値をメモリに保存し、サイズ増加部６１２に向かう（図１０−２）。ＸとＣが等しければ（ステップ１０１２でＹＥＳ）、シーケンス番号が同じ受信確認パケットを連続して受信しているということなので、メモリに保存してあるｎｕｍ（同じ番号のシーケンス番号を受信した回数）の値に１を加算する（ステップ１０１４）。そしてｎｕｍが３、つまりシーケンス番号が同じである受信確認パケットを３回連続して受信したならば（ステップ１０１５でＹＥＳの場合）、ｎｕｍを１に、ＣをＸの値に更新し、ｎｕｍとＣの値をメモリに保存し（ステップ１０１６）、サイズ減少部６１３に向かう（図１０−３）。ｎｕｍが３でなければ（ステップ１０１５でＮＯの場合）、ｎｕｍの値をメモリに保存し、サイズ増加部６１２に向かう（図１０−２）。

図１０−２に、サイズ増加部６１２におけるアルゴリズム（フローチャート）を示す。ｔはウインドウサイズを減少し再び増加し始めてからの時間であり、ｔ_ｄｅｃは前回、ウインドウサイズを減少した時刻であり、ＡＢＥは利用可能帯域計算部６０５から通知された値であり、Ｗ_ｍａｘ、Ｗ_ｍｉｎは往復遅延時間計算部６０３から通知された値であり、Ｃは定数である。図１０−２の定数Ｃは背景技術の欄で述べたＣＵＢＩＣ−ＴＣＰにおけるｃｗｎｄ（ｔ）を求める式の定数Ｃと同じ定数を用いることができる。ＣＵＢＩＣ−ＴＣＰにおける定数Ｃの推奨値は０．４であるから、図１０−２の定数Ｃの推奨値も０．４である。図１０−２に示すようにサイズ増加部６１２では、メモリに記憶してある前回ウインドウサイズが減少した時刻ｔ_ｄｅｃを基にして、値ｔを計算する（ステップ１０２１）。そして利用可能帯域計算部６０５から通知されたＡＢＥ、往復遅延時間計算部６０３から通知されたＲＴＴ_ｍｉｎ、ＲＴＴ_ｍａｘ、メモリに記憶してあるＣを基にして、値Ｋ＝（ＡＢＥ＊（ＲＴＴ_ｍａｘ−ＲＴＴ_ｍｉｎ）／Ｃ）^１／３を計算する。これらの値からウインドウサイズｃｗｎｄ（ｔ）＝Ｃ（ｔ−Ｋ）^３＋ＲＴＴ_ｍａｘ＊ＡＢＥを計算し、新しいウインドウサイズを決定する（ステップ１０２２）。

図１０−３に、ウインドウサイズ決定部６１０のサイズ減少部６１３におけるアルゴリズム（フローチャート）を示す。図１０−３に示すようにサイズ減少部６１３では、利用可能帯域計算部６０５から通知されたＡＢＥ、往復遅延時間計算部６０３から通知されたＲＴＴ_ｍｉｎを基にして、ウインドウサイズｃｗｎｄ＝ＲＴＴ_ｍｉｎ＊ＡＢＥを計算し、新しいウインドウサイズを決定する（ステップ１０３１）。そしてウインドウサイズを減少した時刻を、ウインドウ増加部のメモリに記憶されているｔ_ｄｅｃに代入する（１０３２）。

以下、図１１に示す例を用いて、本実施例の動作を説明する。送信端末６００は図１１に示すように、パケット１から３を受信端末７００に向けてそれぞれ時刻１０．０００、１０．００１、１０．００２秒に送信し、受信端末７００からの受信確認パケット１から３をそれぞれ時刻１０．１０１、１０．１０２、１０．１０３秒に受信するとする。受信確認パケット１から３は、時刻情報ｎｏｗ１として、それぞれ１０．０００、１０．００１、１０．００２秒、次に受信を期待するパケットのシーケンス番号として、それぞれ１００、１０１、１０２を有しているとする。受信確認パケット１を受信する直前、図８のＲＴＴ_ｍａｘ（最大往復遅延時間）は０．２秒、ＲＴＴ_ｍｉｎ（最小往復遅延時間）は０．１秒、図９のｌａｓｔ_ｔ_（前回ＡＢＥを計算した時刻）は１０．００３秒、ｄ（確認応答されたパケット数）は１００、Ｃ（シーケンス番号読取部６０４から前回通知された番号）は９９、α（定数）は０．９、図１０−１のｎｕｍ（同じ番号のシーケンス番号を受信した回数）は１、Ｃ（シーケンス番号読取部６０４から前回通知された番号）は９９、図１０−２のｔ_ｄｅｃ（前回、ウインドウサイズを減少した時刻）は９秒、Ｃ（定数）は０．４、ＡＢＥ（利用可能帯域計算部６０５から通知された値）は１０００とする。

送信端末６００がパケット１の受信確認パケットを受信すると、時刻読取部６０２でそのパケットに書き込まれている時刻情報ｎｏｗ１を読み取る。そしてｎｏｗ１（＝１０．０００）と現在の時刻ｎｏｗ（＝１０．１０１）を往復遅延時間計算部６０３に通知する。往復遅延時間部６０３では、Ｔを計算する（図８のステップ８０１）。Ｔは０．１０１（＝１０．１０１−１０．０００）であり、この値はＲＴＴ_ｍｉｎ（＝０．１）より小さくなく（ステップ８０４でＮＯ）、ＲＴＴ_ｍａｘ（＝０．２）より大きくもないので（ステップ８０２でＮＯ）、ＲＴＴ_ｍａｘ、ＲＴＴ_ｍｉｎの値は更新されない。シーケンス番号読取部６０４ではパケットに付与されている次に受信を期待するパケットのシーケンス番号を読み取る。その値は１００であり、その値を利用可能帯域計算部６０５、及びウインドウサイズ決定部６１０に通知する。利用可帯域能計算部６０５では、Ｔ及びｄを計算する（図９のステップ９０１、９０２）。Ｔは０．０９８（＝１０．１０１−１０．００３）、ｄは１０１（＝１００＋（１００−９９））となる。Ｔ（＝０．０９８）はＲＴＴ_ｍｉｎ（＝０．１）以上ではないので（ステップ９０３でＮＯ）、新しいＡＢＥは計算されない。値Ｃは１００に更新される（ステップ９０６）。ウインドウサイズ決定部６１０では、まずサイズ増減判断部６１１でウインドウサイズを増加するかしないかを決定する。今回はＸが１００、Ｃが９９なので（図１０−１のステップ１０１２でＮＯ）、ｎｕｍを１に、Ｃを１００に更新して（ステップ１０１３）、サイズ増加部６１２に移動する。サイズ増加部ではまずｔを計算する（図１０−２のステップ１０２１）。ｔは１．１０１（＝１０．１０１−９）となる。次にＫを計算する。

よって、ウインドウサイズは

となる（ステップ１０２２）。

送信端末６００がパケット２の受信確認パケットを受信すると、時刻読取部６０２でそのパケットに書き込まれている時刻情報ｎｏｗ１を読み取る。そしてｎｏｗ１（＝１０．００１）と現在の時刻ｎｏｗ（＝１０．１０２）を往復遅延時間計算部６０３に通知する。往復遅延時間部６０３では、Ｔを計算する（図８のステップ８０１）。Ｔは０．１０１（＝１０．１０２−１０．００１）であり、この値はＲＴＴ_ｍｉｎ（＝０．１）より小さくなく（ステップ８０４でＮＯ）、ＲＴＴ_ｍａｘ（＝０．２）より大きくもないので（ステップ８０２でＮＯ）、ＲＴＴ_ｍａｘ、ＲＴＴ_ｍｉｎの値は更新されない。シーケンス番号読取部６０４ではパケットに付与されている次に受信を期待するパケットのシーケンス番号を読み取る。その値は１０１であり、その値を利用可能帯域計算部６０５、及びウインドウサイズ決定部６１０に通知する。利用可能帯域計算部６０５では、Ｔ及びｄを計算する（図９のステップ９０１、９０２）。Ｔは０．０９９（＝１０．１０２−１０．００３）、ｄは１０２（＝１０１＋（１０１−１００））となる。Ｔ（＝０．０９９）はＲＴＴ_ｍｉｎ（＝０．１）以上ではないので（ステップ９０３でＮＯ）、新しいＡＢＥは計算されない。値Ｃは１０１に更新される（ステップ９０６）。ウインドウサイズ決定部６１０では、まずサイズ増減判断部６１１でウインドウサイズを増加するかしないかを決定する。Ｘが１０１、Ｃが１００なので（図１０−１のステップ１０１２でＮＯ）、ｎｕｍを１に、Ｃを１０１に更新して（ステップ１０１３）、サイズ増加部６１２に移動する。サイズ増加部６１２ではまずｔを計算する（図１０−１の１０２１）。ｔは１．１０２（＝１０．１０２−９）となる。次にＫを計算する。

よって、ウインドウサイズは

となる（ステップ１０２２）。

送信端末６００がパケット３の受信確認パケットを受信すると、時刻読取部６０２でそのパケットに書き込まれている時刻情報ｎｏｗ１を読み取る。そしてｎｏｗ１（＝１０．００２）と現在の時刻ｎｏｗ（＝１０．１０３）を往復遅延時間計算部６０３に通知する。往復遅延時間部６０３では、Ｔを計算する（図８のステップ８０１）。Ｔは０．１０１（＝１０．１０３−１０．００２）であり、この値はＲＴＴ_ｍｉｎ（＝０．１）より小さくなく（ステップ８０４でＮＯ）、ＲＴＴ_ｍａｘ（＝０．２）より大きくもないので（ステップ８０２でＮＯ）、ＲＴＴ_ｍａｘ、ＲＴＴ_ｍｉｎの値は更新されない。シーケンス番号読取部６０４ではパケットに付与されている次に受信を期待するパケットのシーケンス番号を読み取る。その値は１０２であり、その値を利用可能帯域計算部６０５、及びウインドウサイズ決定部６１０に通知する。利用可能帯域計算部６０５では、Ｔ及びｄを計算する（図９のステップ９０１、９０２）。Ｔは０．１（＝１０．１０３−１０．００３）、ｄは１０３（＝１０２＋（１０２−１０１））となる。Ｔ（＝０．１）はＲＴＴ_ｍｉｎ（＝０．１）以上なので（ステップ９０３でＹＥＳ）、新しいＡＢＥを計算する（ステップ９０４）。

ｄは０に、ｌａｓｔ_ｔは１０．１０３に、Ｃは１０２に更新される（ステップ９０５、９０６）。ウインドウサイズ決定部６１０では、まずサイズ増減判断部６１１でウインドウサイズを増加するかしないかを決定する。Ｘが１０２、Ｃが１０１なので（図１０−１のステップ１０１２）、ｎｕｍを１に、Ｃを１０２に更新して（ステップ１０１３）、サイズ増加部６１２に移動する。サイズ増加部６１２ではまずｔを計算する（図１０−２のステップ１０２１）。ｔは１．１０３（＝１０．１０３−９）となる。次にＫを計算する。

よって、ウインドウサイズは

となる（ステップ１０２２）。

次に本実施例の効果を確認するシミュレーションを行った結果を示す。シミュレーションの条件は背景技術（図４、図５参照）で述べたものとまったく同じである。図１２に時間毎の輻輳ウインドウサイズの変化を示す。図５と図１２を比較すると、本実施例を用いた場合、１００秒に通信を開始したフローのウインドウサイズが既に通信を開始してるフローのウインドウサイズと等しくなるまでの時間が大幅に短縮できていることが確認できる。

以上説明した実施例において、送信端末および受信端末の各部はコンピュータと記憶装置に記憶されたプログラムで実現することができる。プログラム中に使用される変数名は、本実施例における変数名に限定されず、任意の変数名を使用することができる。

以上、本発明者によってなされた発明を、前記実施例に基づき具体的に説明したが、本発明は、前記実施例に限定されるものではなく、その要旨を逸脱しない範囲において種々変更可能であることは勿論である。

パケットに付与されるシーケンス番号パケットが再送される条件ウインドウサイズが減少した後、再び増加し始めてからｔ時間経過した時のウインドウサイズシミュレーションモデル従来方式を用いた場合のシミュレーション結果送信端末のシステム構成受信端末のシステム構成往復遅延時間計算部６０３におけるアルゴリズム（フローチャート）利用可能帯域計算部６０５におけるアルゴリズム（フローチャート）サイズ増減判断部６１１におけるアルゴリズム（フローチャート）サイズ増加部６１２におけるアルゴリズム（フローチャート）サイズ減少部６１３におけるアルゴリズム（フローチャート）実施例におけるパケットの送受信の流れ実施例を用いた場合のシミュレーション結果

符号の説明

６００…送信端末、６０１…現在時刻書込部、６０２…時刻読取部、６０３…往復遅延時間計算部、６０４…シーケンス番号読取部、６０５…利用可能帯域計算部、６１０…ウインドウサイズ決定部、６１１…サイズ増減判断部、６１２…サイズ増加部、６１３…サイズ減少部、７００…受信端末、７０１…時刻読取部、７０２…情報書込部

Claims

ネットワークが輻輳状態であると判断した時にウインドウサイズを減少し、そうでないと判断した時にウインドウサイズを増加する輻輳制御方法において、
送信端末が、パケット送信時に現在の時刻ｎｏｗ１をパケットに書き込むステップと、
受信端末が、前記パケットを受信した時、前記パケットに書き込まれているｎｏｗ１を読み取るステップと、
前記受信端末が、受信した前記パケットに対する受信確認パケットを送信する際、ｎｏｗ１を受信確認パケットに書き込むステップと、
前記送信端末が、前記受信確認パケットを受信した時、現在の時刻ｎｏｗから前記受信確認パケットに書き込まれているｎｏｗ１を減算した値を計算し、その最小値である最小往復遅延時間ＲＴＴ_ｍｉｎ、及びその最大値である最大往復遅延時間ＲＴＴ_ｍａｘを記憶するステップと、
前記送信端末が、前回利用可能帯域ＡＢＥを計算した時刻から最小往復遅延時間ＲＴＴ_ｍｉｎを経過する時間の間に受信した確認応答されたパケット数を基にして利用可能帯域ＡＢＥを計算するステップと、
前記送信端末が、ネットワークが輻輳状態でないと判断した場合にウインドウサイズを増加させる時、ＲＴＴ_ｍｉｎ＊ＡＢＥとＲＴＴ_ｍａｘ＊ＡＢＥを基にして、ウインドウサイズを決定するステップと、
を有し、
前記送信端末が、前記ウインドウサイズを決定するステップにおいて、現在、ウインドウサイズが減少した後、再び増加し始めてからｔ時間経過しているとすると、ウインドウサイズｃｗｎｄ（ｔ）を、Ｃ（ｔ−Ｋ） ^３＋ＲＴＴ_ｍａｘ＊ＡＢＥ、（Ｃは定数、Ｋは（ＡＢＥ＊（ＲＴＴ_ｍａｘ−ＲＴＴ_ｍｉｎ）／Ｃ） ^１／３である）に決定することを特徴とする輻輳制御方法。
ネットワークが輻輳状態であると判断した時にウインドウサイズを減少し、そうでないと判断した時にウインドウサイズを増加する輻輳制御を行う通信端末において、
パケット送信時に現在の時刻ｎｏｗ１をパケットに書き込む現在時刻書込部と、
前記パケットの受信確認パケットを受信した時、現在の時刻ｎｏｗから前記受信確認パケットに書き込まれているｎｏｗ１を減算した値を計算し、その最小値である最小往復遅延時間ＲＴＴ_ｍｉｎ、及びその最大値である最大往復遅延時間ＲＴＴ_ｍａｘを記憶する往復時間計算部と、
前回利用可能帯域ＡＢＥを計算した時刻から最小往復遅延時間ＲＴＴ_ｍｉｎを経過する時間の間に受信した確認応答されたパケット数を基にして利用可能帯域ＡＢＥを計算する利用可能帯域計算部と、
ネットワークが輻輳状態でないと判断した場合にウインドウサイズを増加させる時、ＲＴＴ_ｍｉｎ＊ＡＢＥとＲＴＴ_ｍａｘ＊ＡＢＥを基にして、ウインドウサイズを決定するウインドウサイズ決定部と、
を備え、
前記ウインドウサイズ決定部が、現在、ウインドウサイズが減少した後、再び増加し始めてからｔ時間経過しているとすると、ウインドウサイズｃｗｎｄ（ｔ）を、Ｃ（ｔ−Ｋ） ^３＋ＲＴＴ_ｍａｘ＊ＡＢＥ、（Ｃは定数、Ｋは（ＡＢＥ＊（ＲＴＴ_ｍａｘ−ＲＴＴ_ｍｉｎ）／Ｃ） ^１／３である）に決定することを特徴とする通信端末。