JPH11127163A - ウィンドウ制御方法 - Google Patents
ウィンドウ制御方法Info
- Publication number
- JPH11127163A JPH11127163A JP28982597A JP28982597A JPH11127163A JP H11127163 A JPH11127163 A JP H11127163A JP 28982597 A JP28982597 A JP 28982597A JP 28982597 A JP28982597 A JP 28982597A JP H11127163 A JPH11127163 A JP H11127163A
- Authority
- JP
- Japan
- Prior art keywords
- window size
- window
- size
- capacity
- slow start
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims description 45
- 238000004891 communication Methods 0.000 claims abstract description 42
- 230000005540 biological transmission Effects 0.000 claims description 31
- 238000012545 processing Methods 0.000 claims description 8
- 238000012790 confirmation Methods 0.000 claims 2
- 238000012546 transfer Methods 0.000 abstract description 7
- 230000007704 transition Effects 0.000 description 20
- 238000010586 diagram Methods 0.000 description 17
- 230000000903 blocking effect Effects 0.000 description 6
- 238000004364 calculation method Methods 0.000 description 3
- 238000005538 encapsulation Methods 0.000 description 2
- 238000007796 conventional method Methods 0.000 description 1
- 230000003111 delayed effect Effects 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 239000000835 fiber Substances 0.000 description 1
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
(57)【要約】
【課題】 スループットを改善するとともに、通信メデ
ィアがシェアドメディアであっても従来の処理を踏襲す
る。 【解決手段】 エンドシステム１のウィンドウ制御プロ
トコル４において、フロー制御としてウィンドウ制御を
行う場合、送信バッファ容量，受信バッファ容量の空き
容量，および使用可能な最大帯域×遅延（ＲＴＴ）のう
ち、いずれか最小のものを最大ウィンドウサイズとして
用いる。
ィアがシェアドメディアであっても従来の処理を踏襲す
る。 【解決手段】 エンドシステム１のウィンドウ制御プロ
トコル４において、フロー制御としてウィンドウ制御を
行う場合、送信バッファ容量，受信バッファ容量の空き
容量，および使用可能な最大帯域×遅延（ＲＴＴ）のう
ち、いずれか最小のものを最大ウィンドウサイズとして
用いる。
Description
【０００１】
【発明の属する技術分野】本発明は、ウィンドウ制御方
法に関し、特に通信資源を予約しうる通信メディアにお
いて、通信メディアで帯域、遅延などの確保した通信資
源に関わるパラメータに基づいて、ＴＣＰなどのフロー
制御にウィンドウ制御を行うプロトコルのウィンドウ制
御方法に関するものである。
法に関し、特に通信資源を予約しうる通信メディアにお
いて、通信メディアで帯域、遅延などの確保した通信資
源に関わるパラメータに基づいて、ＴＣＰなどのフロー
制御にウィンドウ制御を行うプロトコルのウィンドウ制
御方法に関するものである。
【０００２】
【従来の技術】従来のＴＣＰ（Transmission Control P
rotocol ）における送信開始あるいは輻輳検出後のウィ
ンドウサイズは、スロースタートおよび輻輳回避と呼ば
れるアルゴリズムにより制御されている。スロースター
トでは、ウィンドウサイズを単位送信容量である１セグ
メントから開始し、セグメントを送信してその確認応答
信号（ＡＣＫ）が返送されると１つのＡＣＫに対してウ
ィンドウサイズを１セグメント分増加する。
rotocol ）における送信開始あるいは輻輳検出後のウィ
ンドウサイズは、スロースタートおよび輻輳回避と呼ば
れるアルゴリズムにより制御されている。スロースター
トでは、ウィンドウサイズを単位送信容量である１セグ
メントから開始し、セグメントを送信してその確認応答
信号（ＡＣＫ）が返送されると１つのＡＣＫに対してウ
ィンドウサイズを１セグメント分増加する。
【０００３】これにより、ウィンドウサイズの増加は指
数関数的になる。なお、１セグメント長は、ネットワー
ク形式に固有のＭＴＵ（Maximum Transfer Unit ：最大
転送ユニット）のサイズに依存する。例えば、ＡＴＭで
はＭＴＵ＝９１８０バイトがデフォルト値となってお
り、このサイズが１セグメント長として用いられる。
数関数的になる。なお、１セグメント長は、ネットワー
ク形式に固有のＭＴＵ（Maximum Transfer Unit ：最大
転送ユニット）のサイズに依存する。例えば、ＡＴＭで
はＭＴＵ＝９１８０バイトがデフォルト値となってお
り、このサイズが１セグメント長として用いられる。
【０００４】また、輻輳回避では、ＡＣＫが返送された
とき１つのＡＣＫに対してウィンドウをセグメントの１
／Ｎずつ増加する。なお、Ｎはウインドウあたりのセグ
メント数を示す。ＴＣＰでは、輻輳が検出されたとき、
ウィンドウを単一のセグメントサイズにしてスロースタ
ートにより輻輳が発生する前のウィンドウサイズの１／
２のサイズまで指数関数的にウィンドウを増加する。
とき１つのＡＣＫに対してウィンドウをセグメントの１
／Ｎずつ増加する。なお、Ｎはウインドウあたりのセグ
メント数を示す。ＴＣＰでは、輻輳が検出されたとき、
ウィンドウを単一のセグメントサイズにしてスロースタ
ートにより輻輳が発生する前のウィンドウサイズの１／
２のサイズまで指数関数的にウィンドウを増加する。
【０００５】したがって、それ以降は、輻輳回避によ
り、ウィンドウをセグメントサイズごとに緩やかに増加
させるものとなっていた。また、予め帯域を保証する通
信メディアの場合、最大の送信ウィンドウサイズ（最大
ウィンドウサイズ）は、送信バッファ容量と受信バッフ
ァの空き容量のうち小さいものが採用されるものとなっ
ていた。
り、ウィンドウをセグメントサイズごとに緩やかに増加
させるものとなっていた。また、予め帯域を保証する通
信メディアの場合、最大の送信ウィンドウサイズ（最大
ウィンドウサイズ）は、送信バッファ容量と受信バッフ
ァの空き容量のうち小さいものが採用されるものとなっ
ていた。
【０００６】
【発明が解決しようとする課題】しかしながら、このよ
うな従来のウィンドウ制御方法では、予め帯域を保証す
る通信メディアの場合、最大の送信ウィンドウサイズを
送信バッファ容量と受信バッファの空き容量のうち小さ
いものを採用するため、確保した帯域と遅延の積がこれ
らより小さいとパケット紛失が発生し、その後、スロー
スタート、輻輳回避を繰り返して、スループットが低下
する問題点があった。また、ＴＣＰがスロースタートか
ら輻輳回避に切り替えるしきい値を、輻輳発生時、一律
に１／２に削減するため、保証された帯域を使いきれな
いという問題点があった。
うな従来のウィンドウ制御方法では、予め帯域を保証す
る通信メディアの場合、最大の送信ウィンドウサイズを
送信バッファ容量と受信バッファの空き容量のうち小さ
いものを採用するため、確保した帯域と遅延の積がこれ
らより小さいとパケット紛失が発生し、その後、スロー
スタート、輻輳回避を繰り返して、スループットが低下
する問題点があった。また、ＴＣＰがスロースタートか
ら輻輳回避に切り替えるしきい値を、輻輳発生時、一律
に１／２に削減するため、保証された帯域を使いきれな
いという問題点があった。
【０００７】また、ＴＣＰのウィンドウ制御を、帯域を
保証する通信メディアに特化した場合、シェアドメディ
アでは使用できないという問題が生じる。なお、シェア
ドメディアとは、イーサネットやＦＤＤＩ（Fiber Dist
ributedData Interface）のように、複数のコネクショ
ン（ＴＣＰやＵＤＰ）が帯域を共有する伝送媒体のこと
であり、通信帯域は保証されない。本発明は、このよう
な課題を解決するためのものであり、スループットを改
善できるとともに、通信メディアがシェアドメディアで
あっても従来の処理を踏襲できるウィンドウ制御方法を
提供することを目的としている。
保証する通信メディアに特化した場合、シェアドメディ
アでは使用できないという問題が生じる。なお、シェア
ドメディアとは、イーサネットやＦＤＤＩ（Fiber Dist
ributedData Interface）のように、複数のコネクショ
ン（ＴＣＰやＵＤＰ）が帯域を共有する伝送媒体のこと
であり、通信帯域は保証されない。本発明は、このよう
な課題を解決するためのものであり、スループットを改
善できるとともに、通信メディアがシェアドメディアで
あっても従来の処理を踏襲できるウィンドウ制御方法を
提供することを目的としている。
【０００８】
【課題を解決するための手段】このような目的を達成す
るために、本発明による請求項１の発明は、通信資源を
予約しうる通信メディアに対するフロー制御として、ス
ロースタート処理および輻輳回避処理とからなるウィン
ドウ制御を実行する通信プロトコルにおいて、送信バッ
ファ容量，受信バッファの空き容量，および使用可能な
最大帯域とラウンドトリップタイムとの積のうち、いず
れか最小の値からなる第１のウィンドウサイズを最大ウ
ィンドウサイズとして用いるようにしたものである。
るために、本発明による請求項１の発明は、通信資源を
予約しうる通信メディアに対するフロー制御として、ス
ロースタート処理および輻輳回避処理とからなるウィン
ドウ制御を実行する通信プロトコルにおいて、送信バッ
ファ容量，受信バッファの空き容量，および使用可能な
最大帯域とラウンドトリップタイムとの積のうち、いず
れか最小の値からなる第１のウィンドウサイズを最大ウ
ィンドウサイズとして用いるようにしたものである。
【０００９】また、請求項２の発明は、請求項１のウィ
ンドウ制御方法において、通信メディアがＡＴＭでサー
ビスカテゴリがコンスタントビットレートの場合には、
スロースタートにより増加するウィンドウサイズが、送
信バッファ容量，受信バッファの空き容量，およびピー
クセルレートに基づき確保した使用可能な最大帯域とラ
ウンドトリップタイムとの積のうち、いずれか最小の値
からなる第２のウィンドウサイズとなった時点で、スロ
ースタート処理を終了し、スロースタート処理の終了後
は、パケット紛失が発生するまで、第２のウィンドウサ
イズを最大ウィンドウサイズとして用いるようにしたも
のである。
ンドウ制御方法において、通信メディアがＡＴＭでサー
ビスカテゴリがコンスタントビットレートの場合には、
スロースタートにより増加するウィンドウサイズが、送
信バッファ容量，受信バッファの空き容量，およびピー
クセルレートに基づき確保した使用可能な最大帯域とラ
ウンドトリップタイムとの積のうち、いずれか最小の値
からなる第２のウィンドウサイズとなった時点で、スロ
ースタート処理を終了し、スロースタート処理の終了後
は、パケット紛失が発生するまで、第２のウィンドウサ
イズを最大ウィンドウサイズとして用いるようにしたも
のである。
【００１０】また、請求項３の発明は、請求項１のウィ
ンドウ制御方法において、通信メディアがＡＴＭでサー
ビスカテゴリがアベーラブルビットレートの場合には、
スロースタートにより増加するウィンドウサイズが、送
信バッファ容量，受信バッファの空き容量，およびミニ
マムセルレートに基づき確保した使用可能な最大帯域と
ラウンドトリップタイムとの積のうち、いずれか最小の
値からなる第３のウィンドウサイズとなった時点で、ス
ロースタート処理を終了するようにしたものである。
ンドウ制御方法において、通信メディアがＡＴＭでサー
ビスカテゴリがアベーラブルビットレートの場合には、
スロースタートにより増加するウィンドウサイズが、送
信バッファ容量，受信バッファの空き容量，およびミニ
マムセルレートに基づき確保した使用可能な最大帯域と
ラウンドトリップタイムとの積のうち、いずれか最小の
値からなる第３のウィンドウサイズとなった時点で、ス
ロースタート処理を終了するようにしたものである。
【００１１】また、請求項４の発明は、請求項１のウィ
ンドウ制御方法において、通信メディアがＡＴＭで通信
資源を予約しうる通信メディアと相互接続して通信して
いる旨の通知に応じて、送信バッファ容量および受信バ
ッファの空き容量のうち、いずれか最小の値からなる第
４のウィンドウサイズを最大ウィンドウサイズとして用
いるようにしたものである。
ンドウ制御方法において、通信メディアがＡＴＭで通信
資源を予約しうる通信メディアと相互接続して通信して
いる旨の通知に応じて、送信バッファ容量および受信バ
ッファの空き容量のうち、いずれか最小の値からなる第
４のウィンドウサイズを最大ウィンドウサイズとして用
いるようにしたものである。
【００１２】
【発明の実施の形態】次に、本発明について図面を参照
して説明する。図１は、本発明の一実施の形態であるウ
ィンドウ制御方法が適用される通信システムを示すブロ
ック図である。６はＡＴＭ網を構成する中継ノードであ
り、資源予約プロトコル７、および資源予約プロトコル
７が予約した帯域の確保や通信品質の維持を行うパケッ
トクラシファイアおよびスケジューラ（Packet Classif
ier and Packet Scheduler）８から構成されている。
して説明する。図１は、本発明の一実施の形態であるウ
ィンドウ制御方法が適用される通信システムを示すブロ
ック図である。６はＡＴＭ網を構成する中継ノードであ
り、資源予約プロトコル７、および資源予約プロトコル
７が予約した帯域の確保や通信品質の維持を行うパケッ
トクラシファイアおよびスケジューラ（Packet Classif
ier and Packet Scheduler）８から構成されている。
【００１３】同図において、１は中継ノード６に接続さ
れたエンドシステムであり、上位のアプリケーション
２、資源予約プロトコル３、本発明が適用されるウィン
ドウ制御プロトコル４、および資源予約プロトコル３が
予約した帯域の確保や通信品質の維持を行うパケットク
ラシファイアおよびスケジューラ５から構成されてい
る。
れたエンドシステムであり、上位のアプリケーション
２、資源予約プロトコル３、本発明が適用されるウィン
ドウ制御プロトコル４、および資源予約プロトコル３が
予約した帯域の確保や通信品質の維持を行うパケットク
ラシファイアおよびスケジューラ５から構成されてい
る。
【００１４】以下、図１〜３を参照して、本発明の第１
の実施の形態について、従来のウィンドウ制御方法と比
較しながら説明する。ここでは、本発明のウィンドウ制
御方法として、送信バッファ容量，受信バッファの空き
容量，および使用可能な最大帯域×遅延のうち、いずれ
か小さいものを最大ウィンドウサイズとして用いるよう
にしたものである。
の実施の形態について、従来のウィンドウ制御方法と比
較しながら説明する。ここでは、本発明のウィンドウ制
御方法として、送信バッファ容量，受信バッファの空き
容量，および使用可能な最大帯域×遅延のうち、いずれ
か小さいものを最大ウィンドウサイズとして用いるよう
にしたものである。
【００１５】図２は、従来のウィンドウ制御方法による
ウィンドウサイズの推移を示す説明図であり、特に、最
大のウィンドウサイズを適用し、スロースタートと輻輳
回避アルゴリズムによるウィンドウ制御を行った場合の
ウィンドウサイズの推移を示している。同図において、
縦軸はウィンドウサイズ、横軸はデータ往復遅延時間を
示すラウンドトリップタイムＲＴＴ（Round Trip Time
）を示している。
ウィンドウサイズの推移を示す説明図であり、特に、最
大のウィンドウサイズを適用し、スロースタートと輻輳
回避アルゴリズムによるウィンドウ制御を行った場合の
ウィンドウサイズの推移を示している。同図において、
縦軸はウィンドウサイズ、横軸はデータ往復遅延時間を
示すラウンドトリップタイムＲＴＴ（Round Trip Time
）を示している。
【００１６】また、９、１０はパケット紛失の起きる時
刻Ｔ１，Ｔ２、１１は送信バッファ容量と受信バッファ
の空き容量のうちいずれか小さいものを示すサイズＡ、
すなわちＡ＝ｍｉｎ（送信バッファ容量，受信バッファ
の空き容量）、１２は使用可能な最大帯域と遅延（ＲＴ
Ｔ）の積で求められるサイズＢ、１３はサイズＢの１／
２すなわちＢ／２のサイズを示している。なお、以下の
説明では、サイズＢ＜サイズＡと仮定している。
刻Ｔ１，Ｔ２、１１は送信バッファ容量と受信バッファ
の空き容量のうちいずれか小さいものを示すサイズＡ、
すなわちＡ＝ｍｉｎ（送信バッファ容量，受信バッファ
の空き容量）、１２は使用可能な最大帯域と遅延（ＲＴ
Ｔ）の積で求められるサイズＢ、１３はサイズＢの１／
２すなわちＢ／２のサイズを示している。なお、以下の
説明では、サイズＢ＜サイズＡと仮定している。
【００１７】一方、図３は、本発明の第１の実施の形態
によるウィンドウサイズの推移を示す説明図であり、特
に、最大のウィンドウサイズを適用し、従来と同様に、
スロースタートと輻輳回避アルゴリズムによるウィンド
ウ制御を行った場合のウィンドウサイズの推移を示して
いる。同図において、１４は使用可能な最大帯域と遅延
（ＲＴＴ）の積Ｂを示しており、前述の図１の１２と対
応する。
によるウィンドウサイズの推移を示す説明図であり、特
に、最大のウィンドウサイズを適用し、従来と同様に、
スロースタートと輻輳回避アルゴリズムによるウィンド
ウ制御を行った場合のウィンドウサイズの推移を示して
いる。同図において、１４は使用可能な最大帯域と遅延
（ＲＴＴ）の積Ｂを示しており、前述の図１の１２と対
応する。
【００１８】まず、図１において、アプリケーション２
は、資源予約プロトコル３により通信資源を確保し、ウ
ィンドウ制御プロトコル４で情報転送を開始する。この
とき、ウィンドウ制御プロトコル４には、資源予約プロ
トコル３から使用可能な最大帯域が通知される。
は、資源予約プロトコル３により通信資源を確保し、ウ
ィンドウ制御プロトコル４で情報転送を開始する。この
とき、ウィンドウ制御プロトコル４には、資源予約プロ
トコル３から使用可能な最大帯域が通知される。
【００１９】ここで、図２の従来方法では、送信バッフ
ァ容量と受信バッファの空き容量のいずれか小さいも
の、すなわちサイズＡを最大ウィンドウサイズとして用
いてウィンドウ制御するものとなっている。したがっ
て、スロースタートにより時刻Ｔ０からウィンドウサイ
ズの増加が行われ、サイズＡまで継続しようとするた
め、実際に使用可能な最大帯域×遅延、すなわちサイズ
Ｂを超えた時点、すなわち時刻Ｔ１でパケット紛失が発
生してしまう。
ァ容量と受信バッファの空き容量のいずれか小さいも
の、すなわちサイズＡを最大ウィンドウサイズとして用
いてウィンドウ制御するものとなっている。したがっ
て、スロースタートにより時刻Ｔ０からウィンドウサイ
ズの増加が行われ、サイズＡまで継続しようとするた
め、実際に使用可能な最大帯域×遅延、すなわちサイズ
Ｂを超えた時点、すなわち時刻Ｔ１でパケット紛失が発
生してしまう。
【００２０】このため、時刻Ｔ１から再びスロースター
トが開始され、ウィンドウサイズはサイズＢ／２まで増
加し、その後は輻輳回避によりサイズＡまで増加しよう
とするが、前述と同様に、サイズＢを越えた時点、すな
わち時刻Ｔ２でパケット紛失を起こし、時刻Ｔ２から再
びスロースタートを繰り返す。これにより、以降、スロ
ースタートおよび輻輳回避を繰り返すことになり、スル
ープットが低下する。
トが開始され、ウィンドウサイズはサイズＢ／２まで増
加し、その後は輻輳回避によりサイズＡまで増加しよう
とするが、前述と同様に、サイズＢを越えた時点、すな
わち時刻Ｔ２でパケット紛失を起こし、時刻Ｔ２から再
びスロースタートを繰り返す。これにより、以降、スロ
ースタートおよび輻輳回避を繰り返すことになり、スル
ープットが低下する。
【００２１】一方、図３の本発明では、送信バッファ容
量，受信バッファの空き容量，および使用可能な最大帯
域×遅延のうち、いずれか小さいもの、すなわちサイズ
ＡとサイズＢのいずれか小さいもの（第１のウィンドウ
サイズ）を最大ウィンドウサイズとして用いてウィンド
ウ制御するものとなっている。ここで、サイズＢ＜サイ
ズＡと仮定していることから、最大ウィンドウサイズと
してサイズＢが選択される。
量，受信バッファの空き容量，および使用可能な最大帯
域×遅延のうち、いずれか小さいもの、すなわちサイズ
ＡとサイズＢのいずれか小さいもの（第１のウィンドウ
サイズ）を最大ウィンドウサイズとして用いてウィンド
ウ制御するものとなっている。ここで、サイズＢ＜サイ
ズＡと仮定していることから、最大ウィンドウサイズと
してサイズＢが選択される。
【００２２】したがって、時刻Ｔ０から開始されたスロ
ースタートによるウィンドウサイズの増加は、時刻Ｔ１
においてサイズＢで停止される。これにより、パケット
紛失は発生せず、従来のように、スロースタートや輻輳
回避動作が繰り返されなくなり、平均のスループット
（データ転送量／時間）は従来（図２参照）の場合より
高くなる。
ースタートによるウィンドウサイズの増加は、時刻Ｔ１
においてサイズＢで停止される。これにより、パケット
紛失は発生せず、従来のように、スロースタートや輻輳
回避動作が繰り返されなくなり、平均のスループット
（データ転送量／時間）は従来（図２参照）の場合より
高くなる。
【００２３】次に、図１，４，５，８，９を参照して、
本発明の第２の実施の形態として、特に、ＡＴＭのサー
ビスカテゴリーＣＢＲ（Constant Bit Rate ：コンスタ
ントビットレート）上のフロー制御に対してウィンドウ
制御を行うプロトコルに適用する場合について説明す
る。ここでは、本発明のウィンドウ制御方法として、送
信バッファ容量，受信バッファの空き容量，およびＰＣ
Ｒ（Peak Cell Rate：ピークセルレート）により確保し
た帯域と遅延（ＲＴＴ）との積のうち、いずれか小さい
ものをスロースタートのしきい値として用いるようにし
たものである。
本発明の第２の実施の形態として、特に、ＡＴＭのサー
ビスカテゴリーＣＢＲ（Constant Bit Rate ：コンスタ
ントビットレート）上のフロー制御に対してウィンドウ
制御を行うプロトコルに適用する場合について説明す
る。ここでは、本発明のウィンドウ制御方法として、送
信バッファ容量，受信バッファの空き容量，およびＰＣ
Ｒ（Peak Cell Rate：ピークセルレート）により確保し
た帯域と遅延（ＲＴＴ）との積のうち、いずれか小さい
ものをスロースタートのしきい値として用いるようにし
たものである。
【００２４】図８は、パケットスイッチまたはＡＴＭス
イッチにおけるヘッドオブラインブロッキングを示す図
である。同図において、４０は入力のポート＃１、４１
は入力のポート＃２、４２はスイッチ部、４３は出力の
ポート＃３、４４は出力のポート＃４を示している。
イッチにおけるヘッドオブラインブロッキングを示す図
である。同図において、４０は入力のポート＃１、４１
は入力のポート＃２、４２はスイッチ部、４３は出力の
ポート＃３、４４は出力のポート＃４を示している。
【００２５】この場合、ポート＃２からポート＃４に多
量のデータが転送されているため、ポート＃２からポー
ト＃４へのデータ転送が滞る。これにより、ポート＃３
が空いているにも関わらず、ポート＃１において、ポー
ト＃３に向かう後続データを転送できなくなる。このよ
うに、伝送路上の帯域を確保しても、スイッチ内の輻輳
に起因して、データの廃棄や遅延が発生する可能性があ
ることが知られている。
量のデータが転送されているため、ポート＃２からポー
ト＃４へのデータ転送が滞る。これにより、ポート＃３
が空いているにも関わらず、ポート＃１において、ポー
ト＃３に向かう後続データを転送できなくなる。このよ
うに、伝送路上の帯域を確保しても、スイッチ内の輻輳
に起因して、データの廃棄や遅延が発生する可能性があ
ることが知られている。
【００２６】図４は、従来のウィンドウ制御方法を用い
た場合のウィンドウサイズの推移を示す説明図であり、
特に、ＡＴＭのサービスカテゴリーＣＢＲ上のフロー制
御に対してウィンドウ制御を行うプロトコルとして、本
発明による最大ウィンドウサイズ（第１の実施の形態）
を適用し、従来と同様のスロースタートおよび輻輳回避
アルゴリズムによるウィンドウ制御を行った場合のウィ
ンドウサイズの推移を示している。
た場合のウィンドウサイズの推移を示す説明図であり、
特に、ＡＴＭのサービスカテゴリーＣＢＲ上のフロー制
御に対してウィンドウ制御を行うプロトコルとして、本
発明による最大ウィンドウサイズ（第１の実施の形態）
を適用し、従来と同様のスロースタートおよび輻輳回避
アルゴリズムによるウィンドウ制御を行った場合のウィ
ンドウサイズの推移を示している。
【００２７】同図において、１５は図８で説明したヘッ
ドオブラインブロッキングなどでデータ紛失が発生した
時刻Ｔ３、１６は（ＰＣＲ×４８−オーバーヘッド）×
ＲＴＴにより算出されるウィンドウサイズＢ、１７はウ
ィンドウサイズＢ／２を示している。なお、サイズＢの
算出式において、ＰＣＲの単位はcells／secであり、４
８は１セルのペイロードサイズ（bytes ）を示してい
る。したがって、ＰＣＲ×４８の単位は、bytes ／sec
となる。
ドオブラインブロッキングなどでデータ紛失が発生した
時刻Ｔ３、１６は（ＰＣＲ×４８−オーバーヘッド）×
ＲＴＴにより算出されるウィンドウサイズＢ、１７はウ
ィンドウサイズＢ／２を示している。なお、サイズＢの
算出式において、ＰＣＲの単位はcells／secであり、４
８は１セルのペイロードサイズ（bytes ）を示してい
る。したがって、ＰＣＲ×４８の単位は、bytes ／sec
となる。
【００２８】また、オーバーヘッドとは、ＡＡＬ（ATM
Adaption Layer）のトレーラ部（バディング、バケット
長、ＣＲＣ−３２など）、ＬＬＣ（Logical Link Contr
ol）／ＳＮＡＰ（SubNetwork Attachment Point ）カプ
セル化によるＬＬＣヘッダおよびＳＮＡＰヘッダ、ＩＰ
ヘッダ、およびＴＣＰヘッダなどの部分の帯域を示して
おり、これらの制御情報に用いられる部分をＰＣＲ×４
８から減算することにより、使用可能な最大帯域を正確
に求めることができる。
Adaption Layer）のトレーラ部（バディング、バケット
長、ＣＲＣ−３２など）、ＬＬＣ（Logical Link Contr
ol）／ＳＮＡＰ（SubNetwork Attachment Point ）カプ
セル化によるＬＬＣヘッダおよびＳＮＡＰヘッダ、ＩＰ
ヘッダ、およびＴＣＰヘッダなどの部分の帯域を示して
おり、これらの制御情報に用いられる部分をＰＣＲ×４
８から減算することにより、使用可能な最大帯域を正確
に求めることができる。
【００２９】なお、ＡＡＬのヘッダ部／トレーラ部につ
いては、ＡＡＬの種類（１〜５）によって内容が異な
る。ＩＥＴＦ(Internet Engineering Task Force）の規
定ＲＦＣ−１５７７によれば、ＩＰ ｏｖｅｒ ＡＴＭ
では、ＡＡＬ５を使用するが、他のスペックではＡＡＬ
３／４を使用する場合もある。また、ＬＬＣヘッダおよ
びＳＡＮＰヘッダについては、ＩＥＴＦの規定ＲＦＣ−
１４８３によるが、ＡＴＭフォーラムのＬＡＮエミュレ
ーションでは、異なるカプセル化方法を用いる。
いては、ＡＡＬの種類（１〜５）によって内容が異な
る。ＩＥＴＦ(Internet Engineering Task Force）の規
定ＲＦＣ−１５７７によれば、ＩＰ ｏｖｅｒ ＡＴＭ
では、ＡＡＬ５を使用するが、他のスペックではＡＡＬ
３／４を使用する場合もある。また、ＬＬＣヘッダおよ
びＳＡＮＰヘッダについては、ＩＥＴＦの規定ＲＦＣ−
１４８３によるが、ＡＴＭフォーラムのＬＡＮエミュレ
ーションでは、異なるカプセル化方法を用いる。
【００３０】一方、図５は、本発明の第２の実施の形態
によるウィンドウサイズの推移を示す説明図であり、特
に、ＡＴＭのサービスカテゴリーＣＢＲ上のフロー制御
に対してウィンドウ制御を行うプロトコルとして、本発
明による最大ウィンドウサイズ（第１の実施の形態）を
適用し、本発明によるスロースタートアルゴリズムによ
るウィンドウ制御を行った場合のウィンドウサイズの推
移を示している。
によるウィンドウサイズの推移を示す説明図であり、特
に、ＡＴＭのサービスカテゴリーＣＢＲ上のフロー制御
に対してウィンドウ制御を行うプロトコルとして、本発
明による最大ウィンドウサイズ（第１の実施の形態）を
適用し、本発明によるスロースタートアルゴリズムによ
るウィンドウ制御を行った場合のウィンドウサイズの推
移を示している。
【００３１】同図において、２０は図８で説明したヘッ
ドオブラインブロッキングなどでデータ紛失が発生した
時刻Ｔ３、２１は（ＰＣＲ×４８−オーバーヘッド）×
ＲＴＴにより算出されるウィンドウサイズＢを示してい
る。
ドオブラインブロッキングなどでデータ紛失が発生した
時刻Ｔ３、２１は（ＰＣＲ×４８−オーバーヘッド）×
ＲＴＴにより算出されるウィンドウサイズＢを示してい
る。
【００３２】図９は、本発明の第２の実施の形態による
スロースタート処理動作を示すフローチャートである。
同図では、特に、ＡＴＭのサービスカテゴリーＣＢＲ上
のフロー制御にウィンドウ制御を行うプロトコルに本発
明による最大のウィンドウサイズを適用し、本発明によ
るスロースタートのアルゴリズムによるウィンドウ制御
を行う場合を示している。
スロースタート処理動作を示すフローチャートである。
同図では、特に、ＡＴＭのサービスカテゴリーＣＢＲ上
のフロー制御にウィンドウ制御を行うプロトコルに本発
明による最大のウィンドウサイズを適用し、本発明によ
るスロースタートのアルゴリズムによるウィンドウ制御
を行う場合を示している。
【００３３】以下、本発明の第２の実施の形態によるス
ロースタートのアルゴリズムについて説明する。まず、
図１において、アプリケーション２は、資源予約プロト
コル３により通信資源を確保し、ウィンドウ制御プロト
コル４で情報転送開始する。このとき、ウィンドウ制御
プロトコル４に対して、資源予約プロトコル３からＰＣ
Ｒ×４８が通知される。
ロースタートのアルゴリズムについて説明する。まず、
図１において、アプリケーション２は、資源予約プロト
コル３により通信資源を確保し、ウィンドウ制御プロト
コル４で情報転送開始する。このとき、ウィンドウ制御
プロトコル４に対して、資源予約プロトコル３からＰＣ
Ｒ×４８が通知される。
【００３４】ここで、図４の従来のスロースタートのア
ルゴリズムでは、時刻Ｔ３でヘッドオブラインブロッキ
ングの発生に起因してデータが紛失する。これにより、
再度、時刻Ｔ３からスロースタートが開始されて、ウィ
ンドウサイズはサイズＢ／２まで指数関数的に増加し、
それ以降は、輻輳回避によりサイズＢまで緩やかに増加
する。
ルゴリズムでは、時刻Ｔ３でヘッドオブラインブロッキ
ングの発生に起因してデータが紛失する。これにより、
再度、時刻Ｔ３からスロースタートが開始されて、ウィ
ンドウサイズはサイズＢ／２まで指数関数的に増加し、
それ以降は、輻輳回避によりサイズＢまで緩やかに増加
する。
【００３５】一方、図５の本発明では、時刻Ｔ３でヘッ
ドオブラインブロッキングの発生に起因してデータが紛
失した場合、図９に示すようなスロースタート処理の実
行が開始される。まず、ウィンドウサイズを初期化し
（Ｓ１）、ＡＣＫ待ち（Ｓ２）になる。ここで、ＡＣＫ
が返送されると（Ｓ３）、ウィンドウサイズ＋セグメン
トサイズを送信バッファ容量と比較し（Ｓ５）、ウィン
ドウサイズ＋セグメントサイズのほうが大きい場合には
（Ｓ５：ＮＯ）、ＡＣＫ待ち（Ｓ２）に遷移する。
ドオブラインブロッキングの発生に起因してデータが紛
失した場合、図９に示すようなスロースタート処理の実
行が開始される。まず、ウィンドウサイズを初期化し
（Ｓ１）、ＡＣＫ待ち（Ｓ２）になる。ここで、ＡＣＫ
が返送されると（Ｓ３）、ウィンドウサイズ＋セグメン
トサイズを送信バッファ容量と比較し（Ｓ５）、ウィン
ドウサイズ＋セグメントサイズのほうが大きい場合には
（Ｓ５：ＮＯ）、ＡＣＫ待ち（Ｓ２）に遷移する。
【００３６】一方、ウィンドウサイズ＋セグメントサイ
ズのほうが送信バッファ容量より小さい場合には（Ｓ
５：ＹＥＳ）、ウィンドウサイズ＋セグメントサイズを
受信バッファの空き容量と比較する（Ｓ６）。ここで、
ウィンドウサイズ＋セグメントサイズのほうが大きい場
合には（Ｓ６：ＮＯ）、ＡＣＫ待ち（Ｓ２）に遷移し、
小さい場合には（Ｓ６：ＹＥＳ）、ウィンドウサイズ＋
セグメントサイズを（ＰＣＲ×４８−オーバーヘッド）
×ＲＴＴと比較する（Ｓ７）
ズのほうが送信バッファ容量より小さい場合には（Ｓ
５：ＹＥＳ）、ウィンドウサイズ＋セグメントサイズを
受信バッファの空き容量と比較する（Ｓ６）。ここで、
ウィンドウサイズ＋セグメントサイズのほうが大きい場
合には（Ｓ６：ＮＯ）、ＡＣＫ待ち（Ｓ２）に遷移し、
小さい場合には（Ｓ６：ＹＥＳ）、ウィンドウサイズ＋
セグメントサイズを（ＰＣＲ×４８−オーバーヘッド）
×ＲＴＴと比較する（Ｓ７）
【００３７】ここで、ウィンドウサイズ＋セグメントサ
イズのほうか大きい場合には（Ｓ７：ＮＯ）、ＡＣＫ待
ち（Ｓ２）に遷移し、小さい場合には（Ｓ７：ＹＥ
Ｓ）、ウィンドウサイズにセグメントサイズを加えて
（Ｓ８）、ＡＣＫ待ち（Ｓ２）に遷移する。この結果、
図５に示すように、時刻Ｔ３からのスロースタートによ
り、従来のようにサイズＢ／２ではなく、サイズＢ（第
２のウィンドウサイズ）までウィンドウサイズが増加す
るものとなり、平均のスループットは従来の場合（図４
参照）より高くなる。
イズのほうか大きい場合には（Ｓ７：ＮＯ）、ＡＣＫ待
ち（Ｓ２）に遷移し、小さい場合には（Ｓ７：ＹＥ
Ｓ）、ウィンドウサイズにセグメントサイズを加えて
（Ｓ８）、ＡＣＫ待ち（Ｓ２）に遷移する。この結果、
図５に示すように、時刻Ｔ３からのスロースタートによ
り、従来のようにサイズＢ／２ではなく、サイズＢ（第
２のウィンドウサイズ）までウィンドウサイズが増加す
るものとなり、平均のスループットは従来の場合（図４
参照）より高くなる。
【００３８】したがって、本発明の第２の実施の形態に
よりスロースタート制御では、ウィンドウサイズにセグ
メントサイズを加えた値、すなわちウィンドウサイズ＋
セグメントサイズが、送信バッファ容量，受信バッファ
の空き容量、さらには（ＰＣＲ×４８−オーバーヘッ
ド）×ＲＴＴの比較対象となる。
よりスロースタート制御では、ウィンドウサイズにセグ
メントサイズを加えた値、すなわちウィンドウサイズ＋
セグメントサイズが、送信バッファ容量，受信バッファ
の空き容量、さらには（ＰＣＲ×４８−オーバーヘッ
ド）×ＲＴＴの比較対象となる。
【００３９】次に、図１，６，７，１０を参照して、本
発明の第３の実施の形態として、特に、ＡＴＭのサービ
スカテゴリーＡＢＲ（Avalable Bit Rate ：アベーラブ
ルビットレート）上のフロー制御に対してウィンドウ制
御を行うプロトコルに適用する場合について説明する。
ここでは、本発明のウィンドウ制御方法として、送信バ
ッファ容量，受信バッファの空き容量，およびＭＣＲ
（Minimum Cell Rate：ミニマムセルレート）により確
保した帯域と遅延（ＲＴＴ）との積のうち、いずれか小
さいものをスロースタートのしきい値として用いるよう
にしたものである。
発明の第３の実施の形態として、特に、ＡＴＭのサービ
スカテゴリーＡＢＲ（Avalable Bit Rate ：アベーラブ
ルビットレート）上のフロー制御に対してウィンドウ制
御を行うプロトコルに適用する場合について説明する。
ここでは、本発明のウィンドウ制御方法として、送信バ
ッファ容量，受信バッファの空き容量，およびＭＣＲ
（Minimum Cell Rate：ミニマムセルレート）により確
保した帯域と遅延（ＲＴＴ）との積のうち、いずれか小
さいものをスロースタートのしきい値として用いるよう
にしたものである。
【００４０】図６は、従来のウィンドウ制御方法を用い
た場合のウィンドウサイズの推移を示す説明図であり、
特に、ＡＴＭのサービスカテゴリーＡＢＲ上のフロー制
御に対してウィンドウ制御を行うプロトコルとして、本
発明による最大ウィンドウサイズ（第１の実施の形態）
を適用し、従来と同様のスロースタートおよび輻輳回避
アルゴリズムによるウィンドウ制御を行った場合のウィ
ンドウサイズの推移を示している。
た場合のウィンドウサイズの推移を示す説明図であり、
特に、ＡＴＭのサービスカテゴリーＡＢＲ上のフロー制
御に対してウィンドウ制御を行うプロトコルとして、本
発明による最大ウィンドウサイズ（第１の実施の形態）
を適用し、従来と同様のスロースタートおよび輻輳回避
アルゴリズムによるウィンドウ制御を行った場合のウィ
ンドウサイズの推移を示している。
【００４１】同図において、３０は輻輳が発生した時刻
Ｔ４であり、３１は（ＰＣＲ×４８−オーバーヘッド）
×ＲＴＴにより算出されるウィンドウサイズＢ、３２は
（ＭＣＲ×４８−オーバーヘッド）×ＲＴＴにより算出
されるウィンドウサイズＣ、３３はウィンドウサイズＢ
／２を示している。なお、サイズＣの算出式では、前述
のサイズＢの算出式と同様に、ＭＣＲ×４８よりオーバ
ーヘッド分だけ帯域を減算することにより、使用可能な
最大帯域を正確に求めることができる。また、以下の説
明では、サイズＣ＜サイズＢと仮定している。
Ｔ４であり、３１は（ＰＣＲ×４８−オーバーヘッド）
×ＲＴＴにより算出されるウィンドウサイズＢ、３２は
（ＭＣＲ×４８−オーバーヘッド）×ＲＴＴにより算出
されるウィンドウサイズＣ、３３はウィンドウサイズＢ
／２を示している。なお、サイズＣの算出式では、前述
のサイズＢの算出式と同様に、ＭＣＲ×４８よりオーバ
ーヘッド分だけ帯域を減算することにより、使用可能な
最大帯域を正確に求めることができる。また、以下の説
明では、サイズＣ＜サイズＢと仮定している。
【００４２】一方、図７は、本発明の第３の実施の形態
によるウィンドウサイズの推移を示す説明図であり、特
に、ＡＴＭのサービスカテゴリーＡＢＲ上のフロー制御
に対してウィンドウ制御を行うプロトコルとして、本発
明による最大ウィンドウサイズ（第１の実施の形態）を
適用し、本発明によるスロースタートおよび輻輳回避ア
ルゴリズムによるウィンドウ制御を行った場合のウィン
ドウサイズの推移を示した図である。
によるウィンドウサイズの推移を示す説明図であり、特
に、ＡＴＭのサービスカテゴリーＡＢＲ上のフロー制御
に対してウィンドウ制御を行うプロトコルとして、本発
明による最大ウィンドウサイズ（第１の実施の形態）を
適用し、本発明によるスロースタートおよび輻輳回避ア
ルゴリズムによるウィンドウ制御を行った場合のウィン
ドウサイズの推移を示した図である。
【００４３】同図において、３４は輻輳が発生した時刻
Ｔ４、３５は（ＰＣＲ×４８−オーバーヘッド）×ＲＴ
Ｔにより算出されるウィンドウサイズＢ、３６は（ＭＣ
Ｒ×４８−オーバーヘッド）×ＲＴＴにより算出される
ウィンドウサイズＣ、３７はウィンドウサイズＢ／２を
示している。
Ｔ４、３５は（ＰＣＲ×４８−オーバーヘッド）×ＲＴ
Ｔにより算出されるウィンドウサイズＢ、３６は（ＭＣ
Ｒ×４８−オーバーヘッド）×ＲＴＴにより算出される
ウィンドウサイズＣ、３７はウィンドウサイズＢ／２を
示している。
【００４４】図１０は、本発明の第３の実施の形態によ
るスロースタートおよび輻輳回避の処理動作を示すフロ
ーチャートである。同図では、特に、ＡＴＭのサービス
カテゴリーＡＢＲ上のフロー制御にウィンドウ制御を行
うプロトコルに本発明による最大のウィンドウサイズを
適用し、本発明によるスロースタートおよび輻輳回避ア
ルゴリズムによるウィンドウ制御を行う場合について示
している。
るスロースタートおよび輻輳回避の処理動作を示すフロ
ーチャートである。同図では、特に、ＡＴＭのサービス
カテゴリーＡＢＲ上のフロー制御にウィンドウ制御を行
うプロトコルに本発明による最大のウィンドウサイズを
適用し、本発明によるスロースタートおよび輻輳回避ア
ルゴリズムによるウィンドウ制御を行う場合について示
している。
【００４５】以下、本発明の第３の実施の形態によるス
ロースタートおよび輻輳回避のアルゴリズムについて説
明する。まず、図１において、アプリケーション２は、
資源予約プロトコル３により通信資源を確保し、ウィン
ドウ制御プロトコル４で情報転送開始する。このとき、
ウィンドウ制御プロトコル４に対して、資源予約プロト
コル３からＰＣＲ×４８−オーバーヘッド、およびＭＣ
Ｒ×４８−オーバーヘッドが通知される。
ロースタートおよび輻輳回避のアルゴリズムについて説
明する。まず、図１において、アプリケーション２は、
資源予約プロトコル３により通信資源を確保し、ウィン
ドウ制御プロトコル４で情報転送開始する。このとき、
ウィンドウ制御プロトコル４に対して、資源予約プロト
コル３からＰＣＲ×４８−オーバーヘッド、およびＭＣ
Ｒ×４８−オーバーヘッドが通知される。
【００４６】ここで、図６の従来のスロースタートのア
ルゴリズムでは、時刻Ｔ４で輻輳が発生した場合、再
度、時刻Ｔ４からスロースタートが開始されて、ウィン
ドウサイズがサイズＢ／２まで指数関数的に増加し、そ
れ以降は、輻輳回避によりサイズＢまで緩やかに増加す
る。
ルゴリズムでは、時刻Ｔ４で輻輳が発生した場合、再
度、時刻Ｔ４からスロースタートが開始されて、ウィン
ドウサイズがサイズＢ／２まで指数関数的に増加し、そ
れ以降は、輻輳回避によりサイズＢまで緩やかに増加す
る。
【００４７】一方、図７の本発明では、時刻Ｔ３で輻輳
が発生した場合、図１０に示すようなスロースタートお
よび輻輳回避処理の実行が開始される。まず、ウィンド
ウサイズを初期化し（Ｓ１０）、ＡＣＫ待ち（Ｓ１１）
に遷移する。ここでＡＣＫが返送されると（Ｓ１２）、
ウィンドウサイズ＋セグメントサイズを送信バッファ容
量と比較し（Ｓ１４）、ウィンドウサイズ＋セグメント
サイズのほうが大きい場合には（Ｓ１４：ＮＯ）、ＡＣ
Ｋ待ち（Ｓ１１）に遷移する。
が発生した場合、図１０に示すようなスロースタートお
よび輻輳回避処理の実行が開始される。まず、ウィンド
ウサイズを初期化し（Ｓ１０）、ＡＣＫ待ち（Ｓ１１）
に遷移する。ここでＡＣＫが返送されると（Ｓ１２）、
ウィンドウサイズ＋セグメントサイズを送信バッファ容
量と比較し（Ｓ１４）、ウィンドウサイズ＋セグメント
サイズのほうが大きい場合には（Ｓ１４：ＮＯ）、ＡＣ
Ｋ待ち（Ｓ１１）に遷移する。
【００４８】一方、ウィンドウサイズ＋セグメントサイ
ズのほうが送信バッファ容量より小さい場合には（Ｓ１
４：ＹＥＳ）、ウィンドウサイズ＋セグメントサイズを
受信バッファの空き容量と比較する（Ｓ１５）。ここ
で、ウィンドウサイズ＋セグメントサイズのほうが大き
い場合には（Ｓ１５：ＮＯ）、ＡＣＫ待ち（Ｓ１１）に
遷移し、小さい場合には（Ｓ１５：ＹＥＳ）、ウィンド
ウサイズ＋セグメントサイズを（ＭＣＲ×４８−オーバ
ーヘッド）×ＲＴＴと比較する（Ｓ１６）。
ズのほうが送信バッファ容量より小さい場合には（Ｓ１
４：ＹＥＳ）、ウィンドウサイズ＋セグメントサイズを
受信バッファの空き容量と比較する（Ｓ１５）。ここ
で、ウィンドウサイズ＋セグメントサイズのほうが大き
い場合には（Ｓ１５：ＮＯ）、ＡＣＫ待ち（Ｓ１１）に
遷移し、小さい場合には（Ｓ１５：ＹＥＳ）、ウィンド
ウサイズ＋セグメントサイズを（ＭＣＲ×４８−オーバ
ーヘッド）×ＲＴＴと比較する（Ｓ１６）。
【００４９】ここで、ウィンドウサイズ＋セグメントサ
イズのほうが小さい場合には（Ｓ１６：ＹＥＳ）、ウィ
ンドウサイズにセグメントサイズを加えて（Ｓ１８）、
ＡＣＫ待ち（Ｓ１１）に遷移する。一方、ウィンドウサ
イズ＋セグメントサイズのほうが大きい場合には（Ｓ１
６：ＮＯ）、ウィンドウサイズ＋セグメントサイズを
（ＰＣＲ×４８−オーバーヘッド）×ＲＴＴと比較する
（Ｓ１７）。
イズのほうが小さい場合には（Ｓ１６：ＹＥＳ）、ウィ
ンドウサイズにセグメントサイズを加えて（Ｓ１８）、
ＡＣＫ待ち（Ｓ１１）に遷移する。一方、ウィンドウサ
イズ＋セグメントサイズのほうが大きい場合には（Ｓ１
６：ＮＯ）、ウィンドウサイズ＋セグメントサイズを
（ＰＣＲ×４８−オーバーヘッド）×ＲＴＴと比較する
（Ｓ１７）。
【００５０】さらにここで、ウィンドウサイズ＋セグメ
ントサイズのほうが大きい場合には（Ｓ１７：ＮＯ）、
ＡＣＫ待ち（Ｓ１１）に遷移し、小さい場合には（Ｓ１
７：ＹＥＳ）、ウィンドウサイズにセグメントサイズ×
セグメントサイズ÷ウィンドウサイズおよびセグメント
サイズ÷８を加えて（Ｓ１９）、ＡＣＫ待ち（Ｓ１１）
に遷移する。この結果、図７に示すように、時刻Ｔ４か
らのスロースタートにより、従来のようにサイズＢ／２
ではなく、サイズＣ（第３のウィンドウサイズ）までウ
ィンドウサイズが増加するものとなり、平均のスループ
ットは従来の場合（図６参照）より高くなる。
ントサイズのほうが大きい場合には（Ｓ１７：ＮＯ）、
ＡＣＫ待ち（Ｓ１１）に遷移し、小さい場合には（Ｓ１
７：ＹＥＳ）、ウィンドウサイズにセグメントサイズ×
セグメントサイズ÷ウィンドウサイズおよびセグメント
サイズ÷８を加えて（Ｓ１９）、ＡＣＫ待ち（Ｓ１１）
に遷移する。この結果、図７に示すように、時刻Ｔ４か
らのスロースタートにより、従来のようにサイズＢ／２
ではなく、サイズＣ（第３のウィンドウサイズ）までウ
ィンドウサイズが増加するものとなり、平均のスループ
ットは従来の場合（図６参照）より高くなる。
【００５１】次に、図１１，１２を参照して、本発明の
第４の実施の形態について説明する。図１１は、本発明
の第４の実施の形態による通信システムを示すブロック
図であり、特に、通信メディアがＡＴＭでシェアドメデ
ィアと相互接続して通信するとき、中継ノード６（図１
参照）の資源予約プロトコル７により相互接続している
ことを、フロー制御としてウィンドウ制御を行うプロト
コルに通知する場合を示している。
第４の実施の形態について説明する。図１１は、本発明
の第４の実施の形態による通信システムを示すブロック
図であり、特に、通信メディアがＡＴＭでシェアドメデ
ィアと相互接続して通信するとき、中継ノード６（図１
参照）の資源予約プロトコル７により相互接続している
ことを、フロー制御としてウィンドウ制御を行うプロト
コルに通知する場合を示している。
【００５２】同図において、５０は送信側のエンドシス
テム、５１は通知メッセージ、５２は送信側のエンドシ
ステムが接続されているＡＴＭ網、５３はＡＴＭ網とイ
ーサネットを接続する中継ノード、５４はイーサネッ
ト、５５〜５７はイーサネット５４を介して中継ノード
５３に接続される受信側のエンドシステムである。
テム、５１は通知メッセージ、５２は送信側のエンドシ
ステムが接続されているＡＴＭ網、５３はＡＴＭ網とイ
ーサネットを接続する中継ノード、５４はイーサネッ
ト、５５〜５７はイーサネット５４を介して中継ノード
５３に接続される受信側のエンドシステムである。
【００５３】また、図１２は、本発明の第４の実施の形
態によるウィンドウ制御切替処理を示すフローチャート
である。同図では、特に、通信メディアがＡＴＭでシェ
アドメディアと相互接続して通信するときと相互接続し
ないで通信するときのウィンドウ制御の切り替え動作を
示している。
態によるウィンドウ制御切替処理を示すフローチャート
である。同図では、特に、通信メディアがＡＴＭでシェ
アドメディアと相互接続して通信するときと相互接続し
ないで通信するときのウィンドウ制御の切り替え動作を
示している。
【００５４】以下、本発明の第４の実施の形態によるウ
ィンドウ制御の切り替え動作について説明する。まず、
送信側エンドシステム５０のアプリケーション２（図１
参照）は、資源予約プロトコル３により通信資源を確保
するために所定の要求を送信する。一方、受信側エンド
システム５５は帯域を保証しないネットワークすなわち
イーサネット５４に接続されている。
ィンドウ制御の切り替え動作について説明する。まず、
送信側エンドシステム５０のアプリケーション２（図１
参照）は、資源予約プロトコル３により通信資源を確保
するために所定の要求を送信する。一方、受信側エンド
システム５５は帯域を保証しないネットワークすなわち
イーサネット５４に接続されている。
【００５５】したがって、帯域を保証するＡＴＭ網５２
と帯域保証しないイーサネット５４の境界にある中継ノ
ード５３（あるいは図１の６）の資源予約プロトコル７
から、インターワーク有りの通知を送信側エンドシステ
ム５０に送信する。このインターワーク有りの通知は、
送信側エンドシステム５０の資源予約プロトコル３で受
信され、ウィンドウ制御プロトコル４に通知される。
と帯域保証しないイーサネット５４の境界にある中継ノ
ード５３（あるいは図１の６）の資源予約プロトコル７
から、インターワーク有りの通知を送信側エンドシステ
ム５０に送信する。このインターワーク有りの通知は、
送信側エンドシステム５０の資源予約プロトコル３で受
信され、ウィンドウ制御プロトコル４に通知される。
【００５６】これに応じて、ウィンドウ制御プロトコル
４では、ウィンドウ制御時に、図１２に示すウィンドウ
切り替え処理を実行する。まず、インターワークの通知
があったか否か判定し（Ｓ３０）、通知があった場合に
は（Ｓ３０：ＹＥＳ）、従来のウィンドウ制御を実行す
る（Ｓ３１）。これにより、図２で示したように、送信
バッファ容量と受信バッファの空き容量のうち、いずれ
か小さい値が、最大ウィンドウサイズとして用いられ
る。
４では、ウィンドウ制御時に、図１２に示すウィンドウ
切り替え処理を実行する。まず、インターワークの通知
があったか否か判定し（Ｓ３０）、通知があった場合に
は（Ｓ３０：ＹＥＳ）、従来のウィンドウ制御を実行す
る（Ｓ３１）。これにより、図２で示したように、送信
バッファ容量と受信バッファの空き容量のうち、いずれ
か小さい値が、最大ウィンドウサイズとして用いられ
る。
【００５７】一方、インターワークの通知がなかった場
合には（Ｓ３０：ＮＯ）、図３，５，７で示したよう
に、本発明によるウィンドウ制御（Ｓ３２）を実行す
る。これにより、通信メディアがシェアドメディアとイ
ンターワークする場合、従来のウィンドウ制御を踏襲す
ることができ、相互接続性が確保される。
合には（Ｓ３０：ＮＯ）、図３，５，７で示したよう
に、本発明によるウィンドウ制御（Ｓ３２）を実行す
る。これにより、通信メディアがシェアドメディアとイ
ンターワークする場合、従来のウィンドウ制御を踏襲す
ることができ、相互接続性が確保される。
【００５８】
【発明の効果】以上説明したように、本発明は、資源予
約プロトコルなどにより、帯域、遅延などの確保した通
信資源に関わるパラメータに基づいて、フロー制御にウ
ィンドウ制御を行うプロトコルのウィンドウサイズを制
御するようにしたので、無駄なスロースタートや輻輳回
避処理をすることなく最適なウィンドウ制御を行うこと
ができ、スループットを改善できる。また、インターワ
ーク有りの通知に基づき、従来のウィンドウ制御に切り
替えるようにしたので、通信メディアがシェアドメディ
アとインターワークする場合に、従来のウィンドウ制御
を踏襲することができ、相互接続性を確保できる。
約プロトコルなどにより、帯域、遅延などの確保した通
信資源に関わるパラメータに基づいて、フロー制御にウ
ィンドウ制御を行うプロトコルのウィンドウサイズを制
御するようにしたので、無駄なスロースタートや輻輳回
避処理をすることなく最適なウィンドウ制御を行うこと
ができ、スループットを改善できる。また、インターワ
ーク有りの通知に基づき、従来のウィンドウ制御に切り
替えるようにしたので、通信メディアがシェアドメディ
アとインターワークする場合に、従来のウィンドウ制御
を踏襲することができ、相互接続性を確保できる。
【図１】 本発明の一実施の形態であるウィンドウ制御
方法が適用される通信システムを示すブロック図であ
る。
方法が適用される通信システムを示すブロック図であ
る。
【図２】 従来のウィンドウ制御方法によるウィンドウ
サイズの推移を示す説明図である。
サイズの推移を示す説明図である。
【図３】 本発明の第１の実施の形態によるウィンドウ
サイズの推移を示す説明図である。
サイズの推移を示す説明図である。
【図４】 従来のウィンドウ制御方法を用いた場合のウ
ィンドウサイズの推移を示す説明図である。
ィンドウサイズの推移を示す説明図である。
【図５】 本発明の第２の実施の形態によるウィンドウ
サイズの推移を示す説明図である。
サイズの推移を示す説明図である。
【図６】 従来のウィンドウ制御方法を用いた場合のウ
ィンドウサイズの推移を示す説明図である。
ィンドウサイズの推移を示す説明図である。
【図７】 本発明の第３の実施の形態によるウィンドウ
サイズの推移を示す説明図である。
サイズの推移を示す説明図である。
【図８】 パケットスイッチまたはＡＴＭスイッチにお
けるヘッドオブラインブロッキングを示す図である。
けるヘッドオブラインブロッキングを示す図である。
【図９】 本発明の第２の実施の形態によるスロースタ
ート処理動作を示すフローチャートである。
ート処理動作を示すフローチャートである。
【図１０】 本発明の第３の実施の形態によるスロース
タートおよび輻輳回避の処理動作を示すフローチャート
である。
タートおよび輻輳回避の処理動作を示すフローチャート
である。
【図１１】 本発明の第４の実施の形態による通信シス
テムを示すブロック図であ
テムを示すブロック図であ
【図１２】 本発明の第４の実施の形態によるウィンド
ウ制御切替処理を示すフローチャートである。
ウ制御切替処理を示すフローチャートである。
１…エンドシステム、２…アプリケーション、３，７…
資源予約プロトコル、４…ウィンドウ制御プロトコル、
５，８…パケットクラシファイアおよびスケジューラ、
６…中継ノード、５０…エンドシステム、５１…通知メ
ッセージ、５２…ＡＴＭ網、５３…中継ノード、５４…
イーサネット、５５〜５７…エンドシステム。
資源予約プロトコル、４…ウィンドウ制御プロトコル、
５，８…パケットクラシファイアおよびスケジューラ、
６…中継ノード、５０…エンドシステム、５１…通知メ
ッセージ、５２…ＡＴＭ網、５３…中継ノード、５４…
イーサネット、５５〜５７…エンドシステム。
Claims (4)
- 【請求項１】 通信資源を予約しうる通信メディアに対
するフロー制御として、受信側からの送達確認通知を受
信するごとに送信可能容量を示すウィンドウサイズを単
位送信容量から増加させ、所定の最大ウィンドウサイズ
まで指数関数的に増加させるスロースタート処理と、受
信側からの送達確認通知を受信するごとにウィンドウサ
イズを単位送信容量づつ最大ウィンドウサイズまで徐々
に増加させる輻輳回避処理とからなるウィンドウ制御を
実行する通信プロトコルにおいて、 送信バッファ容量，受信バッファの空き容量，および使
用可能な最大帯域とラウンドトリップタイムとの積のう
ち、いずれか最小の値からなる第１のウィンドウサイズ
を最大ウィンドウサイズとして用いることを特徴とする
ウィンドウ制御方法。 - 【請求項２】 請求項１のウィンドウ制御方法におい
て、 通信メディアがＡＴＭでサービスカテゴリがコンスタン
トビットレートの場合には、スロースタートにより増加
するウィンドウサイズが、送信バッファ容量，受信バッ
ファの空き容量，およびピークセルレートに基づき確保
した使用可能な最大帯域とラウンドトリップタイムとの
積のうち、いずれか最小の値からなる第２のウィンドウ
サイズとなった時点で、スロースタート処理を終了し、 スロースタート処理の終了後は、パケット紛失が発生す
るまで、第２のウィンドウサイズを最大ウィンドウサイ
ズとして用いることを特徴とするウィンドウ制御方法。 - 【請求項３】 請求項１のウィンドウ制御方法におい
て、 通信メディアがＡＴＭでサービスカテゴリがアベーラブ
ルビットレートの場合には、スロースタートにより増加
するウィンドウサイズが、送信バッファ容量，受信バッ
ファの空き容量，およびミニマムセルレートに基づき確
保した使用可能な最大帯域とラウンドトリップタイムと
の積のうち、いずれか最小の値からなる第３のウィンド
ウサイズとなった時点で、スロースタート処理を終了す
ることを特徴とするウィンドウ制御方法。 - 【請求項４】 請求項１のウィンドウ制御方法におい
て、 通信メディアがＡＴＭで通信資源を予約しうる通信メデ
ィアと相互接続して通信している旨の通知に応じて、 送信バッファ容量および受信バッファの空き容量のう
ち、いずれか最小の値からなる第４のウィンドウサイズ
を最大ウィンドウサイズとして用いることを特徴とする
ウィンドウ制御方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP28982597A JPH11127163A (ja) | 1997-10-22 | 1997-10-22 | ウィンドウ制御方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP28982597A JPH11127163A (ja) | 1997-10-22 | 1997-10-22 | ウィンドウ制御方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JPH11127163A true JPH11127163A (ja) | 1999-05-11 |
Family
ID=17748266
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP28982597A Pending JPH11127163A (ja) | 1997-10-22 | 1997-10-22 | ウィンドウ制御方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JPH11127163A (ja) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6934251B2 (en) | 2000-02-23 | 2005-08-23 | Nec Corporation | Packet size control technique |
| JP2007201702A (ja) * | 2006-01-25 | 2007-08-09 | Mitsubishi Electric Corp | 受信装置、通信装置および通信方法 |
| JP2010504672A (ja) * | 2006-09-21 | 2010-02-12 | イパネマ・テクノロジーズ | パケット遠隔通信ネットワークにおけるトラフィックの制御の最適化プロセス |
| CN102014055A (zh) * | 2010-11-23 | 2011-04-13 | 中兴通讯股份有限公司 | Mtp2协议中流量控制的方法及系统 |
-
1997
- 1997-10-22 JP JP28982597A patent/JPH11127163A/ja active Pending
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6934251B2 (en) | 2000-02-23 | 2005-08-23 | Nec Corporation | Packet size control technique |
| JP2007201702A (ja) * | 2006-01-25 | 2007-08-09 | Mitsubishi Electric Corp | 受信装置、通信装置および通信方法 |
| JP2010504672A (ja) * | 2006-09-21 | 2010-02-12 | イパネマ・テクノロジーズ | パケット遠隔通信ネットワークにおけるトラフィックの制御の最適化プロセス |
| CN102014055A (zh) * | 2010-11-23 | 2011-04-13 | 中兴通讯股份有限公司 | Mtp2协议中流量控制的方法及系统 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4436981B2 (ja) | ハイブリッドｉｐ−ａｔｍネットワーク内で混雑状態を管理するためのｅｃｎベースの方法 | |
| US5442624A (en) | Dynamic access control for an ATM network | |
| US6208653B1 (en) | Method and apparatus for controlling a flow between terminals in an ATM network | |
| JP2977029B2 (ja) | 高速ａｔｍセル伝送を使用したインターネットプロトコルスイッチング方法及びそのためのネットワーク | |
| JP3607466B2 (ja) | ルータ装置及び制御フレーム処理方法 | |
| JPH0662042A (ja) | データ伝送システムに関する改良 | |
| AU745204B2 (en) | Flow control in a telecommunications network | |
| US5511076A (en) | Method and apparatus to efficiently reuse virtual connections by means of chaser packets | |
| KR100298357B1 (ko) | 프레임릴레이-에이티엠간인터페이스회로및그작동방법 | |
| US5905711A (en) | Method and apparatus for controlling data transfer rates using marking threshold in asynchronous transfer mode networks | |
| WO2022022539A1 (zh) | 控制网络拥塞的方法和相关装置 | |
| US6587436B1 (en) | Method and apparatus for allocation of available bandwidth | |
| CN110808884A (zh) | 一种网络拥塞控制方法 | |
| JP3566047B2 (ja) | ネットワークシステム及び通信装置 | |
| EP1038415B1 (en) | Call admission control system for wireless atm networks | |
| JP3608939B2 (ja) | Ｍｂｅａを利用したａｔｍネットワークのユーザトラフィック制御装置 | |
| KR100411447B1 (ko) | 티씨피 혼잡 제어 방법 | |
| JPH11127163A (ja) | ウィンドウ制御方法 | |
| EP0884923B1 (en) | Packet switching network, packet switching equipment, and network management equipment | |
| Hasegawa et al. | Performance evaluation and parameter tuning of TCP over ABR service in ATM networks | |
| JP2001203697A (ja) | フロー制御方法およびそれを実行する通信要素 | |
| JP2000244524A (ja) | ネットワークシステム、信号送受信装置及びネットワーク資源予約方法 | |
| Van Tan et al. | Hard and soft real time based on switched Ethernet | |
| JPH10126430A (ja) | ケーブル・ネットワークシステム | |
| JP3546814B2 (ja) | Ａｔｍ装置およびａｔｍ通信網 |