(57)【要約】【課題】  ネットワークが輻輳状態にあると判断した時にウインドウサイズの値が連続して減少しており、且つ、減少幅がある値を越えている場合、ウインドウ減少パラメータの値を大きくして、新たに通信を開始したフローが広帯域のスループットを得るまでの時間を短縮することが可能な輻輳制御方法を提供する。【解決手段】  現在のウインドサイズ（cwnd）と、保持してあるウインドサイズ（W_prev）とを比較し、W_prevがcwndより大きいときに、変数（numDec）に１を加算し、前記numDecの値がパラメータ（N1）以上、且つ、変数（W_max）からcwndを減算した値がパラメータ（S）以上という条件を満たすときに、numDec、W_maxおよびW_prevの値に０を代入し、ウインドウ減少パラメータ（b）の値に０．５を代入する。また、W_prevがcwnd以下のときに、numDecの値に０を代入し、W_maxおよびW_prevの値にcwndを代入し、ウインドウ減少パラメータ（b）の値に、HighSpeed TCPで使用される値を代入する。【選択図】        図２−３−２
2006005405.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークが輻輳状態にあると判断した時にウインドウサイズを減少させる輻輳制御手段を備える送信端末であって、
前記輻輳制御手段は、ネットワークが輻輳状態にあると判断した時に、ウインドウサイズの値が連続して減少しており、且つ、減少幅がある値を越えているならば、ウインドウサイズの減少率を、そうでない場合に比べて高くすることを特徴とする送信端末。
【請求項２】
ネットワークが輻輳状態にあると判断した時にウインドウサイズを減少させる輻輳制御手段を備える送信端末であって、
前記輻輳制御手段は、ネットワークが輻輳状態にあると判断した時に、現在のウインドサイズ（cwnd）と、保持してあるウインドサイズ（W_prev）とを比較する手段１と、
前記手段１で比較した結果、前記保持してあるウインドサイズ（W_prev）が前記現在のウインドサイズ（cwnd）より大きいときに、変数（numDec）に１を加算する手段２と、
前記変数（numDec）の値がパラメータ（N1）以上、且つ、変数（W_max）から前記現在のウインドサイズ（cwnd）を減算した値がパラメータ（S）以上という条件を満たすか否かを判断する手段３と、
前記手段３で判断した結果、前記条件を満たすときに、前記変数（numDec）、前記変数（W_max）および前記保持してあるウインドサイズ（W_prev）の値に０を代入し、ウインドウ減少パラメータ（b）の値に０．５を代入する手段４と、
前記手段３で判断した結果、前記条件を満たさないときに、前記変数（numDec）がパラメータ（N2）と等しいか否かを判断する手段５と、
前記手段１で比較した結果、前記保持してあるウインドサイズ（W_prev）が前記現在のウインドサイズ（cwnd）以下のとき、および、前記手段５で判断した結果、前記変数（numDec）がパラメータ（N2）と等しいときに、前記変数（numDec）の値に０を代入し、前記変数（W_max）および前記保持してあるウインドサイズ（W_prev）の値に前記現在のウインドサイズ（cwnd）を代入し、前記ウインドウ減少パラメータ（b）の値に、HighSpeed TCPで使用される値を代入する手段６と、
前記手段５で判断した結果、前記変数（numDec）がパラメータ（N2）と等しくないときに、前記保持してあるウインドサイズ（W_prev）の値に前記現在のウインドサイズ（cwnd）を代入し、前記ウインドウ減少パラメータ（b）の値に、HighSpeed TCPで使用される値を代入する手段７とを有することを特徴とする送信端末。
【請求項３】
ネットワークが輻輳状態にあると判断した時にウインドウサイズを減少させる送信端末の輻輳制御方法であって、
ネットワークが輻輳状態にあると判断した時に、ウインドウサイズの値が連続して減少しており、且つ、減少幅がある値を越えているならば、ウインドウサイズの減少率を、そうでない場合に比べて高くすることを特徴とする輻輳制御方法。
【請求項４】
ネットワークが輻輳状態にあると判断した時にウインドウサイズを減少させる送信端末の輻輳制御方法であって、
ネットワークが輻輳状態にあると判断した時に、現在のウインドサイズ（cwnd）と、保持してあるウインドサイズ（W_prev）とを比較するステップ１と、
前記ステップ１で比較した結果、前記保持してあるウインドサイズ（W_prev）が前記現在のウインドサイズ（cwnd）より大きいときに、変数（numDec）に１を加算するステップ２と、
前記変数（numDec）の値がパラメータ（N1）以上、且つ、変数（W_max）から前記現在のウインドサイズ（cwnd）を減算した値がパラメータ（S）以上という条件を満たすか否かを判断するステップ３と、
前記ステップ３で判断した結果、前記条件を満たすときに、前記変数（numDec）、前記変数（W_max）および前記保持してあるウインドサイズ（W_prev）の値に０を代入し、ウインドウ減少パラメータ（b）の値に０．５を代入するステップ４と、
前記ステップ３で判断した結果、前記条件を満たさないときに、前記変数（numDec）がパラメータ（N2）と等しいか否かを判断するステップ５と、
前記ステップ１で比較した結果、前記保持してあるウインドサイズ（W_prev）が前記現在のウインドサイズ（cwnd）以下のとき、および、前記ステップ５で判断した結果、前記変数（numDec）がパラメータ（N2）と等しいときに、前記変数（numDec）の値に０を代入し、前記変数（W_max）および前記保持してあるウインドサイズ（W_prev）の値に前記現在のウインドサイズ（cwnd）を代入し、前記ウインドウ減少パラメータ（b）の値に、HighSpeed TCPで使用される値を代入するステップ６と、
前記ステップ５で判断した結果、前記変数（numDec）がパラメータ（N2）と等しくないときに、前記保持してあるウインドサイズ（W_prev）の値に前記現在のウインドサイズ（cwnd）を代入し、前記ウインドウ減少パラメータ（b）の値に、HighSpeed TCPで使用される値を代入するステップ７とを有することを特徴とする輻輳制御方法。
【請求項５】
請求項３あるいは請求項４の輻輳制御方法をコンピュータに実行させるための輻輳制御プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、送信端末、輻輳制御方法、および輻輳制御プログラムに係り、特に、トランスポート層に実装される輻輳制御アルゴリズムにおいて、ネットワークの輻輳度に応じて、どの程度ウインドウサイズを減少させるかを計算する技術に関する。
【背景技術】
【０００２】
現在のインターネットで使用されている端末は、トランスポートプロトコルにＴＣＰ（Transmission Control Protocol）を実装している。
ＴＣＰにおける輻輳制御アルゴリズムは、スロースタート段階と輻輳回避段階に分けることができる（下記、非特許文献１参照）。
ここでは、本提案に関係のある輻輳回避段階におけるアルゴリズムについてのみ述べる。
ＴＣＰを使用している送信端末はパケットを送信する時、各パケットにシーケンス番号を付与する。受信端末はパケットを正しく受信すると、次に受信を期待するパケットのシーケンス番号が付与された受信確認パケットを送信する。
図５の例では、シーケンス番号１００或いは１０１のパケットを受信すると、受信端末は、次に受信を期待するパケットのシーケンス番号１０１或いは１０２が付与された受信確認パケットを送信している。
なお、図５は、従来のＴＣＰにおいて、パケットに付与されるシーケンス番号を説明するための図である。
また、送信端末は、輻輳ウインドウ（cwnd）と呼ばれる変数を管理しており、cwndの値だけ、パケットを受信端末からの受信確認パケットの到着なしに送信することができる。
例えば、cwndの値が１００の時、送信端末は１００個のパケットを受信確認パケットの到着なしに送信することができる。
送信端末は、cwndの値分の受信確認パケットを受信すると、ネットワークが輻輳状態にないと判断し、cwndの値を１だけ増加させる。
つまり先程の例では、１００個のパケットに対する受信確認パケットを受信すると、輻輳ウインドウ（cwnd）の値を１だけ増加させ、１０１にする。
【０００３】
一方、次に受信を期待するパケットのシーケンス番号が同じである受信確認パケットを３回連続して受信すると、ネットワークが輻輳状態にあると判断し、輻輳ウインドウ（cwnd）の値を半分にし、そのシーケンス番号のパケットを再送する。
図６では、シーケンス番号１０１のパケットがネットワーク内で廃棄され、送信端末は次に受信を期待するパケットのシーケンス番号が１０１である受信確認パケットを３回受信したので、シーケンス番号が１０１のパケットを再送している。
なお、図６は、従来のＴＣＰにおいて、パケットが再送される条件を説明するための図である。
前述した処理内容が、ＴＣＰにおける輻輳制御アルゴリズムの基本的動作であるが、近年、このアルゴリズムでは、往復伝播遅延時間が長い場合、ギガビットレベルのスループットが実現不可能であることが報告され、新しく、ＨＳ−ＴＣＰ（High-speed TCP）が提案されている（下記、非特許文献２参照）。
ＨＳ−ＴＣＰでは、送信端末は、cwndの値分の受信確認パケットを受信すると、ネットワークが輻輳状態にないと判断し、cwndの値をaだけ増加させる。
一方、次に受信を期待するパケットのシーケンス番号が同じである受信確認パケットを３回連続して受信すると、ネットワークが輻輳状態にあると判断し、cwndの値を（１−b）倍にする。
ここで、a，bは、それぞれウインドウ増加パラメータ、ウインドウ減少パラメータと呼ばれ、下記式で定義される。
【０００４】
【数１】
2006005405.tif 000003
・・・・・・・・・・・・・・・  （１）
【０００５】
なお、本願発明に関連する先行技術文献としては以下のものがある。
【非特許文献１】村山他、”トランスポートプロトコル”，岩波書店,2001年 4月 6日発行，ｐｐ．174〜177
【非特許文献２】S,Floyd, "HighSpeed TCP for Large Congestion Windows",RFC 3649,December 2003
【発明の開示】
【発明が解決しようとする課題】
【０００６】
ＨＳ−ＴＣＰは、従来のＴＣＰの輻輳制御アルゴリズムに比べて、ウインドウ増加パラメータの値を大きく、つまり、輻輳ウインドウ（cwnd）の増加率を高くし、且つ、ウインドウ減少パラメータの値を小さく、つまり、輻輳ウインドウ（cwnd）の減少率を低くすることにより、往復遅延時間が長い場合でも、ギガビットレベルのスループットが実現可能であるようにしている。
しかし、ＨＳ−ＴＣＰでは、あるフローが、ウインドウサイズが大きい状態で通信を行っている時に、別のフローが通信を始めると、通信を開始したフローのウインドウサイズがなかなか増加しないという問題がある。
以下に、この問題を確認するシミュレーションを行った結果を示す。
図７にシミュレーションモデルを示す。図７において、１−１，１−２は送信端末、２−１，２−２は受信端末、３はルータである。
図７に示すモデルでは、送信端末および受信端末はそれぞれ２つで、リンク帯域は１Ｇｂｐｓであり、送信・受信端末間の伝播遅延時間を５０ミリ秒、パケットサイズを１５００バイトとした。
送信端末は常に送信するパケットを有しており、１つ目の送信端末（１−１）は、時刻０秒に通信を開始し、２つ目の送信端末（１−２）は、時刻１００秒に通信を開始するとした。
【０００７】
図８に、時間ごとの輻輳ウインドウサイズの変化を示す。
図８に示すように、時刻１００秒に通信を開始したフローのウインドウサイズが、既に通信を開始しているフローのウインドウサイズと等しくなるまでに５００秒以上かかり、かなりの時間がかかっていることが確認できる。
つまり、ＨＳ−ＴＣＰでは、新たに通信を開始したフローは広帯域のスループットを得るまでかなりの時間がかかるという問題がある。
本発明は、前記従来技術の問題点を解決するためになされたものであり、本発明の目的は、送信端末、および輻輳制御方法において、新たに通信を開始したフローが広帯域のスループットを得るまでの時間を短縮することが可能となる技術を提供することにある。
また、本発明の他の目的は、前述の輻輳制御方法をコンピュータに実行させるための輻輳制御プログラムを提供することにある。
本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述及び添付図面によって明らかにする。
【課題を解決するための手段】
【０００８】
本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、下記の通りである。
本願発明は、ネットワークが輻輳状態にあると判断した時に、ウインドウサイズの値が連続して減少しており、且つ、減少幅がある値を越えているならば、ウインドウサイズの減少率を、そうでない場合に比べて高くすることを特徴とするものであり、これにより、新たに通信を開始したフローが広帯域のスループットを得るまでの時間を短縮する点である。
従来の技術との差異は以下の通りである。
（１）本発明では、ネットワークが輻輳状態にあると判断した時のウインドウサイズが連続して減少しているかどうかを調べている。しかし従来方式ではそのようなことは行っていない。
（２）本発明では、ネットワークが輻輳状態にあると判断した時のウインドウサイズの減少幅がある値以上かどうかを調べている。しかし従来方式ではそのようなことは行っていない。
（３）本発明では、ネットワークが輻輳状態にあると判断した時のウインドウサイズの値が連続して減少しており、且つ、減少幅がある値を越えているならば、ウインドウサイズの減少率をそうでない場合に比べて高くしている。しかし従来方式ではそのようなことは行っていない。
【発明の効果】
【０００９】
本願において開示される発明のうち代表的なものによって得られる効果を簡単に説明すれば、下記の通りである。
本発明によれば、ギガビットレベルのスループットが実現可能なＨＳ−ＴＣＰ（High-speed TCP）において、新たに通信を始めたフローは短時間で広帯域通信が可能となる。
【発明を実施するための最良の形態】
【００１０】
以下、図面を参照して本発明の実施例を詳細に説明する。
なお、実施例を説明するための全図において、同一機能を有するものは同一符号を付け、その繰り返しの説明は省略する。
図１は、本発明の実施例の送信端末の概略構成を示すブロック図である。
なお、図１では、送信端末における、本願発明に係わる構成（本実施例の輻輳制御方法を実行するための輻輳制御手段の構成）のみを図示し、その他の構成の図示は省略している。
送信端末は、受信確認パケットを受信すると、シーケンス番号読取部１１において、パケットに付与されている次に受信を期待するパケットのシーケンス番号を読み取り、その結果をウインドウサイズ決定部１２に通知する。
ウインドウサイズ決定部１２は、サイズ増減判断部１２１において、図２−１のフローチャートに従い、ウインドウサイズを増加するか減少するかを判断し、サイズ増減判断部１２１において増加すると判断したならば、サイズ増加部１２２において、図２−２のフローチャートに従ってウインドウサイズを増加させる。
サイズ増減判断部１２１において減少させると判断したならば、サイズ減少部１２３において、図２−３−１から図２−３−３のフローチャートに従ってウインドウサイズを減少させる。
【００１１】
以下、各フローチャートについて説明する。
図２−１は、図１に示すサイズ増減判断部１２１におけるアルゴリズムを示すフローチャートである。
サイズ増減判断部１２１は、シーケンス番号読取部１１からシーケンス番号を通知されると、その値（X）とメモリに記録してある値（C）を比較する（ステップ２０１）。
もし、ステップ２０１での比較の結果、XとCが等しくなければ、シーケンス番号が同じ受信確認パケットを連続して受信していないということなので、num（同じ番号のシーケンス番号を受信した回数）を１に更新し（ステップ２０２）、numとXの値をメモリに保存し、サイズ増加部１２２に処理を渡す。
ステップ２０１での比較の結果、XとCが等しければ、シーケンス番号が同じ受信確認パケットを連続して受信しているということなので、メモリに保存してあるnumの値に１を加算する（ステップ２０３）。
そして、numが３か否かを判断し（ステップ２０４）、numが３、つまりシーケンス番号が同じである受信確認パケットを３回連続して受信したならば、numを１に更新し（ステップ２０５）、numとXの値をメモリに保存し、サイズ減少部１２３に処理を渡す。
ステップ２０４で、numが３でなければ、numの値をメモリに保存し、サイズ増加部１２２に処理を渡す。
【００１２】
図２−２は、図１に示すサイズ増加部１２２におけるアルゴリズムを示すフローチャートである。
サイズ増加部１２２は、メモリに記録してあるcnt（受信確認パケットを受信した回数）に１を加算し（ステップ２１１）、cntが現在の輻輳ウインドウ（cwnd）と等しくなったかどうかを調べる（ステップ２１２）。
ステップ２１２での結果がＮＯ、即ち、cntとcwndとが等しくなければ、cntの値をメモリに保存し処理を終了する。
ステップ２１２での結果がＹＥＳ、即ち、cntとcwndとが等しければ、cwndの値を、前述の（２）式で定義されているウインドウ増加パラメータ（a）だけ増加させる（ステップ２１３）。
そして、cntの値を０にして（ステップ２１４）、メモリに保存し、処理を終了する。
【００１３】
サイズ減少部１２３は、連続減少判断部１２３１、減少幅判断部１２３２、減少実行部１２３３、情報管理部１２３４から構成される。
図２−３−１は、図１に示す連続減少判断部１２３１におけるアルゴリズムを示すフローチャートである。
連続減少判断部１２３１は、情報管理部１２３４から読み取ったW_prev（前回ネットワークが輻輳状態にあると判断した時のウインドウサイズ）が、cwndより大きいかを調べる（ステップ２２１）。
ステップ２２１での結果がＹＥＳ、即ち、W_prevがcwndより大きい（W_prev＞cwnd）ときは、ネットワークが輻輳状態にあると判断した時のウインドウサイズが連続して減少しているということなので、情報管理部１２３４から読み取ったnmDec（ネットワークが輻輳状態にあると判断した時のウインドウサイズが連続して減少している回数）に１を加算し（ステップ２２２）、decFlagの値を１として（ステップ２２３）、減少幅判断部１２３２に処理を渡す。
ステップ２２１での結果がＮＯ、即ち、W_prevがcwnd以下（W_prev≦cwnd）ときは、decFlagの値を０として（ステップ２２４）、減少幅判断部１２３２に処理を渡す。
【００１４】
図２−３−２は、図１に示す減少幅判断部１２３２におけるアルゴリズムを示すフローチャートである。
減少幅判断部１２３２は、decFlagの値が１か否かを判断する（ステップ２３１）。
ステップ２３１での判断結果がＮＯ、即ち、decFlagの値が０ならば、ウインドウサイズが連続して減少していないということなので、numDecの値を０を、W_max（ウインドウサイズの減少が始まった時のウインドウサイズ）の値をcwndとし（ステップ２３５）、次に、W_prevの値をcwndとするとともに、ウインドウ減少パラメータ（b）の値に、前述の（２）式で定義されているウインドウ減少パラメータを代入し（ステップ２３６）、これらの値を情報管理部１２３４に保存した後、減少実行部１２３３に処理を渡す。
ステップ２３１での判断結果がＹＥＳ、即ち、decFlagが１ならば、ウインドウサイズが連続して減少しているということなので、以下の２つ条件を満足するかどうかを調べる（ステップ２３２）。
（１）numDecがパラメータ（N1）以上（numDec≧N1）か？
（２）（W_max−cwnd）がパラメータ（S）以上｛（W_max−cwnd≧S｝か？
１つ目の条件は、連続して減少している回数が（N1）以上であるかを調べ、２つ目の条件は、減少の幅が（S）以上であるかを調べている。
【００１５】
ステップ２３２の結果がＹＥＳ、即ち、前述の２つの条件を満足しているならば、numDecの値に０を代入し、W_maxおよびW_prevの値に０を代入し、bの値に０．５を代入して（ステップ２３３）、これらの値を情報管理部１２３４に保存した後、減少実行部１２３３に処理を渡す。
ウインドウ減少パラメータ（b）を、０．５にする理由は、現在使用されているＴＣＰが、ウインドウ減少パラメータ（b）として０．５を用いているので、それと合わせる為である。
ステップ２３２での判断結果がＮＯ、即ち、前述の２つの条件を満足していないならば、numDecがパラメータ（N2）と等しいか（numDec＝N2）を調べる（ステップ２３４）。
ステップ２３４での結果がＹＥＳ、即ち、numDecがN2と等しければ、ウインドウサイズの減少が始まってからかなりの時間が経過しているので、W_maxの値が古くなったと判断し、ステップ２３５に進み、numDecの値に０を代入、W_maxの値にcwndを代入した後、ステップ２３６に進む。
ステップ２３４での結果がＮＯの場合、即ち、numDecがN2と等しくなければ、ステップ２３６に進み、W_prevの値をcwndとするとともに、ウインドウ減少パラメータ（b）の値に、前述の（２）式で定義されているウインドウ減少パラメータを代入し、減少実行部１２３３に処理を渡す。
図２−３−３は、図１に示す減少実行部１２３３におけるアルゴリズムを示すフローチャートである。
減少実行部１２３３は、cwndの値を、cwndに（1.0−b）を掛け算した値｛（1.0−b）＊cwnd｝とする（ステップ２４１）。０＜（1.0−b）＜１なので、cwndの値は減少することになる。
【００１６】
以下、図３に示す例を用いて、本発明の動作を説明する。
図３に示すように、送信端末は、１から３の受信確認パケットを受信し、１から３の各受信確認パケット１は、次に受信を期待するパケットのシーケンス番号として、それぞれ、１００、１００、１００を有しているものとする。
受信確認パケット１を受信する直前、図２−１に示すCは９９、numは１であり、図２−２に示すcntは５０９０、cwndは５１００、a（cwnd＝5100）は２０であり、図２−３−１に示すW_prevは５２００、numDecは２、図２−３−２に示すW_maxは５２５０、N1は３、N2は１０、Sは１００、HS_b（cwnd＝5100）は０．２５であるとする。
送信端末が、受信確認パケット１を受信すると、シーケンス番号読取部１１において、次に受信を期待するパケットのシーケンス番号を読み取り、その結果をウインドウサイズ決定部１２に通知する。
受信確認パケット１が有する次に受信を期待する受信確認パケットのシーケンス番号は１００なので、この例では、１００がウインドウサイズ決定部１２に通知される。
サイズ増減判断部１２１では、通知されたシーケンス番号X（＝１００）と保持している前回通知された番号C（＝９９）が異なるので、numの値を１に更新し、num（＝１）とX（＝１００）をメモリに保存し、サイズ増加部１２２に処理を渡す。
サイズ増加部１２２では、メモリに記録してあるcntに１を加算する。つまり、cntは５０９０＋１＝５０９１になる。
そして、cntがcwndと等しくなったかどうかを調べる。cntは５０９１、cwndは５１００なので、cntとcwndは等しくない。
よって、cnt（＝５０９１）をメモリに保存し処理を終了する。
【００１７】
送信端末が受信確認パケット２を受信すると、シーケンス番号読取部１１において、次に受信を期待する受信確認パケットのシーケンス番号を読み取り、その結果をウインドウサイズ決定部１２に通知する。
受信確認パケット２が有する次に受信を期待する受信確認パケットのシーケンス番号は１００なので、１００がウインドウサイズ決定部１２に通知される。
サイズ増減判断部１２１では、通知されたシーケンス番号X（＝１００）と保持している前回通知された番号C（＝１００）が等しいので、メモリに保存してあるnumの値に１を加算する。つまり、numの値は２になる。
しかし、numの値は３ではないので、num（＝２）をメモリの保存し、サイズ増加部１２２に処理を渡す。
サイズ増加部１２２では、メモリに記録してあるcntに２を加算する。つまり、cntは５０９１＋１＝５０９２になる。
そして、cntがcwndと等しくなったかどうかを調べる。cntは５０９２、cwndは５１００なので、cntとcwndは等しくない。
よって、cnt（＝５０９２）をメモリに保存し処理を終了する。
【００１８】
送信端末が受信確認パケット３を受信すると、シーケンス番号読取部１１で次に受信を期待する受信確認パケットのシーケンス番号を読み取り、その結果をウインドウサイズ決定部１２に通知する。
受信確認パケット３が有する次に受信を期待する受信確認パケットのシーケンス番号は１００なので、１００がウインドウサイズ決定部１２に通知される。
サイズ増減判断部１２１では、通知されたシーケンス番号X（＝１００）と保持している前回通知された番号C（＝１００）が等しいので、メモリに保存してあるnumの値に１を加算する。つまり、numの値は３になる。
numの値が３になったので、numを１に更新し、num（＝１）とX（＝１００）をメモリに保存し、サイズ減少部１２３に処理を引き渡す。
連続減少判断部１２３１においては、情報管理部１２３４から読み取ったW_prevがcwndより大きいかを調べる。W_prevは５２００、cwndは５１００なので、W_prevは、cwndより大きい。
よって、情報管理部１２３４から読み取ったnumDec（＝２）の値に１を加算し、decFlagの値を１とし、減少幅判断部１２３２に処理を渡す。
【００１９】
減少幅判断部１２３２では、decFlagの値が１なので、以下の２つ条件を満足するかどうかを調べる。
（１）numDecがパラメータ（N1）以上であるか？
（２）（W_max−cwnd）がパラメータ（S）以上であるか？
numDec（＝３）はN1（＝３）以上、W_max−cwnd（５２５０−５１００＝１５０）は、S（＝１００）以上なので、numDecの値に０を代入、W_maxの値に０を代入、W_prevの値に０を代入して、これらの値を情報管理部１２３４に保存する。そして、ウインドウ減少パラメータ（b）の値に０．５を代入して、減少実行部１２３３に処理を渡す。
減少実行部１２３３では、cwndの値を、cwndに（１．０−ｂ）を掛け算した値にする。
よって、ウインドウサイズは、５１００から（１−ｂ）＊cwnd＝（１−０．５）＊５１００＝２５５０に減少される。
【００２０】
本実施例による効果を確認するためにシミュレーションを行った。ミュレーションの条件は、前述の図８の場合とまったく同じである。
このシミュレーションで用いられるパラメータとしては、N1＝３、N2＝１０、S＝W_max/３２を用いた。但し、Sが２００より大きい場合には、Sの値を２００に、Sが５０より小さい場合にはSの値を５０にした。
図４に、時間ごとの輻輳ウインドウサイズの変化を示す。
図４と図８を比較すると、本実施例の輻輳制御方法を用いた場合、時刻１００秒に通信を開始したフローのウインドウサイズが既に通信を開始しているフローのウインドウサイズと等しくなるまでの時間が２００秒以下と、短縮できていることが確認できる。
なお、前述の説明において、送信端末をコンピュータで実行させることも可能であり、その場合に、本願発明の輻輳制御方法は、コンピュータ内のハードディスクなどに格納されるプログラムを、コンピュータが実行することにより行われる。このプログラムは、ＣＤ−ＲＯＭ、あるいは、ネットワークを介したダウンロードにより供給される。
以上、本発明者によってなされた発明を、前記実施例に基づき具体的に説明したが、本発明は、前記実施例に限定されるものではなく、その要旨を逸脱しない範囲において種々変更可能であることは勿論である。
【図面の簡単な説明】
【００２１】
【図１】本発明の実施例の送信端末の概略構成を示すブロック図である。
【図２−１】図１に示すサイズ増減判断部におけるアルゴリズムを示すフローチャートである。
【図２−２】図１に示すサイズ増加部におけるアルゴリズムを示すフローチャートである。
【図２−３−１】図１に示す連続減少判断部におけるアルゴリズムを示すフローチャートである。
【図２−３−２】図１に示す減少幅判断部におけるアルゴリズムを示すフローチャートである。
【図２−３−３】図１に示す減少実行部におけるアルゴリズムを示すフローチャートである。
【図３】本発明の実施例におけるパケットの流れを説明する図である。
【図４】本発明の実施例を輻輳制御方法を使用した場合のシミュレーション結果として、時間ごとの輻輳ウインドウサイズの変化を示すグラフである。
【図５】従来のＴＣＰにおいて、パケットに付与されるシーケンス番号を説明するための図である。
【図６】従来のＴＣＰにおいて、パケットが再送される条件を説明するための図である。
【図７】従来の輻輳制御方法を使用してシミュレーションした時の、シミュレーションモデルを示す図である。
【図８】従来の輻輳制御方法を使用した場合のシミュレーション結果として、時間ごとの輻輳ウインドウサイズの変化を示すグラフである。
【符号の説明】
【００２２】
１−１，１−２  送信端末
２−１，２−２  受信端末
３  ルータ
１１  シーケンス番号読取部
１２  ウインドウサイズ決定部
１２１  サイズ増減判断部
１２２  サイズ増加部
１２３  サイズ減少部
１２３１  連続減少判断部
１２３２  減少幅判断部
１２３３  減少実行部
１２３４  情報管理部
【図１】
2006005405.tif 000004
【図２−１】
2006005405.tif 000005
【図２−２】
2006005405.tif 000006
【図２−３−１】
2006005405.tif 000007
【図２−３−２】
2006005405.tif 000008
【図２−３−３】
2006005405.tif 000009
【図３】
2006005405.tif 000010
【図４】
2006005405.tif 000011
【図５】
2006005405.tif 000012
【図６】
2006005405.tif 000013
【図７】
2006005405.tif 000014
【図８】
2006005405.tif 000015