(57)【要約】【課題】往復伝播遅延時間が短いネットワークにおいてＨＳ−ＴＣＰが従来のＴＣＰとネットワーク帯域を共有した場合、それぞれが帯域を平等に使用する技術を提供する。【解決手段】送信端末５００は、現在のウインドウサイズの値と、測定された最小遅延時間とあらかじめ設定された時間から一意に決まる値を比較し、その結果を通知するモード決定部５０５と、モード決定部５０５の通知に基づき、現在のウインドウサイズが前記一意に決まる値より大きければ、ＨｉｇｈＳｐｅｅｄ  ＴＣＰのアルゴリズムに従って現在のウインドウサイズの値を更新し、現在のウインドウサイズが前記一意に決まる値以下ならば、ＴＣＰのアルゴリズムに従って現在のウインドウサイズの値を更新するウインドウサイズ決定部５０２と、を備える。【選択図】        図５
2006217235.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークが輻輳状態にあると判断した時にウインドウサイズを減少し、そうでないと判断した時にウインドウサイズを増加する送信端末の輻輳制御方法において、
前記送信端末が、現在のウインドウサイズの値と、測定された最小遅延時間とあらかじめ設定された時間から一意に決まる値を比較し、現在のウインドウサイズが前記一意に決まる値より大きければ、ＨｉｇｈＳｐｅｅｄ  ＴＣＰのアルゴリズムに従って現在のウインドウサイズの値を更新し、現在のウインドウサイズが前記一意に決まる値以下ならば、ＴＣＰのアルゴリズムに従って現在のウインドウサイズの値を更新することを特徴とする輻輳制御方法。
【請求項２】
請求項１の輻輳制御方法において、
前記測定された最小遅延時間とあらかじめ設定された時間から一意に決まる値は、あらかじめ設定された時間の２倍を測定された最小遅延時間で割った値であることを特徴とする輻輳制御方法。
【請求項３】
ネットワークが輻輳状態にあると判断した時にウインドウサイズを減少し、そうでないと判断した時にウインドウサイズを増加する送信端末において、
現在のウインドウサイズの値と、測定された最小遅延時間とあらかじめ設定された時間から一意に決まる値を比較し、その結果を通知するモード決定部と、
前記モード決定部の通知に基づき、現在のウインドウサイズが前記一意に決まる値より大きければ、ＨｉｇｈＳｐｅｅｄ  ＴＣＰのアルゴリズムに従って現在のウインドウサイズの値を更新し、現在のウインドウサイズが前記一意に決まる値以下ならば、ＴＣＰのアルゴリズムに従って現在のウインドウサイズの値を更新するウインドウサイズ決定部と、
を備えることを特徴とする通信端末。
【請求項４】
請求項３の通信端末において、
前記測定された最小遅延時間とあらかじめ設定された時間から一意に決まる値は、あらかじめ設定された時間の２倍を測定された最小遅延時間で割った値であることを特徴とする通信端末。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークが輻輳状態にあると判断した時にウインドウサイズを減少し、そうでないと判断した時にウインドウサイズを増加する送信端末の輻輳制御方法とその送信端末に関し、特に現在のウインドウサイズに応じて、どの程度ウインドウサイズを増加、もしくは減少させるかを決定する技術に関する。
【背景技術】
【０００２】
現在のインターネットで使用されている端末はトランスポートプロトコルにＴＣＰ（Transmission Control Protocol）を実装している。ＴＣＰにおける輻輳制御アルゴリズムは、スロースタート段階と輻輳回避段階に分けることができる（非特許文献１参照）。ここでは本発明に関係のある輻輳回避段階におけるアルゴリズムについてのみ述べる。
【０００３】
ＴＣＰを使用している送信端末はパケットを送信する時、各パケットにシーケンス番号と現在の時刻を付与する。受信端末はパケットを正しく受信すると、次に受信を期待するパケットのシーケンス番号と受信したパケットに書き込まれていた時刻情報を付与した受信確認パケットを送信する。図１を用いてパケットに付与されるシーケンス番号と時刻情報について説明する。（Ａ）に送信端末と受信端末との間でやりとりされるパケットの様子を示す。（Ａ）に示した長方形はパケットを表し、その中に示した数字は（Ｂ）に示すようにパケットに付与されるシーケンス番号と時刻情報である。図１（Ａ）の例では、シーケンス番号１００、時刻情報１０或いはシーケンス番号１０１、時刻情報１０．０１のパケットを受信すると、受信端末は次に受信を期待するパケットのシーケンス番号１０１、時刻情報１０或いは１０２、時刻情報１０．０１が付与された受信確認パケットを送信している。
【０００４】
また送信端末は、輻輳ウインドウ（ｃｗｎｄ）と呼ばれる変数を管理しており、ｃｗｎｄの値だけパケットを受信端末からの受信確認パケットの到着なしに送信することができる。例えばｃｗｎｄの値が１００の時、送信端末は１００個のパケットを受信確認パケットの到着なしに送信することができる。送信端末はｃｗｎｄ個の受信確認パケットを受信すると、ネットワークが輻輳状態にないと判断し、ｃｗｎｄの値を１だけ増加させる。つまり先程の例では１００個のパケットに対する受信確認パケットを受信すると、ｃｗｎｄの値を１だけ増加させ、１０１にする。一方、次に受信を期待するパケットのシーケンス番号が同じである受信確認パケットを３回連続して受信すると、ネットワークが輻輳状態にあると判断し、ｃｗｎｄの値を半分にし、そのシーケンス番号のパケットを再送する。図２を用いてパケットが再送される条件について説明する。図２ではシーケンス番号１０１のパケットがネットワーク内で廃棄され、送信端末は次に受信を期待するパケットのシーケンス番号が１０１である受信確認パケットを３回受信したので、シーケンス番号が１０１のパケットを再送している。
【０００５】
上記が従来のＴＣＰにおける輻輳制御アルゴリズムの基本的動作であるが、近年このアルゴリズムでは、往復伝播遅延時間が長い場合、ギガビットレベルのスループットが実現不可能であることが報告され、新しくＨｉｇｈＳｐｅｅｄ  ＴＣＰ（ＨＳ−ＴＣＰ）が提案されている（非特許文献２参照）。ＨＳ−ＴＣＰでは、送信端末はｃｗｎｄ分の受信確認パケットを受信すると、ネットワークが輻輳状態にないと判断し、ｃｗｎｄの値をＨＳ_ａだけ増加させる。一方、次に受信を期待するパケットのシーケンス番号が同じである受信確認パケットを３回連続して受信すると、ネットワークが輻輳状態にあると判断し、ｃｗｎｄの値を（１−ＨＳ_ｂ）倍にする。ここで、ＨＳ_ａ、ＨＳ_ｂはそれぞれウインドウ増加パラメータ、ウインドウ減少パラメータと呼ばれ、以下のように定義される。
【０００６】
【数１】
2006217235.tif 000003
ＨＳ−ＴＣＰは従来のＴＣＰに比べて、ｃｗｎｄがＷｌｏｗ（＝３８）以上の時、ウインドウ増加パラメータの値を大きく、つまりｃｗｎｄの増加率を高くし、且つウインドウ減少パラメータの値を小さく、つまりｃｗｎｄの減少率を低くしている。これにより往復遅延時間が長い場合でも、ギガビットレベルのスループットが実現可能となる。
【０００７】
しかしＨＳ−ＴＣＰは往復伝播遅延時間が長いネットワークにおけるパフォーマンス向上を念頭にデザインされている為、往復伝播遅延時間が短いネットワークにおいてＨＳ−ＴＣＰが従来のＴＣＰとネットワーク帯域を共有した場合、ＨＳ−ＴＣＰが利用可能な帯域のほとんどを使用するという問題がある。以下にこの問題を確認するシミュレーションを行った結果を示す。図３にシミュレーションモデルを示す。送信端末、受信端末はそれぞれ２つで、１つ目の送信端末１は従来のＴＣＰ、２つ目の送信端末２はＨＳ−ＴＣＰを使用するとした。またリンク帯域は１Ｇｂｐｓであり、送信・受信端末間の伝播遅延時間を５ミリ秒、パケットサイズを１５００バイトとした。送信端末は常に送信するパケットを有しており、時刻０秒に通信を開始するとした。図４に時間ごとの輻輳ウインドウサイズの変化を示す。横軸が時間であり、縦軸が輻輳ウインドウのサイズ(Congestion window size)である。実線が従来のＴＣＰを用いる送信端末１の輻輳ウインドウサイズを示しており、点線がＨＳ−ＴＣＰを用いる送信端末２の輻輳ウインドウサイズを示している。図４により、ＨＳ−ＴＣＰのウインドウサイズは従来のＴＣＰのそれに比べてはるかに大きくなっていることが確認できる。つまり往復伝播遅延時間が短いネットワークにおいてＨＳ−ＴＣＰが従来のＴＣＰとネットワーク帯域を共有した場合、理想的にはそれぞれが帯域を平等に使用すべきであるが、実際にはＨＳ−ＴＣＰが利用可能な帯域のほとんどを使用するという問題が発生する。
【０００８】
【非特許文献１】村山他、“トランスポートプロトコル”、岩波書店、２００１年４月６日、Ｐ１７４〜Ｐ１７６
【非特許文献２】S. Floyd、“HighSpeed TCP for Large Congestion Windows”、RFC3649、December 2003
【発明の開示】
【発明が解決しようとする課題】
【０００９】
本発明は、往復伝播遅延時間が短いネットワークにおいてＨＳ−ＴＣＰが従来のＴＣＰとネットワーク帯域を共有した場合、それぞれが帯域を平等に使用することを目的としている。
【課題を解決するための手段】
【００１０】
本発明は、ネットワークが輻輳状態にあると判断した時にウインドウサイズを減少し、そうでないと判断した時にウインドウサイズを増加する送信端末の輻輳制御方法において、前記送信端末が、現在のウインドウサイズの値と、測定された最小遅延時間とあらかじめ設定された時間から一意に決まる値を比較し、現在のウインドウサイズが前記一意に決まる値より大きければ、ＨｉｇｈＳｐｅｅｄ  ＴＣＰのアルゴリズムに従って現在のウインドウサイズの値を更新し、現在のウインドウサイズが前記一意に決まる値以下ならば、ＴＣＰのアルゴリズムに従って現在のウインドウサイズの値を更新することを特徴とする。また、前記測定された最小遅延時間とあらかじめ設定された時間から一意に決まる値は、あらかじめ設定された時間の２倍を測定された最小遅延時間で割った値であることを特徴とする。
【００１１】
また、本発明は、ネットワークが輻輳状態にあると判断した時にウインドウサイズを減少し、そうでないと判断した時にウインドウサイズを増加する送信端末において、現在のウインドウサイズの値と、測定された最小遅延時間とあらかじめ設定された時間から一意に決まる値を比較し、その結果を通知するモード決定部と、前記モード決定部の通知に基づき、現在のウインドウサイズが前記一意に決まる値より大きければ、ＨｉｇｈＳｐｅｅｄ  ＴＣＰのアルゴリズムに従って現在のウインドウサイズの値を更新し、現在のウインドウサイズが前記一意に決まる値以下ならば、ＴＣＰのアルゴリズムに従って現在のウインドウサイズの値を更新するウインドウサイズ決定部と、を備えることを特徴とする。
【００１２】
本発明のポイントは、測定された最小遅延時間とあらかじめ設定された時間によって一意に定まる値によって、使用する輻輳制御アルゴリズムを変更する点である。従来のＨｉｇｈＳｐｅｅｄ  ＴＣＰ方式では、現在のウインドウサイズがＷｌｏｗ（＝３８）以上ならば、ＨｉｇｈＳｐｅｅｄ  ＴＣＰの輻輳制御アルゴリズムに従ってウインドウサイズを更新し、現在のウインドウサイズの値が、Ｗｌｏｗ（＝３８）以下ならば、従来のＴＣＰの輻輳制御アルゴリズムに従ってウインドウサイズを更新する。一方、本発明では、３８ではなく、測定された最小遅延時間とあらかじめ設定された時間によって一意に定まる値によって、使用する輻輳制御アルゴリズムを変更する。
【発明の効果】
【００１３】
本発明を用いれば、往復伝播遅延時間が短いネットワークにおいてＨｉｇｈＳｐｅｅｄ  ＴＣＰは従来のＴＣＰと平等に帯域を使用することができる。
【発明を実施するための最良の形態】
【００１４】
以下、本発明の実施例を図を参照して説明する。
実施例における送信端末５００の構成図を図５に示す。図５（Ａ）に示すように、送信端末５００はシーケンス番号読取部５０１とウインドウサイズ決定部５０２と時刻読取部５０３と最小遅延時間決定部５０４とモード決定部５０５とを備えている。ウインドウサイズ決定部５０２は、図５（Ｂ）に示すように、サイズ増減判断部５１０とサイズ増加部５１１とサイズ減少部５１２とを備えている。
【００１５】
送信端末５００は受信確認パケットを受信すると、シーケンス番号読取部５０１でパケットに付与されている次に受信を期待するパケットのシーケンス番号を読み取り、その結果をウインドウサイズ決定部５０２に通知する。同時に時刻読取部５０３では、パケットに付与されている時刻情報を読み取り、その値を最小遅延時間決定部５０４に通知する。最小遅延時間決定部５０４では、図６のアルゴリズム（フローチャート）に従い最小遅延時間を決定する。すなわち、最小遅延時間決定部５０４では、現在の時刻ｎｏｗと時刻読取部５０３から通知された時刻情報ｔｔの差ｄｉｆｆを求め（ステップ６０１）、差ｄｉｆｆがメモリに記録している最小遅延時間ｍｉｎＲＴＴよりも小さければ（ステップ６０２）、現在の時刻ｎｏｗと通知された時刻情報ｔｔの差ｄｉｆｆを最小遅延時間ｍｉｎＲＴＴとしてメモリに記録する（ステップ６０３）。現在の時刻ｎｏｗと通知された時刻情報ｔｔの差ｄｉｆｆは遅延時間であるから、図６のアルゴリズムによって記録されるｍｉｎＲＴＴが最小遅延時間であることは明らかである。そして、最小遅延時間決定部５０４はモード決定部５０５から要求があれば最小遅延時間ｍｉｎＲＴＴの値をメモリから読み出し、その値をモード決定部５０５に通知する。モード決定部５０５では、ウインドウサイズ決定部５０２から要求があれば、図７のアルゴリズム（フローチャート）に従い、モードを決定する。すなわち、モード決定部５０５は、最小遅延時間決定部５０４から通知された最小遅延時間ｍｉｎＲＴＴ、メモリに記録してあるあらかじめ設定された時間Ｔから、
【数２】
2006217235.tif 000004
を計算する（ステップ７０１）。そして、ウインドウサイズ決定部５０２から通知された現在のウインドウサイズｃｗｎｄがｆａｉｒ_ｗｉｎｄｏｗより大きいかどうかを判断し（ステップ７０２）、その結果をウインドウサイズ決定部５０２に通知する。すなわち、現在のウインドウサイズｃｗｎｄがｆａｉｒ_ｗｉｎｄｏｗ以下ならば１を（ステップ７０３）、ｆａｉｒ_ｗｉｎｄｏｗ以上ならば２を（ステップ７０４）、ウインドウサイズ決定部５０２に通知する。ここで、１、２は現在のウインドウサイズがｆａｉｒ_ｗｉｎｄｏｗ以下か以上かを示すｆｌａｇである。なお、このｆｌａｇは、後述の図８−２のステップ８２２と図８−３のステップ８３０で１であるかどうか判断され、１であればＴＣＰのアルゴリズムに従って現在のウインドウサイズの値を更新し（ステップ８２３、８３１）、２であればＨｉｇｈＳｐｅｅｄ  ＴＣＰのアルゴリズムに従って現在のウインドウサイズの値を更新する（ステップ８２４、８３２）ために使用される。
【００１６】
ウインドウサイズ決定部５０２では、サイズ増減判断部５１０で、図８−１のフローチャートに従い、ウインドウサイズを増加するか減少するかを判断し、増加すると判断したならば、サイズ増加部５１１で図８−２のフローチャートに従ってウインドウサイズを増加させる。減少させると判断したならば、サイズ減少部５１２で図８−３のフローチャートに従ってウインドウサイズを減少させる。ここで図８のアルゴリズムについて詳細に説明する。
【００１７】
図８−１に示すようにサイズ増減判断部５１０は、シーケンス番号読取部５０１から番号を通知されると（ステップ８１０）、その値Ｘとメモリに記録してある値Ｃを比較する（ステップ８１１）。もしＸ（通知されたシーケンス番号）とＣ（前回通知されたシーケンス番号）が等しくなければ、シーケンス番号が同じ受信確認パケットを連続して受信していないということなので、ｎｕｍ（同じ番号のシーケンス番号を受信した回数）を１に更新し、ｎｕｍ（同じ番号のシーケンス番号を受信した回数）とＸ（通知されたシーケンス番号）の値をメモリに保存し（ステップ８１２）、サイズ増加部５１１（図８−２）に向かう。Ｘ（通知されたシーケンス番号）とＣ（前回通知されたシーケンス番号）が等しければ、シーケンス番号が同じ受信確認パケットを連続して受信しているということなので、メモリに保存してあるｎｕｍ（同じ番号のシーケンス番号を受信した回数）の値に１を加算する（ステップ８１３）。そしてｎｕｍが３であるかどうかを判断し（ステップ８１４）、つまりシーケンス番号が同じである受信確認パケットを３回連続して受信したならば、ｎｕｍを１に更新し、ｎｕｍとＸの値をメモリに保存し（ステップ８１５）、サイズ減少部５１２（図８−３）に向かう。ｎｕｍが３でなければ、ｎｕｍの値をメモリの保存し、サイズ増加部５１１（図８−２）に向かう。
【００１８】
図８−２に示すようにサイズ増加部５１１では、メモリに記録してあるｃｎｔ（受信確認パケットを受信した回数）に１を加算する（ステップ８２０）。そしてｃｎｔがｃｗｎｄ（輻輳ウインドウ）と等しくなったかどうかを調べる（ステップ８２１）。等しくなければ、ｃｎｔの値をメモリに保存し処理を終了する。等しければ、モード決定部５０５に要求を出す。そしてモード決定部５０５から値ｆｌａｇが通知されたならば、その値により以下のような処理を行う（ステップ８２２）。もしｆｌａｇが１ならば、ｃｗｎｄを１だけ増加させる。すなわち、従来のＴＣＰのアルゴリズムに従ってウインドウサイズを増加させる（ステップ８２３）。もしｆｌａｇが２ならば、ｃｗｎｄをＨＳ−ＴＣＰで定義されているウインドウ増加パラメータＨＳ_ａ（数１参照）だけ増加させる。すなわち、ＨＳ−ＴＣＰのアルゴリズムに従ってウインドウサイズを増加させる（ステップ８２４）。その後、ｃｎｔに０を代入してメモリに保存し（ステップ８２５）、処理を終了する。
【００１９】
図８−３に示すようにサイズ減少部５１２は、モード決定部５０５に要求を出す。そしてモード決定部５０５から値ｆｌａｇが通知されたならば、その値により以下のような処理を行う（ステップ８３０）。もしｆｌａｇが１ならば、ｃｗｎｄを半分の値に減少させる。すなわち、従来のＴＣＰのアルゴリズムに従ってウインドウサイズを減少させる（ステップ８３１）。もしｆｌａｇが２ならば、ｃｗｎｄに１からＨＳ−ＴＣＰで定義されているウインドウ減少パラメータＨＳ_ｂ（数１参照）を引いた値を乗算する。（１−ＨＳ_ｂ）が１より小さいので、ウインドウサイズは減少される。すなわち、ＨＳ−ＴＣＰのアルゴリズムに従ってウインドウサイズを減少させる（ステップ８３２）。
【００２０】
以下、図９に示す例を用いて、本実施例の動作を説明する。送信端末５００は図９に示すように受信確認パケット１から３を、それぞれ時刻１０．０２、１０．０３、１０．０４秒に受信するとする。パケット１から３は、次に受信を期待するパケットのシーケンス番号として、それぞれ１００、１００、１００を、時刻情報として１０．００、１０．０２、１０．０３を有しているとする。受信確認パケット１を受信する直前、図６のｍｉｎＲＴＴ（最小遅延時間）は０．０３、図７のＴ（あらかじめ設定してある時間）は５、図８−１のＣ（前回通知された番号）は９９、ｎｕｍ（同じ番号のシーケンス番号を受信した回数）は１であり、図８−２のｃｎｔ（受信確認パケットを受信した回数）は８９０、ｃｗｎｄ（輻輳ウインドウ）は９００、ＨＳ_ａ（ｃｗｎｄ＝９００）は７であり、図８−３のＨＳ_ｂ（ｃｗｎｄ＝９００）は０．３４であるとする。
【００２１】
送信端末５００がパケット１を受信すると、時刻読取部５０３で時刻情報１０．００を読み取り、その値を最小遅延時間決定部５０４に通知する。最小遅延時間決定部５０４では、現在の時刻と通知された時刻の差ｄｉｆｆを求める。現在の時刻は１０．０２、通知された時刻は１０．００なので、ｄｉｆｆは０．０２である（ステップ６０１）。次にこの値をメモリに記録してあるｍｉｎＲＴＴ（最小遅延時間）と比較する（ステップ６０２）。ｍｉｎＲＴＴは０．０３なので、ｄｉｆｆはｍｉｎＲＴＴより小さい。よって、ｍｉｎＲＴＴとして、０．０２をメモリに記録する（ステップ６０３）。シーケンス番号読取部５０１では、次に受信を期待するパケットのシーケンス番号を読み取り、その結果をウインドウサイズ決定部５０２に通知する。パケット１が有する次に受信を期待するパケットのシーケンス番号は１００なので、１００がウインドウサイズ決定部５０２に通知される。ウインドウサイズ決定部５０２のサイズ増減判断部５１０では、通知されたシーケンス番号Ｘ（＝１００）と保持している前回通知された番号Ｃ（＝９９）が異なるので、ｎｕｍを１に更新し、ｎｕｍ（＝１）とＸ（＝１００）をメモリに保存し（ステップ８１２）、サイズ増加部５１１（図８−２）に向かう。サイズ増加部５１１では、メモリに記録してあるｃｎｔ（受信確認パケットを受信した回数）に１を加算する。つまりｃｎｔは８９０＋１＝８９１になる（ステップ８２１）。そしてｃｎｔがｃｗｎｄ（輻輳ウインドウ）と等しくなったかどうかを調べる（ステップ８２１）。ｃｎｔは８９１、ｃｗｎｄは９００なので、ｃｎｔとｃｗｎｄは等しくない。よって、ｃｎｔ（＝８９１）をメモリに保存し処理を終了する。
【００２２】
送信端末５００がパケット２を受信すると、時刻読取部５０３で時刻情報１０．０２を読み取り、その値を最小遅延時間決定部５０４に通知する。最小遅延時間決定部５０４では、現在の時刻ｎｏｗと通知された時刻ｔｔの差ｄｉｆｆを求める。現在の時刻は１０．０３、通知された時刻は１０．０２なので、ｄｉｆｆは０．０１である（ステップ６０１）。次にこの値をメモリに記録してあるｍｉｎＲＴＴと比較する（ステップ６０２）。ｍｉｎＲＴＴは０．０２なので、ｄｉｆｆはｍｉｎＲＴＴより小さい。よって、ｍｉｎＲＴＴとして、０．０１をメモリに記録する（ステップ６０３）。シーケンス番号読取部５０１では、次に受信を期待するパケットのシーケンス番号を読み取り、その結果をウインドウサイズ決定部５０２に通知する。パケット２が有する次に受信を期待するパケットのシーケンス番号は１００なので、１００がウインドウサイズ決定部５０２に通知される。ウインドウサイズ決定部５０２のサイズ増減判断部５１０では、通知されたシーケンス番号Ｘ（＝１００）と保持している前回通知された番号Ｃ（＝１００）が等しいので、メモリに保存してあるｎｕｎの値に１を加算する。つまり、ｎｕｍは２になる（ステップ８１３）。ｎｕｍは３ではないので、ｎｕｍ（＝２）をメモリに保存し、サイズ増加部５１１（図８−２）に向かう。サイズ増加部５１１では、メモリに記録してあるｃｎｔ（受信確認パケットを受信した回数）に１を加算する。つまりｃｎｔは８９１＋１＝８９２になる（ステップ８２０）。そしてｃｎｔがｃｗｎｄ（輻輳ウインドウ）と等しくなったかどうかを調べる（ステップ８２１）。ｃｎｔは８９２、ｃｗｎｄは９００なので、ｃｎｔとｃｗｎｄは等しくない。よって、ｃｎｔ（＝８９２）をメモリに保存し処理を終了する。
【００２３】
送信端末５００がパケット３を受信すると、時刻読取部５０３で時刻情報１０．０３を読み取り、その値を最小遅延時間決定部５０４に通知する。最小遅延時間決定部５０４では、現在の時刻と通知された時刻の差ｄｉｆｆを求める。現在の時刻は１０．０４、通知された時刻は１０．０３なので、ｄｉｆｆは０．０１である（ステップ６０１）。次にこの値をメモリに記録してあるｍｉｎＲＴＴと比較する（ステップ６０２）。ｍｉｎＲＴＴは０．０１なので、ｄｉｆｆはｍｉｎＲＴＴより小さくない。よって、処理は終了する。シーケンス番号読取部５０１では、次に受信を期待するパケットのシーケンス番号を読み取り、その結果をウインドウサイズ決定部５０２に通知する。パケット３が有する次に受信を期待するパケットのシーケンス番号は１００なので、１００がウインドウサイズ決定部５０２に通知される。ウインドウサイズ決定部５０２のサイズ増減判断部５１０では、通知されたシーケンス番号Ｘ（＝１００）と保持している前回通知された番号Ｃ（＝１００）が等しいので、メモリに保存してあるｎｕｍの値に１を加算する（ステップ８１３）。つまり、ｎｕｍは３になる。ｎｕｍが３になったので、ｎｕｍを１に更新し、ｎｕｍ（＝１）とＸ（＝１００）をメモリに保存し（ステップ８１５）、サイズ減少部５１２（図８−３）に向かう。サイズ減少部５１２ではモード決定部５０５にｃｗｎｄ（輻輳ウインドウ）の値を通知し、ｆｌａｇの値を送るように要求を出す。モード決定部５０５では最小遅延時間決定部５０４にｍｉｎＲＴＴの値を送るように要求を出す。最小遅延時間決定部５０４ではメモリに記録してあるｍｉｎＲＴＴの値が０．０１なので、その値をモード決定部５０５に通知する。その情報を受け取ったモード決定部５０５はｆａｉｒ_ｗｉｎｄｏｗの値を計算する（ステップ７０１）。Ｔ（あらかじめ設定している時間）は５、ｍｉｎＲＴＴ（最小遅延時間）は０．０１なので、ｆａｉｒ_ｗｉｎｄｏｗの値は１０００となる。ｃｗｎｄの値は９００なので、ｆｌａｇの値は１になり（ステップ７０３）、その値をウインドウサイズ決定部５０２に通知する。サイズ減少部５１２ではモード決定部５０５からｆｌａｇの値が通知されたならば、その値を調べる。ｆｌａｇは１なので、ｃｗｎｄを半分の値に減少させる（ステップ８３１）。つまりｃｗｎｄの値は４５０になる。
【００２４】
次に本実施例の効果を確認するシミュレーションを行った結果を示す。シミュレーションの条件は図４に示す従来のＨＳ−ＴＣＰを用いた場合で述べたものとまったく同じである。本実施例で用いられるパラメータとしては、Ｔ＝５を用いた。図１０に時間ごとの輻輳ウインドウサイズの変化を示す。図１０では、ＨＳ−ＴＣＰ（点線）とＴＣＰ（実線）のウインドウサイズの変化がまったく同じである（図１０の点線と実線はほとんど重なっている）。つまりＨＳ−ＴＣＰと従来のＴＣＰは帯域を平等に使用していることが確認できる。
【００２５】
なお、あらかじめ設定された時間Ｔは実際の運用、実験、シミュレーション等により適切な値を設定することができる。
【００２６】
以上説明した実施例の送信端末の各部は記憶装置に記憶したプログラムをＣＰＵが実行することによって実現できる。また、その一部または全部をハードウェアで構成してもよい。
【００２７】
以上、本発明者によってなされた発明を、前記実施例に基づき具体的に説明したが、本発明は、前記実施例に限定されるものではなく、その要旨を逸脱しない範囲において種々変更可能であることは勿論である。
【図面の簡単な説明】
【００２８】
【図１】パケットに付与されるシーケンス番号と時刻情報
【図２】パケットが再送される条件
【図３】シミュレーションモデル
【図４】従来のＨＳ−ＴＣＰを用いた場合のシミュレーション結果
【図５】実施例の送信端末のシステム構成
【図６】最小値時間決定部５０４におけるアルゴリズム（フローチャート）
【図７】モード決定部５０５におけるアルゴリズム（フローチャート）
【図８−１】サイズ増減判断部５１０におけるアルゴリズム（フローチャート）
【図８−２】サイズ増加部５１１におけるアルゴリズム（フローチャート）
【図８−３】サイズ減少部５１２におけるアルゴリズム（フローチャート）
【図９】実施例におけるパケットの流れの例
【図１０】実施例を用いた場合のシミュレーション結果
【符号の説明】
【００２９】
５００…送信端末、５０１…シーケンス番号読取部、５０２…ウインドウサイズ決定部、５０３…時刻読取部、５０４…最小遅延時間決定部、５０５…モード決定部、５１０…サイズ増減判定部、５１１…サイズ増加部、５１２…サイズ減少部
【図１】
2006217235.tif 000005
【図２】
2006217235.tif 000006
【図３】
2006217235.tif 000007
【図４】
2006217235.tif 000008
【図５】
2006217235.tif 000009
【図６】
2006217235.tif 000010
【図７】
2006217235.tif 000011
【図８−１】
2006217235.tif 000012
【図８−２】
2006217235.tif 000013
【図８−３】
2006217235.tif 000014
【図９】
2006217235.tif 000015
【図１０】
2006217235.tif 000016