JP5020076B2 - 低頻度ａｃｋのシステムに適した高性能ｔｃｐ - Google Patents

Description

関連出願

本出願は、2004年7月29日出願の米国特許仮出願第60/592,065号の利益を主張する。上記出願の全内容は参照により本明細書に引用したものとする。

コンピュータネットワーク通信において現在最も一般に使用されている伝送制御プロトコル（ＴＣＰ）は、単一プロトコルではなく、実際には、インターネットプロトコル（ＩＰ）接続全体にわたって、安定で高信頼性のパケットデータ伝送を実現するのに用いられる一群の技術である。ＴＣＰの元々のデザインは、原則的にあらゆるタイプの下位の物理ネットワーク上で作動する、ストリームベースで信頼性の高いプロトコルを確立した。元々のＴＣＰでは、「スライディングウィンドウ」を使用し、パケットが送信側によって送信された後に、確認応答パケット（ＡＣＫ）が受信側から送られ、その後、送信側が新しいデータを送信することができるようになる、と仕様が定められた。

ＴＣＰの最初に普及したバージョン（1983年の４．２ＢＳＤ）はローカルエリアネットワーク（ＬＡＮ）において確実に作動した。ＴＣＰは当初はＬＡＮ上での実装を意図したものであったため、場合により、インターネットのような大規模な共有ネットワーク（輻輳の可能性があるネットワーク）において許容できる性能を提供できないことがあった。したがって、ＴＣＰのより最近の実装では、広範囲に分散した共有ネットワークにおいて最小損失で最大データスループットを保証するように進展した。ＴＣＰプロトコルのこれら最近のバージョンは、ウィンドウサイズを制御するだけでなく、各「バースト」すなわち「セグメント」において共に送信されるパケット数、パケットサイズ、および受信側によるパケット確認応答のタイミングも制御する。

例えば、ＴＣＰの「Ｔａｈｏｅ」実装は、輻輳制御（いわゆる、「スロースタート」アルゴリズムによるもの）および輻輳回避（乗算減少によるもの）において、大幅な改良を導入した。このアルゴリズムでは、送信側は、受信側によって通知された広告ウィンドウと輻輳ウィンドウの小さい方の値によって決定されるバイトを送信できる。輻輳ウィンドウ（ＴＣＰ標準では[cwnd]と呼ばれる変数）が、最初は、１パケット（セグメント）の値に設定される。次に、ＡＣＫを連続的に受け取った後に、[cwnd]の値を２倍する。この結果、[cwnd]の値は一般に予測される指数関数的増加となる。

Ｔａｈｏｅはまた、送信ウィンドウしきい値（[ssthresh]）を保持する変数を使用する。このしきい値は、受信側が通知した広告ウィンドウサイズに初期化される。送信タイムアウトの後に（例えば、ＡＣＫが受信されない場合）、アルゴリズムは現在のウィンドウサイズの半分を[ssthresh]に割り当て（乗算減少）、[cwnd]が再度１の値に設定されて、スロースタートフェーズが再度開始される。

ＴＣＰの「Ｒｅｎｏ」バージョンは、早期回復と呼ばれる別の最適化を導入して、後続の再送信性能を改善した。重複ＡＣＫが受信されると、ＲｅｎｏＴＣＰ送信側は、[ssthresh]を[cwnd]の半分に設定し、喪失セグメントを再送信する。次に、重複ＡＣＫを受信するごとに、[cwnd]が１セグメントずつ増加される。

「Ｎｅｗ Ｒｅｎｏ」と呼ばれるＲｅｎｏに対して提案された改良は、Ｒｅｎｏに関する２つの別の問題点に対応することを試みる。特に、[ssthresh]の値が小さいと、スロースタートフェーズが早く終了してしまい、次に[cwnd]が緩やかに増加する可能性がある。一方、[ssthresh]の値が大きい値と、送信側がパケットを過剰に供給し（すなわち、データパケットのバーストの送信が長過ぎる）、輻輳を発生する可能性がある。Ｎｅｗ Ｒｅｎｏは、送信側において間隔の詰まったＡＣＫの到達時間を測定して、ネットワークの「帯域幅遅延積」に等価なバイトを計算することによって、[ssthresh]を最適化することを試みる。

ＴＣＰプロトコルに関するより多くの情報が、各種のインターネット技術協議委員会（ＩＥＴＦ）のコメントに対する要求（ＲＦＣ）（Internet Engineering Task Force(IEFC)Request for Comment(RFC)）文書に記載されている。これらの文書は、例えば、
ＲＦＣ２００１「ＴＣＰスロースタート、輻輳回避、高速再送信および早期回復アルゴリズム（TCP Slow Start, Congestion Avoidance, Fast Retransmit and Fast Recovery Algorithms）」１９９７年１月、および、
ＲＦＣ２５８２「ＴＣＰ早期回復アルゴリズムに関するＮｅｗ Ｒｅｎｏの改良（the new Reno modification to TCP's Fast Recovery Algorithm）」１９９９年４月、である。

これらの文書は、インターネット技術協議委員会（ＩＥＴＦ）から、それらのｗｅｂサイト HYPERLINK "http://www.ietf.org/" http://www.ietf.org/で入手できる。

さらに、Ｎｅｗ Ｒｅｎｏによって使用されるしきい値最適化方法の説明は、Borellaらに特許された米国特許第6,643,259号に記載されている。

本発明は公知のＴＣＰプロトコルの改良である。詳細には、ＡＣＫを処理する際に、本発明は当初に送信されたバースト内のデータ量と確認応答されたデータ量とを比較する。

確認応答されたデータ量が当初のバーストサイズと同一である場合、ＴａｈｏｅのＴＣＰにおける従来の「スロースタート」アルゴリズムと同様に、バーストサイズが増加される。

しかし、ＡＣＫデータ量が、当初のバーストよりも少ないデータ量を対象とする場合、Ｎｅｗ Ｒｅｎｏ ＴＣＰアルゴリズムと同様に、バーストサイズは同一に維持される。

さらに、送信を待つ追加データが存在しない場合、バーストサイズは変化しない。

本発明の好ましい実施形態を以下に説明する。

図１は、本発明の例示の実施形態における典型的はデータネットワーク１０を示すブロック図である。データネットワーク１０は、バックボーンネットワーク１２（例えば、インターネットまたはキャンパスネットワーク）、第１ネットワーク装置１４、および第２ネットワーク装置１６を有する。バックボーンネットワーク１２は、多数の通信システムによって使用されるリソースを共有できる。さらに、複数のローカルアリアネットワーク（「ＬＡＮ」）２０が存在してもよい。データパケットは、バックボーンネットワーク１２を介して、第１ネットワーク装置１４と第２ネットワーク装置１６との間で相互に伝送される。例えば、装置１４，１６には、インターネット上の公衆通信回線アドレス（public network address）が割り当てられる。第１ネットワーク装置１４と第２ネットワーク装置１６との間のデータチャネルは、ルータまたはゲートウェイ（２４、２６）を有してもよい。しかし、他のネットワークタイプおよびネットワーク装置も使用可能であって、本発明は、例示の実施形態に記載されるデータネットワークおよびネットワーク装置に限定されない。

本発明の好ましい一実施形態においては、第１ネットワーク装置１４および第２ネットワーク装置１６は、パーソナルコンピュータ、電話、大容量データ装置、または他のネットワーク上で利用できる装置であってもよい。大容量データ装置は、Ｗｅｂ−ＴＶセットおよびデコーダ、対話式ビデオゲームプレーヤ、またはマルチメディアアプリケーションを実行するパーソナルコンピュータを含むことができる。電話は、ＶｏＩＰ（Voice over Internet Protocol）装置（携帯型または据置型）、またはオーディオアプリケーションを実行するパーソナルコンピュータを含むことができる。ただし、データフローの両端は、別の種類のネットワーク装置を含むことができ、本発明はパーソナルコンピュータ、電話、または大容量データ装置に限定されない。

本発明の好ましい実施形態におけるネットワーク装置およびルータは、米国電気電子技術者学会（「ＩＥＥＥ」）、国際電気通信連合（「ＩＴＵ」）通信規格セクタ、インターネット技術協議委員会（「ＩＥＴＦ」）によって提案された規格、または他のプロトコルに基づくネットワークシステム１０と情報をやりとりできるネットワーク装置を含む。ＩＥＥＥ規格はWorld Wide Web上のUniversal Resource Locator（「ＵＲＬ」）「 HYPERLINK "http://www.ieee.org" www.ieee.org.」で見ることができる。ＩＴＵ（以前は、ＣＣＩＴＴとして公知であった）規格はＵＲＬ「www.itu.ch.」で見ることができる。ＩＥＴＦ規格はＵＲＬ「www.ietf.org.」で見ることができる。当然のことながら、図１の構成および装置は例示の目的だけであって、本発明は特定のプロトコルまたはネットワーク装置の種類に限定されない。

さらに、データネットワーク１０の構成は、図１に示されるような１つのバックボーンネットワーク１２および１つのＬＡＮ２０に限定されない。データネットワーク構成１０内のさまざまな場所において多数のデータネットワークおよび／または多数のローカルエリアネットワークを有する、データネットワーク１０の多くの異なる構成が可能である。

本発明のネットワーク装置（１４，１６）の動作環境は、少なくとも１つのプログラム可能なデータプロセッサまたは信号プロセッサ（本明細書では中央処理ユニット（「ＣＰＵ」）と称する）を有するネットワークインタフェースコントローラ（「ＮＩＣ」）を含む。コンピュータプログラミングの当業者の通例に従い、本発明は以下に、特に指定しない限り、ＣＰＵによって実行される動作または命令の作用および記号表現に関して説明する。このような作用および動作もしくは命令は、「コンピュータで実行」されると称する。

当然のことながら、作用および記号表現される動作もしくは命令は、ＣＰＵによる電気信号の操作を含む。電気信号は一般にデータビットを表し、データビットはさらに、ＣＰＵに結合されたメモリシステム内の記憶域に格納され、または記憶域から読み出されることにより、他の信号処理と同様に、ＣＰＵ動作を再構成または変更することができる。データビットが保持されている記憶域は、データビットに対応する特定の電気的、磁気的、光学的、または有機特性を有する物理的位置である。

データビットはまた、コンピュータ読取可能媒体であり、この媒体は、磁気ディスク、光ディスク、有機メモリ、およびＣＰＵによって読取可能な任意の他の揮発性（例えば、ランダムアクセスメモリ（「ＲＡＭ」）もしくは不揮発性（例えば、リードオンリーメモリ「ＲＯＭ」）記憶システムを含む。コンピュータ読取可能媒体は、協働または相互接続されたコンピュータ読取可能媒体を含む。これら協働または相互接続されたコンピュータ読取可能媒体は、処理システム上に排他的に存在するか、あるいは、処理システム内または処理システムから遠隔にある複数の相互接続された処理システムに分散されている。

＜ネットワーク装置のプロトコルスタック＞
図２は、データネットワーク１０におけるネットワーク装置のプロトコルスタック５０を示すブロック図である。当技術分野では公知のとおり、コンピュータネットワークを記述するために、開放型システム間相互接続（「ＯＳＩ」）モデルが使用される。ＯＳＩモデルは、下位から上位に、物理層、データリンク層、ネットワーク層、トランスポート層、セッション層、およびアプリケーション層を含む７層から成る。物理層はデータビットを通信リンクを介して転送する。データリンク層はデータのエラーのない（error free）フレームを転送する。ネットワーク層はデータパケットを転送およびルーティングする。

プロトコルスタックの最下位層は物理層である。物理層は物理媒体インタフェース５２を有し、このインタフェース５２は、信号をワイヤ、同軸ケーブル、光ファイバなどの伝送媒体に送り出す。つまり、信号を電磁波として伝送する。物理媒体インタフェース５２はまた、伝送媒体から信号を読出し、この信号をデータリンク層５４に提供する。

データリンク層は、例えば媒体アクセス制御（「ＭＡＣ」）層５４である。当技術分野では公知のとおり、ＭＡＣ層５４は物理層を経由して伝送媒体へのアクセスを制御する。通常のＭＡＣ層５４は、イーサネット（Ethernet）（登録商標）用のＩＥＥＥ８０２．３およびケーブルモデム用のＩＥＥＥ８０２．１４を含む。しかし、他のＭＡＣ層プロトコル５４も使用可能であって、本発明はこれにより限定されるわけではない。

データリンク層の上位にはインターネットプロトコル（「ＩＰ」）層５８がある。ＩＰ５８はＯＳＩモデルのネットワーク層にほぼ一致するが、一般には、ＯＳＩモデルの一部として定義されていない。当技術分野では公知のとおり、ＩＰ５８は、ネットワーク内またはネットワーク間のトラフィックをルーティングするように設計された、メッセージのアドレス指定および配信のプロトコルである。

インターネット制御メッセージプロトコル（「ＩＣＭＰ」）層５６は、ネットワーク管理のために使用される。ＩＣＭＰ５６の主機能は、エラーレポート、到達可能性テスト（例えば、「ピンギング（pinging）」）、輻輳制御、ルート変更通知、パフォーマンス、サブネットアドレス指定などを含む。ＩＰ５８は確認応答のないプロトコルであるため、データグラムは廃棄されてもよく、ＩＣＭＰ５６がエラー通知のために使用される。ＩＣＭＰ５６に関する詳細な情報は、参照により本明細書に引用されているＲＦＣ−７９２を参照のこと。

ＩＰ５８およびＩＣＭＰ５６の上位にはトランスポート層があり、この層はユーザデータグラムプロトコル（「ＵＤＰ」）層６０または伝送制御プロトコル（「ＴＣＰ」）層６２であってもよい。当技術分野では公知のとおり、ＵＤＰ６０はデータグラムを用いる通信のコネクションレスモードを提供する。

本発明の好ましい実施形態の特に重要な点は、コネクション型伝送制御プロトコル（「ＴＣＰ」）層６２を含むトランスポート層６２である。ＴＣＰに関する詳細な情報は、参照により本明細書に引用されているＲＦＣ−７９３およびＲＦＣ−１３２３を参照のこと。本発明におけるＴＣＰ層６２に関連する動作は、以下に詳細に説明される。

トランスポート層の上位はアプリケーション層であり、ここにネットワーク装置の所望の機能を実行するアプリケーションプログラムが存在する。例えば、ネットワーク装置１６用のアプリケーションプログラムはプリンタアプリケーションプログラムを有してよく、一方、ネットワーク装置１４用のアプリケーションプログラムはファクシミリアプリケーションプログラムを含んでもよい。一般に、アプリケーション層は動的ホスト構成プロトコル（「ＤＨＣＰ」）層６６および／もしくはファイル転送プロトコル（「ＦＴＰ」）層６８、または、ハイパーテキスト転送プロトコル（「ＨＴＴ」）層６７などのアプリケーションを含む。本発明の好ましい実施形態においては、使用する特定のアプリケーション層は重要ではない。なお、プロトコルスタック５０内で、より多数または少数のプロトコル層を使用することもできる。

＜パケットフォーマット＞
ＩＰ５８はＩＰパケット形式のデータを伝送およびルーティングする。図３はこのようなパケット８０の１つの構造を示すブロック図である。パケット８０はヘッダフィールド８２およびペイロードフィールド１０４を有する。パケット８０のペイロードフィールド１０４は一般に、１つのネットワーク装置から他のネットワーク装置に送信されるデータを含む。ただし、ペイロードフィールド１０４は、ＩＣＭＰ５６メッセージなどのネットワーク管理メッセージ、または、ＵＤＰ６０、ＴＣＰ６２、ＦＴＰ６８、もしくはＤＨＣＰ６６などの他のプロトコルのデータパケットも含むことができる。

ヘッダフィールド８２は、サービスタイプ（「ＴＯＳ」）フィールド８４、全長フィールド８６、識別子フィールド８８、フラグメントフィールド９０、ホップ数（「ＨＯＰ」）フィールド９２、プロトコルフィールド９４、およびヘッダチェックサムフィールド９６を有する。ＩＰ５８のパケット８０の構造に関する詳細な情報は、参照により本明細書に引用されているＲＦＣ−７９１を参照のこと。発信元アドレスフィールド９８は、ＩＰ５８のパケットをデータネットワーク１０上に送出するネットワーク装置のＩＰ５８アドレスを含むことができる。宛先アドレスフィールド１００は、データネットワーク１０上のＩＰ５８パケット８０の指定された受信者であるネットワーク装置のＩＰ５８アドレスを含むことができる。ＩＰ５８ヘッダフィールド８２はさらに、オプションフィールド１０２および当業者には公知の他のフィールドを含むこともできる。

＜ＴＣＰの動作＞
当技術分野では公知のとおり、ＴＣＰ６２の用途の１つは、送信側から受信側へのデータパケット８０の順序どおりの配信を保証することである。ここでは、第１ネットワーク装置１４を送信側とし、第２ネットワーク装置１６を受信側と称する。ただし、いずれのネットワーク装置も送信側または受信側になることができる。パケットが損失するか、または破損して到達する場合、ＴＣＰはこのようなパケットの再送信を保証する。さらに、ＴＣＰ６２はデータネットワーク１０上の輻輳を監視することを試み、これに応じて、データ伝送速度を調整する。限定されたネットワークリソースをデータストリームが競合するとき、帯域幅を適切に割り当てる試みにおいてフロー制御プロセスが選択される。ＴＣＰ６２は、スライディング「ウィンドウ」を使用することによって、そのフロー制御を実行する。スライディングウィンドウによって、発信元アプリケーションを有する送信側が宛先アプリケーションを有する受信側１６に、確認応答を待つ必要なく、複数のパケットを送信できる。受信側１６によるフロー制御は「フロー制御」と呼ばれるのに対して、送信側１４によるフロー制御は「輻輳制御」と呼ばれる。

送信側１４と受信側１６との間のＴＣＰコネクションは、当業者には公知の３方向ハンドリングシェイクによって確立される。コネクションのセットアップの間、受信側１６のＴＣＰ６２プロセスは、送信側１４のＴＣＰ６２に最大セグメントサイズ（「ＭＳＳ」）値を送信するオプションを有する。これは、受信側のネットワーク装置に引き起こされるリンク上のパケットフラグメンテーションを防止するためになされる。使用されるデフォルト値は一般に５３６バイトであるが、他の値を使用することもできる。一般に、大きい最大セグメントサイズがデータネットワーク１０によって許容される場合、大きい最大スループットが得られる。

データパケットと確認応答パケット（「ＡＣＫ」）の交換の間、フロー制御は受信側によってなされ、受信側は提供ウィンドウ（広告ウィンドウ）（[awnd]）を送信側に通知する。[awnd]は、受信側１６がバッファのオーバーフローなく現在受け取ることができるデータ量を表す。提供ウィンドウおよび未処理の確認応答がまだであるパケットを考えると、受信側１６の有効ウィンドウは現在送信できるデータ量として定義される。ＴＣＰ６２の実装が異なれば、デフォルトの提供ウィンドウも異なる。典型的な値は、２０４８バイトの送信および受信バッファ、または４０９６バイトの送信および受信バッファである。

輻輳制御はさらに複雑である。送信側１４のＴＣＰ６２は、輻輳を感知するのに極め少数の限定された方法しか持たない。輻輳の３つの兆候は、パケット損失の感知、変動するラウンドトリップ遅延、および重複する確認応答（ＡＣＫ）である。限定された情報量とデータネットワーク１０からのフィードバック受信の遅れを考えると、ＴＣＰ６２がネットワーク状態に即時に適応することは困難である。

一般に、ＴＣＰ６２はパケット損失を利用して、ネットワーク内で輻輳が発生したことを推定する。典型的なモデムデータネットワークの物理リンク上のエラーは、光ファイバケーブルなどの長距離物理媒体の改良によって、極まれに発生するのみである。しかし、無線リンクは依然としてエラーを生じやすい。物理損失割合は一般に極めて小さく、１％よりも極めて小さいため、確認応答がされていないデータパケットはいずれも、輻輳による損失と考えられる。エラーを含むと考えられるデータパケットが受信側１６で受信されると、受信側１６で廃棄され、確認応答されない。確認応答パケットがないために送信側１４でネットワーク輻輳が認識されると、第１ネットワーク装置１４上のＴＣＰ６２プロセスは、ネットワークにパケットを投入する速度を制限する。このタスクを実行するために、送信側１４のＴＣＰ６２プロセスは輻輳ウィンドウ（[cwnd]）の値を変更する。輻輳ウィンドウ[cwnd]は、データネットワーク１０で許容される未処理バイトの最大数である。

ＴＣＰの典型的な実装では、[cwnd]の値は、輻輳の存在によって減少され、輻輳が検出されないときは増加される。この作用により、データネットワーク１０をトラフィックで溢れさせることなく、データネットワーク１０の状態を変更する安定したフィードバックを可能にする。

送信側１４のＴＣＰ６２プロセスはさらに、ラウンドトリップ遅延時間（「ＲＴＴ」）および遅延変動（「Ａ」）の実行推定値（running estimate）を維持して、パケット損失が発生したか否かを決定する。したがって、データパケットを送信後に送信側１４がこれらパラメータによって指定された時間内に受信側１６から確認応答パケット（「ＡＣＫ」）を受信しない場合、パケット損失が推定されてデータパケットが再送信される。

＜ＴＣＰ Ｒｅｎｏ＞
次に、本発明によって提供される改良を説明する前に、ＴＣＰのいわゆる「Ｒｅｎｏ」実装に従う典型的な標準ＴＣＰフロー制御を説明する。図４は伝送制御プロトコル６２を表すブロック図である。コネクションのセットアップ後、送信側１４のＴＣＰ６２プロセスは開始状態１２２にある。開始状態１２２において、輻輳ウィンドウは初期ウィンドウ値（「ＩＷ」）に設定される。一般に、ＩＷはＭＳＳと同一であるが、ＴＣＰの特定の実装では、ＩＷをＭＳＳの２倍または４倍に設定する。特に、遅延ＡＣＫを使用する受信側１６と通信するとき、ＭＳＳよりも大きいＩＷが第１パケットの不必要な遅延を無くす。加えて、電子メールまたはハイパーテキストマークアップコネクションなどのトランザクション指向コネクションは、一般に、各コネクション当たり少量のデータを送信する。十分に大きなＩＷは１つのウィンドウ内でこのデータの全てを転送することができるので、トランザクション速度が大幅に増す。

さらに、開始状態１２２においては、パケット出力処理モジュール１５０内におけるスロースタートフェーズ１２６から輻輳回避フェーズ１３０への遷移に対して、しきい値が設定される。このしきい値[ssthresh]は、第２ネットワーク装置１６からの提供ウィンドウ[awnd]に設定される。

ＴＣＰ６２プロセスのパラメータが開始状態１２２において初期化されると、送信側１４はデータの初期ウィンドウを送信し、リターントリップタイマを設定する。

次に、ＴＣＰ６２プロセスはパケット処理１５０のスロースタートフェーズ１２６に入る。スロースタートフェーズ１２６はＴＣＰ６２の輻輳制御構成要素の1つである。輻輳回避フェーズ１３０と組み合わせることで、送信側１４が新しいＡＣＫ１２８を受信したときのみ[cwnd]を増加することによって、エンドツーエンドのネットワーク帯域幅に試験的に探りを入れる。スロースタートフェーズ１２６の間、輻輳制御ウィンドウサイズは新しいＡＣＫの受信１２８の度に増加される。このように、パケットがデータネットワーク１０に導入される速度は、ＡＣＫが送信側１４に返送される速度に応じてゲート制御される。これにより、送信側１４と受信側１６との間の流量保存則（conservation of flow）が維持される。

スロースタートフェーズ１２６に入る際、[cwnd]は開始状態１２２においてすでにIW に設定されている。しかし、受信側１６からの各新しいＡＣＫ受信１２８を受け取るごとに、送信側１４はＭＳＳまで[cwnd]を増加させ、リターントリップ時間をリセットする。このように、送信されるセグメント数は、完全に確認応答された[cwnd]の度に、実質的に２倍になる。なお、完全に確認応答されるのは、ほぼラウンドトリップ時間ごとである。スロースタートプロセス１２６は続行されて新しいＡＣＫを受信１２８し、受信側１６によって定義される提供ウィンドウ[awnd]に達するか、またはしきい値[ssthresh]に達するかのいずれかまで、[cwnd]を増加させ、輻輳回避フェーズ１３０に遷移することを通知する。

しかし、送信側１４が時間ＲＴＴ＋４Ａ以内にいずれのパケットについてもＡＣＫを受信しない場合、タイムアウト１３４となり、最も古い確認応答されていないパケットおよびこのパケットの後の全ての送信されたパケットが失われたと推定する。これは通常、重大な輻輳イベントの表示である。タイムアウト１３４では、最も古い確認応答されていないパケットが再送信され、スロースタートしきい値[ssthresh]が実質的に、タイムアウト前の[cwnd]の値の半分に設定され、[cwnd]がＭＳＳに設定され、リターントリップタイマがリセットされ、ＴＣＰ６２プロセスがスロースタートフェーズに再度入る。

輻輳回避フェーズ１３０は、情報路容量の過剰使用を禁止するＴＣＰ６２輻輳制御の１つの構成要素である。輻輳ウィンドウがスロースタートしきい値と交差する（例えば[cwnd]≧[ssthresh]）と、輻輳回避フェーズ１３０に入る。輻輳の特定の形態が検出されるか、または受信側１６でデータ処理できる最高速度に送信側１４が近付きそうなとき、輻輳回避フェーズ１３０に入る。この状態の目標は、[cwnd]を除々に増加して、送信側１４がデータネットワーク１０で利用できる帯域幅を超えて送信しないようにすることである。輻輳回避フェーズ１３０の[cwnd]を増加させるプロセスは、受信側１６からＡＣＫを受信１３２する度に[cwnd]が直線的に増加する点で、スロースタートフェーズとは異なる。再度、データパケットが時間ＲＴＴ＋４Ａ以内に確認応答されない場合、ＴＣＰ６２は前述のとおりタイムアウト１３４して、スロースタートフェーズ１２６に入る。

このことから、ＴＣＰ６２プロセスについて送信側１４から受信側１５へのデータスループットの時間依存性を考慮する。ＴＣＰ６２プロセスは開始状態１２２において開始し、スロースタートフェーズ１２６に入る。スロースタートフェーズ１２６がタイムアウトしない場合、輻輳ウィンドウ[cwnd]がスロースタートしきい値[ssthresh]と交差すると、ＴＣＰ６２プロセスは輻輳回避フェーズ１３０に入る。輻輳回避フェーズ１３０では、データネットワーク１０が送信側１４のパケット挿入速度をサポートできなくなるまで、輻輳ウィンドウおよびスループットが時間にともない直線的に増加する。その後、パケットが損失されて確認応答されず、タイムアウト１３４が発生する。タイムアウト１３４が発生すると、スロースタートしきい値[ssthresh]が直前の輻輳ウィンドウ[cwnd]の半分にリセットされ、ＴＣＰ６２プロセスがスロースタートフェーズ１２６に再度入る。輻輳ウィンドウ[cwnd]が新しいスロースタートしきい値[ssthresh]と交差すると、ＴＣＰ６２プロセスは輻輳回避フェーズ１３０に再度入る。

＜ＴＣＰのＮｅｗ Ｒｅｎｏ＞
前述の図４の状態に加えて、ＴＣＰ６２はさらに、高速再送信および早期回復を可能にする。重複ＡＣＫが送信側１４で受信される場合、これは特殊ケースである。軽度の輻輳または一時的輻輳の状態下では、高速再送信および早期回復がＴＣＰ６２性能を向上できる。例えば、高速再送信は、ＴＣＰ６２が第３の重複ＡＣＫを受信するときに取るアクションである。この状況は、少なくとも１つのパケットが伝送状態から外れて損失されたが、少なくとも３つの後続のデータが無事に到達していることを示す。

[cwnd]をＭＳＳにまで減少してスロースタートフェーズ１２６に入るのではなく、ＴＣＰ６２のＮｅｗ Ｒｅｎｏは、損失されたと推定されるパケットを直ちに再送信し、[ssthresh]を[cwnd]の半分にまで減少させ、[cwnd]を[ssthresh]＋３ ＭＳＳとなるように設定する。これらの調整は、「損失」パケット後に３つのパケットが受信された以降は、送信側がさらの３つのパケットを送信できることを表している。高速再送信が実行された後、早期回復状態に入る。

早期回復は、最後の確認応答されていないパケットが確認応答されるのを待つが、後続の送信パケットが確認応答されている場合は、送信側１４が新しいパケットを送信するのを許可する。早期回復においては、パケットがネットワークによって再度要求されているか、または輻輳が軽度もしくは一時的であるかのいずれかであると、ＴＣＰ６２が仮定する。重複ＡＣＫが受信されると、輻輳が軽度であると推定されて、[cwnd]がＭＳＳ分増加され、伝送中のパケットが受信側１６により受信されたことより、送信側が別のパケットを送信するのを許可する。新しいＡＣＫが受信されると、「損失」パケットの伝送中のパケットの全てが受信されたことを示す。次に、[cwnd]は[ssthresh]に設定され、輻輳回避フェーズ１３０に入る。早期回復の間においてＴＣＰ６２の送信側がタイムアウト１３４すると、スロースタートフェーズ１２６に入る。

＜ＡＣＫでカバーされるデータ量に相当するバーストサイズの設定＞
ＴＣＰ６２の従来のＮｅｗ Ｒｅｎｏ実装においては、送信側１４は比較的小さい「バースト」でパケットを送信できる。例えば、送信側１４はわずか４つのパケットを含むバーストを送信できる。典型的なＮｅｗ ＲｅｎｏのＴＣＰの受信側１６は、２つのパケットを受信する度に、ＡＣＫを送信する。典型的な送信側１４のルールは、ＡＣＫを受信する度に、ＴＣＰ送信ウィンドウに従って、送信側が新しいバースト（４パケット）を送信する。

この結果、送信側１４と受信側１６との間で「伝送状態にある」パケット数が増加する。これは、ネットワークのスループットを最大にするために望ましい。しかし、これは、受信側１６が２つのパケットを受信後に直ちにＡＣＫを送るというＴＣＰルールを実装する場合にだけ当てはまる。これは当初のＴＣＰプロトコルにおける規定であるが、残念なことに、この規定は、ＴＣＰプロトコル規格、ＲｅｎｏとＮｅｗ Ｒｅｎｏのいずれにも要件とされていない。したがって、これは発生を保証できない。

実際に、例えばMicrosoft Window 2000（「Ｗｉｎ２ｋ」）オペレーションシステムによって使用されるような、特定のＴＣＰ実装は、異なるＡＣＫルール使用していることが確認されている。特に、Ｗｉｎ２ｋの送信側１４は受信バーストの各全グループに対してＡＣＫを送信する。したがって、これは最初のパケットの受信後に何らかの遅延を伴って発生する。各ＡＣＫが送信側１４による別のバーストの送信（再度、４パケット）をトリガーするため、Ｗｉｎ２ｋ実装において「伝送状態にある」パケット数は、この状況では、最初の４パケットのバーストサイズ以上に増加しない。したがって、得られるスループットは全く許容できないものである。

受信側１６が２つのパケット毎にＡＣＫを送信する規定を実装すれば、規格方式は良好に機能する。しかし、ＴＣＰのＲｅｎｏまたはＮｅｗ Ｒｅｎｏバージョンにおけるように、２つのパケット毎のＡＣＫが常時要求されるわけではない。したがって、受信側によっては、２つのパケット毎よりも少ない頻度でＡＣＫを送信するものもある。このような場合には、短いバーストが単一確認応答のみをトリガーし、標準ＴＣＰ ＡＣＫ遅延後のみ確認応答をトリガーする可能性がある。

本発明の目的は、標準アルゴリズムが使用する最初のウィンドウサイズを使用し続けるのではなく、このような場合におけるバーストサイズを増加することである。これにより、頻度の低い確認応答を受信側が実装する場合であっても、送信側と受信側は高速で通信できる。

したがって、本発明は標準ＴＣＰ実装の改良を提供する。本発明により、受信側１６が２つのパケット毎に確認応答しない場合であっても、ＴＣＰ送信側１４は高性能を達成できる。

図５は本発明によって実行されるステップを示すフローチャートである。ステップ５００は出力処理ブロック１５０によって実行される。完全なバーストが送出されと、バースト進行中フラグが設定されて、後続のステップが実行される入力処理１６０に指示される。

なお、パケット出力処理１５０は、（ａ）進行中のバーストがない場合、または（ｂ）送信される現在のバースト内に空きがある場合に、別のパケットの送信しか必要としない。一般に、一度に、１つの追跡される未処理バーストのみが存在する。なお、これは伝送状態にあるパケットの全体数を制限するものではない。

次のステップ５０１は、入力プロセス１６０がＡＣＫを受信すると実行される。このステップは、確認応答されたデータ量と、バースト内で最初に送信されたデータ量とを比較する。したがって、このプロセスは、各バースト内で最初に送信されたデータ量の追跡記録を維持する必要があり、次に、各受信されたＡＣＫを各バースト内の対応するパケットに突き合わせる。このような情報は、以下に詳細に説明するように、ステータステーブル内に保持できる。

ＡＣＫが最初のバーストの全てをカバーする場合、ステップ５０２では、バーストサイズが、Ｔａｈｏｅのような従来の「スロースタート」アルゴリズムで指定されたウィンドウサイズパラメータ[cwnd]の増加に相当する量だけ増加される。例えば、この時点で、プロセスはＭＳＳ分バーストサイズを増加させてもよい。その後、ＴＣＰ処理は通常通り続行される。

しかし、ＡＣＫが最初のバースト内のパケット総数よりも少ない数のパケットをカバーする場合、ステップ５０３では、バーストサイズは変更されない。したがって、このステップは従来のＮｅｗ Ｒｅｎｏアルゴリズムと同様に作用する。再度、ＴＣＰ処理はこの時点から従来技術におけるのと同様に続行される。

ある時点で、ステップ５０４に達する。ここでは、送信されるべき追加データが待ち行列に存在するか否かをチェックするように、追加のテストがなされる。送信を待機している追加データが存在しない場合、バーストサイズはこの状態を維持する。

別の改良においては、本発明はバースト内のパケットサイズに敏感である。つまり、パケットサイズをチェックする。一例として、イーサネット（Ethernet）（登録商標）は現在通常、９０１８バイトの「ジャンボ」フレームを使用する。この状況では、バーストサイズ増加プロセスによって、このように大きいパケットでネットワークに輻輳を引き起こす可能性がある。このような場合、パケットサイズが小サイズ（例えば、４０９６バイト以下）である場合のみに、本発明を適用する。

本発明による別の改良の領域は、輻輳処理１３０においてもバーストサイズを制御することである。したがって、本発明の好ましい一実施形態においては、輻輳処理プロセス１３０内でステップ５１０が実行され、バーストサイズ値が輻輳イベントにおいて初期値にリセットされる。これは、Ｔａｈｏｅの古典的なスロースタートルールが[cwnd]に適用するのと類似である。しかし、別の実装もバーストサイズを減少でき、バーストサイズを完全にリセットするのではなく、DECnetシステムで使用されるいわゆるFlower/Ramakrishnan輻輳ルールと同様にすることができる

なお、本発明は、前述したものに比べてより汎用的であることは理解されるであろう。例えば、ステップ５０１において他のしきい値ＡＣＫ量としてもよい。ステップ５０１についての前述の説明で仮定した事項は、従来のＡＣＫ手順で使用されたことである。ここで、従来の手順では２つのパケット毎に受信側１６がＡＣＫを送出する。しかし、本発明の一変形形態では、ＡＣＫ当たりのパケットのしきい値量を選択する。このしきい値は２パケットよりも大きくできるが、最大値はバーストサイズである。しきい値量（またはそれ以上）のＡＣＫがバーストサイズの増加を発生させるように、しきい値が作用する。この変形形態によってバーストサイズの急速増加が可能になる。本質的には、受信側１６が「ＡＣＫの２パケット」ルールを全く使用しない場合と同一速度でバースとサイズを増加できる。

前述の記載から明らかなように、本発明の実装は、ＴＣＰ層６２に複数のデータ構造を追加し、特定の他の機能を改良することによって実現できる。

第1に、各コネクション当たりのバーストサイズ（Ｎｅｗ Ｒｅｎｏ当たり）を追跡して維持することが、送信側のＴＣＰ層で必要とされる。これは、少なくとも以下のパラメータを、コネクションごとにコンテクストに維持することを必要とする。これらパラメータは、各コネクションのコネクション統計ブロック６００に格納される。このようなパラメータブロックの1つが、図６に示されている。パラメータは以下のとおりである。
−バースト進行中フラグ６０１（ビジーコネクションについては、大部分の時間で真である）
−Ｒｅｎｏのバースト内に存在する現在のパケット６０２
−バーストサイズ６０３（min＝current_default, max＝＝current_default*Ｎ（ここでＮは８）と定量化される）

現在のＲｅｎｏバーストサイズ６０３を記憶することで、さまざまなコネクションに対してバースト設定を確認できる。好ましい実施形態においては、これらパラメータはコネクション統計ブロック６００の終了時に記憶し、以前のＴＣＰ層６２の実装との後方互換性を維持する。

さらに、パケット処理がＲｅｎｏ ＡＣＫを監視するため、バーストサイズ全体にわたりよりさらなる制御を実装できる。特に、確認応答されたデータ量が全体の未処理バーストサイズの少なくとも半分（１／２）と等しいかそれ以上であり、送信する多数のデータが存在する場合、コネクションのバーストサイズ６０３パラメータは、段階的に（例えば、標準Ｒｅｎｏのスロースタートルールに従って）増加される。次に、パケット処理１５０は通常通りに進行し、ＡＣＫを受信すると、一般に要求されるとおり、別のバースト（最大は有効ウィンドウサイズ[cwnd]）を送信する。

送信ウィンドウが満たされると、存在する現在のパケットのフィールド６０２がゼロにリセットされ、進行中バーストフラグ６０１が偽（false）に設定される。

スロースタート回復１２６はさらに、バーストサイズをデフォルト値にリセットするか、または標準タイムアウトルール（例えば、Ｒｅｎｏによって指定されたとおり）によってバーストサイズを段階的に減少させる必要がある。同様に、アイドル状態に入るコネクションもまた、バーストサイズをデフォルト値にリセットする。

本発明にはいくつかの利点がある。

Ｎｅｗ Ｒｅｎｏの「失速（stall）」を回避する。
特定の条件下では、標準Ｎｅｗ Ｒｅｎｏ ＴＣＰアルゴリズムはバーストサイズの増加を許容しない（例えば、Ｗｉｎ２ｋの例）。本発明はこの状況を回避し、バーストサイズが送信されたＡＣＫ数に関係なく増加することを保証する。

（Windows(登録商標)2000のような）固定ＡＣＫホールドオフタイマ（hold-off timer）を有するピアの高スループット。
大きい転送サイズに対して、３２のバーストサイズは、Windows（登録商標）2000では良好に機能していることは公知である。小さい転送サイズはパケット損失も少ない。本発明のシステムは、ＴＣＰ送信パケットルーチンを呼び出す度に、もはやバーストを送信しないので、小さいパケットを消費するピアのプロセス能力にプロセスが応える。理論的には、これは極めて好ましいスループットの向上である（従来技術におけるのと同様に、ピアコネクションのスループットを容易に超えることができる）。

大きい待ち行列深さにおける少ないパケット損失。
全ての転送サイズは、送出の準備がされているときはいつでも、ＴＣＰ送信プロセス１５０を呼び出すことができる。進行中のバーストが存在し、さらなるデータ送信が要求された場合、ウィンドウがこの時点でデータ送信を許容するならば、追加データが直ちに設定される。したがって、ピアへの出力は確認応答によって主として制御される。再度、プロセスはピアの使用量速度に大きく依存する。この結果、高速の無損失データ伝送が可能になる。

本発明を好ましい実施形態により図示し、説明してきたが、当業者には、添付の特許請求項に包含された本発明の範囲から逸脱することなく、形態または細部にさまざまな変更を加えるのが可能であることは理解されるであろう。

本発明を実装できるネットワークシステムのブロック図である。 プロトコルスタックを示す図である。 ＴＣＰ／ＩＰパケットの構造を示す図である。 本発明によるＴＣＰを実装するプロセスの高レベル図である。 本発明によるＴＣＰの処理を示すフローチャートである。 １つのコネクション当たりのデータ構造を示す図である。

符号の説明

８０ データバケット

Claims (10)

1. 一のデータ通信装置においてデータパケットを処理する方法であって、
   （ａ）前記一のデータ通信装置と他のデータ通信装置の間で許容される未処理のデータパケットの最大数である輻輳ウィンドウを保持する工程と、
   （ｂ）前記一のデータ通信装置からの１つのバースト内で共に送信されるデータパケットの最大数であるバーストサイズを保持する工程と、
   （ｃ）前記バーストサイズによって決定されたデータ量で、当初のデータパケットのバーストを送信する工程と、
   （ｄ）前記当初のデータパケットのバーストの確認応答（ＡＣＫ）を受信する工程であって、前記バーストにおける２つのパケットごとよりも少ない頻度でＡＣＫが受信される、工程と、
   （ｅ）前記ＡＣＫによって示されるパケット数が前記当初のデータパケットのバーストにおけるパケット数と同一の場合、前記輻輳ウィンドウを増加させる工程と、
   （ｆ）前記ＡＣＫによって示されるパケット数が前記当初のデータパケットのバーストにおけるパケット数よりも少ない場合、前記輻輳ウィンドウを減少させる工程と、
   （ｇ）前記当初のデータパケットのバーストのうちの少なくとも所定のデータ量について、前記ＡＣＫが確認応答を行うと、前記バーストサイズを増加させる工程であって、前記所定のデータ量は前記当初のバーストにおけるパケット数よりも少ない、工程と、
   （ｈ）前記当初のデータパケットのバーストのうちの前記所定のデータ量よりも少ない量について、前記ＡＣＫが確認応答を行うと、前記バーストサイズを同一サイズに維持する工程とを備え、
   さらに、前記ＡＣＫによって確認応答が行われたデータ量が、前記輻輳ウィンドウの半分よりも多く、かつ、送信待ち状態のデータパケットが存在する場合、前記バーストサイズを所定量増加させる工程とを備えた、データパケット処理方法。
2. 請求項１において、前記工程（ｄ）よりも後に、さらに、
   前記当初のデータパケットのバーストのデータ量以上の量について、前記ＡＣＫが確認応答を行う場合、前記バーストサイズを増加させる、データパケット処理方法。
3. 請求項１において、さらに、送信される追加データが存在しない場合、前記バーストサイズを同一に維持する工程を備えた、データパケット処理方法。
4. 請求項１において、前記データパケットがＴＣＰパケットである、データパケット処理方法。
5. 請求項１において、さらに、前記一のデータ通信装置がアイドル状態になると、前記バーストサイズをデフォルト値にリセットする工程を備えた、データパケット処理方法。
6. 請求項１において、さらに、データパケット損失が検出されると、前記バーストサイズをデフォルト値にリセットする工程を備えた、データパケット処理方法。
7. 請求項１において、さらに、
   （ｉ）進行中バーストフラグを保持する工程であって、前記当初のデータパケットのバーストを送信する前記工程（ｃ）が完了した後に、前記進行中バーストフラグが真値に設定される工程を備えた、データパケット処理方法。
8. 請求項７において、前記工程（ｇ）および工程（ｈ）は、前記進行中バーストフラグが前記真値に設定されている場合にのみ実行される、データパケット処理方法。
9. 請求項８において、前記ステップ（ｉ）は、さらに、前記当初のバーストにおけるパケットが所定のパケットサイズ制限値よりも短い長さのパケットを有する場合にのみ、進行中バーストフラグを前記真値に設定する、データパケット処理方法。
10. 請求項７において、前記バーストサイズが所定の最大バーストサイズに達した場合、前記進行中バーストフラグが偽値に設定される、データパケット処理方法。

Images