JP2004537218A

JP2004537218A - Ｎａｃｋベースのプロトコルにおける輻輳制御の信頼性のある効率的な対応方法

Info

Publication number: JP2004537218A
Application number: JP2003516188A
Authority: JP
Inventors: ロギノフ，ドミトリ
Original assignee: Koninklijke Philips Electronics NV
Current assignee: Koninklijke Philips NV
Priority date: 2001-07-26
Filing date: 2002-07-02
Publication date: 2004-12-09
Also published as: CN1533656A; KR20040015009A; EP1415444A1; US20030023746A1; WO2003010931A1

Abstract

通信リンクにおいて、サーバとクライアント間で複数のメッセージを交換し、その間の輻輳制御に対応するシステムと方法が開示される。ＮＡＣＫベースのアプリケーションにおける本発明のデータ構造を使用し、損失パケットに対する複数の再送の試みに対応することにより、本発明は、インターネット上において、サーバとクライアント間のリアルタイムのストリーミング・アプリケーションにおける輻輳制御を提供する。ＮＡＣＫベースのアプリケーションにおける再送タイムアウト（ＲＴＯ）プロトコルを使用せずに、ネットワークトラヒックを制御する機能により、ビデオ及びマルチメディアトラヒックを含む多様なネットワークトラヒックの効率的な対処を可能にする。

Description

【技術分野】
【０００１】
本発明は、デジタルパケット伝送に関し、特に、デジタル交換パケット通信環境において、輻輳制御に対応するための制御パケットを交換する方法とシステムに関する。
【背景技術】
【０００２】
多くのインターネットのストリーミング・アプリケーションは、輻輳制御を必要とし、前記輻輳制御は、クライアントノードとサーバノードとに、最初に伝送速度の値を特定の値に設定し、その後、速度を調整して、データリンク上のメッセージ伝送の変化に対応することを可能にする。現在、データ通信ネットワークにおいて、輻輳制御と損失パケット回復とに対応する２つの形式のインターネット転送プロトコルが存在する。第１のアプローチは、伝送制御プロトコル（ＴＣＰ）に示されるＡＣＫベースであり、それは、受信側（又はクライアント）が各受信パケットに応じて、肯定応答（ＡＣＫ）を送信することを含む。各ＡＣＫパケットが、ＲＴＴのサンプルを備え、損失パケットについての情報を有する。図１（ａ）は、エラー回復の仕組みとして、データが受信側端点に到達するＴＣＰの肯定応答（ＡＣＫ）処理を示したものである。本システムは、応答のないフレームのみが伝送される原理のもとで動作する。送信側によってパケットが無事に受信されたことを保障するため、ＴＣＰは、コネクション毎に再送タイマーを管理することによって、再送タイムアウト（ＲＴＯ）の仕組みを使用する。すなわち、ＴＣＰは再送タイマーを設定し、コネクションのＲＴＯ値と、ラウンドトリップタイム（ＲＴＴ）とを追加する。ＲＴＴは、ＴＣＰ型のデータセグメントの伝送開始と、前記セグメントの肯定応答の受信との間の経過時間である。ＲＴＯ_１が終了するまでに肯定応答が受信されない場合は、ＴＣＰは次のＲＴＯ_２内で再度データを再送する。
【０００３】
第２のアプローチは、ユーザ・データグラム・プロトコル（ＵＤＰ）におけるＮＡＣＫベースであり、それは、受信側が各損失パケットに応じて、否定応答（ＮＡＣＫ）を送信することを含む。図１（ｂ）は、再送のため、損失フレームに応じて送信側（又はサーバ）にＮＡＣＫパケットを転送することを含む、否定応答（ＮＡＣＫ）のＵＤＰシステムを示したものである。図１（ｂ）に示す通り、ＮＡＣＫパケットは、受信側から送信側への経路において損失する可能性がある。ＵＤＰは、再送コネクションのためのＴＣＰと同様の再送タイムアウト（ＲＴＯ）の仕組みを利用する。ＲＴＯの評価は、ＲＴＴの以前のサンプルに基づいて、ＲＴＴの次の値を予測することにより実行される。ＲＴＯが過大評価されると、ＴＣＰにおいて低いスループット性能につながり、リアルタイム・アプリケーションにおいて、アンダーフローのイベントの増加を引き起こし得る。しかし、ＲＴＯが過小評価されると、いっそう多くの不要なパケットが再送され、重大なネットワークの輻輳を引き起こす多数の複製パケットをプロトコルが生成する。実際には、歴史的な理由により、多くの提案された輻輳制御の仕組みは、ＴＣＰに示されるフロー制御と同様の、ウィンドウベースのフロー制御に依存している。
【０００４】
例えばマルチメディアアプリケーション等の、リアルタイムのストリーミング・アプリケーションにおいては、受信側から送信側への経路での低いオーバーヘッドと、損失パケットの潜在的に早い回復のため、ＮＡＣＫベースの動作が好まれる。しかし、ＮＡＣＫベースのプロトコルにおける輻輳制御は、高い振動の度合い（ＮＡＣベースの輻輳制御の“オープンループ”動作により引き起こされる）と、ＮＡＣベースの仕組みが各送信パケットからＲＴＴのサンプルを導き出すことが不可能であることと（結果として、フィードバックの頻度が低くなる）により、一般的に困難と考えられている。さらに、ＮＡＣＫベースのプロトコルが、効率的に（すなわち、ほとんどタイムアウトせずに）制御メッセージの損失を克服する一般的な方法は存在しない。したがって、本発明は、低い振動レベルと、ＲＴＴの測定の高い頻度と、損失パケットに対する高い回復度と、高いビットレートの拡張性と、効果的なＮＡＣＫベースの再送と、従来のＡＣＫベースの輻輳制御の全機能とを達し、サーバとクライアント間のＮＡＣＫベースの環境において、輻輳制御メッセージを交換する改良された仕組みに関する。
【発明の開示】
【課題を解決するための手段】
【０００５】
本発明は、サーバとクライアント間のインターネット上のリアルタイムのストリーミング・アプリケーションにおいて輻輳制御を提供する方法とシステムを対象にする。
【０００６】
本発明の一形態は、パケット通信システムにおいて、送信側速度を調整し、サーバとクライアント間の輻輳制御に対応する方法に関する。本方法は：クライアントに複数のデータパケットを伝送するステップと；サーバからクライアントへの通信コネクションで、データパケットの１つが損失したかどうかを判断するステップと；データパケットの１つが損失した場合に、クライアントにより再送のための応答パケットを伝送するステップと；サーバに応答パケットを送信することと、サーバから損失パケットの対応する再送を受信することとの間の遅延時間に対応するラウンドトリップタイム（ＲＴＴ）とパケット損失率とに基づいて、新たな送信側速度を計算するステップと；前記通信コネクションの間に、所定の数のＲＴＴが検出されると、サーバによる新たな送信側速度を調整するステップとを含む。
【０００７】
本発明の他の形態は、パケット通信システムにおいて、送信側速度を調整し、サーバとクライアント間の輻輳制御に対応するシステムに関する。本システムは、複数のデータパケットを受信する手段と；伝送中にデータパケットの１つが損失したかどうかを判断する手段と；何らかの損失フレームパケットが再送されることを要求する手段と；損失フレームの再送をサーバに要求することと、対応する損失パケットの再送をサーバから受信することとの間の遅延時間に対応するラウンドトリップタイム（ＲＴＴ）とパケット損失率とに基づいて、新たな送信側速度を計算する手段と；その後に計算されるＲＴＴが所定の閾値を満たすと、サーバに新たな送信側速度を知らせる手段とを含む。
【０００８】
図面と共に、次の詳細な説明を読むことにより、本技術に熟練した人にこれらの利点や他の利点が明白になるだろう。
【発明を実施するための最良の形態】
【０００９】
本発明の完全な理解を提供するために、次の説明において、限定の目的ではなく説明の目的で、特定の構成や、インタフェースや、技術等のような特定の詳細が示される。加えて、不要な詳細で本発明の説明をあいまいにしないように、明確さと簡潔さの目的で、周知の装置や、回路や、方法の詳細な説明は省略される。
【００１０】
サーバからのパケットが輻輳になり得る程の速すぎる速度で到達することを、クライアントが判断すると、本発明による輻輳制御の動作が実行される。このため、クライアントは、伝送する応答メッセージに輻輳制御情報を挿入し、それにより、応答メッセージを受信するサーバが、クライアントにパケットを伝送する速度を下げる。その後輻輳が弱まると、クライアントノードは、応答パケットにおいて、クライアントにパケットを送信する速度を上げることを受信サーバに許可する輻輳制御情報を伝送する。さらに、本発明は、先行技術のシステムにあるような再送タイムアウト（ＲＴＯ）を使用せずに、クライアントが再送の損失を検出可能な仕組みを提供し、これにより、損失パケットの早い回復を提供する。さらに、本発明の仕組みは、パケット損失に対する回復と、クライアントからサーバへの経路での再要求である。すなわち、本発明の仕組みの動作は、サーバが、クライアントにより送信された期限切れの再要求された輻輳制御メッセージに反応することを回避する。さらに、本発明の仕組みは、輻輳制御動作の減衰が、特定の輻輳制御アルゴリズムに調整されることを許容し、輻輳制御の周期の増加と減少のための異なる度合いの減衰を提供する。
【００１１】
図２を参照すると、本発明を使用するシステム１０は、サーバ１２と、クライアントシステム１４とを有し、ネットワーク１６のアクセス回線を介して相互に通信する。サーバとクライアント間の通信接続は、無線通信リンクと、有線通信リンクと、有線通信リンクと無線通信リンクとの組み合わせのうちの少なくとも１つを含み得る。サーバ１２とクライアント１４の双方は、例えば、１ユーザ又は数ユーザに使用され得るパーソナルコンピュータ又はコンピュータワークステーションを含み得る。本発明の選択された実施例は、サーバとクライアントシステムで実行するソフトウェアである。コンピュータプログラム（又はコンピュータ制御ロジック）は、各システムのメインメモリに蓄積される。前記コンピュータプログラムは、実行されると、各システムが本願に論ずる本発明の機能を実行することを可能にする。図２に示すネットワークは、説明の目的で小さいが、実際には、ネットワークは非常に多くの異なるコンピュータシステムを含み得ることに注目すべきである。さらに、本発明はクライアント・サーバ環境で実行され得るが、クライアント・サーバ環境は必須ではないことに注目すべきである。
【００１２】
本発明の実施例によると、輻輳制御動作中にクライアント１２がサーバ１４に伝送する２つの形式の制御パケットが存在する。第１の形式のメッセージは、一般的にＮＡＣＫメッセージと呼ばれる再送要求を有する。第２の形式のメッセージは、輻輳制御（ＣＣ）と呼ばれ、サーバ１２からクライアント１４への経路上で実装される新たな伝送速度を有する。すなわち、新たな伝送速度ｒ（ｔ）を示す輻輳制御動作の出力が、クライアント１４からサーバ１２に伝送される。このとき、新たな伝送速度ｒ（ｔ）は、サーバのパケットのパケット損失率と、制御パケットのラウンドトリップタイム（ＲＴＴ）とに基づいて計算される。測定されたＲＴＴ及び／又はパケット損失率に基づく、新たな伝送速度又は新たな送信側速度の計算は、技術的に周知であり、多様な方法で実行され得る。新たな伝送速度の正確な計算は、実装に依存し、本技術に熟練した人は、多くの異なる方法が存在することがわかる。例えば、伝送遅延とＲＴＴに基づき、送信側速度を決定する技術は、１９９８年６月２９日に出願された米国特許出願第６，１１５，３５７号に開示され、参照として本願に取り込まれる。実施例において、新たな伝送速度ｒ（ｔ）は、各ＮＡＣＫメッセージに挿入される。その他、損失パケットが存在しなければ、新たな伝送速度ｒ（ｔ）は、クライアント１４からサーバ１２への輻輳制御（ＣＣ）パケットを介して、サーバ１２に送信される。
【００１３】
データフローの速度は、一つには、伝送遅延とラウンドトリップタイム（ＲＴＴ）とに基づく。図３は、前段落で説明した、パケットヘッダの構造を示したものであり、クライアント１４とサーバ１４との間の制御パケットを交換し、本発明の実施例に従って輻輳制御を実行するために使用される。限定するわけではないが、異なるサイズのフィールドや、異なる順番のフィールドの配置や、図３に示されていない追加フィールドを含む、示されたものから他のデータ構造がうまく使用することができることが、技術的に熟練した人に明白である。
【００１４】
図３に示す通り、クライアント１４によって送信される各パケットは、先行技術の方法には存在しない２つのフィールドを含む。第１のフィールドであるテストＲＴＴシーケンスは、ＲＴＴを測定し、再送パケットが損失したかどうかを検出するために使用される。このために、サーバ１２は、クライアント１４から制御パケットを受信すると、クライアント１４から直前に受信されたテストＲＴＴシーケンスを、クライアント１４に転送する各パケットにコピーする。そして、特定のテストＲＴＴシーケンスを備える要求を送ることと、同じシーケンス番号を備えるサーバのパケットを受信することとの間の継続時間を測定することにより、クライアント１４はＲＴＴを計算する。例えば、図４（ａ）及び４（ｂ）の記号（ｘ，ｙ）は、シーケンス番号がｘでテストＲＴＴシーケンスがｙであるパケットを表す。図４に示す通り、パケット（１００，２）が伝送中に損失すると、再送のため、ＮＡＣＫパケット（１００，３）がサーバ１２に伝送される。その後、要求されたパケット（１００，３）が、サーバ１２からクライアント１４に再送され、それもまた損失する。それにもかかわらず、クライアントは、サーバがクライアントの要求を受信したことを示す次のソースパケット（１０３，３）を受信する。先入れ先出しのネットワークを仮定すれば、クライアントは、再送パケット（１００，３）の損失を推測することができる。したがって、テストＲＴＴシーケンスが（１０２，２）から（１０３，３）に変化することを監視することにより、クライアント１４は、本発明に従ってラウンドトリップタイム（ＲＴＴ）を生成し、パケット（１０３，３）を受信すると、パケット１００の第２のＮＡＣＫを送信することができる。すなわち、クライアント１４がテストＲＴＴシーケンスｉを備えるＮＡＣＫを送信し、その結果として、ｉより大きい又は同じテストＲＴＴシーケンスを備えるサーバのパケットを受信し、この時点までに、クライアント１４がシーケンスｉを備えるＮＡＣＫにおいて要求した再送を受信していない場合は、クライアント１４は要求した再送パケットが損失し、ＮＡＣＫパケットを再度送信しなければならないことがわかる。ラウンドトリップタイム（ＲＴＴ）は、サーバ１２に対する要求（ＮＡＣＫ又はＣＣのいずれか）を送信することと、サーバがクライアントの要求（すなわち、クライアントにより送信された最後のパケットより大きい又は同じテストＲＴＴシーケンスを備えるパケット）を受信したことを示すサーバのパケットの受信との間の時間として定義される。したがって、ＣＣとＮＡＣＫパケットの双方は、本発明のＲＴＴを測定する同じテストＲＴＴシーケンスフィールドに依存し、ＲＴＴの測定を実現するために使用され得る。
【００１５】
図４（ｂ）を参照すると、本発明の実施例による図３に示すＮＡＣＫメッセージのｒａｔｅ（ｔ）フィールドの目的は、先行技術のシステムにおける再送タイムアウト（ＲＴＯ）を待つことなく、クライアント１４からサーバ１２への経路上のＣＣパケットの損失を直ちに克服することである。ＣＣパケットの中のｒａｔｅ（ｔ）が送信され、損失すると、クライアント１４は、ＲＴＴの全周期を待たずに、損失ＣＣメッセージの直後に同じｒａｔｅ（ｔ）を備えるＮＡＣＫを送信し得る。損失パケットが存在し、ＮＡＣＫが正当化される場合に、前記状態が発生する。先行技術のシステムにおいては、クライアント１４は、タイムアウトを待つ必要があり、一般的には、ＲＴＯは、実際のＲＴＴの評価より保守的（かなり大きい）である。本発明において、ＣＣが損失すると、クライアント１４が全ＲＴＴを待ってＣＣメッセージを再送する場合よりかなり早く、次のＮＡＣＫがサーバにｒａｔｅ（ｔ）を供給する。ゆえに、本発明は、損失ＣＣパケットのより早い回復を提供し、損失ＣＣパケットを回復する場合に待つ不必要な再送タイムアウト（ＲＴＯ）を削除する。新たなＣＣ又はＮＡＣＫパケットが送信される毎に、テストＲＴＴシーケンスが１つ増すことに留意すべきである。
【００１６】
図４ｂの上の図を参照すると、（ｒ（ｔ），３）を備えるＣＣメッセージが損失すると（ｒ（ｔ）は新たな速度で、３はテストＲＴＴシーケンスである）、クライアント１４は、タイムアウトの終了により、ＲＴＯ時間単位後になって初めて、ＣＣメッセージの損失を克服することができる。２つのＣＣメッセージの間にＮＡＣＫメッセージ（１００，４）が存在することに留意すべきである。先行技術においては、ＮＡＣＫメッセージは活用されていない。したがって、時間Ｔ１においてサーバ１２が速度ｒａｔｅ（ｔ）を受信する。本発明においては（図の下部）、ＮＡＣＫは、損失パケットのシーケンス番号（すなわち１００）と、次のＲＴＴシーケンス（すなわち４）に加えて、速度ｒ（ｔ）を有する。したがって、サーバ１２は、Ｔ１ではなくＴ０において、速度をより早く取得する。本発明がなければ、ＲＴＯの終了前に再送パケット（１００，４）がクライアントに戻ると、クライアント１４は、ＣＣパケットの損失を推測し、タイマーが終了する前にＣＣパケットを再送するが、それでも（ＲＴＯのかわりに）ＲＴＴの全時間単位が浪費される。
【００１７】
続いて図３を参照すると、ＣＣとＮＡＣＫパケットの双方に存在する第２のフィールドであるＣＡ（制御動作）シーケンスの機能は、輻輳制御シーケンス番号をサーバ１２に伝え、サーバ１２が、ＲＴＴにつき１度以上、クライアント１４により送信された輻輳制御メッセージに反応することを回避する。すなわち、ＣＡシーケンスは、新たな送信側速度を適応させる前に、システムが所定の時間（又は最低輻輳制御周期）を待つ仕組みを提供する。本発明において、最低輻輳制御周期は、新たな送信側速度を特定する前の測定されたＲＴＴの数を表し、１つのＲＴＴの後に発生し得る。したがって、ＲＴＴの数は、サーバ１２が新たな送信側速度を適応することを可能にする前に測定される。加えて、最低輻輳制御周期は、輻輳制御の増加段階と減少段階で異なり得る。このことを達するために、新たな輻輳制御動作がサーバ１２に送信される必要がある場合にのみ、クライアント１４はＣＡシーケンスを増加し、サーバ１２は、サーバのローカルのＣＡシーケンス値より小さい又は同じＣＡシーケンスを備えるパケットにおいて受信された速度ｒ（ｔ）を無視しなければならない。加えて、本方法は、サーバ１２が再要求された輻輳制御メッセージ（例えば、順序違いで到達する遅れたＣＣ及びＮＡＣＫメッセージ）に反応することを回避し、速度の変更を起動しない。
【００１８】
図５は、クライアント１４が輻輳制御動作の頻度（例えば、各周期の継続時間）を決定する動作ステップと、本発明の実施例によりＣＡシーケンスが増加される動作ステップとを示したものである。クライアント１４が、サーバ１２に通信接続し、サーバ１２に制御パケットを伝送すると、サーバ１２がメッセージパケットを伝送し得る速度を示す速度値で、クライアント１４はサーバ１２と通信する。その後の各メッセージパケットは、以前の確立された速度値を変更し得る輻輳制御情報を含み得る。まず、ステップ１００において、クライアント１４は、テストＲＴＴシーケンスがｉであるパケットをサーバから受信する。ステップ１０２において、クライアント１４は、現在受信したテストＲＴＴシーケンスｉが以前に実行されたテストＲＴＴシーケンス（最終動作シーケンス）より大きい又は同じであるかどうか：ｉ≧最終動作シーケンス？を判断する。もし、そうであれば、最初のラウンドトリップタイム（ＲＴＴ）が実行される。ステップ１０４において、ＲＴＴ測定の周期が１つ増す：ＣＣ周期＝ＣＣ周期＋１。そしてステップ１０６において、ＲＴＴ測定の現在の周期が、所定の増加基準周期（ｋ_Ｉ＊ＲＴＴｓ）又は減少周期（ｋ_Ｄ＊ＲＴＴｓ）を超えるかどうかが判断される。望ましい実施態様においては、ｋ_Ｄの値は１であり、ｋ_Ｉの値は２と４の間である。したがって、現在の周期がｋ_Ｄ又はｋ_Ｉの周期を超えると、クライアント１４は、ＣＣ又はＮＡＣＫパケットのいずれかを使用して、送信速度を増加又は減少するようにサーバ１２に指示する。ステップ１０４において更新された新たな周期が、ステップ１０８又はステップ１１０において、それぞれの所定の基準周期より大きい場合は、ＣＡシーケンスが１つ増し、送信速度が新たな速度に変わる。それは、ステップ１１２において、ＲＴＴに基づいて計算される：ＣＡシーケンス＝ＣＡシーケンス＋１及びＣＣ周期＝０。ＲＴＴの値は常に変化するため、クライアント１４は以前に測定されたＲＴＴの値に依存できず、各ＣＣ及びＮＡＣＫ要求の時点で測定したＲＴＴに依存しなければならない。すなわち、新たなＣＣ動作が時間ｔにおいて開始し、クライアントのＣＡシーケンスの現在の値がｊである場合、クライアント１４は、時間ｔにおいてＣＡシーケンスの値をｊ＋１に増し、（損失パケットが存在し、回復が必要な場合に）ＣＣ又はＮＡＣＫのいずれかをサーバ１２に送信する。現在の周期がｋ_Ｄ又はｋ_Ｉの周期を超えない場合、すなわち、ステップ１０８において：ＣＣ周期≧ｋ_Ｉステップ１１０において：ＣＣ周期≧ｋ_Ｄの場合、ステップ１１４において、クライアントはテストＲＴＴの値を更新する。ＣＡシーケンス番号はステップ１１４の間に変化しないが、テストＲＴＴシーケンス番号のみ変化する：テストＲＴＴシーケンス＝テストＲＴＴシーケンス＋１。すなわち、クライアント１４が時間ｔにおいて送信側速度ｒ（ｔ）を変えると、増加が許可されるまで、例えば、時間ｔ＋ｋ_Ｉ＊ＲＴＴにおいて次の増加動作が開始するまで、クライアントはｋ_Ｉラウンドトリップ遅延時間中、同じ速度を維持しなければならない。同様に、次の動作が減少の場合、ｒ（ｔ）が維持される必要のある最小時間は、ｋ_Ｄラウンドトリップ遅延時間である。最後に、制御（すなわちＮＡＣＫ及びＣＣ）メッセージの損失を克服するために、クライアント１４は、再送タイムアウト（ＲＴＯ）タイマーを開始し得る。伝送される各ＣＣ又はＮＡＣＫパケット毎に、本発明はタイマーを維持する。クライアントが、最後に送信したパケットより大きい又は同じテストシーケンスを備えるサーバのパケットを取得する前に、タイマーが終了すると、対応するＣＣ又はＮＡＣＫパケットが再送される。
【００１９】
図６は、再送タイムアウト（ＲＴＯ）の仕組みを必要とせずに、クライアント１４がパケット損失を克服し、サーバ１２の送信側速度を調整することを可能にする動作ステップを示したものである。まず、サーバ１２は、ネットワーク上でクライアントに少なくとも１つのソースパケットを送信する。図４に示す通り、サーバ１２からクライアント１４へのソースパケットが、エラー又は損失として伝送されると、再送のため、クライアント１４は否定応答（ＮＡＣＫ）パケットをサーバ１２に伝送する。再送パケットが損失すると、ステップ２００において、クライアントは、次のソースパケットのテストＲＴＴシーケンスのフィールドから損失を推測する（図４の例を参照）。実施例では、リアルタイムセッションにおいてクライアント１４は、ラウンドトリップ遅延時間を定期的に測定しなければならない。ＲＴＴは、ＮＡＣＫ又はＣＣメッセージを送信することと、クライアントから対応する要求をサーバが受信したことを認める対応する再送又は最初のサーバパケットを受信することとの間の継続時間である。本発明において、各ＣＣメッセージはＲＴＴの測定を提供する。ＣＣメッセージは非常に頻繁であるため、クライアントはＲＴＴのサンプルを高頻度で取得し、ＡＣＫベースの輻輳制御の仕組みと同じ性能を達する。ステップ２１０において、新たな送信側速度を設定する前に、ラウンドトリップ遅延時間の追加のサンプルを取得することにより、クライアント１４によってＲＴＴが繰り返して測定される。ステップ２３０において、所定の周期の数に到達すると、クライアント１４は、直前に計算されたＲＴＴを伝送し、制御動作（ＣＡ）シーケンスを１つ増し、サーバ１２に送信側速度を調整するように通知する。その後、更なるデータパケットがクライアント１４によって受信されると、動作ステップ２００−２３０が再度繰り返される。
【００２０】
要約すると、本発明はＮＡＣＫベースのプロトコルにおける輻輳制御の新たなフレームワークを提供し、著しい性能の改善（例えば、低い振動率や、パケット損失や再要求に対する回復や、タイムアウトのない損失の再送の検出や、各ＣＣ／ＮＡＣＫメッセージからのＲＴＴの測定や、既存のＮＡＣＫベースの輻輳制御方法に対してかなり少ない複製パケットを有するＮＡＣＫベースの再送）を達する。デジタル通信リンクにおいて、輻輳制御メッセージを管理する前述の望ましい実施態様を有することにより、システムの特定の利点が達せられることが、技術的に熟練した人に明白である。前述は、本発明の例示的な実施例のみとして構成されたものである。したがって、技術的に熟練した人は、本発明の基本的な原理又は範囲を逸脱することなく、本発明と同様の機能を備える他の構成を容易に考えることが可能である。
【図面の簡単な説明】
【００２１】
【図１（ａ）】ＴＣＰ通信環境における代表的なデータフローを示したものである。
【図１（ｂ）】ＵＤＰ通信環境における代表的なデータフローを示したものである。
【図２】本発明によるシステムのブロック図を示したものである。
【図３】本発明によるサーバの端点におけるユーザ・データグラム・プロトコル（ＵＤＰ）パケットのフォーマットを示したものである。
【図４（ａ）】本発明により、ラウンドトリップタイム（ＲＴＴ）を測定するためのパケットの交換を示したタイムチャートである。
【図４（ｂ）】本発明により、制御動作パケットの紛失を克服するためのパケットの交換を示した対照によるタイムチャートである。
【図５】本発明による輻輳制御の動作を示したフローチャートである。
【図６】再送タイムアウト（ＲＴＯ）の仕組みを必要とせずに、クライアント１４がパケット損失を克服し、サーバ１２の送信側速度を調整することを可能にする動作ステップを示したものである。

Claims

パケット通信システムにおいて、送信側速度を調整し、サーバとクライアント間の輻輳制御に対応する方法であって、
（ａ）前記クライアントに複数のデータパケットを伝送するステップと、
（ｂ）前記サーバから前記クライアントへの通信コネクションで、前記データパケットの１つが損失したかどうかを判断するステップと、
（ｃ）前記データパケットの１つが損失した場合に、前記クライアントにより再送のための応答パケットを伝送するステップと、
（ｄ）前記サーバに前記応答パケットを送信することと、前記サーバから前記損失パケットの対応する再送を受信することとの間の遅延時間に対応するラウンドトリップタイム（ＲＴＴ）に基づいて、新たな送信側速度を計算するステップと、
（ｅ）前記通信コネクションの間に、所定の数の前記ＲＴＴがその後検出されると、前記サーバに新たな送信側速度を伝送するステップと
を有する方法。
請求項１に記載の方法であって、
前記ＲＴＴが、
前記データパケットの１つが損失した場合に、ＲＴＴシーケンス番号を備える第１のパケットを前記サーバに伝送するステップと、
前記サーバからの前記第１のパケットに応じて、前記損失パケットを有する第２のパケットを受信するステップと、
前記第１のパケットと前記第２のパケットの間の遅延に基づいて、前記ラウンドトリップタイム（ＲＴＴ）を計算するステップと
に従って判断される方法。
請求項１に記載の方法であって、
前記サーバと前記クライアントの間の前記通信コネクションが、無線通信リンクと、有線通信リンクと、有線通信リンクと無線通信リンクとの組み合わせのうちの少なくとも１つを有する方法。
請求項１に記載の方法であって、
前記クライアントにより、複数の前記データパケットに応じた多数の肯定応答メッセージに、前記サーバが後のデータパケットを前記クライアントに伝送する伝送速度を示す新たな送信側速度を含めるステップと、
前記サーバにより、前記肯定応答メッセージに応じて、前記サーバが後のデータパケットを前記クライアントに送信する新たな送信側速度を調整するステップと
を更に有する方法。
請求項１に記載の方法であって、
前記応答パケットのフィールドに、ＲＴＴシーケンス番号と前記新たな送信側速度とを含めるステップと、
前記サーバから受信した前記ＲＴＴシーケンス番号が順序違いである場合に、前記クライアントにより、前記データパケットの１つが損失したことを判断するステップと
を更に有する方法。
請求項１に記載の方法であって、
前記応答パケットのフィールドに、前記サーバへの前記新たな送信側速度の再送を示す制御動作（ＣＡ）シーケンス番号を含めるステップと、
前記所定の数のＲＴＴが後に検出されると、前記サーバにより、前記送信側速度を調整するステップと
を更に有する方法。
請求項１に記載の方法であって、
前記応答パケットが、否定応答（ＮＡＣＫ）パケットと、前記サーバに対する前記新たな送信側速度の再送を示す制御動作（ＣＣ）パケットとのうちの１つである方法。
請求項１に記載の方法であって、
前記新たな送信側速度の前記計算が、パケット損失率に基づく方法。
通信リンクにおいて、サーバとクライアント間で複数のメッセージを交換し、その間の輻輳制御に対応する方法であって、
（ａ）前記サーバから前記クライアントに複数のデータパケットを伝送するステップと、
（ｂ）前記バーストパケットの１つが損失した場合に、前記クライアントにより、再送のための否定応答（ＮＡＣＫ）パケットを伝送するステップと、
（ｃ）前記クライアントにより、前記ＮＡＣＫパケットを前記サーバに送信することと、前記損失パケットの対応する再送を前記サーバから受信することとの間の遅延時間に対応するラウンドトリップタイム（ＲＴＴ_ｉ）を計算するステップと、
（ｄ）前記サーバが後のデータパケットを前記クライアントに伝送し得る伝送速度を示す前記計算されたＲＴＴに基づいて、新たな送信側速度を判断するステップと、
（ｅ）前記新たな送信側速度を有する複数の前記データパケットに応じて、複数の応答パケットを継続的に伝送するステップと、
（ｆ）前記ＲＴＴが、所定の閾値よりも多いと計算された場合に、前記サーバにより、前新たな送信側速度を調整するステップと
を有する方法。
請求項９に記載の方法であって、
前記ＲＴＴが、
前記データパケットの１つが損失した場合に、ＲＴＴシーケンス番号を備える第１のパケットを前記サーバに伝送するステップと、
前記サーバからの前記第１のパケットに応じて、前記損失パケットを有する第２のパケットを受信するステップと、
前記第１のパケットと前記第２のパケットの間の遅延に基づいて、前記ＲＴＴを計算するステップと
に従って判断される方法。
請求項９に記載の方法であって、
前記サーバと前記クライアントの間の前記通信コネクションが、無線通信リンクと、有線通信リンクと、有線通信リンクと無線通信リンクとの組み合わせのうちの少なくとも１つを有する方法。
請求項９に記載の方法であって、
前記クライアントにより、複数の前記データパケットに応じた複数の肯定応答メッセージに、前記サーバが後のデータパケットを前記クライアントに伝送する伝送速度を示す新たな送信側速度を含めるステップと、
前記サーバにより、前記肯定応答メッセージに応じて、前記サーバが後のデータパケットを前記クライアントに送信する新たな送信側速度を調整するステップと
を更に有する方法。
請求項９に記載の方法であって、
前記応答パケットのフィールドに、ＲＴＴシーケンス番号と前記新たな送信側速度とを含めるステップと、
前記サーバから受信した前記ＲＴＴシーケンス番号が順序違いである場合に、前記クライアントにより、前記データパケットの１つが損失したことを判断するステップと
を更に有する方法。
請求項９に記載の方法であって、
前記応答パケットのフィールドに、前記サーバへの前記新たな送信側速度の再送を示す制御動作（ＣＡ）シーケンス番号を含めるステップと、
前記所定の数のＲＴＴが後に検出されると、前記サーバにより、前記送信側速度を調整するステップと
を更に有する方法。
請求項９に記載の方法であって、
前記応答パケットが、否定応答（ＮＡＣＫ）パケットと、前記サーバに対する前記新たな送信側速度の再送を示す制御動作（ＣＣ）パケットとのうちの１つである方法。
パケット通信システムにおいて、送信側速度を調整し、サーバとクライアント間の輻輳制御に対応するシステムであって、
前記クライアントに複数のデータパケットを伝送する手段と、
伝送中に前記データパケットの１つが損失したかどうかを判断する手段と、
何らかの損失フレームパケットが再送される要求を行う手段と、
前記サーバに前記損失フレームの再送を要求することと、前記サーバから前記損失フレームの対応する再送を受信することとの間の遅延時間に対応するラウンドトリップタイム（ＲＴＴ）に基づいて、新たな送信側速度を計算する手段と、
前記ＲＴＴが所定の閾値より大きいと計算されると、前記サーバに新たな送信側速度を通知する手段と
を有するシステム。
請求項１６に記載のシステムであって、
前記第１のパケットが、前記サーバが後のデータパケットを前記クライアントに伝送し得る伝送速度を示す前記新たな送信側速度とＲＴＴシーケンス番号とを有し、
前記サーバから受信した前記ＲＴＴシーケンス番号が順序違いである場合に、前記データパケットの１つが損失したと判断されるシステム。
請求項１６に記載の方法であって、
前記第１のパケットが、前記サーバへの前記新たな送信側速度の再送を示す制御動作（ＣＡ）シーケンス番号を有する方法。
請求項１６に記載の方法であって、
前記サーバが前記クライアントに後のデータを送信する前記新たな送信側速度を調整する手段を更に有する方法。
通信リンクにおいて、サーバとクライアント間で複数のメッセージを交換し、その間の輻輳制御に対応するシステムであって、
前記サーバから前記クライアントに複数のデータパケットを伝送する手段と、
前記バーストパケットの１つが損失した場合に、前記クライアントにより、再送のための否定応答（ＮＡＣＫ）パケットを伝送する手段と、
前記クライアントにより、前記ＮＡＣＫパケットを前記サーバに送信することと、前記損失パケットの対応する再送を前記サーバから受信することとの間の遅延時間に対応するラウンドトリップタイム（ＲＴＴ_ｉ）を計算する手段と、
前記サーバが後のデータパケットを前記クライアントに伝送し得る伝送速度を示す前記計算されたＲＴＴに基づいて、新たな送信側速度を判断する手段と、
前記新たな送信側速度を有する複数の前記データパケットに応じて、複数の応答パケットを継続的に伝送する手段と、
前記ＲＴＴが、所定の閾値よりも多いと計算された場合に、前記サーバにより、前新たな送信側速度を調整する手段と
を有するシステム。