JPH09247209A - 資源予約チャネル用トランスポートレイヤプロトコルのフロー制御方式 - Google Patents

Abstract

(57)【要約】 【課題】 転送遅延の大きいネットワークを介しデータ
転送する場合に受信端末の受信バッファサイズを増加さ
せずに効率的なスループットのデータ転送を可能にす
る。 【解決手段】 送信端末１に、ネットワークの転送遅延
を受信バッファ２１に仮想化する仮想化ウインドウ制御
部１６を設け、送信端末１は、データ転送の際にはウイ
ンドウ制御部による実ウインドウサイズと仮想化ウイン
ドウ制御部による仮想化ウインドウサイズとを加算して
送信ウインドウサイズとして拡張し、スライディングウ
インドウ制御を行う。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、送信端末、受信端
末及び複数の交換ノードからなる資源予約ネットワーク
において各端末間でデータを転送する際の資源予約チャ
ネル用トランスポートレイヤプロトコルにおけるフロー
制御方式に関する。

【０００２】

【従来の技術】コンピュータ・ネットワークのデータ転
送におけるエンド＿エンド端末間のフロー制御について
は、インターネットにおける代表的なトランスポートプ
ロトコルであるＴＣＰに見られるような制御方法があ
り、そのフロー制御は送信ウインドウと呼ばれる機能を
用いて次のように行われる。

【０００３】まず、受信側で確保できた受信バッファの
サイズを送信側のデータ送信に先立って送信側へ通知す
る。すると、送信側では受信側に対し、そのバッファサ
イズの範囲内でデータの送信を行う。受信側では受信デ
ータの受信処理が終了すると受信バッファの解放を行
い、正常に受信したデータ分の受信バッファサイズを送
信側へ通知する。この場合、送信側では、送信ウインド
ウをスライドさせて次のデータブロックを送信バッファ
に格納して転送するスライディングウインドウ制御を行
う。

【０００４】図５はこのようなエンド＿エンド端末間で
通信されるデータのフロー制御を行う送信端末及び受信
端末の構成を示す図である。同図において、１は送信端
末、２は受信端末である。送信端末１は、送信データを
格納する送信データ格納メモリ１１、送信バッファ１
２、送信バッファ１２から転送する送信データの伝送速
度を定めるレートタイマ１３、受信端末２から通知され
た受信バッファサイズに従って送信データ格納メモリ１
１内のデータを送信バッファ１２に転送するウインドウ
制御部１４、及び受信端末２へ転送したデータの応答確
認を解析するＡＣＫ解析部１５からなる。

【０００５】また、受信端末２は、送信端末１から転送
されるデータ転送パケットを蓄積する受信バッファ２
１、受信バッファ２１に蓄積されたパケットデータを読
み出して所定の処理を行う受信データ処理部２２、及び
受信データ処理部２２で正常に処理された場合に送達確
認パケットＡＣＫを生成し送信端末１側へ返送するＡＣ
Ｋ生成部２３からなる。

【０００６】図６は、送信端末１のウインドウ制御部１
４におけるスライディングウインドウ制御のイメージを
示す図である。図５及び図６に従い、従来のフロー制御
について説明する。いま、ウインドウ制御部１４でアド
レス管理する送信データ格納メモリ１１内のデータの送
信状況が図６（ａ）のような状態であったとする。即
ち、図６（ａ）において、Ａは受信端末２へ送信して受
信端末２から送達確認ＡＣＫが得られた分のデータ、Ｃ
は受信端末２へ送信したが受信端末２から送達確認ＡＣ
Ｋが得られない分のデータを示す。なお、Ｄ，Ｅは未送
信データであるがこのうち未送信データＤは送信ウイン
ドウ幅の範囲内にあるため、受信端末２から送達確認Ａ
ＣＫが来なくても受信端末２側に送信できるデータであ
る。

【０００７】そこで、送信端末１は、レートタイマタイ
ミングで、この未送信データＤのうちレート制御で規
定されているデータ量Ｂを送信バッファ１２から受信端
末２側へ送信する。すると、この時点の送信データ格納
メモリ１１のデータの送信状況は図６（ｂ）のように、
送信済み送達確認待ちデータＣの領域がその分（即ち、
データ量Ｂ）だけ増加し、未送信データＤの領域はその
分だけ減少する。

【０００８】ここで時点において、送信バッファ１２
から送達確認ＡＣＫを受けたデータを廃棄し、その分の
データ量を送信データ格納メモリ１１から取り出して送
信バッファ１２に格納する。この動作により、送信ウイ
ンドウが送達確認ＡＣＫで表示される受信バッファ２１
の空き容量分スライドされたことになる。この結果、図
６（ｃ）に示すように、送信データ格納メモリ１１内の
送達確認済みデータＡの領域が送達確認ＡＣＫを受けた
データの容量分だけ増加する。またこのとき未送信デー
タＤの領域もその分だけ増加し、未送信データＥの領域
はその分だけ減少する。その後、図６（ｄ）に示すよう
に、レートタイマタイミングで未送信データＤのうち
レート制御で規定されているデータ量Ｂの容量分のデー
タが受信端末２へ送信される。以降、送信データ格納メ
モリ１１に格納されているデータ全てが送信されるまで
同様の動作が繰り返し行われる。

【０００９】

【発明が解決しようとする課題】従来方式では、ネット
ワーク上で転送遅延による転送のブロッキングが生じて
受信端末から送達確認ＡＣＫが得られず、従って新たな
ウインドウの通知が来ない限りは送信端末側では、送信
ウインドウを消費した時点でデータ転送がブロックされ
てしまい、転送帯域と転送遅延時間積の大きな高速広帯
域ネットワークにおいてはこの間、図４（ｂ）に示すよ
うに受信端末側にデータ転送が行えず、スループットが
低下する。このため、こうした転送帯域と転送遅延時間
積の大きなネットワークにおいて上記のような問題に対
処する方法として、転送遅延及び転送帯域を見込んで送
受信バッファのサイズを予め大きく確保するウインドウ
サイズの拡張方法が提案されている。

【００１０】しかし、この方法では事前にネットワーク
の転送遅延量が不明であるため、ネットワークの実際の
転送遅延や受信端末の実際の受信処理速度に無関係に大
きなサイズの送受信バッファを送受信側に確保する必要
があり、このことは現状のネットワークの高速化や拡大
化において、送受信端末のバッファ資源の浪費を招くと
いう問題がある。

【００１１】従って本発明は、転送遅延の大きいネット
ワークを介してデータを転送する場合に受信端末側の受
信バッファのサイズを増加させずにデータ伝送のスルー
プットを向上させることを目的とする。

【００１２】

【課題を解決するための手段】このような課題を解決す
るために本発明は、送信端末に、ネットワークの転送遅
延を受信バッファに仮想化する仮想化ウインドウ制御部
を備え、送信端末は、ウインドウ制御部による実ウイン
ドウサイズと仮想化ウインドウ制御部による仮想化ウイ
ンドウサイズとを加算して送信ウインドウサイズとして
拡張し、スライディングウインドウ制御を行うようにし
たものである。従って、ネットワーク転送遅延に応じた
仮想化ウインドウサイズを算出して実ウインドウに加算
しスライディングウインドウ制御を行うことで、ネット
ワーク転送遅延に依存しないバッファサイズによる効率
的なスループットのデータ転送が可能になる。また、送
信端末は、データ転送時に受信端末からの再送要求の有
無及びネットワーク転送遅延によるデータ転送のブロッ
キングの発生の有無をそれぞれ検出して再送要求が検出
されれば送信ウインドウサイズを縮小してデータ転送を
行い、ブロッキングの発生が検出されれば送信ウインド
ウサイズの拡張の有無を判断し、送信ウインドウサイズ
が拡張されていなければ送信ウインドウサイズの拡張を
行ってデータ転送を行う一方、送信ウインドウサイズが
拡張されていれば前段階の送信ウインドウサイズの拡張
により転送されたデータの送達確認の受信の有無を判断
のうえ送信ウインドウサイズをさらに拡張してデータ転
送を行う。この結果、データ転送時の各条件に応じて最
適なウインドウサイズを決定することができる。

【００１３】

【発明の実施の形態】以下、本発明について図面を参照
して説明する。ところで本発明では、ネットワークレイ
ヤ以下のレイヤで転送レート（転送帯域）は、ＡＴＭや
ＲＳＶＰ等の資源予約プロトコルにより保証され、図１
に示す送信端末１がその転送レートでデータを送信する
限りはネットワーク上での輻輳は発生しないことを前提
としている。

【００１４】本発明では、送信端末１でネットワーク転
送遅延により送信ウインドウが枯渇し、データ転送がブ
ロッキングされることを回避するため、ネットワーク転
送遅延を受信バッファに仮想化し、ネットワーク転送遅
延をウインドウサイズに変換する手段を有している。そ
してこの仮想化ウインドウサイズを、受信端末２から通
知される実ウインドウサイズに加算してスライディング
ウインドウ制御を行うことであたかも受信バッファサイ
ズが拡大したかのようなデータ転送を可能とし、トータ
ルなスループットの効率化を図るようにしている。即
ち、ネットワーク転送遅延と転送帯域に応じた仮想化ウ
インドウを算出してスライディングウインドウ制御を行
うことで、ネットワーク転送遅延に依存しない端末の処
理能力に応じた最適なバッファサイズにより効率的なス
ループットのデータ転送を可能にするものである。

【００１５】図１は本発明の実施の形態を示すブロック
図である。同図において、図５に示す従来装置と同一部
分は同一符号を付してその概略説明を省略する。即ち本
発明においては、送信端末１に、新たにネットワーク転
送遅延をウインドウサイズに変換するための仮想化ウイ
ンドウ制御部１６を設けている。図１を参照しながら送
信端末１及び受信端末２間のデータ転送動作について説
明する。

【００１６】図１に示す送信端末１及び受信端末２に
は、それぞれ双方の端末間で指定されたデータ転送許容
量分の送信バッファ１２及び受信バッファ２１を有して
いる。ここで、受信端末２では、受信データ処理部２２
で規定されたデータ量の受信処理が終了する毎にＡＣＫ
生成部２３から送信端末１側に送達確認ＡＣＫを返送し
ている。この送達確認ＡＣＫを受信すると、送信端末１
は送信ウインドウをスライドさせるフロー制御を行う。
さらに送信端末１は、その送信ウインドウの許容範囲内
でレートタイマ１３に基づくレート制御によるデータの
転送を行う。本発明では、上述したように、スライディ
ングウインドウ制御を行う従来のウインドウ制御部１４
に加えて、新たに、ネットワーク転送遅延から仮想化ウ
インドウを算出する手段である仮想化ウインドウ制御部
１６を設けている。

【００１７】まず、送信端末１と受信端末２間では、通
信コネクションの確立に当たってデータ転送許容量（送
信バッファサイズ及び受信バッファサイズ）とデータの
転送レートとをネゴシエートする。ウインドウ制御部１
４ではこのネゴシエートされたウインドウサイズ分のデ
ータを送信データ格納メモリ１１から読み出して送信バ
ッファ１２にコピーする。

【００１８】レートタイマ１３では、例えばネゴシエー
トされたパラメータをレート（Ｒｂｐｓ）、バースト
（Ｂｂｉｔ）とし、レートタイマの時間（ＲＴ＝Ｂ／
Ｒ）毎に最大Ｂｂｉｔまでのバーストデータを順次送信
バッファ１２から受信端末２側にデータ転送パケットと
して転送する。受信端末２では、受信したデータ転送パ
ケットを順次受信バッファ２１に蓄積すると共に、この
蓄積パケットデータを受信データ処理部２２で順次処理
する。そして、データが正常に受信された場合はＡＣＫ
生成部２３から応答確認パケットを送信端末１へ返送す
る。また、データが正常に受信できない場合や受信デー
タに欠損がある場合は、ＡＣＫ生成部２３から再送要求
パケットを送信端末１に返送する。

【００１９】送信端末１では、送達確認パケットを受信
した場合は、このパケットをＡＣＫ解析部１５で解析し
てウインドウ制御部１４に送達確認ＡＣＫとして通知す
る。ウインドウ制御部１４ではこの通知を受けるとその
通知を受けたウインドウサイズ分のデータを新たに送信
データ格納メモリ１１から送信バッファ１２にコピーす
る。以降、送信端末１及び受信端末２は全てのデータの
転送が終了するまでこのような動作を繰り返して行う。

【００２０】ここで、以上のようなデータ転送動作にお
いて、送信端末１側で送信バッファ１２の全データの送
信が終了しても送達確認ＡＣＫが受信端末２側から得ら
れない場合は、送信端末１側ではデータ転送のブロッキ
ングが発生したと判断する。この場合、送信端末１の仮
想化ウインドウ制御部１６では、図３に示す動作フロー
に従って送信ウインドウ幅の拡張動作を開始する。な
お、この図３に示す送信ウインドウ幅の拡張動作はその
一例を示すものであり、本発明のスライディングウイン
ドウ制御に転送遅延仮想化ウインドウを加算するフロー
制御を限定するものではない。

【００２１】以下、ウインドウ幅の拡張動作の詳細につ
いて図３の動作フローに従って説明する。送信端末１で
は、レートタイマ１３による送信タイミング時にＡＣＫ
解析部１５において解析された受信端末２からの再送要
求の有無及び転送ブロッキング発生の有無を判定する。
ここで、再送要求を検出しステップＳ１の判定が「Ｙ」
となる場合は、この時点で送信ウインドウの拡張を行っ
ていればステップＳ２で送信ウインドウ幅の縮小（例え
ば、実ウインドウサイズに変更、或いは単調減少則に従
って縮小）を行う。また、このとき送信ウインドウサイ
ズの縮小を行っていなければ実ウインドウサイズのまま
とする。そして、ステップＳ３で転送ブロッキングの発
生の有無を判断し、転送ブロッキングが発生していなけ
ればステップＳ７へ処理を進めて通常のデータ転送を行
う。

【００２２】また、転送ブロッキングが発生していれば
さらに次の判定を行う。即ち、ステップＳ４で送信ウイ
ンドウの拡張済みか否かを判定し、転送ブロッキングが
発生したときに送信ウインドウ幅の拡張を行っていなけ
れば、ステップＳ６へ処理を進めてある法則（例えば、
単調増加則、或いは指数則）に従ってウインドウ幅の拡
張を行い、その後ステップＳ７でデータ転送を行う。ま
た、転送ブロッキングが発生したときにウインドウ幅の
拡張を既に行っていれば、処理をステップＳ５に進めて
さらに次の判定を行う。

【００２３】即ち、前段階の送信ウインドウの拡張によ
り受信端末２側に転送されたデータの正常な送達確認Ａ
ＣＫが受信端末２から受信されているか否かを判断し、
送達確認ＡＣＫが受信されていれば、ステップＳ６であ
る法則（例えば、単調増加則、或いは指数則）に従って
ウインドウ幅の拡張を行い、その後ステップＳ７でデー
タ転送を行う。また、前段階のウインドウの拡張により
受信端末２側に転送されたデータの正常な送達確認ＡＣ
Ｋを受信端末２から受信していなければ、データ転送を
ブロックする（ステップＳ８）。そして以降、全データ
の転送が終了するまで上記動作を繰り返し行う。

【００２４】図２は、このような送信端末１によるスラ
イディングウインドウ制御イメージを示す図である。送
信データ格納メモリ１１内のデータの状況が図２（ａ）
に示すように、送達確認済みデータＡ、送信済みかつ送
達確認待ちデータＣ、及び未送信データＥのようになっ
ており、かつ送信済み送達確認待ちデータ量Ｃが送信ウ
インドウ幅（送信バッファ）と一致し、ウインドウが枯
渇状態となっているときでも、図３に示すフローに従え
ば、受信端末２側へのデータ転送は可能となる。即ち、
レートタイマによる送信タイミング（時点）で、図３
のステップＳ６で示した法則に基づくデータ量分だけの
ウインドウ幅の拡張（即ち、拡張送信バッファ１７を設
けて送信バッファを拡張）とデータ転送処理を行い、実
ウインドウ幅に対し転送データ分だけウインドウ幅を拡
張して送信ウインドウ幅とする（図２（ｂ））。

【００２５】ここで時点において、受信端末２から送
達確認ＡＣＫを受信すると、送信バッファ１２，１７か
ら送達確認ＡＣＫを受けたデータを廃棄し、その分のデ
ータ量を送信データ格納メモリ１１から取り出して送信
バッファ１２，１７に格納する。この動作により、拡張
送信ウインドウによるスライドが実行されたことになる
（図２（ｃ））。そして次の送信タイミング（時点）
で送信バッファにある未送信データのうち、レート制御
で規定されているデータ量Ｂが受信端末２に送信される
（図２（ｄ））。

【００２６】このようにして、従来の実ウインドウ幅に
仮想ウインドウ幅を加算して送信フインドウ幅を拡張す
ることにより、ネットワーク転送遅延が大きなネットワ
ークにおいても、送信端末１側では図４（ａ）に示すよ
うに、受信端末２側に対し連続的にデータを転送できる
ため、データ転送におけるネットワーク転送遅延による
スループットの低下を防止でき、かつ受信端末２側の受
信バッファ２１のサイズの拡大を防止できる。

【００２７】このように、ネットワークレイヤ以下で資
源予約が行われるネットワーク上のトランスポートレイ
ヤプロトコルにおけるデータ転送において、実ウインド
ウサイズが遅延時間の影響しない転送距離においては、
従来と同等の性能が得られると共に、実ウインドウサイ
ズが遅延時間の影響を受けるネットワークにおいてもウ
インドウ枯渇によるスループットの低下を回避でき、最
低の場合でも従来と同等のスループットを得ることがで
きる。また、実環境（例えば、端末の処理能力や負荷）
に応じた送受信バッファの割付が可能になるため、転送
距離による受信バッファの浪費を防止できる。

【００２８】

【発明の効果】以上説明したように本発明によれば、送
信端末に、ネットワークの転送遅延を受信バッファに仮
想化する仮想化ウインドウ制御部を備え、送信端末は、
ウインドウ制御部による実ウインドウサイズと仮想化ウ
インドウ制御部による仮想化ウインドウサイズとを加算
して送信ウインドウサイズとして拡張し、スライディン
グウインドウ制御を行うようにしたので、最適なバッフ
ァサイズによるネットワーク転送遅延に依存しない効率
的なスループットのデータ転送が可能になる。また、例
えば端末の処理能力や負荷に応じた送受信バッファの割
付が可能になるため、ネットワーク転送遅延による受信
バッファの浪費を防止できる。また、送信端末は、デー
タ転送時に受信端末からの再送要求の有無及びネットワ
ーク転送遅延によるデータ転送のブロッキングの発生の
有無をそれぞれ検出して再送要求が検出されれば送信ウ
インドウサイズを縮小してデータ転送を行い、ブロッキ
ングの発生が検出されれば送信ウインドウサイズの拡張
の有無を判断し、送信ウインドウサイズが拡張されてい
なければ送信ウインドウサイズの拡張を行ってデータ転
送を行う一方、送信ウインドウサイズが拡張されていれ
ば前段階の送信ウインドウサイズの拡張により転送され
たデータの送達確認の受信の有無を判断のうえ送信ウイ
ンドウサイズをさらに拡張してデータ転送を行うように
したので、データ転送時の各条件に応じて最適なウイン
ドウサイズを決定することができる。

【図面の簡単な説明】

【図１】 本発明を適用した送信端末及び受信端末の構
成を示すブロック図である。

【図２】 送信端末によるスライディングウインドウ制
御イメージを示す図である。

【図３】 送信端末の要部動作を示すフローチャートで
ある。

【図４】 本発明によるデータ転送状況（図４（ａ））
及び従来方式によるデータ転送状況（図４（ｂ））を示
す図である。

【図５】 従来の送信端末及び受信端末の構成を示す図
である。

【図６】 従来方式によるスライディングウインドウ制
御イメージを示す図である。

【符号の説明】

１…送信端末、２…受信端末、１１…送信データ格納メ
モリ、１２…送信バッファ、１３…レート制御部、１４
…ウインドウ制御部、１５…ＡＣＫ解析部、１６…仮想
ウインドウ制御部、２１…受信バッファ、２２…受信デ
ータ処理部、２３…ＡＣＫ生成部、１７…拡張送信バッ
ファ。

Claims (2)

【特許請求の範囲】
1. 【請求項１】 送信端末と、受信端末と、複数の交換ノ
   ードからなるネットワークとからなり、送信端末はウイ
   ンドウ制御部を有し、前記ウインドウ制御部は前記ネッ
   トワークを介して受信端末にデータ転送を行い受信端末
   から送達確認パケットが返送された際にはその送達確認
   パケットに表示されている新たな受信端末の空受信バッ
   ファのサイズ分のデータ転送を順次行う資源予約チャネ
   ル用トランスポートレイヤプロトコルのフロー制御方式
   において、 前記送信端末に、前記ネットワークの転送遅延を前記受
   信バッファに仮想化する仮想化ウインドウ制御部を備
   え、前記送信端末は、前記ウインドウ制御部による実ウ
   インドウサイズと前記仮想化ウインドウ制御部による仮
   想化ウインドウサイズとを加算して送信ウインドウサイ
   ズとして拡張し、スライディングウインドウ制御を行う
   ことを特徴とする資源予約チャネル用トランスポートレ
   イヤプロトコルのフロー制御方式。
2. 【請求項２】 請求項１において、 前記送信端末は、データ転送時に受信端末からの再送要
   求の有無及びネットワーク転送遅延によるデータ転送の
   ブロッキングの発生の有無をそれぞれ検出し再送要求を
   検出すると送信ウインドウサイズを縮小してデータ転送
   を行い、ブロッキングの発生を検出すると送信ウインド
   ウサイズの拡張の有無を判断し、送信ウインドウサイズ
   が拡張されていなければ送信ウインドウサイズの拡張を
   行ってデータ転送を行う一方、送信ウインドウサイズが
   拡張されていれば前段階の送信ウインドウサイズの拡張
   により転送されたデータの送達確認パケットの受信の有
   無を判断のうえ送信ウインドウサイズをさらに拡張して
   データの転送を行うことを特徴とする資源予約チャネル
   用トランスポートレイヤプロトコルのフロー制御方式。