JP4738594B2 - データフロー制御方法および装置 - Google Patents

Description

【０００１】
［技術的背景］
本発明はパケット交換接続におけるデータフロー制御方法および装置に関する。
【０００２】
いわゆるインターネットはいくつかの異なるサービスレイヤを含む通信網である。最下位レイヤはハードウェアレイヤであり、その上にさまざまな機能のソフトウェアレイヤが付加される。例として、いわゆるｗｏｒｌｄ ｗｉｄｅ ｗｅｂ（ＷＷＷ）はいわゆるインターネットプロトコル（ＩＰ）により提供されるベーシックインターネットレイヤの上のレイヤである。
【０００３】
インターネットはパケット交換網であり、情報の基本的構造はインターネットプロトコルＩＰにより決定される。プロトコルは所期の通信において２つのパートナーが通信できるようにするために従わなければならない１組のルールである。インターネットプロトコルＩＰはアドレス指定を調整する、すなわち２つの通信点間のルーターが宛先へデータパケットを送れることを保証する。ＩＰパケットは送られるデータに関する情報を含むヘッダー、およびデータ自体を含む本体からなっている。
【０００４】
通信の両端間で信頼度の高いデータ伝送を容易にするために、さらに伝送制御プロトコル（ＴＣＰ）が設けられる。ＴＣＰは送られる情報を取り込んで所与のセグメント内へ分割する。各セグメントが番号を受信し、所与のセグメントの受信を受信者が通知することができ受信者は情報を正しい順序に配列できるようにされる。ＴＣＰはこのプロトコルにより使用されるそれ自体の情報を運ぶそれ自体のヘッダーを有する。ＴＣＰパケットはＩＰパケット内に配置される、すなわち（下層）ＩＰパケット内にカプセル化される、ことによりインターネットを介して送られる。インターネット両端間でのパケットの移送がしばしばＴＣＰ／ＩＰと呼ばれるのはそのためである。
【０００５】
それぞれ１番から８番の同じサイズの８つのデータセグメントへ分割されるデータの本体１００を図２に示す。例として、本体１００は８１９２バイトのサイズを有し、各データセグメントは１０２４バイトを含むようにすることができる。実際に送る必要がある情報は通常７１６８バイトと前記した８１９２バイトの間であり、最後のデータセグメント８は単にいわゆるパディングで埋められて等サイズデータセグメントが達成されることをお判り願いたい。単一データセグメントの精密なサイズは１０２４バイトの前記選択例には固定されず所与の制約、例えば特定のリンクにより許容される最大伝送単位（ＭＴＵ）、にしたがって送信システムにより適切に選択される。
【０００６】
ＴＣＰがデータセグメントのフローを制御する方法は“スライディングウィンドウズ”法である。その概念は例えばダブリュ.アール.スチーブンスの著書“ＴＣＰ／ＩＰ Ｉｌｌｕｓｔｒａｔｅｄ”,Ｖｏｌｕｍｅ １，Ａｄｄｉｓｏｎ Ｗｅｓｌｅｙ，１９９４，第２０章および第２１章に記載されている。
【０００７】
“ウィンドウ”という用語はバイトの量、より一般的にはデータ単位で表わされるデータ量、を示す。ＴＣＰに従って、受信者は通信を開始する発信者からのパケットに応答していわゆる“公示された”（ａｄｖｅｒｔｉｓｅｄ）すなわち提供されたウィンドウを発信者へ送る。ＴＣＰ発信者は公示されたウィンドウにより定義される量よりも多くの受信通知されない未決定パケットを有することを許されない。受信者は公示されたウィンドウを各受信通知メッセージもしくはパケット内で送信することをお判り願いたい。
【０００８】
公示されたウィンドウは通常受信者側の入力バァッファ容量に対応する。したがって、公示されたウィンドウの機能は高速発信者が低速受信者の入力バァッファをオーバフローさせてしまうのを防止することである。
【０００９】
次に、図２に示すデータ量１００の送信例を示す図３および図４、およびスライディングウィンドウ制御の原理を示す図５および図６についてスライディングウィンドウ制御機構の説明を行う。
【００１０】
図２に示すデータの８セグメントの送信例を図３に示し、発信者は左側に示され受信者は右側に示されている。各矢符はパケットの送信を示し、後述するように、二重線矢符はデータセグメントを含むパケットに対応する。個別パケットの送信は参照符号Ｓ１−Ｓ２０で示され、どちら側からの送信行為もセグメントと呼ばれる。それは一般的に図２のデータを含む１つのパケットは１つのデータセグメントを含むことを示している。時間の方向は頂部から底部へ向かう。
【００１１】
図３に示すシーケンスはフロー制御を説明するために単純化されており、したがって全てのパケットに参照符号があるわけではなく、通信の他のアスペクトに関連するものもあることをお判り願いたい。また、参照符号のあるセグメントのいくつかはさらにデータを運ぶが、この補足データもフロー制御以外の通信の他のアスペクトに関連するため、ここには例示しない。Ｘ：Ｙ（Ｚ）の表示はＸ番からＹ番バイトが送られ、合計Ｚとなることを意味する。ＡｃｋＸはＸ番までのバイトの受信が通知されることを意味し、ＷｉｎＸはＸバイトのウィンドウが公示されることを意味する。
【００１２】
発信者および受信者間のセグメントＳ１−Ｓ３は通信の確立に関連しており、受信者はセグメントＳ２内に４０９６バイトのウィンドウをアナウンスすること以外は説明を行わない。セグメントＳ４からＳ７において発信者は最初の３つのデータセグメント１−３、すなわち１−１０２５，１０２５−２０４９および２０４９−３０７３バイトを送信する。受信者はＳ７において２０４９までのバイトの受信を通知し、Ｓ７は４０９６のウィンドウを再度公示する。受信者がなぜ３０７３まで通知しないかということはフロー制御の説明にとって重要ではない。例えば、このデータセグメントは受信側の処理で遅延されることがある。セグメントＳ８において受信者は３０７３までを受信通知し３０７３のウィンドウを公示する。ここでも、その理由はフロー制御の説明にとって重要ではない。例えば、受信者の入力バァッファをさらに遅延され、縮小したウィンドウがオーバフローを防止するようにすることができる。セグメントＳ９において発信者はもう１つのデータセグメント、すなわち３０７３から４０９７バイト、を送信する。それらはセグメントＳ１０において受信通知され、再度４０９６のウィンドウが公示される。次に、発信者はセグメントＳ１１からＳ１３において３つのデータセグメント、すなわち４０９７−５１２１，５１２１−６１４５および６１４５−７１６９を送信する。セグメントＳ１４において、受信者は６１４５バイトまでしか受信通知しないが、４０９６のウィンドウを公示し続ける。セグメントＳ１５において、発信者は７１９６−８１９３バイトからなる最終データセグメントを送信し、受信者はセグメントＳ１６において８１９３までの全バイト受信を通知する。残りの交換Ｓ１７からＳ２０まではフロー制御に無関係である。
【００１３】
図からお判りのように、各データセグメントが個別に受信通知される必要はなく、受信者は１つの受信通知メッセージにより所与のセグメントまでのいくつかのデータセグメントの受信を通知することもできる。
【００１４】
図５にスライディングウィンドウベースフロー制御の原理を示す。１番から１１番はデータセグメントに関連しており、例えば、それらは図２に示すデータセグメントもしくは単に所与数のバイトとすることができる。ウィンドウベースフロー制御の説明に関して、重要なのはウィンドウ２００がある量のデータをカバーし、左縁２０１と右縁２０２間の制御ウィンドウがデータセグメント４から９をカバーするということだけである。図５の例では、制御ウィンドウは公示されたウィンドウである。（もう１種の制御ウィンドウについては後述する。）ウィンドウ２００の左縁の位置は既に送信され（発信者により）受信通知されている（受信者により）データセグメントの数により決定される。図５において、それはデータセグメント１から３が送信され受信通知されていることを意味する。
【００１５】
一連のセグメントの例に関してデータフローが説明されているが、ＴＣＰはストリームオリエンテッドプロトコルであり、シーケンスベースはバイトに関するようにされることをお判り願いたい。したがって、受信者からの受信通知メッセージは受信セグメントを表示せず、むしろシーケンスデータのどのバイトまでデータが受信されているかを示す。
【００１６】
発信者は全体ウィンドウサイズと送信されてはいるがまだ受信通知されていないデータ量との差として使用可能なウィンドウ、すなわち送信できるデータ量、を計算する。図５では、分割２０３から右縁２０２までの使用可能なウィンドウがデータセグメント７から９をカバーする。したがって、これらのデータは送信することができる。右縁２０２を越えるデータセグメント、すなわち１０，１１等、はウィンドウが移動してそれらをカバーするまで送信することができない。次に、ウィンドウの移動について説明する。
【００１７】
図６はウィンドウの時間調節の原理を示す。受信者がデータを受信通知する時に、ウィンドウは時間をかけて右へ移動する。２つの縁２０１，２０２の相対移動によりウィンドウのサイズが増減する。この移動を説明するために従来３つの異なる用語が使用されており、それは左縁２０１が右へ移動するとウィンドウが閉じる、右縁２０２が右へ移動するとウィンドウが開く、および右縁２０２が左へ移動するとウィンドウが閉じるである。縁２０１，２０２の移動はどれだけのデータが送信され受信通知されているかに従った左縁２０１の位置、および右縁２０２を決定する所与の左縁２０１から始まる公示されたウィンドウサイズにより支配される。左縁は左へは移動せず、左縁を左へ移動させることを意味する受信通知（ＡＣＫ）が受信されておれば、それは重複ＡＣＫであり捨てられることがお判りであろう。
【００１８】
左縁２０１が右縁２０２に達する結果生じるウィンドウ２００はゼロウィンドウと呼ばれる。それは発信者が任意のデータを送信するのを停止させる。
【００１９】
フロー制御の前記した原理を図４に示し、それは図３に示す例に対するスライディングウィンドウフロー制御を説明するものである。図の頂部に図２のデータセグメントを示しその下のバーおよび矢符は、発信者によるデータの送信および受信者による受信通知に応答した、フロー制御ウィンドウの移動および時間変化を表わしかつ例示している。図からお判りのように、発信者はデータの全ウィンドウの量を送信する必要はない。受信者からの各受信通知によりウィンドウは右へスライドされる。セグメントＳ７からＳ８への変化で示すようにウィンドウのサイズは減少することがあるが、ウィンドウの右縁は左方へ移動してはならない。また、受信者はＡＣＫを送信する前にウィンドウが埋まるのを待つ必要がない。
【００２０】
前記説明では、フロー制御を決定したウィンドウはウィンドウから公示されたすなわち提供されたウィンドウであった。すなわち、公示されたウィンドウはそれにより受信者がフロー制御に影響を与える手段であり、それ自体が当然発信者により実施される。前記したように、受信者は公示されたウィンドウを使用してその入力バァッファのオーバフローを防止する。したがって、通常は公示されたウィンドウのサイズは受信プロセスにより制御される。
【００２１】
高速発信者が低速受信者にオーバフローをきたす問題の他に、ネットワーク上で競合が生じることがあるという問題が存在する。それは接続の受信端ではなく送受信端間で生じる問題である。よく知られているように、インターネット上の典型的な接続は、ルーターとして作動する、他の部材を介して確立されこれらのルーターは広範に変動するタイプのハードウェアにより接続されることがあり、ルーター間のこのような接続は一般的にリンクと呼ばれる。すなわち、発信者から受信者へのパケットは受信端に到達するまでルーターによりリンクを介して他のルーターへ案内される。競合は所与のリンクがそれを介して送信されるデータ量を処理するのに十分な大きさではない（十分な送信容量がない）場合に生じる結果である。それは例えば大容量を有するリンク（“ビッグパイプ”、例えば高速ＬＡＮ）上にデータが到達し低容量を有するリンク（“スモールパイプ”、例えば低速ＷＡＮ）上に出て行く時、あるいは出力容量が入力の和よりも小さいルーターに多数の入力ストリームが到達する時に生じることがある。
【００２２】
図７に競合の例を示す。この図では、図２に示したものと同じデータセグメントを含みしたがって１から８の番号を運ぶパケットが大きい送信容量を有するリンク３００を介してルーターＲ１に到達する。Ｒ１がパケットをルーティングするリンク３０１はリンク３００よりも小さい。パケットはハッチングした領域で表わされ、この領域はパケットサイズに対応することをお判り願いたい。それはリンク３０１に示すパケット３もしくは４の領域がリンク３００内のパケット５もしくは６、あるいはリンク３０２内のパケット１もしくは２の領域に等しいことを意味する。図からお判りのように、Ｒ１はリンク３００に到達する時の速さでリンク３０１内へパケットを送信することができないため、“ボトルネック”として作動する。やはり図からお判りのように、ルーターＲ２は低容量リンク３０１から到達するのと同じ速さでしかパケットをリンク３０２へ入れることができない。したがって、最低容量のリンクがパケットの間隔を決定する。
【００２３】
図７の例では、受信者は８セグメントに対応するサイズを有するウィンドウを公示しており、発信者はリンク３００が受け取れる速さで８つ全部を送信したものと仮定していることをお判り願いたい。また、ルーターＲ１は着信パケットを送信できるまで格納するための十分大きいバァッファを有するものと仮定している。しかしながら、後者の仮定は満たされない場合が多く、競合によりパケットが廃棄されることがあり、それはパケットを再送信する必要があることを意味する、すなわち送信は不利にされる。
【００２４】
競合を配慮するために、ＴＣＰ内のデータフロー制御は前記した公示されたウィンドウに従うだけでなく、いわゆる競合ウィンドウにも従って実施される。競合ウィンドウはスロースタートと呼ばれるルーチンにより次のように使用される。新しい接続が確立されると、競合ウィンドウはデータの１セグメントへ初期化される。発信者により受信通知が受信されるたびに、競合は１セグメントだけ増加される。前記したスライディングウィンドウ制御（図５および図６参照）は公示されたウィンドウもしくは競合ウィンドウのどちらか小さい方で実施される。すなわち、競合ウィンドウが公示されたウィンドウよりも小さい場合には、図５に示す制御ウィンドウ２００は競合ウィンドウであって公示されたウィンドウではない。制御ウィンドウの左縁位置を決定するプロセスが図４、図５および図６に関して前記したとおりに実施されるが、右縁位置は公示されたウィンドウと競合ウィンドウの最小値により決定される。
【００２５】
公示されたウィンドウは受信者により決定され、競合ウィンドウは発信者により決定される。したがって、競合ウィンドウは発信者により課せられるフロー制御であり、公示されたウィンドウは受信者により課せられるフロー制御である。前者は知覚されたネットワーク競合の発信者の評価であり、後者は受信者において利用可能なバァッファスペース量に関連している。
【００２６】
［発明の根本にかかわる問題］
前記したようにスロースタートおよび競合ウィンドウを使用してスライディングウィンドウズフロー制御が実施される場合、発信者は１つのセグメントすなわちパケットを送信し対応する受信通知ＡＣＫを待機することにより開始する。そのＡＣＫが受信されると、競合ウィンドウは１から２へ増分され、２セグメントを送ることができる。一般的に、各受信ＡＣＫによりウィンドウは１だけ増加する。したがって、これら２つのセグメントの各々が受信通知されると、競合ウィンドウはたとえば４に増加する。それにより指数関数的増加となる。指数関数的増加は純粋な時間に関するものではなく、いわゆるラウンドトリップ時間ＲＴＴに関するものであることをお判り願いたい。ＲＴＴは所与のバイトの送信と対応する受信通知メッセージの受信との間で経過する時間である。この指数関数的増加により、図７に関して説明したように、競合ウィンドウのサイズは公示されたウィンドウよりはまだ小さいが競合に到る値へ迅速に達することができる。
【００２７】
典型的に競合によりパケット損失を生じ、それは通信において生じる時間切れ（パケットが送信される時に、時間切れクロックが動作開始し、予め設定された期間内に受信通知が受信されない場合には、時間切れが発せられる）もしくは受信される重複ＡＣＫにより認知することができる。
【００２８】
この問題に対処するために、競合回避方法が提案され、それは例えばダフリュー．アール．スチーブンスの前記した書籍の第２１．６章に記載されている。通常は前記したスロースタート方法と一緒に実現されるこの方法に従って、競合ウィンドウ値およびスロースタート閾値が維持される。最初に競合ウィンドウは１セグメントにセットされ閾値は許容最大ウィンドウサイズ（典型的には、６５５３５バイト）にセットされる。制御ウィンドウは公示されたウィンドウと競合ウィンドウの最小値として選択される。競合が生じそれが時間切れの発生により認知されると、現在の制御ウィンドウの半分が閾値として格納され競合ウィンドウは１セグメントにセットされる。時間切れはパケットの送信以来経過する時間をそれに従ってタイマが測定する機能であり、所定期間内に受信通知が受信されなければ時間切れ警告が発せられる。次に、制御ウィンドウサイズが閾値に達するまでスロースタート方法が利用され（ウィンドウサイズの指数関数的増加と共に）、その後競合回避方法が開始され、それは競合ウィンドウがその逆数により増分されることを指示し、競合ウィンドウのサイズは線形増加するようになる。
【００２９】
競合のもう１つの表示は重複受信通知の受信であり、その後で競合ウィンドウは現在の制御ウィンドウの半分にセットされ競合回避方法が使用される。時間切れおよび重複受信通知、およびそれに対する反応はＴＣＰに関してよく知られているため、これ以上説明する必要はない。
【００３０】
この結果、ＴＣＰにより実施される基本的フロー制御は発信者によるプロービングをより多くの帯域幅に対して一定とするのに役立つ。帯域幅はデータ送信レートとして定義される、すなわち単位時間当たりデータ、例えばビット／秒、の単位で与えられる。この帯域幅に対する一定プロービングは、たとえある点以降は競合ウィンドウを線形に増加させてしまう前記した競合回避方法に従ってなされる場合であっても、受信者が十分大きなウィンドウを公示する限り、それでも競合が生じるという効果を有する。
【００３１】
この問題はＴＣＰに限定されず、スライディングウィンドウフロー制御を利用するいかなるシステムでも生じることをお判り願いたい。
ＥＰ−０４５４３６４Ａ２には 2 つのウィンドウを有する高速トランスポートプロトコルが示されている。このプロトコルは情報量を制御する 2 つのウィンドウを含み、第１のウィンドウはネットワークウィンドウと呼ばれネットワーク内のデータを制限してネットワークバァッファリソースが経済的サイズとされしかもネットワークを介して送信されるパケット数に過剰な損失がないようにするのに使用され、第２のウィンドウは受信者フロー制御ウィンドウと呼ばれ典型的には第１のウィンドウよりも大きい。第２のウィンドウはパケットが受信者においてドロップすなわち消失されないことを保証するのに使用される。この文献は典型的に第１のウィンドウが、ラウンドトリップ遅延と発信者および受信者を相互接続するネットワークの帯域幅値との積として定義される、いわゆる帯域幅遅延積にセットされると述べている。帯域幅遅延積という用語は受信通知されないデータの量と同義語である。
ＥＰ−０６９３８４０Ａ１からホップバイホップフロー制御を使用するシステムが知られており、ソース端局が確立された接続を介してディスティネーション端局へ規則正しく制御セルを送出し、制御セルは個別の伝送速度を示すスタンプされた速度フィールドを有する。周期的更新プロセスにおいて、ソース端局とディスティネーション端局間の接続に沿ったスイッチの各々が接続に対する利用可能な帯域幅を計算する。各制御セル内のスタンプされた速度フィールド内の値が現在利用可能な帯域幅割当てと比較され、所与のスイッチ内の現在利用可能な帯域幅割当てが現在フィールド内に存在する値よりも小さければスタンプされた速度フィールド内に書き込まれる。次に、制御セルリターンプロセスが実行され、ソース端局において戻された制御セルが許容伝送速度の更新をトリガーし、許容伝送速度は個別伝送速度の 1 つに等しくされる。したがって、この文献は速度制御方法について記載している。
Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ １９９６ ＩＥＥＥ Ｆｉｆｔｅｅｎｔｈ Ａｎｎｕａｌ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｐｈｏｅｎｉｘ Ｃｏｎ ｆｅｒｅｎｃｅ ｏｎ Ｃｏｍｐｕｔｅｒｓ ａｎｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ，Ｓｃｏｔｔｓｄａｌｅ，Ｍａｒｃｈ ２７−２９，１９９６，ｎｏ．Ｃｏｎｆ．１５，Ｍａｒｃｈ ２７，１９９６，第２３９−２４５頁（ＸＰ０００５９４７９５）のミローチェバ，アイ，等の論文“Ｐｒｏｔｏｃｏｌ Ｍｅｃｊｈａｎｉｓｍｓ ｆｏｒ Ｒｅｌｉａｂｌｅ Ｔｒａｎｓｍｉｓｓｉｏｎ ａｎｄ Ｆｌｏｗ Ｃｏｎｔｒｏｌ ｏｎ Ｍｕｌｔｉｍｅｄｉａ Ｈｉｇｈｗａｙｓ”にはＴＣＰにおけるスロースタートおよび競合回避等のあるルーチンおよび技術が記載されている。
【００３２】
［発明の目的］
前記した問題点を克服し改善されたフロー制御方法および装置を提供することが本発明の目的である。
【００３３】
［発明の概要］
この目的は独立項に記載された方法および装置により解決される。有利な実施例が独立項に記載されている。
【００３４】
本発明に従って、ある量のデータが送信される接続におけるフロー制御は前記接続上の情報、すなわち前記接続を形成するリンクに関連する１つ以上の帯域幅値、を直接利用する。このようにして、フロー制御はネットワーク上の状況に直接適応させることができる。
【００３５】
好ましくは、データ送信中に帯域幅値は一度だけでなく数回決定され、帯域幅値が更新されてフロー制御が接続に沿った状況にダイナミックに適応されるようにされる。
【００３６】
本発明の好ましい実施例に従って、スライディングウィンドウフロー制御が使用されるシステムにおいて、ウィンドウサイズが前記帯域幅に依存して計算され、前記ウィンドウサイズは前記スライディングウィンドウフロー制御において制御ウィンドウを決定するプロセスで利用される。
【００３７】
制御ウィンドウを決定するプロセスで前記ウィンドウサイズを利用することは、例えば、ウィンドウが制御ウィンドウのサイズとして直接使用される、あるいは利用できる他のウィンドウサイズ値（例えば、ＴＣＰから知られる競合ウィンドウサイズおよび公示されたウィンドウサイズ）と比較され制御ウィンドウサイズはこの比較から決定される、例えば利用できる最小ウィンドウサイズが選択される、ことを意味する。
【００３８】
ウィンドウを前記したように定義することの基本的な効果は、やはりボトルネックウィンドウと呼ばれる、この新しいウィンドウが接続における１つのリンクがパケット送信に対してボトルネックとなりかねないことを考慮することであり、スライディングウィンドウフロー制御中にボトルネックウィンドウを考慮することにより前記ボトルネックウィンドウを決定するのにその帯域幅が考慮される前記リンクの１つにおける競合を最小限に抑えることができる。
【００３９】
もう１つの好ましい実施例では、考慮中の各リンクに対する各帯域幅値を得、前記複数の帯域幅値の最小値を求め、所与のバイトを送信してからそれが前記接続の他端で受信されているという受信通知が受信されるまでの間に経過する時間量を特徴づける時間値を求め、時間値と最小帯域幅値の積をボトルネックウィンドウとして計算することによりボトルネックウィンドウが求められる。
【００４０】
好ましくは、前記時間値はパケットが送信される方向における所与のパケット交換接続に対するラウンドトリップ時間値である。
【００４１】
もう１つの好ましい実施例では、リンクに関連する帯域幅値は前記リンクの物理的帯域幅、すなわち所与の時点において前記リンクを介して送信することができるデータの総量である。もう１つの好ましい実施例では、リンクに関連する帯域幅値は前記リンクにおいてパケット交換接続に利用できる実際の帯域幅値である。後の実施例は２つ以上の接続がリンクを介して行われることがあることを考慮している。
【００４２】
さらにもう１つの好ましい実施例では、１つの帯域幅値すなわちアクセスリンクの利用できる帯域幅しか考慮されない。アクセスリンクはパケット交換接続の終端における装置とパケット交換接続に沿った次のルーター間のリンクである。この実施例によりボトルネックリンクはアクセスリンクの帯域幅に基づいて定義され、前記アクセスリンクにおける競合の可能性を低減できるようにされる。測定されるアクセスリンクは接続において発信者として作動する装置、もしくは受信者として作動する装置とすることができる。
【００４３】
好ましくは、この実施例はアクセスリンクの帯域幅がそれを介してリンクレイヤを制御するコンポーネントにより与えられるようにされている。例として、パケット交換接続の終端における装置がパーソナルコンピュータでありアクセスリンクがインターネットプロバイダへのモデムリンクであれば、リンクレイヤはＳＬＩＰ（Ｓｅｒｉａｌ Ｌｉｎｅ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ），ＰＰＰ（Ｐｏｉｎｔ−ｔｏ−Ｐｏｉｎｔ Ｐｒｏｔｏｃｏｌ）もしくはＲＬＰ（ＧＳＭに関連して使用されるＲａｄｉｏ Ｌｉｎｋ Ｐｒｏｔｏｃｏｌ）等の適切なリンクプロトコルにより確立され、リンクレイヤを制御するコンポーネントはパーソナルコンピュータとモデム間の交換を支配するドライバである。もう１つの例として、アクセスリンクはＩＳＤＮ回線等のデジタル電話リンクやデジタルセルラー電話網における接続とすることができ、そこではドライバはモデムを制御せずＩＳＤＮアダプタカード等の適切なアダプタ装置を制御する。
【００４４】
この最後の実施例には、ネットワークやそれを支配するプロトコルを変えずに任意数のパケット交換網内に実現することができるため実現が容易であるという利点があり、セルラー電話機を介したアクセスリンク等の無線送信部を含むアクセスリンクの場合、アクセスリンクが典型的にボトルネックリンク、すなわちパケット交換接続を形成する全リンクの中で発信者に最低帯域幅を提供するリンク、であるため特に有効である。すなわち、この場合アクセスリンクにおいて競合が回避されれば全体パケット交換接続における競合の発生を完全に回避することができ、前記実施例において本発明が保証できることはそれである。
【００４５】
もう１つの好ましい実施例では、２つの帯域幅値すなわち発信者および受信者のアクセスリンクの帯域幅値がそれぞれ求められる。このようにして、これらのリンクの１つにおける競合の発生を低減することができる。
【００４６】
本発明は前記した競合回避の問題に対する単純で、有効な柔軟性のある解決法を提供し、いかなる通信システムにも応用することができる。
【００４７】
それはスライディングウィンドウフロー制御を使用するシステムに特に応用される。前記したように、フロー制御はボトルネックウィンドウだけを使用したり、ボトルネックウィンドウの使用を所与のシステムに対する既知のウィンドウと組み合わせて行うことができる。例えば、本発明をＴＣＰに応用する場合には、フロー制御がボトルネックウィンドウだけで行われる、あるいは、例えば制御ウィンドウを公示されたウィンドウ、競合ウィンドウおよびボトルネックウィンドウの最小値として決定することにより、ボトルネックウィンドウの使用を既知のウィンドウ、すなわち競合ウィンドウおよび公示されたウィンドウ、の使用に加えられるようにこのプロトコルを変えることができる。
【００４８】
後者の場合、すなわちボトルネックウィンドウを既存のウィンドウに加え次にこれらのウィンドウから制御ウィンドウを選択して本発明を応用する場合、本発明は従来の伝送プロトコル（例えば、ＴＣＰ）を変える必要がないという追加利点を提供し、しかも本発明は接続の一端でしか実現されない場合でも有効である。すなわち、後者の場合標準伝送プロトコルの既存のインプリメンテーションとのコンパチビリティが保持され、しかも性能向上の利点がある。
【００４９】
スライディングウィンドウフロー制御で使用される新しいウィンドウ、すなわちボトルネックウィンドウ、を定義することにより本発明の好ましい実施例は従来技術で準備される概念に反するものであり、既存のウィンドウズ（公示されたウィンドウ、競合ウィンドウ）は新しいアルゴリズム、例えば前記した競合回避アルゴリズム、と一緒に使用される。それとは対照的に、パケット交換接続を形成するリンクの中の個別のリンクの帯域幅上の局部情報を考慮するボトルネックウィンドウを定義することにより、本発明は単純で柔軟性の高い方法を達成し、単独であれ既知のウィンドウと一緒であれ、このボトルネックウィンドウの使用により既知の解決法よりも有効な競合回避を達成する。
【００５０】
［発明の詳細な説明］
後述する大概の例はＴＣＰに従った通信に関連して説明される。本発明はＴＣＰに従ったフロー制御の既知の要素と組み合わせることができるため、前記説明は本開示の一部を形成する。しかしながら、本発明はＴＣＰへの応用に限定されるものではなく、スライディングウィンドウフロー制御を使用するいかなる通信システムにも応用することができる。
【００５１】
インターネット等のパケット交換網における２つの通信パートナー間の接続は典型的にいくつかの個別リンクからなっており、前記リンクはルーターにより接続される。例えば、パーソナルコンピュータは高速ＬＡＮを介してサーバに接続することができ、サーバは低速ＷＡＮを介してインターネットのもう１方の会員（インターネットプロトコルピアすなわちＩＰピアとも呼ばれる）に接続することができ、インターネットの他方の会員はやはり高速ＬＡＮを介して受信者に接続することができる。ＬＡＮおよびＷＡＮはリンクを構成し、サーバはルーター、すなわちパケット内に含まれるルーティング情報に従って行き先へ向けてパケットをルーティングする装置である。この状況は図７に略示するものに対応しており、第１のＬＡＮはリンク３００、第１のサーバルーターＲ１、ＷＡＮリンク３０１、他方のインターネット会員ルーターＲ２、および第２のＬＡＮリンク３０２である。もう１つの例は低速モデムリンクを介してインターネットサーバに接続されるパーソナルコンピュータであり、サーバは専用衛星回線を介してもう１つのＩＰピアに接続されており、このＩＰピアはやはり低速モデムリンクを介して受信者に接続されている。
【００５２】
図１は本発明に従ったフロー制御方法の基本的実施例を示す。２つの通信パートナー間のパケット交換接続におけるデータのフローが制御され、前記接続はルーターにより接続される複数のリンクからなっている。一例はインターネットを介したＴＣＰ／ＩＰ接続である。接続において、送信するデータを有するパートナーが発信者であり、他方のパートナーが受信者である。第１のステップＳｔ１０において、送信されるデータのシーケンス（すなわち、ｅ−メール）が発信者に対して決定される。それは送信されるデータの一連のデータ単位（例えば、バイト）が決定されることを意味する。
【００５３】
次のステップＳｔ２０において、データが送信される接続内の少なくとも１つのリンクに関連づけられる帯域幅値が自動的に決定される。それは非常に多くの異なる方法で行うことができる。例えば、接続における一方もしくは両方のパートナーがデータが送信される方向、すなわち発信者から受信者への方向、における接続の１つ以上のリンクの帯域幅値を監視することができる。１つの可能性は接続に沿ったルーターにこれらの帯域幅値を受信者へ送信されるパケット、好ましくは発信者へ戻される受信通知パケット、に付加させることである。もう１つの可能性は一方もしくは両方のパートナーのリンクレイヤドライバをそのパートナーのアクセスリンクの帯域幅値を監視するように適応させることである。アクセスリンクはパートナーを他方のパートナーへの接続における次のルーターに接続させるリンクである。リンクに関連づけられる帯域幅値は前記リンクが単位時間当たりどれだけのデータを運べるかの表示を与える任意の数とすることができる。例えば、それはリンクの物理的な帯域幅値、すなわちリンクの全帯域幅とすることができ、より好ましくはそのリンクにおける接続に瞬時利用できる帯域幅とすることができる。
【００５４】
最後に、前記データシーケンスのフローは前記帯域幅値を利用して制御することができる。それは競合を最小限に抑えられるように１つ以上の帯域幅値を自動的に考慮することにより発信者からのデータフローが制御されることを意味する。それは、例えばスライディングウィンドウベースフロー制御を使用するシステムでは、１つ以上の帯域幅値からウィンドウ値を求め次に前記ウィンドウ値を制御ウィンドウとして使用するか、あるいはとりわけ前記ウィンドウ値を含むグループから制御ウィンドウを選択して行うことができる。このようにして、本発明は接続を直接特徴づけるパラメータに自動的に依存してデータフローが制御されるシステムを達成する。
【００５５】
フローを制御するハードウェアは、例えば接続における両方のパートナーを同時に制御する装置内に、任意適切なもしくは所望の方法で提供することができるが、より好ましくは本発明に従った制御は接続における一方もしくは両方のパートナーに直接内蔵される。好ましい実施例に従って、接続の一方のパートナーにしか実施しなくても全体接続に対する改善されたフロー制御を達成できることが、本発明の重要な利点である。
【００５６】
図８は本発明の方法の好ましい実施例のフロー図を示す。第１のステップＳｔ１において、接続に沿ったリンクに関連づけられる１つ以上の帯域幅値が決定される。帯域幅は単位時間当たりデータ量、例えばビット／秒、として定義される。接続におけるリンクはパケットが送信されるもしくは送信されている方向で発信者と受信者間にパスを確立するものであることをお判り願いたい。それは発信者から受信者へパケットが送信されるパスすなわち接続は受信者から発信者へパケットが送信されるパスと必ずしも同一ではないという事実による。
【００５７】
どの帯域幅が所与のリンクと関連づけられるかを決定する機構は本発明にとって重要ではなく、任意適切な方法で選択することができる。本発明の好ましい実施例に従って、所与のリンクと関連づけられる値は前記リンクに対応する物理的接続の帯域幅である。例として、２８８００ビット／秒の伝送速度を有するモデムによりリンクが形成される場合、関連する帯域幅は２８８００ビット／秒となる。物理的帯域幅は特定のリンクが提供できる絶対最小帯域幅とすることができ、その場合この値は所与のリンクに対して一定であり、あるいは支配的状況下における最大帯域幅とすることができることをお判り願いたい。リンクが無線通信により与えられる場合にはこの違いは重要であり、その場合絶対最大値は理想的無線状況下での値であり、支配的最大値は瞬時的状況により許容される値である。
【００５８】
このように定義されるこの物理的リンク帯域幅は考慮中の接続にどれだけ多くの帯域幅が実際に利用できるかということとは無関係である。従来技術で良く知られているように、所与のリンクは２つ以上の接続を運ぶことができ、全体（すなわち、物理的）帯域幅の一部を各接続に利用することができる。したがって、本発明のもう１つの好ましい実施例では、所与のリンクに関連づけられる帯域幅は前記リンクの接続に現在利用できる帯域幅である。
【００５９】
リンクに関連づけられる帯域幅が現在利用できる帯域幅である実施例において、この値を求める１つの可能性はパケット伝送の基礎をなす基本的プロトコル（たとえば、インターネットを介したパケット交換の場合はＩＰ）を修正して、受信者へ送信されるデータパケットであってもあるいは受信者から発信者へ送信される対応する受信通知パケットであっても、接続における各リンクが送信されるパケットへこの情報を加えるようにすることである。しかしながら、本発明はそれに依存しないため、現在利用できる帯域幅を決定する任意適切な方法を使用することができる。
【００６０】
物理的リンク帯域幅が関連付けられる帯域幅として使用される実施例において、これらの値を求める１つの可能性はやはり、リンクがこの情報を発信者もしくは受信者（やはり、例えば、ＩＰ）へ提供するように、基礎をなすネットワークレイヤ伝送プロトコルを修正することである。しかしながら、基礎をなす伝送プロトコルを修正せずに本発明の方法を使用することもできる。１つの可能性は基本的伝送プロトコル（例えば、ＴＣＰ）を修正せずに、適切に修正されたリンクレイヤプロトコル（例えば、ＳＬＩＰ，ＰＰＰもしくはＲＬＰ）より好ましくはこのようなリンクレイヤプロトコルに対する修正されたドライバを使用して関連する帯域幅情報が提供されることである。リンクレイヤプロトコルのドライバしか修正されない場合には、本発明は関与するどのプロトコルも変える必要がないという利点を提供し、そのため確立されたシステムとのコンパチビリティ問題は全くなく、ネットワークの残りのなにものも変えることなく任意数のネットワーク内へ本発明を導入することができる。
【００６１】
リンクレイヤプロトコルは特定のリンクを介した通信における２つのパートナー間の通信を支配し、前記リンクは接続の一部を形成する。典型的な例はパーソナルコンピュータからモデムリンクを介してサーバへインターネットでアクセスすることである。パーソナルコンピュータとルーターとして作動するサーバ間の通信が次に、例えば、ＳＬＩＰ（ｓｅｒｉａｌ ｌｉｎｅ ｉｎｔｅｒｎｅｔ ｐｒｏｔｏｃｏｌ）やＰＰＰ（ｐｏｉｎｔ ｔｏ ｐｏｉｎｔ ｐｒｏｔｏｃｏｌ）等のこのようなリンクに対する特定のプロトコルに従って行われる。これらのプロトコルは下位パケット、すなわち、ＴＣＰ／ＩＰパケットをカプセル化する。これらのプロトコルおよびカプセル化は従来技術で既知であり、例えば、前記したダブリュ．アール．スチーブンスの書籍、ＴＣＰ／ＩＰ Ｉｌｌｕｓｔｒａｔｅｄに記載されている。したがって、ここではその詳細を繰り返さない。
【００６２】
リンクレイヤプロトコルに従って通信を実行するのに使用されるドライバが次に対応するリンクの物理的帯域幅に関する情報を提供する。
【００６３】
基本的な基礎をなす伝送プロトコル（例えば、ＴＣＰ／ＩＰ）を修正せずに物理的帯域幅を使用して本発明を実現する利点は、本発明をコンパチビリティ問題なしで既存のシステムに統合することができ、しかも性能改善の利益を有することである。さらに、本発明は通信の一方だけのパートナーに実施することができしかも有効である。それはシステムの基礎をなす伝送プロトコルを修正する必要なしに、スライディングウィンドウフロー制御を使用する任意のシステムに本発明を一般的に応用できることを意味する。既知の全ての解決法が両方の通信パートナーを修正するかあるいはネットワーク内にトランスポートレイヤ状態をインストールする必要があるため、これは従来技術に比べて著しい利点である。
【００６４】
次に、図８の説明に戻って、ステップＳｔ１で求められた帯域幅値は関連づけられるリンクが処理できる単位時間当たりデータ量を表わす。
【００６５】
次のステップＳｔ２において、ステップＳｔ１で求められた帯域幅値の最小値が求められる。１つの値しか求められていない場合には、当然この値が最小値である。しかしながら、好ましくは２つ以上の帯域幅値がステップＳｔ１で求められ、ステップＳｔ２で選択される最小値はステップＳｔ１で考慮されるリンクの中の最低伝送速度を有するリンクの帯域幅を表わすようにされる。接続を形成する全リンクを考慮することが好ましいが、後述するようにそうする必要性はない。
【００６６】
次のステップＳｔ３において、送信方向（すなわち、発信者から受信者の方向）におけるパケット交換に沿った遅延を特徴づける時間値が求められる。この特性時間値は一般的に接続のいわゆるラウンドトリップ時間（ＲＴＴ）と関連づけられる。ＲＴＴは所与の方向においてその方向へバイトを送信してから前記バイトの直接受信通知が受信されるまでの間に経過する時間として定義される。図３に示すパケット交換を例にとると、ＲＴＴは発信者によるセグメントＳ１の送信とセグメントＳ２における受信通知の受信との間に経過する時間である。すなわち、ＲＴＴはメッセージに対する返答の受信と前記メッセージの送信との間の時間差であり、より詳細には特定のシーケンス番号を有するバイトの送信とこのシーケンス番号をカバーする受信通知の受信との間の時間である。
【００６７】
本実施例では、前記した特性時間値はパケット交換接続に沿った遅延時間、すなわちパケットの送出と対応する受信通知の受信との間の前記した時間差、を示す任意の値として解釈されることをお判り願いたい。したがって、ＲＴＴもしくはそこから誘導される任意の値が前記特性時間値として適切である。
【００６８】
ＲＴＴの決定は任意適切な方法で行うことができる。１つの特定の可能性が前記したダブリュ．アール．スチーブンスの書籍、ＴＣＰ／ＩＰＩ ｌｌｕｓｔｒａｔｅｄの２１．３章から知られている。そこに記載された方法はＴＣＰに限定されず、パケット伝送にスライディングウィンドウフロー制御を使用する任意のシステムに適切に応用することができる。替わりの方法が、例えば、ブイ．ヤコブソン，アール．ブレーデン，ディー．ボーマン，によるｔｈｅ Ｎｅｔｗｏｒｋ Ｗｏｒｋｉｎｇ Ｇｒｏｕｐ Ｉｎｔｅｒｎｅｔ−Ｄｒａｆｔ，１９９７年２月から知られている。
【００６９】
最も単純なケースでは、特性時間値は特定のシーケンス番号を有するセグメントの送出と、例えばセグメントが送出される時に作動開始し対応する受信通知パケットが受信される時に経過時間を示す値を出力する適切なクロック回路による、前記セグメントの受信通知を含むパケットの他端における受信との間の経過時間を監視することにより瞬時ＲＴＴとして直接決定することができる。この出力値は瞬時ＲＴＴとして格納される。このような決定は個別の各パケットすなわちセグメントを個別に受信通知する、すなわちデータセグメントと受信通知メッセージの１対１の対応を有する、制御プロトコルでは完全に適切である。
【００７０】
しかしながら、ＴＣＰ（例えば、図３のＳ７参照、２０４９バイトまで、すなわち最初の２つのデータセグメントＳ４およびＳ５、受信通知する）の場合のように、累積受信通知メッセージも送信することができるプロトコルでは、ステップＳｔ３の特性時間値をＲＴＴによって決まる平滑化された量として決定することが好ましい。この場合、瞬時ＲＴＴは前記したように測定される、すなわち特定のシーケンス番号を有するセグメントの送出と前記シーケンス番号をカバーする（他のシーケンス番号もカバーすることができる）受信通知の受信との間の時間遅延。この時間値はＭで示される。次に、ローパスフィルタを使用して推定量Ｒが次のように更新され、
Ｒ←αＲ＋（１−α）Ｍ
ここに、αは平滑化係数でありＴＣＰでは０．９の推奨値を有する。次に、Ｒの瞬時値はステップＳｔ３において特性時間値として使用することができる。
【００７１】
さらに好ましくは、特性時間値は測定値Ｍを平均化して測定される。それはエラー値Ｅｒｒを計算しＭの各測定値ごとに平均値Ａを次のように更新して行われ、
Ｅｒｒ＝Ｍ−Ａ
Ａ←Ａ＋ｇＥｒｒ
ここに、ｇは平均値を求めるための利得値である。ｇの典型的な値は０．１２５である。次に、Ａの瞬時値はステップＳｔ３において特性時間値として使用することができる。
【００７２】
最後に、ステップＳｔ４において、ステップＳＴ２で求められた最小帯域幅値とステップＳｔ３で求められた特性時間値の積が計算され、この積はボトルネックウィンドウとして定義される。本発明に従って、このボトルネックウィンドウは次にスライディングウィンドウフロー制御に使用することができる。精密な方法、すなわち図５および図６に関して説明するようにボトルネックウィンドウがスライディングウィンドウフロー制御において制御ウィンドウとして使用される条件もしくは必要条件、は本発明にとって重要ではない。
【００７３】
一実施例では、ボトルネックウィンドウは常に制御ウィンドウとして使用される、すなわち全体フロー制御がボトルネックウィンドウに基づいて実行される。
【００７４】
もう１つの実施例では、ボトルネックウィンドウは既知の公示されたウィンドウと一緒に使用され、制御ウィンドウはボトルネックウィンドウおよび公示されたウィンドウの最小値として選択される。さらにもう１つの実施例では、ボトルネックウィンドウは既知の公示されたウィンドウおよび既知の競合ウィンドウと一緒に使用され、制御ウィンドウは公示された、競合およびボトルネックウィンドウの最小値として選択される。
【００７５】
最も単純な実施例では、ボトルネックウィンドウの値は番号付けされたデータシーケンス（例えば、図２に示すように）の送信を開始する前に一度自動的に計算されるだけである。しかしながら、好ましい実施例では、ボトルネックウィンドウの値はセグメントの送信中に数回求められ、ボトルネックが常に更新されパケット交換接続の瞬時送信状態を正しく反映するようにされる。ボトルネックウィンドウのこの測定および更新はさらにセグメントが送られるたびに、あるいは所与の期間で周期的に、あるいは絶え間なく行うことができる、すなわち本発明の方法が実現される装置は可能な最高速度でボトルネックウィンドウを決定するプロセスを巡回し、それはボトルネックウィンドウを決定するサイクルが完了するたびに新しいボトルネックウィンドウの決定が開始されることを意味する。
【００７６】
ステップＳｔ１からＳｔ３で遭遇するさまざまなパラメータが時間と共に変動する傾向がある、例えばネットワーク上の変化するトラフィックにより接続に利用できる瞬時帯域幅値が変化することがある、ためにボトルネックウィンドウが前記したようにダイナミックに適応される場合には、たとえパケット交換接続の特性が変化する場合でも、考慮されたリンクにおける前記接続に関して競合に対する発信者の寄与は最小限に抑えることができる。
【００７７】
“競合”という用語は一般的にリンクにおける全体競合、すなわち前記リンクを通過する全てのトラフィック（全ての接続）により生じる競合、を示すのに使用されることをお判り願いたい。本発明は考慮中の接続において発信者により生じる全体競合の一部、すなわち発信者の競合に対する寄与、にしか直接影響を与えることができないことが判る。しかしながら、この寄与を最小限に抑えれば当然全体競合も最小限に抑えられる。
【００７８】
本発明により定義されるボトルネックウィンドウは特定のリンクおよびそれよりも大きい帯域幅を有する他の全てのリンクにおける競合を最小限に抑える手段である。それは従来技術が達成できないものである。すなわち、前記説明からお判りのように、ボトルネックウィンドウはステップＳｔ３で決定される最小帯域幅に関連づけられるリンクに対応して定義される。ボトルネックウィンドウの使用により前記リンクにおける競合が最小限に抑えられる。前記したように、ステップＳｔ１において考慮されたリンクは好ましくは全て接続における全リンクである。この場合ボトルネックウィンドウは最低帯域幅を絶対的に提供する接続を形成するリンクの中のリンクに対応する。しかしながら、本発明はステップＳｔ１においてより少ないリンクしか考慮しない場合にも有効に働き、それは考慮されたリンクにおいて競合が少なくとも安全に最小限に抑えられるためであり、それは従来技術では保証できないことである。
【００７９】
スライディングウィンドウフロー制御を行うパケット交換接続におけるパートナーである装置内で本発明を実行する場合、前記装置が発信者であれば、前記したようにそれは単純に送信方向のボトルネックウィンドウを決定してフロー制御に適切に使用する。パートナーが受信者であれば、それはその受信方向のボトルネックウィンドウを決定してその情報を発信者へ送信する。例えば、本発明に従って受信者しか動作しないＴＣＰ接続では、受信者はその受信方向のボトルネックウィンドウを決定することができ、次にボトルネックウィンドウおよび標準ＴＣＰ（例えば、入力バァッファ限界）に従って公示するウィンドウの最小値を公示されたウィンドウとしてＴＣＰ発信者へ公示する。このようにして、発信者はどのようにも修正はされていないが、本発明に従って動作する。このようにして、本発明にはなんらコンパチビリティ問題を生じることなくいかなる既存システムにも統合することができ、しかも性能改善の利益を保持するという著しい利点がある。
【００８０】
本発明は発信者もしくは受信者として設計された装置内に実現することができるが、典型的にはデータが前記装置から送信されるかあるいは前記装置により受信されるかに応じて発信者および受信者の両方として作動することができる装置内に実現される。
【００８１】
本発明が図８に示す実施例に従って発信者として作動する装置内に実現される場合、装置がリンクに対する１つ以上の帯域幅値を適切に決定し（図８のステップＳｔ１）次に最小値を決定する（ステップＳｔ２）ように制御を行うことができる。ステップＳｔ１およびＳｔ２に関して前記した可能性のいずれかを使用することができる。例えば、バイトの送信とそれをカバーする受信通知の受信との間で経過する時間を測定することにより、遅延表示値の決定（ステップＳｔ３）も直接実施することができる。次に最小帯域幅値と遅延表示値の積を前記発信者において計算してフロー制御におけるボトルネックウィンドウとして適切に使用することができる。
【００８２】
一方、本発明が図８に示す実施例に従って受信者として作動する装置内に実現される場合、やはり装置がリンクに対する１つ以上の帯域幅値を適切に決定し（図８のステップＳｔ１）次に最小値を決定する（ステップＳｔ２）ように制御を行うことができる。ステップＳｔ１およびＳｔ２に関して前記した可能性のいずれかをやはり使用することができる。発信者から受信者への方向における遅延表示値の決定を任意適切な方法で行うことができる。１つの可能性は受信者が専用接続遅延時間測定値メッセージを発信者へ送出して対応する受信通知が戻されるまで時間を測定することである。それには接続内の受信者と発信者の両方がこのような遅延時間測定値メッセージをサポートするプロトコルに従って動作する必要がある。好ましい実施例では、受信者が遅延表示値を独立して決定することができるため、このようなプロトコルは必要がない。データの受信を通知するシステムが発信者と受信者間に与えられることを想定するにすぎない。次に、受信者は受信通知ＡＣＫ（ｎ）の送信と第ｎ＋１バイトをカバーするセグメントの受信との間の差を測定することにより接続のＲＴＴを求め、ここにＡＣＫ（ｎ）は発信者により送信されるシーケンス内の第ｎバイトまでの含まれる全バイトに対する受信通知である。このように求められた値はボトルネックウィンドウの計算に直接使用することができ、あるいはＲおよびＡの値に関する前記説明と同様に、平滑化および／もしくは平均化を実施することができる。前記したように、次にボトルネックウィンドウは任意適切な方法、例えば公示されたウィンドウの形で、発信者へ提供することができる。
【００８３】
次に説明する本発明のもう１つの実施例では、本発明はＴＣＰ通信に応用され、下記の定義が使用される。ここでいうＴＣＰとは、過去、現在および将来の全てのバリエーションおよび、例えば任意の支配的標準に従った、このプロトコルのインプリメンテーションが含まれるという意味で、インターネット上で使用される伝送制御プロトコルのことである。
【００８４】
ＴＣＰプロトコルが実現されかつＴＣＰ接続の一端を形成する通信装置は“ＴＣＰピア”と呼ばれる。各ＴＣＰピアはＴＣＰ発信者もしくはＴＣＰ受信者もしくは同時にその両方として動作することができる。本発明に従って修正されるＴＣＰピアは“修正ＴＣＰピア”と呼ばれ、そうでなければ“標準ＴＣＰピア”と呼ばれる。したがって、“修正ＴＣＰ発信者”、“修正ＴＣＰ受信者”、“標準ＴＣＰ発信者”および“標準ＴＣＰ受信者”という用語が使用される。修飾語“修正”もしくは“標準”がなければ、関連用語は両方のケースに当てはまる。説明の目的で、標準ＴＣＰピアはダブリュ．アール．スチーブンスの前記した書籍、ＴＣＰ／ＩＰ Ｉｌｌｕｓｔｒａｔｅｄ、第１巻に従って実現されるものとするが、本実施例に関して述べた仮定および必要条件が満たされる限り、本実施例はＴＣＰの任意のバリエーションに応用することができる。
【００８５】
本実施例に従って、修正ＴＣＰピアは標準ＴＣＰピアの標準コンプライアント修正である、すなわち修正ＴＣＰピアは現在のＴＣＰプロトコル標準に従うように挙動し、それにより既存のＴＣＰインプリメンテーションとのバックワードコンパチビリティが保証される。
【００８６】
“最大リンク帯域幅”（ＭＬＢ）という用語はそのリンク上の発信者が利用できる前記リンクに対応する物理的接続の帯域幅のことである。
【００８７】
ＴＣＰ接続の特定方向（送信もしくは受信）に対する修正ＴＣＰピアにより考慮される全てのＭＬＢの最小値は関連方向の“ＭｉｎＭＬＢ”と呼ばれる。送信方向に対するリンクのパスは受信方向に対するリンクのパスと必ずしも同じではないため、ＭｉｎＭＬＢはＴＣＰピアの送信もしくは受信方向に対して異なることがあることをお判り願いたい。さらに、ＭｉｎＭＬＢは前記したように一方向のＴＣＰ接続を構成する全リンクの全ＭＬＢの最小値ではないこともお判り願いたい。大概の場合、例えば必要がないかあるいは未知であるため、修正ＴＣＰピアは全ＭＬＢを考慮することがない。例えば既知のＭＬＢの値が変化したり、従来考慮されない新しいＭＬＢが考慮されると、ＭｉｎＭＬＢは時間と共に変化することがありこの新しいＭＬＢは前のＭｉｎＭＬＢよりも低い。
【００８８】
所与の方向（送信もしくは受信）に対する“ボトルネックウィンドウ”という用語はその方向の現在のＭｉｎＭＬＢとその方向の現在のＲＴＴの積に対して使用される。ＭｉｎＭＬＢと同様に、ボトルネックウィンドウはＴＣＰピアの送信および受信方向に対して異なることがある。
【００８９】
本実施例では、修正ＴＣＰ発信者はその送信方向の現在のＭｉｎＭＬＢよりも高速で送信しないように制限され、修正ＴＣＰ受信者はその受信方向の現在のＭｉｎＭＬＢよりも高速で送信させないように対応するＴＣＰ発信者を制御する。後者は対応するＴＣＰ発信者がその送信方向の現在のＭｉｎＭＬＢよりも高速で送信することを許されないということに等しい。
【００９０】
ＭｉｎＭＬＢよりも高速で送信しないということはＴＣＰ発信者がその送信方向のボトルネックウィンドウにより与えられるよりも多くの受信通知されない未解決のパケットを有することを許されないことを意味する。修正ＴＣＰ発信者はその送信方向の現在のＭｉｎＭＬＢおよび現在のＲＴＴを連続的に追跡する。修正ＴＣＰ受信者はその受信方向の現在のＭｉｎＭＬＢおよび現在のＲＴＴを連続的に追跡する、すなわち対応するＴＣＰ発信者の送信方向のボトルネックウィンドウを追跡する。
【００９１】
本実施例では、修正ＴＣＰ発信者のフロー制御はその送信方向のボトルネックウィンドウにより補足される、すなわち使用される制御ウィンドウを決定するのにボトルネックウィンドウが公示されたウィンドウおよび競合ウィンドウと一緒に使用される。制御ウィンドウは３つのウィンドウの最小値として選択され、それは修正ＴＣＰ発信者が公示されたウィンドウ、競合ウィンドウおよびその送信方向のボトルネックウィンドウの最小値よりも多くの受信通知されない未解決のパケットを持たないことがあることを意味する。さらに本実施例では、修正ＴＣＰ受信者はその受信方向のボトルネックウィンドウを決定し、次にボトルネックウィンドウおよび標準ＴＣＰ（例えば、入力バァッファ限界）に従って公示するウィンドウの最小値を公示されたウィンドウとしてＴＣＰ発信者に公示する。
【００９２】
本実施例が発信者として作動する装置内に実現される場合には、ボトルネックウィンドウの決定に使用される送信方向のＲＴＴの決定は特定のシーケンス番号を有するバイトの送出とそのバイトの受信に関連する受信者からの受信通知の受信との間の時間経過を監視して瞬時ＲＴＴを測定することにより行うことができる。この値はＭと呼ばれる。次に、エラー値Ｅｒｒが計算されＭの測定のたびに平均値Ａが次のように更新され、
Ｅｒｒ＝Ｍ−Ａ
Ａ←Ａ＋ｇＥｒｒ
ここにｇは平均値を求めるための利得値である。典型的にｇは０．１２５である。次に、Ａの瞬時値はボトルネックウィンドウの計算に利用されるＲＴＴ値として使用される。
【００９３】
本実施例が受信者として作動する装置内に実現される場合には、ボトルネックウィンドウの決定に使用される送信方向（すなわち、発信者から受信者への方向）のＲＴＴの決定は修正された方法で瞬時ＲＴＴを測定することにより行うことができる。
【００９４】
やはりＭと呼ばれる現在のＲＴＴ値は第ｎバイトまでの含まれる全バイトの受信を通知する受信通知ＡＣＫ（ｎ）を受信者が送出してから第ｎ＋１バイトをカバーするＴＣＰセグメントを受信者が受信するまでの時間経過を監視して決定することができる。採用されたＲＴＴの値はやはりＡとして次のように決定される。
Ｅｒｒ＝Ｍ−Ａ
Ａ←Ａ＋ｇＥｒｒ
【００９５】
逆方向の状況は送信方向の状況と同一ではないため、第ｎバイトをカバーするセグメントがＴＣＰ発信者において遅延される場合には、アプリケーションがまだそれを解放していないため、問題が生じる。その場合測定された瞬時ＲＴＴＭは値Ａの更新に使用してはならない、すなわちＭのこのような値はスキップしなければならない。スキップの判断は受信者から受信されるＴＣＰパケットのパケット間到着時間に基づいてなされる。すなわち、本実施例では、修正された受信者が瞬時ＲＴＴと共にパケット到着間時間を測定して、到着時間を閾値と比較し、到着時間が前記閾値を越える場合には、測定された瞬時値ＲＴＴは前記した公式でＡの更新に使用されない。
【００９６】
本実施例では、発信者としてもしくは受信者として、本発明に従って作動する装置は瞬時的に利用できるそのアクセスリンクの帯域幅としてＭｉｎＭＬＢを決定する。１つだけのＭＬＢが決定され、それは自動的にＭｉｎＭＬＢに等しい。アクセスリンクが両方向、すなわち送信および受信方向、に使用されるため、ここでは送信および受信方向の区別をする必要がない。アクセスリンクは装置を接続に沿って次のルーターに接続するリンクである。この実施例では、利用可能な帯域幅はリンクレイヤドライバにより供給される。リンクレイヤドライバは近い過去を考慮する実行中のスループットメトリックを維持する、すなわち時間間隔にわたってデータのスループットを測定し（バイトで）測定されたスループットを前記間隔の長さで除算して、スループットと間隔長の商として帯域幅を連続的に測定する。それは連続的に行われる、すなわちある間隔にわたる測定が終了した後で、次が開始される。もう１つの可能性は経過した所与の時間量（例えば、数秒）の間隔にわたって移動平均をとることである。使用したリンクレイヤプロトコル、例えばＳＬＩＰ，ＰＰＰもしくはＲＬＰ、を適切にインプリメントすることにより、この機能を装置のリンクレイヤドライバ内にインプリメントすることができる。インプリメンテーションの修正は標準プロトコルが完全に保持されることを意味し、任意の標準インプリメンテーションとの通信が保持されるが、すなわちコンパチビリティ、前記した帯域幅決定の特殊機能は本実施例に従って動作する装置におけるインプリメンテーション内に付加される。
【００９７】
ＴＣＰ性能を改善する従来の技術はＴＣＰの双方向通信路の両方のエンドポイント（すなわち、発信者および受信者）でインプリメンテーションを修正する必要がある。したがって、このような技術を成功させるには、それにより通信を探索するこれらのホストの全ての既存のＴＣＰインプリメンテーションをグレードアップしなければならない。今日のインターネットサーバーの広範な拡がりを考えると、それは実用的ではない。ＴＣＰ性能を改善するための他の方法はネットワーク内でＴＣＰフローごとの状態を維持する必要があり、ネットワーク内のフローごとリソース要求の欠点を生じる。
【００９８】
前記した実施例はエンドツーエンドＴＣＰ接続の一方側を修正するだけでＴＣＰ性能を送信および受信の両方向で高められる利点を有する。
【図面の簡単な説明】
【図１】 本発明の基本的な実施例を示すフロー図である。
【図２】 送信される１セットのデータセグメントの例を示す図である。
【図３】 図２に示すセグメントを送信するＴＣＰに従ったパケット交換の例を示す図である。
【図４】 図３に示す通信のフロー制御中の制御ウィンドウの動作および調節を説明する図である。
【図５】 スライディングウィンドウフロー制御の原理を示す略図である。
【図６】 制御ウィンドウのエッジがどのように移動するかを示す略図である。
【図７】 通信路に沿ったリンクにおける競合を説明する略表現である。
【図８】 ボトルネックウィンドウを決定する好ましい実施例を示すフロー図である。

Claims (30)

1. パケット交換接続における発信側から受信側へ送信するデータ量に対する送信の方法であって、前記パケット交換接続はルーターにより直列に接続される複数のリンクからなり、該方法は、
   前記発信側を制御して送信されるデータのシーケンスを前記データ量から決定するステップと、
   前記複数のリンクに含まれる２以上のリンクの中から１つ以上の帯域幅値を決定するステップと、
   前記決定された１つ以上の帯域幅値で前記発信側から前記受信側へのデータを送信するように制御するプロセスに利用するステップと、
   前記シーケンス内のどの点までデータが受信されているかを示すメッセージを発信側へ戻すことにより受信側におけるデータの受信を通知するステップと、
   ある時点でデータウィンドウ内側のデータの一部もしくは全部しか送信できないように前記発信側における前記シーケンスの送信を制御するステップであって、前記データウィンドウは前記シーケンスに関する第１および第２の限界により画定され、前記第１の限界は既に送信され受信通知されたデータ量が前記ウィンドウの範囲外となるように前記既に送信され受信通知されたデータ量に依存して決定され、前記第２の限界は前記第１の限界にデータウィンドウサイズ値を加えて決定される、制御する前記ステップと、
   前記１つ以上の帯域幅値を前記データウィンドウサイズ値を決定するプロセスで利用するステップと、
   を含むことを特徴とする方法。
2. 前記１つ以上の帯域幅値は前記シーケンスの送信中に２回以上決定されることを特徴とする請求項１に記載の方法。
3. 前記１つ以上の帯域幅値は前記シーケンスの送信中に規則正しい時間間隔で決定されることを特徴とする請求項１に記載の方法。
4. 前記１つ以上の帯域幅値は前記シーケンスの送信中に連続的に決定されることを特徴とする請求項１に記載の方法。
5. 前記１つ以上の帯域幅値は新しいパケットが送信されるたびに送信の前に決定されることを特徴とする請求項１に記載の方法。
6. −前記シーケンスが送信される方向で前記複数のリンクに関連づけられる前記１つ以上の帯域幅値を決定するステップと、
   −前記１つ以上の帯域幅値の最小値を決定するステップと、
   −前記発信側により所与のバイトが送信されてから前記所与のバイトが受信側により受信されているという受信通知が受信されるまでの間に経過する時間量を特徴づける時間値を決定するステップであって、前記接続に対する前記時間値は前記シーケンスが送信される方向で決定されるステップと、
   −前記１つ以上の帯域幅値の前記最小値と前記時間値との積をリンク依存データ量値として求めるステップであって、該リンク依存データ量値は前記データウィンドウサイズ値を決定するプロセスで利用されるステップと、
   を含むことを特徴とする請求項１に記載の方法。
7. 前記リンク依存データ量値は前記データウィンドウサイズ値として使用されることを特徴とする請求項６に記載の方法。
8. 前記データウィンドウサイズ値は一群のデータ量値から最小値を選択して決定され、前記リンク依存データ量値は前記群内にあることを特徴とする請求項６に記載の方法。
9. 前記パケット交換接続はＴＣＰに従って確立され、前記データウィンドウサイズ値は公示されたウィンドウ、競合ウィンドウおよび前記リンク依存データ量値からなる群から選択されることを特徴とする請求項８に記載の方法。
10. 前記パケット交換接続はＴＣＰに従って確立され、前記時間値はシーケンスが送信される方向における前記接続に対するラウンドトリップ時間の関数として決定されることを特徴とする請求項６乃至９の何れか一項に記載の方法。
11. リンクに関連づけられる帯域幅値は前記リンクの物理的帯域幅であることを特徴とする請求項１乃至１０の何れか一項に記載の方法。
12. リンクに関連づけられる帯域幅値は前記リンク内で発信側から受信側への方向の前記接続に現在利用できる帯域幅であることを特徴とする請求項１乃至１０の何れか一項に記載の方法。
13. 前記帯域幅値は前記発信側のアクセスリンクおよび前記受信側のアクセスリンクに関連づけられる少なくとも１つの帯域幅値を含み、前記発信側の前記アクセスリンクは前記シーケンスが送信される方向で前記パケット交換接続に沿った次のルーターに前記発信側を接続するリンクであり、前記受信側の前記アクセスリンクは前記シーケンスが送信される方向とは反対の方向で前記パケット交換接続に沿った次のルーターに前記受信側を接続するリンクであることを特徴とする請求項１乃至１２の何れか一項に記載の方法。
14. アクセスリンクに関連づけられる前記帯域幅値は前記発信側および前記受信側の一方もしくは両方の前記アクセスリンクに対するリンクレイヤドライバにより提供されることを特徴とする請求項１３に記載の方法。
15. パケット交換接続における発信側から受信側へ送信するデータ量に対して送信する帯域幅値を決定する装置であって、前記パケット交換接続はルーターにより直列に接続される複数のリンクからなり、該装置は、
    送信されるデータシーケンスを前記データ量から決定する決定手段と、
    前記複数のリンクに含まれる２以上のリンクの中から１つ以上の帯域幅値を決定する手段と、
    前記決定された１つ以上の帯域幅値で前記発信側から前記受信側へデータを送信するように制御するプロセスに利用する手段と、
    前記シーケンス内のどの点までデータが受信されているかを示すメッセージを発信側へ戻すことにより受信側におけるデータの受信を通知する手段と、
    ある時点でデータウィンドウ内側のデータの一部もしくは全部しか送信できないように前記発信側における前記シーケンスの送信を制御する手段であって、
    前記データウィンドウは前記シーケンスに関する第１および第２の限界により画定され、前記第１の限界は既に送信され受信通知されたデータ量が前記ウィンドウの範囲外となるように前記既に送信され受信通知されたデータ量に依存して決定され、前記第２の限界は前記第１の限界にデータウィンドウサイズ値を加えて決定される、制御する前記手段と、
    前記１つ以上の帯域幅値を前記データウィンドウサイズ値を決定するプロセスで利用する手段と、
    を含むことを特徴とする装置。
16. パケット交換接続における発信側から受信側へ送信するデータ量に対して送信する帯域幅値を決定する通信装置であって、前記パケット交換接続はルーターにより直列に接続される複数のリンクからなり、該通信装置は、
    前記通信装置を制御する制御手段を含み、
    前記通信装置が前記接続を介してデータ量を送信する発信側として作動する場合には、送信されるデータシーケンスが前記データ量から決定され、前記リンクの１つ以上にそれぞれ関連づけられ、前記データが送信される方向における、前記複数のリンクに含まれる２以上のリンクの中から１つ以上の帯域幅値が決定され、前記決定された１つ以上の帯域幅値で前記発信側から前記受信側へデータを送信するように制御するプロセスに使用され、
    前記通信装置が前記接続の他端における通信パートナーから前記接続を介してデータを受信する受信側として作動する場合には、前記リンクの１つ以上にそれぞれ関連づけられる、前記パートナーから前記受信側への方向における前記複数のリンクに含まれる２以上のリンクの中から１つ以上の帯域幅値が決定され、前記パートナーによる前記データの送信プロセスにおいて前記１つ以上の帯域幅値を使用できるように前記パートナーへメッセージが送られ、
    どのバイトまでデータが受信されているかを示すバイトメッセージを発信側へ戻すことにより一連のバイトの受信を受信側が通知するように前記接続を介してデータを送信するプロトコルを特徴とし、ある時点で送信されるシーケンスの送信はその時点でデータウィンドウ内側のデータの一部もしくは全部しか送信することができないように行われ、前記データウィンドウは送信される前記シーケンスに関する第１および第２の限界により画定され、前記第１の限界は既に送信され受信通知されたデータ量が前記ウィンドウの範囲外となるように既に送信され受信通知された前記データ量に依存して決定され、前記第２の限界は前記第１の限界にデータウィンドウサイズ値を加えて決定され、 前記通信装置が発信側として作動する時は、前記制御手段は前記データウィンドウサイズ値を決定するプロセスで前記１つ以上の帯域幅値を使用し、 前記通信装置が受信側として作動する時は、前記制御手段は前記１つ以上の帯域幅値に基づいてデータ量値を決定し、前記データ量値は前記接続における前記パートナーへ送信されて、前記パートナーが前記データウィンドウサイズ値を決定するプロセスで使用できるようにされる
    ことを特徴とする通信装置。
17. 前記制御手段は前記通信装置が発信側として作動する時は前記シーケンスの送信中に前記１つ以上の帯域幅値が２回以上決定され、前記通信装置が受信側として作動する時は前記データの受信中に前記１つ以上の帯域幅値が２回以上決定されるように機能することを特徴とする請求項１６に記載の通信装置。
18. 前記制御手段は前記通信装置が発信側として作動する時は前記シーケンスの送信中に前記１つ以上の帯域幅値が規則正しい時間間隔で決定され、前記通信装置が受信側として作動する時は前記データの受信中に前記１つ以上の帯域幅値が規則正しい時間間隔で決定されるように機能することを特徴とする請求項１６に記載の通信装置。
19. 前記制御手段は前記通信装置が発信側として作動する時は前記シーケンスの送信中に前記１つ以上の帯域幅値が連続的に決定され、前記通信装置が受信側として作動する時は前記データの受信中に前記１つ以上の帯域幅値が連続的に決定されるように機能することを特徴とする請求項１６に記載の通信装置。
20. 前記制御手段は、前記通信装置が発信側として作動する時は、前記データシーケンスが送信される方向で前記複数のリンクに関連づけられる前記１つ以上の帯域幅値を決定し、前記１つ以上の帯域幅値の最小値を決定し、前記発信側により所与のバイトが送信されてから接続の他端で前記所与のバイトが受信されているという受信通知が受信されるまでの間に経過する時間量を特徴づける時間値を決定し、前記１つ以上の帯域幅値の前記最小値と前記時間値との積をリンク依存データ量値として決定し、該リンク依存データ量値が前記データウィンドウサイズ値を決定するプロセスで利用されることを特徴とする請求項１６に記載の通信装置。
21. 前記パケット交換接続はＴＣＰに従って確立され前記時間値はシーケンスが送信される方向で前記接続に対するラウンドトリップ時間の関数として決定されることを特徴とする請求項２０に記載の通信装置。
22. 前記制御手段は、前記通信装置が受信側として作動する時は、データが送信される方向で前記複数のリンクに関連づけられる前記１つ以上の帯域幅値を決定し、前記１つ以上の帯域幅値の最小値を決定し、前記受信側によりあるバイトをカバーする所与の受信通知メッセージが送信されてから前記接続の他端で前記接続のパートナーから送信される前記データシーケンス内の次のバイトが受信されるまでの間に経過する時間量を特徴づける時間値を決定し、前記１つ以上の帯域幅値の前記最小値と前記時間値との積をリンク依存データ量値として決定し、該リンク依存データ量値が前記パートナーへ送信されて前記データウィンドウサイズ値を決定するプロセスで利用されることを特徴とする請求項１６乃至２０の何れか一項に記載の通信装置。
23. 前記リンク依存データ量値は前記データウィンドウサイズ値として使用されることを特徴とする請求項２０又は２２に記載の通信装置。
24. 前記データウィンドウサイズ値は一群のデータ量値から最小値を選択して決定され、前記リンク依存データ量値は前記群内にあることを特徴とする請求項２０又は２２に記載の通信装置。
25. 前記パケット交換接続はＴＣＰに従って確立され、前記通信装置が発信側として作動する時は、前記制御手段は前記データウィンドウサイズ値が公示されたウィンドウ、競合ウィンドウおよび前記リンク依存データ量値からなる群から選択されるように機能することを特徴とする請求項２４に記載の通信装置。
26. 前記パケット交換接続はＴＣＰに従って確立され、前記通信装置が受信側として作動する時は、前記制御手段は前記リンク依存データ量値が前記接続における前記パートナーへ公示されたウィンドウとして送信されるように機能することを特徴とする請求項２４に記載の通信装置。
27. リンクに関連づけられる帯域幅値は前記リンクの物理的帯域幅であることを特徴とする請求項１６乃至２６の何れか一項に記載の通信装置。
28. リンクに関連づけられる帯域幅値は前記リンク内で前記データが送信される方向の前記接続に現在利用できる帯域幅であることを特徴とする請求項１６乃至２６の何れか一項に記載の通信装置。
29. 前記帯域幅値は前記通信装置のアクセスリンクに関連づけられる帯域幅値を含み、前記アクセスリンクは前記通信装置を前記パケット交換接続に沿った次のルーターに接続するリンクであることを特徴とする請求項１６乃至２８の何れか一項に記載の通信装置。
30. リンクレイヤドライバ手段を有することを特徴とし、前記アクセスリンクに関連づけられる前記帯域幅値はリンクレイヤドライバ手段により提供されることを特徴とする請求項２９に記載の通信装置。

Images