JP2984910B2 - データフロー制御方法 - Google Patents

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、データフロー制御
方法に関し、特に通信プロトコル処理を実行するノード
におけるレイヤ４（ＯＳＩ参照モデル／トランスポート
層）のデータフロー制御方法に関するものである。

【０００２】

【従来の技術】一般に、インターネットで広く使用され
ているＴＣＰプロトコルなどのレイヤ４（ＯＳＩ参照モ
デル／トランスポート層）では、ウィンドウ方式と呼ば
れるデータフロー制御を基本としている。特に、異なる
性能を有する網やノードが混在したネットワーク環境を
対象としているため、利用できるリソースが不明という
前提に基づいてデータフロー制御のパラメータを調整し
て送信する制御を行うものとなっている。

【０００３】図８は従来のデータフロー制御の処理動作
を示すフローチャートである（例えば、「ＴＣＰ／ＩＰ
によるネットワーク構築」Ｖｏｌ．Ｉの第１２．２０節
およびＶｏｌ．ＩＩの第１４．７節−第１４．８節、
Ｄ．Ｃｏｍｅｒ著、村井訳、共立出版など）。ここでは
受信側が宣言した受信ウィンドウサイズ（ａｄｗｎｄ）
の他に、輻輳ウィンドウサイズ（ｃｗｎｄ）およびスロ
ースタートしきい値（ｓｓｔｈｒｅｓｈ）というパラメ
ータが設けられている。

【０００４】またフロー制御の方法としては、異なる２
つのフェーズ、すなわちスロースタートフェーズと輻輳
回避フェーズを有している。ある時点において送信可能
なパケット数は、ｍｉｎ（ｃｗｎｄ，ａｄｗｎｄ）（但
し、ｍｉｎ（Ａ，Ｂ）はＡまたはＢのいずれか小さい値
を採ることを示す）であり、各パラメータの変動に伴っ
て通信中に変化していくものとなっている。

【０００５】コネクション設定後にデータフロー制御が
開始され、まずフロー制御パラメータとして、ｓｓｔｈ
ｒｅｓｈがａｄｗｎｄに、またｃｗｎｄが１データパケ
ットに初期設定される（ステップ８０）。続いてスロー
スタートフェーズに入り、１個のデータパケットを送信
し、確認応答パケットの受信を待つ（ステップ８１）。

【０００６】ここでパケット送信後から所定時間内に確
認応答パケットを受信した場合には（ステップ８１：確
認応答受信）、送信可能量を示すｃｗｎｄがしきい値ｓ
ｓｔｈｒｅｓｈより小さいか否か判断し（ステップ８
２）、ｃｗｎｄがｓｓｔｈｒｅｓｈより小さい場合には
（ステップ８２：ＹＥＳ）、ｃｗｎｄを２倍に増やし
（ステップ８３）、ステップ８１に戻って次のパケット
を送信する。これにより、送信可能量ｃｗｎｄがしきい
値ｓｓｔｈｒｅｓｈになるまではスロースタートフェー
ズとして確認応答を受信するごとにｃｗｎｄが２倍ずつ
（１，２，４，８・・）増加する（図５（ｂ）参照）。

【０００７】一方、ステップ８２においてｃｗｎｄがｓ
ｓｔｈｒｅｓｈに達した場合には（ステップ８２：Ｎ
Ｏ）、輻輳回避フェーズに入り、ｃｗｎｄを１／ｃｗｎ
ｄだけ増やし（ステップ８４）、ステップ８１に戻って
次のパケットを送信する。これにより、ｃｗｎｄがｓｓ
ｔｈｒｅｓｈに達した場合には、輻輳回避フェーズとし
て確認応答を受信するごとにｃｗｎｄが１／ｃｗｎｄず
つ増加するものとなり、直前のパケット送信量であるｃ
ｗｎｄに対するすべての確認応答を受信すると、ｃｗｎ
ｄは１データパケットだけ増加するものとなり、当初の
スロースタートフェーズに比較して穏やかな増加とな
る。

【０００８】また、ステップ８１において、パケット送
信後から所定時間内に確認応答が受信されなかった場合
には（ステップ８１：確認応答タイムアウト）、輻輳に
よりパケット紛失が発生したと見なして、ｓｓｔｈｒｅ
ｓｈをｍｉｎ（ｃｗｎｄ，ａｄｗｎｄ）／２に設定する
とともに、ｃｗｎｄを「１」に設定し（ステップ８
５）、ステップ８１に戻って次のパケットを送信するも
のとなっていた。

【０００９】

【発明が解決しようとする課題】したがって、このよう
な従来のデータフロー制御方法では、性能が異なる網や
ノードが混在した不均一なネットワーク環境で、輻輳が
発生しやすく、データ伝送時間が回線の伝搬遅延時間よ
りはるかに大きい回線、例えば６４Ｋｂｐｓなどの中低
速回線では効率よく動作するが、データ伝送時間と伝搬
遅延時間との大小関係が逆転するような場合には、デー
タ送信後の確認応答待ち状態が相対的に大きくなり、回
線利用率の低下や回線能力を有効利用できないという問
題点があった。

【００１０】図９はデータ転送所要時間を示す説明図で
あり、ｔh は送信側および受信側におけるパケット処理
に要するパケット処理時間、ｔp は送信側からデータパ
ケットを送信するのに要するデータパケット伝送時間、
ｔakは受信側から確認応答パケットを送信するのに要す
る確認応答パケット伝送時間、ｄは送受信間で各種パケ
ットを転送するのに要する伝搬遅延時間である。一般
に、６４Ｋｂｐｓなどの中低速回線では、パケット転送
速度が低いことから、伝搬遅延時間（ｄ×２）に比較し
てデータ伝送時間すなわちデータパケット伝送時間と確
認応答パケット伝送時間との和（ｔp ＋ｔak）の方が大
きい。

【００１１】しかし、１５０Ｍｂｐｓから数Ｇｂｐｓに
およぶ超高速回線と超高性能な処理装置とからなる比較
的均一なネットワーク環境では、資源容量（回線速度や
バッファのメモリ容量）が不足する場合が少ないと考え
られるので、輻輳は比較的発生しにくく、またデータ伝
送時間（ｔp ＋ｔak）と伝搬遅延時間（ｄ×２）の大小
関係が逆転する。例えば、８Ｋバイトのパケットを東京
−大阪間（約６００Ｋｍ）で転送する場合、光ファイバ
の伝搬遅延時間は５μｓｅｃ／Ｋｍなので往復の伝搬遅
延時間（ｄ×２）は６ｍｓｅｃとなるが、データ伝送時
間（ｔp ＋ｔak）は２．４Ｇｂｐｓ回線では２７μｓｅ
ｃ、また６４Ｋｂｐｓ回線では１ｓｅｃとなり、中低速
回線と超高速回線とでは、伝搬遅延時間とデータ伝送時
間との大小関係が異なる。

【００１２】従来のデータフロー制御方法では、コネク
ション設定完了後に、輻輳ウィンドウサイズｃｗｎｄ＝
「１」から送信を開始し、確認応答を受信するごとに次
に送信できる送信量を２倍にし、順次送信量を増加させ
ていくものとなっているため、超高速回線と超高性能な
処理装置とからなる比較的均一なネットワーク環境で
は、前述したように、伝搬遅延時間の占める割合が大き
いことから、データ送信後の確認応答待ち状態、すなわ
ち回線空き状態が相対的に大きくなり、回線利用率の大
幅な低下を招くという問題点があった。

【００１３】また、パケット紛失時にも同様に、輻輳ウ
ィンドウサイズｃｗｎｄ＝「１」に設定され、そこから
確認応答の受信ごとに順次送信量を増加させるものとな
っているため、途中で中継ノードのバッファ負荷が軽減
されて大量の情報転送が可能となった場合でも、負荷軽
減により増加した回線能力を有効に利用できず、回線能
力を最大限に利用できるまでに時間を要するものとな
り、回線能力を有効利用できず、アプリケーション側か
ら見ると転送時間がかかるという問題点があった。本発
明はこのような課題を解決するためのものであり、回線
を有効利用して高スループットを実現でき、アプリケー
ション側から見た転送所要時間を短縮することができる
データフロー制御方法を提供することを目的としてい
る。

【００１４】

【課題を解決するための手段】このような目的を達成す
るために、本発明によるデータフロー制御方法は、ＯＳ
Ｉ参照モデル・レイヤ４のプロトコルヘッダに中継ノー
ドのバッファ負荷状態を示すバッファ負荷状態表示を設
けて、中継ノードは、パケット中継時に自己のバッファ
使用率が所定値に達していない場合にはバッファ負荷状
熊表示を「０」に設定し、バッファ使用率が所定値に達
している場合にはバッファ負荷状態表示を「１」に設定
し、送信側エンドノードは、レイヤ４プロトコル処理に
て、コネクション設定要求パケット送信後に受信側から
返送されるコネクション設定応答パケットのバッファ負
荷状態表示を確認し、バッファ負荷状態表示に「０」が
設定されている場合には、受信側の所定の受信ウィンド
ウサイズまで送信データパケット量を許可し、バッファ
負荷状熊表示に「１」が設定されている場合には、送信
データパケット量を少量から順次増加させるようにした
ものである。

【００１５】したがって、コネクション設定要求パケッ
ト送信後に受信側から返送されるコネクション設定応答
パケットのバッファ負荷状態表示に「０」が設定されて
いる場合には、送信側エンドノードにて、受信側の所定
の受信ウィンドウサイズまで送信データパケット量が許
可され、「１」が設定されている場合には、送信データ
パケット量が少量から順次増やされる。

【００１６】また、中継ノードは、パケット中継時に自
己のバッファ使用率が所定値に達していない場合にはバ
ッファ負荷状態表示を「０」に設定し、バッファ使用率
が所定値に達している場合にはバッファ負荷状態表示を
「１」に設定し、送信側エンドノードは、レイヤ４プロ
トコル処理にて、最初に１データパケット送信し、その
後に受信側から返送される確認応答パケットのバッファ
負荷状態表示を確認し、バッファ負荷状態表示に「０」
が設定されている場合には、受信側の所定の受信ウィン
ドウサイズまで送信データパケット量を許可し、バッフ
ァ負荷状態表示に「１」が設定されている場合には、送
信データパケット量を少量から順次増加させるようにし
たものである。したがって、最初に送信した１データパ
ケットに応じて受信側から返送される確認応答パケット
のバッファ負荷状態表示に「０」が設定されている場合
には、送信側エンドノードにて、受信側の所定の受信ウ
ィンドウサイズまで送信データパケット量が許可され、
「１」が設定されている場合には、送信データパケット
量が少量から順次増やされる。

【００１７】

【発明の実施の形態】次に、本発明について図面を参照
して説明する。図１は本発明の一実施の形態であるデー
タフロー制御方法によるデータ伝送システムのブロック
図である。同図において、１ａ，１ｂは通信回線３およ
び転送ノード２を介して所望のデータを送受信するエン
ドノードである。

【００１８】エンドノード１ａ，１ｂにおいて、１２は
レイヤ３以下のプロトコル処理を行う下位レイヤ処理部
であり、ここでは通信回線３との電気的整合性を提供す
るレイヤ１（ＯＳＩ参照モデル／物理層）、フレームの
組立／分解などを行うレイヤ２（ＯＳＩ参照モデル／デ
ータリンク層）、およびルーティングなどを行うレイヤ
３（ＯＳＩ参照モデル／ネットワーク層）の各レイヤの
プロトコル処理が行われる。

【００１９】１１は各種データ送受信処理に用いるバッ
ファ、１３はコネクションの設定解放やフロー制御など
に基づいたデータ送受信処理を行うレイヤ４処理部、１
４はユーザに対して各種データ通信サービスを提供する
アプリケーション処理部である。また中継ノード２にお
いて、２１は各種データ中継処理に用いるバッファ、２
２は前述の下位レイヤ処理部１２と同等に、レイヤ１〜
３のプロトコル処理を行う下位レイヤ処理部である。

【００２０】図２は、レイヤ４のヘッダ構成を示す説明
図であり、従来のヘッダ構成と比較して、中継ノード２
のバッファ２１の使用率を示すバッファ負荷状態表示
（Ｃｏｎｇ）が増設されている。このバッファ負荷表示
は、エンドノード１ａ（１ｂ）のレイヤ４処理部１３に
て、パケット送信時にＣｏｎｇ＝「０」に設定される。
また中継ノード２のバッファ２１の使用率が所定値に達
した場合に、その中継ノード２の下位レイヤ処理部２２
によりＣｏｎｇ＝「１」に設定され、それ以外はＣｏｎ
ｇ＝「０」に設定されるものとする。

【００２１】次に、図３を参照して、本発明の第１の実
施の形態によるデータフロー制御の処理動作を説明す
る。図３は本発明の第１の実施の形態によるデータフロ
ー制御の処理動作を示すフローチャートであり、以下、
エンドノード１ａから中継ノード２を介してエンドノー
ド１ｂにデータを送信する場合を例に説明する。

【００２２】ここでは受信側が受信可能容量として宣言
した受信ウィンドウサイズ（ａｄｗｎｄ）の他に、輻輳
ウィンドウサイズ（ｃｗｎｄ）およびスロースタートし
きい値（ｓｓｔｈｒｅｓｈ）というパラメータが設けら
れている。また、ある時点において送信可能なパケット
数は、ｍｉｎ（ｃｗｎｄ，ａｄｗｎｄ）（但し、ｍｉｎ
（Ａ，Ｂ）はＡまたはＢのいずれか小さい値を採ること
を示す）であり、各パラメータの変動に伴って通信中に
変化していくものとなっている。

【００２３】エンドノード１ａでは、アプリケーション
処理部１４からの通信要求に基づいて、レイヤ４処理部
１３により所定のコネクション設定要求パケットが送信
され（ステップ３０）、このコネクション設定要求パケ
ットに対するコネクション設定応答パケットの受信待ち
となる（ステップ３１）。コネクション設定要求パケッ
ト送信後から所定時間以内にコネクション設定応答パケ
ットが受信されなかった場合には（ステップ３１：設定
応答タイムアウト）、再送回数が所定の限界値以下の場
合にのみ（ステップ３２：ＹＥＳ）、ステップ３０に戻
ってコネクション設定要求パケットの再送を行い、再送
回数の限界値超過に応じて異常終了する（ステップ３
２：ＮＯ）。

【００２４】一方、正常時には、中継ノード２を介して
受信したコネクション設定要求パケットに応じて、受信
側エンドノード１ｂからコネクション設定応答パケット
が返送される。また、中継ノード２では、バッファ２１
の使用率が所定の限界値に達した場合にのみ、下位レイ
ヤ処理部２２によりコネクション設定応答パケットのＣ
ｏｎｇ＝「１」に設定し、それ以外にはＣｏｎｇ＝
「０」に設定する。

【００２５】したがって、コネクション設定要求パケッ
ト送信後から所定時間以内にコネクション設定応答パケ
ットが受信された場合には、その受信パケットのレイヤ
４ヘッダに格納されているバッファ負荷状態表示Ｃｏｎ
ｇの値をチェックし、Ｃｏｎｇ＝「０」の場合には（ス
テップ３１：設定応答受信／Ｃｏｎｇ＝０）、スロース
タートしきい値ｓｓｔｈｒｅｓｈ＝ａｄｗｎｄに初期設
定するとともに、輻輳ウィンドサイズｃｗｎｄ＝ｓｓｔ
ｈｒｅｓｈに初期設定する（ステップ３３）。これによ
り、データ送信開始時からｍｉｎ（ｃｗｎｄ，ａｄｗｎ
ｄ）により求められる個数の多量のパケットの連続送信
が許可される。

【００２６】一方、ステップ３１において、受信したコ
ネクション設定応答パケットがＣｏｎｇ＝「１」の場合
には（ステップ３１：設定応答受信／Ｃｏｎｇ＝１）、
ｓｓｔｈｒｅｓｈ＝ａｄｗｎｄに初期設定するととも
に、ｃｗｎｄ＝「１」に初期設定する（ステップ３
４）。これにより、前述（図８参照）と同様のスロース
タートフェーズの動作に入るものとなる。

【００２７】このようにしてｓｓｔｈｒｅｓｈおよびｃ
ｗｎｄを初期設定した後、これらパラメータに基づい
て、ｍｉｎ（ｃｗｎｄ，ａｄｗｎｄ）個のパケットを送
信し、これに対する確認応答の受信を待つ（ステップ３
５）。ここで、パケット送信後から所定時間内に確認応
答が受信された場合には、前述（ステップ３１）と同様
に、その受信パケットのレイヤ４ヘッダに格納されてい
るＣｏｎｇをチェックする。

【００２８】Ｃｏｎｇ＝「１」の場合には（ステップ３
５：確認応答受信／Ｃｏｎｇ＝１）、送信可能量を示す
ｃｗｎｄがしきい値ｓｓｔｈｒｅｓｈより小さいか否か
判断し（ステップ３６）、ｃｗｎｄがｓｓｔｈｒｅｓｈ
より小さい場合には（ステップ３６：ＹＥＳ）、ｃｗｎ
ｄを＋１し（ステップ３７Ｙ）、ステップ３５に戻って
次のパケットを送信する。これにより、送信可能量ｃｗ
ｎｄがしきい値ｓｓｔｈｒｅｓｈになるまではスロース
タートフェーズとして確認応答を受信するごとにｃｗｎ
ｄが１ずつ（１，２，３，４・・）増加する。

【００２９】一方、ステップ３６においてｃｗｎｄがｓ
ｓｔｈｒｅｓｈに達した場合には（ステップ３６：Ｎ
Ｏ）、輻輳回避フェーズに入り、ｃｗｎｄを１／ｃｗｎ
ｄだけ増やし（ステップ３７Ｎ）、ステップ３５に戻っ
て次のパケットを送信する。これにより、ｃｗｎｄがｓ
ｓｔｈｒｅｓｈに達した場合には、輻輳回避フェーズと
して確認応答を受信するごとにｃｗｎｄが１／ｃｗｎｄ
ずつ増加するものとなり、直前のパケット送信量である
ｃｗｎｄに対するすべての確認応答を受信すると、ｃｗ
ｎｄは１データパケットだけ増加するものとなり、スロ
ースタートフェーズに比較して穏やかな増加となる。

【００３０】また、ステップ３５において、パケット送
信後から所定時間内に受信された確認応答がＣｏｎｇ＝
「０」の場合には（ステップ３５：確認応答受信／Ｃｏ
ｎｇ＝０）、ｃｗｎｄ＝ａｄｗｎｄを設定して（ステッ
プ３８）、ステップ３５に戻って次のパケットを送信す
る。これにより、次回のデータ送信時から受信ウィンド
ウサイズに等しい個数の多量のパケットの連続送信が許
可される。

【００３１】また、ステップ３５において、パケット送
信後から所定時間内に確認応答が受信されなかった場合
には（ステップ３５：確認応答タイムアウト）、輻輳に
よりパケット紛失が発生したと見なして、ｓｓｔｈｒｅ
ｓｈをｍｉｎ（ｃｗｎｄ，ａｄｗｎｄ）／２に設定する
とともに、ｃｗｎｄを「１」に設定し（ステップ３
９）、ステップ３５に戻って次のパケットを送信する。

【００３２】次に、図４を参照して、本発明の第２の実
施の形態について説明する。図４は本発明の第２の実施
の形態によるデータフロー制御の処理動作を示すフロー
チャートであり、特に予め決定されている通信相手と、
常時、データ通信を行う場合、すなわちコネクション設
定および解放手順が不要なＰＶＣ（パーマネントバーチ
ャルチャネルコール）接続の場合を例に説明する。

【００３３】まず、発信側エンドノード１ａのレイヤ４
処理部１３は、スロースタートしきい値ｓｓｔｈｒｅｓ
ｈ＝ａｄｗｎｄに初期設定するとともに、輻輳ウィンド
サイズｃｗｎｄ＝「１」に初期設定する（ステップ４
０）。続いて、アプリケーション処理部１４からのデー
タ送信要求に応じて、１個のデータパケットの送信を下
位レイヤ処理部１２へ依頼し、受信側エンドノード１ｂ
からの確認応答の受信を待つ（ステップ４１）。

【００３４】データパケット送信後から所定時間内に確
認応答パケットが受信された場合には、その確認応答パ
ケットのレイヤ４ヘッダのバッファ負荷状態表示Ｃｏｎ
ｇをチェックし、Ｃｏｎｇ＝「０」の場合には（ステッ
プ４１：確認応答受信／Ｃｏｎｇ＝０）、ｃｗｎｄ＝ｓ
ｓｔｈｒｅｓｈとする。これにより、次回のデータ送信
時からｍｉｎ（ｃｗｎｄ，ａｄｗｎｄ）により求められ
る個数の多量のパケットの連続送信が許可され、前述
（図３のステップ３５）のパケット送信処理に移行す
る。

【００３５】一方、ステップ４１において、受信された
確認応答パケットがＣｏｎｇ＝「１」の場合には（ステ
ップ４１：確認応答受信／Ｃｏｎｇ＝１）、前述（図３
のステップ３６，３７Ｙ，３７Ｎ）の説明と同様のスロ
ースタートフェーズの動作に入るものとなり、以降、Ｃ
ｏｎｇ＝「１」の確認応答を受信するごとにｃｗｎｄが
１ずつ増加するものとなる。

【００３６】またステップ４１において、データパケッ
ト送信後から所定時間内に確認応答パケットが受信され
なかった場合には（ステップ４１：確認応答タイムアウ
ト）、ｃｗｎｄ＝「１」のまま、前述（図３のステップ
３５）のパケット送信処理に移行する。これ以降の処理
は、前述（図３のステップ３５〜３９）と同様であり、
ここでは省略する。

【００３７】このように、レイヤ４のプロトコルヘッダ
に中継ノード２のバッファ２１の負荷状態を表示するバ
ッファ負荷状態表示を設けて、中継ノード２にてバッフ
ァ２１の負荷状態に応じてこのバッファ負荷状態表示を
設定するとともに、送信側エンドノード１ａにてバッフ
ァ負荷状態表示を確認し、中継ノード２のバッファ２１
の負荷状態に応じて送信データパケット量を決定するよ
うにしたので、データ伝送時間と伝搬遅延時間との大小
関係が逆転するような場合でも、回線を有効利用して高
スループットを実現でき、アプリケーション側から見た
転送所要時間を短縮することができる。

【００３８】図５は送信データパケット量の変化を示す
説明図であり、（ａ）はＣｏｎｇ＝「０」の確認応答受
信に応じて、一度に送信データパケット量が増加した場
合（ステップ３８）、（ｂ）はＣｏｎｇ＝「１」の確認
応答受信に応じて、１個ずつ送信パケットが増加した場
合（ステップ３７Ｙ：従来のスロースタートフェーズと
同等）を示している。これにより、中継ノード２のバッ
ファ２１の負荷状態が小さい場合には、Ｃｏｎｇ＝０に
応じて送信可能量ｃｗｎｄが一度に増えることがわか
る。

【００３９】また、累積転送情報量と経過時間との関係
は、図６に示すように、本発明によれば、最初に送信し
たデータパケットに対する確認応答パケットがＣｏｎｇ
＝「０」であった場合、その次の送信可能量ｃｗｎｄが
受信側受信可能量ａｄｗｎｄに設定されることから、こ
れ以降は回線能力を有効利用できるのに対して、従来の
スロースタートフェーズ動作では、送信可能量ｃｗｎｄ
が徐々に増加し、途中に送信休止状態が入るため、回線
能力を有効利用できない。

【００４０】したがって、所定のデータ量Ｄｆを転送す
る場合、従来の方法では時間Ｔｆｏだけ要するのに対し
て本発明では時間Ｔｆｎに短縮される。さらに、一例と
して、回線速度が２．４Ｇｂｐｓ、中継ノードが１つ、
転送データ量が１０ＭＢ、パケット長が８ＫＢ、ノード
におけるパケット処理時間が１データパケット伝送時間
にほぼ等しいものとした場合、回線利用率Ｒｆおよび転
送所要時間Ｔｆは、それぞれ通信距離Ｌに対して図７
（ａ）および（ｂ）に示すように変化する。

【００４１】これは、通信距離Ｌの増加に伴ってデータ
伝送時間より伝送遅延時間の割合が増加することから、
従来の方法によればデータ送信後の確認応答待ち状態、
すなわち回線空き状態が相対的に大きくなり、回線利用
率Ｒｆおよび転送所要時間Ｔｆを大幅に悪化させるのに
対して、本発明ではデータ送信後の確認応答待ち状態が
相対的に小さいため、通信距離Ｌが増加しても回線利用
率Ｒｆおよび転送所要時間Ｔｆの悪化が抑制される。し
たがって、例えば、東京−大阪間（通信距離Ｌ＝６００
Ｋｍ）では、本発明によれば従来に比較して回線利用率
では１．８倍向上するとともに、転送所要時間Ｔｆでは
約１／２に短縮できることがわかる。

【００４２】

【発明の効果】以上説明したように、本発明は、ＯＳＩ
参照モデル・レイヤ４のプロトコルヘッダに中継ノード
のバッファ負荷状態を示すバッファ負荷状態表示を設け
て、中継ノードにより、パケット中継時に自己のバッフ
ァ使用率が所定値に達していない場合にはバッファ負荷
状態表示を「０」に設定し、バッファ使用率が所定値に
達している場合にはバッファ負荷状熊表示を「１」に設
定し、送信側エンドノードのレイヤ４プロトコル処理に
て、コネクション設定要求パケット送信後に受信側から
返送されるコネクション設定応答パケットのバッファ負
荷状態表示に「０」が設定されている場合には、受信側
の所定の受信ウィンドウサイズまで送信データパケット
量を許可し、「１」が設定されている場合には、送信デ
ータパケット量を少量から順次増加させるようにしたも
のである。

【００４３】したがって、データ伝送時間と伝搬遅延時
間との大小関係が逆転するような場合でも、回線を有効
利用して高スループットを実現でき、アプリケーション
側から見た転送所要時間を短縮することができる。 ま
た、通信開始時にコネクションの設定が必要な場合に
は、そのコネクション設定に用いるパケットにてバッフ
ァ負荷状態を把握して速やかにデータパケット送信量を
決定することができ、データパケット送信開始時からバ
ッファ負荷状態に応じた量のデータパケットを送信する
ことが可能となる。

【００４４】また、送信側エンドノードのレイヤ４プロ
トコル処理にて、最初に１データパケット送信し、その
後に受信側から返送される確認応答パケットのバッファ
負荷状態表示を確認し、バッファ負荷状態表示に「０」
が設定されている場合には、受信側の所定の受信ウィン
ドウサイズまで送信データパケット量を許可し、バッフ
ァ負荷状態表示に「１」が設定されている場合には、送
信データパケット量を少量から順次増加させるようにし
たので、通信開始時にコネクションの設定が必要でない
場合には、データパケット送信開始時から最短の時間で
速やかにデータパケット送信量を決定することがで
き、、バッファ負荷状態に応じた量のデータパケットを
送信することが可能となる。

【図面の簡単な説明】

【図１】 本発明の一実施の形態によるデータフロー制
御方法によるデータ伝送システムのブロック図である。

【図２】 レイヤ４のプロトコルヘッダを示す構成図で
ある。

【図３】 本発明の第１の実施の形態によるデータフロ
ー制御動作を示すフローチャートである。

【図４】 本発明の第２の実施の形態によるデータフロ
ー制御動作を示すフローチャートである。

【図５】 送信データパケット量の変化を示す説明図で
ある。

【図６】 累積転送情報量と経過時間との関係を示す説
明図である。

【図７】 通信距離と回線利用率および転送所要時間と
の関係を示す説明図である。

【図８】 従来のデータフロー制御動作を示すフローチ
ャートである。

【図９】 データ転送所要時間ＲＴＴを示す説明図であ
る。

【符号の説明】

１ａ，１ｂ…エンドノード、１１…バッファ、１２…下
位レイヤ処理部、１３…レイヤ４処理部、１４…アプリ
ケーション処理部、２…中継ノード、２１…バッファ、
２２…下位レイヤ処理部、３…通信回線。

───────────────────────────────────────────────────── フロントページの続き (56)参考文献 特開 昭63−24742（ＪＰ，Ａ) 特開 平８−251226（ＪＰ，Ａ) 特開 平３−283940（ＪＰ，Ａ) 特開 平３−45051（ＪＰ，Ａ) 特開 平２−14645（ＪＰ，Ａ) 特開 平２−16840（ＪＰ，Ａ) 特開 昭62−85532（ＪＰ，Ａ) (58)調査した分野(Int.Cl.⁶，ＤＢ名) H04L 12/56 H04L 12/28

Claims (2)

(57)【特許請求の範囲】
1. 【請求項１】 中継ノードおよび通信回線を介して接続
   されたエンドノード間にて所定の通信プロトコル処理を
   実行することにより、データパケットを用いて所望のデ
   ータ伝送を行う場合のデータフロー制御方法において、 ＯＳＩ参照モデル・レイヤ４のプロトコルヘッダに中継
   ノードのバッファ負荷状態を示すバッファ負荷状態表示
   を設けて、 中継ノードは、パケット中継時に自己のバッファ使用率
   が所定値に達していない場合にはバッファ負荷状態表示
   を「０」に設定し、前記バッファ使用率が所定値に達し
   ている場合にはバッファ負荷状態表示を「１」に設定
   し、 送信側エンドノードは、レイヤ４プロトコル処理にて、
   コネクション設定要求パケット送信後に受信側から返送
   されるコネクション設定応答パケットのバッファ負荷状
   態表示を確認し、前記バッファ負荷状態表示に「０」が
   設定されている場合には、受信側の所定の受信ウィンド
   ウサイズまで送信データパケット量を許可し、前記バッ
   ファ負荷状態表示に「１」が設定されている場合には、
   送信データパケット量を少量から順次増加させるように
   したことを特徴とするデータフロー制御方法。
2. 【請求項２】 請求項１記載のデータフロー制御方法に
   おいて、 中継ノードは、パケット中継時に自己のバッファ使用率
   が所定値に達していない場合にはバッファ負荷状態表示
   を「０」に設定し、前記バッファ使用率が所定値に達し
   ている場合にはバッファ負荷状熊表示を「１」に設定
   し、 送信側エンドノードは、レイヤ４プロトコル処理にて、
   最初に１データパケット送信し、その後に受信側から返
   送される確認応答パケットのバッファ負荷状熊表示を確
   認し、前記バッファ負荷状態表示に「０」が設定されて
   いる場合には、受信側の所定の受信ウィンドウサイズま
   で送信データパケット量を許可し、前記バッファ負荷状
   態表示に「１」が設定されている場合には、送信データ
   パケット量を少量から順次増加させるようにしたことを
   特徴とするデータフロー制御方法。