JP2010022001A - トンネルのトランスポートチャネル上のデータストリームの送信を管理する方法、対応するトンネル終点及びコンピュータ読み取り可能な記憶媒体 - Google Patents
トンネルのトランスポートチャネル上のデータストリームの送信を管理する方法、対応するトンネル終点及びコンピュータ読み取り可能な記憶媒体 Download PDFInfo
- Publication number
- JP2010022001A JP2010022001A JP2009162185A JP2009162185A JP2010022001A JP 2010022001 A JP2010022001 A JP 2010022001A JP 2009162185 A JP2009162185 A JP 2009162185A JP 2009162185 A JP2009162185 A JP 2009162185A JP 2010022001 A JP2010022001 A JP 2010022001A
- Authority
- JP
- Japan
- Prior art keywords
- tunnel
- acknowledgment
- stream
- packet
- loss
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/19—Flow control; Congestion control at layers above the network layer
- H04L47/193—Flow control; Congestion control at layers above the network layer at the transport layer, e.g. TCP related
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Communication Control (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
【課題】トンネルの輻輳検出時、伝送ビットレートの管理を制御できるトランスポートチャネル上のデータストリームの送信を管理する方法を提供する。
【解決手段】送信側デバイスから受信側デバイスに送信される各ストリームの送信は、トランスポートプロトコルに従って確認応答と共にトランスポートチャネル上に実行され、送信側デバイス及び受信側デバイスのうち、一方のデバイスに接続される第１のサブネットワーク及び、他方のデバイスに接続される第２のサブネットワークにそれぞれ接続される第１のトンネル終点と第２のトンネル終点との間に実現され、第１のトンネル終点により、トンネルのトランスポートチャネル上のパケットの損失を検出し、損失によりブロックされたパケットを有するストリームを識別し、識別されたストリームに対して、損失によりブロックされたパケットを送信した送信側デバイスに、トンネル上に確認応答を生成及び送信する。
【選択図】図６
【解決手段】送信側デバイスから受信側デバイスに送信される各ストリームの送信は、トランスポートプロトコルに従って確認応答と共にトランスポートチャネル上に実行され、送信側デバイス及び受信側デバイスのうち、一方のデバイスに接続される第１のサブネットワーク及び、他方のデバイスに接続される第２のサブネットワークにそれぞれ接続される第１のトンネル終点と第２のトンネル終点との間に実現され、第１のトンネル終点により、トンネルのトランスポートチャネル上のパケットの損失を検出し、損失によりブロックされたパケットを有するストリームを識別し、識別されたストリームに対して、損失によりブロックされたパケットを送信した送信側デバイスに、トンネル上に確認応答を生成及び送信する。
【選択図】図６
Description
本発明は、通信ネットワークの分野に関する。
特に、本発明は、主通信ネットワークによりサポートされるトンネルのトランスポートチャネル上のデータストリームの送信を管理する技術に関する。
一方では高ビットレートのインターネットの大衆化が、他方ではネットワーク接続性を有する消費者向け音声映像機器の出現が、ユーザ行動の新しい形態を作り出すであろう。これらの新しい形態の行動は、「永続リンク」グループと呼ぶ共通の関心を有するグループ（即ち、余暇、家族等の共通の関心）に属する個人の登場に確実に関係する。これらのグループは、同一の関心分野を有する他の個人とのほぼ永続的な接続をセットアップすることにより、少なくとも音声及び映像通信の何れかをセットアップし、全ての種類の情報（音声、映像、写真、テキスト等）を共有する。
仮想プライベートネットワーク（ＶＰＮ）の技術は、この要望に対する価値ある解決策を提供している。この技術により、同一の関心分野を共有する個人間でリアルタイムの透過的なセキュリティ保護された通信が可能になるが、それと同時に、信頼性は低いが安価なインターネットインフラストラクチャを使用する。
透過的に通信し且つ転送不可能なアドレスの必要性を克服するために、ＶＰＮは、トンネルと呼ばれるものを作成するトンネリングとして周知の特定の種類のカプセル化を使用する。これは、カプセル化プロトコルＣを使用してＢレベルのプロトコル（転送又は搬送プロトコル）にＡレベルのプロトコル（組み込み又は搬送又はパッセンジャープロトコル）をカプセル化することからなる。従って、トランスポートプロトコルＢは、パッセンジャープロトコルＡをペイロードデータであるかのように処理する。
以下に詳細に説明する図３は、レベル２のＶＰＮにおけるパケットカプセル化、即ち、レベル２トンネル（レベル２トンネルは、パッセンジャープロトコルが各レイヤ及びそれらのレイヤの対話により提供されるサービスを記述するＩＳＯモデルのレイヤ２のプロトコルであることを意味する）におけるカプセル化の一例を示す図である。
トンネリングは、ネットワークプロトコルをサポートしないネットワーク上でネットワークプロトコルを転送するために使用される。また、トンネリングは、プライベートアドレス指定等の種々のＶＰＮ機能を提供するために使用される。
トンネリング技術は、リモートクライアントアクセスを伴う機能、及びホームローカルエリアネットワーク（ＬＡＮ）により益々使用されるようになってきている。
本明細書の以下の説明において、ＯＳＩモデルのトランスポートプロトコルＢのレベルがトランスポート層のレベル（ＩＳＯモデルのレベル４のトランスポート層）に等しいレベル２、又はレベル３トンネルを単なる一例として考慮する。本発明の説明は限定的なものではなく、ＯＳＩモデルのトランスポートプロトコルＢのレベルがより低くても良く（イーサネットキャリアを有するトンネルの場合）又はより高くても良い（時間及びＨＴＴＰキャリアを有する場合）ことは明らかである。
２つの独自のＬＡＮの結合により形成される仮想プライベートネットワーク（ＶＰＮ）を作成するために、トンネリング技術は、２つのＬＡＮを相互接続するために頻繁に使用される。セキュリティ保護されたＶＰＮは、転送データの秘密性を保証するための暗号化／認証アルゴリズムを含む。トンネリング技術に基づく一般的なＶＰＮ構成を図１（以下に詳細に説明する）に示す。この例において、トンネル終点（ＴＥＰ）はゲートウェイに組み込まれない。トンネルは、２つのトンネル終点間にセットアップされ、リモートＬＡＮに接続される装置に送出される各パケット（フレームとも呼ぶ）は、ローカルトンネル終点によりカプセル化され、リモートトンネル終点に送出される。リモートトンネル終点はそれを非カプセル化し、リモートＬＡＮに送出する。トンネルにより相互に接続されるＬＡＮの装置から見て、それらの装置は仮想的に同一のＬＡＮに接続される。トンネルの使用は接続されたＬＡＮの装置に対して透過的であるため、トンネルを介する２つの装置間の通信は終点間通信と呼ばれる。
従来技術において、使用されるのは、主にＩＰ又はインターネットプロトコル（レイヤ３）又はＴＣＰ（伝送制御プロトコル）／ＵＤＰ（ユーザデータグラムプロトコル）（レイヤ４）である。ＩＰを使用するトンネリング技術がネットワークアドレス変換（ＮＡＴ）機構を考慮できず、それらの技術が図１の一般的なトンネリング構成に完全に準拠しないため、以下の説明においては、レイヤ４（トランスポート層）、即ち、ＴＣＰ又はＵＤＰに基づく解決策を考慮する（単なる一例として）。
ＴＣＰプロトコルの動作の原理を提示する付録において説明するように、ＴＣＰプロトコル（ＩＥＴＦ規格ＲＦＣ７９３により規定される）は、輻輳制御及び再送機構に基づくＡＲＱ（自動再送要求）プロトコルであるため、各パケットをその宛先に配信することを保証する。
ＵＤＰプロトコルは、フレームの順番を考慮せず且つ確認応答を管理しない非常に単純で高速なプロトコルである。
ここで規定されているように、ＴＣＰプロトコルは、待ち時間が長い、低速リンク及び高速リンク、或いは変動する誤差率を持つリンクを含む広範囲なネットワーク通信環境において動作し且つ融通性があるように設計された。ＴＣＰプロトコルは種々の環境で動作するが、それらの性能レベル（特に帯域幅）は使用される各通信リンクの特性により影響を受ける。帯域幅に関するＴＣＰプロトコルの性能は、ルーティング時間が非常に長く、少なくとも誤差率が高くなる環境において悪影響を受ける。
拡張プロキシ概念又はＲＦＣ３１３５規格に基づくＰＥＰ（プロキシ拡張プロトコル）タイプの概念は、インフラストラクチャの性能を向上するために使用される。ＲＦＣ３１３５規格は、サーバとクライアントとの間のＴＣＰストリームのルーティング経路上のネットワーク装置に埋め込まれるデータストリーム送信を向上するための種々の機構（以下においてＰＥＰ機構と呼ばれる）を記述する。以下に説明するように、ＰＥＰシステムは、ＴＣＰストリーム輻輳の制御に作用するように各環境に特殊化される。
インターネットの場合、接続は一般に「ベストエフォート」型である。即ち、これらの接続は宛先まで情報を搬送するために可能な全てのことを行うが、ある特定のレベルのサービス品質（ＱｏＳ）を保証しない。従って、ＶＰＮ通信の環境において、トンネルのトランスポート層は送信容量の大きな変動の影響を受ける。
従来、このトンネルのパッセンジャーＴＣＰストリームは、終点間輻輳制御を実行する。即ち、２つの通信デバイスは、データがサーバデバイス（以下では、送信デバイスとも呼ぶ）からクライアントデバイス（以下では、受信デバイスとも呼ぶ）に送出される時のビットレートを判定する際に、共に動作する。しかし、送信デバイスは、トンネルのストリームの転送の条件下で利用可能な情報を有し、このトンネルは送信デバイスと受信デバイスから見て透過的である。受信デバイスにセットアップされた終点間輻輳制御を介して取得される情報により、送信デバイスはトンネルにおける転送の条件に不適切であり且つ不必要な再送又は利用可能な帯域幅の不十分な活用により帯域幅の消費を増加させるような判定を行う。
ＰＥＰ機構は、既定の時点でトンネルの本質的な制限に応じてトンネルからのパッセンジャーＴＣＰストリームに対する輻輳制御に影響を及ぼすためにセットアップされる。
Elaoud,M及びRamanathan,Pの「TCP-SMART: a technique for improving TCP performance in a spotty wide band environment」（IEEE Communications, 2000. ICC 2000；1783〜1787ページ第3巻；Digital Object Identifier 10.1109/ICC.2000.853814）
例えば、インターネットなどのワイドエリアネットワーク（以下、ＷＡＮと呼ぶ）におけるＶＰＮトンネルの一時的な輻輳の間、高信頼確認応答に基づく通信プロトコルを使用するこのトンネルのキャリア（即ち、例えばＴＣＰプロトコルに従うこのトンネルのトランスポートチャネル）は自動再送に入る。これは、トンネルのトランスポートチャネルで搬送される全てのストリーム（トンネルキャリアのカプセル化パケット、即ち、埋め込みパケットの損失に直接関係しないストリームであっても）を保留する効果がある。実際には、いくつかのパッセンジャーストリームは、トンネルの同一トランスポートチャネル（即ち、同一通信セッション）により搬送される。更に構成上、ＴＣＰプロトコルはパケットの到着順を保証し、このトンネルの損失パケットに後続するトンネルのパケットを受信側エンティティ（この場合はリモートトンネル終点）に先に提供しない。換言すると、キャリアのデータシーケンス番号がトンネルの損失パケットに対応する番号より大きい受信パッセンジャーパケットのリモートＬＡＮへの転送は行われない。それらの格納されたパケットのブロック解除は損失パケットが送信側トンネル終点により再送され且つ受信側トンネル終点により受信された場合にのみ行われる。
損失パケットの再送フェーズは、トンネルでのラウンドトリップ時間（又はＲＴＴ）を必要とし、パケットに対する従来のデータ／確認応答（ＤＡＴＡ／ＡＣＫ）転送フェーズを補足することが分かる。
インターネットトンネルにおけるＲＴＴは非常に長いため（ＬＡＮの１０〜１００倍）、このＲＴＴがリモートクライアントとサーバとの間のトンネルにより搬送される接続（即ち、トンネルのパッセンジャーである接続）の挙動を大きく左右することは明らかである。
従って、ＶＰＮの一時的な輻輳の間、全てのパッセンジャー接続は、トンネルのＲＴＴの２倍の遅延、即ち、それらの接続に対する再送タイムアウト（以下では、ＲＴＯと呼ぶ）の臨界値に近い遅延の影響を受ける。
ＷＡＮの変動に依存し、ＶＰＮトンネルセクションで同報通信するＴＣＰサーバでは、伝送ビットレートの低下を招くＲＴＯが満了になることが分かる。尚、遅延が長くなると、低下前に初期の伝送ビットレートに回復するのにかかる時間が長くなるため、それらのサーバのビットレートの増加は受信者への搬送時間（ＲＴＴ）に直接依存する。更に、損失カプセル化パケットに対するトンネルでの再送が引き継がれるにもかかわらず、再送はＴＣＰサーバがトンネルのパッセンジャーストリームを送出することにより行われる。
その結果、ＴＣＰトンネルにおける最小損失は、このトンネルの埋め込みＴＣＰ接続の終点間性能に悪影響を及ぼす。
ＰＥＰ機構は、主に輻輳制御に適用され、またＴＣＰ接続により利用される種々のネットワークセグメントにおける再送の問題に適用される。トンネルのキャリア（ＴＣＰトランスポートチャネル）におけるカプセル化パケット（ＷＡＮパケット）の損失の上記問題を克服するために、パケットの一時的な記憶又はバッファリングに基づいてＰＥＰ機構はキャッシュメモリに更なるデータを格納できる。しかし、これの効果は時間的に制限される。
ＰＥＰ機構は、トンネルにより搬送される接続に対するタイムアウト現象を遅延できるだけであり、これでは不十分である。
従って、一時的に輻輳するＴＣＰトンネルで搬送されるその接続のＲＴＯタイムアウトの問題を克服し、ローカルＬＡＮからリモートＬＡＮへ、このトンネルを通して移動するデジタルコンテンツを搬送するＴＣＰサーバの伝送ビットレートを制御する効率的な方法を提案する必要があり、これは本発明の重要な目的である。
不安定な環境（インターネット又は無線リンク等）においてＴＣＰ性能を向上する２つのカテゴリの原理が存在する。即ち、終点間プロトコル及び分割接続プロトコルである。後者のカテゴリは、そのプロトコルが終点間クライアントＴＣＰ接続をサポートするトンネリングの本質的な原理に違反するため、本発明の問題に対して考慮されない。後者のカテゴリのプロトコルの原理は、異機種ネットワークの部分毎に特徴付けられた独自の接続を有することである。
殆どの終点間接続プロトコル原理は、異機種ネットワーク間（一般に、ＷＡＮの場合はトンネル終点間又は無線ネットワークの場合は基地局間）のインフラストラクチャ機器へのＰＥＰ（性能拡張プロキシ）タイプの専用エージェントの追加に依存する。
次に、ＴＣＰトンネリングのＴＣＰの特定の影響を克服することを可能にする２つの従来技術を説明する。
米国特許出願公開第2006/0002301A1号明細書（INTEL CORP. USの「Transferring TCP Packets」）において、第１の従来技術が説明される。この特許文献は、ＴＣＰトンネルを介して２つのリモートＬＡＮの装置間にセットアップされるＴＣＰ接続とそれらの２つのＬＡＮとを接続するＴＣＰトンネルに関する。
トンネルにおいて損失がある場合にデータの二重の再送（トンネルキャリアによる再送及びパッセンジャーＴＣＰストリームによる再送に対応する）を回避するために、各トンネル終点にＰＥＰ一時記憶機構を実現し、いずれかのトンネル終点で有効に受信されたパケットに関する情報の２つのトンネル終点間における交換を更に可能にすることが提案される。第１の従来の交換処理において、トンネルにおける損失は以下の効果の組合せによりＬＡＮの装置から隠蔽される。第１に、自動再送が損失データに対してトンネルにおいて実行され、第２に、一時記憶がその再送に必要な遅延を部分的に隠す。
これにより、終点間の再送（パッセンジャーＴＣＰストリーム）をなくし、トンネルキャリアにより単一の再送を行うという利点を得る。利用可能なキャッシュメモリは、再送の各ネットワークセグメント（ローカルＬＡＮ、ＷＡＮ、リモートＬＡＮ）におけるローカル管理を提供する。この機構は、このトンネルにおいて損失があり（必要な再送時のみのトンネルの帯域幅の効率的な使用）且つリモートネットワークにおいて損失がある（ローカルな再送）場合、トンネルにおける性能の問題に対処する。
しかし、提案された機構は、リモートクライアント（リモートＬＡＮに接続される）によるデータの確認応答を待つローカルＬＡＮのＲＴＯタイムアウトの影響の問題を解決しない。
第１の従来技術において実現されるように、一時記憶ゾーンが送信時間に関してＷＡＮにおける損失を隠すことを望むことは無益である。一時記憶ゾーン（各トンネル終点における）からパケットを搬送するのにかかる時間の変動は、ＴＣＰサーバがＲＴＯを認識するのにかかる時間を長くできるだけである（上述の特許文献には記載されていない）。
ＩＥＥＥの文献であるElaoud,M及びRamanathan,Pの「TCP-SMART: a technique for improving TCP performance in a spotty wide band environment」（IEEE Communications, 2000. ICC 2000；1783〜1787ページ第3巻；Digital Object Identifier 10.1109/ICC.2000.853814）において、第２の従来技術が説明される。
この文献は、不安定な環境（リンクの切断が頻繁にある無線リンクにおける）を移動する終点間ＴＣＰ接続の性能を向上するために、ローカル再送及び重複確認応答又は重複ＡＣＫのフィルタリングを実行する役割を果たすスヌープ機構を説明する。
この第２の従来技術の目的は、無線リンクの切断中のサーバのＲＴＯの満了の回数を低減することである。これらの切断は、リモートＴＣＰクライアントからの確認応答の到着を防止する。
無線基地局のＰＥＰエージェントは、各ＴＣＰ接続を解析し、無線リンクで送出されるデータを一時的に格納する。このデータの確認応答がリモートＴＣＰクライアントからエージェントにより受信される場合、それらのパケットはキャッシュから削除される。ある特定の期間中に確認応答が受信されない場合又は誤りの指示が受信された（重複確認応答又は重複ＡＣＫ）場合、それらのデータはクライアントに再送される。これが従来のＰＥＰ記憶機構の挙動である。
この第２の従来技術は、ＴＣＰからの送信を停止するために０の「確認応答ウィンドウ」又は「広告ウィンドウ」フィールドを有する有線ネットワークのＴＣＰサーバ用の重複確認応答（重複ＡＣＫ）を生成する機能を更に追加する。ＴＣＰサーバは中断モードであり、このモードから解放するためにクライアントからの新しい確認応答（厳密に０より大きい広告ウィンドウフィールドを有する）を保留にする。
この第２の従来技術の目的は、ＲＴＴが非常に大きいＷＡＮ環境に適応されない不連続な無線リンクにおける通信呼び出しに関して本発明と同様の問題を解決すること（即ち、ＴＣＰサーバのＲＴＯの満了の現象を防止すること）である。実際には、無線キャリアのある程度長い物理的切断中のバッファの輻輳を防止するために送信中サーバを停止する原理は、不連続な無線リンクにおける通信の場合には価値があるが、１つのパケットに制限される損失がこのトンネルの停止を全く示さない（更に、トンネルが損失データを再送するためにアクティブなままである）ＶＰＮトンネルの場合には価値がない。尚、ＷＡＮ（ＷＡＮ上でトンネルがセットアップされる）における搬送の速度は、ＬＡＮ又はＷＬＡＮ（無線ＬＡＮ）より非常に遅く、ＷＡＮの能力の不十分な活用は、搬送時間に関する損害が大きい。
上述のように、従来のＰＥＰ機構は、主に一時データ記憶の原理に基づいて準備される。これは、データが少なくとも２サイクルのＲＴＴの期間格納される必要があるため、ＷＡＮ（ＷＡＮにおいてトンネルがセットアップされる）における送信に関係する実質的なメモリリソースを示す。これは、ＴＣＰ ＶＰＮトンネルがセットアップされたＷＡＮにおいてトンネルのキャリアが浮遊パケットを再送する役割を自動的に果たすことが確実であるため、そのトンネルに更に大きな損害を与えるだけである。第２の従来技術により提案されたデバイスは更に複雑であるが、インターネットにおけるＴＣＰトンネルの送信能力から最良の可能な利点を引き出すように適応されない。
従って、従来技術は、リソースに関して低コストである技術を有さず、サーバ及びクライアントに対して透過的であり（終点間ＴＣＰ接続の上述の原理に準拠する）且つＶＰＮトンネルにおける突発的な損失に適応されるＴＣＰサーバの内部ＴＣＰ管理制御の習得を可能にする。
本発明は、少なくとも１つの実施形態において、特に従来技術の種々の欠点を克服することである。
更に詳細には、本発明の少なくとも１つの実施形態の目的は、ＴＣＰサーバから送信ストリームの最小限の帯域幅を使用可能にするトンネルの輻輳の検出時（データの損失後に且つ／又はこのトンネルの待ち時間が１回のみ増加している間に再送フェーズへトンネルが推移する時）、１つ以上の送信機デバイス（例えば、ＴＣＰサーバ）の伝送ビットレートの管理を制御できるトンネルのトランスポートチャネルにおけるデータストリーム送信を管理する技術を提供することである。
更に、本発明の少なくとも１つの実施形態の目的は、例えば送信側（サーバ）デバイス及び受信側（クライアント）デバイスのＴＣＰ／ＩＰスタックの任意の変更を必要としないこの種の技術を提供することである。
本発明の少なくとも１つの実施形態の更に別の目的は、送信側（サーバ）デバイス及び受信側（クライアント）デバイスに対して完全に透過的であるこの種の技術を提供することである。
本発明の少なくとも１つの実施形態の更に別の目的は、制限されたメモリリソースを必要とするこの種の技術を提供することである。
本発明の少なくとも１つの実施形態の追加の目的は、実現するのに単純であり且つコストが安いこの種の技術を提供することである。
本発明の特定の一実施形態は、トンネルのトランスポートチャネル上のデータストリームの送信を管理する方法であって、各ストリームの送信はパケットによりスケジュールされるトランスポートプロトコルに従って確認応答と共に前記トランスポートチャネル上で実行され、前記トンネルは第１のサブネットワーク及び第２のサブネットワークにそれぞれ接続される第１のトンネル終点と第２のトンネル終点との間に実現され、各ストリームは送信側デバイスから受信側デバイスに送信され、前記送信側デバイス及び前記受信側デバイスのうち、一方のデバイスは第１のサブネットワークに接続され、他方のデバイスは第２のサブネットワークに接続され、前記第１のトンネル終点により実行され、前記方法は、
前記トンネルのトランスポートチャネル上のパケットの損失を検出する工程と、
前記損失によりトンネルのトランスポートチャネル上でブロックされた少なくとも１つのパケットを有する少なくとも１つのストリームを識別する工程と、
前記少なくとも１つの識別されたストリームに対して、前記損失によりブロックされたパケットを送信した送信側デバイスに、前記トンネル上に少なくとも１つの確認応答を生成及び送信する工程とを有する。
前記トンネルのトランスポートチャネル上のパケットの損失を検出する工程と、
前記損失によりトンネルのトランスポートチャネル上でブロックされた少なくとも１つのパケットを有する少なくとも１つのストリームを識別する工程と、
前記少なくとも１つの識別されたストリームに対して、前記損失によりブロックされたパケットを送信した送信側デバイスに、前記トンネル上に少なくとも１つの確認応答を生成及び送信する工程とを有する。
従って、この特定の実施形態において、本発明は、送信側デバイス（サーバ）のＲＴＯの満了の現象を防止するために予防修正（トンネル入力トンネル終点による「偽の」確認応答の生成）が適用される斬新な発明の方法に依存する。
第２の従来技術のように送信側デバイスを停止するのではなく、送信側デバイスは送出されたデータの搬送が制御され且つ残りのデータを送信し続けられると確信できる。
トンネルの帯域幅は、ペイロードデータ、即ち、トンネルのパッセンジャーストリーム（更に、バーストである場合が多い）の自動再送の取消しのために節約される。
この技術は、送信側デバイス（サーバ）及び受信側デバイス（クライアント）に対して完全に透過的である。送信側デバイス（サーバ）及び受信側デバイス（クライアント）のＴＣＰ／ＩＰプロトコルスタック等のプロトコルスタックの変更はない。
この技術は、メモリのオーバーフローの可能性がないため（ＰＥＰ格納機構のため）、制限されたメモリリソースを必要とする。
少なくとも１つの既定の識別されたストリームに対して、前記少なくとも１つの生成された確認応答は、前記損失によりブロックされた前記識別されたストリームの第１のパケットに先行するパケットの確認応答であるのが有利である。損失が検出されたパケットが属する識別されたストリームに対して、前記損失によりブロックされた第１のパケットは、損失の検出に続いて前記トンネルのトランスポートチャネルに上に再送されるパケットであると見なされる。
従って、第１のトンネル終点により生成される確認応答の送信により、接続が依然として有効であり且つ考慮される各ストリームに対してパケットの搬送の遅延以外に特定の問題が存在しないことを、確認応答を受信する送信側デバイスに通知する。
少なくとも１つの既定の識別されたストリームに対して、少なくとも１つの確認応答を生成及び送信する前記工程は、
前記既定の識別されたストリームを送信する送信側デバイスと関連付けられる再送タイムアウトの期間を推定する関数及び前記損失によりブロックされる前記識別されたストリームの第１のパケットに先行する前記パケットのトンネル終点による処理の処理瞬間の関数として第１の確認応答を送出する第１の送出瞬間ｔ１を判定する工程と、
前記第１の送出瞬間ｔ１に前記第１の確認応答を送信する工程とを有するのが有利である。
前記既定の識別されたストリームを送信する送信側デバイスと関連付けられる再送タイムアウトの期間を推定する関数及び前記損失によりブロックされる前記識別されたストリームの第１のパケットに先行する前記パケットのトンネル終点による処理の処理瞬間の関数として第１の確認応答を送出する第１の送出瞬間ｔ１を判定する工程と、
前記第１の送出瞬間ｔ１に前記第１の確認応答を送信する工程とを有するのが有利である。
従って、修正は送信側デバイス別に行われる。実際には、これはトンネルのアクティビティ及び考慮されるストリームの特性に依存する。
前記第１の送出瞬間ｔ１は、t1 = t0 + RTO' - Δにより定義されるのが有利である。式中、
ｔ０は、前記損失によりブロックされる前記識別されたストリームの第１のパケットに先行する前記パケットの前記第１のトンネル終点における処理の前記処理瞬間であり、
ＲＴＯ’は、前記既定の識別されたストリームを送信する送信側デバイスと関連付けられる再送タイムアウトの期間の前記推定であり、
Δは、予め定められた安全余裕度である。
ｔ０は、前記損失によりブロックされる前記識別されたストリームの第１のパケットに先行する前記パケットの前記第１のトンネル終点における処理の前記処理瞬間であり、
ＲＴＯ’は、前記既定の識別されたストリームを送信する送信側デバイスと関連付けられる再送タイムアウトの期間の前記推定であり、
Δは、予め定められた安全余裕度である。
このように、第１の送出瞬間ｔ１の判定は単純である。
少なくとも１つの既定の識別されたストリームに対して、少なくとも１つの確認応答の生成及び送信の前記工程は、
ｔ１が１回目の繰り返しの場合に前記第１の送出瞬間であり又は２回目以降の各繰り返しの場合に先行する繰り返しにおいて判定される新しい送出瞬間ｔ２である時、t2 = t1 + RTO' - Δにより定義される新しい確認応答を送出する新しい送出瞬間ｔ２を判定する工程と、
前記新しい送出瞬間ｔ２において前記新しい確認応答を送信する工程との少なくとも１回の繰り返しを有するのが有利である。
ｔ１が１回目の繰り返しの場合に前記第１の送出瞬間であり又は２回目以降の各繰り返しの場合に先行する繰り返しにおいて判定される新しい送出瞬間ｔ２である時、t2 = t1 + RTO' - Δにより定義される新しい確認応答を送出する新しい送出瞬間ｔ２を判定する工程と、
前記新しい送出瞬間ｔ２において前記新しい確認応答を送信する工程との少なくとも１回の繰り返しを有するのが有利である。
従って、予防策として、既定の識別されたストリームに対して第１のトンネル終点において別の確認応答を生成しようとする。第１のトンネル終点により生成される第１の確認応答はトンネルにおけるパケットの単純な損失の影響を軽減するが、トンネルが復元されるために必要な１サイクルのＲＴＴより長い期間を必要とする場合を考慮しなければならない。
このように、新しい各送出瞬間ｔ２は容易に判定される。この場合も、修正は送信側デバイス別に行われる。
RTO' = 2.RTTであるのが有利であり、ＲＴＴはトンネルにおけるラウンドトリップ時間の測定値である。
従って、計算は単純化される。尚、トンネルのＲＴＴがＬＡＮのＲＴＴより非常に長いため、送信側デバイスと受信側デバイスとのＲＴＴの期間はトンネルのＲＴＴの期間により近似される。
少なくとも１つの既定の識別されたストリームに対して、少なくとも１つの確認応答を生成及び送信する前記工程において、トンネルのトランスポートチャネルを通過中であり且つ前記損失によりブロックされる前記既定の識別されたストリームのパケット数が前記既定の識別されたストリームに対して前記第１のトンネル終点により生成及び送信される確認応答の数より多いという第１の条件が検証される場合にのみ、確認応答は生成及び送信されるのが有利である。
送信側デバイスが送信したパケットより多くの確認応答を受信しないため（例えばＴＣＰにおいて、確認応答はサーバにより送信されるパケットに応答してのみクライアントにより生成される）、この第１の条件は、パケットにより命令されるトランスポートプロトコル及び確認応答（例えば、ＴＣＰプロトコル）に準拠することを保証する際に送信側デバイス（サーバ）に対する透過性を保証する。
少なくとも１つの既定の識別されたストリームに対して、少なくとも１つの確認応答を生成及び送信する前記工程において、前記既定の識別されたストリームに対して前記第１のトンネル終点により生成及び送信される確認応答の数が前記既定の識別されたストリームを送信する送信側デバイスに対してパケット損失を示す予め定められた閾値以下であるという第２の条件が検証される場合にのみ、確認応答は生成及び送信されるのが有利である。
従って、本発明は、送信側デバイス（サーバ）が第１のトンネル終点により生成される連続する確認応答の生成をパケット損失と解釈しないようにし、従って、送信側デバイスが損失されると考えられるパケットを再送しないようにする。
有利な特徴によると、少なくとも１つの既定の識別されたストリームに対して、方法は、前記第１のトンネル終点が確認応答を既に生成及び送信した前記既定の識別されたストリームの受信側デバイスからトンネルを介して到達する確認応答をフィルタリングする工程を有する。
従って、第１のトンネル終点による偽の確認応答の生成により及ぼされる副次的影響は、送信側デバイス（サーバ）において接続中の状態遷移機械を妨害しないように管理される。例えば、リモート受信側デバイス（クライアント）がリモートＬＡＮにおける容易な非順序付けのために「真の」重複確認応答（重複ＡＣＫ）を送出し且つ第１のトンネル終点が１つ又は２つの「偽の」重複確認応答を既に生成及び送出している場合、送信側デバイス（サーバ）が再送モードにされる（回避されるＴＣＰ送信側ウィンドウ関数の低下を伴う）原因となる第３の重複確認応答を受信しないように「真の」重複確認応答をフィルタリング（即ち、検出及び破棄）する必要がある。
別の実施形態において、本発明は、通信ネットワークからダウンロード可能であり且つ／又はコンピュータ読み取り可能な媒体に記録され且つ／又はプロセッサにより実行可能であるコンピュータプログラム製品に関する。このコンピュータプログラム製品は、前記プログラムがコンピュータにおいて実行される場合に上述の方法（種々の実施形態のうちの１つにおける）を実現するためのプログラムコード命令を含む。
別の実施形態において、本発明は、上述の方法（種々の実施形態のうちの任意の１つにおける）を実現するために、コンピュータにより実行可能な命令の集合を含むコンピュータプログラムを格納するコンピュータ可読記憶媒体に関する。
特定の一実施形態において、本発明は、トンネルのトランスポートチャネルに上のデータストリームの送信の管理を可能にする第１のトンネル終点であって、各ストリームの送信はパケットによりスケジュールされるトランスポートプロトコルに従って確認応答を使用して前記トランスポートチャネルに対して実行され、トンネルは第１のサブネットワーク及び第２のサブネットワークにそれぞれ接続される第１のトンネル終点と第２のトンネル終点との間に実現され、各ストリームは送信側デバイスから受信側デバイスに送信され、前記送信側デバイス及び前記受信側デバイスのうち、一方のデバイスは第１のサブネットワークに接続され、他方のデバイスは第２のサブネットワークに接続され、前記第１のトンネル終点は、
前記トンネルのトランスポートチャネル上のパケットの損失を検出する手段と、
前記損失によりトンネルのトランスポートチャネル上でブロックされた少なくとも１つのパケットを有する少なくとも１つのストリームを識別する手段と、
前記少なくとも１つの識別されたストリームに対して、前記損失によりブロックされたパケットを送信した送信側デバイスに、前記トンネル上に少なくとも１つの確認応答を生成及び送信する手段とを有する。
前記トンネルのトランスポートチャネル上のパケットの損失を検出する手段と、
前記損失によりトンネルのトランスポートチャネル上でブロックされた少なくとも１つのパケットを有する少なくとも１つのストリームを識別する手段と、
前記少なくとも１つの識別されたストリームに対して、前記損失によりブロックされたパケットを送信した送信側デバイスに、前記トンネル上に少なくとも１つの確認応答を生成及び送信する手段とを有する。
少なくとも１つの既定の識別されたストリームに対して、前記少なくとも１つの生成された確認応答は、前記損失によりブロックされた前記識別されたストリームの第１のパケットに先行するパケットの確認応答であるのが有利である。損失が検出されたパケットが属する識別されたストリームに対して、前記損失によりブロックされた第１のパケットは、損失の検出に続いて前記トンネルのトランスポートチャネル上で再送されるパケットであると見なされる。
少なくとも１つの確認応答を生成及び送信する前記手段は、
少なくとも１つの既定の識別されたストリームに対して、前記既定の識別されたストリームを送信する送信側デバイスと関連付けられる再送タイムアウトの期間を推定する関数及び前記損失によりブロックされる前記識別されたストリームの第１のパケットに先行する前記パケットの前記トンネル終点による処理の処理瞬間の関数として第１の確認応答を送出する第１の送出瞬間ｔ１を判定する手段と、
前記第１の送出日時ｔ１に前記第１の確認応答を送信する手段とを有するのが有利である。
少なくとも１つの既定の識別されたストリームに対して、前記既定の識別されたストリームを送信する送信側デバイスと関連付けられる再送タイムアウトの期間を推定する関数及び前記損失によりブロックされる前記識別されたストリームの第１のパケットに先行する前記パケットの前記トンネル終点による処理の処理瞬間の関数として第１の確認応答を送出する第１の送出瞬間ｔ１を判定する手段と、
前記第１の送出日時ｔ１に前記第１の確認応答を送信する手段とを有するのが有利である。
従って、修正は送信側デバイス別に行われる。実際には、これはトンネルのアクティビティ及び考慮されるストリームの特性に依存する。
前記第１の送出瞬間ｔ１は、t1 = t0 + RTO' - Δにより定義されるのが有利である。式中、
ｔ０は、前記損失によりブロックされる前記識別されたストリームの第１のパケットに先行する前記パケットの前記第１のトンネル終点における処理の前記処理瞬間であり、
ＲＴＯ’は、前記既定の識別されたストリームを送信する送信側デバイスと関連付けられる再送タイムアウトの期間の前記推定であり、
Δは、予め定められた安全余裕度である。
ｔ０は、前記損失によりブロックされる前記識別されたストリームの第１のパケットに先行する前記パケットの前記第１のトンネル終点における処理の前記処理瞬間であり、
ＲＴＯ’は、前記既定の識別されたストリームを送信する送信側デバイスと関連付けられる再送タイムアウトの期間の前記推定であり、
Δは、予め定められた安全余裕度である。
少なくとも１つの確認応答を生成及び送信する前記手段は、
ｔ１が１回目の繰り返しの場合に前記第１の送出瞬間であり又は２回目以降の各繰り返しの場合に先行する繰り返しにおいて判定される新しい送出瞬間ｔ２である時、少なくとも１つの識別されたストリームに対して、t2 = t1 + RTO' - Δにより定義される新しい確認応答を送出する新しい送出瞬間ｔ２を判定する手段と、
前記新しい送出瞬間ｔ２に前記新しい確認応答を送信する手段とを有し、それらの手段は少なくとも１回起動されるのが有利である。
ｔ１が１回目の繰り返しの場合に前記第１の送出瞬間であり又は２回目以降の各繰り返しの場合に先行する繰り返しにおいて判定される新しい送出瞬間ｔ２である時、少なくとも１つの識別されたストリームに対して、t2 = t1 + RTO' - Δにより定義される新しい確認応答を送出する新しい送出瞬間ｔ２を判定する手段と、
前記新しい送出瞬間ｔ２に前記新しい確認応答を送信する手段とを有し、それらの手段は少なくとも１回起動されるのが有利である。
RTO' = 2.RTTであるのが有利であり、ＲＴＴはトンネルにおけるラウンドトリップ時間の測定値である。
第１のトンネル終点は、
少なくとも１つの既定の識別されたストリームに対して、トンネルのトランスポートチャネルを通過中であり且つ前記損失によりブロックされる前記既定の識別されたストリームのパケット数が前記既定の識別されたストリームに対して前記第１のトンネル終点により生成及び送信される確認応答の数より多いという第１の条件を検証する第１の検証手段と、
前記第１の検証手段が肯定の検証を行った場合に前記少なくとも１つの既定の識別されたストリームに対して少なくとも１つの確認応答を生成及び送信する前記手段を起動する手段とを更に有するのが有利である。
少なくとも１つの既定の識別されたストリームに対して、トンネルのトランスポートチャネルを通過中であり且つ前記損失によりブロックされる前記既定の識別されたストリームのパケット数が前記既定の識別されたストリームに対して前記第１のトンネル終点により生成及び送信される確認応答の数より多いという第１の条件を検証する第１の検証手段と、
前記第１の検証手段が肯定の検証を行った場合に前記少なくとも１つの既定の識別されたストリームに対して少なくとも１つの確認応答を生成及び送信する前記手段を起動する手段とを更に有するのが有利である。
第１のトンネル終点は、
少なくとも１つの既定の識別されたストリームに対して、前記既定の識別されたストリームに対して前記第１のトンネル終点により生成及び送信される確認応答の数が前記既定の識別されたストリームを送信する送信側デバイスに対してパケット損失を示す予め定められた閾値以下であるという第２の条件を検証する第２の検証手段と、
前記第２の検証手段が肯定の検証を行った場合に前記少なくとも１つの既定の識別されたストリームに対して少なくとも１つの確認応答を生成及び送信する前記手段を起動する手段とを更に有するのが有利である。
少なくとも１つの既定の識別されたストリームに対して、前記既定の識別されたストリームに対して前記第１のトンネル終点により生成及び送信される確認応答の数が前記既定の識別されたストリームを送信する送信側デバイスに対してパケット損失を示す予め定められた閾値以下であるという第２の条件を検証する第２の検証手段と、
前記第２の検証手段が肯定の検証を行った場合に前記少なくとも１つの既定の識別されたストリームに対して少なくとも１つの確認応答を生成及び送信する前記手段を起動する手段とを更に有するのが有利である。
有利な特徴によると、第１のトンネル終点は、少なくとも１つの既定の識別されたストリームに対して、前記第１のトンネル終点が確認応答を既に生成及び送信した前記既定の識別されたストリームの受信側デバイスからトンネルを介して到達する確認応答をフィルタリングする手段を更に有する。
本発明の実施形態の他の特徴及び利点は、示される制限しない例として与えられる以下の説明及び添付の図面から明らかとなる。
本発明の全ての図面において、同一の要素及びステップは同一の図中符号により示される。
図１に、通信ネットワーク１０７（例えば、インターネット）を経由してローカルトンネル終点１０１とリモートトンネル終点１０２との間にトンネル１００を実現する仮想プライベートネットワーク（ＶＰＮ）の一般的な構成を示す。このトンネル１００は、２つのローカルネットワークであるＡＮ Ａ１０３及びＬＡＮ Ｂ１０４を接続する。ＬＡＮ１０３及び１０４の各々は、高ビットレートインターネットアクセス装置（ファイアウォールを組み込み可能なホームゲートウェイ）１０５及び１０６、ＰＣ型装置１０９及び１１１、デジタルメディア（音声、映像及び写真のデジタルメディア）を格納及び配信するためのサーバ１１０及び１１３、並びにデジタルメディアレンダリング装置１０８及び１１２を有する。トンネル終点は、デジタルテレビ受信機等の音声映像装置に組み込まれても良い。また、トンネル終点は、関連する機能を実行するプログラムの形式でＰＣ型装置に提供されても良い。
トンネル１００がセットアップされると、ＬＡＮ Ａ１０３に接続された装置１０８、１０９及び１１０は、ＬＡＮ Ｂ１０４に接続された装置１１１、１１２及び１１３と通信できる。例えば、ＬＡＮ Ａ１０３に接続されたクライアント１０８は、ネットワークＬＡＮ Ｂ１０４に接続されたサーバ１１３と通信できる。
図１は、１つのトンネルのみ有する単純な通信ネットワークを示すが、同一のトンネル終点が第１のＬＡＮをいくつかの他のＬＡＮに相互接続するようにいくつかのトンネル（同数のトンネル終点につながる）を管理してもよいことが理解される。更に、簡潔にするために、図にはインターネットルータ等のインターネットにおけるインフラストラクチャ装置を示していない。
装置１０８、１０９、１１０（ＬＡＮ Ｂ１０３に接続される）の１つから到着し且つトンネル１００に入るイーサネットフレームのルーティングについて、図２を参照して説明する。その目的のために、階層モデルが使用される。この階層モデルは、トンネル１００の実現に必要とされるプロトコル層を記述する。このモデルには、トンネルの使用以外の機能に必要なプロトコル要素は表さない。例えば、トンネル終点１０１がＵＰｎＰ装置に組み込まれる場合、ＵＰｎＰアーキテクチャと関連するプロトコル要素は示さない。
トンネル終点１０１は、装置１０８、１０９、１１０から到着するイーサネットフレームをルーティングするためにリンク層２０７に渡すイーサネット物理インタフェース２０８を有する。このルーティングは、トンネル終点を含む装置用のイーサネットフレームの場合にはネットワーク層２０６に向けて行われ、他のイーサネットフレームの場合にはブリッジ層２０９に向けて行われる。ブリッジ層２０９は、イーサネットフレームのフィルタリング及び１つ又は複数の適切なイーサネット出力ポートへのそれらフレームの中継等のイーサネットブリッジの従来の動作を実行する。ブリッジは、イーサネットインタフェース２０７及び少なくとも１つの仮想インタフェース２１０を有し、接続されたイーサネット制御器をシミュレートする。仮想インタフェース２１０は、インスタンス化された各トンネルを通過中に移動する必要のあるイーサネットフレームを与えられるアプリケーション２００によりインスタンス化されたトンネル毎に作成される。一般に、アプリケーション２００により表されるトンネルのカプセル化のプロトコルは、各トンネルを実現するのに必要な動作、その中でも特に構成、フィルタリング及びカプセル化（トンネルパケットの形成）の動作、並びにフレームの抽出を実行する。
仮想インタフェース２１０から受信されたフレームは、アプリケーション２００により処理された後、ＳＳＬプロトコル２０２及びＤＴＬＳプロトコル２０４によりそれぞれセキュリティ保護される高信頼ＴＣＰトランスポートプロトコル２０３又は低信頼ＵＤＰトランスポートプロトコル２０５にアプリケーションインタフェース又はソケット２０１を介してパケットの形式で渡される。
用語「高信頼転送モード」又は「高信頼トランスポートプロトコル」は、フレーム又はデータパケットを送出するデバイスが受信側デバイスへのフレーム又はデータパケットの配信に関する１つの情報を取得する転送モード又はプロトコルを意味すると理解される。そのようなモードの主な特徴は、フレーム又は１つのデータの配信の保証であり、送信側デバイスと受信側デバイスとの間の転送の待ち時間がないことである。以下において、用語「高信頼チャネル」は、データトランスポートプロトコル（このデータ自体は、判定されたトランスポートプロトコルに従うパケット又はフレームの形式をとることができる）を使用する２つのサブネットワーク（ローカルＬＡＮとも呼ばれる）間のトンネルのデータの転送のためのチャネルを意味すると理解される。
トンネルパケット２５０（図３）を形成するためのトランスポートプロトコルによる処理の後、このパケットはネットワーク層２０６に渡される。このように現在のパケットにより形成されるＩＰデータグラムは、リンク層２０７及び物理層２０８を介してＬＡＮに送信される。
トンネル１００から到着するフレームの受信は、上述で提示された経路とは逆のトンネル終点の経路に従う。
図３は、例えば図１のＬＡＮ Ａ１０３を通過中のイーサネットフレーム（図中符号２６０）の従来の形式の一例を示し、これは以下を含む。
−イーサネットヘッダフィールド（図中符号２６１）
−レベル２トンネルパケット（図中符号２５０）を転送する第１のＩＰデータグラム（図中符号２６２）自体
−ＦＣＳ（フレームチェックシーケンス）フィールド（図中符号２６３）
トンネルパケット２５０は以下の４つの部分を有する。
−レベル２トンネルパケット（図中符号２５０）を転送する第１のＩＰデータグラム（図中符号２６２）自体
−ＦＣＳ（フレームチェックシーケンス）フィールド（図中符号２６３）
トンネルパケット２５０は以下の４つの部分を有する。
−トランスポートプロトコルヘッダフィールド２５１（即ち、この例においてはＴＣＰ又はＵＤＰフィールド）
−カプセル化プロトコルのヘッダフィールド２５２（即ち、この例においてはＬ２ＴＰ又はＴＬＳであり、特にJ. Lau他の文献"IETF RFC3931「Layer two tunneling protocol - version 3 (L2TPv3)」2005年3月及び文献"IETF RFC2246「The TLS Protocol Version 1.0」において説明される）
−パッセンジャープロトコルのヘッダフィールド２５３（即ち、この例においてはイーサネット）
−送信元装置からの通過中に断片化が起こらなかった場合に、完全な第２のＩＰデータグラムを含むユーザデータフィールド２５４。
−カプセル化プロトコルのヘッダフィールド２５２（即ち、この例においてはＬ２ＴＰ又はＴＬＳであり、特にJ. Lau他の文献"IETF RFC3931「Layer two tunneling protocol - version 3 (L2TPv3)」2005年3月及び文献"IETF RFC2246「The TLS Protocol Version 1.0」において説明される）
−パッセンジャープロトコルのヘッダフィールド２５３（即ち、この例においてはイーサネット）
−送信元装置からの通過中に断片化が起こらなかった場合に、完全な第２のＩＰデータグラムを含むユーザデータフィールド２５４。
図４は、図１に説明した環境を参照して本発明の特定の一実施形態の応用例を示す概略図である。
トンネル終点１０１での位置付けに従って、本発明の特定の本実施形態のアルゴリズムを以下に説明する。実際には、任意のトンネル終点が本発明を実行できる。しかし、発明のアルゴリズムをセットアップするトンネルエントリトンネル終点は、ＴＣＰトンネルを介して、リモートＬＡＮを対象としたローカルＬＡＮから受信されるＴＣＰデータのみに焦点を合わせる。
図４に示す例では、トンネル終点ＴＥＰ１０１は、（リモート）ＬＡＮ１０４を対象としたトンネルに入るためにＬＡＮ（ローカルＬＡＮ）１０３から送出されるＴＣＰデータを解析し、このＴＣＰデータに対してＬＡＮ１０４から受信される確認応答も解析する。
この例では、２つのメディアサーバ１１０−Ａ及び１１０−ＢがＬＡＮ１０３に位置し、それらのサーバの２つのクライアントデバイス１１２−Ａ及び１１２−Ｂがローカルエリアネットワーク１０４に位置する。尚、この例の説明を理解し易いように、パケットの指標の概念は、パケットの送出順序に対応し（パケットの指標ｉは、パケットがｉ番目のパケットであることを示す）、通信プロトコルの実体を有していない（各ＴＣＰパケットに組み込まれるシーケンス番号と異なる）。
ＴＣＰパケットに対して以下の表記法が使用される：
−「ｉ」で参照されるパケット４１０：指標ｉのデータセグメントＴＣＰ（即ち、データシーケンス番号ｎに対してＬＡＮ１０３のサーバ１１０−Ａ、１１０−Ｂのうち、一方により送出されるｉ番目のパケット）；
−「Ｒｉ」で示されるパケット４１３：同一の指標「ｉ」を有するが同一のデータシーケンス番号ｎで再送されたパケット４１０と同一のＴＣＰデータセグメント；
−「Ａｉ」で示されるパケット４１１：データシーケンス番号ｎに対するパケット「ｉ」又は「Ｒｉ」のＴＣＰ確認応答（従って、ＴＣＰプロトコルによると、このパケット４１１は確認応答シーケンス番号ｎ＋１を含む）。即ち、この確認応答４１１はＬＡＮ１０４のクライアントからＬＡＮ１０３のサーバに送出される；
−「Ｄｉ」で示されるパケット４１２：データシーケンス番号ｎに対するパケット「ｉ」又は「Ｒｉ」のＴＣＰ確認応答（従って、ＴＣＰプロトコルによると、このパケット４１２は確認応答シーケンス番号ｎ＋１を含む）。即ち、この確認応答４１２はトンネル終点ＴＥＰ１０１（本発明の機構に従う）（図６及び図８を参照）からＬＡＮ１０３のサーバに送出される。確認応答４１２は、従来の確認応答（重複するため、サーバにより「重複ＡＣＫ」と考えられる）又は選択的確認応答ＳＡＣＫである（これらの２種類の確認応答は付録において詳細に説明する）。
−「ｉ」で参照されるパケット４１０：指標ｉのデータセグメントＴＣＰ（即ち、データシーケンス番号ｎに対してＬＡＮ１０３のサーバ１１０−Ａ、１１０−Ｂのうち、一方により送出されるｉ番目のパケット）；
−「Ｒｉ」で示されるパケット４１３：同一の指標「ｉ」を有するが同一のデータシーケンス番号ｎで再送されたパケット４１０と同一のＴＣＰデータセグメント；
−「Ａｉ」で示されるパケット４１１：データシーケンス番号ｎに対するパケット「ｉ」又は「Ｒｉ」のＴＣＰ確認応答（従って、ＴＣＰプロトコルによると、このパケット４１１は確認応答シーケンス番号ｎ＋１を含む）。即ち、この確認応答４１１はＬＡＮ１０４のクライアントからＬＡＮ１０３のサーバに送出される；
−「Ｄｉ」で示されるパケット４１２：データシーケンス番号ｎに対するパケット「ｉ」又は「Ｒｉ」のＴＣＰ確認応答（従って、ＴＣＰプロトコルによると、このパケット４１２は確認応答シーケンス番号ｎ＋１を含む）。即ち、この確認応答４１２はトンネル終点ＴＥＰ１０１（本発明の機構に従う）（図６及び図８を参照）からＬＡＮ１０３のサーバに送出される。確認応答４１２は、従来の確認応答（重複するため、サーバにより「重複ＡＣＫ」と考えられる）又は選択的確認応答ＳＡＣＫである（これらの２種類の確認応答は付録において詳細に説明する）。
従来のＴＣＰ接続は、パケット「Ａｉ」４１１により確認応答されるパケット「ｉ」４１０により形成される。
従って図４の例において、トンネルは、以下の２つの別個のＴＣＰ接続に対してＬＡＮ１０３からＬＡＮ１０４へデータパケット４１０を送出し、ＬＡＮ１０４からＬＡＮ１０３へ確認応答パケット４１１を送出する。
−サーバ１１０−Ａと受信機１１２−Ａとの間にセットアップされる接続Ａ（この接続Ａのパケットは、上述の表記法「ｉ」、「Ｒｉ」、「Ａｉ」及び「Ｄｉ」を含む正方形により表される）；
−サーバ１１０−Ｂと受信機１１２−Ｂとの間にセットアップされる接続Ｂ（この接続Ｂのパケットは、上述の表記法「ｉ」、「Ｒｉ」、「Ａｉ」及び「Ｄｉ」を含む円により表される）。
−サーバ１１０−Ｂと受信機１１２−Ｂとの間にセットアップされる接続Ｂ（この接続Ｂのパケットは、上述の表記法「ｉ」、「Ｒｉ」、「Ａｉ」及び「Ｄｉ」を含む円により表される）。
トンネル終点ＴＥＰ１０１は、トンネル上の送信の日時とスケジューリングを知るために使用される時間指示と共に、トンネル上を通過中のパケット４１０及び４１１のシーケンス番号を保存できる（実際には、指標ｉのセグメント４１０の記録はそれに対応する確認応答４１１の受信まで保存される）と仮定する。更に、トンネルキャリアの各パケット（キャリアパケット）の内容を容易に識別するために、データシーケンス番号の関連付けは、トンネルのキャリアのパケットとパッセンジャーストリームのパケットとの間で行われる（以下において指定される）。
情報に対して、トンネル終点ＴＥＰ１０１は、トンネル上に送出されるＴＣＰセグメントのテーブル５０１を管理する（図５を参照してこのテーブル５０１を以下に説明する）。
フェーズ４−１：トンネル上の誤り（エラー）の検出
このフェーズは、トンネル上の誤りの検出時間に対応する。例えば、３つの重複確認応答（重複ＡＣＫ）４２０は、トンネルのパケットの損失を示すためにトンネル終点ＴＥＰ１０２により送出される。同一のデータシーケンス番号ｋに対する３つの重複ＡＣＫの受信後（確認応答シーケンス番号ｋ＋１のＴＣＰプロトコルに従って）、トンネルのＴＣＰプロトコル層は失われたキャリアパケットを自動的に再送する。同時に、データシーケンス番号ｋのキャリアパケットにより転送されるデータの特性を判定するために、トンネル終点ＴＥＰ１０１において警告がトリガされる。
このフェーズは、トンネル上の誤りの検出時間に対応する。例えば、３つの重複確認応答（重複ＡＣＫ）４２０は、トンネルのパケットの損失を示すためにトンネル終点ＴＥＰ１０２により送出される。同一のデータシーケンス番号ｋに対する３つの重複ＡＣＫの受信後（確認応答シーケンス番号ｋ＋１のＴＣＰプロトコルに従って）、トンネルのＴＣＰプロトコル層は失われたキャリアパケットを自動的に再送する。同時に、データシーケンス番号ｋのキャリアパケットにより転送されるデータの特性を判定するために、トンネル終点ＴＥＰ１０１において警告がトリガされる。
図４の例において、データシーケンス番号ｋのキャリアパケットは、１１０−Ａから１１２−Ａ（接続Ａ）へのストリームの指標３のパケット４１０に対応する。従って、トンネルはこのデータ（パケット「Ｒ３」）を搬送するための再送に入る。
トンネル終点ＴＥＰ１０１は、リモートトンネル終点１０２のＴＣＰプロトコル層においてブロックされるデータセグメント４１０を判定する。接続Ａの指標３のパケット４１０の後にトンネルに送出されたのは、ローカルエリアネットワーク１０３の全てのパケット４１０である。
この例において、判定されたパケット４１０は以下の通りである。
−接続Ａの場合、３より大きい指標を有する全てのパケット；
−接続Ｂの場合、２より大きい指標を有する全てのパケット（接続Ｂの指標２は、接続Ａの指標３のパケットの送出に先行する）。
−接続Ｂの場合、２より大きい指標を有する全てのパケット（接続Ｂの指標２は、接続Ａの指標３のパケットの送出に先行する）。
トンネルにおける誤りの検出は、３つの重複ＡＣＫの受信後、即ち、１トンネルラウンドトリップ時間（ＲＴＴ）後、トンネル終点ＴＥＰ１０１とトンネル終点１０２との間で行われる。従って、トンネルにおける指標Ｒ３のパケット４１３の送信（損失したデータの再送）がリモートクライアントにより受信されるブロックされないパケットに対する確認応答４１１のＬＡＮ１０３への逆方向の送信とほぼ同時であることが図４において分かる。
従って、これは、サーバとクライアントとの間の１ラウンドトリップ時間（トンネルのＲＴＴがＬＡＮ１０３及び１０４の各々のＲＴＴより非常に長いため、トンネルにおける別のラウンドトリップ時間に近似される）の後にのみ、接続Ａ及びＢの後続シーケンスに対するその後の確認応答がＬＡＮ１０３において受信されることを意味する。
従って、次のフェーズ４−２はサーバＴＣＰ１１０−Ａ及び１１０−ＢのタイムアウトＲＴＯの満了の現象を防止するために予防修正（トンネル終点ＴＥＰ１０１による確認応答４１２の生成）を適用することを目的とし、この修正はＬＡＮ１０３の各サーバ１１０−Ａ及び１１０−Ｂ別に行われる。
フェーズ４−２：タイムアウトＲＴＯの満了の問題に対する修正の適用
このフェーズは、２つのステップ４−２ａ及び４−２ｂに細分化される。一方のフェーズ（４−２ａ）は、確認応答メッセージ４１２を送出するためのタイムアウトの計算であり、他方のフェーズ（４−２ｂ）は、このタイムアウト期間の満了時に確認応答メッセージ４１２の送出を行う。
このフェーズは、２つのステップ４−２ａ及び４−２ｂに細分化される。一方のフェーズ（４−２ａ）は、確認応答メッセージ４１２を送出するためのタイムアウトの計算であり、他方のフェーズ（４−２ｂ）は、このタイムアウト期間の満了時に確認応答メッセージ４１２の送出を行う。
従って、方法は、トンネルのパッセンジャーストリーム毎に第１のブロックされたパケット４１０のトンネル終点ＴＥＰ１０１による処理の日時Ｔ０を判定する（チャネルでの再送により考慮されるストリームの場合、第１のブロックされたパケットは再送中のパケット４１０であると考えられる）。
トンネルのＲＴＴの連続測定の後、方法は、ストリーム毎に確認応答メッセージ４１２の送信がプログラムされる日時ｔ１を判定する。この日時ｔ１は(t0 + 2.RTT - Δ)に対応する。ここで、Δは数ミリ秒の安全余裕度である。尚、各サーバ１１０−Ａ、１１０−ＢのＲＴＯに対応する期間はトンネルの２．ＲＴＴにほぼ等しく、発明の予防修正は、各サーバのＲＴＯをゼロに再設定して満了にならないようにＲＴＯの満了前に確認応答メッセージ４１２を各サーバに送出することからなる。
この目的のために、入力はサーバ１１０−Ａ及び１１０−Ｂに対する確認応答メッセージ４１２の生成に必要な情報を含むタイムアウトテーブル５１０（図５を参照）に記録される。
ブロックがトンネルにおいて継続する場合、１つ以上の第２のタイムアウト期間を判定し、他の確認応答メッセージ４１２を考慮されるサーバＴＣＰ１１０−Ａ、１１０−Ｂに送出するための１つ以上の日時ｔ２を判定するのが好ましい。リモートＬＡＮ１０４から到着し且つトンネルにより搬送されるクライアント１１２−Ａ、１１２−Ｂにより起動される真の確認応答４１１を受信すると、後続するタイムアウト期間は削除される（トンネル終点ＴＥＰ１０１により生成される確認応答メッセージ４１２の後続の送出がない）。
更に、生成される確認応答４１２に対応するクライアント１１２−Ａ、１１２−Ｂにより起動される真の確認応答４１１は、確認応答メッセージを過度に送出しないようにフィルタリングされる。実際には、例えば３つの重複確認応答（「重複ＡＣＫ」）の蓄積により、サーバは回避される誤りがネットワークにおいて発生したと解析により判断する。
次に図５を参照すると、データ構造の種々のテーブル５５０、５０１、５１０及び５２０が提示される。各データストリームは、送信元ＩＰアドレス、送信元ＴＣＰポート、並びに宛先ＩＰアドレス及び宛先ＴＣＰポートにより特徴付けられる。尚、ＴＣＰ通信が双方向通信であるため、同一のＴＣＰセッションは２つのデータストリームを搬送できる。以下において、限定しない例として各テーブルを説明する。
テーブル５５０は、トンネル終点における有効なストリームのテーブルである。用語「有効なストリーム」は、終了していない確立したＴＣＰセッションと関連するストリームを意味すると理解される。このテーブル５５０は以下を含む。
−ストリーム毎にそのストリームに割り当てられ且つストリームに対する他のデータ構造の参照としての役割を果たす固有の識別子を表すフィールド５５１；
−ＴＣＰセッションの送信元ＩＰアドレス及び宛先ＩＰアドレスをそれぞれ表すフィールド５５２及び５５４；
−ＴＣＰセッションの送信元ポート及び宛先ポートをそれぞれ表すフィールド５５３及び５５５；
−接続によりサポートされる確認応答メッセージの種類に対応するフィールド５５６。例えば、従来の種類の確認応答（ＡＣＫ）又は選択的確認応答（ＳＡＣＫ）。
−ＴＣＰセッションの送信元ＩＰアドレス及び宛先ＩＰアドレスをそれぞれ表すフィールド５５２及び５５４；
−ＴＣＰセッションの送信元ポート及び宛先ポートをそれぞれ表すフィールド５５３及び５５５；
−接続によりサポートされる確認応答メッセージの種類に対応するフィールド５５６。例えば、従来の種類の確認応答（ＡＣＫ）又は選択的確認応答（ＳＡＣＫ）。
テーブル５０１は、トンネルで転送されるテーブル５５０の有効な各ストリームに対するＴＣＰパケット４１０に関する複数のデータを表す。トンネルで転送され且つまだ確認されていないパッセンジャーストリームの各ＴＣＰパケットに対するテーブルへの入力が１つ存在する。このテーブル５０１は以下を含む。
−ＴＣＰセグメント／パケットがトンネルに送出される日時等のトンネル終点１０１によるＴＣＰセグメント／パケットの処理の日時ｔ０を表すフィールド５０２（パケット４０１をカプセル化するのに必要な時間を監視するために、殆どの場合、この値はローカルＬＡＮから到着するトンネル終点によるパケット４１０の受信の日時により識別される）；
−ストリーム識別子５５１を表すフィールド５０３；
−パッセンジャーストリームパケットのデータシーケンス番号ｎ、即ち、考慮されるストリーム５５１に対してＬＡＮから到着するトンネル終点１０１により受信されるＴＣＰデータシーケンス番号（ＴＣＰパケット４１０、即ち、パッセンジャーセグメント）を表すフィールド５０４；
−トンネルのキャリアのキャリアパケットのデータシーケンス番号ｋ、即ち、フィールド５０４で示されるパッセンジャーセグメント（ＴＣＰパケット４１０）を搬送するパケットのキャリア（キャリアパケット）のＴＣＰデータシーケンス番号を表すフィールド５０５。
−ストリーム識別子５５１を表すフィールド５０３；
−パッセンジャーストリームパケットのデータシーケンス番号ｎ、即ち、考慮されるストリーム５５１に対してＬＡＮから到着するトンネル終点１０１により受信されるＴＣＰデータシーケンス番号（ＴＣＰパケット４１０、即ち、パッセンジャーセグメント）を表すフィールド５０４；
−トンネルのキャリアのキャリアパケットのデータシーケンス番号ｋ、即ち、フィールド５０４で示されるパッセンジャーセグメント（ＴＣＰパケット４１０）を搬送するパケットのキャリア（キャリアパケット）のＴＣＰデータシーケンス番号を表すフィールド５０５。
テーブル５１０は、確認応答メッセージ４１２の後続の生成のためのタイムアウト値格納テーブルを表す。プログラムされた各送信に対してテーブルへの入力が１つ存在する。このテーブル５１０は以下を含む。
−確認応答メッセージ４１２が生成される必要がある有効期限の日時（例えば、ｔ１）を表すフィールド５１２；
−ストリーム識別子５５１を表すフィールド５１３；
−同一のストリーム識別子（フィールド５０３（テーブル５０１）及びフィールド５５１（テーブル５５０））に対してテーブル５０１（フィールド５０４）に記録されるデータシーケンス番号「ｎ」（n = j - 1）を確認する確認応答シーケンス番号「ｊ」を表すフィールド５１４。従って、ＴＣＰプロトコルによると、フィールド５１４は確認応答シーケンス番号「ｊ」（これは、データシーケンス番号「ｊ−１」が適切に受信され且つデータシーケンス番号「ｊ」を待つことを示す）を含む。
−ストリーム識別子５５１を表すフィールド５１３；
−同一のストリーム識別子（フィールド５０３（テーブル５０１）及びフィールド５５１（テーブル５５０））に対してテーブル５０１（フィールド５０４）に記録されるデータシーケンス番号「ｎ」（n = j - 1）を確認する確認応答シーケンス番号「ｊ」を表すフィールド５１４。従って、ＴＣＰプロトコルによると、フィールド５１４は確認応答シーケンス番号「ｊ」（これは、データシーケンス番号「ｊ−１」が適切に受信され且つデータシーケンス番号「ｊ」を待つことを示す）を含む。
テーブル５２０は、ストリーム毎に生成される確認応答メッセージ４１２をカウントするためのテーブルである。このテーブル５２０は以下を含む。
−ストリーム識別子５１３を表すフィールド５２２；
−確認応答シーケンス番号５１４を表すフィールド５２３。実際には、テーブル５２０は、生成された最後の確認応答４１２に対応するストリーム５１３毎に１つのエントリのみを保持する（先行するセグメントに対して先行して生成された確認応答４１２がより小さなデータシーケンス番号を確認し且つ生成された現在の最後の確認応答がＴＣＰプロトコルのスケジュールされた確認応答プロトコルに従って全ての先行セグメントを本質的に確認するため、それらの確認応答４１２には重要性がない）；
−考慮されるストリーム５２２の上述の確認応答シーケンス番号５２３に対してトンネル終点により生成された確認応答メッセージ４１２の数を表すフィールド５２４；
−考慮されるストリーム５２２の上述の確認応答シーケンス番号５２３に対して、トンネルを介してトンネル終点により受信され且つリモートクライアント１１２−Ａ又は１１２−Ｂから到着する確認応答メッセージ４１１の数を表すフィールド５２５。
−確認応答シーケンス番号５１４を表すフィールド５２３。実際には、テーブル５２０は、生成された最後の確認応答４１２に対応するストリーム５１３毎に１つのエントリのみを保持する（先行するセグメントに対して先行して生成された確認応答４１２がより小さなデータシーケンス番号を確認し且つ生成された現在の最後の確認応答がＴＣＰプロトコルのスケジュールされた確認応答プロトコルに従って全ての先行セグメントを本質的に確認するため、それらの確認応答４１２には重要性がない）；
−考慮されるストリーム５２２の上述の確認応答シーケンス番号５２３に対してトンネル終点により生成された確認応答メッセージ４１２の数を表すフィールド５２４；
−考慮されるストリーム５２２の上述の確認応答シーケンス番号５２３に対して、トンネルを介してトンネル終点により受信され且つリモートクライアント１１２−Ａ又は１１２−Ｂから到着する確認応答メッセージ４１１の数を表すフィールド５２５。
図６に、トンネルの送信誤りの検出時に実行されるアルゴリムを示す。このアルゴリズムは、本発明の修正方法の特定の一実施形態に含まれ、トンネル終点ＴＥＰ（例えば、１０１）において実現される。
トンネル終点ＴＥＰ１０１は、トンネルを移動する有効な接続のデータストリームを監視する。
説明は、トンネル１００のパッセンジャーＴＣＰストリームのルーティングを管理するトンネル終点ＴＥＰに関するのが好ましい。即ち、トンネル終点ＴＥＰ１０１はトンネルを移動する入力ポートにおけるＴＣＰストリームを識別できる。例えば、主な（及び特に継続する）転送に対応するＴＣＰストリーム及び制御ストリーム（いくつかのラウンドトリップメッセージ）の２種類のＴＣＰストリームを適切に考慮できる。従って、第１のカテゴリのＴＣＰストリームのみが本発明の特定の一実施形態により考慮される。これはストリームに対する帯域幅の割当てを可能にし、それにより利益が得られる。例えば、そのようなストリームは、ＵＰｎＰ、ＱｏＳ又はＳＢＭクエリなどのサービス品質ＱｏＳクエリ、或いは１つのＬＡＮ上で有効な任意の他のＱｏＳプロトコルに関連するクエリのトンネル終点ＴＥＰによる受信により検出可能である。ストリームに対する優先度クエリにより、それらのストリームの特性を認識できる。IEEE802.1Q規格において、優先度４〜６はストリーミング、映像転送及び音声転送にそれぞれ対応する。それらのＱｏＳクエリは、ＴＣＰストリームの識別に後で必要とされる全ての参照（送信元アドレス、宛先アドレス、ポート、プロトコル）を搬送する。提案される例において、ＴＣＰトランスポートプロトコルストリームのみが考慮されることが明らかである。
更に、ＴＣＰ接続の開始（ＳＮＹフラグを含むＴＣＰパケット、付録を参照）の検出時、応用プロトコルの更に綿密な解析により、転送特性の知識が得られる。例えば、ｈｔｔｐ応用プロトコル（２５３）を搬送するＴＣＰストリームは、要求された媒体の種類を表す情報を含む（ＭＩＭＥタイプ「ｖｉｄｅｏ／ｍｐｅｇ」の映像の場合はｈｔｔｐ ＧＥＴメッセージ）。これらの例は、限定しない例として与えられる。
本発明の特定の一実施形態において、上述のように識別されない任意の他のＴＣＰストリームがトンネル終点ＴＥＰ１０１による管理制御なしでトンネルに搬送される例を考慮する。これには、非常に重要なストリームに対してトンネル終点ＴＥＰ１０１の利用可能なプロセッサ及びメモリリソースを保持する利点がある。一変形例において、本発明の方法がトンネルを移動する全てのＴＣＰストリームに適用可能であることは明らかである。
特定の別の実施形態において、各ＴＣＰ接続により使用される確認応答の種類が更に判定される。ＳＡＣＫ拡張（文献ＲＦＣ２０１８に準拠する）は、ＴＣＰメッセージの２つのオプションのフィールドを使用する。第１のフィールドは、接続が開始された時にＴＣＰ ＳＹＮセグメントにおいて検査されるか又は検査されない「ＳＡＣＫ許可」起動オプションであり、ＳＡＣＫ機構を後で使用する可能性を示す。第２のオプションは、ＴＣＰ接続のセットアップ時に許可される場合に選択的確認応答の送信中に検査されるＳＡＣＫオプションである。
ストリームのテーブル５５０（図５を参照）は、新しいＴＣＰ接続の開始／終了毎に定期的に更新される。更に、テーブル５０１（図５を参照）は、図１を参照して説明される環境においてＴＣＰクライアント／サーバの対（１１０−Ａ及び１１２−Ａ）等により受信されるデータセグメント及び確認応答を管理する。
本発明は、テーブル５５０を埋める方法を特許請求することを目的としない。この目的のためにいくつかの従来技術が存在する。
考慮されるストリームに対して、トンネル終点ＴＥＰ１０１は、トンネル終点ＴＥＰ１０１を通過するデータ（ＤＡＴＡ）のデータセグメント（パケット）のＴＣＰシーケンス番号を保持する（テーブル５０１）。これは、トンネル終点ＴＥＰ１０１がトンネルに送出されたが確認されていないパケットの数（flightsize）を随時認識することを意味する。
更に、トンネル終点は、トンネルのＴＣＰチャネルに対して開かれたネットワークコネクタ又はソケットの特性を取得する（例えば、トンネルの誤りを認識することを可能にするＡＰＩ「Unix（登録商標） Socket Interface」を使用して）。ＡＰＩは「Application Programming Interface」を意味する。
変更ＴＣＰプロトコルスタックは、テーブル５０１を埋めるためにトンネル終点ＴＥＰ１０１により使用されるのが好ましい。プロトコルスタックはトンネルのパッセンジャーストリームのデータを送出するコマンドをトンネル終点ＴＥＰ１０１のルーティング機能を介して受信中にテーブル５０１を直接更新するか、或いはＡＰＩ「Unix（登録商標） Socket Interface」を介してデータを送出するコマンドに応答してトンネルのＴＣＰデータシーケンス番号に関する追加の情報が示され且つテーブル５０１を更新するのがトンネル終点ＴＥＰ自体である。
トンネルにおいて誤りが検出された時、ＡＰＩ「Unix（登録商標） Socket Interface」は、本発明のアルゴリズムに警告でき、特に図６のステップ６００を再開できる。尚、トンネルＴＣＰ自体が損失パケットの再送を管理する。
ステップ６０１は、テーブル５０１と考慮されるパッセンジャーストリーム（識別子５０３）のトンネルのＴＣＰキャリアの損失パケットのデータシーケンス番号（識別子５０５）及びＴＣＰキャリアの損失パケットにより転送された搬送されたパケット４１０のデータシーケンス番号（図中符号５０４）の知識とから判定することからなる。
ステップ６０２において、本発明は、テーブル５０１に基づいて、トンネルで搬送される他の各ストリームに対して、ステップ６０１で判定されたパケット４１０の後に送出される第１のデータシーケンス番号を判定する。これらは、相関的なＴＣＰサーバに対する本発明のメッセージの生成の原理が適用されるデータシーケンス番号である。
ステップ６０３において、上記規定されているように、適切なパッセンジャーＴＣＰストリームのうちの一部の選択的スケジューリングが行われても良い。ステップ６０４及び６０５を実行するために、選択されたストリームのみが１つずつ考慮される。選択的スケジューリングが行われない場合、先に判定された全てのストリームがステップ６０４及び６０５を実行するために１つずつ考慮される。
スケジューリングに対していくつかのオプションが可能である。
−スロースタートフェーズ（付録を参照）のＴＣＰストリームは、制限（ＳＳＴＨＲＥＳＨ）が演繹的に認識されないこのフェーズにおける輻輳ウィンドウの更なる実質的な増加の結果として優先度を有すると考えられる；
−本発明は、安定化フェーズ（これは輻輳回避フェーズであり、付録を参照）においてＴＣＰストリームのウィンドウサイズの縮小を回避するのが好ましい。しかし、ウィンドウのサイズ縮小は殆ど影響を及ぼさない；
−クライアントにより送出される機器ウィンドウ（又は広告ウィンドウ、付録を参照）の値は、ビットレートの増加に対する最大の余裕を提案するストリームを認識するために使用される；
−優先度を有すると考えられるストリームは、６０１で判定されたパッセンジャーストリームに非常に近接する時間にデータを送出した（即ち、トンネルでの再送が行われた）ストリームである。尚、６０１で判定されたストリームは、本発明の修正アルゴリズムが適用される最初のストリームである。
−本発明は、安定化フェーズ（これは輻輳回避フェーズであり、付録を参照）においてＴＣＰストリームのウィンドウサイズの縮小を回避するのが好ましい。しかし、ウィンドウのサイズ縮小は殆ど影響を及ぼさない；
−クライアントにより送出される機器ウィンドウ（又は広告ウィンドウ、付録を参照）の値は、ビットレートの増加に対する最大の余裕を提案するストリームを認識するために使用される；
−優先度を有すると考えられるストリームは、６０１で判定されたパッセンジャーストリームに非常に近接する時間にデータを送出した（即ち、トンネルでの再送が行われた）ストリームである。尚、６０１で判定されたストリームは、本発明の修正アルゴリズムが適用される最初のストリームである。
ステップ６０４は、本発明に従って生成された確認応答メッセージ４１２をＴＣＰサーバに向けて送出する第１の日時（第１のタイムアウト）ｔ１を判定するために使用される。
ステップ６０５において、確認応答メッセージ４１２の送出はプログラムされたディスパッチのテーブル５１０にプログラムされる。
第１の送信日時ｔ１の判定の特定の面を示しても良い。図８のステップ８０７を参照して詳細に説明するように、第２の送信日時ｔ２（第２のタイムアウト）は後でプログラムされる可能性が高い。
ステップ６０４及び６０５が適用されるトンネルのパッセンジャーストリーム毎の確認応答メッセージ４１２の第１の送信日時ｔ１は、トンネルのＲＴＴの連続測定の値（全てのパッセンジャーストリームに共通のパラメータ）及び考慮されるパッセンジャーストリームの第１のブロックされたパケットのトンネル終点１０１による処理の日時ｔ０（１つの日時ｔ０はストリーム毎に特有である）に大きく依存する。第１のタイムアウトの起動はストリーム別に行われ、可能な限り割り込まないようにストリームのアクティビティと連携される。
尚、確認応答メッセージ４１２の生成（図８のアルゴリズムの起動）のためにプログラムされる第１の送信日時ｔ１は、t1 = t0 + 2.RTT - Δにより取得される。式中、Δは数ミリ秒の安全余裕度（例えば、トンネルＲＴＴの１０％）である。
図７は、トンネルのパッセンジャーＴＣＰストリームに対するトンネルから到着する確認応答の受信時に実行されるアルゴリズムを示す。このアルゴリズムは、本発明の修正方法の特定の一実施形態に含まれ、例えばトンネル終点ＴＥＰ（１０１）において実現される。
ステップ７００において、トンネル終点ＴＥＰ１０１は、パッセンジャー接続からのＴＣＰ確認応答メッセージ（例えば、図４に関しては、サーバ１１０−Ａによるセグメント４１０のディスパッチ後にクライアント１１２−Ａから到着する確認応答４１１）の受信に対して警告される。
ステップ７０１において、トンネルを介して送出された１つ以上のセグメントデータシーケンス番号（パケット）４１０に対応して、クライアント１１２−Ａから到着する確認応答４１１を受信後、その確認応答４１１の解析が行われる。この確認応答４１１は従来の確認応答であっても良く（文献ＲＦＣ７９３に準拠する）、ＳＡＣＫタイプであっても良い（文献ＲＦＣ２０１８に準拠する）。何れの場合においても、考慮されるストリームに対して、データシーケンス番号５０４が確認応答４１１で示される確認応答シーケンス番号以下の値を有するテーブル５０１において入力が判定される。このように判定される全てのエントリは、テーブル５０１から削除される。確認応答４１１がＳＡＣＫタイプであり、送信誤りがある特定のシーケンス番号に対して起こったことを示す場合であっても、ＳＡＣＫタイプのメッセージにより報告される確認応答シーケンス番号が考慮される。これは、この（最大）確認応答シーケンス番号までの全てのパケット４１０がローカルネットワークにおいてトンネル終点ＴＥＰ１０２により送信されたが明らかに損失があることを意味する。
ステップ７０２において、考慮されるストリームに対して、本発明の修正手順が行われたか（即ち、図６のステップ６０５が実行されたか）を示すテーブル５１０の探索が行われる。これは、確認応答４１１を搬送する現在の接続の識別子に対応するフィールド５１３を有するこのテーブルのエントリを判定する場合の例である。
テスト７０２が否定の場合、ステップ７０５に直接進む。テスト７０２が肯定の場合、確認応答４１１の確認応答シーケンス番号が適用される修正測定値に対する比率を有することを検証する際に、ステップ７０３における探索は修正される。確認応答４１１により確認されたシーケンスに対応するフィールド基準５１４を満たすテーブル５１０のエントリが存在する場合、ステップ７０４を実行する。ＳＡＣＫオプションが使用される場合、フィールド５１４は確認応答４１１の確認されたシーケンスのＳＡＣＫメッセージのリスト（肯定応答は、ＳＡＣＫオプションが使用されない従来の例に対応する）又は異常なシーケンスの（ＳＡＣＫメッセージの）リスト（この場合、セグメントは損失され、サーバは通知される必要がある）に同様に含まれる必要がある。
ステップ７０４は、トンネルにおける損失の検出後に修正測定を停止するために、タイムアウトのリスト５１０にプログラムされたエントリを消去することからなる。その後、ステップ７０５に進む。
ステップ７０５のテストは、修正測定が確認応答メッセージ４１２の生成（生成については図８を参照）後にＴＣＰ接続を不安定にしないように現在のパッセンジャーストリームに対して過去に行われたかを見つけるために使用される。ストリームが本発明により生成される確認応答メッセージ４１２をカウントするためのテーブル５２０において識別されるかを調査するために探索が行われる。
テスト７０５が否定の場合、通常、ＬＡＮ１０３に送出される（ステップ７０８）確認応答４１１に対するフィルタリングは行われない。
テスト７０５が肯定の場合、ステップ７０６のテストは、確認応答４１２がＬＡＮ１０３で生成されたセグメントを確認応答４１１が確認するかを調査するために実行される。
テスト７０６の結果が否定の場合、確認応答メッセージ４１１がテーブル５２０に記録される確認応答シーケンス番号により確認されるデータシーケンス番号より大きいデータシーケンス番号を確認するかを調査する（ステップ７０７のテスト）。換言すると、確認応答４１１がテーブル５２０の考慮されるセグメントを含むいくつかのデータセグメント４１０を確認するかを調査する。テスト７０７の結果が肯定の場合、テーブル５２０の現在の入力は削除され（ステップ７１１）、通常、確認応答４１１はＬＡＮ１０３に送出される（ステップ７０８）。ステップ７０７が否定の場合、ステップ７０８に直接進む。
テスト７０６の結果が肯定の場合、現在の確認応答４１１は、本発明により生成される確認応答４１２（図８を参照）に完全に対応する。確認応答４１１の受信の統計データは更新され（ステップ７０９において、フィールド５２５が増分される）、現在の確認応答４１１が問題なくＬＡＮ１０３に中継されるかを調査する（ステップ７１０のテスト）。
従って、生成された確認応答４１２より多くの確認応答４１１を受信していない限り（テスト７１０が否定）、確認応答４１１は破棄される（ステップ７１２のフィルタリングにより）。より多くの確認応答４１１が受信された場合（テスト７１０の結果が肯定の場合）、本発明がＴＣＰサーバ１１０が受信する確認応答の数の平衡を回復し、「偽の」確認応答４１２の生成により及ぼされる副次的影響の削除の判断基準が利用されることを意味する。即ち、上述したステップ７１１に進む。
確認応答４１１がＳＡＣＫタイプの確認応答である場合、確認応答４１１（確認応答は肯定又は否定である）において参照されるデータシーケンス毎に上述した残りのステップ７０５〜７０８に繰り返し進むのが好ましい（図７はこれを示さない）。
図８は、確認応答メッセージ４１２の生成及びローカルＴＣＰサーバへの送出に対する第１の日時ｔ１（図６のステップ６０４及び６０５を参照）を示すタイムアウトの満了時に実行されるアルゴリズムを示す。このアルゴリズムは、本発明の修正方法の特定の一実施形態に含まれ、トンネル終点ＴＥＰ（例えば、１０１）において実現される。
ステップ８０１において、確認応答４１２の生成動作を必要とするプログラミングテーブル５１０のエントリを判定する。
判定されたエントリ（ステップ８０２のテスト）毎に、ステップ８０３〜８０９のシーケンスを実行する。
ステップ８０３において、確認応答メッセージ４１２を作成するのに必要なパラメータを種々のテーブルから検索する。
−テーブル５１０は、考慮されるストリーム（フィールド５１３）及び確認応答４１２が生成される必要のある確認応答シーケンス番号（フィールド５１４）を示す；
−ストリームの識別子５１３から開始し且つテーブル５５０を使用し、フィールド５５２〜５５５はメッセージのＩＰヘッダの形成を可能にし、フィールド５５６はサポートされる確認応答の種類を示す。デフォルトでは、規格ＲＦＣ７９３に従う従来の種類が常に使用されても良いが、サーバによりサポートされる場合はＳＡＣＫサポートの使用が好ましいことが推奨される。
−ストリームの識別子５１３から開始し且つテーブル５５０を使用し、フィールド５５２〜５５５はメッセージのＩＰヘッダの形成を可能にし、フィールド５５６はサポートされる確認応答の種類を示す。デフォルトでは、規格ＲＦＣ７９３に従う従来の種類が常に使用されても良いが、サーバによりサポートされる場合はＳＡＣＫサポートの使用が好ましいことが推奨される。
ステップ８０４は、確認応答メッセージ４１２（従来技術に従う）を作成し、それをローカルネットワーク１０３に送出する。
現在のエントリをテーブル５１０から削除し（ステップ８０５）、確認応答メッセージ生成統計データ４１２をテーブル５２０で増分する（ステップ８０６）。必要に応じて、新しいエントリを、テーブル５１０のフィールド５２４を１、及びフィールド５２５を０にして作成する。
予防対策として、確認応答メッセージ４１２の新たな生成を引き続き行おうとすることが重要である。実際には、ステップ８０４の現在の生成は、トンネルにおける単純な損失を克服するが、トンネルが回復されるのに１サイクルのＲＴＴより長くかかる例を考慮するのが望ましい。従って、ステップ８０７のテストは確認応答メッセージ４１２の新たな生成の可能性を検証し、ステップ８０８は新しい確認応答メッセージ４１２をＬＡＮ１０３に送出するのに推奨される日時ｔ２を計算する。
まず、メッセージが以下の２つの条件を組み合わせることにより生成されるかを調査する。
条件１：Ｎは１以上である必要があり、N = Nb_packet_410 - Nb_packet_412である。式中：
「Nb_packet_410」は、トンネルを通過中のパケット４１０の数（フィールド５２０の現在のエントリのフィールド５２３の確認応答シーケンス番号により確認されるデータシーケンス番号より大きいデータシーケンス番号）であり、ここではテーブル５０１において参照される；
「Nb_packet_412」は、生成される確認応答パケット４１２の数である（テーブル５２０の現在のエントリのフィールド５２４の値）。
「Nb_packet_410」は、トンネルを通過中のパケット４１０の数（フィールド５２０の現在のエントリのフィールド５２３の確認応答シーケンス番号により確認されるデータシーケンス番号より大きいデータシーケンス番号）であり、ここではテーブル５０１において参照される；
「Nb_packet_412」は、生成される確認応答パケット４１２の数である（テーブル５２０の現在のエントリのフィールド５２４の値）。
換言すると、条件１は以下のようにも表すことができる。
Nb_packet_410 ＞ Nb_packet_412
条件２：「Nb_packet_412」は３以下である必要がある。
条件２：「Nb_packet_412」は３以下である必要がある。
実際には、４つ以上の同一の確認応答メッセージ４１２が生成される場合、それらの同一の確認応答メッセージのうち第４の確認応答メッセージは第３の重複確認応答メッセージ（「重複ＡＣＫ」）であると考えられ、サーバはこれを送信誤り（これは回避される）と解釈する。
上述の２つの条件が検証されない場合、現在のエントリに対して手順は完了する（ステップ８０２に戻る）。
上述の２つの条件が検証された場合、ステップ８０８が実行される。確認応答メッセージ４１２の生成に対してプログラムされる新しい日時ｔ２は以下のように取得される。
t2 = current_date + 2.RTT - Δ
式中、Δは数ミリ秒の安全余裕度であり（例えば、トンネルＲＴＴの１０％）、「current_date」は先行する確認応答生成日時４１２（即ち、ｔ１）である。
式中、Δは数ミリ秒の安全余裕度であり（例えば、トンネルＲＴＴの１０％）、「current_date」は先行する確認応答生成日時４１２（即ち、ｔ１）である。
送出日時ｔ２が判定されると、ステップ８０９において新しい送出動作がプログラムされる。
第１の送出日時ｔ１と同様に、ステップ８０８及び８０９が適用されるトンネルのパッセンジャーストリーム毎に確認応答メッセージ４１２を送出する第２の日時ｔ２は、トンネルのＲＴＴの連続測定の値（全てのパッセンジャーストリームに共通のパラメータ）及び日時ｔ１（各ストリームに特有）に大きく依存する。従って、第２のタイムアウトの起動（ｔ２の判定）はストリーム別に行われ、可能な限り割り込まないようにストリームのアクティビティと連携される。
本発明のアルゴリズムにより選択されるストリームのためのサーバ１１０−Ａ、１１０−Ｂとクライアント１１２−Ａ、１１２−Ｂとの間のＴＣＰ接続に対する送信を停止すること（検出されるＴＣＰ ＳＹＮ−ＥＮＤメッセージ、付録を参照）により、図８のアルゴリズムのセットアップが自動的に停止することは明らかである。この目的のために、ＴＣＰ接続が停止するとすぐに、終了したＴＣＰ接続を参照するエントリはテーブル５５０、５０１、５１０及び５２０から除去される（図８には示さない）。
図９は、本発明のアルゴリズムを実現するトンネル終点１０１のＰＥＰシステムの関数型アーキテクチャを示す概略図である。
トンネル終点ＴＥＰ１０１は、ＬＡＮ１０３に対する２つの通信ポート、即ち、入力ポート９１０及び出力ポート９２０により主に形成される。実際には、それらの２つのポートは、同一のイーサネットタイプの双方向物理インタフェースを有する（図１０によると、ネットワークポート１０２０）。
それらの２つのポートは、２つのＬＡＮ１０３及び１０４を接続するトンネルのＴＣＰチャネル９３０に接続される。そのトンネルは、トンネルフレームのパッセンジャーストリームをカプセル化するタスクを有するマルチプレクサ９３１及びトンネルのＴＣＰキャリアにより搬送されるフレームを非カプセル化するタスクを有するデマルチプレクサ９３２を介して通信する。
ＬＡＮ１０３からイーサネットフレームが到着した時、ストリームセレクタＴＣＰ９１１は図６のステップ６００を参照して詳細が説明される選択手段を適用する役割を果たす。
エントリフレームが選択されなかったＴＣＰストリームに関係する場合、このイーサネットフレームは、カプセル化されてトンネルに送出されるためにマルチプレクサ９３１に提供される。
エントリフレームが選択されたＴＣＰストリームに関係する場合、エージェント９１２は、搬送されるＴＣＰセグメントの種類（ＤＡＴＡ又はＡＣＫ）を解析し、テーブル５５０及び５０１の統計データを更新する。
トンネルのコントローラ９４０から送信誤り警告を受信すると、確認応答メッセージ４１２の生成のためのＰＥＰシステム９１３は図６で説明されるアルゴリズムを実行する。このＰＥＰシステム９１３の内部のタイムアウト機構（テーブル５１０）の設定により、適切な瞬間に図８のアルゴリズムの手順が再開される。
逆に、トンネルからフレームを受信すると、デマルチプレクサ９３２は元のイーサネットフレームをストリームスイッチ９３３に与える。ストリームスイッチ９３３は、フレームがＴＣＰ接続に関係するかを確認するための調査を行う役割を果たす。調査の結果が肯定の場合、そのＴＣＰ接続が監視されるかを調査する（ＴＣＰストリームセレクタ９１１と同一の基準を探索する）役割を果たす。ＴＣＰ接続が監視されない場合、イーサネットフレームは出力インタフェースモジュール９３６を介してローカルエリアネットワーク１０３に送信される。
ＴＣＰ接続が監視される場合、イーサネットフレームは接続の統計データを更新する（図７のアルゴリズムのステップ７０１）役割を果たすモジュール９３４に送信される。モジュール９３５は、特にメッセージ４１１をフィルタリング（削除）する能力を有する図７のアルゴリズムを実行する。確認応答メッセージ４１２が既に送信された確認応答メッセージ４１１に対応しない任意のイーサネットフレームは、出力インタフェースモジュール９３６を介してＬＡＮ１０３に送出される。モジュール９３５は、受信される（図７を参照して説明したように）確認応答メッセージ４１１に対するタイムアウト機構の起動／停止に関してＰＥＰシステム９１３に通知する。
図１０は、本発明の技術の特定の一実施形態を実現するように適応された汎用通信デバイス１０００の概略構成を示す。例えば、図１を参照して上述したトンネル終点１０１又は１０２は汎用デバイス１０００と同一である。
この汎用デバイス１０００は、グラフィックカードに接続され且つ汎用デバイス１０００にマルチメディア情報を配信する画像、映像又は音声を格納する任意の手段に特に接続されてもよい。
汎用デバイス１０００は通信バス１００２を有し、通信バス１００２には以下のものが接続される。
−中央処理装置１００３（例えば、ＣＰＵと呼ばれるマイクロプロセッサ）；
−上述の１つ又は複数のソフトウェアプログラムを含むことができるＲＯＭと呼ばれる読み出し専用メモリ１００４；
−上述の１つ又は複数のソフトウェアプログラムにより実行中に作成及び変更される変数及びパラメータを記録するのに適するレジスタを含むランダムアクセスメモリ１００６（ＲＡＭと呼ばれるキャッシュメモリ）；
−例えば（図１の場合）ＬＡＮ１０３／１０４及びインターネット１０７である少なくとも２つの分散型通信ネットワーク１０２０にリンクされる通信インタフェース１０１８。インタフェースは、それらのネットワークに対してデータを送受信できる。
−上述の１つ又は複数のソフトウェアプログラムを含むことができるＲＯＭと呼ばれる読み出し専用メモリ１００４；
−上述の１つ又は複数のソフトウェアプログラムにより実行中に作成及び変更される変数及びパラメータを記録するのに適するレジスタを含むランダムアクセスメモリ１００６（ＲＡＭと呼ばれるキャッシュメモリ）；
−例えば（図１の場合）ＬＡＮ１０３／１０４及びインターネット１０７である少なくとも２つの分散型通信ネットワーク１０２０にリンクされる通信インタフェース１０１８。インタフェースは、それらのネットワークに対してデータを送受信できる。
汎用デバイス１０００は、以下を更に有する（しかし、これはオプションである）。
−キーボード１０１０、或いは例えばマウス１０１１又は光ペンシルであるポインティングデバイス等の任意の他の手段を使用して、本発明に従って１つ又は複数のプログラムと対話できるネットワーク管理者に対するグラフィカルユーザインタフェースとして動作し且つ／又はデータを見るのに使用される画面１００８；
−上述のプログラムを含むことができるハードディスクドライブ１０１２；
−ＵＳＢメモリスティックの読み出しを可能にする外部ディスクドライブ１０１４。
−上述のプログラムを含むことができるハードディスクドライブ１０１２；
−ＵＳＢメモリスティックの読み出しを可能にする外部ディスクドライブ１０１４。
通信バス１００２は、汎用デバイス１０００に含まれるか又はこのデバイスに接続される種々の手段の間の通信及び相互運用を可能にする。更に一般的には、中央処理装置１００３は、通信バス１００２を介して、汎用デバイス１０００に含まれる任意のデバイスに命令を直接通信できるか又は別の汎用デバイスを使用して通信できる。
汎用デバイス１０００が本発明の一実施形態に係る方法を実現することを可能にする上述の各プログラムの実行可能コード（ＰＥＰ機構を管理する方法）は、ハードディスクドライブ１０１２、読み出し専用メモリ１００４又はＵＳＢスティック１０１６等の不揮発性メモリに格納される。
中央処理装置１００３は、本発明の一実施形態に係る１つ又は複数のプログラムのソフトウェアコードの命令又は部分の実行（ＰＥＰ機構を管理する方法）を制御及び指示する。機器の電源が投入されると、上述の不揮発性メモリ（１０１２、１００４又は１０１６）に格納される１つ又は複数のプログラムは、本発明の１つ又は複数のプログラムの実行可能コードを含むランダムアクセスメモリ１００６、並びに本発明の方法の本実施形態を実現するのに必要な変数及びパラメータを記憶するレジスタに転送される。
尚、本発明に係るデバイスを含む通信装置は、プログラムされた装置であってもよい。この装置は、例えば特定用途向け集積回路（ＡＳＩＣ）にハードワイヤードされる１つ又は複数のコンピュータプログラムのコードを含む。
付録：ＴＣＰプロトコルに関する注意
ＴＣＰプロトコル（ＲＦＣ７９３規格により規定されるような伝送制御プロトコル）は、速度及び品質の主な判断基準に従ってインターネットでデータを転送するために作成されたＡＲＱプロトコルである。受信機に到着する過度なトラフィックを管理するために、少なくとも２つの機構が使用される。即ち、第１の機構はバッファ受信メモリを使用し、第２の機構はストリームの制御をセットアップする。
付録：ＴＣＰプロトコルに関する注意
ＴＣＰプロトコル（ＲＦＣ７９３規格により規定されるような伝送制御プロトコル）は、速度及び品質の主な判断基準に従ってインターネットでデータを転送するために作成されたＡＲＱプロトコルである。受信機に到着する過度なトラフィックを管理するために、少なくとも２つの機構が使用される。即ち、第１の機構はバッファ受信メモリを使用し、第２の機構はストリームの制御をセットアップする。
ＴＣＰプロトコルは、データグラム配信の制御を組み込まないＩＰプロトコルを使用するが、データを確実に転送するために使用される。実際には、ＴＣＰプロトコルはクライアント（クライアントデバイス又は受信側マシンとも呼ぶ）及びサーバ（サーバデバイス又は送信側マシンとも呼ぶ）により使用される確認応答システム又はＡＣＫとも呼ぶ受信確認応答システムを有し、データの効率的な相互受信を確実にする。データセグメント（データパケットとも呼ぶ）が送出される場合、順序番号（データシーケンス番号とも呼ぶ）はそのデータセグメントと関連付けられる。データセグメントを受信すると、受信側マシンは、１増分された受信セグメントのデータシーケンス番号に等しい受信番号（確認応答シーケンス番号とも呼ぶ）の確認応答が付随するフラグＡＣＫが１（これが受信の確認応答であることを報告するため）のデータセグメントを返す。実際には、確認応答シーケンス番号は、待っている次のセグメントのデータシーケンス番号（受信された最後のセグメントのデータシーケンス番号ではなく）に対応する。
データ送信及び受信の確認応答により実行される通信処理がデータ順序番号（又はシーケンス番号）に基づくため、送信側マシン（サーバ）及び受信側マシン（クライアント）は、他方のマシンの初期順序番号（初期シーケンス番号又はＩＳＮと呼ばれる）を認識する必要がある。
接続のセットアップ
ＴＣＰ接続は、以下の３段階でセットアップされる。
ＴＣＰ接続は、以下の３段階でセットアップされる。
−第１段階において、クライアントは、ＳＹＮフラグ（又はＳＹＮメッセージ）を含むデータセグメントを送出し、これが初期データシーケンス番号（ISN = x）を有する同期セグメントであることを報告する；
−第２段階において、サーバはクライアントから到着する同期セグメントを受信し、受信の確認応答、即ち、フラグＡＣＫが１であり、フラグＳＹＮが１であり且つ自身のシーケンス番号（ISN = y）を含むデータセグメントを送出する。しかし、サーバは先行パケットを確認する必要もあり、これは１増分されたクライアントの初期順序番号（ack = x + 1）を含む受信番号（確認応答シーケンス番号）の確認応答により行われる；
−第３段階において、クライアントは受信の確認応答、即ち、同期セグメントではないためにフラグＡＣＫが１であり且つフラグＳＹＮが０であるセグメントをサーバに送出する。その順序番号（データシーケンス番号）は増分され（seq = x + 1）、確認応答受信番号（確認応答シーケンス番号）は１増分されたサーバの初期順序番号（データシーケンス番号）（ack = y + 1）を表す。
−第２段階において、サーバはクライアントから到着する同期セグメントを受信し、受信の確認応答、即ち、フラグＡＣＫが１であり、フラグＳＹＮが１であり且つ自身のシーケンス番号（ISN = y）を含むデータセグメントを送出する。しかし、サーバは先行パケットを確認する必要もあり、これは１増分されたクライアントの初期順序番号（ack = x + 1）を含む受信番号（確認応答シーケンス番号）の確認応答により行われる；
−第３段階において、クライアントは受信の確認応答、即ち、同期セグメントではないためにフラグＡＣＫが１であり且つフラグＳＹＮが０であるセグメントをサーバに送出する。その順序番号（データシーケンス番号）は増分され（seq = x + 1）、確認応答受信番号（確認応答シーケンス番号）は１増分されたサーバの初期順序番号（データシーケンス番号）（ack = y + 1）を表す。
「３ウェイハンドシェーク」と呼ばれるこのフェーズを完了すると、２つのアプリケーションは、接続のセットアップを保証するバイトを交換できる。
ストリーム制御は、指定受信者のレベルでメモリ及びプロセス等のリソースの割当てを管理する。一般に、ストリーム制御に従って、宛先は、宛先にデータを送出する全ての送信元により実現される送信処理量の制限を設定する。送信元及び宛先は、クエリ及び受信の確認応答を含むメッセージを交換することによりデータの転送を連携して行う。送信元は、パケットの送出を開始する前に、送信開始の許可を取得することを目的とする要求を宛先に送出する。このクエリに応答して、宛先は、送信元が追加の許可なしでその宛先に送信できるパケット数の識別を含むメッセージを送出する。一般に、この数は「ウィンドウサイズ」と呼ばれる。その後、送信元は、許可されたパケット数を宛先に送出し、宛先がそれらのパケットの受信を検証するのを待つ。宛先は、パケットを正常に受信した後、パケットが正常に受信されたことを示し且つある特定の場合には送信元が別のパケットを送出することを許可する受信の確認応答（確認応答）を含むリターンメッセージを送信元に送出する。従って、送信元から宛先に移動するネットワーク上のパケット数は許可されたウィンドウサイズを超えることはない。
以下において、ＴＣＰウィンドウの種々の名前を示す。
−ＴＣＰウィンドウ：接続のセットアップ中に検証される初期値であり、接続期間中に許可される最大値である；
−輻輳ウィンドウ（ＣＷＮＤ）：クライアントに対してアドレス指定されたＴＣＰパケットにおいてサーバから送出される現在のウィンドウの値；
−確認応答ウィンドウ（肯定応答ウィンドウ又は広告ウィンドウ）：クライアントの一部におけるメモリ占有を示すＡＣＫ ＴＣＰパケットでサーバに送出されるウィンドウの値；
−スライディングウィンドウ：最後の確認応答ＴＣＰセグメントが到着してから送信されるデータ数を認識することを可能にするサーバ内部のウィンドウの値。
−輻輳ウィンドウ（ＣＷＮＤ）：クライアントに対してアドレス指定されたＴＣＰパケットにおいてサーバから送出される現在のウィンドウの値；
−確認応答ウィンドウ（肯定応答ウィンドウ又は広告ウィンドウ）：クライアントの一部におけるメモリ占有を示すＡＣＫ ＴＣＰパケットでサーバに送出されるウィンドウの値；
−スライディングウィンドウ：最後の確認応答ＴＣＰセグメントが到着してから送信されるデータ数を認識することを可能にするサーバ内部のウィンドウの値。
ＴＣＰウィンドウサイズが大きいことにより送出が促進される。ウィンドウが示す数より受信されるデータ数が多い場合、ウィンドウ外のデータは拒否される。この損失により、再送の数は多くなり、ネットワーク及びＴＣＰに無駄に過度な負担をかけることになる。小さなサイズのウィンドウの使用は、ラウンドトリップ時間又はＲＴＴにある特定の追加の遅延を加えることにより処理量を分割するが、再送に起因するネットワークの過度な負荷を制限する際に処理量を分割する。更に、非常に小さなウィンドウを開くことは、データに対するヘッダの重みを増加することにより性能を低減する。
それらの機構のセットアップを行った場合でも、使用中のネットワークにおいて、いくつかの送信元はネットワークにおいて２つ以上の宛先にストリームを同時に送出する。そのような多すぎるストリームが非常に短時間に単一のルータに集中した場合、そのルータのバッファメモリの制限される容量はストリームのそのボリュームを処理できなくしてしまい、そのルータは一部のパケットを拒否又は破棄してしまう。そのような状況が発生した場合、ネットワークは輻輳していると言う。そのような状況が発生した場合、ネットワークにおける転送は非常に遅くなり、ネットワークの処理量は低下する。ネットワークの特定のリソースが再送に使用されるため、ネットワークが過負荷状態になった場合、ネットワーク全体のブロッキング及び輻輳の伝播が発生する危険性は高い。
ＴＣＰ ＭＳＳ（最大セグメントサイズ）フィールドの値は、ローカルシステムが受け入れ可能なＩＰデータグラム毎のＴＣＰデータの最大量を示す。ＩＰデータグラムは、送出されると、いくつかのパケットに分割される。理論上、この値は値６５４９５に到達可能である。しかし、そのような大きな値が実現されることはない。一般に、端末システムは、ＭＴＵインタフェース（出力インタフェース最大転送単位）を使用する。値４０は、ＭＴＵインタフェースからＴＣＰ ＭＳＳフィールド値として演繹される。例えば、イーサネットプロトコルのＴＣＰ ＭＳＳフィールド値は１４６０（1500 - 40 = 1460）である。
ＴＣＰ ＭＳＳフィールドの値は、接続をセットアップするのに使用され且つ信号ＳＹＮを含むパケットに入力される。各側が自身のＴＣＰ ＭＳＳフィールド値を送出する。各側が同一のＴＣＰ ＭＳＳフィールド値を使用する必要はないが、各側はリモート局により許可されたデータより多くのデータを送出できない。ＴＣＰ ＭＳＳフィールドの値は、ＴＣＰヘッダオプションの最大セグメントサイズ（ＭＳＳ）で送出される。
尚、接続インタフェースのバッファメモリのサイズのデフォルト値は実現例の機能によって非常に異なる。Berkeleyから得られる古い実現例は、ＴＣＰ受信／送出バッファメモリに対して４Ｋｂのデフォルト値を要求するが、より最近のシステムは更に大きな値（例えば、最大６４Ｋｂ）を実現する。例えばＷｉｎｄｏｗｓ（登録商標） XP（登録商標）において、受信時のウィンドウサイズの現在の値は、ＴＣＰ接続がセットアップされた時に交渉された最大セグメントサイズ（ＭＳＳ）単位で自動的に調整される。
ストリームの制御
ＴＣＰプロトコルは、輻輳を管理するためにいくつかのアルゴリズムを使用する。更に詳細には、スロースタート及び輻輳回避アルゴリズムを使用する。それらのアルゴリズムの各々は、既定の時点において通過中の未確認のバイト数を制限する輻輳ウィンドウ（ＣＷＮＤ）を操作することによりサーバの送出処理量を管理する。既定の輻輳ウィンドウ値に対する可能なＴＣＰ処理量は、確認応答が受信される際の速度により判定される。１つのデータを送出してから確認応答を受信するまでにかかる時間は、ＴＣＰラウンドトリップ時間（ＲＴＴ）と呼ばれる。
ＴＣＰプロトコルは、輻輳を管理するためにいくつかのアルゴリズムを使用する。更に詳細には、スロースタート及び輻輳回避アルゴリズムを使用する。それらのアルゴリズムの各々は、既定の時点において通過中の未確認のバイト数を制限する輻輳ウィンドウ（ＣＷＮＤ）を操作することによりサーバの送出処理量を管理する。既定の輻輳ウィンドウ値に対する可能なＴＣＰ処理量は、確認応答が受信される際の速度により判定される。１つのデータを送出してから確認応答を受信するまでにかかる時間は、ＴＣＰラウンドトリップ時間（ＲＴＴ）と呼ばれる。
接続が開始されると、可能な限り迅速に帯域幅の値を得るために、スロースタートアルゴリズムは輻輳ウィンドウ（ＣＷＮＤ）を迅速に増加するためにセットアップされる。可変ＳＳＴＨＲＥＳＨ（定常閾値）は、２つのフェーズを区別するためにサーバにより維持される。セグメントの損失があると送信機が判断した場合、送信機はネットワーク過負荷の暗黙信号としてその情報を処理し、輻輳ウィンドウを迅速に低減する。大よその輻輳閾値ＳＳＴＨＲＥＳＨを演繹した後、ＴＣＰは、利用可能な追加の帯域幅を占有するために輻輳ウィンドウの値を更にゆっくり増加する輻輳回避アルゴリズムをセットアップする。
スロースタートフェーズ中（接続を開始する時又はタイムアウトを超えた後）、始動器は１ＭＳＳのＣＷＮＤウィンドウ設定動作から開始し、ＣＷＮＤは確認応答を受信する毎に1*MSSだけ増加する。輻輳ウィンドウＣＷＮＤはＲＴＴ毎に約２倍になる（指数関数的増加）。輻輳回避フェーズ中（輻輳回避中）、ＣＷＮＤの増加はＲＴＴ毎に1*MSSに制限される（加法的増加）。
性能の低下は、伝播時間が長時間であるインターネットにおいて示される。これは、送信ウィンドウが新しいセグメントを迅速に送出することを防止する（確認応答は送信ウィンドウのサイズの増加を判定し、確認応答は長時間後に到着する）。
輻輳及び重複確認応答（重複ＡＣＫ）の検出
ＴＣＰ接続に対して、サーバ装置が同一の確認応答シーケンス番号を有するいくつかのＡＣＫを受信する場合、用語「重複確認応答」（又は重複ＡＣＫ）が使用される。サーバは、指定されたデータシーケンス番号に対応するデータセグメントを再送する。サーバが重複ＡＣＫを受信しない場合又はサーバがデータセグメント送出後の判定された期間中に他のＡＣＫ（別の確認応答シーケンス番号を有する）を受信しない場合であっても、サーバはその未確認のデータセグメントを再送する。
ＴＣＰ接続に対して、サーバ装置が同一の確認応答シーケンス番号を有するいくつかのＡＣＫを受信する場合、用語「重複確認応答」（又は重複ＡＣＫ）が使用される。サーバは、指定されたデータシーケンス番号に対応するデータセグメントを再送する。サーバが重複ＡＣＫを受信しない場合又はサーバがデータセグメント送出後の判定された期間中に他のＡＣＫ（別の確認応答シーケンス番号を有する）を受信しない場合であっても、サーバはその未確認のデータセグメントを再送する。
一般に、ＴＣＰクライアントは、順序が違うデータセグメントの受信時に（即ち、ＴＣＰクライアントが予想したデータシーケンス番号より大きいデータシーケンス番号のデータセグメントを受信した場合に）重複確認応答又は重複ＡＣＫを送出する。重複ＡＣＫの目的は、データセグメントが順序を間違って受信されたことをサーバに通知し、予想されたデータシーケンス番号を知らせることである。重複ＡＣＫのバーストは、伝送経路における損失データセグメント及び／又はデータセグメントの再スケジューリングの結果である。
高速再送アルゴリズム及び高速回復アルゴリズム
ＴＣＰプロトコルは、重複ＡＣＫの受信により識別されるパケット損失を迅速に検出してそれに反応するためにＩＥＴＦ ＲＦＣ２５８１インターネット規格に記述される高速再送アルゴリズム（機構）を使用する。高速再送アルゴリズムは、３つの重複ＡＣＫ（実際には、４つの同一の確認応答又はＡＣＫであり、想定される問題が正常に戻されたことを示す他の確認応答を含まない）の到着をデータセグメントが損失されたことの指示と考える。２つ以下の重複ＡＣＫが受信される場合、考慮されるセグメントに対する確認応答により解決され追従されるパケットの非スケジューリングの短時間の問題であったと考えられる。これらの３つの重複ＡＣＫを受信すると、サーバはＲＴＯの満了又は再送タイムアウトを待たずに失われたデータセグメントを再送する。
ＴＣＰプロトコルは、重複ＡＣＫの受信により識別されるパケット損失を迅速に検出してそれに反応するためにＩＥＴＦ ＲＦＣ２５８１インターネット規格に記述される高速再送アルゴリズム（機構）を使用する。高速再送アルゴリズムは、３つの重複ＡＣＫ（実際には、４つの同一の確認応答又はＡＣＫであり、想定される問題が正常に戻されたことを示す他の確認応答を含まない）の到着をデータセグメントが損失されたことの指示と考える。２つ以下の重複ＡＣＫが受信される場合、考慮されるセグメントに対する確認応答により解決され追従されるパケットの非スケジューリングの短時間の問題であったと考えられる。これらの３つの重複ＡＣＫを受信すると、サーバはＲＴＯの満了又は再送タイムアウトを待たずに失われたデータセグメントを再送する。
その後、高速回復アルゴリズムは開始され、非重複ＡＣＫを受信するまで新しいデータの送信を管理する。ＴＣＰクライアントが別のデータセグメントの到着時にのみ重複ＡＣＫを送出できるため、これは、１つのデータセグメント（しかし、予想されたデータセグメントではない）が受信され、ネットワークのリソースをそれ以上使用しないことを意味する。従って、常にネットワーク上にアクティビティが存在し、ＴＣＰサーバは新しいデータセグメントを送信し続けられる（送信は低減された輻輳ウィンドウＣＷＮＤで継続する）。
上述の２つのアルゴリズム（高速再送アルゴリズム及び高速回復アルゴリズム）は、ＴＣＰサーバにおいて以下のように共にセットアップされる。
１．第３の重複ＡＣＫの受信時、値ＳＳＴＨＲＥＳＨは以下の最大値を超えないように変更される：
SSTHRESH = max(FlightSize/2, 2*MSS)
式中：
−値「flightsize」は、サーバがクライアントから確認応答をまだ受信していない通過中のパケットの推定を与える；
−値ＭＳＳは、ローカルシステムが伝送経路において受け入れ可能なＩＰデータグラム毎のＴＣＰデータの最大量を示す。
SSTHRESH = max(FlightSize/2, 2*MSS)
式中：
−値「flightsize」は、サーバがクライアントから確認応答をまだ受信していない通過中のパケットの推定を与える；
−値ＭＳＳは、ローカルシステムが伝送経路において受け入れ可能なＩＰデータグラム毎のＴＣＰデータの最大量を示す。
２．損失されたと考えられるセグメントの再送及び輻輳ウィンドウＣＷＮＤの(SSTHRESH + 3*MSS)への更新。これにより、輻輳ウィンドウは、ネットワークに出力され且つクライアントにより正確に受信されているセグメント数（３）だけ増加する。
３．サーバにより受信される新しい各重複ＡＣＫに対して、輻輳ウィンドウＣＷＮＤは1*MSSだけ増加する。
４．輻輳ウィンドウＣＷＮＤの新しい値及びクライアントにより示される確認応答ウィンドウ（「広告ウィンドウ」）の値により許可される場合、データセグメントを送信する。
５．再送元においてデータセグメントのクライアントによる受信を確認する次のＡＣＫの受信時、輻輳ウィンドウＣＷＮＤはステップ１で計算された値ＳＳＴＨＲＥＳＨに低下する。このＡＣＫメッセージは、再送の後、当然１サイクルのＲＴＴより前に到着している（或いは、問題の原因がデータセグメントのクライアントへの間違った順序の配信であった場合には更に早い）。ＴＣＰビットレートは、損失が発生した時のビットレートの半分に低下するため、輻輳回避のフェーズが存在する。
最も一般的なＴＣＰオプション
選択的確認応答（ＳＡＣＫ）
ＳＡＣＫオプションは、選択的再送［ＲＦＣ２０１８］のポリシーを実現するために使用されるＴＣＰプロトコルオプションである。このオプションは、損失の回復のために更に詳細な情報を供給することを目的とする。実際には、累積肯定ＡＣＫは制限された情報を与え、ＴＣＰ送信元はＲＴＴ毎に１つのパケット損失の存在のみを知る。ＳＡＣＫ拡張は、この制限を超えるＴＣＰプロトコル手段を与える。
選択的確認応答（ＳＡＣＫ）
ＳＡＣＫオプションは、選択的再送［ＲＦＣ２０１８］のポリシーを実現するために使用されるＴＣＰプロトコルオプションである。このオプションは、損失の回復のために更に詳細な情報を供給することを目的とする。実際には、累積肯定ＡＣＫは制限された情報を与え、ＴＣＰ送信元はＲＴＴ毎に１つのパケット損失の存在のみを知る。ＳＡＣＫ拡張は、この制限を超えるＴＣＰプロトコル手段を与える。
ＳＡＣＫ機構は、受信機（クライアント）がＴＣＰストリームにおいてシーケンスの中断を認識するとすぐに実現される。受信機は、シーケンスにおいて受信した最後のバイト番号（ＴＣＰエントリの従来のＡＣＫフィールド）及び現在のウィンドウで観察されるシーケンスにおける最後の中断の位置を示すために使用される現在正確に受信されているバイトの連続範囲のリストを含む選択的確認応答（選択的ＡＣＫ）を送信機に送出する。
選択的確認応答［ＲＦＣ２０１８に従う］は、損失毎に１つ以上のラウンドトリップを実行する必要なくウィンドウ毎にいくつかのセグメントの損失を克服するために使用される。
「送信制限」アルゴリズム
上述したように、既定のセグメントの再送は、３つの重複ＡＣＫの受信後に実行される。後続するセグメントに対する他の損失がある場合、これは、受信される最後の連続するシーケンス番号の正確なＡＣＫを受信するまでに更に１サイクルのＲＴＴを必要とする。識別されたセグメントが損失されたことを理解するのに３つの他の重複ＡＣＫが必要とされる。
上述したように、既定のセグメントの再送は、３つの重複ＡＣＫの受信後に実行される。後続するセグメントに対する他の損失がある場合、これは、受信される最後の連続するシーケンス番号の正確なＡＣＫを受信するまでに更に１サイクルのＲＴＴを必要とする。識別されたセグメントが損失されたことを理解するのに３つの他の重複ＡＣＫが必要とされる。
現在のＣＷＮＤウィンドウによっては、サーバは、必要な全ての重複ＡＣＫを生成するのに十分な数のデータセグメントを送出できない可能性がある。
従って、ＲＴＯは満了になり、サーバはスロースタートモードになる。
規格ＲＦＣ３０４２（Enhancing TCP's Loss Recovery Using Limited Transmit（送信制限を使用する拡張ＴＣＰの損失回復））は、タイムアウトの回数を減少することを目的とする。従って、送信制限アルゴリズムは、受信された最後の２つの重複ＡＣＫの各々に対してサーバがデータセグメントを送出することを推奨する。この方法により、クライアントが誤りを通知するのに必要な３つの重複ＡＣＫを送出できる確率は増加する。
送信制限機構は、ＳＡＣＫ機構と共に又はＳＡＣＫ機構とは関係なく使用できる。
Claims (19)
- トンネルのトランスポートチャネル上のデータストリームの送信を管理する方法であって、各ストリームの送信はパケットによりスケジュールされるトランスポートプロトコルに従って確認応答と共に前記トランスポートチャネル上に実行され、前記トンネルは第１のサブネットワーク及び第２のサブネットワークにそれぞれ接続される第１のトンネル終点と第２のトンネル終点との間に実現され、各ストリームは送信側デバイスから受信側デバイスに送信され、前記送信側デバイス及び前記受信側デバイスのうち、一方のデバイスは第１のサブネットワークに接続され、他方のデバイスは第２のサブネットワークに接続され、前記第１のトンネル終点により実行され、前記方法は、
前記トンネルのトランスポートチャネル上のパケットの損失を検出する工程と、
前記損失によりトンネルのトランスポートチャネル上でブロックされた少なくとも１つのパケットを有する少なくとも１つのストリームを識別する工程と、
前記少なくとも１つの識別されたストリームに対して、前記損失によりブロックされたパケットを送信した送信側デバイスに、前記トンネル上に少なくとも１つの確認応答を生成及び送信する工程とを有することを特徴とする方法。 - 少なくとも１つの既定の識別されたストリームに対して、前記少なくとも１つの生成された確認応答は、前記損失によりブロックされた前記識別されたストリームの第１のパケットに先行するパケットの確認応答であり、損失が検出されたパケットが属する識別されたストリームに対して、前記損失によりブロックされた第１のパケットは、損失の検出に続いて前記トンネルのトランスポートチャネル上で再送されるパケットであると見なされることを特徴とする請求項１に記載の方法。
- 少なくとも１つの既定の識別されたストリームに対して、少なくとも１つの確認応答を生成及び送信する前記工程は、
前記既定の識別されたストリームを送信する送信側デバイスと関連付けられる再送タイムアウトの期間を推定する関数及び前記損失によりブロックされる前記識別されたストリームの第１のパケットに先行する前記パケットのトンネル終点による処理の処理瞬間の関数として第１の確認応答を送出する第１の送出瞬間ｔ１を判定する工程と、
前記第１の送出瞬間ｔ１に前記第１の確認応答を送信する工程とを有することを特徴とする請求項１に記載の方法。 - 前記第１の送出瞬間ｔ１は、t1 = t0 + RTO' - Δにより定義され、式中、
ｔ０は、前記損失によりブロックされる前記識別されたストリームの第１のパケットに先行する前記パケットの前記第１のトンネル終点における処理の前記処理瞬間であり、
ＲＴＯ’は、前記既定の識別されたストリームを送信する送信側デバイスと関連付けられる再送タイムアウトの期間の前記推定であり、
Δは、予め定められた安全余裕度であることを特徴とする請求項１に記載の方法。 - 少なくとも１つの既定の識別されたストリームに対して、少なくとも１つの確認応答の生成及び送信の前記工程は、
ｔ１が１回目の繰り返しの場合に前記第１の送出瞬間であり又は２回目以降の各繰り返しの場合に先行する繰り返しにおいて判定される新しい送出瞬間ｔ２である時、t2 = t1 + RTO' - Δにより定義される新しい確認応答を送出する新しい送出瞬間ｔ２を判定する工程と、
前記新しい送出瞬間ｔ２において前記新しい確認応答を送信する工程との少なくとも１回の繰り返しを有することを特徴とする請求項４に記載の方法。 - RTO' = 2.RTTであり、ＲＴＴはトンネルにおけるラウンドトリップ時間の測定値であることを特徴とする請求項４に記載の方法。
- 少なくとも１つの既定の識別されたストリームに対して、少なくとも１つの確認応答を生成及び送信する前記工程において、トンネルのトランスポートチャネルを通過中であり且つ前記損失によりブロックされる前記既定の識別されたストリームのパケット数が前記既定の識別されたストリームに対して前記第１のトンネル終点により生成及び送信される確認応答の数より多いという第１の条件が検証される場合にのみ、確認応答は生成及び送信されることを特徴とする請求項１に記載の方法。
- 少なくとも１つの既定の識別されたストリームに対して、少なくとも１つの確認応答を生成及び送信する前記工程において、前記既定の識別されたストリームに対して前記第１のトンネル終点により生成及び送信される確認応答の数が前記既定の識別されたストリームを送信する送信側デバイスに対してパケット損失を示す予め定められた閾値以下であるという第２の条件が検証される場合にのみ、確認応答は生成及び送信されることを特徴とする請求項１に記載の方法。
- 少なくとも１つの既定の識別されたストリームに対して、前記第１のトンネル終点が確認応答を既に生成及び送信した前記既定の識別されたストリームの受信側デバイスからトンネルを介して到達する確認応答をフィルタリングする工程を有することを特徴とする請求項１に記載の方法。
- コンピュータ読み取り可能な記憶媒体であって、トンネルのトランスポートチャネル上のデータストリームの送信を管理する方法をコンピュータに実行させるためのプログラムを記憶し、各ストリームの送信はパケットによりスケジュールされるトランスポートプロトコルに従って確認応答と共に前記トランスポートチャネル上に実行され、前記トンネルは第１のサブネットワーク及び第２のサブネットワークにそれぞれ接続される第１のトンネル終点と第２のトンネル終点との間に実現され、各ストリームは送信側デバイスから受信側デバイスに送信され、前記送信側デバイス及び前記受信側デバイスのうち、一方のデバイスは第１のサブネットワークに接続され、他方のデバイスは第２のサブネットワークに接続され、前記第１のトンネル終点により実行され、前記方法は、
前記トンネルのトランスポートチャネル上のパケットの損失を検出する工程と、
前記損失によりトンネルのトランスポートチャネル上でブロックされた少なくとも１つのパケットを有する少なくとも１つのストリームを識別する工程と、
前記少なくとも１つの識別されたストリームに対して、前記損失によりブロックされたパケットを送信した送信側デバイスに、前記トンネル上に少なくとも１つの確認応答を生成及び送信する工程とを有することを特徴とする記憶媒体。 - トンネルのトランスポートチャネル上のデータストリームの送信の管理を可能にする第１のトンネル終点であって、各ストリームの送信はパケットによりスケジュールされるトランスポートプロトコルに従って確認応答を使用して前記トランスポートチャネルに対して実行され、トンネルは第１のサブネットワーク及び第２のサブネットワークにそれぞれ接続される第１のトンネル終点と第２のトンネル終点との間に実現され、各ストリームは送信側デバイスから受信側デバイスに送信され、前記送信側デバイス及び前記受信側デバイスのうち、一方のデバイスは第１のサブネットワークに接続され、他方のデバイスは第２のサブネットワークに接続され、前記第１のトンネル終点は、
前記トンネルのトランスポートチャネル上のパケットの損失を検出する手段と、
前記損失によりトンネルのトランスポートチャネル上でブロックされた少なくとも１つのパケットを有する少なくとも１つのストリームを識別する手段と、
前記少なくとも１つの識別されたストリームに対して、前記損失によりブロックされたパケットを送信した送信側デバイスに、前記トンネル上に少なくとも１つの確認応答を生成及び送信する手段とを有することを特徴とする第１のトンネル終点。 - 少なくとも１つの既定の識別されたストリームに対して、前記少なくとも１つの生成された確認応答は、前記損失によりブロックされた前記識別されたストリームの第１のパケットに先行するパケットの確認応答であり、損失が検出されたパケットが属する識別されたストリームに対して、前記損失によりブロックされた第１のパケットは、損失の検出に続いて前記トンネルのトランスポートチャネル上に再送されるパケットであると見なされることを特徴とする請求項１１に記載の第１のトンネル終点。
- 少なくとも１つの確認応答を生成及び送信する前記手段は、
少なくとも１つの既定の識別されたストリームに対して、前記既定の識別されたストリームを送信する送信側デバイスと関連付けられる再送タイムアウトの期間の推定の関数及び前記損失によりブロックされる前記識別されたストリームの第１のパケットに先行する前記パケットの前記トンネル終点による処理の処理瞬間の関数として第１の確認応答を送出する第１の送出瞬間ｔ１を判定する手段と、
前記第１の送出瞬間ｔ１に前記第１の確認応答を送信する手段とを有することを特徴とする請求項１１に記載の第１のトンネル終点。 - 前記第１の送出瞬間ｔ１は、t1 = t0 + RTO' - Δにより定義され、式中、
ｔ０は、前記損失によりブロックされる前記識別されたストリームの第１のパケットに先行する前記パケットの前記第１のトンネル終点における処理の前記処理瞬間であり、
ＲＴＯ’は、前記既定の識別されたストリームを送信する送信側デバイスと関連付けられる再送タイムアウトの期間の前記推定であり、
Δは、予め定められた安全余裕度であることを特徴とする請求項１１に記載の第１のトンネル終点。 - 少なくとも１つの確認応答を生成及び送信する前記手段は、
ｔ１が１回目の繰り返しの場合に前記第１の送出瞬間であり又は２回目以降の各繰り返しの場合に先行する繰り返しにおいて判定される新しい送出瞬間ｔ２である時、少なくとも１つの識別されたストリームに対して、t2 = t1 + RTO' - Δにより定義される新しい確認応答を送出する新しい送出瞬間ｔ２を判定する手段と、
前記新しい送出瞬間ｔ２に前記新しい確認応答を送信する手段とを有し、それらの手段は少なくとも１回起動されることを特徴とする請求項１４に記載の第１のトンネル終点。 - RTO' = 2.RTTであるのが有利であり、ＲＴＴはトンネルにおけるラウンドトリップ時間の測定値であることを特徴とする請求項１４に記載の第１のトンネル終点。
- 少なくとも１つの既定の識別されたストリームに対して、トンネルのトランスポートチャネルを通過中であり且つ前記損失によりブロックされる前記既定の識別されたストリームのパケット数が前記既定の識別されたストリームに対して前記第１のトンネル終点により生成及び送信される確認応答の数より多いという第１の条件を検証する第１の検証手段と、
前記第１の検証手段が肯定の検証を行った場合に前記少なくとも１つの既定の識別されたストリームに対して少なくとも１つの確認応答を生成及び送信する前記手段を起動する手段とを更に有することを特徴とする請求項１１に記載の第１のトンネル終点。 - 少なくとも１つの既定の識別されたストリームに対して、前記既定の識別されたストリームに対して前記第１のトンネル終点により生成及び送信される確認応答の数が前記既定の識別されたストリームを送信する送信側デバイスに対してパケット損失を示す予め定められた閾値以下であるという第２の条件を検証する第２の検証手段と、
前記第２の検証手段が肯定の検証を行った場合に前記少なくとも１つの既定の識別されたストリームに対して少なくとも１つの確認応答を生成及び送信する前記手段を起動する手段とを更に有することを特徴とする請求項１１に記載の第１のトンネル終点。 - 少なくとも１つの既定の識別されたストリームに対して、前記第１のトンネル終点が確認応答を既に生成及び送信した前記既定の識別されたストリームの受信側デバイスからトンネルを介して到達する確認応答をフィルタリングする手段を更に有することを特徴とする請求項１１に記載の第１のトンネル終点。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0854784 | 2008-07-11 | ||
| FR0854784A FR2933834A1 (fr) | 2008-07-11 | 2008-07-11 | Procede de gestion d'une transmission de flux de donnees sur un canal de transport d'un tunnel, tete de tunnel, produit programme d'ordinateur et moyen de stockage correspondants. |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2010022001A true JP2010022001A (ja) | 2010-01-28 |
| JP5005003B2 JP5005003B2 (ja) | 2012-08-22 |
Family
ID=40030273
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2009162185A Expired - Fee Related JP5005003B2 (ja) | 2008-07-11 | 2009-07-08 | トンネルのトランスポートチャネル上のデータストリームの送信を管理する方法、対応するトンネル終点及びコンピュータ読み取り可能な記憶媒体 |
Country Status (7)
| Country | Link |
|---|---|
| US (1) | US8072898B2 (ja) |
| EP (1) | EP2144403B1 (ja) |
| JP (1) | JP5005003B2 (ja) |
| CN (1) | CN101635665B (ja) |
| AT (1) | ATE507636T1 (ja) |
| DE (1) | DE602009001149D1 (ja) |
| FR (1) | FR2933834A1 (ja) |
Families Citing this family (22)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4692355B2 (ja) * | 2006-03-30 | 2011-06-01 | ブラザー工業株式会社 | 情報通信システム、情報通信方法、情報通信システムに含まれるノード装置および情報処理プログラム |
| JP5318111B2 (ja) * | 2007-10-24 | 2013-10-16 | ラントロニクス・インコーポレイテツド | リモートデバイスに構成情報を自動配布するための中央管理ステーションのための種々の方法および装置 |
| FR2939993B1 (fr) * | 2008-12-12 | 2010-12-17 | Canon Kk | Procede de transmission d'un flux de donnees multi-canal sur un tunnel multi-transport, produit programme d'ordinateur, moyen de stockage et tetes de tunnel correspondantes |
| US9756468B2 (en) | 2009-07-08 | 2017-09-05 | Dejero Labs Inc. | System and method for providing data services on vehicles |
| US10033779B2 (en) | 2009-07-08 | 2018-07-24 | Dejero Labs Inc. | Multipath data streaming over multiple wireless networks |
| US10117055B2 (en) | 2009-07-08 | 2018-10-30 | Dejero Labs Inc. | System and method for providing data services on vehicles |
| US8625622B2 (en) * | 2009-12-25 | 2014-01-07 | Cisco Technology, Inc. | Increasing transmission rate to a remote device in response to attributing information loss as not being a result of network congestion |
| KR101413295B1 (ko) * | 2010-11-04 | 2014-06-30 | 한국전자통신연구원 | 확장성과 적응성을 가지는 ｄｄｓ 구조 및 ｄｄｓ를 구성하는 노드 |
| KR101741003B1 (ko) * | 2011-01-28 | 2017-05-30 | 삼성전자주식회사 | 중복된 애크를 이용한 통신 방법 |
| JP5963540B2 (ja) * | 2012-05-30 | 2016-08-03 | キヤノン株式会社 | 情報処理装置、プログラム及び制御方法 |
| US20150046558A1 (en) * | 2013-03-15 | 2015-02-12 | Google Inc. | System and method for choosing lowest latency path |
| CN107196834B (zh) | 2013-07-12 | 2021-08-13 | 华为技术有限公司 | 报文处理方法及设备 |
| US20150095196A1 (en) * | 2013-09-30 | 2015-04-02 | Jewel Burks | Method for Identifying Replacement Parts and Extracting Features Via a Sequence of Images |
| EP3068163B1 (en) * | 2013-11-06 | 2020-07-22 | Nec Corporation | Mobile communication system, gateway device and communication method |
| WO2015069164A1 (en) | 2013-11-08 | 2015-05-14 | Telefonaktiebolaget L M Ericsson (Publ) | Handling of transport conditions |
| EP3101821B1 (en) * | 2014-01-28 | 2021-07-07 | Mitsubishi Electric Corporation | Satellite communication system, satellite repeater, and satellite communication method |
| JP5970489B2 (ja) * | 2014-01-30 | 2016-08-17 | 株式会社Ｎｔｔドコモ | 移動通信システム及び移動局装置 |
| US9742587B2 (en) * | 2015-07-29 | 2017-08-22 | Oracle International Corporation | Negative acknowledgment of tunneled encapsulated media |
| US10805420B2 (en) * | 2017-11-29 | 2020-10-13 | Forcepoint Llc | Proxy-less wide area network acceleration |
| CN108833063B (zh) * | 2018-08-29 | 2021-04-27 | 新华三技术有限公司 | 一种报文重传方法及装置 |
| CN112585910B (zh) * | 2020-09-15 | 2022-03-08 | 香港应用科技研究院有限公司 | 在广域网中建立安全、低延迟、优化路径的方法和装置 |
| US11743193B2 (en) | 2021-11-01 | 2023-08-29 | Seagate Technology Llc | Sliding window protocol for communication among more than two participants |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2001036586A (ja) * | 1999-07-21 | 2001-02-09 | Oki Electric Ind Co Ltd | ゲートウェイ装置 |
| JP2008078966A (ja) * | 2006-09-21 | 2008-04-03 | Nec Corp | 通信システム、トンネリング装置、通信方法、およびプログラム |
Family Cites Families (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6208620B1 (en) * | 1999-08-02 | 2001-03-27 | Nortel Networks Corporation | TCP-aware agent sublayer (TAS) for robust TCP over wireless |
| US7219158B2 (en) * | 2000-07-21 | 2007-05-15 | Hughes Network Systems Llc | Method and system for improving network performance using a performance enhancing proxy |
| US6934257B2 (en) * | 2001-04-04 | 2005-08-23 | Intel Corporation | Transferring transmission control protocol packets |
| US7089312B2 (en) * | 2001-09-20 | 2006-08-08 | Intel Corporation | System and method for reducing retransmissions due to tunneled TCP-in-TCP communication in a network |
| US20030172264A1 (en) * | 2002-01-28 | 2003-09-11 | Hughes Electronics | Method and system for providing security in performance enhanced network |
| US20030219022A1 (en) * | 2002-01-28 | 2003-11-27 | Hughes Electronics | Method and system for utilizing virtual private network (VPN) connections in a performance enhanced network |
| US7398552B2 (en) * | 2002-01-28 | 2008-07-08 | Hughes Network Systems, Llc | Method and system for integrating performance enhancing functions in a virtual private network (VPN) |
| US7656799B2 (en) * | 2003-07-29 | 2010-02-02 | Citrix Systems, Inc. | Flow control system architecture |
| FR2863127A1 (fr) | 2003-12-02 | 2005-06-03 | Canon Kk | Procedes et dispositifs pour la delivrance asynchrone de donnees numeriques |
| CN1956353B (zh) * | 2005-10-28 | 2011-07-20 | 华为技术有限公司 | 基于隧道进行流管理的方法和无线接入中转系统 |
| EP1850531B1 (en) * | 2006-04-26 | 2013-06-12 | Alcatel Lucent | Method and architecture for interworking of standardised networks |
| US7760642B2 (en) * | 2007-03-12 | 2010-07-20 | Citrix Systems, Inc. | Systems and methods for providing quality of service precedence in TCP congestion control |
| FR2919778A1 (fr) | 2007-07-30 | 2009-02-06 | Canon Kk | Procede de transmission de paquets de donnees dans un tunnel, produit programme d'ordinateur, moyen de stockage et tete de tunnel correspondants |
| FR2926939A1 (fr) | 2008-01-30 | 2009-07-31 | Canon Kk | Procede de transmission de donnees avec anticipation des acquittements, dispositif d'entree, produit programme d'ordinateur et moyen de stockage correspondants |
-
2008
- 2008-07-11 FR FR0854784A patent/FR2933834A1/fr not_active Withdrawn
-
2009
- 2009-06-19 US US12/488,402 patent/US8072898B2/en not_active Expired - Fee Related
- 2009-06-30 DE DE602009001149T patent/DE602009001149D1/de active Active
- 2009-06-30 AT AT09164124T patent/ATE507636T1/de not_active IP Right Cessation
- 2009-06-30 EP EP09164124A patent/EP2144403B1/en active Active
- 2009-07-08 JP JP2009162185A patent/JP5005003B2/ja not_active Expired - Fee Related
- 2009-07-10 CN CN2009101401963A patent/CN101635665B/zh not_active Expired - Fee Related
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2001036586A (ja) * | 1999-07-21 | 2001-02-09 | Oki Electric Ind Co Ltd | ゲートウェイ装置 |
| JP2008078966A (ja) * | 2006-09-21 | 2008-04-03 | Nec Corp | 通信システム、トンネリング装置、通信方法、およびプログラム |
Also Published As
| Publication number | Publication date |
|---|---|
| US20100008245A1 (en) | 2010-01-14 |
| CN101635665B (zh) | 2012-03-21 |
| CN101635665A (zh) | 2010-01-27 |
| EP2144403B1 (en) | 2011-04-27 |
| US8072898B2 (en) | 2011-12-06 |
| EP2144403A1 (en) | 2010-01-13 |
| FR2933834A1 (fr) | 2010-01-15 |
| JP5005003B2 (ja) | 2012-08-22 |
| DE602009001149D1 (de) | 2011-06-09 |
| ATE507636T1 (de) | 2011-05-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP5005003B2 (ja) | トンネルのトランスポートチャネル上のデータストリームの送信を管理する方法、対応するトンネル終点及びコンピュータ読み取り可能な記憶媒体 | |
| US8169911B2 (en) | Method for transmitting a data stream with anticipation of acknowledgments, correspondence input device and computer-readable storage medium | |
| US10237153B2 (en) | Packet retransmission method and apparatus | |
| US8605590B2 (en) | Systems and methods of improving performance of transport protocols | |
| Fairhurst et al. | Advice to link designers on link Automatic Repeat reQuest (ARQ) | |
| JP4829896B2 (ja) | データ破壊を避けることによる改善されたネットワーク性能のための方法、システム及び物品 | |
| US8717900B2 (en) | Mechanisms to improve the transmission control protocol performance in wireless networks | |
| TWI530123B (zh) | Communication devices and communication methods | |
| US20090316719A1 (en) | Method for managing mechanisms to enhance transmission of data streams in a tunnel, corresponding computer program product, storage medium and tunnel end-point | |
| US11956099B2 (en) | Multi-part TCP connection over VPN | |
| US11671377B2 (en) | System and method for reducing bandwidth usage of a network | |
| US20110141904A1 (en) | Method and apparatus for transmitting packets of a two-way passenger data stream | |
| JP2008078966A (ja) | 通信システム、トンネリング装置、通信方法、およびプログラム | |
| CN113424578B (zh) | 一种传输控制协议加速方法和装置 | |
| JP2006148727A (ja) | アプリケーションモニタ装置 | |
| JP2008199431A (ja) | 通信装置 | |
| KR101396785B1 (ko) | 네트워크 장치에서 tcp 기능을 수행하는 방법 | |
| Callegari et al. | A Friendliness Study of TCP Linux Variants |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20110617 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20110701 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20110825 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20120423 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20120522 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20150601 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20150601 Year of fee payment: 3 |
|
| LAPS | Cancellation because of no payment of annual fees |