JP2005269643A - スプリアスタイムアウトに対する応答 - Google Patents

Abstract

【課題】 無線ＷＡＮにおいてスプリアスタイムアウト（ＳＴＯ）に応答するための技術を提供する。
【解決手段】 ＳＴＯ応答により、送信側デバイスが、ＳＴＯの検出の後、輻輳状態パラメータを調整しパケットフローを維持できるようになる。ＳＴＯの発生はデータ損失を伴う場合があるため、ＳＴＯ応答はそれより前に利用可能であった帯域幅の値を維持すること、及び受信確認のパターンに基づき送信側が送信することができる限度を増加させることにより、ＳＴＯと損失イベントを結合する。詳細には、限度は、データパケットの送信の成功を示す受信確認が受信側から受信されるたびに送信側が送信できるデータセグメントの最大サイズだけ増加される。このためさらなるパケット損失ならびに受信側ホストによって正常に受信されている可能性があるデータパケットの再送信を回避しながら、確実なデータフローを維持できる。
【選択図】 図１

Description

本発明は、無線ワイドエリアネットワークにおいてスプリアスタイムアウトに応答するための技術を対象とする。

ＧＰＲＳ（汎用パケット無線サービス）などの無線環境では、再送信タイマは、しばしば、スプリアス的に満了して、送信されたデータの実際の損失が存在しない場合でも、１つまたは複数のデータパケットの不要な再送信をトリガすることが知られている。そのような「スプリアスタイムアウト」として知られる（「ＳＴＯ」とも呼ばれる）タイムアウトは、一般に、伝送制御プロトコル（以降、「ＴＣＰ」）の限界に起因する。

無線ネットワークにおけるスプリアスタイムアウトは、例えば、伝送帯域幅を求めて競合するより高い伝送優先度を有するデータパケットが出現して、スプリアスの再送信タイムアウトをもたらすこと、永続的な信頼できる無線リンクレイヤが、劣悪な無線接続を介してデータパケットを繰り返し再送信して、ＴＣＰ送信側ホストタイムアウトを生じさせること、またはビジーな逆方向チャネルに起因して、受信側ホストが、受信確認メッセージ（以降、「ＡＣＫ」）を送信側ホストに適時に送信できないことを含め、様々な原因を有する。

ＴＣＰスタックにおいて、ＭＳＳ（「最大セグメントサイズ」）が、送信側ホストが、単一のパケット内、または単一のセグメント内で受信側ホストに送信することができる最大データ量（バイト単位の）を示す。一般に、効率のため、送信側ホストは、ＭＳＳに応じてデータパケットを送信する。ＴＣＰウインドウ（以降、「ウインドウ」）とは、送信側ホストが、受信側ホストから、送信されたデータに関する受信確認（「ＡＣＫ」とも呼ばれる）を受信するまでに送信することができるデータ量を指す。

ＡＣＫは、送信されたデータの受信を確認するように受信側ホストから送信側ホストに送信される通信コードである。さらに、ＡＣＫは、ＴＣＰデータセグメントが受信されるたびに受信側ホストから送信側ホストに送信されることも可能である。また、ＡＣＫは、順序の乱れたデータパケットが受信された場合に、受信側ホストから送信側ホストに選択的に送信されることも可能である。受信されたデータパケットは、選択的受信確認（以降、「ＳＡＣＫ」）ブロックと呼ばれる拡張ＴＣＰヘッダオプションの中で報告される。いずれにしても、ＴＣＰは、ＡＣＫまたはＳＡＣＫが、最初に送信されたデータセグメントに応答して生成されたのか、または再送信されたデータセグメントに応答して生成されたのかを区別することができない。

通常、タイムアウトが生じると、ＴＣＰスタックは、受信確認が行われていない全ウインドウ分のデータの再送信を既定で行う。しかし、前述したとおり、すべてのタイムアウトがデータ損失によって生じさせられるわけではない。したがって、自動的な再送信は、帯域幅が、既に正常に受信されているデータの再送信に不要に充てられる可能性がある。その結果、ネットワーク接続の完全性が低下する。

ＴＣＰデータセグメントのそのような自動的な再送信は、以前に送信されたデータが、受信済みであると確認されるか、または失われたと確認されるまで、データがネットワークに導入されてはならないことを明言する「パケット保存（ｃｏｎｓｅｒｖａｔｉｏｎ）原理」に違反する可能性がある。明らかに、スプリアスタイムアウト後のＴＣＰセグメントのあらゆる自動的な再送信は、パケット保存原理と相容れない。

無線ネットワークにおいて生じるスプリアスタイムアウトに応答するための技術を説明する。スプリアスタイムアウトが生じた場合、１つの説明される応答は、データ損失が確認されるまで、または確認されない限り、輻輳状態パラメータの下で送信側ホストからのデータフローを続けることである。詳細には、輻輳状態値が復元され、データ送信が、受信された受信確認に依存して徐々に増加することが可能なフローレート（ｆｌｏｗ−ｒａｔｅ）で続けられる。輻輳値を復元することには、タイムアウトに先立って検出された使用可能な帯域幅を復元すること、受信確認を受信するまでに送信されることが可能なデータの量の限度の既定値を復元することが含まれる。この既定値は、輻輳ウインドウとして知られる。送信データフローが続けられる際、輻輳ウインドウのあらゆる増加は、受信側ホストからの受信確認の受信に依存する。これは、受信確認により、データパケットが送信側ホストから受信側ホストに流れており、ネットワーク上で失われていないことが示されるからである。

添付の図を参照して詳細な説明を述べる。図では、符号の左端の数字が、その符号が最初に現れる図を明らかにする。異なる図における同一の符号の使用により、類似のアイテム、または同一のアイテムが示される。

以下の説明は、無線ネットワークにおいて起こるスプリアスタイムアウトに応答するための技術を対象とする。タイムアウトは、必ずしもデータ損失を示すものではないため、スプリアスタイムアウトの際のデータの自動的な再送信は、ネットワークリソースに関して潜在的に無駄の多い応答である。以下の実施例において実現される保守的な応答は、データ損失が確認されるまで、または確認されない限り、送信側ホストからの確実なデータフローを維持することにより、冗長なデータ送信を回避する。応答は、輻輳状態値を復元すること、および受信された受信確認に基づいて輻輳ウインドウのサイズを増加させることを含む。輻輳ウインドウ（「ｃｗｎｄ」とも呼ばれる）は、送信側ホストが、受信確認を受信するまでにネットワークを介して送信することができるデータの量を制限する状態変数である。

本明細書で説明する例示的な実施形態は、公開プロトコルおよび／または独自のプロトコルを含め、様々なネットワークプロトコルのいずれを利用することもできる。諸実施形態は、例証としてであって、いずれの形でも限定することを意図するものではない。

図１は、ネットワーク１０２が、クライアントデバイス１０５、１１０、１１５、および１２０、ならびにサーバデバイス１２５の間で通信を可能にする例示的なアーキテクチャ１００を示す。ネットワーク１０２は、有線ネットワークおよび／または無線ネットワークを含むことが可能な、様々な従来のネットワークトポロジおよびネットワークタイプのいずれかを表すことを意図している。ネットワーク１０２は、さらに、公開プロトコルおよび／または独自のプロトコルを含め、様々な従来のネットワークプロトコルのいずれを利用することもできる。ネットワーク１０２には、例えば、インターネット、および１つまたは複数のローカルエリアネットワーク（ＬＡＮ）の少なくとも一部が含まれることが可能である。

クライアントデバイス１０５には、デスクトップパーソナルコンピュータ（ＰＣ）、ワークステーション、メインフレームコンピュータ、インターネット機器、およびゲームコンソールを含め、様々な従来のコンピューティングデバイスのいずれが含まれることも可能である。さらに、ネットワーク１０２に関連するクライアントデバイスには、有線リンクおよび／または無線リンクでネットワーク１０２と通信することが可能な、パーソナルデジタルアシスタント（ＰＤＡ）１１０、ラップトップコンピュータ１１５、および携帯電話１２０などが含まれることが可能である。さらに、クライアントデバイス１０５、１１０、１１５、および１２０の１つまたは複数には、同一のタイプのデバイスが含まれること、または代替として、異なるタイプのデバイスが含まれることが可能である。

サーバデバイス１２５は、様々なデータおよび／または機能をコンピューティングデバイス１０５、１１０、１１５、および１２０に提供することができる。データは、公開されていること、または代替として制限されていること、例えば、一部のユーザだけに制限されていること、または適切な料金が支払われた場合にだけ利用可能であることが可能である。サーバデバイス１２５は、ネットワークサーバ、アプリケーションサーバ、およびＷｅｂブレード（ｂｌａｄｅ）の少なくとも１つであり、あるいは以上の任意の組み合わせであることが可能である。サーバデバイス１２５は、コンテンツのソースである任意のデバイスであり、クライアントデバイス１０５、１１０、１１５、および１２０には、そのようなコンテンツを受信する任意のデバイスが含まれる。クライアントデバイスまたはサーバデバイスの例示的な実施形態を、図７を参照して以下にさらに詳細に説明する。

クライアントデバイス１０５、１１０、１１５、１２０、およびサーバデバイス１２５のいずれのデバイスも、本明細書で説明する例示的な実施形態に従って送信側ホストまたは受信側ホストとして動作することができる。いずれの形でも限定することを意図しない説明の目的で、クライアントデバイス１１５が、ネットワーク１０２を介して受信側ホストにデータを送信する送信側ホストである。送信側ホスト１１５は、プロセッサ１１７を含み、プロセッサ１１７が、本明細書で説明する例示的な実施形態に対応するスプリアスタイムアウト応答１１９を実施する。

図１のネットワーク１０２に対応するプロトコルには、ＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）が含まれることが可能であるが、これには限定されず、ＴＣＰは、終端間のエラー検出およびエラー訂正を実施する接続ベース（ｃｏｎｎｅｃｔｉｏｎ−ｂａｓｅｄ）のストリーム指向配信サービス（ｓｔｒｅａｍ−ｏｒｉｅｎｔｅｄ ｄｅｌｉｖｅｒｙ ｓｅｒｖｉｃｅ）である。送信側ホスト１１５から受信側ホストにデータを送信する際、スプリアスタイムアウトが、無線ワイドエリアネットワークであることが可能なネットワーク１０２において生じることは稀ではない。送信トランザクションに対するそのようなタイムアウトのあらゆる効果を当業者は理解している。しかし、スプリアスタイムアウトの発生は、必ずしも失われたデータパケットまたは輻輳を示すものではない。

スプリアスタイムアウト応答１１９は、データの再送信を自動的には起こさない形でスプリアスタイムアウトを扱う。むしろ、スプリアスタイムアウト（ＳＴＯ）が検出された場合、スプリアスタイムアウト応答１１９は、輻輳状態値を復元し、送信側ホストからの確実なデータフローを維持することにより、ＳＴＯに応答する。つまり、送信側ホストからのデータフローは、データ損失が確認されるまで、または確認されない限り、データパケットの再送信を全く含まない。

より詳細には、スプリアスタイムアウト応答１１９は、タイムアウトが検出された時点より前の値にスロースタート（ｓｌｏｗ−ｓｔａｒｔ）閾値（「ｓｓｔｈｒｅｓｈ」とも呼ばれる）を復元し、輻輳ウインドウ「ｃｗｎｄ」を徐々に増加させるようにＴＣＰスタックに指示する。スロースタート閾値「ｓｓｔｈｒｅｓｈ」は、データ送信を制御するために利用される推定の利用可能な帯域幅に関する状態変数であり、輻輳ウインドウ「ｃｗｎｄ」は、繰り返すが、送信側ホストが、受信確認「ＡＣＫ」を受信するまでにネットワークを介して送信することができるデータの量を制限する状態変数である。タイムアウトが生じた後、輻輳ウインドウは、ＭＳＳに設定され、最初の受信確認されなかったパケットが再送信される。しかし、再送信が不要であることが判明した場合、すなわち、元の送信が受信側ホストによって正常に受信されている場合、送信側ホストは、その他のタイムアウトパケットの再送信を止める。さらに、輻輳ウインドウは、ＡＣＫが受信されると、最大セグメントサイズ（ＭＳＳ）だけ増加させられる（すなわち、ｃｗｎｄ＝ｃｗｎｄ＋ＭＳＳ）。というのは、ＡＣＫは、タイムアウトデータパケットの送信の成功を示すからである。つまり、ＡＣＫは、ネットワークパスを再検証するのに必要な正確なデータを提供するため、ＡＣＫを受信することにより、送信することができるデータの量を増加させることができることが示される。

図２は、送信側ホスト１１５のプロセッサ１１７をより詳細に示す。プロセッサ１１７は、例えば、ＴＣＰプロトコルを利用して、受信側ホストにデータパケットを送信するデータパケット送信機２０５を含む。再送信タイマ／タイムアウト検出器２１０が、送信機２０５からデータパケットが送信されてからの時間を追跡記録している。このため、再送信タイマ／タイムアウト検出器２１０は、データパケットが送信されてから所定の時間、例えば、５００ミリ秒が経過し、そのデータパケットに対応するＡＣＫが、送信側ホスト１１５において受信されないと、タイムアウトを検出する。タイムアウトがスプリアスタイムアウトであると判定された場合、タイムアウト応答プロセッサ２１５が、「再パケット化を伴うスプリアスタイムアウト検出」（以降、「ＳＴＯＤＥＲ」と呼ぶ）応答であるタイムアウト応答プロセス１１９（図１を参照）を実施する。図４〜６が、タイムアウト応答プロセス１１９をより詳細に表す。図２に示した処理モジュールは、図示するとおり、個別に、または様々な組み合わせで実装することができる。

図３は、スプリアスタイムアウトに応答するためのタイムアウト応答プロセス１１９を示す。プロセス１１９は、このプロセスを実行するように行われる少なくとも１つの動作をそれぞれが表すブロックの組として図示されている。動作は、ソフトウェア、ハードウェア、ファームウェア、またはそれらの任意の組み合わせによって実施されることが可能である。この場合も、説明の目的で、プロセス１１９は、タイムアウトが生じると、送信側ホスト１１５から受信側ホストにデータパケットを送信するという状況で説明する。

３０５で、送信側ホスト１１５が、タイムアウト条件を検出する。タイムアウトを検出すると、送信側ホスト１１５は、タイムアウト検出の時点までに送信側ホスト１１５から送信されたデータパケットに対応する最大のシーケンス番号を保存する３１０。保存されたシーケンス番号は、後続するデータパケット送信のための参照点の役割をすることが可能である。次に、最初の受信確認されなかったパケットが、再送信される。受信側ホストから最初の受信確認が受信されると、タイムアウトがスプリアスタイムアウト（ＳＴＯ）であるという判定３１５が、当技術分野で周知の技術に従って行われる。そのような技術の例には、それに限定するものではないが、２００４年１月１５日に米国特許庁に出願した同時係属出願第１０／７５８,５１０号で説明されている技術が含まれ、したがって、本明細書では説明しない。

図４〜６は、ＳＴＯが検出３１５されると実施される例示的なプロトコル応答１１９を示す。詳細には、本明細書で説明するＳＴＯＤＥＲ応答は、データパケットを自動的に再送信すること、または既定で輻輳制御状態処理を行うことによってＳＴＯに応答することはせず、代わりに、パケット保存原理に適合する応答を実施する。

図４は、ＳＴＯＤＥＲ応答における初期の諸動作を示す。ＳＴＯの検出３１５（図３を参照）は、必ずしもデータパケットの損失を前提としないため、送信側ホスト１１５からの確実なデータフローを維持するように輻輳状態値が復元される４０５。送信されるべき次のデータパケットに関するパラメータが、ＳＴＯ検出の時点までに送信されている、以前の送信済みデータパケットと実質的に等しくなるように設定される。この時点を「ＳＴＯＤＥＲ回復点」（以降、「ＳＲＰ」）と呼ぶことができる。スロースタート閾値「ｓｓｔｈｒｅｓｈ」が、タイムアウトが生じる前の値に実質的に等しくなるように復元され、輻輳ウインドウ「ｃｗｎｄ」が、最大セグメントサイズの２倍（すなわち、ｃｗｎｄ＝２^＊ＭＳＳ）に設定される。これは、２つのデータパケットのサイズを超えない輻輳ウインドウの初期値に関する周知のＴＣＰ原理に適合する。

データパケットが失われたという確認が存在しない場合、パケット保存原理の遵守により、以前に送信済みのデータが全く再送信されないことが要求される。つまり、この時点で、継続するデータフローは、新たに送信されるデータパケットだけを含むことになる。したがって、４１０で、送信側ホスト１１５は、最大で２つの新たなデータパケットを受信側ホストに送信することにより、データフローを維持する。データフローを維持するのにネットワークを介して送信される新たなデータパケットの数は、プロトコルが進化するにつれて変わる可能性があることに留意されたい。

４１５で、送信側ホスト１１５は、ネットワーク内で未処理であるバイト数の送信側の推定である「パイプ」値を設定する。この段階で、パイプ値は、以下のとおり、それまでに送信された最大シーケンス番号（すなわち、ｓｎｄ．ｍａｘ）と、まだ受信確認されていない最小シーケンス番号（すなわち、ｓｎｄ．ｕｎａ）の差に、最大セグメントサイズ（ＭＳＳ）を足した値に等しくなるように設定される。
パイプ＝ＭＳＳ＋ｓｎｄ．ｍａｘ−ｓｎｄ．ｕｎａ
ＭＳＳの加算は、タイムアウトした最初のデータパケットの再送信を計算に入れるために行われる。

４２０で、送信側ホスト１１５は、受信確認（ＡＣＫ）を受信する。後続の処理は、ＡＣＫが、確実なデータフローを進めるか、またはそれが重複（ｄｕｐｌｉｃａｔｅ）ＡＣＫであるかによって影響される。ＡＣＫは、送信されたデータパケットが受信側ホストにおいて正常に受信済みであることを示す場合、確実なデータフローを進める。重複ＡＣＫは、新たなデータを累積的に受信確認するのではなく、受信確認フィールド内でＳｎｄ．ｕｎａを繰り返すだけのＡＣＫである。

図５では、送信側ホスト１１５においてＡＣＫが受信された４２０（図４を参照）後のＳＴＯＤＥＲ応答の例示的な実施形態を続けている。受信されたＡＣＫにより、ＳＲＰに及ぶシーケンス番号が受信確認されるかどうかに関して判定５０５が行われる。ＡＣＫに対応するシーケンス番号が、ＳＲＰに及んでいる（ＡＣＫ Ｓｅｑ．Ｎｏ．＞ＳＲＰ）（すなわち、５０５から「Ｙｅｓ」の分岐）場合、ＳＴＯＤＥＲ応答は、終了する５０７。

そうでない場合、ＡＣＫにより、ＳＲＰ未満のデータが受信確認されているかどうか、すなわち、ＡＣＫにより、いくらかの新たな、ただし、ＳＲＰに及ばないデータが確認されているかどうかの判定５１０が行われる。そのようなＡＣＫは、いくつかのデータパケットが、ネットワークを離れたことを示す。したがって、この条件の肯定的な判定（すなわち、５１０から「Ｙｅｓ」の分岐）後、未処理のパケットが減少したことを反映するようにパイプ値が調整される（すなわち、ブロック５１２）。さらに、ＡＣＫは、いくらかのデータが受信側ホストにおいて正常に受信されたことを示すので、ＡＣＫが受信された時点で、輻輳ウインドウ「ｃｗｎｄ」がスロースタート閾値「ｓｓｔｈｒｅｓｈ」未満である（すなわち、ｃｗｎｄ＜ｓｓｔｈｒｅｓｈ）である場合、輻輳ウインドウ「ｃｗｎｄ」は、最大セグメントサイズ「ＭＳＳ」を輻輳ウインドウ「ｃｗｎｄ」に加算する（すなわち、ｃｗｎｄ＝ｃｗｎｄ＋ＭＳＳ）により、広げられることが可能である。その後、安定した（ｃｏｎｓｉｓｔｅｎｔ）データフローを維持するため、パイプ値が輻輳ウインドウ「ｃｗｎｄ」未満（すなわち、ｐｉｐｅ＜ｃｗｎｄ）である場合、新たなデータパケット、すなわち、まだ送信されていないデータを、送信することが可能である。

そうでない場合、ＡＣＫが「重複ＡＣＫ」であるかどうか、つまり、ＡＣＫが、同一のシーケンス番号を有するか、または受信確認されていないデータの最小の番号未満、すなわち、ｓｎｄ．ｕｎａ未満を有するかの判定５２０が行われる。重複ＡＣＫの判定（すなわち、５２０から「Ｙｅｓ」の分岐）後、ネットワーク内における未処理のデータの量の推定が、パイプ値を最大セグメントサイズ「ＭＳＳ」未満の元のパイプ値に再設定する５２２（すなわち、ｐｉｐｅ＝ｐｉｐｅ−ＭＳＳ）ことにより、調整される。

さらに、重複ＡＣＫが、ＳＲＰのデータセグメント未満のデータセグメントを選択的に受信確認するＳＡＣＫブロックを含み、輻輳ウインドウ「ｃｗｎｄ」が、スロースタート閾値「ｓｓｔｈｒｅｓｈ」未満（すなわち、ｃｗｎｄ＜ｓｓｔｈｒｅｓｈ）である場合、輻輳ウインドウ「ｃｗｎｄ」は、最大セグメントサイズ「ＭＳＳ」を輻輳ウインドウ「ｃｗｎｄ」の現在の値に加算すること（すなわち、ｃｗｎｄ＝ｃｗｎｄ＋ＭＳＳ）により、再設定される。その後、安定したデータフローを維持するため、パイプ値が輻輳ウインドウ「ｃｗｎｄ」未満である（すなわち、ｐｉｐｅ＜ｃｗｎｄ）である場合、新たなデータパケットが送信される。

そうではなく、３つの重複ＡＣＫが受信されているという判定５３０が行われた場合、データパケットはネットワークから失われている（すなわち、５３０から「Ｙｅｓ」の分岐）ものと、推定に基づいて（ｐｒｅｓｕｍｐｔｉｖｅｌｙ）考えられる。したがって、第３の重複ＡＣＫが受信されると、ＡＣＫが受信されていない、失われたデータパケットが、送信側ホスト１１５から再送信５２５されることが可能である。さらに、損失が検出されているので、スロースタート閾「ｓｓｔｈｒｅｓｈ」状態値および輻輳ウインドウ「ｃｗｎｄ」状態値が再設定５２７される。具体的には、スロースタート閾値は、元の値の１／２に低減され（すなわち、ｓｓｔｈｒｅｓｈ＝ｓｓｔｈｒｅｓｈ／２）、輻輳ウインドウは、第３の重複ＡＣＫが受信された時点における輻輳ウインドウとスロースタート閾値の小さい方に設定される（すなわち、ｃｗｎｄ＝ｍｉｎ（ｃｗｎｄ，ｓｓｔｈｒｅｓｈ））。３つの重複ＡＣＫに関して否定的な判定５３０の場合、処理は、５０５に戻る。

失われたデータの再送信に加えて、ＳＴＯに対する応答は、ＳＡＣＫベースのスロースタート回復処理に移る。

図６は、ＳＡＣＫベースのスロースタート回復処理を示す。スロースタート閾状態値および輻輳ウインドウ状態値が再設定５２７された（図５を参照）後の送信側ホスト１１５におけるＡＣＫの受信が、受信されたＡＣＫにより、ＳＲＰに及ぶシーケンス番号が受信確認されるかどうか、すなわち、ＡＣＫが未だに受信確認されていない何らかの未処理のデータに対応するかどうかの判定６０５を生じさせる。このため、ＡＣＫに対応するシーケンス番号がＳＲＰに及んでいる（すなわち、６０５から「Ｙｅｓ」の分岐）場合、ＳＴＯＤＥＲ応答は、終了する６０７。

そうでない場合、ＡＣＫにより、ＳＲＰで示されるデータに満たないデータが受信確認されているかどうか、すなわち、ＡＣＫが「部分的ＡＣＫ」であるかどうかの判定６１０が行われる。ＳＡＣＫベースのスロースタート回復段階における第１の部分的ＡＣＫの判定６１５（すなわち、６１０から「Ｙｅｓ」の分岐）により、ＳＲＰ未満のすべてのデータパケットが失われたという推定に基づく結論がもたらされる。したがって、以下のとおり、再送信されるべきデータのサイズ（ｒｅｔｒａｎ＿ｄａｔａ）に、部分的ＡＣＫが判定された時点までに送信されたデータからＳＲＰを引いた値（ｓｎｄ．ｍａｘ−ＳＲＰ）を足し、ＳＲＰを超える選択的に受信確認されたデータパケット（ＳＲＰを超えるｓａｃｋｅｄ＿ｐｋｔｓ）を引いた値に設定することにより、再送信バーストが回避６２０される。
ｐｉｐｅ＝ｒｅｔｒａｎ＿ｄａｔａ＋（ｓｎｄ．ｍａｘ−ＳＲＰ）−（ＳＲＰを超えるｓａｃｋｅｄ＿ｐｋｔｓ）
さらに、輻輳ウインドウ「ｃｗｎｄ」が、ウインドウと、パイプ値に２^＊ＭＳＳという初期ウインドウ値を足した値の間で小さい方の値になるように調整される。すなわち、
ｃｗｎｄ＝ｍｉｎ（ｃｗｎｄ，ｐｉｐｅ＋（２^＊ＭＳＳ））
次に、データが、失われたものと考えられるＳＲＰ未満のデータパケットの形態で送信６２５される。

部分的ＡＣＫのその後の受信により、パイプ値が、元のパイプ値から受信確認されたデータのサイズを引いた値に再設定されること（すなわち、ｐｉｐｅ＝ｐｉｐｅ−ｄａｔａ＿ａｃｋｅｄ）、および輻輳ウインドウ「ｃｗｎｄ」が、「ｓｓｔｈｒｅｓｈ」未満である場合、輻輳ウインドウ「ｃｗｎｄ」に最大セグメントサイズ「ＭＳＳ」を足した値に再設定されること（すなわち、ｃｗｎｄ＝ｃｗｎｄ＋ＭＳＳ）を含め、状態値が再設定６３０されることがもたらされる。安定したデータフローを維持するため、パイプ値が輻輳ウインドウ未満であるものと想定すると（すなわち、ｐｉｐｅ＜ｃｗｎｄ）、例えば、部分的に受信確認される最も古いデータが、送信側ホスト１１５から再送信６２５される。

部分的なＡＣＫの否定的な判定６１０により、ＡＣＫが重複ＡＣＫであることが示唆される。したがって、パイプ値は、パイプ値からＭＳＳを引いた値に設定６３５される（すなわち、ｐｉｐｅ＝ｐｉｐｅ−ＭＳＳ）。第１の部分的ＡＣＫより前に重複ＡＣＫが受信され、そのＡＣＫが、ＳＲＰ未満のデータを選択的に受信確認するＳＡＣＫブロックを含み、輻輳ウインドウがスロースタート閾値未満である（すなわち、ｃｗｎｄ＜ｓｓｔｈｒｅｓｈ）である場合、輻輳ウインドウは、最大セグメントサイズ「ＭＳＳ」だけ増加される（すなわち、ｃｗｎｄ＝ｃｗｎｄ＋ＭＳＳ）。安定したデータフローを維持するため、パイプ値が輻輳ウインドウ未満であるものと想定すると、失われたデータ、または新たなデータが、送信側ホスト１１５から（再）送信６２５される。

第２の再送信タイムアウトが生じた場合、前述した応答処理は終了し、周知のスロースタート処理が開始することに留意されたい。

図７は、本明細書で説明する技術を実施するのに使用することができる汎用コンピュータ環境７００を示す。コンピュータ環境７００は、コンピューティング環境の一実施例に過ぎず、コンピュータ環境およびネットワーク環境の利用法または機能の範囲について何ら限定を示唆するものではない。また、コンピューティング環境７００が、例示的なコンピュータ環境７００に示したコンポーネントのいずれかの１つ、または組み合わせに関していかなる依存関係も要件も有するものと解釈してはならない。

コンピュータ環境７００は、コンピュータ７０２の形態で汎用コンピューティングデバイスを含む。コンピュータ７０２のコンポーネントには、１つまたは複数のプロセッサまたは処理装置７０４、システムメモリ７０６、ならびにプロセッサ７０４からシステムメモリ７０６までを含む様々なシステムコンポーネントを繋ぐシステムバス７０８が含まれることが可能であるが、これには限定されない。

システムバス７０８は、様々なバスアーキテクチャのいずれかを使用するメモリバスまたはメモリコントローラ、周辺バス、アクセラレーテッドグラフィックスポート（ａｃｃｅｌｅｒａｔｅｄ ｇｒａｐｈｉｃｓ ｐｏｒｔ）、およびプロセッサバスまたはローカルバスを含め、いくつかのタイプのバス構造のいずれかの１つまたは複数を表す。例としては、そのようなアーキテクチャとして、インダストリスタンダードアーキテクチャ（Ｉｎｄｕｓｔｒｙ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）（ＩＳＡ）バス、マイクロチャネルアーキテクチャ（Ｍｉｃｒｏ Ｃｈａｎｎｅｌ Ａｒｃｈｉｔｅｃｔｕｒｅ）（ＭＣＡ）バス、エンハンストＩＳＡ（Ｅｎｈａｎｃｅｄ ＩＳＡ）（ＥＩＳＡ）バス、ビデオエレクトロニクススタンダーズアソシエーション（Ｖｉｄｅｏ Ｅｌｅｃｔｒｏｎｉｃｓ Ｓｔａｎｄａｒｄｓ Ａｓｓｏｃｉａｔｉｏｎ）（ＶＥＳＡ）ローカルバス、メザニン（Ｍｅｚｚａｎｉｎｅ）バスとしても知られるペリフェラルコンポーネントインターコネクツ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔｓ）（ＰＣＩ）バス、ＰＣＩエクスプレス（Ｅｘｐｒｅｓｓ）バス、ユニバーサルシリアルバス（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）（ＵＳＢ）、セキュアデジタル（Ｓｅｃｕｒｅ Ｄｉｇｉｔａｌ）（ＳＤ）バス、またはＩＥＥＥ１３９４バス、すなわち、ＦｉｒｅＷｉｒｅバスを挙げることができる。

コンピュータ７０２は、様々なコンピュータ可読媒体を含むことが可能である。そのような媒体は、コンピュータ７０２がアクセスすることができる任意の利用可能な媒体であることが可能であり、揮発性媒体と不揮発性媒体、リムーバブルな媒体と非リムーバブルの媒体がともに含まれる。

システムメモリ７０６は、ランダムアクセスメモリ（ＲＡＭ）７１０のような揮発性メモリの形態、および／または読み出し専用メモリ（ＲＯＭ）７１２またはフラッシュＲＡＭのような不揮発性メモリの形態でコンピュータ可読媒体を含む。起動中などに、コンピュータ７０２内部の要素間で情報を転送するのを助ける基本ルーチンを含む基本入出力システム（ＢＩＯＳ）７１４が、ＲＯＭ７１２またはフラッシュＲＡＭの中に格納される。ＲＡＭ７１０は、通常、処理装置７０４が即時にアクセスすることができ、かつ／または現在、操作されているデータおよび／またはプログラムモジュールを含む。

コンピュータ７０２は、他のリムーバブルな／非リムーバブルの、揮発性／不揮発性のコンピュータ記憶媒体も含むことが可能である。例として、図７は、非リムーバブルの不揮発性の磁気媒体（図示せず）に対して読み取りおよび書き込みを行うためのハードディスクドライブ７１６、リムーバブルな不揮発性の磁気ディスク７２０（例えば、「フロッピー（登録商標）ディスク」）に対して読み取りおよび書き込みを行うための磁気ディスクドライブ７１８、およびＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、または他の光媒体などのリムーバブルな不揮発性の光ディスク７２４に対して読み取りおよび／または書き込みを行うための光ディスクドライブ７２２を示す。ハードディスクドライブ７１６、磁気ディスクドライブ７１８、および光ディスクドライブ７２２はそれぞれ、１つまたは複数のデータ媒体インタフェース７２５でシステムバス７０８に接続される。代替として、ハードディスクドライブ７１６、磁気ディスクドライブ７１８、および光ディスクドライブ７２２は、１つまたは複数のインタフェース（図示せず）でシステムバス７０８に接続することもできる。

以上のディスクドライブ、およびそれらに関連するコンピュータ可読媒体により、コンピュータ可読命令、データ構造、プログラムモジュール、およびその他のデータの不揮発性の記憶がコンピュータ７０２に提供される。実施例は、ハードディスク７１６、リムーバブルな磁気ディスク７２０、およびリムーバブルな光ディスク７２４を示しているが、磁気カセットまたは他の磁気記憶装置、フラッシュメモリカード、ＣＤ−ＲＯＭ、デジタルバーサタイルディスク（ＤＶＤ）または他の光ストレージ、ランダムアクセスメモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、電気的に消去可能なプログラマブル読み出し専用メモリ（ＥＥＰＲＯＭ）などの、コンピュータがアクセスすることができるデータを格納することができる他のタイプのコンピュータ可読媒体も、例示的なコンピューティングシステムおよびコンピューティング環境を実施するのに利用できることが理解されよう。

例として、オペレーティングシステム７２６、１つまたは複数のアプリケーションプログラム７２８、その他のプログラムモジュール７３０、およびプログラムデータ７３２を含め、任意の数のプログラムモジュールが、ハードディスク７１６、磁気ディスク７２０、光ディスク７２４、ＲＯＭ７１２、および／またはＲＡＭ７１０に格納されることが可能である。そのようなオペレーティングシステム７２６、１つまたは複数のアプリケーションプログラム７２８、他のプログラムモジュール７３０、およびプログラムデータ７３２（またはそれらの何らかの組み合わせ）により、分散ファイルシステムをサポートする常駐コンポーネントのすべて、または一部が実装されることが可能である。

ユーザは、キーボード７３４やポインティングデバイス７３６（例えば、「マウス」）などの入力デバイスを介して、コマンドおよび情報をコンピュータ７０２に入力することができる。その他の入力デバイス７３８（特に図示せず）には、マイク、ジョイスティック、ゲームパッド、サテライトディッシュ、シリアルポート、スキャナ、および／または以上に類するデバイスが含まれることが可能である。以上の入力デバイス、およびその他の入力デバイスは、システムバス７０８に繋がれた入出力インタフェース７４０を介して処理装置７０４に接続されるが、パラレルポート、ゲームポート、またはユニバーサルシリアルバス（ＵＳＢ）などの他のインタフェースまたはバス構造で接続してもよい。

モニタ７４２、またはその他のタイプのディスプレイデバイスも、ビデオアダプタ７４４などのインタフェースを介してシステムバス７０８に接続されることが可能である。モニタ７４２に加え、他の出力周辺デバイスには、入出力インタフェース７４０を介してコンピュータ７０２に接続することができるスピーカ（図示せず）やプリンタ７４６などのコンポーネントが含まれることが可能である。

コンピュータ７０２は、リモートコンピューティングデバイス７４８などの１つまたは複数のリモートコンピュータに対する論理接続を使用するネットワーク化された環境において動作することができる。一例として、リモートコンピューティングデバイス７４８は、ＰＣ、ポータブルコンピュータ、サーバ、ルータ、ネットワークコンピュータ、ピアデバイス、または他の一般的なネットワークノードなどであることが可能である。リモートコンピューティングデバイス７４８は、コンピュータ７０２に関連して本明細書で説明した要素および特徴の多く、またはすべてを含むことが可能なポータブルコンピュータとして例示している。また、コンピュータ７０２は、ネットワーク化されていない環境において動作することも可能である。

コンピュータ７０２とリモートコンピュータ７４８の間の論理接続をローカルエリアネットワーク（ＬＡＮ）７５０および汎用ワイドエリアネットワーク（ＷＡＮ）７５２として示す。そのようなネットワーキング環境は、オフィス、企業全体のコンピュータネットワーク、イントラネット、およびインターネットで一般的である。

ＬＡＮネットワーキング環境で実施される場合、コンピュータ７０２は、ネットワークインタフェースまたはネットワークアダプタ７５４を介してローカルネットワーク７５０に接続される。ＷＡＮネットワーキング環境で実施される場合、コンピュータ７０２は、通常、ワイドネットワーク７５２を介して通信を確立するためのモデム７５６、または他の手段を含む。コンピュータ７０２の内部にあることも、外部にあることも可能なモデム７５６は、入出力インタフェース７４０、または他の適切な機構を介してシステムバス７０８に接続されることが可能である。例示したネットワーク接続は、実施例に過ぎず、コンピュータ７０２とコンピュータ７４８の間で少なくとも１つの通信リンクを確立するための他の手段も使用することができる。

コンピューティング環境７００で例示したようなネットワーク化された環境では、コンピュータ７０２に関連して示したプログラムモジュール、またはその諸部分は、リモートメモリ記憶装置の中に格納されることが可能である。例として、リモートアプリケーションプログラム７５８は、リモートコンピュータ７４８のメモリデバイス上に存在する。例示のため、アプリケーションまたはプログラム、ならびにオペレーティングシステムなどの他の実行可能プログラムコンポーネントは、本明細書で別々のブロックとして示しているが、そのようなプログラムおよびコンポーネントは、様々な時点で、コンピューティングデバイス７０２の異なるストレージコンポーネントの中に存在し、コンピュータの少なくとも１つのデータプロセッサによって実行されることが理解されよう。

様々なモジュールおよび技術は、本明細書で、１つまたは複数のコンピュータまたは他のデバイスによって実行される、プログラムモジュールなどの、コンピュータ実行可能命令の一般的なコンテキストで説明することができる。プログラムモジュールには、一般に、特定のタスクを実行する、または特定の抽象データ型を実装するためのルーチン、プログラム、オブジェクト、コンポーネント、データ構造などが含まれる。通常、プログラムモジュールの機能は、様々な実施形態において所望に応じて組み合わせることも、分散させることもできる。

以上のモジュールおよび技術の実装は、何らかの形態のコンピュータ可読媒体上に格納すること、または何らかの形態のコンピュータ可読媒体を介して伝送することができる。コンピュータ可読媒体は、コンピュータがアクセスすることができる任意の利用可能な媒体であることが可能である。例として、限定としてではなく、コンピュータ可読媒体は、「コンピュータ記憶媒体」および「通信媒体」を含むことが可能である。

「コンピュータ記憶媒体」には、コンピュータ可読命令、データ構造、プログラムモジュール、またはその他のデータなどの情報を格納するために任意の方法または技術で実装された揮発性媒体および不揮発性媒体、リムーバブルな媒体および非リムーバブルの媒体が含まれる。コンピュータ記憶媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、デジタルバーサタイルディスク（ＤＶＤ）または他の光ストレージ、磁気カセット、磁気テープ、磁気ディスクストレージまたは他の磁気記憶装置、あるいは所望の情報を格納するのに使用することができ、コンピュータがアクセスすることができる他の任意の媒体が含まれるが、以上には限定されない。

「通信媒体」は、通常、搬送波や他のトランスポート機構などの変調されたデータ信号中にコンピュータ可読命令、データ構造、プログラムモジュール、またはその他のデータを具現化する。通信媒体には、あらゆる情報伝達媒体も含まれる。「変調されたデータ信号」という用語は、信号内に情報を符号化するような形で特性の１つまたは複数が設定または変更されている信号を意味する。限定的ではない単なる例として、通信媒体には、有線ネットワークまたは直接有線接続などの有線媒体、ならびに音響媒体、ＲＦ媒体、赤外線媒体、およびその他の無線媒体などの無線媒体が含まれる。また、以上の媒体のいずれかの組み合わせも、コンピュータ可読媒体の範囲内に含まれる。

本明細書全体で、「一実施形態」、「実施形態」、または「例示的な実施形態」について述べており、これは、説明する特定の特徴、構造、または特性が本発明の少なくとも１つの実施形態に含まれることを意味する。このため、そのような言い回しの使用は、１つだけにとどまらない実施形態を指すことが可能である。さらに、説明する特徴、構造、または特性は、１つまたは複数の実施形態において任意の適切な形で組み合わせることができる。

ただし、本発明は、特定の詳細の１つまたは複数を伴わずに、または他の方法、リソース、資材などを使用して実施することも可能なことを、当業者は理解できよう。その他、周知の構造、リソース、または動作は、単に本発明の諸態様を不明瞭にするのを避けるため、詳細に図示したり説明することはしていない。

本発明の例示的な実施形態および応用例を図示し、説明してきたが、本発明は、以上に説明した構成およびリソースそのものには限定されないことを理解されたい。請求する本発明の範囲を逸脱することなく、本明細書で開示する本発明の方法およびシステムの構成、動作、および詳細において、当業者に明らかな様々な改変、変更、および変形を行うことができる。

無線ネットワークを介して通信する、スプリアスタイムアウトに応答するための技術を実施するデバイスを示す図である。 本明細書で説明する例示的な実施形態を実施するための通信環境を示す図である。 スプリアスタイムアウトに応答するためのプロセスを示す流れ図である。 図３に示したスプリアスタイムアウトに応答するためのプロセスの態様の実施例を示す図である。 図３に示したスプリアスタイムアウトに応答するためのプロセスの態様の実施例を示す図である。 図３に示したスプリアスタイムアウトに応答するためのプロセスの態様の実施例を示す図である。 本明細書で説明する技術を実施するのに使用することができる汎用コンピュータネットワーク環境を示す図である。

符号の説明

１０２ ネットワーク
１１７ プロセッサ
１１９ タイムアウト応答プロセス
２０５ データパケット送信機
２１０ 送信タイマ／タイムアウト検出器
２１５ タイムアウト応答プロセッサ

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