JP2009526494A - トランスポートプロトコルの性能を改善するシステムおよび方法 - Google Patents

Abstract

トランスポートプロトコルの性能を改善するシステムおよび方法を開示する。１つの例示的な方法は、第１の状態において、輻輳ウィンドウを非線形に増大させるステップと、第１の状態の間に、輻輳ウィンドウが閾値を上回ったことを受けて、第２の状態へ遷移するステップと、第２の状態において、輻輳ウィンドウを線形に増大させるステップとを含む。別の例示的な方法は、多数のパケットの損失を示す重複確認応答の受信時に、第３の状態へ遷移するステップと、該第３の状態において、該パケット損失の数に比例して輻輳ウィンドウを減少させるステップとをさらに含む。

Description

（関連出願の参照）
本出願は、米国仮特許出願第６０／７６５，７８７号（２００６年２月７日出願）の利益を主張し、これにより参照により本明細書に援用される。

本開示は、通信プロトコルに関し、より具体的には、トランスポート層プロトコルに関する。

伝送制御プロトコル（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ；ＴＣＰ）として知られているトランスポートプロトコルは、過去２０年間にわたって、インターネット上における信頼できるデータ配信のための事実上のトランスポートプロトコルとして好成果を上げてきた。ＴＣＰが使用するアルゴリズムは、インターネット上における安定性、信頼性、および公平性を推進するように設計されたものであったが、これらの同じアルゴリズムが、通信システム間のエンドツーエンドパスに沿った一定の条件の存在下で、ＴＣＰ性能の低下をもたらした。広帯域、大きな遅延、および／または著しい損失率を含むこれらの特性は、現在のインターネットにおいてますます一般的なものとなりつつある。ＴＣＰが使用する基本アルゴリズムは長年にわたって修正されてきたが、ＴＣＰを使用するシステムにはそのように大きい設置基盤があることから、これらのアルゴリズムに対する著しい変化は起こりそうにない。したがって、これらの、およびその他の課題に取り組む必要性が存在する。

トランスポートプロトコルの性能を改善するシステムおよび方法を開示する。１つの例示的な方法は、第１の状態において、輻輳ウィンドウを非線形に増大させるステップと、第１の状態の間に、輻輳ウィンドウが閾値を上回ったことを受けて、第２の状態へ遷移するステップと、第２の状態において、輻輳ウィンドウを線形に増大させるステップと、を含む。

以下の図面を参照して、本開示の多くの態様をよりよく理解することができる。図面中の構成要素は必ずしも縮尺通りでなく、本開示の原理を明瞭に示すことに重点を置いたものである。

図１は、トランスポートプロトコルの性能を改善するためのシステムおよび方法の一実施形態が位置する環境のブロック図である。エンドポイントデバイス１１０は、トランスポート層（第４層）プロトコル１２０を使用し、ネットワーク１３０上で互いに通信を行う。本開示では、例示的なトランスポート層プロトコルとしてＴＣＰについて考察するが、当業者であれば、本願において開示するトランスポートプロトコルの性能を改善するための原理が、その他のトランスポート層プロトコルにも当てはまることを認識するはずである。ルータ１４０は、ネットワーク１３０を越えてトラフィックを輸送し、これには、インターネットプロトコル（ＩＰ）等のネットワーク層（第３層）プロトコルの使用を伴う場合がある。本願においては「ルータ」という用語を使用するが、当業者であれば、ルータ１４０は代わりに第３層スイッチの形態をとり得ることを認識するはずである。

ネットワークデバイス１５０は、（論理的に）エンドポイント１１０とルータ１４０との間に位置する。各ネットワークデバイス１５０は、トランスポートプロトコルの性能を改善するための論理１６０を含み、これにより、ネットワークデバイス１５０が拡張トランスポートプロトコル１６５を使用してピアネットワークデバイス１５０と通信を行うことを可能にする。したがって、一対のエンドポイント１１０は、一対のネットワークデバイス１５０を介して互いに通信を行う。図１では、ネットワークデバイス１５０はエンドポイント１１０とルータ１４０との間に表示されるが、これは物理的表現ではなく論理的表現であり、パケットがネットワークデバイス１５０を通過することを示しているに過ぎない。以下で説明するように、ネットワークデバイス１５０のいくつかの実施形態は、実際にはエンドポイント１１０とルータ１４０との間にインラインに載置されておらず、代わりに、ルータ１４０にぶら下がるオフラインデバイスとして動作する。

ネットワークデバイス１５０のいくつかの実施形態は、エンドポイントネットワークインタフェース１７０とピアネットワークインタフェース１７５とを含み、エンドポイントネットワークインタフェース１７０はリンク１８０を介してエンドポイント１１０と連結され、ピアネットワークインタフェース１７５はリンク１８５を介してルータ１４０と連結される。ネットワークデバイス１５０のその他の実施形態は、ルータ１４０と連結された単一ネットワークインタフェースを含む。（単一インタフェースの実施形態は、以下で説明するように、インラインよりも「オフライン」で使用され得る。）
いくつかの実施形態において、ネットワーク１３０内のリンクは、エンドポイント１１０へのリンクとは異なる性能特性を呈する。例えば、エンドポイント１１０へのリンクは、比較的高速の有線接続（例えば、１００メガビットイーサネット（登録商標））を提供することができ、一方、ネットワーク１３０内のリンクは、低速の有線または無線接続（例えば、Ｔ１、ＷｉＦｉ）を提供することができる。拡張トランスポートプロトコル１６５は、ネットワークデバイス１５０間のリンクの性能特性に合わせて設計されている。

ネットワークデバイス１５０のいくつかの実施形態において、拡張トランスポートプロトコル１６５は、エンドポイント１１０によって使用されるトランスポートプロトコル１２０とは異なっており、ここで、エンドポイント１１０とその対応するネットワークデバイス１５０との間で使用されるプロトコルが元のトランスポートプロトコル１２０であり、ピアネットワークデバイス１５０間で使用されるプロトコルが拡張トランスポートプロトコル１６５である。そのような実施形態において、ネットワークデバイス１５０は、エンドポイント１１０用のトランスポートプロキシとして作用する。いくつかのプロキシ実施形態において、エンドポイント１１０は、当該エンドポイント１１０が異なるトランスポートプロトコルを使用していることに気付かず、この場合、ネットワークデバイス１５０は、エンドポイント１１０に対して透過なトランスポートプロキシである。以下でさらに詳細に説明するように、ネットワークデバイス１５０は、エンドポイントが、プロキシを実際の受信機としてではなく他の通信するエンドポイントとして気付くだけであるような手法で、ＴＣＰエンドポイントによって送信されたパケットに応答することにより、透過性を保持する。

以後、拡張トランスポートプロトコル１６５によって使用されるパケットに言及する場合、「拡張トランスポートパケット」という用語を使用する。当業者であれば、そのようなプロトコルは、一般に、データを搬送するパケット（データパケット）と、データに確認応答するパケット（確認応答パケット）と、接続の初期化／終了処理を行うために使用される制御パケットとを含むことを認識するはずである。したがって、本願においては、「拡張トランスポートデータパケット」と、「拡張トランスポート確認応答パケット」と、「拡張トランスポート制御パケット」とに言及する。これらのパケットは、元のトランスポートプロトコルに対応するものであるが、それとは異なる。例えば、ＴＣＰデータパケットおよび拡張トランスポートデータパケットはいずれもデータを搬送するが、ＴＣＰデータパケットはＴＣＰエンドポイント１１０に由来する、またはそこへ配信されるものであり、一方、拡張トランスポートデータパケットは、トランスポートプロキシピア１５０間で伝達される。いくつかの実施形態において、拡張トランスポートパケットは、元のトランスポートプロトコルパケットにトレーラフィールドを追加することによって形成される。例えば、ＴＣＰデータパケットは、「拡張トランスポートデータ」の「プロトコルタイプ」フィールドを付加することによって拡張トランスポートデータパケットに変換され、一方、ＴＣＰ制御パケットは、「拡張トランスポート制御パケット」の「プロトコルタイプ」フィールドを付加することによって拡張トランスポート制御パケットに変換される。これは、カプセル化の形態であるとみなされ得るが、エンドポイントに対して透過的であるという利点を有する。いくつかの場合において、拡張トランスポートパケットは、カプセル化せずに単独で伝達される。これらの場合において、ＩＰヘッダ中のＰｒｏｔｏｃｏｌ Ｔｙｐｅフィールドは、拡張トランスポートプロトコルの存在を示す特殊な値に設定され得る。すなわち、拡張トランスポートプロトコル１６５は、ＩＰまたはネットワーク層によって、ＴＣＰまたはＵＤＰのようなプロトコルタイプとして見られる。

当業者であれば、トランスポートプロトコルの性能を改善するための論理１６０がいくつかの異なる手法で具体化され得ることを十分に理解するはずである。一例として、ＴＣＰ通信端末デバイスとアクセスルータ１４０との間に座置するスタンドアロン１５０デバイス内に論理１６０を実装する。論理１６０のもう１つの具体化は、例えば、カーネルプロトコルスタックのＴＣＰ層とＩＰ層との間に座置するカーネルドライバとして、エンドポイント１１０内で行われる。さらに別の例として、トランスポートプロトコルの性能を改善するための論理１６０は、エンドポイント１１０のプロトコルスタック内のトランスポート層としてＴＣＰと置き換わることができる。本願においてはスタンドアロンネットワークデバイス１５０についてのみ考察するが、そのようなすべての具体化が本開示の範囲内にあることを意図するものである。

図２は、トランスポートプロトコルの性能を改善するためのシステムおよび方法の別の実施形態が位置する環境のブロック図である。この環境において、一対のエンドポイント１１０は、ピア間に複数の接続２１０、２２０、２３０を含み得る。これらの接続（２１０〜２３０）のそれぞれは、改善されたネットワークデバイス１５０Ａおよび１５０Ｂを通過する。本実施形態において、ネットワークデバイス１５０は、接続毎に、ネットワークデバイス１５０間の接続の区間に拡張トランスポートプロトコル１６５を使用するか元のトランスポートプロトコル１２０を使用するかを決定する。図２の例において、接続２１０および２２０は中央区間に拡張トランスポートプロトコル１６５を使用し、接続２３０は元のトランスポートプロトコル１２０を使用する。

いくつかの実施形態において、ユーザ（例えば、システム管理者）は、どの接続がどのトランスポートプロトコルを使用するかを決定し、それにしたがってネットワークデバイス１５０を構成する。いくつかの構成例として、特定のエンドポイント１１０からのすべての接続が拡張トランスポートプロトコル１６５を使用する、特定のエンドポイント１１０からの接続がいずれも拡張トランスポートプロトコル１６５を使用しない、ヘッダフィールドの特定の組み合わせによって識別された特定のエンドポイント１１０からのそれらの接続が拡張トランスポートプロトコル１６５を使用する、ヘッダフィールドの特定の組み合わせによって識別されない特定のエンドポイント１１０からのそれらの接続が、拡張トランスポートプロトコル１６５を使用しない、というものが挙げられる。当業者であれば、これらは例に過ぎず、どの接続が拡張トランスポートプロトコル１６５を使用するかを判断するためのその他の技術も可能であることを認識するはずである。

図３は、図１のトランスポートプロトコルの性能を改善するための論理１６０のブロック図である。接続マネージャ３１０は、ネットワーク内のその他のネットワークデバイス１５０への接続をセットアップし、その他のネットワークデバイス１５０に関する一般的な状態情報を保持する。接続マネージャ３１０は、構成データベース（ローカルまたは集中型）によって、または動的学習プロセスによって、または、当業者に既知であるその他任意の適切な機構によって、その他のネットワークデバイス１５０の存在およびアドレスを発見することができる。

ピアデバイス１５０が発見されると、接続マネージャ３１０は、ピアデバイス１５０の障害を監視する。障害が発見された場合、接続マネージャ３１０は、当該障害について、トランスポートプロトコルの性能を改善するための論理１６０内のその他の構成要素に通知する。各構成要素は、ピアの障害を受けて適切なアクションをとる。いくつかの実施形態において、ピアの障害の認識は、ピアネットワークデバイス１５０間のハートビート信号によって実現される。接続マネージャ構成要素３１０は、そのデバイス１５０のハートビートを送信し、その他のピアデバイス１５０のハートビートの監視も行う。ここで、ハートビート信号の不在は、ピアデバイス１５０の障害を意味する。

構成および監視マネージャ３２０は、ネットワークデバイス１５０の動作を調節することを可能にする。構成および監視マネージャ３２０は、両方のネットワークデバイス１５０の性能特性も監視する。いくつかの実施形態において、構成および監視マネージャ３２０は、デバイス１５０中を流れるエンドポイントトラフィックの性能特性の監視も行う。

トラフィック分類子３３０は、ネットワークデバイス１５０に入るネットワークトラフィックを分類する。分類は、着信パケット上のヘッダによって形成されるＮタプル（Ｎ−ｔｕｐｌｅ）に基づく。いくつかの実施形態において、Ｎタプルは、送信元ＩＰアドレス、宛先ＩＰアドレス、送信元ＴＣＰポート、および宛先ＴＣＰポートを含む４タプルである。トラフィック分類子３３０は、特殊な接続制御パケット（例えば、ＳＹＮ、ＡＣＫ、ＦＩＮ等）を識別するために、パケットのディープインスペクションも実行する。続いて、トラフィック分類子３３０は、これらの制御パケットに関しその他の論理構成要素に通知する。

分類後、トラフィック分類子３３０は、論理１６０内のその他の構成要素を通ってパケットを誘導するか、デフォルトの転送パスを通って誘導するかを決定する。この決定は、構成および監視マネージャ３２０と協議して為され（後述）、構成および監視マネージャ３２０は、プロトコル改善選択に関する情報（例えば、どの接続に改善を適用し、どの接続で従来のプロトコルを使用するか）を保持する。

状態マネージャ３４０は、改善が適用されるそれらのＴＣＰ接続に関する状態を保持する。状態マネージャ３４０は、トラフィック分類子３３０によって提供されるディープインスペクションデータからＴＣＰ接続の初期化および終了処理について学習する。いくつかの実施形態において、接続は、接続制御パケット内のＮタプルに基づいてハッシュまたはインデックス作成され、それは、より速い接続ルックアップおよびパケット識別を容易にする。状態マネージャ３４０はまた、常にパケットを送信／受信しているアクティブ接続に関する情報と、アイドル状態のままである接続に関する情報とを保持する。この区別は、異なるＴＣＰ接続間における公平性を達成することを援助し、論理１６０が、それらの容量の公正な分配より大きくなってきた接続にペナルティを科すことを可能にする。

接続ターミネータ３５０は、エンドポイントＴＣＰ接続のソースおよび宛先それぞれに対する、宛先およびソースとして作用する。したがって、接続ターミネータ３５０は、接続管理、パケット順序付け、輻輳制御、フロー制御、確認応答送信、確認応答受信処理、損失検出、および損失回復等、ＴＣＰエンドポイントの機能性を含む。接続ターミネータ３５０は、拡張トランスポートプロトコル１６５と元のトランスポートプロトコル１２０との間のアダプタとしても機能し、これらのエンドポイント１１０によって理解可能な形態で、ＴＣＰ送信機または受信機へ決定を伝搬する。例えば、論理１６０が「これ以上データを送信しない」というフロー制御決定を為すと、接続ターミネータ３５０は、告知ウィンドウサイズゼロによってこの決定をＴＣＰ送信エンドポイント１１０へ伝達する。接続ターミネータ３５０は、アウトオブオーダ配信、パケット損失、パケット再送等を扱うために、データバッファの保持および管理も行う。

透過マネージャ３６０は、状態マネージャ３４０と連動して、２つのＴＣＰエンドシステム間のネゴシエートされたパラメータ（例えば、最大送信単位、選択的確認応答機構のアベイラビリティ等）が、論理１６０によって必要とされるものと一致することを確実にする。前述のように、トラフィック分類子３３０は、ディープパケットインスペクションを実行し、ＴＣＰ制御パケット（例えば、ＳＹＮ、ＡＣＫ、ＦＩＮ）を検査する。透過マネージャ３６０には、これらのＳＹＮおよびＳＹＮ−ＡＣＫ制御パケットにおいて使用されるパラメータが通知される。元のデフォルトパラメータ自体が論理１６０の要求に適合する場合、そのようなパラメータはそのまま通過させられる。しかしながら、デフォルトパラメータが適合しない場合、透過マネージャ３６０は、代替パラメータを使用するように接続制御パケットを修正する。

コア３７０は、ピアネットワークデバイス１５０間でデータを配信し、拡張トランスポートプロトコル１６５を実装する。拡張トランスポートプロトコル１６５のいくつかの特徴について、以下で説明する。透過なトランスポートプロキシの実施形態において、ネットワークデバイス１５０は、ＴＣＰエンドポイントから受信されるパケットに追加されるトレーラの追加および処理に基づいてそれらの動作を実行する。したがって、２つのネットワークデバイス１５０間を流れるパケットは、元の通信エンドポイントによって送信されたパケットと類似する。現存するネットワーク構成要素はパケットを識別および処理するためにヘッダを使用するので、本発明の特徴は（上述したブリッジ機能性と共に）、拡張トランスポートプロトコル１６５がその他のネットワーク構成要素に対して透過となることを可能にする。

最後に、仮想接続マネージャ３８０は、ピアデバイス１５０間の複数の仮想接続にＴＣＰ接続をマッピングし、これらの仮想接続を集約する。仮想エンドツーエンドパスを形成する、集約された仮想接続を、本願においては「パイプ」と称する。そのような実装の一例は、「Ｓｙｓｔｅｍｓ ａｎｄ Ｍｅｔｈｏｄｓ ｆｏｒ Ｐａｒａｌｌｅｌ Ｃｏｍｍｕｎｉｃａｔｉｏｎ」と題された米国出願第１１／０６３，２８４号において記載されており、当該出願は、参照することによりその全体が本願に組み込まれる。これらの実施形態のいくつかにおいて、仮想接続の数は構成可能であり、論理１６０によって動的に選定され得る。

図３は、処理のために１つの構成要素から別の構成要素に渡されるパケットを示す。いくつかの実施形態において、メモリ使用の効率を増大させるゼロコピー手法が使用される。ゼロコピーパケット処理は、パケットにアクセスする構成要素の数を追跡するために、内部パケット表現の中のＮｕｍＲｅｆｅｒｅｎｃｅｓ（数参照）フィールドを使用する。構成要素がパケットを処理する場合はいつでも、ＮｕｍＲｅｆｅｒｅｎｃｅｓフィールドを増大させる。構成要素が処理を終了すると、ｎｕｍ＿ｒｅｆｅｒｅｎｃｅｓ値を減少させる。これにより、構成要素間でパケットを渡す際のコピーの必要性を回避する。

図４は、図１および３のトランスポートプロトコルの性能を改善するための論理１６０によるパケットの処理を示すデータフロー図である。着信パケットの処理は、トラフィック分類子３３０から始まり、当該トラフィック分類子は、パケットを分類する（４１０）ために、ソースＩＰアドレス、宛先ＩＰアドレス、およびプロトコルヘッダフィールドを使用する。パケットがＴＣＰパケットでも拡張トランスポートパケットでもないことをプロトコルタイプフィールドが示す場合、当該パケットは修正されることなく論理第２層ブリッジ４２０へ転送され、当該ブリッジがパケットを送信する。当業者には理解されるはずであるように、ブリッジ４２０は、単一ＩＰアドレスを有し、第３層（ＩＰ）アドレスと第２層（ＭＡＣ）アドレスとの間のマッピングテーブルを保持することにより、エンドポイントネットワークインタフェース１７０とピアネットワークインタフェース１７５とを連結する。送信用のパケットが与えられると、ブリッジ４２０は、当該パケット内の第３層アドレスを検査し、アドレステーブルに基づいて、いずれのインタフェース（エンドポイントネットワークインタフェース１７０およびピアネットワークインタフェース１７５）で送信するかを判断する。したがって、以下の考察においては、どのインタフェースかを特定することなく、パケットの伝送、送信、または転送に言及する。

ブリッジとして動作することにより、トランスポートプロトコルの性能を改善するための論理１６０を含むネットワークデバイス１５０は、ＴＣＰエンドポイント１１０上の経路指定テーブルへの変更を必要とすることなく、パケットのインターセプトおよび処理を実行することが可能になる。ブリッジ動作は、ネットワークデバイス１５０が、ＴＣＰエンドポイント１１０とルータ１４０との間のインラインの代わりに、ルータ１４０から離れて位置するオフラインデバイスとして動作することも可能にする。

トラフィック分類子３３０によってパケットがＴＣＰパケットとして分類される（４１０）と、当該パケットは状態マネージャ３４０に提供される。状態マネージャ３４０は、ＴＣＰパケットのタイプを判断する（４３０）。ＴＣＰパケットが接続セットアップパケット（例えば、ＳＹＮまたはＳＹＮＡＣＫ）である場合、状態マネージャ３４０は、接続状態をそれぞれ作成または更新し、パケットを透過マネージャ３６０にハンドオフする。前述のように、透過マネージャ３６０は、セットアップ中に、ＴＣＰ ＳＹＮおよびＴＣＰ ＳＹＮＡＣＫパケット内で伝達される接続オプションを検査し、これらのオプションを、拡張トランスポートプロトコル１６５との適合性を確保するために随時修正する。続いて、透過マネージャ３６０は、ＴＣＰ制御パケットを転送する。

ＴＣＰパケットはＲＳＴパケットであると状態マネージャ３４０が判断する（４３０）と、状態マネージャ３４０は、接続が存在するか否かを（例えば、接続ハッシュテーブルを調べることによって）判断する（４４０）。接続が存在する場合、当該接続は状態マネージャ３４０によって削除され、ＴＣＰ制御パケットが転送される。状態マネージャ３４０による判断４３０に戻り、パケットがＦＩＮパケットであって接続が存在する場合、当該接続状態は更新される。ＦＩＮがローカルエンドポイントでも受信されていた場合、当該接続は削除される。いずれの場合も、状態マネージャ３４０は、接続ターミネータ３５０にＴＣＰ ＦＩＮパケットを送信するように要求し、その後、当該ＴＣＰ ＦＩＮパケットを転送する。

再度状態マネージャ３４０による判断４３０に戻り、ＴＣＰパケットがＡＣＫまたはＴＣＰデータパケットである場合、状態マネージャ３４０は、接続が存在するか否かを（例えば、接続ハッシュテーブルを調べることによって）判断する。接続が存在しない場合、状態マネージャ３４０はＴＣＰパケットを転送する。接続が存在する場合、状態マネージャ３４０は状態情報を更新し、パケットを接続ターミネータ３５０にハンドオフする。

状態マネージャ３４０からＴＣＰパケットを受信した後、接続ターミネータ３５０は、ＴＣＰパケットを分類する（４５０）。ＴＣＰパケットがＡＣＫである場合、接続ターミネータ３５０は、確認応答の受信によって示される適切なハウスキーピング処理を実行し、ＡＣＫを廃棄または消費する。

ここで、接続ターミネータ３５０によって実行されるハウスキーピング処理について、図５のフローチャートに関連して説明する。接続ターミネータ３５０は、ブロック５１０において確認応答の処理を始め、ここで確認応答されたパケットがＴＣＰ送信バッファから除去される。次に、ブロック５２０において、確認応答を反映させるために、シーケンス内の番号が更新される。続いて、ブロック５３０において、通信中パケットのカウントが更新される。ブロック５４０において処理が継続し、ここで最大許容未処理パケットが更新される。最後に、通信中カウントが最大許容未処理パケット未満である間、ブロック５５０が繰り返しループで実行され、ここで５５０はＴＣＰ送信バッファ内で次のパケットを送信する。

ここで、図４の接続ターミネータ３５０による分類（４５０）に戻り、ＴＣＰパケットが制御パケットとは異なるデータである場合、接続ターミネータ３５０は、パケットをさらに処理する。ここで、この接続ターミネータ３５０によるＴＣＰデータパケットの処理について、図６のフローチャートに関連して説明する。

接続ターミネータ３５０は、ブロック６１０においてパケットの処理を始め、当該処理は、コア構成要素（３７０）のバッファサイズを閾値と比較するものである。バッファサイズが閾値を満たす場合、ブロック６２０は、次のシーケンス内のパケットのためのＤＵＰＡＣＫを送信する。次に、当該パケットが廃棄され（ブロック６３０）、パケットの処理が完了する。コア構成要素のバッファサイズが閾値を満たさない場合、ブロック６４０において処理が継続する。ブロック６４０では、受信パケットが次のシーケンス内のパケットか否かを判断する。「いいえ」の場合、ブロック６４５において、受信パケットがＴＣＰ受信バッファ内へ挿入され、ブロック６５０は、次のシーケンス内のパケットのためのＤＵＰＡＣＫを送信し、このパケットの処理は完了する。一方で、受信パケットが次のシーケンス内のパケットであるとブロック６４０が判断した場合、ブロック６５５において処理が継続する。

ブロック６５５は、接続状態を更新する。次に、ブロック６６０において、コア構成要素３７０は、パケットを送信するように要求される。ブロック６６５において、ＴＣＰ受信バッファが空であるか否かを判断する処理が継続する。空である場合、ブロック６７０は受信パケットの確認応答を送信し、当該パケットの処理は終了する。ＴＣＰ受信バッファが空でない場合、ブロック６７５は、バッファ内のすべてのシーケンス内のパケットは送信処理の準備が整っていることをコア構成要素３７０に通知する。次に、ブロック６８０は、ブロック６７５で処理されたばかりのシーケンス内のパケットすべてについて確認応答を送信する。受信したＴＣＰパケットの処理は、これで完了である。

論理１６０によるＴＣＰパケットの処理については、図５および６のフローチャートの他に、図４の主データフロー図と併せて説明した。ここで図４の主データフロー図に戻り、パケットがＴＣＰパケットではなく拡張トランスポートパケットとして分類された場合（４１０）、当該パケットはコア３７０に提供される。コア３７０は、当該パケットが、拡張トランスポートデータパケット（４７０）であるか、または拡張トランスポート制御もしくは確認応答パケット（４８０）であるかを判断する（４６０）。

コア３７０による、拡張トランスポートのデータパケット、制御パケット、確認応答パケットのさらなる処理について、図７のフローチャートに関連して説明する。

コア３７０による受信した拡張トランスポートパケットの処理がブロック７１０において始まり、当該処理は、受信パケットが拡張トランスポートデータであるか否かを判断するものである。「いいえ」である場合、ブロック７６５（図７Ｂ）において処理が継続し、これについては以下で考察する。受信パケットが拡張トランスポートデータである場合、ブロック７１５において処理が継続し、当該処理は、受信パケットが次のシーケンス内のパケットであるか否かを判断するものである。「いいえ」である場合、ブロック７２０において処理が継続し、ここで、当該パケットは受信バッファ内に格納される。次に、ブロック７２５は、次のシーケンス内のパケットのためのＤＵＰＡＣＫを送信する。続いて、拡張トランスポートデータパケットの処理が完了する。

ブロック７１５に戻り、受信したデータパケットが次のシーケンス内のパケットではないと判断された場合、ブロック７３０は、拡張トランスポートデータパケットからＴＣＰパケットを脱カプセル化し、ブロック７３５において、ＴＣＰパケットがさらなる処理のために接続ターミネータ構成要素３５０にハンドオフされる。接続ターミネータ処理の後、ブロック７４０において、コア構成要素の受信バッファが確認される。受信バッファが空である場合、ブロック７４５において処理が継続し、ここで、受信した拡張トランスポートデータパケットの確認応答が送信され、受信した拡張トランスポートデータパケットの処理が完了する。しかしながら、コア構成要素の受信バッファが空でない場合、ブロック７５０は、受信バッファ内のシーケンス内の拡張トランスポートデータパケットに包含されるＴＣＰパケットを脱カプセル化することにより、受信バッファを扱う。次に、ブロック７５５において、ＴＣＰパケットは、さらなる処理のために、接続ターミネータ構成要素３５０にハンドオフされる。接続ターミネータ処理の後、ブロック７６０は、コア受信バッファ内の処理されたシーケンス内のパケットすべての確認応答を送信し、処理が完了する。

ブロック７１０に戻り、受信パケットが拡張トランスポートデータパケットではない場合、当該パケットはブロック７６５（図７Ｂ）においてさらに分類される。パケットが確認応答ではない場合（例えば、拡張トランスポートＳＹＮ、ＳＹＮＡＣＫ、ＲＥＳＥＴ、またはハートビート）、当該パケットは、さらなる処理のために、ブロック７７０において接続マネージャ構成要素３１０に渡される。一方で、パケットが拡張トランスポート確認応答である場合、ブロック７７５において処理が継続する。

ブロック７７５において、コア３７０は、確認応答が行列の先頭のパケットのものであるか否かを判断する。「いいえ」である場合、パケットは無視され、処理が完了する。「はい」である場合、ブロック７８０は、次のシーケンス内の番号、通信中パケットの数、および許容される未処理パケットの数を更新する。統計値を更新した後、受信した確認応答によって確認応答されたパケットは、ブロック７８５において、受信バッファから除去される。いくつかの実施形態において、バッファをリキャプチャするために、「遅延解放」技術が使用される。（遅延解放技術については、以下で考察する。）バッファ一掃後、仮想接続マネージャ３８０は、ブロック７９０において、輻輳ウィンドウに現在新しい伝送が可能か否かを判断するためにクエリされる。可能である場合、ブロック７９５は、ウィンドウ空間が利用可能でなくなるまで、新しい拡張トランスポートデータパケットを送信する。

コア３７０のいくつかの実施形態によって実装される遅延パケット解放機構は、確認応答されたパケットの解放をパケット処理サイクル中の後の時点まで遅延させる。具体的には、複数のパケットの受信を通知する確認応答が受信機から到着すると、送信機は確認応答されたパケットのリストをマークし、それらのパケットの実際の解放を後に延期する。続いて、送信機によって送信される新しいパケット毎に、規定数のパケットが遅延バッファから解放される。これにより、複数のパケット送信の間にわたる複数のパケットメモリ解放動作のオーバーヘッドを分割償却し、確認応答の受信直後の処理を減速させない。

図８は、仮想接続マネージャ３８０による、受信した拡張トランスポートパケットの処理を示すフローチャートである。拡張トランスポートデータパケットおよび拡張トランスポート確認応答パケットを含むこれらの受信パケットは、コア３７０によって仮想接続マネージャ３８０に提供される。仮想接続マネージャ３８０による、受信した拡張トランスポートパケットの処理は、ブロック８０５で始まり、当該処理は、拡張トランスポートパケットがデータであるか確認応答であるかを判断するものである。データであれば、ブロック８１０において処理は継続し、当該処理は、受信したデータパケットが次のシーケンス内のパケットであるか否かを判断するものである。「いいえ」である場合、ブロック８１５において処理が継続し、ここで、受信したデータパケットのシーケンス番号は、アウトオブオーダ・リストに格納される。次に、ブロック８２０は、選択的確認応答（ＳＡＣＫ）スコアボードを更新し、ブロック８２５は、次のシーケンス内のパケットのためのＤＵＰＡＣＫを送信する。そして、拡張トランスポートデータパケットの処理が完了する。

ブロック８１０に戻り、受信したデータパケットが次のシーケンス内のパケットであると判断された場合、ブロック８３０は、アウトオブオーダ・リストを検査する。リストが空である場合、ブロック８３５は、受信パケットの確認応答を送信し、処理が完了する。リストが空でない場合、ブロック８４０は、受信パケットに対応するシーケンス内の番号をアウトオブオーダ・リストから除去する。次に、ブロック８４５において、シーケンス内のすべてのパケットの確認応答が送信され、受信パケットの処理が終了する。

ブロック８０５における受信パケットの分類に戻り、パケットが拡張トランスポート確認応答パケットである場合、ブロック８５０は、確認応答が行列の先頭のパケットのものであるか否かを判断する。「いいえ」である場合、当該パケットは無視され、処理が完了する。「はい」である場合、ブロック８５５は、コア構成要素がＬＯＳＳ ＲＥＣＯＶＥＲＹ（損失回復）状態であるか否かを判断する。一実施形態において、コア構成要素の状態は、ＮＯＲＭＡＬ（正常）、ＬＯＳＳ＿ＲＥＣＯＶＥＲＹ、ＴＩＭＥＯＵＴ（タイムアウト）、ＳＹＮ＿ＳＥＮＴ（同期送信）、およびＳＹＮ＿ＲＥＣＶＤ（同期受信）を含む。これらの状態は、当業者には理解されるはずであるように、トランスポートプロトコルの選定によって変動し得る。

損失回復状態でない場合、ブロック８６０において、以下の統計値、つまり次のシーケンス内の番号、通信中パケットの数、および許容される未処理パケットの数が更新される。これらの統計値が更新された後、ブロック８６５において、輻輳制御パラメータが更新される。一実施形態において、輻輳制御パラメータは、輻輳ウィンドウサイズおよび閾値を含む。そして、拡張トランスポート確認応答パケットの処理が完了する。

ブロック８５５でコア構成要素が損失回復状態であると判断すると、ブロック８７０において処理が継続し、当該処理は、ＬＯＳＳ＿ＲＥＣＯＶＥＲＹ状態に入る時に、確認応答が未処理パケットすべてのものであるか否かを判断するものである。「はい」である場合、コア構成要素の状態はＮＯＲＭＡＬに更新される。ブロック８７５において、パイプパラメータがブロック８８０で更新され、パケットの処理が完了する。ブロック８７０で確認応答が未処理パケットすべてのものに満たないと判断すると、ブロック８８５においてパイプ（仮想エンドツーエンドパス）のパラメータが更新される。一実施形態において、これらのパラメータは、次のシーケンス内の番号、通信中パケットの数、および許容される未処理パケットの数を含む。ブロック８９０において受信パケットが再送信され、続いて処理が完了する。

拡張トランスポートプロトコル１６５を実装する論理１６０の動作全般について説明してきたが、ここで、このプロトコルのいくつかの特徴について説明する。当業者であれば、これらの特徴は概して互いに独立しているため、拡張トランスポートプロトコル１６５の特定の実施形態は、これらの特徴の何らかの組み合わせを含み得ることを理解するはずである。拡張トランスポートプロトコル１６５は、ＴＣＰとは異なり、その他のアプリケーションおよびサービスとメモリを共有することを要求されない。デバイスのメモリ全体が、アクティブ接続のパケットのバッファリング専用であってもよい。さらに、この大きいバッファは、接続に対するいかなる固定割り当てにもなっておらず、複数のアクティブエンドツーエンド接続間で柔軟に共有される。広帯域遅延積を有するネットワークにおいて、ＴＣＰの性能は、当該ネットワーク内の最大未処理パケットに課される制限によって制限される。拡張トランスポートプロトコルは、小型ウィンドウの制限事項を排除し、アクティブ接続のパケットをバッファするためのシステムに利用可能なメモリ全体の完全な共有を達成することにより、広帯域遅延積を有するネットワークにおけるエンドツーエンド接続の性能を改善する。

広帯域遅延積を有するネットワークにおいて、ＴＣＰ性能は、当該ネットワーク内の最大未処理パケットに課される制限によって制限される。拡張トランスポートプロトコルは、小型ウィンドウの制限事項を排除し、アクティブ接続のパケットをバッファするためのシステムに利用可能なメモリ全体の完全な共有を達成することにより、広帯域遅延積（ｌａｒｇｅ ＢＤＰ；ｌａｒｇｅ Ｂａｎｄｗｉｄｔｈ‐Ｄｅｌａｙ Ｐｒｏｄｕｃｔ）を有するネットワークにおけるエンドツーエンド接続の性能を改善する。

図９は、拡張トランスポートプロトコル１６５によって使用されるフロー制御機構のフロー図である。本例において、エンドポイント１１０ＡはＴＣＰ送信機であり、エンドポイント１１０ＢはＴＣＰ受信機である。エンドポイント１１０Ａは、エンドポイント１１０Ｂに宛てたＴＣＰデータメッセージ９１０を送信する。ネットワークデバイス１５０Ａは、ＴＣＰデータメッセージ９１０を受信し、それらを拡張トランスポートプロトコルデータメッセージ９２０内にカプセル化し、ネットワークデバイス１５０Ｂへ送信する。ネットワークデバイス１５０Ｂは、ＴＣＰデータメッセージ９２０を受信し、その中にカプセル化されたＴＣＰデータメッセージ９１０を除去し、ＴＣＰデータメッセージ９１０をエンドポイント１１０Ｂへ送信する。

フロー制御は、接続の３つの区間すべてにおいて使用される。エンドポイント１１０Ａに最も近いネットワークデバイス１５０Ａは、エンドポイント１１０Ａの送信速度を制御するためにＴＣＰフロー制御機構を使用する。すなわち、ネットワークデバイス１５０Ａは、ＴＣＰスライディングウィンドウ告知および／または凍結メッセージ９３０をエンドポイント１１０Ａへ送り返すことにより、自身のエンドポイント側の受信バッファを管理する。エンドポイント１１０Ａは、これらのＴＣＰフロー制御メッセージ９３０を理解し、示されるようにスロットルを絞る。

エンドポイント１１０ＡからＴＣＰデータを受信するエンドポイント１１０Ｂも、それに最も近いネットワークデバイス１５０Ｂのスロットルを絞るために、ＴＣＰフロー制御メッセージ９３０を使用する。ネットワークデバイス１５０Ｂは、エンドポイント側からのフロー制御メッセージがＴＣＰフロー制御メッセージ９３０であることを予期して、示されるようにスロットルを絞る。ネットワークデバイス１５０Ｂが、エンドポイント１１０Ｂによって命令されるようにデータ速度を低下させると、ネットワークデバイス１５０Ｂは、同様に送信ネットワークデバイス１５０Ａのスロットルを絞ることが必要となる場合がある。そうすると、ネットワークデバイス１５０Ｂは、拡張トランスポートフロー制御メッセージ９４０を（ＴＣＰフロー制御メッセージ９３０とは異なる）ネットワークデバイス１５０Ａへ送信する。これにより、ネットワークデバイス１５０Ｂ内のルータ側受信バッファを充填することができ、この時点で、ネットワークデバイス１５０Ｂは、ＴＣＰフロー制御メッセージ９３０を送信することにより、エンドポイント１１０Ａのスロットルを絞ることになる。このように、送信エンドポイント１１０Ａのデータ速度は、接続の３つの区間すべてに対するフロー制御によって影響を及ぼされ得る。当業者であれば、ネットワークデバイス１５０が受信バッファ空間を使い果たすと、この方法が、ネットワークデバイス１５０間のネットワーク１３０におけるトラフィックを減速させ、最終的にＴＣＰ送信エンドポイント１１０Ａに戻すための優れた背圧機構を提供することを十分に理解するはずである。

ネットワークデバイス１５０のいくつかの実施形態は、ＴＣＰ接続レベルで実行される、さらなるレベルのフロー制御を含み、これは、単一のＴＣＰ接続が受信バッファの「公正な分配」を上回った場合に発生する。この条件下において、受信ネットワークデバイス１５０は、その特定のＴＣＰ接続を表すＴＣＰ凍結メッセージを送信ネットワークデバイス１５０へ送信する。これを受けて、送信ネットワークデバイス１５０は、リモート側にある対応するＴＣＰ接続の送信速度のスロットルを絞る。

図１０は、ネットワークデバイス１５０のいくつかの実施形態によって実装される輻輳制御機構を示す状態図である。アルゴリズムは、ＳｌｏｗＳｔａｒｔ（低速開始）１０１０、ＣｏｎｇｅｓｔｉｏｎＡｖｏｉｄａｎｃｅ（輻輳回避）１０１５、Ｍａｉｎｔａｉｎ（保持）１０２０、ＰｒｏｐｏｒｔｉｏｎａｌＤｅｃｒｅａｓｅ（比例する減少）１０２５、ＬｏｓｓＲｅｃｏｖｅｒｙ（損失回復）１０３０、およびＩｎｉｔｉａｌｉｚｅＷｉｎｄｏｗ（ウィンドウ初期化）１０３５という６つの状態の間を遷移する。拡張トランスポートプロトコル１６５は、ＳｌｏｗＳｔａｒｔ状態１０１０から始まる。ＳｌｏｗＳｔａｒｔ状態１０１０である間、接続における輻輳ウィンドウは、非線形様式で周期的に増大する（１０４０）。一実施形態において、ＳｌｏｗＳｔａｒｔ状態１０１０の間に輻輳ウィンドウが閾値に到達する（１０４５）と、送信機はＣｏｎｇｅｓｔｉｏｎ Ａｖｏｉｄａｎｃｅ状態１０１５に遷移する。代わりに、ネットワーク１３０を通る接続の往復時間（プローブによって計測されるもの）が閾値に到達した（１０５０）場合、送信機は、Ｍａｉｎｔａｉｎ状態１０２０に遷移し、これについては以下で考察する。

ＳｌｏｗＳｔａｒｔ状態１０１０から到達したＣｏｎｇｅｓｔｉｏｎ Ａｖｏｉｄａｎｃｅ状態１０１５は、パケット損失を示すイベント（１０５５または１０５７）時に脱出される。Ｃｏｎｇｅｓｔｉｏｎ Ａｖｏｉｄａｎｃｅ状態１０１５は、プローブによって計測されるような、ネットワーク１３０を通る接続の往復時間が閾値を越えて増大した（１０６０）際にも脱出され得る。パケット損失を示すタイムアウトイベント（１０５５）の場合、送信機はＩｎｉｔｉａｌｉｚｅＷｉｎｄｏｗ状態１０３５に遷移し、ここで輻輳ウィンドウは初期値にリセットされ、続いて、送信機はＳｌｏｗＳｔａｒｔ状態１０１０に戻る。パケット損失を示す重複確認応答イベント（１０５７）の場合、送信機は、以下で考察するＰｒｏｐｏｒｔｉｏｎａｌ Ｄｅｃｒｅａｓｅ状態１０２５に遷移する。往復時間が閾値に到達した（１０６０）場合、送信機は、Ｃｏｎｇｅｓｔｉｏｎ Ａｖｏｉｄａｎｃｅ状態１０１５からＭａｉｎｔａｉｎ状態１０２０に遷移する。

Ｍａｉｎｔａｉｎ状態１０２０の間、輻輳ウィンドウは、タイムアウト（１０６５）または重複確認応答（１０７０）によって示されるようなパケット損失が発生するまで、前回の算出値に固定されたままである。タイムアウト１０６５の場合、送信機はＳｌｏｗＳｔａｒｔ状態１０１０に戻る。重複確認応答１０７０の場合、送信機は、Ｐｒｏｐｏｒｔｉｏｎａｌ Ｄｅｃｒｅａｓｅ状態１０２５に遷移する。

Ｐｒｏｐｏｒｔｉｏｎａｌ Ｄｅｃｒｅａｓｅ状態１０２５において、送信機は、損失パケットの数に比例する値だけ速度のスロットルを絞ることによって輻輳損失の検出に反応し、Ｌｏｓｓ Ｒｅｃｏｖｅｒｙ状態１０３０に入る。Ｌｏｓｓ Ｒｅｃｏｖｅｒｙ状態１０３０に入る際、輻輳ウィンドウは、損失時における未処理パケットの数に設定され、１回の往復時間中に、ネットワーク１３０内で損失したパケットの数に比例する量だけ削減される。この機構は、損失回復中に、損失パケットよりも前に新しいパケットが伝送されることを確実にする。Ｌｏｓｓ Ｒｅｃｏｖｅｒｙ状態１０３０の間、確認応答毎にデータが送信される（１０７５）。損失回復に入る時における未処理パケットすべての確認応答時（１０８０）、送信機は、Ｌｏｓｓ Ｒｅｃｏｖｅｒｙ状態１０３０を脱出し、Ｃｏｎｇｅｓｔｉｏｎ Ａｖｏｉｄａｎｃｅ状態１０１５に戻る。パケット損失を示すタイムアウト時、輻輳ウィンドウは、損失時の元のウィンドウサイズ（状態１０３５）にリセットされ、送信機は、ＳｌｏｗＳｔａｒｔ状態１０１０に戻る。

当業者であれば、この損失回復機構がＴＣＰと比較して積極性の低い方法であることを十分に理解するであろう。ＴＣＰは、接続進行中に発生するいかなるパケット損失もネットワーク輻輳の兆候として解釈されるように設計され、ＴＣＰは、接続の速度のスロットルを半分だけ絞ることによって反応する。拡張トランスポートプロトコル１６５によって使用される比例的減少機構は、プロビジョニングされた帯域幅が利用可能な環境（例えば、無線データネットワークおよびプライベートＷＡＮ）において、より適切である。積極性の低い輻輳制御を達成することとは別に、拡張トランスポートプロトコル１６５によって用いられる比例的減少機構は、ＴＣＰによって使用される相乗的減少機構よりも良好にランダムパケット損失を扱うことができる。拡張トランスポートプロトコル１６５は、パケット損失の数に比例して輻輳ウィンドウを削減するため、輻輳制御に対するランダム損失の影響は減少される。

当業者であれば、輻輳ウィンドウの上記の調整は、更新された輻輳ウィンドウが損失回復状態の脱出時において多数のパケット伝送を可能にするシナリオをもたらし得ることも認識するはずである。拡張トランスポートプロトコル１６５のいくつかの実施形態において、受信ネットワークデバイス１５０は、新しいパケット送信の数を新しい確認応答の受信毎に２つに制限することにより、これらのパケット送信を未来にわたり確認応答を分散させる。

当業者であれば、図１０の輻輳アルゴリズムと、ＴＣＰ等の従来のトランスポートプロトコルによって使用されるものとの差異を十分に理解するはずである。ＴＣＰは、速度探査のために線形増大方法を使用し、利用可能な容量がＣユニットであり、且つＴＣＰ接続の現在のデータ速度がＣ−Ｘユニットである場合、ＴＣＰは、接続データ速度の理想的な動作点に到達するために約Ｘ往復時間を要することになる。したがって、ＴＣＰは、ネットワーク１３０における新しいリソースのアベイラビリティ、および、輻輳ウィンドウの前回の削減に起因する低ビットレート動作の両方に対して、反応が遅い。往復時間が大きい場合、ＴＣＰは、理想的な動作点に到達するために長時間を要する。ＳＳＬトランザクション等の短期接続は、理想的な動作点に到達する前に、データ転送を完全に終了し得る。さらに、既に確立された拡張トランスポートプロトコル接続への複数のエンドツーエンド接続の多重化により、ネットワークデバイスは、これらのエンドツーエンド接続の起動探査遅延を排除する。これは、それによって多重化される拡張トランスポートプロトコル接続を通るエンドツーエンド接続間でネットワーク情報を共有することによって可能となる。この起動遅延削減は、短寿命を有するトランザクションアプリケーションの性能を著しく改善する。

さらに、ＴＣＰ輻輳制御プロセスは増大段階および減少段階という２つの段階しか有さないことから、ＴＣＰは、ルーチンの輻輳制御動作中でさえも損失を誘発する傾向を有する。ネットワーク１３０内に外部からの輻輳がない場合であっても、ＴＣＰは、ネットワーク１３０内で輻輳が誘発されて損失が発生するまで、接続データ速度を増大させ続け、このとき、減少段階に移行し、速度は輻輳制御サイクルの反復のために半分になる。強制的な減少および緩慢な増大を伴うこの不必要なサイクルは、ＴＣＰ接続の性能をさらに制限するものである。

拡張トランスポートプロトコル１６５は、従来のトランスポートプロトコルよりも高速ネットワークに適した損失検出機構も特徴とする。損失を検出するために高オーバーヘッドタイムアウトを使用する代わりに、拡張トランスポートプロトコル１６５は、送信されたパケットの数、受信されたパケットの数、および、損失検出中に適切なマイルストーンイベントにおいて送信されたパケットのシーケンス番号に基づく受動的学習手法を使用する。より具体的には、送信ネットワークデバイス１５０は、それが送信するすべてのパケット上にある、ＣＯＮＧ＿ＳＥＱ＿ＮＵＭと称される単調増大シーケンス番号を使用する。受信ネットワークデバイス１５０は、確認応答時にＣＯＮＧ＿ＳＥＱ＿ＮＵＭを受信パケットに反映させ、ＡＣＫ＿ＣＯＮＧ＿ＳＥＱとする。ＡＣＫ＿ＣＯＮＧ＿ＳＥＱが対応する再送信されたパケット上のＣＯＮＧ＿ＳＥＱ＿ＮＵＭよりも大きい場合、送信ネットワークデバイス１５０は、再送信されたパケットが損失したと結論付け、当該損失から回復するために適切なアクションをとる。この機構がない場合、再送信されたパケットが損失したか否かを判断するための唯一の手法は、タイムアウト機構を使用することであるが、これは貴重なネットワーク帯域幅の非効率的な使用法である。

拡張トランスポートプロトコル１６５によって使用される損失報告機構は、より多数の損失ブロックを収容し、マルチレベル選択的確認応答（ＳＡＣＫ）機構を組み込むことにより、従来の技術よりも速い報告を可能にする。従来のＴＣＰによって使用される単層式のＳＡＣＫ機構とは異なり、拡張トランスポートプロトコル１６５は、損失を送信ネットワークデバイス１５０へ伝達するために、複数レベルのＳＡＣＫを使用する。各ＳＡＣＫブロックは、パケットの損失ブロックの開始および終了の両方、ならびに、損失回復段階の伝送サイクルの番号を有する。伝送サイクル番号は、ＳＡＣＫブロック内のパケットの再伝送の数によって識別される。送信ネットワークデバイス１５０は、再伝送プロセスに関する最小伝送サイクル番号に優先権を与える。

ネットワークデバイス１５０は、パケットが受信機に到達しない際にネットワーク１３０が長期にわたってダウンする事例に対処するために、粗タイムアウトも使用する。新しいデータパケットが受信機によって確認応答される（確認応答によって示される）度に、タイマがリセットされる。タイマが満了した場合、それは、送信バッファ中の行列の先頭のパケットが首尾よく配信されず、したがって再送信の必要があることを示している。これらの粗タイムアウトは、一時的なネットワーク故障に対処することができ、一方、上述したＣＯＮＧ＿ＳＥＱ＿ＮＵＭベースの損失検出および回復機構は、受信機に到達し、それによって送信機への確認応答をトリガするパケットがある場合のみ、稼動する。

拡張トランスポートプロトコル１６５のまた別の特徴は、従来のトランスポートプロトコルとは異なりシーケンス番号を使用することによって信頼性を増大させる。受信ネットワークデバイス１５０は、確認応答内のＮＸＴ＿ＳＥＱ＿ＮＵＭフィールドを使用して、受信ネットワークデバイス１５０における受信バッファのステータスを送信ネットワークデバイス１５０に連絡する。ＮＸＴ＿ＳＥＱ＿ＮＵＭは、受信機のアウトオブオーダ・バッファ中にある行列の先頭のパケットのシーケンス番号である。送信機は、ＮＸＴ＿ＳＥＱ＿ＮＵＭ値を使用して、受信した確認応答が「真の部分的確認応答」であるか「偽の部分的確認応答」であるかを判断する。真の部分的確認応答は、ＮＸＴ＿ＳＥＱ＿ＮＵＭに満たないすべてのパケットの受信を確認応答するが、損失時において未処理であるすべてのパケットではない。偽の部分的確認応答は、ＮＸＴ＿ＳＥＱ＿ＮＵＭに満たないすべてのパケットの受信を確認応答せず、受信機によって予期された次のシーケンス内のパケットを確認応答する。真および偽の部分的確認応答を区別するためにＮＸＴ＿ＳＥＱ＿ＮＵＭフィールドを使用することにより、送信ネットワークデバイス１５０は、損失回復中でさえも、ネットワーク１３０の利用を増大させる。

拡張トランスポートプロトコル１６５とＴＣＰ等の従来のトランスポートプロトコルとの間のさらに別の差異は、拡張トランスポートプロトコル１６５のいくつかの実施形態が、告知（スライディング）ウィンドウサイズまたは輻輳ウィンドウサイズについての限界を有さないことである。拡張トランスポートプロトコル１６５のその他の実施形態は、限界を有する。これらの実施形態のいくつかは、従来のプロトコルによって使用される限界よりもはるかに大きい限界を有する。

図１１は、トランスポートプロトコルの性能を改善するためのシステムおよび方法にしたがった、ネットワークデバイス１５０のハードウェアブロック図である。ネットワークデバイス１５０は、プロセッサ１１１０、ローカルネットワークインタフェース１１２０、リモートローカルインタフェース１１３０、メモリ１１４０、および不揮発性ストレージ１１５０を含む、データ通信の分野で既知である多数の構成要素を包含する。不揮発性ストレージの例としては、例えば、ハードディスク、フラッシュＲＡＭ、フラッシュＲＯＭ、ＥＥＰＲＯＭ等を含む。これらの構成要素は、バス１１６０を介して連結される。メモリ１１４０は、図１のトランスポートプロトコルの性能を改善するための論理１６０を包含する。

ネットワークデバイス１５０は、２つのネットワークインタフェースと共に示されている。ローカルネットワークインタフェース１１２０はエンドポイント１１０と通信を行っており、リモートローカルインタフェース１１３０はルータ１４０と通信を行っている。当業者であれば、ネットワークインタフェースは異なるタイプの、異なる媒体および速度に対応するもの等であってもよいことを理解するはずである。図１１からは、ネットワークデバイス１５０の動作について説明するために必要ない、当業者に既知である多数の従来の構成要素が省略されている。

フローチャート内のあらゆるプロセス記述またはブロックは、当該プロセス中の特定の論理機能またはステップを実装するための１つ以上の実行可能命令を含むモジュール、セグメント、またはコードの部分を表すものとして理解されるべきものである。ソフトウェア開発分野の当業者には理解されるように、本開示の範囲内には、代替的実装も含まれる。これらの代替的実装において、機能は、関与する機能性に応じて、図示または考察されているものと実質的に同時または逆の順序を含むアウトオブオーダで実行され得る。

本願において開示するシステムおよび方法は、命令実行システム、装置、もしくはデバイスによって、またはそれらと接続して使用するための任意のコンピュータ可読媒体において具現化され得る。そのような命令実行システムは、任意のコンピュータベースのシステム、プロセッサ包含システム、または、命令実行システムからの命令をフェッチおよび実行することができるその他のシステムを含む。本開示の文脈において、「コンピュータ可読媒体」は、命令実行システムによって、またはそれと接続して使用するためのプログラムを包含、格納、通信、伝搬、または運搬することができる任意の手段であってもよい。コンピュータ可読媒体は、例えば、電子、磁気、光学、電磁気、赤外線、または半導体技術に基づくシステムまたは伝搬媒体であってもよいが、これらに限定されない。

電子技術を使用するコンピュータ可読媒体の具体例としては、１本以上のワイヤを有する電気的接続（電子）、ランダムアクセスメモリ（ＲＡＭ）、リードオンリメモリ（ＲＯＭ）、消去可能リードオンリメモリ（ＥＰＲＯＭまたはフラッシュメモリ）を含み得る（がこれらに限定されない）。磁気技術を使用する具体例としては、ポータブルコンピュータディスケットを含む（がこれらに限定されない）。光学技術を使用する具体例としては、光ファイバおよびポータブルコンパクトディスクリードオンリメモリ（ＣＤ‐ＲＯＭ）を含む（がこれらに限定されない）。

前述の記述は、図示および説明を目的として提示したものである。網羅的であることも、開示されている厳密な形態に本開示を限定することも意図していない。上記の教示に鑑みて、明らかな修正形態または変形形態が可能である。しかしながら、考察されている実装は、本開示の原理およびその実践的応用を説明し、それによって、当業者が、種々の実装において、および予定される特定の使用に適した種々の修正形態と共に本開示を利用することを可能にするために、選定および説明したものである。そのような修正形態および変形形態はすべて、それらが公正且つ合法的に権利を与えられた幅にしたがって解釈される場合、添付の特許請求の範囲によって判断されるように、本開示の範囲内である。

図１は、トランスポートプロトコルの性能を改善するためのシステムおよび方法の一実施形態が位置する環境のブロック図である。 図２は、トランスポートプロトコルの性能を改善するためのシステムおよび方法の別の実施形態が位置する環境のブロック図である。 図３は、図１のトランスポートプロトコルの性能を改善するための論理１６０のブロック図である。 図４は、図１および３のトランスポートプロトコルの性能を改善するための論理１６０によるパケットの処理を示すデータフロー図である。 図５は、図３の接続ターミネータ３５０による、受信した確認応答の処理を示すフローチャートである。 図６は、図３の接続ターミネータ３５０による、ＴＣＰパケットの処理を示すフローチャートである。 図７は、図３のコア３７０による、拡張トランスポートのデータ、制御、または確認応答のパケットの処理を示すフローチャートである。 図７は、図３のコア３７０による、拡張トランスポートのデータ、制御、または確認応答のパケットの処理を示すフローチャートである。 図８は、図３の仮想接続マネージャ３８０による、受信パケットの処理を示すフローチャートである。 図９は、図３の論理１６０のいくつかの実施形態によって使用されるフロー制御機構のフロー図である。 図１０は、図３の論理１６０のいくつかの実施形態によって使用される輻輳制御機構の状態図である。 図１１は、本願において開示するトランスポートプロトコルの性能を改善するためのシステムおよび方法を実装するために使用され得る、汎用コンピュータのブロック図である。

Claims (5)

1. 第１のデバイスとピアの第２のデバイスとの間のネットワークにおける輻輳を制御する方法であって、
   第１の状態において、輻輳ウィンドウを非線形に増大させるステップと、
   該第１の状態の間に、該輻輳ウィンドウが閾値を上回ったことを受けて、第２の状態へ遷移するステップと、
   該第２の状態において、該輻輳ウィンドウを線形に増大させるステップと
   を含む、方法。
2. 多数のパケットの損失を示す重複確認応答の受信時に、第３の状態へ遷移するステップと、
   該第３の状態において、該パケット損失の数に比例して前記輻輳ウィンドウを減少させるステップと
   をさらに含む、請求項１に記載の方法。
3. 第１のパケット系列を送信するステップであって、各パケットは、増加するシーケンス番号を含む、ステップと、
   第２のパケット系列を受信するステップであって、各パケットは、確認応答されたシーケンス番号を含む、ステップと、
   該確認応答されたシーケンス番号のうちの１つが、該第１のパケット系列のうちの対応する１つの該増加するシーケンス番号より大きい場合、パケットの損失を示すステップと
   をさらに含む、請求項１に記載の方法。
4. 開始シーケンス番号、終了シーケンス番号、および送信サイクル番号を包含する選択的確認応答を送信するステップをさらに含む、請求項１に記載の方法。
5. パケットの損失を検出するステップと、
   該パケットの損失の検出時に、損失検出時点で確認応答されていないパケットの数を記録するステップと、
   ピア受信機のアウトオブオーダ・バッファ内にある次のパケットのシーケンス番号を包含する確認応答を受信するステップと、
   該受信したシーケンス番号が、該損失検出時点で確認応答されていないすべてのパケットの確認応答を示しているか否かを判断するステップと
   をさらに含む、請求項１に記載の方法。

Images