(57)【要約】【課題】  ネットワーク内でのパケットの再配列の後のトランスポート層の性能を改善するための改善された方法、システム及び製品を提供すること。【解決手段】  パケットが再送されるとＴＣＰ輻輳回避が実施され、パケットの再配列を示す早期確認通知（ＡＣＫ）を受け取った後に元の輻輳状態に戻され、それによりＴＣＰ帯域幅に対する不必要な制約がなくなる。再送されたパケットのＡＣＫが受け取られると、送信側でのＡＣＫの到着時刻に基づいて、そのＡＣＫが、再配列された元のパケットの受信によるものなのか又は再送されたパケットの受信によるものなのかが判断される。再送されたパケットのラウンド・トリップ・タイム（ＲＴＴ）が、送信側と受信側との間のネットワーク・リンクに関する計算された平均又は現在ＲＴＴよりかなり小さい場合には、再配列イベントの結果として再送が行われ、輻輳ウィンドウが再送前の値にリストアされ、それにより、ネットワーク・リンクが元の大きなスループットで引き続き動作することが可能となる。【選択図】      図７
2007534194.tif 000002
【特許請求の範囲】
【請求項１】
送信側（７０５）と受信側（７１０）との間にネットワーク接続を有し、該ネットワーク接続がある輻輳状態で動作するようになったネットワーク（７１５）においてパケットの再配列の後のトランスポート層（３１２）の性能を改善する方法であって、
第１の輻輳状態で動作するネットワーク接続を介してデータ・パケットが伝送されることを要求する、所定閾値数の第１の確認通知を受け取るステップと、
所定閾値数の第１の確認通知を受け取る前記ステップに応答して（８０５）、前記要求されたデータ・パケットを前記ネットワーク接続を介して送信側から受信側に伝送するステップ（８１５）と、
前記要求されたデータ・パケットが受信側によって受信されたことを示す第２の確認通知を受け取るステップ（８２０）と、
前記第２の確認通知が受け取られた時刻と前記要求されたデータ・パケットが伝送された時刻との差を計算するステップ（８２５）と、
送信側と受信側との間の前記ネットワーク接続を介するデータ・パケットの最小ラウンド・トリップ・タイムである閾値ラウンド・トリップ・タイムより前記差が小さい場合に、ネットワーク接続の前記輻輳状態を第１の輻輳状態に設定するステップ（８３５）と、
前記差が前記閾値ラウンド・トリップ・タイムより大きい場合に、ネットワーク接続の前記輻輳状態を前記第１の輻輳状態より小さい第２の輻輳状態に設定するステップと、
を含む、方法。
【請求項２】
前記要求されたデータ・パケットを伝送すると前記輻輳状態を第３の輻輳状態に設定するステップをさらに含む、請求項１に記載の方法。
【請求項３】
前記要求されたデータ・パケットを伝送する前に前記第１の輻輳状態を保存するステップ（８１０）をさらに含む、請求項２に記載の方法。
【請求項４】
前記第３の輻輳状態が前記第１の輻輳状態より小さい、請求項２に記載の方法。
【請求項５】
前記所定閾値数が３である、請求項１に記載の方法。
【請求項６】
前記輻輳状態が輻輳ウィンドウを含む、請求項１に記載の方法。
【請求項７】
前記輻輳状態がスロー・スタート閾値を含む、請求項１に記載の方法。
【請求項８】
前記要求されたデータ・パケットが伝送された時刻を保存するステップ（８１５）をさらに含む、請求項１に記載の方法。
【請求項９】
前記ネットワーク接続がＴＣＰプロトコルに準拠して動作する、請求項１に記載の方法。
【請求項１０】
前記閾値ラウンド・トリップ・タイムが、前記ネットワーク接続に関する平均ラウンド・トリップ・タイムの５０パーセントから７５パーセントの間である、請求項１に記載の方法。
【請求項１１】
送信側（７０５）と受信側（７１０）との間にネットワーク接続を有するネットワーク（７１５）におけるパケット再配列の後のトランスポート層（３１２）の改善された性能を提供するデータ処理システムであって、前記システムは、
前記データ処理システムと前記受信側との間のネットワーク接続が第１の輻輳状態で動作している状態でデータ・パケットが伝送されることを要求する、所定閾値数の第１の確認通知を受信側から受け取る（８０５）ための手段と、
前記所定閾値数の第１の確認通知を受け取る前記ステップに応答して、前記要求されたデータ・パケットを受信側に伝送する（８１５）ための手段と、
前記要求されたデータ・パケットが受信側によって受信されたことを示す第２の確認通知を受信する（８２０）ための手段と、
前記第２の確認通知が受け取られた時刻と要求されたデータ・パケットが伝送された時刻との差を計算する（８２５）ための手段と、
送信側と受信側との間の前記ネットワーク接続を介するデータ・パケットの最小ラウンド・トリップ・タイムである閾値ラウンド・トリップ・タイムより前記差が小さい場合に、前記ネットワーク接続を第１の輻輳状態で動作させる（８３５）ための手段と、
前記差が前記閾値ラウンド・トリップ・タイムより大きい場合に、前記ネットワーク接続を前記第１の輻輳状態より小さい第２の輻輳状態で動作させるための手段と、
を含む、システム。
【請求項１２】
前記要求されたデータ・パケットを伝送すると前記ネットワーク接続を第３の輻輳状態で動作させるための手段をさらに含む、請求項１１に記載のデータ処理システム。
【請求項１３】
前記要求されたデータ・パケットを伝送する前に前記第１の輻輳状態を保存する（８１０）ための手段をさらに含む、請求項１２に記載のデータ処理システム。
【請求項１４】
前記第３の輻輳状態が前記第１の輻輳状態より小さい、請求項１２に記載のデータ処理システム。
【請求項１５】
前記所定閾値数が３である、請求項１１に記載のデータ処理システム。
【請求項１６】
前記輻輳状態が輻輳ウィンドウを含む、請求項１１に記載のデータ処理システム。
【請求項１７】
前記輻輳状態がスロー・スタート閾値を含む、請求項１１に記載のデータ処理システム。
【請求項１８】
前記要求されたデータ・パケットが伝送された時刻を保存するための手段をさらに含む、請求項１１に記載のデータ処理システム。
【請求項１９】
前記ネットワーク接続がＴＣＰプロトコルに準拠して動作する、請求項１１に記載のデータ処理システム。
【請求項２０】
前記要求されたデータ・パケットが前記データ処理システムによって送られ、前記確認通知が前記受信側から前記ネットワークを介して送られる、請求項１１に記載のデータ処理システム。
【請求項２１】
請求項１から請求項１０までのいずれか１項に記載のステップを実行するように適合されたコンピュータ・プログラム・コード手段を含むコンピュータ・プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、データ処理システム・ネットワークにおいてデータを伝送すること、特に、インターネット又はそれに類似のネットワーク上でデータ・ブロックを伝送することに関する。より具体的には、本発明は、パケットを再配列する際のＴＣＰネットワークにおける輻輳制御の改善に関する。
【背景技術】
【０００２】
インターネットは、データ（テキスト、コード、イメージ、ビデオ、オーディオ又はそれらの混合体）及びソフトウェアを伝送し及び配布するための重要なパイプとなってきている。ユーザは、１４．４Ｋｂ／ｓないしは４５Ｍｂ／ｓ以上の多様なレベルの性能をもつバックボーンに接続する。さらに、伝送制御プロトコル／インターネット・プロトコル（ＴＣＰ／ＩＰ）が、クライアント、サーバ、及びそれらを結合する通信システム間の様々な異質性を許容する、インターネット及びイントラネット技術において幅広く実装された標準通信プロトコルとなっている。インターネット・プロトコル（ＩＰ）はネットワーク層プロトコルであり、伝送制御プロトコル（ＴＣＰ）はトランスポート層プロトコルである。ネットワーク・レベルにおいて、ＩＰは「データグラム」配信サービスを提供する。それに対し、ＴＣＰは、データグラム・サービスを介してコネクション・オリエンテッド・トランスポート・レベル・サービスを構築し、２つのＩＰホスト間の、保証されたバイト・ストリームの順次配信を提供する。ＴＣＰに送られたアプリケーション・データは、セグメントに分解されＩＰに送られる。セグメントはセグメント番号によって順序付けされる。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
データ伝送における信頼性は、データ汚染、データ損失、及びデータ再配列の３つの事象によって損なわれることがある。データ損失は、タイムアウト機構によって管理される。ＴＣＰは、伝送されたセグメントの確認通知（ＡＣＫ）を受信側から受け取る際の遅延を計測するためのタイマー（再送タイマー）を保持する。ＡＣＫが推定された時間内に到着しないときには、対応するセグメントが失われたものとみなされ、再送される。ＴＣＰは、入来パケットをそれらが順番どおりに再配列されるまでキューに入れる再組立キューを保持することによって、データの再配列、又はＩＰデータグラムとして伝送されたデータ・セグメントの順番どおりでない到着を管理する。このキューに入っているデータが順番どおりになったときにのみ、データがユーザの受信バッファに移動され、そこで該データがユーザに見られる。ＴＣＰは、セグメントが受信側に到着したときに該セグメントに対してチェックサムを行うことによってデータ汚染を管理する。チェックサムに関しては、ＴＣＰ送信側は、パケット・データのチェックサムを計算し、この２バイト値をＴＣＰヘッダに付加する。チェックサム・アルゴリズムは、ＴＣＰヘッダ及びデータにおけるすべての１６ビット・ワードの１の補数和の１６ビットの１の補数である。受信側は、受信したデータに対するチェックサム（ＴＣＰヘッダにおける２バイトのチェックサム・フィールドを除く）を計算し、それがヘッダのチェックサム値と一致することを確認する。チェックサム・フィールドはまた、ＩＰヘッダからの情報（４バイトの「ｓｒｃ  ｉｐ」アドレス、４バイトの「ｄｅｓｔ  ｉｐ」アドレス、２バイトのペイロード長、１バイトのプロトコル・フィールドを含む）を含有する１２バイトの擬似ヘッダを含む。
【０００４】
ＴＣＰプロトコルは、最初は、リンク・エラー率の低いネットワーク内で動作するように設計されたものであった、すなわち全てのセグメント損失は、大抵はネットワーク輻輳に起因するものであった。その結果として、送信側は、セグメント損失が検出される度に伝送速度を減少させる。しかしながら、再配列されたパケットが、ネットワーク輻輳において失われたパケットであると誤って判断されたときには、輻輳制御による関連する伝送速度の減少によって不必要なスループットの低下につながる。
【０００５】
パケットの再配列は、並列リンクの普及その他のパケットの再配列の要因があれば、ＴＣＰネットワークにおいてはよくあることである。例えば、多数の実アダプタが集合されて論理アダプタを形成するイーサチャンネルにおいては、パケット再配列は、パケットがこれらの複数のアダプタを介して並列に送られるときによく起こる。ＴＣＰにおいては、失われ又は再配列されたデータ・パケットに後続するいずれのデータ・パケットも、未着パケットが到着するまで受信側でキューに入れられる。次に、受信側が、全てのパケットをまとめて確認通知する。失われたパケットが再送されるのを受信側が待っている間は、それ以上データは送られない。しかしながら、パケットの再配列のために、ＴＣＰがネットワーク輻輳によってパケットが失われたと間違って推測するので、ＴＣＰセッションが、Ｆａｓｔ  Ｒｅｔｒａｎｓｍｉｔ  ａｎｄ  Ｒｅｃｏｖｅｒｙを自動的に実施する。再配列が、Ｆａｓｔ  Ｒｅｔｒａｎｓｍｉｔ  ａｎｄ  Ｒｅｃｏｖｅｒｙか、又はＳｅｌｅｃｔｉｖｅ  Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ  Ｏｐｔｉｏｎ（ＳＡＣＫ）による通知をうかつにもトリガしたときには、輻輳ウィンドウが半分にカットされ、タイムアウトが生じたときに、輻輳ウィンドウが１セグメント・サイズに設定され、スロー・スタートが強いられる。これらの機構は輻輳ウィンドウを自動的に減少させるので、こうしたパケットの再配列は、うかつにもネットワーク性能の激減を招く。パケットの再配列に起因するこうした不必要なスループットの低下を回避することが望ましいであろう。
【課題を解決するための手段】
【０００６】
したがって、本発明は、ネットワークにおいてパケットの再配列の後のトランスポート層の性能を改善するための改善された方法、システム及び製品を提供する。送信側と受信側との間のネットワーク接続がある輻輳状態で動作する本発明の１つの好ましい方法においては、この方法は、第１の輻輳状態で動作するネットワーク接続を介してデータ・パケットが伝送されることを要求する、所定閾値数の第１の確認通知を受け取るステップと、所定閾値数の第１の確認通知を受け取るステップに応答して、要求されたデータ・パケットをネットワーク接続を介して送信側から受信側に伝送するステップと、要求されたデータ・パケットが受信側によって受信されたことを示す第２の確認通知を受け取るステップと、第２の確認通知が受け取られた時刻と要求されたデータ・パケットが伝送された時刻との差を計算するステップと、送信側と受信側との間のネットワーク接続を介するデータ・パケットの最小ラウンド・トリップ・タイムである閾値ラウンド・トリップ・タイムより差が小さい場合に、ネットワーク接続の輻輳状態を第１の輻輳状態に設定するステップと、差が閾値ラウンド・トリップ・タイムより大きい場合に、ネットワーク接続の輻輳状態を前記第１の輻輳状態より小さい第２の輻輳状態に設定するステップを含む。
【発明を実施するための最良の形態】
【０００７】
ここで、本発明を、単なる例として付属の図面を参照しながら説明する。
ここで図面、特に図１を参照すると、本発明の好ましい実施形態を実装可能なデータ処理システム・ネットワークが示されている。データ処理システム・ネットワーク１００は、インターネット１０８のような少なくとも１つのネットワークを介して少なくとも１つのクライアント・システム１０６に結合された少なくとも１つのサーバ・システム１０４を含む。サーバ・システム１０４とクライアント・システム１０６との間のデータの伝送は、ＴＣＰ／ＩＰ仕様、並びに、Ｆｉｌｅ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ（ＦＴＰ）、ＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）、又はその他の類似の通信プロトコルに準拠させられる。認識されるように、単一のサーバ・システム１０４及び単一のクライアント・システム１０６のみが示されているが、データ処理システム・ネットワーク１００は、１つ又はそれ以上の接続、及びインターネット１０８を含むネットワークによって相互に接続された、あらゆる数のサーバ・システム及びクライアント・システム（図示せず）を含むことができる。
【０００８】
ネットワーク上でデータを伝送するために、伝送シーケンスの全ての部分が適切に実行されるようにするルール・セットをもつことが必要である。これらのルールの各々はプロトコルと呼ばれ、ルール・セットはプロトコル・スイートと呼ばれる。ＬＡＮ（ローカル・エリア・ネットワーク）及びＷＡＮ（ワイド・エリア・ネットワーク）のようなインターネットその他の種々のネットワーク上でデータを伝送するときに用いられる最も一般的なプロトコル・セットは、ＴＣＰ／ＩＰ（伝送制御プロトコル／インターネット・プロトコル）プロトコル・スイートによって提供されるものである。ＴＣＰ／ＩＰプロトコル・スイートは、異なるオペレーティング・システムで動作する種々の異なるタイプのコンピュータが互いに通信することを可能にする。ＴＣＰ／ＩＰは、ワールドワイド・インターネット、文字どおり地球全体にわたる１００万台を超えるコンピュータのワイド・エリア・ネットワークのための基礎を形成する。ＴＣＰ／ＩＰスイートに加えて、ＩＰＸ／ＳＰＸ（Ｉｎｔｅｒｎｅｔ  Ｐａｃｋｅｔ  Ｅｘｃｈａｎｇｅ／Ｓｅｑｕｅｎｃｅｄ  Ｐａｃｋｅｔ  Ｅｘｃｈａｎｇｅ）、及びＮｅｔＢｉｏｓを含む多くの他のネットワーク・プロトコル・スイートが存在する。独自の研究グループによって独創的に開発されていても、ほとんどのネットワーク・プロトコルは、オープン（使用を限定されない）スタンダードであり、それらの多くは、一連の数字の番号が付されたＲＦＣ（Ｒｅｑｕｅｓｔ  ｆｏｒ  Ｃｏｍｍｅｎｔ）ペーパとして公表されている。例えば、ＩＰプロトコルはＲＦＣ７９１である。ＲＦＣペーパは、インターネット上で又は種々のライブラリですぐに入手することができる。これらのネットワーク・プロトコル・スイートの各々は、それぞれは別個のものではあるが、層の組からなる類似の構造であり、その各層は通信タスクの異なる面を担っている。便宜上、以下の説明は、主にＴＣＰ／ＩＰプロトコルを用いるときの本発明の使用についてなされる。しかしながら、当業者であれば、本発明の原理はＴＣＰ／ＩＰプロトコルに関連して説明されているが、本発明はその他の種々のネットワーク・プロトコルにも同様に適用可能であることが分かるであろう。
【０００９】
フロー制御は、伝送メディアによって提供された帯域幅を最大限に活用するために、受信側と送信側との間の処理及びバッファリング容量の不一致を取り扱うプロシージャである。ＴＣＰフロー制御機構は、ＴＣＰエンドポイントがデータを放出する速度を制限するように専らエンドステーションにおいて動作する。しかしながら、ＴＣＰには明示的なデータ速度制御はない。基本的なフロー制御機構は、最後の明示的に確認通知されたバイトを越えるバイト範囲上に重ねられる「スライディング・ウィンドウ」である。スライディング・ウィンドウは、サーバから一番最近送信されたバイトとクライアントからの受信確認通知がまだ受け取られていない最古のバイトとの間の最大数の一連のバイトを制限する。このスライディング動作は、ＴＣＰエンドポイントが放出することができる確認通知されていない伝送可能データの量を制限する。受信側ホストは、接続設定段階の間に、任意の時点で未処理の（確認通知されていない）可能性がある「最大」数のパケットに関連するバッファ容量を送信側ホストに通知する。これは、受信側又はスライディング・ウィンドウ・サイズ、ｒｗｎｄである。送信側は、現在のサイズ、ｗｎｄが確認通知（ＡＣＫ）を待たずにどれだけの量のパケットがネットワークに送り込まれるかの推定である、伝送ウィンドウを保持する。ｗｎｄの上限がｒｗｎｄである。
【００１０】
スライディング・ウィンドウの限度を超えたときには、種々のアルゴリズムがパケットを自動的に再送信し、データ伝送をゆっくり再開する。したがって、データ・コレクションの伝送の最中にサーバとクライアントとの間のリンクがシャットダウンされた場合には、サーバは、クライアントによって確認通知された最後のパケットの１スライディング・ウィンドウ内でパケットの送信を止める。このスライディング・ウィンドウの使用は、ネットワークを通るデータ伝送の帯域幅を本質的に制限する。
【００１１】
ＴＣＰにおけるスロー・スタート（ＳＳ）アルゴリズムは、ウィンドウ・サイズをゼロに設定し、接続を開始し又は再開するときに伝送ルートの未知の容量を見積もる。データ・パスの帯域幅と遅延との積が、伝送ルートの容量の概算である。ＳＳアルゴリズムが繰り返されるたびに、ウィンドウ・サイズが、帯域幅と遅延との積の推定に達するように倍にされる。
【００１２】
ＴＣＰ輻輳回避アルゴリズムは、伝送速度を制御された形で減少させることによってネットワークの輻輳に反応する。輻輳は、パケットの欠落の結果としてのスイッチング・ポイント（例えばゲートウェイ又はルータ）におけるデータグラムのオーバーロードに起因する重大な遅延状態である。送信側は、影響を受けたパケットを再送することによって遅延及びパケット損失に反応する。これが輻輳に加わって、輻輳が急速に増大し、輻輳崩壊として現在知られているようなことが起こる。タイムアウトにより元のＡＣＫが失われていることが検出されたときに、又は受信側が順序どおりでないパケットの受信に応答して重複確認通知（ＤＡＣＫ）を送信したときに、輻輳回避が開始される。これが開始されると、輻輳回避アルゴリズムの前のイテレーションで計算された伝送ルート容量の推定値が、変数ｓｓｔｈｒｅｓｈとして保存される。したがって、この推定値は、スロー・スタートが実行され、伝送ルート容量が後で再び見積もられるまで閾値として用いられる。ｓｓｔｈｒｅｓｈのウィンドウ・サイズを超えると、ウィンドウ・サイズの直線的増加が採用される。輻輳によって支配されるウィンドウ・サイズの実行中の推定値を保存するために、別の変数ｃｗｎｄが用いられる。伝送ウィンドウは、輻輳ウィンドウ及びスライディング・ウィンドウのうち小さい方に制限されることが分かる（すなわち、ｗｎｄ＝ｍｉｎ（ｃｗｎｄ，ｒｗｎｄ））。さらに、タイムアウトによって輻輳が示される場合には、ｃｗｎｄは１セグメント・サイズに設定され、スロー・スタートが強いられる。
【００１３】
ＴＣＰ性能を強化するための別の機構は、Ｆａｓｔ  Ｒｅｔｒａｎｓｍｉｓｓｉｏｎ  ａｎｄ  Ｒｅｃｏｖｅｒｙ（ＦＲＲ）アルゴリズムである。特定の伝送に関して受け取られたＤＡＣＫの数が閾値（ｔｙｐ３）に達したときに、ＴＣＰが失われたパケットを再送し、ウィンドウが１に近づけられるのではなく２分の１に減少される。タイムアウト（輻輳の強い表示）又はＤＡＣＫ（輻輳の弱い表示）によって輻輳が検出されると、現在の輻輳ウィンドウ（ｃｗｎｄ）の半分がｓｓｔｈｒｅｓｈに保存されて、輻輳回避がなされる。これは、輻輳制御アルゴリズムの乗算減少部である。さらに、再送が最後に確認通知されたときにパケットのバーストが伝送されるのを防ぐために、輻輳回避が実行されていながら各ＤＡＣＫと共に新しいパケットが伝送される。伝送ウィンドウ（ｗｎｄ）を超える連続した数のパケット又は伝送における最後のパケットが失われたときに、ＦＲＲが失敗する。
【００１４】
図２は、本発明の好ましい実施形態において用いることができるサーバ・クライアント・システムの典型的なソフトウェア・アーキテクチャの図である。サーバ１０４及びクライアント１０６の各々は、ソフトウェア・アーキテクチャ２００と共に設計される。最下位レベルにおいて、ユーザに及び他のソフトウェアにハイレベルの機能を提供するために、オペレーティング・システム２０５が用いられる。こうしたオペレーティング・システムは、典型的には、ＢＩＯＳ（Ｂａｓｉｃ  Ｉｎｐｕｔ  Ｏｕｔｐｕｔ  Ｓｙｓｔｅｍ）を含む。通信ソフトウェア２１０は、ネットワーク上での通信のために、オペレーティング・システムの機能を直接呼び出すか、又は間接的に、オペレーティング・システムをバイパスしてハードウェアにアクセスするかのいずれかによって、物理的通信リンクを介してインターネットのようなネットワークへの外部ポートを通る通信を提供する。アプリケーション・プログラミング・インターフェース２１５は、システムのユーザが、特定の機能がどのように実装されるかに関係なく、標準整合インターフェースを用いてシステムのボリュームを呼び出すことを可能にする。インターネット・ソフトウェア２２０は、コンピュータにインターネット機能を備えさせるために利用可能な幾つかの標準商業パッケージのいずれか１つを表す。アプリケーション・ソフトウェア２２５は、通信ポートを通じてデータに反応して、ユーザが求める所望の機能を提供するように設計された、あらゆる数のソフトウェア・アプリケーションを表す。このレベルのアプリケーションは、インターネット・ユーザによってアクセスされることが可能なデータ、ビデオ、グラフィックス、写真又はテキストを取り扱う必要があるものを含む。
【００１５】
図３に示されるように、ＴＣＰ／ＩＰ及びそれに類似のプロトコルは、アプリケーション層３１０、トランスポート層３１２、ネットワーク層３１４、及びリンク層３１６を含む、ネットワークのための４層通信アーキテクチャ３００によって用いられる。各層は、以下のような、種々の通信タスクを取り扱うための役目をもっている。リンク層３１６（データリンク層又はネットワーク・インターフェース層とも呼ばれる）は、普通は、オペレーティング・システムのデバイス・ドライバと、それに対応するコンピュータのネットワーク・インターフェース・カードを含む。それらは共に、使用されるネットワーク媒体、例えばイーサネットケーブル等と物理的にインターフェースする全てのハードウェアの詳細を取り扱う。
【００１６】
ネットワーク層３１４（インターネット層とも呼ばれる）は、ネットワーク中のデータ・パケットの移動を取り扱う。例えば、ネットワーク層は、ネットワーク上で伝送された種々のデータ・パケットのルーティングを取り扱う。ＴＣＰ／ＩＰスイートのネットワーク層は、ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）、ＩＣＭＰ（Ｉｎｔｅｒｎｅｔ  Ｃｏｎｔｒｏｌ  Ｍｅｓｓａｇｅ  Ｐｒｏｔｏｃｏｌ）及びＩＧＭＰ（Ｉｎｔｅｒｎｅｔ  Ｇｒｏｕｐ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ）を含む幾つかのプロトコルからなる。
【００１７】
トランスポート層３１２は、２つのホストコンピュータ間のデータの伝送を容易にする、ネットワーク層３１４とアプリケーション層３１０との間のインターフェースを提供する。トランスポート層は、アプリケーションから渡されたデータを分割して下のネットワーク層に適したサイズのチャンクにする、受け取ったパケットを確認通知する、送信されたパケットの確認通知が相手側に確実になされるようにタイムアウトを設定する、といったイベントに関連する。ＴＣＰ／ＩＰプロトコル・スイートにおいては、２つの明確に異なるトランスポート・プロトコル、すなわち、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）及びＵＤＰ（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ）がある。ＴＣＰは、２つのホスト間でデータが適切に伝送されることを保証する、ドロップアウト検出及び再送サービスを含む信頼性サービスを提供する。逆に、ＵＤＰは、データが適切に伝送されたことを保証するための何らかの機構を備えることなく、１つのホストから他のホストへの、データグラムと呼ばれるデータ・パケットの単純な送信によって、アプリケーション層に非常に単純なサービスを提供する。ＵＤＰを用いたときには、アプリケーション層は、信頼性機能を実行しなければならない。
【００１８】
アプリケーション層３１０は、特定のアプリケーションの詳細を取り扱う。ほぼ全ての実装を提供する、（１）リモート・ログインのためのＴｅｌｎｅｔ、（２）ＦＴＰ、Ｆｉｌｅ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ、（３）電子メールのためのＳＭＴＰ、Ｓｉｍｐｌｅ  Ｍａｉｌ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ、及び（４）ＳＮＭＰ、Ｓｉｍｐｌｅ  Ｎｅｔｗｏｒｋ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌを含む、多くの一般的なＴＣＰ／ＩＰアプリケーションが存在する。
【００１９】
インターネットのようなネットワークは、ルータによって互いに接続され、その各々は、２つ又はそれ以上のネットワークを互いに接続する。典型的なルータは、入力及び出力接続、専用ハードウェア、及び／又は、イーサネット、トークンリング、２地点間リンク等といった多くの異なる形式の物理的ネットワークが接続されることを可能にする内蔵型ソフトウェアを有する特殊目的ハードウェアボックスを含む。図４は、ルータ４３６によってトークン・リング・ネットワーク４３４に接続されたイーサネット・ネットワーク４３２を含むインターネット４００を示す。図４は、通信する２つのみのホストが示されているが、イーサネット・ネットワーク上のいずれのホストも該イーサネット・ネットワーク上のいずれかのホストと、又はトークン・リング・ネットワーク上のいずれかのホストと通信可能であり、この逆も可能である。
【００２０】
図４に示されるように、ルータ４３６は、ネットワーク層モジュール４３８（この場合はＩＰモジュール）と、ホスト・ネットワークに接続するための適切なネットワーク・ドライバ、すなわちイーサネット・ドライバ４４０及びトークン・リング・ドライバ４４２とを含む。アプリケーション層において、ネットワークは、ＦＴＰクライアント４２０とＦＴＰサーバ４２２とを含む。ほとんどのネットワーク・アプリケーションは、一方のエンドがクライアントで、他方がサーバであるように設計される。サーバは、ある種のサービス、この場合はサーバホスト上のファイルへのアクセスを種々のクライアントに提供する。各層は、同じ層においてそのピアと通信するための１つ又はそれ以上のプロトコルを有する。これらの通信プロトコルは、アプリケーション層におけるＦＴＰプロトコル４４４と、トランスポート層におけるＴＣＰプロトコル４４６と、ネットワーク層におけるＩＰプロトコル４４８と、リンク層におけるイーサネット・プロトコル４５０及びトークン・リング・プロトコル４５４とを含む。アプリケーション層は、通常、ユーザプロセスを取り扱うが、その下の３つの層（トランスポート、ネットワーク及びリンク）は、ＵＮＩＸ又はＷｉｎｄｏｗｓオペレーティング・システムといったオペレーティング・システムのカーネルにおいて実装される。例えば、ネットワーク・インターフェース層の目的は、通信媒体（イーサネット、トークン・リングなど）の詳細を取り扱うことであり、一方、アプリケーション層の目的は、１つの特定のユーザ・アプリケーション（ＦＴＰ、Ｔｅｌｎｅｔなど）を取り扱うことである。
【００２１】
アプリケーション層及びトランスポート層は、エンド・ツー・エンド・プロトコル（ＦＴＰプロトコル４４４、ＴＣＰプロトコル４４６）を用いる。ネットワーク層は、２つのエンドシステム及びそれらの間の全ての中間システム上で用いられるホップ・ツー・ホップ・プロトコルを提供する（明確にするために、ここでは１つのみの中間システムが示されている）。例えば、ルータ４３６のＩＰモジュール４３８は、ＩＰプロトコル４４８によって２つのホストに接続される。リンク層におけるネットワークとルータとの間の通信を取り扱うために、ルータに接続された種々の形式のホスト・ネットワークに固有のリンク層プロトコルも存在する。したがって、ルータ４３６のイーサネット・ドライバ４４０とイーサネット・ネットワーク４３２上のホストのイーサネット・ドライバ４５２との間の通信を取り扱うためにイーサネット・プロトコル４５０が用いられ、一方、ルータ４３６のトークン・リング・ドライバ４４２とトークン・リング・ネットワーク４３４上のホストのトークン・リング・ドライバ４５６との間の通信を取り扱うためにトークン・リング・プロトコル４５４が用いられる。
【００２２】
ＴＣＰ／ＩＰプロトコル・スイートにおいては、ネットワーク層、ＩＰは、信頼性のあるサービスを提供しない。ＩＰは、パケットをソースから宛先に移動させるが、送達を保証するための機構を提供せず、適切な転送が行われたかを判断することはできる。ＴＣＰは、２つのホスト間でデータが適切に伝送されたことを保証する、ドロップアウト検出及び再送サービスを含む、信頼性サービスを提供する。
【００２３】
ルータは、２つ又はそれ以上のネットワーク・インターフェース層を有する（ルータは２つ又はそれ以上のネットワークを接続するものであるため）。複数のインターフェースを備えたシステムは、マルチホームと呼ばれる。ホストもまたマルチホームとすることができるが、特に１つのインターフェースから別のインターフェースにパケットを転送しない限り、それをルータとは呼ばない。また、ルータは、インターネット中で唯一パケットを移動させる特別なハードウェアボックスである必要はない。ほとんどのＴＣＰ／ＩＰの実装は、マルチホーム・ホストがルータとして働くことを可能にするが、ホストは、この用途をサポートするように構成される必要がある。こうした場合には、システムは、ホスト（ＦＴＰ又はＴｅｌｎｅｔといったアプリケーションが用いられるとき）か、又はルータ（１つのネットワークから他のネットワークにパケットを転送するとき）のいずれかである。ネットワークを接続する別の方法は、ブリッジを設けることである。ブリッジは、リンク層においてネットワークを接続し、一方、ルータは、ネットワーク層においてネットワークを接続する。ブリッジは、複数のＬＡＮが上の層に単一のＬＡＮとして現れるようにする。
【００２４】
アプリケーションがＴＣＰ／ＩＰを用いてデータを送るときに、データは、該データがネットワークを横切るビット・ストリームとして送られるまで、プロトコル・スタックの各層を通って下方に送られる。図５に示されるように、各層は、受信したデータにヘッダを付加する（時にはトレーラー情報を付加する）ことによって、データに情報を付加する。例えば、アプリケーション層において、アプリケーション・ヘッダ５８０がユーザデータ５８２に付加されてアプリケーション・データ５８４が形成される。トランスポート層において、アプリケーション・データにトランスポート・プロトコル・ヘッダが付加される。図５の場合、トランスポート層がＴＣＰであり、したがって、アプリケーション・データ５８４にＴＣＰヘッダ５８６が付加され、それにより、ネットワーク層ＩＰに送られるＴＣＰフレーム５８８が形成される。ＴＣＰヘッダ５８６は、２０バイトを構成する。同様に、ネットワーク層においては、ネットワーク層ヘッダがトランスポート層データに付加される。ＴＣＰ／ＩＰの場合には、ＩＰヘッダ５９０がＴＣＰフレーム５８８に付加されて、ＩＰデータグラム５９２が形成される。ＩＰヘッダ５９０もまた、２０バイトを構成する。最後に、リンク層において、イーサネット・ヘッダ５９４といったメディア・ヘッダが、ネットワーク層から受信されたデータに付加されて、データ・フレームを形成する。メディアがイーサネットであるような場合には、メディア・トレーラもデータのエンドに付加される。例えば、図５においては、イーサネット・トレーラ５９６がイーサネット・ヘッダ５９４及びＩＰデータグラム５９２に付加されて、イーサネット・フレーム５９８が形成される。イーサネット・フレームは、元のアプリケーション・メッセージ・データに対応する、ネットワークを横切って流れるビット・ストリームを含む。ヘッダの下部の数字（１４、２０、２０、４）は、ヘッダの典型的なバイトサイズであり、例えば、イーサネット・ヘッダ９４は１４バイトを構成する。フレームサイズは、データ・パケットを伝送するのに用いられるネットワークタイプの最大伝送単位（ＭＴＵ）によって制限されることになる。例えば、イーサネット・ネットワークのＭＴＵは１５００バイトである。ネットワーク層は、フラグメンテーション（データグラムを小部分に分断する）を自動的に実行し、それにより各フラグメントはネットワークのＭＴＵより小さくなる。
【００２５】
特定のデータ・フレームがデータ伝送ストリームから欠落しているとクライアントが検出したときに、クライアントは、確認通知フレームにおいて未着フレームの最初のバイトの順序番号を送信することによって、サーバが未着フレームを再送することをクライアントが要求する。図６に示されるように、ＴＣＰは、典型的にはメディア・ヘッダ６１２、プロトコル・ヘッダ６１４、受信順序番号フィールド６１６、送信順序番号フィールド６１８、及びメッセージ本体６２０を含むメッセージ６１０を送信し又は再試行する。メディア・ヘッダ６１２は、特にネットワークタイプのもの、例えばイーサネット・ネットワーク用のイーサネット・ヘッダなどである。プロトコル・ヘッダ６１４は、ＴＣＰ／ＩＰ、ＩＰＸ／ＳＰＸ、Ｎｅｔｂｉｏｓなどのような使用されるトランスポート及びネットワーク層プロトコルに依存する。受信順序番号フィールド６１６は、コンピュータによって確実に受信された最後の順序番号への識別子を提供する。送信順序番号６１８は、メッセージの相対順序番号に対応する。メッセージ本体６２０は、ソース及び宛先コンピュータ間で送信されるアプリケーション・データを含む。ＴＣＰ確認通知フレーム６２２は、メディア・ヘッダ６２４、プロトコル・ヘッダ６２６、受信順序番号フィールド６２８、及び送信順序番号フィールド６３０を含む。これらのフィールドは、同じ名前をもつ上述のフィールドに類似している。送信又は再試行メッセージの受取の確認通知をするために、確認通知フレーム６２２が受信側コンピュータによって送信される。ＴＣＰにおいては、未着フレームを示す３つの連続する確認通知フレームを受信すると、サーバは、普通は、未着の順序番号で始まる未着フレームを「高速再送」することになる。こうした再送は、サーバがそのスライディング・ウィンドウを縮小し、送信するデータ量を減少させるため、性能に悪影響を及ぼす。
【００２６】
ここで図７を参照すると、本発明の好ましい実施形態によって提供される改善されたＴＣＰ性能の例に関するタイミング・ダイアグラムが示されている。図７に示された例は、送信側７０５がネットワーク７１５を介して５つのデータ・パケットを受信側７１０に伝送するときのタイミング・ダイアグラム７００を示す。時刻Ａにおいて、パケット１がネットワーク７１５に送信される。時刻Ｂにおいて、パケット１がネットワーク７１５から受信側７１０に伝送される。時刻Ｃにおいて、受信側７１０は、パケット１の受取を確認通知し、パケット２（ＡＣＫ２）を要求する。時刻Ｄにおいて、ＡＣＫ２がネットワーク７１５から送信側７０５に伝送される。
【００２７】
時刻Ｅ、Ｆ、Ｇ及びＨにおいて、送信側７０５は、パケット２、３、４及び５をそれぞれネットワーク７１５に伝送する。しかしながら、ネットワーク７１５は、送信側７０５から受信したパケットを再び順序付けし、時刻Ｉに見られるように、最初にパケット３を受信側７１０に伝送する。パケット３の受取に応答して、受信側７１０は、時刻Ｊにおいて、受信側７１０がパケット２をまだ受け取っておらず、かつパケット３が順番を抜かして受信されたことを示す重複ＡＣＫ２（ＤＡＣＫ２）を伝送する。時刻Ｋにおいて、ＤＡＣＫ２がネットワーク７１５から送信側７０５に伝送される。また、時刻Ｋにおいて、ネットワーク７１５がパケット４を受信側７１０に伝送する。それに応答して、時刻Ｌにおいて、パケット４が順番を抜かして受信され、かつパケット２を要求することを示す第２のＤＡＣＫ２を受信側７１０が伝送する。時刻Ｍにおいて、この第２のＤＡＣＫ２は、ネットワーク７１５から送信側７０５に送られ、パケット５がネットワーク７１５から受信側７１０に渡される。時刻Ｎにおいて、受信側７１０は、第３のＤＡＣＫ２を再送し、パケット５の受取を確認通知し、再びパケット２を要求することによって、パケット５の受取に応答する。時刻Ｏにおいて、この第３のＤＡＣＫ２が送信側７０５でネットワーク７１５から受信される。また、時刻Ｏにおいて、受信側７１０は、最後にネットワーク７１５からパケット２を受け取る。時刻Ｐにおいて、送信側７０５は、第３のＤＡＣＫ２を受け取った後に、ＴＣＰプロトコルによって特定されるようにパケット２を「高速再送」する。ＴＣＰは、ネットワーク７１５上の輻輳の結果として第３のＤＡＣＫの受取を考慮に入れるので、送信側７０５は、パケット２を再送すると、輻輳ウィンドウを５０パーセント減少させる。また、時刻Ｐにおいて、受信側７１０は、このときパケット２、３、４及び５を受信しており、パケット６を要求するＡＣＫに応答する。ネットワーク７１５におけるパケットの再配列の結果として、ＡＣＫ６及び再送されたパケット２は、両方ともネットワーク７１５内に同時に存在する。（このタイミングは、単なる一例であり、プロセスにおいては他のタイミングも起こりうることを理解されたい。本発明の方法の適切な動作に関する唯一のタイミング要件は、受信側７１０が再送されたパケット２を受信する前に受信側７１０からＡＣＫ６が伝送されることである。）時刻Ｑにおいて、受信側７１０は、ネットワーク７１５から再送されたパケット２を受信する。時刻Ｒにおいて、送信側７０５は、ネットワーク７１５からＡＣＫ６を受信する。
【００２８】
この時点では、パケットの再送後に時刻Ｒにおいて受信されたＡＣＫ６が、パケット２の元の伝送又は再送に応答したものであるかどうかは不明である。従来技術では、ＡＣＫは、受信側７１０が再送されたパケット２を受信した結果であるとみなされ、そのため、ＴＣＰにおいては、送信側７０５は、輻輳ウィンドウの減少を伴って動作し続ける。しかしながら、本発明の好ましい実施形態は、送信側７０５に、実際のパケット・ロス・イベントの結果として受信されたＡＣＫとパケットの再配列の結果として受信されたＡＣＫとを区別する方法を提供する。送信側７０５が、好ましい実施形態に従って、再配列の結果として高速再送が起こったと判断した場合には、輻輳制御及び回避は行われず、それによりＴＣＰ帯域幅に対する不必要な制約がなくされる。
【００２９】
本発明の好ましい実施形態は、「高速再送」によってパケットを再送して輻輳ウィンドウを減少させる前に、送信側７０５が現在の輻輳状態をＳＳＴｈｒｅｓｈ及びｃｗｎｄを表す変数ＣＣＳとしてセーブするときに始まるプロセスである。再送されたパケットを受取通知する後続のＡＣＫ（図７の例においてはＡＣＫ６）を受信した後に、ＴＣＰ送信側７０５が、送信側７０５におけるＡＣＫの到着時刻に基づいて、ＡＣＫが元の再配列されたパケット又は再送されたパケットのいずれの受取によってもたらされたものであるかを判断する。再送されたパケットのラウンド・トリップ・タイムに関する計算された時間閾値の有効期限（ＴＨＲＥＳＨ−ＲＴＴ）より前にＡＣＫが到着した場合には、送信側７０５は、ネットワーク７１５においてパケット・ロスではなく再配列が起こったとみなす。この場合、ＣＣＳは、輻輳状態をリストアして保存された値に戻すために用いられ、それにより、ネットワーク輻輳の結果として再送が起こらないため、その元の増加したスループットでシステムが引き続き動作することを可能にする。
【００３０】
閾値再送ＲＴＴ（ＴＨＲＥＳＨ−ＲＴＴ）を計算するために、ＴＣＰ送信側７０５は、パケットが再送される（Ｔ再送）時刻を保存する。再送確認通知が到着すると、送信側７０５が、確認通知が到着した時刻（Ｔ現在）を保存し、次に再送時刻と到着時刻との差（すなわちＴ現在−Ｔ再送）を計算することによってＲＴＴを計算する。この差が、送信側と受信側との間のリンクに関する平均又は現在の計算されたラウンド・トリップ・タイム（ＲＴＴ）よりかなり小さい場合には、再配列イベントの結果として再送が起こるという強い指示がある。次式は、好ましい実施形態におけるこの計算を説明するものである。
（Ｔ現在−Ｔ再送）＜アルファ＊ＲＴＴ
ここで、「アルファ」は、０から１までの間の数であり、送信側と受信側との間の最小の可能なＲＴＴを推定するための係数であり、ＲＴＴにおける変化及びネットワークにおける関連のない急激なＲＴＴのドロップを補償する。好ましい実施形態においては、アルファは、０．５から０．７５の範囲内（すなわち５０−７０パーセント）、好ましくは０．６に設定される。確認された上記の計算に基づいて再配列イベントが検出されると、送信側は、高速再送を行う前に輻輳状態をリストアしてシステム値に戻す（すなわちＣＣＳに関する保存された値に戻す）。理解されるように、好ましい実施形態の機構は、送信側で実装され、受信側の論理に対する変化は要求しない。これは、この技術が、この性能の強化を実装しない全ての既存の及び将来のＴＣＰ実装と共に機能することを保証する。
【００３１】
理解されるように、１つの好ましい実施形態においては、パケットが再送されると輻輳回避が実装され、パケットの再配列を示す早期ＡＣＫの受取の後に元のＣＣＳに復帰される。別の好ましい実施形態においては、輻輳回避の実装は、再送に対するタイムリーな応答ＡＣＫが受信された後に、パケット・ロスに起因するネットワーク輻輳が確認されるまで、高速再送の後に遅延される。
【００３２】
ここで図８を参照すると、本発明の好ましい実施形態に係る、パケットの再配列の後の改善されたＴＣＰ性能のためのプロセスの流れ図が示されている。プロセス８００は送信側７０５で受信された重複確認通知の数がトランスポート・プロトコルにおける閾値数を超えたときにステップ８０５で始まり、指定されたパケットのＦａｓｔ  Ｒｅｔｒａｎｓｍｉｓｓｉｏｎ  ａｎｄ  Ｒｅｃｏｖｅｒｙ（ＦＲＲ）をトリガする。ＴＣＰプロトコルにおいては、ＦＲＲは通常、送信側７０５が３ＤＡＣＫを受信したときに起こる。その後、プロセスがステップ８１０に進み、そこで、送信側７０５が現在の輻輳状態（ＣＳＳ）を保存し、該ＣＳＳは、輻輳ウィンドウ及びスロー・スタート閾値を含み、スロー・スタート閾値（ＳＳＴｈｒｅｓｈ）をその現在値の半分まで減少させることによって輻輳回避を実施する。次に、プロセスがステップ８１５に進み、そこで、送信側７０５が指定されたロスト・パケットを再送し、変数Ｔ再送の下で再送が起こる時刻を保存する。次に、プロセスがステップ８２０に進み、その時点で、送信側７０５が再送されたパケットの確認通知を受信し、この確認通知の到着時刻を変数Ｔ現在として保存する。その後、プロセスがステップ８２５に進み、そこで、再送時刻とパケットの確認通知到着時刻との間の差を求めることによって、再送されたパケットに関するラウンド・トリップ・タイム（ｒｒｔ）が計算される。次に、プロセスが決定ブロック８３０に進み、そこで、再送されたパケットのラウンド・トリップ・タイムが、送信側７０５と受信側７１０との間のルートに関する最小期待ラウンド・トリップ・タイムより所定の量だけ小さいかどうかを判断し、該所定の量は、ネットワーク７１５内のリンク及びＲＴＴにおける理論上起こりうる急激なドロップの特徴の関数である。この所定量は、「アルファ」によって表される係数を伴って実装され、０から１までの間、好ましくは０．５から０．７５の範囲内に設定される。したがって、ステップ８３０における決定は、式、ｒｒｔ＜アルファ＊ＲＴＴで表すことができる。ステップ８３０における決定が否定である場合には、プロセスはステップ８４０に進み、そこで、ロスト・パケットに応答して輻輳回避が適切に実施されたと判断されるため、プロセスが終了する。ステップ８３０における決定が肯定である場合には、プロセスがステップ８３５に進み、そこで、送信側７０５の輻輳状態が、ステップ８１０で保存されたＣＣＳにリストアされ、その後プロセスがステップ８４０において終了する。
【００３３】
ステップ８２５において計算されたラウンド・トリップ・タイムは、確認通知が、元のパケットが再ルーティングされ受信側７１０に到着するのに応答して受信されたのであって、再送されたパケットの受取に応答して受信されたのではないことを示すので、輻輳状態は、送信側７０５が高速再送を始める前に存在するＣＣＳに戻されることを理解されたい。したがって、好ましい実施形態によれば、伝送されたパケットの再配列に起因する輻輳回避の誤ったトリガは、輻輳状態をＣＣＳに復元することにより無効にされ、それにより、そうでなければＴＣＰ輻輳回避の実装によってスロットルされるであろうスループットが増加することによって、性能が強化される。
【００３４】
本発明は、特に好ましい実施形態に関連して図示され説明されたが、当業者であれば、本発明の精神及び範囲から逸脱することなく、本発明に形式及び細部の種々の変更をなしうることを理解するであろう。例えば、本発明は、コンピュータ・プログラミング・ソフトウェア、ファームウェア又はハードウェアのいずれかの組み合わせを用いて実装することができる。本発明を実施する、又は本発明に係る装置を構成するための準備段階として、本発明に係るコンピュータ・プログラミング・コード（ソフトウェア又はハードウェアのいずれか）が、通常は、固定（ハード）ドライブ、ディスケット、光ディスク、磁気テープ、ＲＯＭ、ＰＲＯＭのような半導体メモリといった、１つ又はそれ以上の機械可読ストレージ・メディアに格納され、それにより本発明に係る製品が形成される。コンピュータ・プログラミング・コードを格納した製品は、コードを直接ストレージ・デバイスから実行するか、コードをストレージ・デバイスからハードディスク、ＲＡＭなどのような別のストレージ・デバイスにコピーするか、遠隔実行するためにコードを伝送することのいずれかによって用いられる。本発明を実施する方法は、コードを格納した１つ又はそれ以上の機械可読ストレージ・デバイスを、適当な標準コンピュータ・ハードウェアと組み合わせて、コードを実行することによるものとすることができる。本発明を実施するための装置は、１つ又はそれ以上のコンピュータと、本発明に従ってコード化されたコンピュータ・プログラムへのネットワーク・アクセスを含む又は有するストレージ・システムとすることができる。
【図面の簡単な説明】
【００３５】
【図１】本発明の好ましい実施形態を実装可能なデータ処理システム・ネットワークを示す図である。
【図２】本発明の好ましい実施形態において用いることができる、サーバ・クライアント・システムの典型的なソフトウェア・アーキテクチャの図である。
【図３】ＴＣＰ／ＩＰを用いる４層通信アーキテクチャの例を示す図である。
【図４】ルータによってトークン・リング・ネットワークに接続されたイーサネット・ネットワークを含むインターネットの例を示す図である。
【図５】ＴＣＰ／ＩＰプロトコル・スタックをトラバースする際のデータ・フォーマットを示す図である。
【図６】ＴＣＰ送信又は再試行フレーム及びＴＣＰ確認通知フレームのデータ構造を示す図である。
【図７】本発明の好ましい実施形態によって提供される改善されたＴＣＰ性能の例のタイミング図である。
【図８】本発明の好ましい実施形態に係る、パケットの再配列の後の改善されたＴＣＰ性能のプロセスの流れ図である。
【図１】
2007534194.tif 000003
【図２】
2007534194.tif 000004
【図３】
2007534194.tif 000005
【図４】
2007534194.tif 000006
【図５】
2007534194.tif 000007
【図６】
2007534194.tif 000008
【図７】
2007534194.tif 000009
【図８】
2007534194.tif 000010
【手続補正書】
【提出日】平成17年6月14日(2005.6.14)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
送信側（７０５）と受信側（７１０）との間にネットワーク接続を有し、該ネットワーク接続がある輻輳状態で動作するネットワーク（７１５）においてパケットの再配列の後のトランスポート層（３１２）の性能を改善する方法であって、
第１の輻輳状態で動作するネットワーク接続を介してデータ・パケットが伝送されることを要求する、所定閾値数の第１の確認通知を送信側で受け取るステップと、
所定閾値数の第１の確認通知を受け取る前記ステップに応答して（８０５）、前記要求されたデータ・パケットを前記ネットワーク接続を介して送信側から受信側に伝送するステップ（８１５）と、
前記要求されたデータ・パケットが受信側によって受信されたことを示す第２の確認通知を送信側で受け取るステップ（８２０）と、
前記第２の確認通知が受け取られた時刻と前記要求されたデータ・パケットが伝送された時刻との差を計算するステップ（８２５）と、
を含み、
送信側と受信側との間の前記ネットワーク接続を介するデータ・パケットの最小ラウンド・トリップ・タイムである閾値ラウンド・トリップ・タイムより前記差が小さい場合に、前記ネットワーク接続の輻輳状態を第１の輻輳状態に設定する（８３５）ステップと、
前記差が前記閾値ラウンド・トリップ・タイムより大きい場合に、ネットワーク接続の輻輳状態を前記第１の輻輳状態より小さい第２の輻輳状態に設定するステップと、
によって特徴付けられる方法。
【請求項２】
前記要求されたデータ・パケットを伝送すると前記輻輳状態を第３の輻輳状態に設定するステップをさらに含む、請求項１に記載の方法。
【請求項３】
前記要求されたデータ・パケットを伝送する前に前記第１の輻輳状態を保存するステップ（８１０）をさらに含む、請求項２に記載の方法。
【請求項４】
前記第３の輻輳状態が前記第１の輻輳状態より小さい、請求項２に記載の方法。
【請求項５】
前記所定閾値数が３である、請求項１に記載の方法。
【請求項６】
前記輻輳状態が輻輳ウィンドウを含む、請求項１に記載の方法。
【請求項７】
前記輻輳状態がスロー・スタート閾値を含む、請求項１に記載の方法。
【請求項８】
前記要求されたデータ・パケットが伝送された時刻を保存するステップ（８１５）をさらに含む、請求項１に記載の方法。
【請求項９】
前記ネットワーク接続がＴＣＰプロトコルに準拠して動作する、請求項１に記載の方法。
【請求項１０】
前記閾値ラウンド・トリップ・タイムが、前記ネットワーク接続に関する平均ラウンド・トリップ・タイムの５０パーセントから７５パーセントの間である、請求項１に記載の方法。
【請求項１１】
送信側（７０５）と受信側（７１０）との間にネットワーク接続を有するネットワーク（７１５）におけるパケット再配列の後のトランスポート層（３１２）の改善された性能を提供するデータ処理システムであって、前記システムは、
前記データ処理システムと前記受信側との間のネットワーク接続が第１の輻輳状態で動作している状態でデータ・パケットが伝送されることを要求する、所定閾値数の第１の確認通知を受信側から受け取る（８０５）ための手段と、
所定閾値数の第１の確認通知を受け取る前記ステップに応答して、要求されたデータ・パケットを受信側に伝送する（８１５）ための手段と、
要求されたデータ・パケットが受信側によって受信されたことを示す第２の確認通知を受信する（８２０）ための手段と、
前記第２の確認通知が受け取られた時刻と要求されたデータ・パケットが伝送された時刻との差を計算する（８２５）ための手段と、
を含み、
送信側と受信側との間の前記ネットワーク接続を介するデータ・パケットの最小ラウンド・トリップ・タイムである閾値ラウンド・トリップ・タイムより前記差が小さい場合に、前記ネットワーク接続を第１の輻輳状態で動作させる（８３５）ための手段と、
前記差が閾値ラウンド・トリップ・タイムより大きい場合に、前記ネットワーク接続を前記第１の輻輳状態より小さい第２の輻輳状態で動作させるための手段と、
によって特徴付けられるシステム。
【請求項１２】
前記要求されたデータ・パケットを伝送すると前記ネットワーク接続を第３の輻輳状態で動作させるための手段をさらに含む、請求項１１に記載のデータ処理システム。
【請求項１３】
前記要求されたデータ・パケットを伝送する前に前記第１の輻輳状態を保存する（８１０）ための手段をさらに含む、請求項１２に記載のデータ処理システム。
【請求項１４】
前記第３の輻輳状態が前記第１の輻輳状態より小さい、請求項１２に記載のデータ処理システム。
【請求項１５】
前記所定閾値数が３である、請求項１１に記載のデータ処理システム。
【請求項１６】
前記輻輳状態が輻輳ウィンドウを含む、請求項１１に記載のデータ処理システム。
【請求項１７】
前記輻輳状態がスロー・スタート閾値を含む、請求項１１に記載のデータ処理システム。
【請求項１８】
前記要求されたデータ・パケットが伝送された時刻を保存するための手段をさらに含む、請求項１１に記載のデータ処理システム。
【請求項１９】
前記ネットワーク接続がＴＣＰプロトコルに準拠して動作する、請求項１１に記載のデータ処理システム。
【請求項２０】
前記要求されたデータ・パケットが前記データ処理システムによって送られ、前記確認通知が前記受信側から前記インターネットを介して送られる、請求項１１に記載のデータ処理システム。
【請求項２１】
請求項１から請求項１０までのいずれか１項に記載のステップを実行するように適合されたコンピュータ・プログラム・コード手段を含むコンピュータ・プログラム。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、データ処理システム・ネットワークにおいてデータを伝送すること、特に、インターネット又はそれに類似のネットワーク上でデータ・ブロックを伝送することに関する。より具体的には、本発明は、パケットを再配列する際のＴＣＰネットワークにおける輻輳制御の改善に関する。
【背景技術】
【０００２】
インターネットは、データ（テキスト、コード、イメージ、ビデオ、オーディオ又はそれらの混合体）及びソフトウェアを伝送し及び配布するための重要なパイプとなってきている。ユーザは、１４．４Ｋｂ／ｓないしは４５Ｍｂ／ｓ以上の多様なレベルの性能をもつバックボーンに接続する。さらに、伝送制御プロトコル／インターネット・プロトコル（ＴＣＰ／ＩＰ）が、クライアント、サーバ、及びそれらを結合する通信システム間の様々な異質性を許容する、インターネット及びイントラネット技術において幅広く実装された標準通信プロトコルとなっている。インターネット・プロトコル（ＩＰ）はネットワーク層プロトコルであり、伝送制御プロトコル（ＴＣＰ）はトランスポート層プロトコルである。ネットワーク・レベルにおいて、ＩＰは「データグラム」配信サービスを提供する。それに対し、ＴＣＰは、データグラム・サービスを介してコネクション・オリエンテッド・トランスポート・レベル・サービスを構築し、２つのＩＰホスト間の、保証されたバイト・ストリームの順次配信を提供する。ＴＣＰに送られたアプリケーション・データは、セグメントに分解されＩＰに送られる。セグメントはセグメント番号によって順序付けされる。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
データ伝送における信頼性は、データ汚染、データ損失、及びデータ再配列の３つの事象によって損なわれることがある。データ損失は、タイムアウト機構によって管理される。ＴＣＰは、伝送されたセグメントの確認通知（ＡＣＫ）を受信側から受け取る際の遅延を計測するためのタイマー（再送タイマー）を保持する。ＡＣＫが推定された時間内に到着しないときには、対応するセグメントが失われたものとみなされ、再送される。ＴＣＰは、入来パケットをそれらが順番どおりに再配列されるまでキューに入れる再組立キューを保持することによって、データの再配列、又はＩＰデータグラムとして伝送されたデータ・セグメントの順番どおりでない到着を管理する。このキューに入っているデータが順番どおりになったときにのみ、データがユーザの受信バッファに移動され、そこで該データがユーザに見られる。ＴＣＰは、セグメントが受信側に到着したときに該セグメントに対してチェックサムを行うことによってデータ汚染を管理する。チェックサムに関しては、ＴＣＰ送信側は、パケット・データのチェックサムを計算し、この２バイト値をＴＣＰヘッダに付加する。チェックサム・アルゴリズムは、ＴＣＰヘッダ及びデータにおけるすべての１６ビット・ワードの１の補数和の１６ビットの１の補数である。受信側は、受信したデータに対するチェックサム（ＴＣＰヘッダにおける２バイトのチェックサム・フィールドを除く）を計算し、それがヘッダのチェックサム値と一致することを確認する。チェックサム・フィールドはまた、ＩＰヘッダからの情報（４バイトの「ｓｒｃ  ｉｐ」アドレス、４バイトの「ｄｅｓｔ  ｉｐ」アドレス、２バイトのペイロード長、１バイトのプロトコル・フィールドを含む）を含有する１２バイトの擬似ヘッダを含む。
【０００４】
ＴＣＰプロトコルは、最初は、リンク・エラー率の低いネットワーク内で動作するように設計されたものであった、すなわち全てのセグメント損失は、大抵はネットワーク輻輳に起因するものであった。その結果として、送信側は、セグメント損失が検出される度に伝送速度を減少させる。しかしながら、再配列されたパケットが、ネットワーク輻輳において失われたパケットであると誤って判断されたときには、輻輳制御による関連する伝送速度の減少によって不必要なスループットの低下につながる。
【０００５】
パケットの再配列は、並列リンクの普及その他のパケットの再配列の要因があれば、ＴＣＰネットワークにおいてはよくあることである。例えば、多数の実アダプタが集合されて論理アダプタを形成するイーサチャンネルにおいては、パケット再配列は、パケットがこれらの複数のアダプタを介して並列に送られるときによく起こる。ＴＣＰにおいては、失われ又は再配列されたデータ・パケットに後続するいずれのデータ・パケットも、未着パケットが到着するまで受信側でキューに入れられる。次に、受信側が、全てのパケットをまとめて確認通知する。失われたパケットが再送されるのを受信側が待っている間は、それ以上データは送られない。しかしながら、パケットの再配列のために、ＴＣＰがネットワーク輻輳によってパケットが失われたと間違って推測するので、ＴＣＰセッションが、Ｆａｓｔ  Ｒｅｔｒａｎｓｍｉｔ  ａｎｄ  Ｒｅｃｏｖｅｒｙを自動的に実施する。再配列が、Ｆａｓｔ  Ｒｅｔｒａｎｓｍｉｔ  ａｎｄ  Ｒｅｃｏｖｅｒｙか、又はＳｅｌｅｃｔｉｖｅ  Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ  Ｏｐｔｉｏｎ（ＳＡＣＫ）による通知をうかつにもトリガしたときには、輻輳ウィンドウが半分にカットされ、タイムアウトが生じたときに、輻輳ウィンドウが１セグメント・サイズに設定され、スロー・スタートが強いられる。これらの機構は輻輳ウィンドウを自動的に減少させるので、こうしたパケットの再配列は、うかつにもネットワーク性能の激減を招く。パケットの再配列に起因するこうした不必要なスループットの低下を回避することが望ましいであろう。
【課題を解決するための手段】
【０００６】
本発明は、ネットワークにおいてパケットの再配列の後のトランスポート層の性能を改善する方法を提供するものであり、ネットワークは送信側と受信側との間にある輻輳状態で動作するネットワーク接続を有し、この方法は、第１の輻輳状態で動作するネットワーク接続を介してデータ・パケットが伝送されることを要求する、所定閾値数の第１の確認通知を送信側で受け取るステップと、所定閾値数の第１の確認通知を受け取るステップに応答して、要求されたデータ・パケットをネットワーク接続を介して送信側から受信側に伝送するステップと、要求されたデータ・パケットが受信側によって受信されたことを示す第２の確認通知を送信側で受け取るステップと、第２の確認通知が受け取られた時刻と要求されたデータ・パケットが伝送された時刻との差を計算するステップとを含み、送信側と受信側との間のネットワーク接続を介するデータ・パケットの最小ラウンド・トリップ・タイムである閾値ラウンド・トリップ・タイムより差が小さい場合に、ネットワーク接続の輻輳状態を第１の輻輳状態に設定するステップと、差が閾値ラウンド・トリップ・タイムより大きい場合に、ネットワーク接続の輻輳状態を第１の輻輳状態より小さい第２の輻輳状態に設定するステップとによって特徴付けられる。
【０００７】
本発明はまた、ネットワークにおいてパケットの再配列の後の改善されたトランスポート層の性能を提供するデータ処理システムを提供するものであり、ネットワークは送信側と受信側との間にネットワーク接続を有し、このシステムは、データ処理システムと受信側との間のネットワーク接続が第１の輻輳状態で動作している状態でデータ・パケットが伝送されることを要求する、所定閾値数の第１の確認通知を受信側から受け取るための手段と、所定閾値数の第１の確認通知を受け取るステップに応答して、要求されたデータ・パケットを受信側に伝送するための手段と、要求されたデータ・パケットが受信側によって受信されたことを示す第２の確認通知を受信するための手段と、第２の確認通知が受け取られた時刻と要求されたデータ・パケットが伝送された時刻との差を計算するための手段とを含み、差が閾値ラウンド・トリップ・タイムより小さい場合に、ネットワーク接続を第１の輻輳状態で動作させるための手段と、送信側と受信側との間のネットワーク接続を介するデータ・パケットの最小ラウンド・トリップ・タイムである閾値ラウンド・トリップ・タイムより差が大きい場合に、ネットワーク接続を第１の輻輳状態より小さい第２の輻輳状態で動作させるための手段とによって特徴付けられる。
【０００８】
したがって、本発明は、ネットワークにおいてパケットの再配列の後のトランスポート層の性能を改善するための改善された方法、システム及び製品を提供する。送信側と受信側との間のネットワーク接続が輻輳状態で動作する本発明の１つの好ましい方法においては、この方法は、データ・パケットが第１の輻輳状態で動作するネットワーク接続を介して伝送されることを要求する、所定閾値数の第１の確認通知を受け取るステップと、所定閾値数の第１の確認通知を受け取るステップに応答して、要求されたデータ・パケットをネットワーク接続を介して送信側から受信側に伝送するステップと、要求されたデータ・パケットが受信側によって受信されたことを示す第２の確認通知を受け取るステップと、第２の確認通知が受け取られた時刻と要求されたデータ・パケットが伝送された時刻との差を計算するステップと、送信側と受信側との間のネットワーク接続を介するデータ・パケットの最小ラウンド・トリップ・タイムである閾値ラウンド・トリップ・タイムより差が小さい場合に、ネットワーク接続の輻輳状態を第１の輻輳状態に設定するステップと、差が閾値ラウンド・トリップ・タイムより大きい場合に、ネットワーク接続の輻輳状態を前記第１の輻輳状態より小さい第２の輻輳状態に設定するステップを含む。
【発明を実施するための最良の形態】
【０００９】
ここで、本発明を、単なる例として付属の図面を参照しながら説明する。
ここで図面、特に図１を参照すると、本発明の好ましい実施形態を実装可能なデータ処理システム・ネットワークが示されている。データ処理システム・ネットワーク１００は、インターネット１０８のような少なくとも１つのネットワークを介して少なくとも１つのクライアント・システム１０６に結合された少なくとも１つのサーバ・システム１０４を含む。サーバ・システム１０４とクライアント・システム１０６との間のデータの伝送は、ＴＣＰ／ＩＰ仕様、並びに、Ｆｉｌｅ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ（ＦＴＰ）、ＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）、又はその他の類似の通信プロトコルに準拠させられる。認識されるように、単一のサーバ・システム１０４及び単一のクライアント・システム１０６のみが示されているが、データ処理システム・ネットワーク１００は、１つ又はそれ以上の接続、及びインターネット１０８を含むネットワークによって相互に接続された、あらゆる数のサーバ・システム及びクライアント・システム（図示せず）を含むことができる。
【００１０】
ネットワーク上でデータを伝送するために、伝送シーケンスの全ての部分が適切に実行されるようにするルール・セットをもつことが必要である。これらのルールの各々はプロトコルと呼ばれ、ルール・セットはプロトコル・スイートと呼ばれる。ＬＡＮ（ローカル・エリア・ネットワーク）及びＷＡＮ（ワイド・エリア・ネットワーク）のようなインターネットその他の種々のネットワーク上でデータを伝送するときに用いられる最も一般的なプロトコル・セットは、ＴＣＰ／ＩＰ（伝送制御プロトコル／インターネット・プロトコル）プロトコル・スイートによって提供されるものである。ＴＣＰ／ＩＰプロトコル・スイートは、異なるオペレーティング・システムで動作する種々の異なるタイプのコンピュータが互いに通信することを可能にする。ＴＣＰ／ＩＰは、ワールドワイド・インターネット、文字どおり地球全体にわたる１００万台を超えるコンピュータのワイド・エリア・ネットワークのための基礎を形成する。ＴＣＰ／ＩＰスイートに加えて、ＩＰＸ／ＳＰＸ（Ｉｎｔｅｒｎｅｔ  Ｐａｃｋｅｔ  Ｅｘｃｈａｎｇｅ／Ｓｅｑｕｅｎｃｅｄ  Ｐａｃｋｅｔ  Ｅｘｃｈａｎｇｅ）、及びＮｅｔＢｉｏｓを含む多くの他のネットワーク・プロトコル・スイートが存在する。独自の研究グループによって独創的に開発されていても、ほとんどのネットワーク・プロトコルは、オープン（使用を限定されない）スタンダードであり、それらの多くは、一連の数字の番号が付されたＲＦＣ（Ｒｅｑｕｅｓｔ  ｆｏｒ  Ｃｏｍｍｅｎｔ）ペーパとして公表されている。例えば、ＩＰプロトコルはＲＦＣ７９１である。ＲＦＣペーパは、インターネット上で又は種々のライブラリですぐに入手することができる。これらのネットワーク・プロトコル・スイートの各々は、それぞれは別個のものではあるが、層の組からなる類似の構造であり、その各層は通信タスクの異なる面を担っている。便宜上、以下の説明は、主にＴＣＰ／ＩＰプロトコルを用いるときの本発明の使用についてなされる。しかしながら、当業者であれば、本発明の原理はＴＣＰ／ＩＰプロトコルに関連して説明されているが、本発明はその他の種々のネットワーク・プロトコルにも同様に適用可能であることが分かるであろう。
【００１１】
フロー制御は、伝送メディアによって提供された帯域幅を最大限に活用するために、受信側と送信側との間の処理及びバッファリング容量の不一致を取り扱うプロシージャである。ＴＣＰフロー制御機構は、ＴＣＰエンドポイントがデータを放出する速度を制限するように専らエンドステーションにおいて動作する。しかしながら、ＴＣＰには明示的なデータ速度制御はない。基本的なフロー制御機構は、最後の明示的に確認通知されたバイトを越えるバイト範囲上に重ねられる「スライディング・ウィンドウ」である。スライディング・ウィンドウは、サーバから一番最近送信されたバイトとクライアントからの受信確認通知がまだ受け取られていない最古のバイトとの間の最大数の一連のバイトを制限する。このスライディング動作は、ＴＣＰエンドポイントを放出することができる確認通知されていない伝送可能データの量を制限する。受信側ホストは、接続設定段階の間に、任意の時点で未処理の（確認通知されていない）可能性がある「最大」数のパケットに関連するバッファ容量を送信側ホストに通知する。これは、受信側又はスライディング・ウィンドウ・サイズ、ｒｗｎｄである。送信側は、現在のサイズ、ｗｎｄが確認通知（ＡＣＫ）を待たずにどれだけの量のパケットがネットワークに送り込まれるかの推定である、伝送ウィンドウを保持する。ｗｎｄの上限がｒｗｎｄである。
【００１２】
スライディング・ウィンドウの限度を超えたときには、種々のアルゴリズムがパケットを自動的に再送信し、データ伝送をゆっくり再開する。したがって、データ・コレクションの伝送の最中にサーバとクライアントとの間のリンクがシャットダウンされた場合には、サーバは、クライアントによって確認通知された最後のパケットの１スライディング・ウィンドウ内でパケットの送信を止める。このスライディング・ウィンドウの使用は、ネットワークを通るデータ伝送の帯域幅を本質的に制限する。
【００１３】
ＴＣＰにおけるスロー・スタート（ＳＳ）アルゴリズムは、ウィンドウ・サイズをゼロに設定し、接続を開始し又は再開するときに伝送ルートの未知の容量を見積もる。データ・パスの帯域幅と遅延との積が、伝送ルートの容量の概算である。ＳＳアルゴリズムが繰り返されるたびに、ウィンドウ・サイズが、帯域幅と遅延との積の推定に達するように倍にされる。
【００１４】
ＴＣＰ輻輳回避アルゴリズムは、伝送速度を制御された形で減少させることによってネットワークの輻輳に反応する。輻輳は、パケットの欠落の結果としてのスイッチング・ポイント（例えばゲートウェイ又はルータ）におけるデータグラムのオーバーロードに起因する重大な遅延状態である。送信側は、影響を受けたパケットを再送することによって遅延及びパケット損失に反応する。これが輻輳に加わって、輻輳が急速に増大し、輻輳崩壊として現在知られているようなことが起こる。タイムアウトにより元のＡＣＫが失われていることが検出されたときに、又は受信側が順序どおりでないパケットの受信に応答して重複確認通知（ＤＡＣＫ）を送信したときに、輻輳回避が開始される。これが開始されると、輻輳回避アルゴリズムの前のイテレーションで計算された伝送ルート容量の推定値が、変数ｓｓｔｈｒｅｓｈとして保存される。したがって、この推定値は、スロー・スタートが実行され、伝送ルート容量が後で再び見積もられるまで閾値として用いられる。ｓｓｔｈｒｅｓｈのウィンドウ・サイズを超えると、ウィンドウ・サイズの直線的増加が採用される。輻輳によって支配されるウィンドウ・サイズの実行中の推定値を保存するために、別の変数ｃｗｎｄが用いられる。伝送ウィンドウは、輻輳ウィンドウ及びスライディング・ウィンドウのうち小さい方に制限されることが分かる（すなわち、ｗｎｄ＝ｍｉｎ（ｃｗｎｄ，ｒｗｎｄ））。さらに、タイムアウトによって輻輳が示される場合には、ｃｗｎｄは１セグメント・サイズに設定され、スロー・スタートが強いられる。
【００１５】
ＴＣＰ性能を強化するための別の機構は、Ｆａｓｔ  Ｒｅｔｒａｎｓｍｉｓｓｉｏｎ  ａｎｄ  Ｒｅｃｏｖｅｒｙ（ＦＲＲ）アルゴリズムである。特定の伝送に関して受け取られたＤＡＣＫの数が閾値（ｔｙｐ３）に達したときに、ＴＣＰが失われたパケットを再送し、ウィンドウが１に近づけられるのではなく２分の１に減少される。タイムアウト（輻輳の強い表示）又はＤＡＣＫ（輻輳の弱い表示）によって輻輳が検出されると、現在の輻輳ウィンドウ（ｃｗｎｄ）の半分がｓｓｔｈｒｅｓｈに保存されて、輻輳回避がなされる。これは、輻輳制御アルゴリズムの乗算減少部である。さらに、再送が最後に確認通知されたときにパケットのバーストが伝送されるのを防ぐために、輻輳回避が実行されていながら各ＤＡＣＫと共に新しいパケットが伝送される。伝送ウィンドウ（ｗｎｄ）を超える連続した数のパケット又は伝送における最後のパケットが失われたときに、ＦＲＲが失敗する。
【００１６】
図２は、本発明の好ましい実施形態において用いることができるサーバ・クライアント・システムの典型的なソフトウェア・アーキテクチャの図である。サーバ１０４及びクライアント１０６の各々は、ソフトウェア・アーキテクチャ２００と共に設計される。最下位レベルにおいて、ユーザに及び他のソフトウェアにハイレベルの機能を提供するために、オペレーティング・システム２０５が用いられる。こうしたオペレーティング・システムは、典型的には、ＢＩＯＳ（Ｂａｓｉｃ  Ｉｎｐｕｔ  Ｏｕｔｐｕｔ  Ｓｙｓｔｅｍ）を含む。通信ソフトウェア２１０は、ネットワーク上での通信のために、オペレーティング・システムの機能を直接呼び出すか、又は間接的に、オペレーティング・システムをバイパスしてハードウェアにアクセスするかのいずれかによって、物理的通信リンクを介してインターネットのようなネットワークへの外部ポートを通る通信を提供する。アプリケーション・プログラミング・インターフェース２１５は、システムのユーザが、特定の機能がどのように実装されるかに関係なく、標準整合インターフェースを用いてシステムのボリュームを呼び出すことを可能にする。インターネット・ソフトウェア２２０は、コンピュータにインターネット機能を備えさせるために利用可能な幾つかの標準商業パッケージのいずれか１つを表す。アプリケーション・ソフトウェア２２５は、通信ポートを通じてデータに反応して、ユーザが求める所望の機能を提供するように設計された、あらゆる数のソフトウェア・アプリケーションを表す。このレベルのアプリケーションは、インターネット・ユーザによってアクセスされることが可能なデータ、ビデオ、グラフィックス、写真又はテキストを取り扱う必要があるものを含む。
【００１７】
図３に示されるように、ＴＣＰ／ＩＰ及びそれに類似のプロトコルは、アプリケーション層３１０、トランスポート層３１２、ネットワーク層３１４、及びリンク層３１６を含む、ネットワークのための４層通信アーキテクチャ３００によって用いられる。各層は、以下のような、種々の通信タスクを取り扱うための役目をもっている。リンク層３１６（データリンク層又はネットワーク・インターフェース層とも呼ばれる）は、普通は、オペレーティング・システムのデバイス・ドライバと、それに対応するコンピュータのネットワーク・インターフェース・カードを含む。それらは共に、使用されるネットワーク媒体、例えばイーサネットケーブル等と物理的にインターフェースする全てのハードウェアの詳細を取り扱う。
【００１８】
ネットワーク層３１４（インターネット層とも呼ばれる）は、ネットワーク中のデータ・パケットの移動を取り扱う。例えば、ネットワーク層は、ネットワーク上で伝送された種々のデータ・パケットのルーティングを取り扱う。ＴＣＰ／ＩＰスイートのネットワーク層は、ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）、ＩＣＭＰ（Ｉｎｔｅｒｎｅｔ  Ｃｏｎｔｒｏｌ  Ｍｅｓｓａｇｅ  Ｐｒｏｔｏｃｏｌ）及びＩＧＭＰ（Ｉｎｔｅｒｎｅｔ  Ｇｒｏｕｐ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ）を含む幾つかのプロトコルからなる。
【００１９】
トランスポート層３１２は、２つのホストコンピュータ間のデータの伝送を容易にする、ネットワーク層３１４とアプリケーション層３１０との間のインターフェースを提供する。トランスポート層は、アプリケーションから渡されたデータを分割して下のネットワーク層に適したサイズのチャンクにする、受け取ったパケットを確認通知する、送信されたパケットの確認通知が相手側に確実になされるようにタイムアウトを設定する、といったイベントに関連する。ＴＣＰ／ＩＰプロトコル・スイートにおいては、２つの明確に異なるトランスポート・プロトコル、すなわち、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）及びＵＤＰ（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ）がある。ＴＣＰは、２つのホスト間でデータが適切に伝送されることを保証する、ドロップアウト検出及び再送サービスを含む信頼性サービスを提供する。逆に、ＵＤＰは、データが適切に伝送されたことを保証するための何らかの機構を備えることなく、１つのホストから他のホストへの、データグラムと呼ばれるデータ・パケットの単純な送信によって、アプリケーション層に非常に単純なサービスを提供する。ＵＤＰを用いたときには、アプリケーション層は、信頼性機能を実行しなければならない。
【００２０】
アプリケーション層３１０は、特定のアプリケーションの詳細を取り扱う。ほぼ全ての実装を提供する、（１）リモート・ログインのためのＴｅｌｎｅｔ、（２）ＦＴＰ、Ｆｉｌｅ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ、（３）電子メールのためのＳＭＴＰ、Ｓｉｍｐｌｅ  Ｍａｉｌ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ、及び（４）ＳＮＭＰ、Ｓｉｍｐｌｅ  Ｎｅｔｗｏｒｋ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌを含む、多くの一般的なＴＣＰ／ＩＰアプリケーションが存在する。
【００２１】
インターネットのようなネットワークは、ルータによって互いに接続され、その各々は、２つ又はそれ以上のネットワークを互いに接続する。典型的なルータは、入力及び出力接続、専用ハードウェア、及び／又は、イーサネット、トークンリング、２地点間リンク等といった多くの異なる形式の物理的ネットワークが接続されることを可能にする内蔵型ソフトウェアを有する特殊目的ハードウェアボックスを含む。図４は、ルータ４３６によってトークン・リング・ネットワークに４３４に接続されたイーサネット・ネットワーク４３２を含むインターネット４００を示す。図４は、通信する２つのみのホストが示されているが、イーサネット・ネットワーク上のいずれのホストも該イーサネット・ネットワーク上のいずれかのホストと、又はトークン・リング・ネットワーク上のいずれかのホストと通信可能であり、この逆も可能である。
【００２２】
図４に示されるように、ルータ４３６は、ネットワーク層モジュール４３８（この場合はＩＰモジュール）と、ホスト・ネットワークに接続するための適切なネットワーク・ドライバ、すなわちイーサネット・ドライバ４４０及びトークン・リング・ドライバ４４２とを含む。アプリケーション層において、ネットワークは、ＦＴＰクライアント４２０とＦＴＰサーバ４２２とを含む。ほとんどのネットワーク・アプリケーションは、一方のエンドがクライアントで、他方がサーバであるように設計される。サーバは、ある種のサービス、この場合はサーバホスト上のファイルへのアクセスを種々のクライアントに提供する。各層は、同じ層においてそのピアと通信するための１つ又はそれ以上のプロトコルを有する。これらの通信プロトコルは、アプリケーション層におけるＦＴＰプロトコル４４４と、トランスポート層におけるＴＣＰプロトコル４４６と、ネットワーク層におけるＩＰプロトコル４４８と、リンク層におけるイーサネット・プロトコル４５０及びトークン・リング・プロトコル４５４とを含む。アプリケーション層は、通常、ユーザプロセスを取り扱うが、その下の３つの層（トランスポート、ネットワーク及びリンク）は、ＵＮＩＸ又はＷｉｎｄｏｗｓオペレーティング・システムといったオペレーティング・システムのカーネルにおいて実装される。例えば、ネットワーク・インターフェース層の目的は、通信媒体（イーサネット、トークン・リングなど）の詳細を取り扱うことであり、一方、アプリケーション層の目的は、１つの特定のユーザ・アプリケーション（ＦＴＰ、Ｔｅｌｎｅｔなど）を取り扱うことである。
【００２３】
アプリケーション層及びトランスポート層は、エンド・ツー・エンド・プロトコル（ＦＴＰプロトコル４４４、ＴＣＰプロトコル４４６）を用いる。ネットワーク層は、２つのエンドシステム及びそれらの間の全ての中間システム上で用いられるホップ・ツー・ホップ・プロトコルを提供する（明確にするために、ここでは１つのみの中間システムが示されている）。例えば、ルータ４３６のＩＰモジュール４３８は、ＩＰプロトコル４４８によって２つのホストに接続される。リンク層におけるネットワークとルータとの間の通信を取り扱うために、ルータに接続された種々の形式のホスト・ネットワークに固有のリンク層プロトコルも存在する。したがって、ルータ４３６のイーサネット・ドライバ４４０とイーサネット・ネットワーク４３２上のホストのイーサネット・ドライバ４５２との間の通信を取り扱うためにイーサネット・プロトコル４５０が用いられ、一方、ルータ４３６のトークン・リング・ドライバ４４２とトークン・リング・ネットワーク４３４上のホストのトークン・リング・ドライバ４５６との間の通信を取り扱うためにトークン・リング・プロトコル４５４が用いられる。
【００２４】
ＴＣＰ／ＩＰプロトコル・スイートにおいては、ネットワーク層、ＩＰは、信頼性のあるサービスを提供しない。ＩＰは、パケットをソースから宛先に移動させるが、送達を保証するための機構を提供せず、適切な転送が行われたかを判断することはできる。ＴＣＰは、２つのホスト間でデータが適切に伝送されたことを保証する、ドロップアウト検出及び再送サービスを含む、信頼性サービスを提供する。
【００２５】
ルータは、２つ又はそれ以上のネットワーク・インターフェース層を有する（ルータは２つ又はそれ以上のネットワークを接続するものであるため）。複数のインターフェースを備えたシステムは、マルチホームと呼ばれる。ホストもまたマルチホームとすることができるが、特に１つのインターフェースから別のインターフェースにパケットを転送しない限り、それをルータとは呼ばない。また、ルータは、インターネット中で唯一パケットを移動させる特別なハードウェアボックスである必要はない。ほとんどのＴＣＰ／ＩＰの実装は、マルチホーム・ホストがルータとして働くことを可能にするが、ホストは、この用途をサポートするように構成される必要がある。こうした場合には、システムは、ホスト（ＦＴＰ又はＴｅｌｎｅｔといったアプリケーションが用いられるとき）か、又はルータ（１つのネットワークから他のネットワークにパケットを転送するとき）のいずれかである。ネットワークを接続する別の方法は、ブリッジを設けることである。ブリッジは、リンク層においてネットワークを接続し、一方、ルータは、ネットワーク層においてネットワークを接続する。ブリッジは、複数のＬＡＮが上の層に単一のＬＡＮとして現れるようにする。
【００２６】
アプリケーションがＴＣＰ／ＩＰを用いてデータを送るときに、データは、該データがネットワークを横切るビット・ストリームとして送られるまで、プロトコル・スタックの各層を通って下方に送られる。図５に示されるように、各層は、受信したデータにヘッダを付加する（時にはトレーラー情報を付加する）ことによって、データに情報を付加する。例えば、アプリケーション層において、アプリケーション・ヘッダ５８０がユーザデータ５８２に付加されてアプリケーション・データ５８４が形成される。トランスポート層において、アプリケーション・データにトランスポート・プロトコル・ヘッダが付加される。図５の場合、トランスポート層がＴＣＰであり、したがって、アプリケーション・データ５８４にＴＣＰヘッダ５８６が付加され、それにより、ネットワーク層ＩＰに送られるＴＣＰフレーム５８８が形成される。ＴＣＰヘッダ５８６は、２０バイトを構成する。同様に、ネットワーク層においては、ネットワーク層ヘッダがトランスポート層データに付加される。ＴＣＰ／ＩＰの場合には、ＩＰヘッダ５９０がＴＣＰフレーム５８８に付加されて、ＩＰデータグラム５９２が形成される。ＩＰヘッダ５９０もまた、２０バイトを構成する。最後に、リンク層において、イーサネット・ヘッダ５９４といったメディア・ヘッダが、ネットワーク層から受信されたデータに付加されて、データ・フレームを形成する。メディアがイーサネットであるような場合には、メディア・トレーラもデータのエンドに付加される。例えば、図５においては、イーサネット・トレーラ５９６がイーサネット・ヘッダ５９４及びＩＰデータグラム５９２に付加されて、イーサネット・フレーム５９８が形成される。イーサネット・フレームは、元のアプリケーション・メッセージ・データに対応する、ネットワークを横切って流れるビット・ストリームを含む。ヘッダの下部の数字（１４、２０、２０、４）は、ヘッダの典型的なバイトサイズであり、例えば、イーサネット・ヘッダ９４は１４バイトを構成する。フレームサイズは、データ・パケットを伝送するのに用いられるネットワークタイプの最大伝送単位（ＭＴＵ）によって制限されることになる。例えば、イーサネット・ネットワークのＭＴＵは１５００バイトである。ネットワーク層は、フラグメンテーション（データグラムを小部分に分断する）を自動的に実行し、それにより各フラグメントはネットワークのＭＴＵより小さくなる。
【００２７】
特定のデータ・フレームがデータ伝送ストリームから欠落しているとクライアントが検出したときに、クライアントは、確認通知フレームにおいて未着フレームの最初のバイトの順序番号を送信することによって、サーバが未着フレームを再送することをクライアントが要求する。図６に示されるように、ＴＣＰは、典型的にはメディア・ヘッダ６１２、プロトコル・ヘッダ６１４、受信順序番号フィールド６１６、送信順序番号フィールド６１８、及びメッセージ本体６２０を含むメッセージ６１０を送信し又は再試行する。メディア・ヘッダ６１２は、特にネットワークタイプのもの、例えばイーサネット・ネットワーク用のイーサネット・ヘッダなどである。プロトコル・ヘッダ６１４は、ＴＣＰ／ＩＰ、ＩＰＸ／ＳＰＸ、Ｎｅｔｂｉｏｓなどのような使用されるトランスポート及びネットワーク層プロトコルに依存する。受信順序番号フィールド６１６は、コンピュータによって確実に受信された最後の順序番号への識別子を提供する。送信順序番号６１８は、メッセージの相対順序番号に対応する。メッセージ本体６２０は、ソース及び宛先コンピュータ間で送信されるアプリケーション・データを含む。ＴＣＰ確認通知フレーム６２２は、メディア・ヘッダ６２４、プロトコル・ヘッダ６２６、受信順序番号フィールド６２８、及び送信順序番号フィールド６３０を含む。これらのフィールドは、同じ名前をもつ上述のフィールドに類似している。送信又は再試行メッセージの受取の確認通知をするために、確認通知フレーム６２２が受信側コンピュータによって送信される。ＴＣＰにおいては、未着フレームを示す３つの連続する確認通知フレームを受信すると、サーバは、普通は、未着の順序番号で始まる未着フレームを「高速再送」することになる。こうした再送は、サーバがそのスライディング・ウィンドウを縮小し、送信するデータ量を減少させるため、性能に悪影響を及ぼす。
【００２８】
ここで図７を参照すると、本発明の好ましい実施形態によって提供される改善されたＴＣＰ性能の例に関するタイミング・ダイアグラムが示されている。図７に示された例は、送信側７０５がネットワーク７１５を介して５つのデータ・パケットを受信側７１０に伝送するときのタイミング・ダイアグラム７００を示す。時刻Ａにおいて、パケット１がネットワーク７１５に送信される。時刻Ｂにおいて、パケット１がネットワーク７１５から受信側７１０に伝送される。時刻Ｃにおいて、受信側７１０は、パケット１の受取を確認通知し、パケット２（ＡＣＫ２）を要求する。時刻Ｄにおいて、ＡＣＫ２がネットワーク７１５から送信側７０５に伝送される。
【００２９】
時刻Ｅ、Ｆ、Ｇ及びＨにおいて、送信側７０５は、パケット２、３、４及び５をそれぞれネットワーク７１５に伝送する。しかしながら、ネットワーク７１５は、送信側７０５から受信したパケットを再び順序付けし、時刻Ｉに見られるように、最初にパケット３を受信側７１０に伝送する。パケット３の受取に応答して、受信側７１０は、時刻Ｊにおいて、受信側７１０がパケット２をまだ受け取っておらず、かつパケット３が順番を抜かして受信されたことを示す重複ＡＣＫ２（ＤＡＣＫ２）を伝送する。時刻Ｋにおいて、ＤＡＣＫ２がネットワーク７１５から送信側７０５に伝送される。また、時刻Ｋにおいて、ネットワーク７１５がパケット４を受信側７１０に伝送する。それに応答して、時刻Ｌにおいて、パケット４が順番を抜かして受信され、かつパケット２を要求することを示す第２のＤＡＣＫ２を受信側７１０が伝送する。時刻Ｍにおいて、この第２のＤＡＣＫ２は、ネットワーク７１５から送信側７０５に送られ、パケット５がネットワーク７１５から受信側７１０に渡される。時刻Ｎにおいて、受信側７１０は、第３のＤＡＣＫ２を再送し、パケット５の受取を確認通知し、再びパケット２を要求することによって、パケット５の受取に応答する。時刻Ｏにおいて、この第３のＤＡＣＫ２が送信側７０５でネットワーク７１５から受信される。また、時刻Ｏにおいて、受信側７１０は、最後にネットワーク７１５からパケット２を受け取る。時刻Ｐにおいて、送信側７０５は、第３のＤＡＣＫ２を受け取った後に、ＴＣＰプロトコルによって特定されるようにパケット２を「高速再送」する。ＴＣＰは、ネットワーク７１５上の輻輳の結果として第３のＤＡＣＫの受取を考慮に入れるので、送信側７０５は、パケット２を再送すると、輻輳ウィンドウを５０パーセント減少させる。また、時刻Ｐにおいて、受信側７１０は、このときパケット２、３、４及び５を受信しており、パケット６を要求するＡＣＫに応答する。ネットワーク７１５におけるパケットの再配列の結果として、ＡＣＫ６及び再送されたパケット２は、両方ともネットワーク７１５内に同時に存在する。（このタイミングは、単なる一例であり、プロセスにおいては他のタイミングも起こりうることを理解されたい。本発明の方法の適切な動作に関する唯一のタイミング要件は、受信側７１０が再送されたパケット２を受信する前に受信側７１０からＡＣＫ６が伝送されることである。）時刻Ｑにおいて、受信側７１０は、ネットワーク７１５から再送されたパケット２を受信する。時刻Ｒにおいて、送信側７０５は、ネットワーク７１５からＡＣＫ６を受信する。
【００３０】
この時点では、パケットの再送後に時刻Ｒにおいて受信されたＡＣＫ６が、パケット２の元の伝送又は再送に応答したものであるかどうかは不明である。従来技術では、ＡＣＫは、受信側７１０が再送されたパケット２を受信した結果であるとみなされ、そのため、ＴＣＰにおいては、送信側７０５は、輻輳ウィンドウの減少を伴って動作し続ける。しかしながら、本発明の好ましい実施形態は、送信側７０５に、実際のパケット・ロス・イベントの結果として受信されたＡＣＫとパケットの再配列の結果として受信されたＡＣＫとを区別する方法を提供する。送信側７０５が、好ましい実施形態に従って、再配列の結果として高速再送が起こったと判断した場合には、輻輳制御及び回避は行われず、それによりＴＣＰ帯域幅に対する不必要な制約がなくされる。
【００３１】
本発明の好ましい実施形態は、「高速再送」によってパケットを再送して輻輳ウィンドウを減少させる前に、送信側７０５が現在の輻輳状態をＳＳＴｈｒｅｓｈ及びｃｗｎｄを表す変数ＣＣＳとしてセーブするときに始まるプロセスである。再送されたパケットを受取通知する後続のＡＣＫ（図７の例においてはＡＣＫ６）を受信した後に、ＴＣＰ送信側７０５が、送信側７０５におけるＡＣＫの到着時刻に基づいて、ＡＣＫが元の再配列されたパケット又は再送されたパケットのいずれの受取によってもたらされたものであるかを判断する。再送されたパケットのラウンド・トリップ・タイムに関する計算された時間閾値の有効期限（ＴＨＲＥＳＨ−ＲＴＴ）より前にＡＣＫが到着した場合には、送信側７０５は、ネットワーク７１５においてパケット・ロスではなく再配列が起こったとみなす。この場合、ＣＣＳは、輻輳状態をリストアして保存された値に戻すために用いられ、それにより、ネットワーク輻輳の結果として再送が起こらないため、その元の増加したスループットでシステムが引き続き動作することを可能にする。
【００３２】
閾値再送ＲＴＴ（ＴＨＲＥＳＨ−ＲＴＴ）を計算するために、ＴＣＰ送信側７０５は、パケットが再送される（Ｔ再送）時刻を保存する。再送確認通知が到着すると、送信側７０５が、確認通知が到着した時刻（Ｔ現在）を保存し、次に再送時刻と到着時刻との差（すなわちＴ現在−Ｔ再送）を計算することによってＲＴＴを計算する。この差が、送信側と受信側との間のリンクに関する平均又は現在の計算されたラウンド・トリップ・タイム（ＲＴＴ）よりかなり小さい場合には、再配列イベントの結果として再送が起こるという強い指示がある。次式は、好ましい実施形態におけるこの計算を説明するものである。
（Ｔ現在−Ｔ再送）＜アルファ＊ＲＴＴ
ここで、「アルファ」は、０から１までの間の数であり、送信側と受信側との間の最小の可能なＲＴＴを推定するための係数であり、ＲＴＴにおける変化及びネットワークにおける関連のない急激なＲＴＴのドロップを補償する。好ましい実施形態においては、アルファは、０．５から０．７５の範囲内（すなわち５０−７０パーセント）、好ましくは０．６に設定される。確認された上記の計算に基づいて再配列イベントが検出されると、送信側は、高速再送を行う前に輻輳状態をリストアしてシステム値に戻す（すなわちＣＣＳに関する保存された値に戻す）。理解されるように、好ましい実施形態の機構は、送信側で実装され、受信側の論理に対する変化は要求しない。これは、この技術が、この性能の強化を実装しない全ての既存の及び将来のＴＣＰ実装と共に機能することを保証する。
【００３３】
理解されるように、１つの好ましい実施形態においては、パケットが再送されると輻輳回避が実装され、パケットの再配列を示す早期ＡＣＫの受取の後に元のＣＣＳに復帰される。別の好ましい実施形態においては、輻輳回避の実装は、再送に対するタイムリーな応答ＡＣＫが受信された後に、パケット・ロスに起因するネットワーク輻輳が確認されるまで、高速再送の後に遅延される。
【００３４】
ここで図８を参照すると、本発明の好ましい実施形態に係る、パケットの再配列の後の改善されたＴＣＰ性能のためのプロセスの流れ図が示されている。プロセス８００は送信側７０５で受信された重複確認通知の数がトランスポート・プロトコルにおける閾値数を超えたときにステップ８０５で始まり、指定されたパケットのＦａｓｔ  Ｒｅｔｒａｎｓｍｉｓｓｉｏｎ  ａｎｄ  Ｒｅｃｏｖｅｒｙ（ＦＲＲ）をトリガする。ＴＣＰプロトコルにおいては、ＦＲＲは通常、送信側７０５が３ＤＡＣＫを受信したときに起こる。その後、プロセスがステップ８１０に進み、そこで、送信側７０５が現在の輻輳状態（ＣＳＳ）を保存し、該ＣＳＳは、輻輳ウィンドウ及びスロー・スタート閾値を含み、スロー・スタート閾値（ＳＳＴｈｒｅｓｈ）をその現在値の半分まで減少させることによって輻輳回避を実施する。次に、プロセスがステップ８１５に進み、そこで、送信側７０５が指定されたロスト・パケットを再送し、変数Ｔ再送の下で再送が起こる時刻を保存する。次に、プロセスがステップ８２０に進み、その時点で、送信側７０５が再送されたパケットの確認通知を受信し、この確認通知の到着時刻を変数Ｔ現在として保存する。その後、プロセスがステップ８２５に進み、そこで、再送時刻とパケットの確認通知到着時刻との間の差を求めることによって、再送されたパケットに関するラウンド・トリップ・タイム（ｒｒｔ）が計算される。次に、プロセスが決定ブロック８３０に進み、そこで、再送されたパケットのラウンド・トリップ・タイムが、送信側７０５と受信側７１０との間のルートに関する最小期待ラウンド・トリップ・タイムより所定の量だけ小さいかどうかを判断し、該所定の量は、ネットワーク７１５内のリンク及びＲＴＴにおける理論上起こりうる急激なドロップの特徴の関数である。この所定量は、「アルファ」によって表される係数を伴って実装され、０から１までの間、好ましくは０．５から０．７５の範囲内に設定される。したがって、ステップ８３０における決定は、式、ｒｒｔ＜アルファ＊ＲＴＴで表すことができる。ステップ８３０における決定が否定である場合には、プロセスはステップ８４０に進み、そこで、ロスト・パケットに応答して輻輳回避が適切に実施されたと判断されるため、プロセスが終了する。ステップ８３０における決定が肯定である場合には、プロセスがステップ８３５に進み、そこで、送信側７０５の輻輳状態が、ステップ８１０で保存されたＣＣＳにリストアされ、その後プロセスがステップ８４０において終了する。
【００３５】
ステップ８２５において計算されたラウンド・トリップ・タイムは、確認通知が、元のパケットが再ルーティングされ受信側７１０に到着するのに応答して受信されたのであって、再送されたパケットの受取に応答して受信されたのではないことを示すので、輻輳状態は、送信側７０５が高速再送を始める前に存在するＣＣＳに戻されることを理解されたい。したがって、好ましい実施形態によれば、伝送されたパケットの再配列に起因する輻輳回避の誤ったトリガは、輻輳状態をＣＣＳに復元することにより無効にされ、それにより、そうでなければＴＣＰ輻輳回避の実装によってスロットルされるであろうスループットが増加することによって、性能が強化される。
【００３６】
本発明は、特に好ましい実施形態に関連して図示され説明されたが、当業者であれば、本発明の精神及び範囲から逸脱することなく、本発明に形式及び細部の種々の変更をなしうることを理解するであろう。例えば、本発明は、コンピュータ・プログラミング・ソフトウェア、ファームウェア又はハードウェアのいずれかの組み合わせを用いて実装することができる。本発明を実施する、又は本発明に係る装置を構成するための準備段階として、本発明に係るコンピュータ・プログラミング・コード（ソフトウェア又はハードウェアのいずれか）が、通常は、固定（ハード）ドライブ、ディスケット、光ディスク、磁気テープ、ＲＯＭ、ＰＲＯＭのような半導体メモリといった、１つ又はそれ以上の機械可読ストレージ・メディアに格納され、それにより本発明に係る製品が形成される。コンピュータ・プログラミング・コードを格納した製品は、コードを直接ストレージ・デバイスから実行するか、コードをストレージ・デバイスからハードディスク、ＲＡＭなどのような別のストレージ・デバイスにコピーするか、遠隔実行するためにコードを伝送することのいずれかによって用いられる。本発明を実施する方法は、コードを格納した１つ又はそれ以上の機械可読ストレージ・デバイスを、適当な標準コンピュータ・ハードウェアと組み合わせて、コードを実行することによるものとすることができる。本発明を実施するための装置は、１つ又はそれ以上のコンピュータと、本発明に従ってコード化されたコンピュータ・プログラムへのネットワーク・アクセスを含む又は有するストレージ・システムとすることができる。
【図面の簡単な説明】
【００３７】
【図１】本発明の好ましい実施形態を実装可能なデータ処理システム・ネットワークを示す図である。
【図２】本発明の好ましい実施形態において用いることができる、サーバ・クライアント・システムの典型的なソフトウェア・アーキテクチャの図である。
【図３】ＴＣＰ／ＩＰを用いる４層通信アーキテクチャの例を示す図である。
【図４】ルータによってトークン・リング・ネットワークに接続されたイーサネット・ネットワークを含むインターネットの例を示す図である。
【図５】ＴＣＰ／ＩＰプロトコル・スタックをトラバースする際のデータ・フォーマットを示す図である。
【図６】ＴＣＰ送信又は再試行フレーム及びＴＣＰ確認通知フレームのデータ構造を示す図である。
【図７】本発明の好ましい実施形態によって提供される改善されたＴＣＰ性能の例のタイミング図である。
【図８】本発明の好ましい実施形態に係る、パケットの再配列の後の改善されたＴＣＰ性能のプロセスの流れ図である。
【手続補正書】
【提出日】平成19年6月28日(2007.6.28)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
送信側と受信側との間にネットワーク接続を有し、該ネットワーク接続がある輻輳状態で動作するネットワークにおいてパケットの再配列の後のトランスポート層の性能を改善する方法であって、
前記ネットワーク接続を介して前記受信側において未着のデータ・パケットが伝送されることを要求する、所定閾値数の第１の確認通知を送信側で受け取るステップと、
所定閾値数の第１の確認通知を受け取る前記ステップに応答して、前記要求されたデータ・パケットを前記ネットワーク接続を介して送信側から受信側に伝送するステップと、
前記要求されたデータ・パケットが受信側によって受信されたことを示す第２の確認通知を送信側で受け取るステップと、
前記第２の確認通知が受け取られた時刻と前記要求されたデータ・パケットが伝送された時刻との差を計算するステップと、
前記ネットワーク接続を介するデータ・パケットの最小ラウンド・トリップ・タイムである閾値ラウンド・トリップ・タイムより前記差が大きい場合に、輻輳回避処理を実施するステップと
を含む方法。
【請求項２】
送信側と受信側との間にネットワーク接続を有し、該ネットワーク接続がある輻輳状態で動作するネットワークにおいてパケットの再配列の後のトランスポート層の性能を改善する方法であって、
前記ネットワーク接続を介して前記受信側において未着のデータ・パケットが伝送されることを要求する、所定閾値数の第１の確認通知を送信側で受け取るステップと、
前記要求されたデータ・パケットを伝送する前に前記ネットワーク接続の輻輳ウィンドウの現在の値を保存するステップと、
所定閾値数の第１の確認通知を受け取る前記ステップに応答して、前記要求されたデータ・パケットを前記ネットワーク接続を介して送信側から受信側に伝送するステップと、
前記要求されたデータ・パケットを伝送すると前記輻輳ウィンドウの値を現在設定されている値よりも小さい値に設定するステップと、
前記要求されたデータ・パケットが受信側によって受信されたことを示す第２の確認通知を送信側で受け取るステップと、
前記第２の確認通知が受け取られた時刻と前記要求されたデータ・パケットが伝送された時刻との差を計算するステップと、
前記ネットワーク接続を介するデータ・パケットの最小ラウンド・トリップ・タイムである閾値ラウンド・トリップ・タイムより前記差が小さい場合に、前記輻輳ウィンドウの値を保存した値に戻すステップと
を含む方法。
【請求項３】
前記所定閾値数が３である、請求項１又は２に記載の方法。
【請求項４】
前記設定するステップは更に、前記ネットワーク接続のスロー・スタート閾値の値を現在設定されている値よりも小さい値に設定する、請求項２に記載の方法。
【請求項５】
前記ネットワーク接続がＴＣＰプロトコルに準拠して動作する、請求項１又は２に記載の方法。
【請求項６】
前記閾値ラウンド・トリップ・タイムが、前記ネットワーク接続に関する平均ラウンド・トリップ・タイムの５０パーセントから７５パーセントの間である、請求項１又は２に記載の方法。
【請求項７】
送信側と受信側との間にネットワーク接続を有するネットワークにおけるパケット再配列の後のトランスポート層の改善された性能を提供するデータ処理システムであって、前記送信側である前記システムは、
前記受信側において未着のデータ・パケットが伝送されることを要求する、所定閾値数の第１の確認通知を受信側から受け取るための手段と、
所定閾値数の第１の確認通知の受信に応答して、要求されたデータ・パケットを受信側に伝送するための手段と、
要求されたデータ・パケットが受信側によって受信されたことを示す第２の確認通知を受信するための手段と、
前記第２の確認通知が受け取られた時刻と要求されたデータ・パケットが伝送された時刻との差を計算するための手段と、
前記ネットワーク接続を介するデータ・パケットの最小ラウンド・トリップ・タイムである閾値ラウンド・トリップ・タイムより前記差が大きい場合に、輻輳回避処理を実施するための手段と、
を含むシステム。
【請求項８】
送信側と受信側との間にネットワーク接続を有するネットワークにおけるパケット再配列の後のトランスポート層の改善された性能を提供するデータ処理システムであって、前記送信側である前記システムは、
前記受信側において未着のデータ・パケットが伝送されることを要求する、所定閾値数の第１の確認通知を受信側から受け取るための手段と、
前記要求されたデータ・パケットを伝送する前に前記輻輳ウィンドウの現在の値を保存するための手段と
所定閾値数の第１の確認通知の受信に応答して、要求されたデータ・パケットを受信側に伝送するための手段と、
前記要求されたデータ・パケットを伝送すると前記輻輳ウィンドウの値を現在設定されている値よりも小さい値に設定するための手段と、
要求されたデータ・パケットが受信側によって受信されたことを示す第２の確認通知を受信するための手段と、
前記第２の確認通知が受け取られた時刻と要求されたデータ・パケットが伝送された時刻との差を計算するための手段と、
前記ネットワーク接続を介するデータ・パケットの最小ラウンド・トリップ・タイムである閾値ラウンド・トリップ・タイムより前記差が小さい場合に、前記輻輳ウィンドウの値を保存した値に戻すための手段と
を含むシステム。
【請求項９】
前記所定閾値数が３である、請求項７又は８に記載のデータ処理システム。
【請求項１０】
前記設定するための手段は更に、前記ネットワーク接続のスロー・スタート閾値の値を現在設定されている値よりも小さい値に設定する、請求項８に記載のデータ処理システム。
【請求項１１】
前記ネットワーク接続がＴＣＰプロトコルに準拠して動作する、請求項７又は８に記載のデータ処理システム。
【請求項１２】
前記確認通知が前記受信側から前記インターネットを介して送られる、請求項７又は８に記載のデータ処理システム。
【請求項１３】
送信側と受信側との間にネットワーク接続を有し、該ネットワーク接続がある輻輳状態で動作するネットワークにおいてパケットの再配列の後のトランスポート層の性能を改善するプログラムであって、前記プログラムは前記送信側であるデータ処理システムに、
ネットワーク接続を介して前記受信側において未着のデータ・パケットが伝送されることを要求する、所定閾値数の第１の確認通知を受け取るステップと、
所定閾値数の第１の確認通知を受け取る前記ステップに応答して、前記要求されたデータ・パケットを前記ネットワーク接続を介して受信側に伝送するステップと、
前記要求されたデータ・パケットが受信側によって受信されたことを示す第２の確認通知を受け取るステップと、
前記第２の確認通知が受け取られた時刻と前記要求されたデータ・パケットが伝送された時刻との差を計算するステップと、
前記ネットワーク接続を介するデータ・パケットの最小ラウンド・トリップ・タイムである閾値ラウンド・トリップ・タイムより前記差が大きい場合に、輻輳回避処理を実施するステップと
を実行させるプログラム。
【請求項１４】
送信側と受信側との間にネットワーク接続を有し、該ネットワーク接続がある輻輳状態で動作するネットワークにおいてパケットの再配列の後のトランスポート層の性能を改善するプログラムであって、前記プログラムは前記送信側であるデータ処理システムに、
前記ネットワーク接続を介して前記受信側において未着のデータ・パケットが伝送されることを要求する、所定閾値数の第１の確認通知を送信側で受け取るステップと、
前記要求されたデータ・パケットを伝送する前に前記ネットワーク接続の輻輳ウィンドウの現在の値を保存するステップと、
所定閾値数の第１の確認通知を受け取る前記ステップに応答して、前記要求されたデータ・パケットを前記ネットワーク接続を介して送信側から受信側に伝送するステップと、
前記要求されたデータ・パケットを伝送すると前記輻輳ウィンドウの値を現在設定されている値よりも小さい値に設定するステップと、
前記要求されたデータ・パケットが受信側によって受信されたことを示す第２の確認通知を送信側で受け取るステップと、
前記第２の確認通知が受け取られた時刻と前記要求されたデータ・パケットが伝送された時刻との差を計算するステップと、
前記ネットワーク接続を介するデータ・パケットの最小ラウンド・トリップ・タイムである閾値ラウンド・トリップ・タイムより前記差が小さい場合に、前記輻輳ウィンドウの値を保存した値に戻すステップと
を実行させるプログラム。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】０００６
【補正方法】変更
【補正の内容】
【０００６】
本発明は、ネットワークにおいてパケットの再配列の後のトランスポート層の性能を改善する方法を提供するものであり、ネットワークは送信側と受信側との間にある輻輳状態で動作するネットワーク接続を有し、この方法は、ネットワーク接続を介して受信側において未着のデータ・パケットが伝送されることを要求する、所定閾値数の第１の確認通知を送信側で受け取るステップと、所定閾値数の第１の確認通知を受け取るステップに応答して、要求されたデータ・パケットをネットワーク接続を介して送信側から受信側に伝送するステップと、要求されたデータ・パケットが受信側によって受信されたことを示す第２の確認通知を送信側で受け取るステップと、第２の確認通知が受け取られた時刻と前記要求されたデータ・パケットが伝送された時刻との差を計算するステップと、ネットワーク接続を介するデータ・パケットの最小ラウンド・トリップ・タイムである閾値ラウンド・トリップ・タイムより差が大きい場合に、輻輳回避処理を実施するステップとを含む。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】０００７
【補正方法】変更
【補正の内容】
【０００７】
本発明の他の方法は、ネットワーク接続を介して受信側において未着のデータ・パケットが伝送されることを要求する、所定閾値数の第１の確認通知を送信側で受け取るステップと、要求されたデータ・パケットを伝送する前にネットワーク接続の輻輳ウィンドウの現在の値を保存するステップと、所定閾値数の第１の確認通知を受け取るステップに応答して、要求されたデータ・パケットをネットワーク接続を介して送信側から受信側に伝送するステップと、要求されたデータ・パケットを伝送すると輻輳ウィンドウの値を現在設定されている値よりも小さい値に設定するステップと、要求されたデータ・パケットが受信側によって受信されたことを示す第２の確認通知を送信側で受け取るステップと、第２の確認通知が受け取られた時刻と要求されたデータ・パケットが伝送された時刻との差を計算するステップと、ネットワーク接続を介するデータ・パケットの最小ラウンド・トリップ・タイムである閾値ラウンド・トリップ・タイムより差が小さい場合に、輻輳ウィンドウの値を保存した値に戻すステップとを含む。
【国際調査報告】
2007534194.tif 000011
2007534194.tif 000012
2007534194.tif 000013