JP2008536339A

JP2008536339A - 事実上輻輳のないギャランティードサービス対応ネットワーク：外部インターネットＮｅｘｔＧｅｎＴＣＰ（方形波形）ＴＣＰフレンドリＳＡＮの即座の準備のできた実施

Info

Publication number: JP2008536339A
Application number: JP2007542358A
Authority: JP
Inventors: タンボブ
Original assignee: Individual
Current assignee: Individual
Priority date: 2004-11-29
Filing date: 2005-11-29
Publication date: 2008-09-04
Also published as: IL183431A0; MX2007006395A; BRPI0518691A2; EA200701168A1

Abstract

既存のＱｏＳ／ＭＰＬＳ技法の使用を必要とせず、ネットワーク内のスイッチ／ルータソフトウェアのいずれかがエンドツーエンド性能結果を達成するために変更されるか寄与することを必要とせず、ネットワーク内の各すべてのノード間リンクでの制限されない帯域幅の提供を必要としない、事実上輻輳のないギャランティードサービス対応ネットワークの外部インターネット上での即座の準備ができた実装のための、ＴＣＰ／ＩＰプロトコル及び他の可能なプロトコルと関連するネットワークのスイッチ／ルータ構成とに対する単純な変更のさまざまな技法を提示する。

Description

［注：本発明は、同一発明人による以前に出願された関連の公開されたＰＣＴ出願第ＷＯ２００５０５３２６５号全体を参照し、以前に出願された特許出願、２００５年３月８日のＧＢ０５０４７８２．４、２００５年５月９日のＧＢ０５０９４４４．６、２００５年６月１５日のＧＢ０５１２２２１．３、及び２００５年１０月１２日のＧＢ０５２０７０６．３の説明全体を参照し（及び／又は本願にまだ含まれていない場合にその段落を組み込み）その優先権を主張するものである。］

現在、サービス品質を保証するためにインターネット上のマルチメディア／音声／ファックス／リアルタイムＩＰアプリケーションを容易にするＲＳＶＰ／ＱｏＳ／ＴＡＧスイッチングなどの実施態様は、実施態様の複雑さから損害を受ける。さらに、ＴｏＳ（データパケット内のｔｙｐｅｏｆｓｅｒｖｉｃｅフィールド）、ＴＡＧベースド、ソースＩＰアドレス、ＭＰＬＳの使用など、複数のベンダの実施態様があり、トラバースされるＱｏＳ対応ルータのそれぞれで、データパケットは、そのデータパケットを転送できるようになる前に、上記のベンダの実施したフィールドのすべてについてスイッチ／ルータによって検査される必要がある（この故に、バッファリング／キューイングされる必要がある）。

したがって、最大伝送レートでＱｏＳデータパケットを搬送するテラビットリンクでは、想像するに、ルータは、各到着するデータパケットを検査し（且つ、バッファリング／キューイングし）、且つ、上記のさまざまなフィールドのすべてを検査するのにＣＰＵ処理時間を費やす必要がある（例えば、それに対して検査されるＱｏＳ優先順位ソースＩＰアドレステーブル自体だけでも、数万個になる場合がある）。したがって、ルータ製造業者の指定したスループット容量（通常のデータパケットの転送に関して）は、重いＱｏＳデータパケット負荷の下で達成されない場合があり、一部のＱｏＳパケットは、総データパケット負荷がリンク帯域幅又はルータ製造業者の指定したデータパケット通常スループット容量を超えていない場合であっても、大きい遅延をこうむるか、捨てられる。また、相互運用標準規格の欠如は、いくつかのＩＰテクノロジの、これらのＱｏＳ付加価値サービスをサポートする約束された能力が、まだ完全には実現されないことを意味する。

本明細書では、既存の技術的現状のＱｏＳ実施態様よりよいサービスの保証を確保するために、データパケットによってトラバースされるスイッチ／ルータがＲＳＶＰ／タグスイッチング／ＱｏＳ機能を必要とすることなく、インターネット／プロプラエタリインターネットセグメント／ＷＡＮ／ＬＡＮ上でのよりよい又は類似するエンドツーエンド受信品質を有するマルチメディア／音声／ファックス／リアルタイムなどのアプリケーションに関するサービス品質を保証する方法を説明する。さらに、データパケットは、既存ＱｏＳベンダの実施態様フィールドのすべてを検査するためのバッファリング／キューイングを必ずしも必要とせず、したがって、上述した起こり得る捨てられるか又は遅延するシナリオを回避し、スイッチ／ルータ製造業者の指定した全スループット容量を容易にすると同時に、リンク帯域幅の全送信レートにおいてさえ、これらのギャランティードサービス（ｇｕａｒａｎｔｅｅｄｓｅｒｖｉｃｅ）データパケットを転送する。

既存のＴＣＰ／ＩＰの同時乗法レート減少及びＲＴＯタイムアウト時のパケット再送信機構よりよい輻輳回復／回避／予防のため及び／又は事実上輻輳のないギャランティードサービスＴＣＰ／ＩＰ機能を可能にするため及び／又は既存の同時乗法レートがタイムアウト及びＲＴＯタイムアウトとして知られるパケット再送信タイムアウトを減らすようにするためにさらに変更される既存ＴＣＰ／ＩＰスタックの変更は、異なるレート減少タイムアウト値及びパケット再送信タイムアウト値を有する別々のプロセスに分離される
ＴＣＰ／ＩＰスタックは、下記のように変更される。

．同時ＲＴＯレート減少及びＲＴＯタイムアウトイベント時のパケット再送信が、ＲＴＯＴｉｍｅｄＯｕｔを有する特定のソース−デスティネーションＴＣＰフローに関するパケット／データユニット転送及びパケット再送信の完全な「ポーズ」の形をとるが、特定のＴＣＰフローの１つ又は定義された個数のパケット／データユニット（ＲＴＯパケット／データユニットとすることができる）を「ポーズ／拡張ポーズ」期間中の完全なポーズインターバルごとに前方に転送できるようにし、
．送信された対応するパケット／データユニットの肯定応答が、「ポーズ」がもたらされる前にデスティネーション受信ＴＣＰ／ＩＰスタックから戻って受信されていない場合のソース／デスティネーションノード対に関する同時ＲＴＯレート減少及びパケット再送信インターバルは、下記になるようにセットされる。

．（Ａ）ネットワーク内のソースノード／デスティネーションノード対の間の非輻輳ＲＴＴ＊必ず１より大きい被乗数、又はソースノード／デスティネーションノード対の間の非輻輳ＲＴＴと、．．．．．．によって導入される遅延に対処するのに十分なインターバルとの和、
又は
（Ｂ）最大の非輻輳ＲＴＴを有するネットワーク内の最も離れたソースノード／デスティネーションノード対の間の非輻輳ＲＴＴ＊必ず１より大きい被乗数、又は最大の非輻輳ＲＴＴを有するネットワーク内の最も離れたソースノード／デスティネーションノード対の間の非輻輳ＲＴＴと、さまざまなコンポーネントによって導入される可変遅延に対処するのに十分なインターバルとの和、
又は
（Ｃ）ある考案されたアルゴリズムに従って、ヒストリカルＲＴＴ値から動的に導出される、例えば、＊必ず１より大きい被乗数、又はさまざまなコンポーネントによって導入される可変遅延によって導入される遅延に対処するのに十分なインターバルとの和など
又は
（Ｄ）任意のユーザ供給の値、例えば、オーディオ−ビジュアル知覚許容範囲について２００ｍｓ、又は例えばｈｔｔｐウェブページダウンロード知覚許容範囲について４秒．．．など。世界中の最も離れたソースノード／デスティネーションノード対の間のタイムクリティカルなオーディオ−ビジュアルフローについて、非輻輳ＲＴＴが、約２５０ｍｓになる場合があり、この場合に、そのような長距離タイムクリティカルフローのＲＴＯセッティングは、上記の通常のオーディオ−ビジュアル許容範囲期間になり、衛星を介する今日の大陸間携帯電話呼品質と同様に許容される必要があるはずであることに留意されたい。

例えば２００ｍｓのリアルタイムオーディオ−ビジュアルの知覚許容範囲限界内にキャッピングされた上記の（Ａ）、（Ｂ）、（Ｃ）、又は（Ｄ）のＲＴＯインターバル値を用いる場合に、事実上輻輳のないギャランティードサービスのネットワーク性能が達成される。

．「ポーズ」だけであるが、既存の結合された同時ＲＴＯレート減少及びパケット再送信の代わりの又はその代理の、１つ又は定義された個数のパケット／データユニットが完全なポーズインターバル全体の間又は各連続する完全なポーズインターバルの間に転送されることを可能にする、上で説明したＴＣＰ／ＩＰ変更は、インターネット／インターネットのサブセット／ＷＡＮ／ＬＡＮ上で、ＲＴＯ機構上での既存ＴＣＰ／ＩＰ同時乗法レート減少より高速且つよりよい輻輳の回復／回避／予防を機能強化でき、事実上輻輳のないギャランティードサービス機能を使用可能にさえすることに留意されたい。また、既存ＴＣＰ／ＩＰスタックの結合された同時ＲＴＯレート減少及びパケット再送信を、異なるレート減少タイムアウト値及びパケット再送信タイムアウト値を有する別々のプロセスに分離できることに留意されたい。

．また、前の段落のＴＣＰ／ＩＰ変更を、初期の少数のユーザによって増分式に実施できるが、必ずしも、変更された「ポーズ」ＴＣＰ採用者に関するかなり悪い性能影響を有しない場合があり、さらに、変更された「ポーズ」ＴＣＰ／ＩＰを使用して送信されるパケット／データユニットが、ルートに沿ったスイッチ／ルータによってごく希に捨てられ、パケット／データユニットを捨てさせないように微調整され／捨てさせなくすることすらできることに留意されたい。この変更が大多数によって又はあまねく採用されるようになる時に、既存インターネットは、事実上輻輳のないギャランティードサービス機能を達成し、及び／又は輻輳バッファオーバーフローに起因するスイッチ／ルータによるルートに沿ったパケットドロップがない。

例として、ネットワーク／インターネットサブセット／プロプラエタリインターネット／ＷＡＮ／ＬＡＮ内のすべてのスイッチ／ルータのそれぞれが、最小ｓ秒と同等の（すなわち、ｓ秒＊すべての先行する着信リンクの物理帯域幅の合計）バッファサイズを有する／又はそのようにされ、起点センダソースＴＣＰ／ＩＰスタックのＲＴＯタイムアウト又はデカップルドレート減少タイムアウトインターバルに、同一のｓ秒又はそれ未満がセットされる（これは、オーディオ−ビジュアル許容範囲又はｈｔｔｐ許容範囲期間以内とすることができる）場合に、ソースの変更されたＴＣＰ／ＩＰから送信されるすべてのパケット／データユニットは、介在するスイッチ／ルータでの輻輳バッファオーバーフローによって捨てられなくなり、すべてが、ワーストケースにおいて、ｓ秒＊トラバースされるノード数と同等の時間期間又は秒単位のすべての介在するノードのバッファサイズ同等物の合計のうちの大きい方（好ましくは、これは、必要な定義された許容範囲期間以内であり、あるいは、そうなるようにすることができる）以内に到着する。したがって、バッファサイズのすべてが、少なくとも、起点センダ／ソースの変更されたＴＣＰ／ＩＰスタックの同等のＲＴＯタイムアウト又はデカップルドレート減少タイムアウトインターバルセッティング以上であることが、介在するノードのスイッチ／ルータに対するよい実践になる。起点センダソースＴＣＰ／ＩＰスタックは、介在するノードの累積バッファ遅延の合計が起点センダソースＴＣＰ／ＩＰスタックのＲＴＯタイムアウトインターバル又はデカップルドレート減少（本明細書では「ポーズ」の形）タイムアウトインターバル以上になる時に、ＲＴＯタイムアウト又はデカップルドレート減少タイムアウトを有し、このＲＴＯタイムアウト又はデカップルドレート減少タイムアウトインターバル値は、必要な定義された知覚許容範囲インターバル以内にセットされ／そうなるようにすることができる。

これは、任意のポーズ期間／インターバル中に送信される単一の又は定義された個数のパケット／データユニットが、それに対応する肯定応答がその後にＲＴＯタイムアウト又はデカップルドレート減少タイムアウトの後に遅れて到着する場合であっても、任意のＲＴＯ「ポーズ」イベント又はデカップルドレート減少「ポーズ」からさらに除外されるか、それを引き起こすことを許容されない場合に、特にそうである。その場合に、最悪の輻輳の場合に、起点センダソースＴＣＰ／ＩＰスタックは、「ポーズ」とそれぞれが等しい持続時間の通常パケット送信フェーズとの間で交番する→すなわち、起点センダソースＴＣＰ／ＩＰスタックは、最悪の場合でもその送信レートを「半分にする」だけであるはずであり、「ポーズ」中には、ほとんど何も送信しないが、ポーズが止まった時に再開されたならば、スライディングウィンドウ機構の下で許容される最高速度で送信する。

さらに、すべてのＴＣＰ／ＩＰスタック又は大多数に関して、すべてがそのように変更され、ＲＴＯタイムアウトインターバル又はデカップルドレート減少タイムアウトインターバルに共通の値、例えば必要な定義された知覚許容範囲期間内のｔミリ秒（ｔ＝ネットワーク内の最も離れたソースノード／デスティネーションノード対の非輻輳ＲＴＴ＊ｍ被乗数）をセットされたインターネット／インターネットサブセット／ＷＡＮ／ＬＡＮ上で、そのインターネット／インターネットサブセット／ＷＡＮ／ＬＡＮ内で送信されるすべてのパケットは、ｓ＊ノード数又は（ｔ−非輻輳ＲＴＴ）＋ｔのうちの短い方のみのルートに沿った総累積バッファ遅延を経験しながらデスティネーションに到着しなければならない。

これは、既存ＴＣＰ／ＩＰスタックのＲＦＣ実施態様と好都合に対照をなし、この既存ＴＣＰ／ＩＰスタックのＲＦＣ実施態様は、パケットが捨てられないことを保証することができず、さらに、おそらく、送信されたすべてのパケットがある有用な定義された許容範囲期間以内に到着することを保証できない。「ポーズ」中に、介在する経路の輻輳は、この「ポーズ」によってクリアされて助けられ、この「ポーズ」中に送信される単一の又は少数の定義された個数のパケットは、この変更されたＴＣＰ／ＩＰスタックがそれ相応に反応するために、介在する経路を有用にプローブして、輻輳が継続しているか止まったかを確かめる。

ＮｅｘｔＧｅｎｅｒａｔｉｏｎＴＣＰ：さらなる改善及び変更
外部インターネットノード（内部ネットワークノードにも適用可能とすることができる）
ギャランティードサービスインターネットサブセット／ＷＡＮ／ＬＡＮに適用される同一のデカップルド「ポーズ」／送信レート減少タイムアウト及び実際のパケット再送信タイムアウトの機構（ＡＣＫタイムアウト及びパケット再送信タイムアウト）を、同様に、外部内部クラウド／外部ＷＡＮ／外部ＬＡＮに適用することができる。この場合に、非輻輳ＲＴＴｅｓｔ（すなわち、これまでに受信された対応する戻るＡＣＫに関する最新の最も小さい最小時間期間の変数）が、ギャランティードサービスインターネットサブセット／ＷＡＮ／ＬＡＮ内の既知の非輻輳ＲＴＴ値の代わりに使用される。

．受信されたＡＣＫ（送信された通常のデータパケット、ＩＣＭＰプローブ、又はＵＤＰプローブに関するＡＣＫとすることができる）から、ＡＣＫの受信の最新の最小時間期間（対応するパケット送信時刻からの）の変数が、更新され、この非輻輳ＲＴＴｅｓｔは、ソースとデスティネーションとの間の非輻輳ＲＴＴ値の最も最近の推定値として働く（ソースインターネットノードと外部インターネットノードとの間の非輻輳ＲＴＴが実際にわかっている場合には、さらによい）。知識を、地球上の最も離れた非輻輳ＲＴＴが例えば４００ｍｓであるという事実について作ることができ、したがって、最大非輻輳ＲＴＴｅｓｔが例えば４００ｍｓであるという事実を利用することができる（しかし、両端が例えば小さい５６Ｋモデム帯域幅であり、且つ、例えば１５００バイトなどの大きいパケットが転送される場合に、１５００バイトパケットがモデムから完全に出るかモデムに完全に入るのに約２５０ｍｓを要するという点で、注意を払わなければならず、したがって、非輻輳ＲＴＴｅｓｔ値をそれ相応に調整するために、パケットが実際にモデムを完全に出ることを完了した時刻をも入手することが好ましいはずである）。

．任意のパケットのＲＴＴ（そのＡＣＫから導出される）＊ａ＞非輻輳ＲＴＴｅｓｔ（ａは、必ず１より大きい被乗数である）である場合に、「ポーズ」がトリガされ（しかし、その「ポーズ」インターバル又は拡張された「ポーズ」インターバル（１つ又は複数）中に、通る１つ又は複数のデータパケットを許容するか、通るプローブパケットだけを許容し）、又は、レートが、あるパーセンテージ、例えば既存レートの９５％まで減少し（これは、例えば、トラフィックシェーピング技法又は輻輳ウィンドウサイズの減分．．．などを介して実施することができ）、及び／又は、最も最近の／後続の受信されるＡＣＫのＲＴＴ＊ａが＞非輻輳ＲＴＴｅｓｔであり続ける限り又は考案されるアルゴリズムに基づいて導出される定義された時間期間について、後続ＡＣＫ時に変更されたＴＣＰのウィンドウサイズ／輻輳ウィンドウサイズを単に増分しないこと、又は上記のいずれかの組合せ、
直接にＴＣＰスタック上でのレート減分実施態様は、自明であるが、モニタソフトウェア／ＩＰ転送モジュール／プロキシＴＣＰ．．．などでは、既存レートシェーピング／レートスロットリング技法を介して実施することができ、あるいは、特定のＴＣＰフローの最も最近の有効ウィンドウサイズ値を単純にミラーリングする（且つ／又はこの機構の動作を延期する）モニタソフトウェア／ＩＰ転送モジュール／プロキシＴＣＰ内のＴＣＰフローごとのもう１つのウィンドウサイズ／輻輳ウィンドウサイズ機構として実施すること、しかし、特定のフローの最も最近に受信されたＡＣＫのＲＴＴ＊ａが＞非輻輳ＲＴＴｅｓｔであり続ける時に／である限り、最も最近の有効ウィンドウサイズ値をミラーリングしない／ミラーリングを停止すること（すなわち、この機構の動作を開始する）：そうではなく、この時間中に、最も最近に受信されたＡＣＫのＲＴＴ＊ａが＞非輻輳ＲＴＴｅｓｔであり続ける時に／である限り、この特定のフローに関するモニタソフトウェアのウィンドウサイズ／輻輳ウィンドウサイズ値は、そのフローの最も最近にミラーリングされた導出された／計算された現在の有効ウィンドウサイズすなわち、ウィンドウサイズ／アドバタイズされたウィンドウサイズ／輻輳ウィンドウサイズ値のうちのより小さいもののｍ％、例えば９５％まで減らされるはずである（注：上記の動作を、任意選択で、ｔ秒、例えば１秒だけ又はある考案されるアルゴリズムに基づいて遅延させることができる）。

［注：モニタソフトウェアを実施する時に、センダＴＣＰ輻輳ウィンドウサイズは、ＷｉｎｄｏｗｓＴＣＰスタックソースコードがないＷｉｎｄｏｗｓプラットフォームでは直接に入手可能ではなく、したがって、ネットワークから導出される必要があり、この故に、センダＴＣＰソースの現在の有効ウィンドウサイズを導出することができる（有効ウィンドウサイズ＝ｍｉｎ（ウィンドウサイズ，輻輳ウィンドウサイズ，レシーバがアドバタイズしたウィンドウサイズ）。現在のセンダＴＣＰソースの現在の有効ウィンドウサイズ値／輻輳ウィンドウサイズ値の導出／近似において、さまざまな既存の技術的現状の方法論がある。しかし、例として、我々は、接続をオーバーフローさせない時に、センダＴＣＰソースの輻輳ウィンドウサイズが、現在の送信レート＊非輻輳ＲＴＴｅｓｔであると仮定することができる（すなわち、その送信時刻及びその戻るＡＣＫ時刻を監視するＲＴＴあたり１つの「区別される」パケットを選択することによって計算される現在の送信レート、現在の送信レート＝（送信時刻と戻るＡＣＫ時刻との間に移動中のバイト数）／（戻るＡＣＫ時刻−送信時刻）、我々は、センダＴＣＰソースの現在の輻輳ウィンドウサイズが、移動中のバイト数と等しいと仮定することができる。

もう１つの例は、類似して、同様に、ＲＴＴインターバル内にモニタソフトウェアによって転送された総バイト数を監視することによって導出されるセンダＴＣＰソースの現在の有効ウィンドウサイズ／現在の輻輳ウィンドウサイズを導出することができる］。

モニタソフトウェアでは、パーセンテージレート減分は、任意選択で、上記ように現在の有効ウィンドウサイズの導出／推定に依存する必要がない場合があり、その代わりに、モニタソフトウェアは、その代わりに「ポーズ」をもたらすことができる（及び／又は、１つ又は複数のパケットがこのポーズインターバル中に転送されることを可能にする）：
．周期的な間隔を置かれたポーズされるインターバルが例えば１秒以内に合計ｐ＊Ｉ（Ｉは、秒単位の周期的な間隔を置かれたポーズされるインターバルである）になる場合に、効果的に輻輳ウィンドウ＝（１−（ｐ＊Ｉ））／現在のスループットの１秒（現在の有効ウィンドウサイズ＊現在のＲＴＴ）。

．この故に、５％レート減分をもたらすためには、（Ｐ＊Ｉ）を、０．０５と等しくしなければならない。

この「ポーズ」インターバルは、周期的に均等に間隔を置かれて離れている必要すらない場合があり、且つ／又は各「ポーズ」インターバルは、同一のポーズ持続時間を有する必要すらない場合がある。

例：「１つ又は複数のポーズ」中に合計５％未満の送信時間がある場合に、ソース−デスティネーションの帯域幅遅延積は、今や、既存値の０．９５まで減らされるはずである。これは、今や、上記のオーバーラップしないＲＴＴインターバルごとの総有効ウィンドウサイズ分のデータバイトまでを送信するのに、例えば１秒以内に５％少ない個数のオーバーラップしないＲＴＴインターバルがあるはずだからである。「ポーズ」インターバル持続時間は、好ましくは、少なくとも非輻輳ＲＴＴｅｓｔの最小値と同等にセットされなければならないが、必要な場合にはより小さくすることができる。例、２０ｍｓおきに１つのサンプリングされたパケットを送信するＶｏＩＰ送信において（非輻輳ＲＴＴｅｓｔよりはるかにより小さいと仮定する）、例えば１秒の中の５０ｍｓの単一の「ポーズ」インターバル持続時間（すなわち、５％有効ウィンドウサイズ減分と同等のレート減分をもたらす）を、例えば１秒の中の５つの均等な間隔を置かれた周期的「ポーズ」にすることができ、ここでの「ポーズ」のそれぞれは、持続時間１０ｍｓを有し（タイムクリティカルＶｏＩＰパケット転送での長い遅延を導入しないように）、あるいは、例えば１秒の中の１０個の均等な間隔を置かれた周期的「ポーズ」にすることができ、この「ポーズ」のそれぞれは、持続時間５ｍｓを有し．．．．などである。

さらに、センダＴＣＰソースコードは、同様に、完全に「ポーズ」法を利用し、輻輳ウィンドウサイズセッティングの必要を完全に置換して、現在の有効ウィンドウサイズセッティングを実施することができる。この変更されたＴＣＰでは、任意の時の現在の有効ウィンドウサイズは、［ｍｉｎ（ウィンドウサイズ，レシーバがアドバタイズしたウィンドウサイズ）＊（（１−（ｐ＊Ｉ））／１秒）］になるはずである。

（継続される受信されたＡＣＫのＲＴＴ＊ａのストリームが＞非輻輳ＲＴＴｅｓｔであり続ける時に繰り返して減分しないように：しかし、さらに、例えば最も最近の最新のレート減分以降に送信されたパケットに対応する、最も最近に受信されたＡＣＫのストリームＲＴＴ＊ｂ（ｂは必ず＞ａ）が＞非輻輳ＲＴＴｅｓｔである場合に、モニタソフトウェアのウィンドウサイズ値／輻輳ウィンドウサイズ値を、今や、さらに、現在既にＬ％／ｍ％まで減らされているモニタソフトウェアのウィンドウサイズ値／輻輳ウィンドウサイズ値の例えば９０／９５％（Ｌ％又はｍ％）まで任意選択で繰り返して減らすことができる｛ｂは、ａより深刻なレベルの輻輳又はパケットドロップさえも表す。ａとｂとの一方又は両方は、パケットドロップイベントを意味する可能性が非常に高くなるものとすることができる。モニタソフトウェアは、任意選択として、上記の動作をｔ秒、例えば１秒だけ遅延させることができ、その結果、すべての既存の未変更のＴＣＰが、レート減分において同期するようになる｝。

且つ／又は、ある条件が成り立つ時、例えば、フローの最も最近の／後続の受信されたＡＣＫのＲＴＴ＊ａが＞非輻輳であり続ける限り、ある考案されるアルゴリズムに基づくある期間の間にウィンドウサイズ／輻輳ウィンドウサイズを増分しない。

モニタソフトウェアを使用する時に、ＴＣＰは、もちろん、それ自体のスロースタート／輻輳回避／カップルドＲＴＯ．．．などを行い続ける。モニタソフトウェアは、例えば送信されたセグメントのＡＣＫが例えば１秒などの非常に長い期間の後にまだ受信されていない時．．．など、又はフローの送信レートの突然の半分化から．．．など、ＴＣＰＲＴＯイベントを予測し／検出することができる。モニタソフトウェアは、さらに、そのミラーリングされたウィンドウサイズ値／輻輳ウィンドウサイズ値を例えば既存値の９０％（ｎ％）に減分することを選択することができ、且つ／又は、ある考案されたアルゴリズムに基づいて導出されるある時間期間の間に、例えば最も最近の／後続の受信されたＡＣＫのＲＴＴ＊ａが＞非輻輳ＲＴＴｅｓｔであり続ける限り、特定のフローのそれ自体の有効ウィンドウサイズ／輻輳ウィンドウサイズを増分しないことを選択することができる。

モニタソフトウェアは、さらに、それ自体のパケット再送信タイムアウトを実施することもでき、これは、モニタソフトウェアが、送信されたパケットの動的ウィンドウ分のコピーを必ず保持すること及びＴＣＰに類似する再送信ソフトウェアモジュールを必要とし、この故に、モニタソフトウェアは、ＴＣＰＲＴＯ表示を待つ必要なしに上記の段落の諸機能をはるかによりすばやく実行することができる。この故に、モニタソフトウェアは、任意選択として、例えばＴＣＰへのＡＣＫをスプーフィングすることによって、遅いＡＣＫがＴＣＰでＲＴＯを引き起こすのを防ぐことができ、ＴＣＰへの生成された／スプーフィングされたＡＣＫを介してＴＣＰを制御し／ペーシングするとができ、例えば、０のアドバタイズされたレシーバウィンドウサイズを有するスプーフィングされたＡＣＫをセットして、時間の期間の間だけＴＣＰを「ポーズ」させ、あるいはスプーフィングされたＡＣＫにある所望の値をセットしてＴＣＰの有効ウィンドウサイズを減分し、ＡｃｋｎｏｗｌｅｄｇｅｍｅｎｔＮｕｍｂｅｒフィールド値＝最新の送信されたＳｅｑＮｏ値を有するＤＵＰＡＣＫをセットして、実際のパケット再送信を必要に引き起こすことなくＴＣＰに有効ウィンドウサイズを半分にさせる．．．などである。モニタソフトウェアは、任意選択として、ｔ秒、例えば１秒だけ上記の動作を遅延させることができ、その結果、すべての既存の未変更のＴＣＰが、さまざまなレート減分において同期するようになる。

さまざまな異なるアルゴリズム／異なるアルゴリズムの組合せを、図示の／上記で概要を示したものの代わりに考案することができる。さまざまな既存の技術的現状の方法又はコンポーネント方法を、さらに、本明細書で説明される方法又はコンポーネント方法のどれにでも、改善として組み込むことができる。

変更されたＴＣＰ（又は変更されたＲＴＰｏｖｅｒＵＤＰ／変更されたＵＤＰ．．．などでさえ）フローは、この場合に、レートを半分にする必要がない。というのは、これらが、輻輳してパケットドロップを引き起こす時（バッファリングイベント中）に、レートを増分する必要がなく、且つ、例えば送信レートの１０％／５％減分が、新しいフローの非枯渇を保証するからである（すべての他の既存の未変更のＴＣＰフローは、５０％減分を保証するはずであるが、必ず、レートを増分しようと努力して、もう一度パケットドロップを引き起こすはずである）。新しいフローは、その公平なシェアを経時的に築き上げるはずである。これは、既存の確立されたフローの短い待ち時間．．．などをもほどよく保存し（ＶｏＩＰ／マルチメディアに適する）、既存の伝統的なＰＳＴＮ呼アドミッションスケジュールを反映する。

この場合に、変更されたＴＣＰ／変更されたＲＴＰｏｖｅｒＵＤＰ／変更されたＵＤＰは、リンクの帯域幅の、その確立されたシェア又はその確立されたシェアのほとんどを保持するが、さらなる追加の輻輳／パケットドロップを引き起こさない。

閾値までのＴＣＰ指数関数的増加、閾値の後の輻輳回避中の線形増加、スライディングウィンドウ／輻輳ウィンドウ機構．．．などは、ボトルネックリンクの輻輳の始まりが徐々であることを保証し、この故に、変更されたＴＣＰ及び既存の未変更のＴＣＰは、それ相応に反応して、輻輳を除去することができる。ここでの変更されたＴＣＰ／変更されたＲＴＰｏｖｅｒＵＤＰ／変更されたＵＤＰは、例えばパケットドロップに近い輻輳レベルの時に、十分な余分のトラフィックのすばやい突然のバーストを使用することすらして、特定の輻輳したリンク（１つ又は複数）をトラバースするすべての又は選択的な既存フローが、送信レートを下げるためにパケットドロップ通知を得ることを保証することができる。既存の未変更ＴＣＰは、そのレートを半分にし、前の輻輳を引き起こす送信レートを構築し直すのに長い時間を要するはずであるが、変更されたＴＣＰは、リンク（１つ又は複数）に沿った帯域幅のすべての確立されたシェアのほとんどを保持するはずである。

これは、公衆インターネット上でのこの単純な分離されたＴＣＰ変更の増分的採用を最も有用に促進する。変更されたセンダＴＣＰソースは、より高いスループットを達成し、ドロップを引き起こすボトルネックリンクの輻輳（又はパケットドロップを引き起こす単なる物理送信エラー）の際にボトルネックリンクの帯域幅のその確立されたシェアを保持すると同時に、フローの間の公平さを保ち（単一のパケットドロップの際に、確立された帯域幅の半分を失う既存ＴＣＰと比較されたい）、それ自体では、パケットドロップを一切引き起こさない。この変更されたセンダソースＴＣＰは、高帯域幅長待ち時間ネットワークで、単一のパケットドロップだけによって引き起こされる既存のＴＣＰレート回復問題を克服する。

センダＴＣＰソースのトラフィックが、外部インターネットノード／ＷＡＮ／ＬＡＮから発する場合に、外部から発するトラフィックがタイムスタンプされる（レシーバＴＣＰが経路伝送時間又はソースからデスティネーションまでの一方向伝送遅延を導出することを可能にする）と仮定すると、上記の変更されたセンダソースＴＣＰ法は、レシーバベースドの方法として働くように適合させることができる。

．起点ソースのタイムスタンプは、レシーバに正確に同期される必要がない。レシーバは、この場合にソースシステムクロックのタイムスタンプドリフトを無視することができる。ＯＴＴｅｓｔ（ソースからデスティネーションへの受信されたパケットの一方向伝送待ち時間の最も最新の更新推定値であり、パケットが受信された時の現在のレシーバシステム時間−受信されたパケットのセンダタイムスタンプと同等のこれまでに導出された最小の値である）が、レシーバで導出される。後続の受信されたパケットで観察されるＯＴＴのすべての増分は、経路に沿った輻輳の無知な始まり（ｉｎｓｉｐｉｅｎｔｏｎｓｅｔ）（すなわち、その経路に沿った少なくとも１つの転送するリンクが、現在、完全に１００％利用されており、パケットがその経路に沿ってバッファリングされ始める）を示し、今や、センダＴＣＰソースが、今や変更されたレート減分又は「ポーズ」機構をトリガしなければならないことを意味するはずである。レシーバは、下記によって、これをセンダＴＣＰソースにシグナリングすることができる。

．適当な「ポーズ」又は適当な「周期的」ポーズの後に同一のオリジナルのアドバタイズされるウィンドウサイズに戻る前に、適当な期間の戻るＡＣＫ内で、アドバタイズされるウィンドウサイズに０をセットする。

．センダＴＣＰソースの現在の導出／推定された有効ウィンドウサイズ（有効ウィンドウサイズ＝ｍｉｎ（ウィンドウサイズ，輻輳ウィンドウサイズ，レシーバウィンドウサイズ）の適当に減分された値、例えばセンダＴＣＰソースの現在の導出／推定された有効ウィンドウサイズの９５％をアドバタイズされるウィンドウサイズにセットすること。この場合に、センダＴＣＰソースは、変更されたレシーバＴＣＰが同一のアドバタイズされる減分された現在の導出／推定された有効ウィンドウサイズを用いてＡＣＫし続ける限り、各ＲＴＴ内で受信されるＡＣＫについて有効ウィンドウサイズを継続的には増分しないはずである。しかし、現在の戻るＡＣＫのアドバタイズされるレシーバウィンドウサイズが、後に変更される場合に、その増分は、パケットドロップを引き起こさない。というのは、センダＴＣＰソースが、その経路に沿った輻輳の次の無知な始まりの際に、最終的にその有効ウィンドウサイズを減分することを、変更されたレシーバＴＣＰが保証するからである。他の可能な技法に、レシーバＴＣＰがＡｃｋをＤＵＰすることが含まれる（センダＴＣＰソース乗法輻輳ウィンドウ減少の半分化をトリガするための連続する３つのＤＵＰＡＣＫ）。

．初期ＴＣＰ接続確立フェーズ中に、変更されたレシーバＴＣＰは、タイムスタンプオプションを有するためにセンダＴＣＰソースとネゴシエートするはずである。このレシーバベースドの変更されたＴＣＰ／変更されたモニタソフトウェアは、センダＴＣＰを変更することを必要としない。

センダＴＣＰとレシーバＴＣＰとの両方が、タイムスタンプオプションと一緒に変更される時に、両方の方向でのよりよく正確なＯＴＴ／ＯＴＴ変動の知識がイネーブルされるはずである（変更されたＴＣＰ／変更されたモニタソフトウェアの両方が、お互いへの方向でＯＴＴの知識を渡すことができ、したがって、変更されたＴＣＰ／変更されたモニタソフトウェアは、今や、ＲＴＴではなくＯＴＴを使用してよりよい制御を提供することができ、例えば、送信されたセグメントのＯＴＴが輻輳を示さないが戻るＡＣＫのＯＴＴが輻輳を示す場合に、以前のＲＴＴベースの方法で使用されるＲＴＴがタイムアウトしている場合であっても、レート減分／「ポーズ」を行う必要はない。センダでのみ実施される時の、タイムスタンプオプションと一緒に使用される、ＲＴＴベースの変更されたＴＣＰは、センダが、戻るＡＣＫのＯＴＴｅｓｔ及び／又はＯＴＴ変動を同様に所有することを可能にして、よりよい制御を同様に提供するはずである。

変更されたＴＣＰ技法が大陸間海低ケーブル／衛星リンク／ＷＡＮリンクの両端で実施される場合に、事実上物理リンクの物理帯域幅の２倍化に似て、ＴＣＰの伝送媒体の帯域幅利用度及びスループットが増えるはずであることに留意されたい。

当業者は、さまざまな修正及び変更を行うことができるが、本原理の範囲に含まれる。

ＵＤＰの優先順位付け
インターネット／インターネットサブセット／ＷＡＮ／ＬＡＮ内の各ノードでＵＤＰにＴＣＰより高い優先順位を与えること → などは、それでも、ノードの入力キューの以前の既存のＴＣＰバッファリングされたパケット＝＞ＵＤＰパケットのバッファリングされた遅延又はＵＤＰパケットドロップにさえ起因して、ＵＤＰトラフィックが転送するリンクの帯域幅の１００％を超えて利用していない時であってもＵＤＰドロップをもたらすことに留意されたい。

１．すべてのＵＤＰパケットをノードの入力キューバッファの前面に置き（且つ／又はＴＣＰパケットが既に出力キューにエンキューされている時であってもＴＣＰパケットを超えて優先順位を与えられるＵＤＰ入力キューからＵＤＰパケットを出力キューの前面に優先して置き）、すべてのＴＣＰパケットをキューの終りに向かってプッシュする（この故に、すべてのＴＣＰパケットが、入力キュー及び／又は出力キューでのすべてのＵＤＰパケットドロップの前に捨てられる）ために、ルータ／スイッチのソフトウェアをアップグレード／変更する必要がある。

２．別々のＵＤＰ入力キュー（非常に小さいものとすることができる）及びＴＣＰ入力キューの作成を可能にするためにルータ／スイッチのソフトウェアをアップグレードし、ＵＤＰキューは、ＴＣＰパケットの前に出力キューにスケジュールされる。且つ／又は、ＵＤＰ高優先順位出力キュー及び低優先順位ＴＣＰ出力キューを実施する。

ＵＤＰトラフィック単独が、リンクの物理帯域幅を超える場合があり、ＵＤＰを送信するソースに送信レートすなわち分解能品質（ｒｅｓｏｌｕｔｉｏｎｑｕａｌｉｔｙ）を下げさせる可能性があり、且つ／又はルータ／スイッチノードにすべてのＵＤＰフローに対してこの分解能低下プロセスを実行させる可能性がある（例えば、フローの交番するパケットだけの送信及び他の交番するＵＤＰパケットの破棄、又は、２つ（又は複数）の例えばＶｏＩＰＵＤＰパケットのデータを同一サイズだがより低い分解能品質の１つのパケットへの組合せ）。

ノードは、さまざまなＵＤＰ／ＴＣＰ．．．などのフローに関する転送するリンクの帯域幅の最小比率を保証することによって、ＴＣＰ非完了枯渇を保証することができる。

帯域幅推定
さらなる変更は、下記を含む（且つ、前に説明した非輻輳ＲＴＴ／ＲＴＴｅｓｔ／ＲＴＴｂａｓｅ／ＯＴＴｅｓｔ／ＯＴＴｂａｓｅ／レシーバＯＴＴｅｓｔ方法と一緒にあいまって使用することができ、したがって、出力結果をもたらすのにある時間を必要とする場合がある下の技法が上記の方法を補足するのに十分な時間を与えることができる）。

１．例えば、キューが形成されず／パケットがバッファリングされない（すなわち、トラバースされるすべてのノードがバッファ遅延を全く導入しないようにバッファ遅延をプリエンプトする）ようにするために、「ポーズ」／レート減少のために転送するリンク利用度が１００％に達するなど、ある条件に出会う時に、そのため／レート減少（ある考案される最適化されたアルゴリズムに従う）のために考案されるアルゴリズムから導出される適当なインターバルの間だけ「ポーズ」するために、各トラバースされるノードの転送するリンクの帯域幅、利用度、スループット、キュー長、出会う遅延．．．などを確かめるために、ｐｉｐｅｃｈａｒ、ｐｉｐｅｃｈａｒ、ｔｒａｃｅｒｏｕｔｅ、ｐａｔｈｃｈａｒ、ｐｃｈａｒ、ｐａｔｈｌｏａｄ、ｂｐｒｏｂｅ、ｃｐｒｏｂｅ、ｎｅｔｅｓｔ、ｃｈｉｒｐ．．．などの方法及び類似する技法を使用すること。

例えば、特定のリンクでの利用度（ＵＤＰ、ＩＣＭＰ、及びＴＣＰのすべてを含むものとすることができる）が、例えば９５％に達する時には、受信されるＡＣＫのウィンドウサイズをそれ以上増分せず、且つ、その後にパケットが捨てられる場合／時に限って、例えば１０％だけ減分し（新しいフローが特定のリンクで帯域幅について完全に「枯渇」しないようにするために）、且つ／又は、おそらく、その後に、各ＡＣＫのウィンドウサイズを増分しないことができる。パケットが物理送信エラーに起因して（すなわち、バッファ過充填輻輳に起因するのではなく）捨てられる場合、経路に沿った特定のリンクでのリンク利用度が例えば９５％（又は指定されたパーセンテージ）利用度未満の場合に、我々は、ウィンドウサイズ減分を停止する必要がない［高帯域幅長ＲＴＴＴＣＰレート回復問題を解決する］。これは、公衆インターネット上でのこの単純な分離されたＴＣＰ変更の増分的採用を最も有用に促進する。新しいフロー（ＵＤＰ、ＩＣＭＰ、ＴＣＰ）及び／又は既存の未変更のＴＣＰ／ＲＴＰｏｖｅｒＵＤＰ／ＵＤＰは、今や、必ず、常に増大するために少なくとも５％の非枯渇保証帯域幅を有しなければならない。というのは、変更されたＴＣＰ／ＲＴＰｏｖｅｒＵＤＰ／ＵＤＰが、例えば、リンク利用度が例えば９５％を超える時に、すべてが送信レートを増分しないことができるからである。また、その後、リンクがパケットを捨てる場合／時に、変更されたＴＣＰ／ＲＴＰｏｖｅｒＵＤＰ／ＵＤＰは、ウィンドウサイズ／送信レートを例えば１０％だけ減分する（あるいは、例えばｘ／（ｘ＋ｙ）＝０．１になるように、期間ｙについて送信側ソースに隣接する伝送媒体によって許可される無制限のレートで送信する前に、周期的にインターバルｘだけポーズする、すなわち、例えば１０％のスライディングウィンドウ又は輻輳ウィンドウのサイズ減分／レート減分と同等）。スライディングウィンドウ／輻輳ウィンドウサイズ減分／レート減分ではなくインターバルｘの間のポーズは、ノードでの輻輳したバッファの最高速の可能な早期クリアを与え、且つ、経路に沿ったノードでのバッファ遅延をまさに最小値に保つことを助ける。

ここでのバッファサイズ要件は、全く、考慮のために非常に関連する要因ではない。おそらく、常時、使用可能な物理帯域幅以内に／その１００％を超えないようにすべてのトラフィックを保つことができる（非常に突然のバースト性（ｂｕｒｓｔｉｎｅｓｓ）を受けて、バッファリングされる必要がある場合がある）。

ＶｏＩＰ／マルチメディア（例えば、ＲＴＰｏｖｅｒＵＤＰ／ＵＤＰを利用する）又は同一の経路／経路の同一部分をトラバースする総計としてのＶｏＩＰ／マルチメディアについて、リンクが例えば９５％又は１００％により近い値すら超え始める時に、ソースＶｏＩＰ／マルチメディアは、今や、例えばあるパーセンテージ、例えば分解能品質の半分で送信することができ、且つ、他のトラフィックの増加がリンク利用度を例えば９５％／１００％まで戻すのを待って、現在の突然のバーストを全面的な分解能品質送信及び／又はそれに加えて余分の分解能、例えば２００％以上（余分の冗長消去コーディング（ｒｅｄｕｎｄａｎｔｅｒａｓｕｒｅｃｏｄｉｎｇ）．．．などを用いて）に戻して、即座の突然のバーストを引き起こし、他のＴＣＰフロー（変更された又は未変更の）のレート減少（通常は既存のＲＦＣＴＣＰ実施態様で１秒以内）をトリガする捨てられたパケットをバッファリングすることができ、且つ、他のフロー、例えばＴＣＰが今やレート減分する時に、１００％オリジナル送信品質に即座に戻る（又は、おそらくはリンクの帯域幅／ＶｏＩＰ／マルチメディアによって利用される帯域幅の比率／ノードでのバッファサイズ．．．などに依存して、２００％分解能品質送信に留まりながらできる限り多くの帯域幅をつかみ続けることさえ）できる → ＶｏＩＰ／マルチメディアの最小の可能なバッファ遅延を保証する。

おそらく、ＶｏＩＰ／マルチメディアは、より高い分解能送信品質で開始することさえできる（例えば、冗長消去コーディング．．．などを用いて、通常の必要な分解能の２００％）。

これは、すべてのフローについて、トラバースされるノードで、できる限り少ないバッファ遅延期間を保証するので、すべてのフローに役立つ。許可された要求がフローパケットを捨てる（例えば、センダにレート減分を知らせるために各ＴＣＰフローから１パケット）ことを許可するため、及び／又は例えば９５％／１００％リンク利用度の検出時にこれを行うために、ルータソフトウェアを、さらにアップグレードすることができる。

上記の方法は、既存の例えばＲＩＰ／ＢＧＰルータテーブル更新パケット．．．及び／又は類似する技法と共に使用して、すべてのノードでの最小の又は無のバッファ遅延を保証することができ、アップグレードされたルータソフトウェアは、リンクプリファレンスルーティングテーブル更新を行って、特定の転送するリンクの例えば９５％／１００％を超過してプリエンプトし．．．且つ／又はこれを隣接するルータだけではなくネットワーク全体に伝搬させる（しかし、より頻繁なリアルタイム速度更新を可能にするために機能強化される必要があるはずである）。

もう１つの次世代ネットワーク設計は、ルータが、特定の転送するリンクの例えば９５％／１００％利用度（１００％利用度はパケットバッファリングの差し迫った始まりを示すはずである）及び／又はリンクの生帯域幅／キューイングポリシ／バッファサイズ．．．などの他の構成詳細について隣接するルータにシグナリングすること（隣接ルータがこのルータ／又はこの転送するリンクだけへの既存の送信レートを増やさないようにするために）、及び／又は、更新された情報又は期間ｙの制限されない送信レート（実際にはルータの間のリンク帯域幅によってのみ制限される）を継続する前のいくつかの対応する「ポーズ」インターバルｘにさえ依存する、考案されるアルゴリズムに基づくあるパーセンテージだけの、通知されるルータリンクをトラバースするフローに対するフローごとのレート減分／レートシェーピングとすることができる。「レート減分」／「ポーズ」中のバッファリングを必要とするすべてのＴＣＰフローのパケットは、どの一時にもウィンドウサイズのほとんどであるのみになるはずであり、ＲＴＰ／ＵＤＰフローは、同様にバッファリングされ得る → 今や、おそらくソース輻輳回避ＴＣＰレート制限機構を一切なしで済ませることができると考えられる！。ルータは、センダＴＣＰソースに戻るＡＣＫのａｄｖｅｒｔｉｓｅｄＷｉｎｄｏｗｓｉｚｅフィールドに、ある持続時間について又は周期的にある持続時間について０をセットする（「ポーズ」又は周期的「ポーズ」を引き起こす）ように変更するか、あるいは、ａｄｖｅｒｔｉｓｅｄＷｉｎｄｏｗフィールド値を、センダＴＣＰソースの導出された／推定された現在の有効ウィンドウサイズのある減分されたパーセンテージに変更／セットする（したがって、ソーストラフィックのレート制限をもたらす）ことさえできる。インターネット／インターネットサブセット／ＷＡＮ／ＬＡＮ上のスイッチ／ルータは、すべてのフローのソース−デスティネーションアドレス及び／又はポートのテーブルを、その最新のＳｅｑＮｕｍｂｅｒフィールド及び／又はＡＣＫｎｕｍｂｅｒフィールド（及び／又はリンクに沿ったフローごとの転送レート、現在の導出された／推定されたリンクに沿ったフローごとの有効ウィンドウサイズ．．．など）と一緒に維持して、ルータが「純ＡＣＫ」及び／又は「ピギーバックＡＣＫ」及び／又は「複製されたパケット」．．．などを介してアドバタイズされたウィンドウサイズ更新を生成できるようにすることだけが必要である（例えば、「ポーズ」の前の既存のレシーバウィンドウサイズ値に戻る前に、ある期間の間に０の連続的なアドバタイズされたレシーバウィンドウサイズを介して「ポーズ」するように、又は導出された／推定された現在のソースＴＣＰ有効ウィンドウサイズに基づいて減分された値のアドバタイズされたレシーバウィンドウサイズを介してレートを減らすように、ソースＴＣＰに通知する）。隣接するルータは、次のルータの通知されるルータのリンクに沿った宛てられたパケットを減らし／トラフィックシェーピングし、あるパケットＩＰアドレスを知っている隣接物は、ルーティングテーブルエントリ、ＲＩＰ／ＢＧＰ更新、ＭＩＢ交換．．．などからの通知される次のルータのリンクに沿ってルーティングされる予定である。例えば、通知するルータに先行する隣接するルータでの既に周期的にポーズされているフロー（周期的「ポーズ」を介してレート制御される）は、今や、さらに、影響されるフローの「ポーズ」インターバル長を増やし、且つ／又はその期間内の「ポーズ」の個数を増やすはずである。周期的ポーズは、例えば、考案されるアルゴリズムから導出されるある定義された期間、例えば通知するルータが今、あるパーセンテージ未満、例えば９５％未満に戻って下落したリンク利用度を示す隣接するルータを更新する時に、頻度／個々のポーズインターバルを止めるか減らすことができる。

ＲＥＤ／ＥＣＮ機構を、この機能性を提供するために変更することができる、すなわち、バッファリングされたパケットを監視し、且つ、パケットを選択的に捨て／センダに通知するのではなく、ＲＥＤ／ＥＣＮは、例えば利用度があるパーセンテージ、例えば９５％に達する時．．．など、リンク利用度に関するポリシに基づくことができる。

上記のボトルネックリンク利用度推定技法、使用可能ボトルネック帯域幅推定技法、ボトルネックスループット推定技法、ボトルネックリンク帯域幅容量推定技法を、さらに、非輻輳ＲＴＴ／ＲＴＴｅｓｔ／ＲＴＴｂａｓｅ／レシーバＯＴＴｅｓｔ法に基づく前に説明したレート減分／「ポーズ」法に組み込むことができる。ここで、非輻輳ＲＴＴ／ＲＴＴｅｓｔ／ＲＴＴｂａｓｅ／レシーバＯＴＴｅｓｔ法に基づく前に説明したレート減分／「ポーズ」法をさらに機能強化するために、ボトルネックリンク利用度推定技法、使用可能ボトルネック帯域幅推定技法、ボトルネックスループット推定技法、ボトルネックリンク帯域幅容量推定技法を十分によい正確さのために導出し／推定するための豊富な時間があるはずである。経路のトポロジ／構成を補足し／提供するさまざまなさらなる技法に、ＳＮＭＰ／ＲＭＯＮ／ＩＰＭＯＮ／ＲＩＰ／ＢＧＰ．．．などを含めることができる。

２．周期的プローブは、ＷｉｎｄｏｗｓＵｐｄａｔｅプローブ（レシーバがまだ０ウィンドウサイズをアドバタイズしていない場合であってもレシーバウィンドウサイズを照会するため）又は類似するプローブパケット．．．の形とすることができ、あるいは、周期的プローブとしての実際のデータパケット（送信に使用可能な場合に）．．．など、又は未使用ポート番号を有するデスティネーションへのＵＤＰ（デスティネーションポート到着不能というリターンメッセージを得るため）、及び／又はこれに加えてすべてのノードからのタイムスタンプオプションを使用することができる。あるいは、同様に、未使用ポート番号を有するデスティネーションへのＴＣＰ（このＴＣＰパケットは未使用ポート番号へのＴＣＰＳＹＮＣとすることができる）。

さまざまな注記
［注：ポーズしたインターバルが、例えば１秒以内に合計ｐ＊Ｉになる場合に、効果的に、輻輳ウィンドウ＝（ｐ＊Ｉ）／現在のスループットの１秒（現在の有効ウィンドウサイズ＊現在のＲＴＴ）］
輻輳の検出時に、タイムクリティカルアプリケーションは、バーストを送信してパケットドロップを引き起こすことができ、あるいは、タイムスタンプから輻輳を検出するレシーバが、おそらくは便利に大きいプローブの形で、バーストを引き起こすか、バーストを引き起こすためにサーバに通知することができる。

外部インターネットノードに対するＲＴＴｅｓｔ技法に加えて、例えばレシーバプロセッサ遅延、生帯域幅、使用可能帯域幅、バッファサイズ、バッファ輻輳レベル、リンク利用度と共に、帯域幅推定技法の使用を改善することができる。

レシーバベースドＯＴＴｅｓｔは、ＧＰＳ同期化を展開する必要はなく、非輻輳ＯＴＴｅｓｔ、非輻輳ＯＴＴｂａｓｅ、又は既知の非輻輳ＯＴＴ及びＯＴＴモニタ変形だけを必要とする！！！。

センダベースド及び／又はレシーバベースドの生の帯域幅及びスループット推定 → リンク利用度
センダが遅延変動を処理するレシーバをブロックアウトできるように、タイムスタンプ（センダ及びエコー送信側（ｅｃｈｏｅｒ））を使用する。

変更されたＴＣＰ／変更されたモニタソフトウェアは、ポーズされた時に、任意選択として、今バッファリングされる必要があるホストソースＴＣＰからのＡＣＫフラグをセットされたすべての新たに到着したデータセグメント（すなわち、ピギーバックＡＣＫセグメント又は純ＡＣＫ、何もＡＣＫしない通常のデータセグメントは無視する）に対応する、データペイロードを搬送しない純ＡＣＫを即座に生成し、送信する（「ポーズ」にもかかわらず）ことができる。このポーズインターバル／拡張ポーズインターバル中に生成されるすべての純ＡＣＫ（１つ又は複数）は、即座に送信されるが、そのＳｅｑＮｕｍｂｅｒフィールド値に、まさに最初にバッファリングされるデータセグメント（これは、ＡＣＫフラグをセットされた又はセットされていない通常のデータセグメント又は純ＡＣＫセグメントとすることができる）とまさに同一のシーケンス番号引く１をセットさせることができる。新たに到着したセグメントが、純ＡＣＫである場合には、単にそれらを同様にバッファリングし、且つ、この新たに到着した現在はバッファリングされている純ＡＣＫに対応する純ＡＣＫを生成し／送信する！。この新たに到着した純ＡＣＫを、この時に、他のバッファリングされたデータセグメントの前に転送することは、受信するＴＣＰに、今、最後に送信された肯定応答番号と同一でなければならない次に期待されるシーケンス番号より大きいシーケンス番号を有するパケットを受信させる場合がある。生成された純ＡＣＫが送信されたならば、対応する現在はバッファリングされている純ＡＣＫを、任意選択として、今、バッファから除去し、且つ、破棄することができる。というのは、複製純ＡＣＫを送信しても意味がないからである。純ＡＣＫは、その代わりに、生成されることができ、且つ、このポーズインターバル期間／拡張ポーズインターバル期間内のすべてのバッファリングされたパケットの中で最大の肯定応答番号を有するバッファリングされたセグメントに対応することができる。

変更されたＴＣＰ／変更されたモニタソフトウェアは、任意選択として、ＵＲＧＥＮＴ／ＰＳＨフラグ．．．．などを有するセグメントを、「ポーズ」／拡張「ポーズ」中であっても即座に転送することを可能にすることができる。

実際のレート＝セグメントの送信時刻以降に送信されたバイト数／ＡＣＫタイムアウトを導出することもできる。ＳｅｑＮｏ、ＡＣＫタイムアウト、このセグメント内のバイト数を含むエントリのイベントリストを保持する。あるいは、実際のレート＝セグメントの送信時刻以降に送信されたバイト数／（この特定のＡＣＫタイムアウトしたセグメントの送信時刻−リスト上の最後の肯定応答されていないセグメントの送信時刻、リストに送信時刻を有する最後のセグメントがない場合には＝このＡＣＫタイムアウトしたセグメント＋ＡＣＫタイムアウト期間をセットする。あるいは、ＡＣＫタイムアウト期間内の、直前に送信されたセグメントに基づく実際のレートを使用する（おそらく、実際のレート＝受信されたＡｃｋ、すなわちこれらの肯定応答されたセグメントのすべてに対応する総バイト数を導出することもできる）ＲＴＴ又はＡＣＫタイムアウト期間内）をセットする。

レシーバベースは、輻輳ロスと物理送信エラーとの間で区別し、レート、ＯＴＴ又はＯＴＴｂａｓｅ、輻輳の始まりを各方向で別々にはるかにより正確に検出することができる。さらによりよく、センダは、レシーバが最初にパケットを受信した時及び／又はレシーバが、センダに送り返すパケット（及び／又はＡＣＫ）（例えば、ＩＰＭＰ）を最後に変更した時のタイムスタンプを伴うＡＣＫを戻って受信する。

スループット＝ウィンドウ＊ＭＳＳ／ＲＴＴバイト／秒をも導出できることに留意されたい。

マルチキャスト用の変更されたＴＣＰテクノロジ実施態様は、ルータのマルチキャストモジュールでの実施／階層的調整を必要とする。

モニタソフトウェアは、センダ及び／又はレシーバが、例えば一意のポート番号確立を介して、お互いの存在を識別したならば、よりよく調整することができる → モニタソフトウェアは、その後、適当なモード／モード動作の組合せに切り替えることができる。

外部ノードを介して送信／受信する場合には、「ポーズ」したくない場合があるが、インターネット上の増分採用が大多数になる時など、この好ましい「ポーズ」包含をイネーブルするための場合には好ましい（おそらくユーザ選択可能オプション）！。

当初に経路（ボトルネックに対応する）の使用可能帯域幅及び／又は生帯域幅容量についてプローブし、その後、例えば使用可能帯域幅の９５％又は例えば容量の９５％が即座に利用されるようにＴＣＰウィンドウサイズを開始することができる。

ＲＴＴが＜ＡＣＫタイムアウトであり続ける場合に、ウィンドウサイズをはるかによりすばやく、例えば＊１／ｃｗｎｄ．．．などで増分することができる。

ＡＣＫタイムアウト（及び又は実際のパケット再送信タイムアウト値）値を、ヒストリカルＲＴＴからの既存ＲＴＯ推定アルゴリズムに似て、戻るリアルタイムＲＴＴから、この目的のために考案されるアルゴリズムに基づいて動的に導出できることに留意されたい。

ＲＦＣでは、ＤＵＰＡＣＫを遅延させてはならず、ここで、我々は、すべてのバッファリングされたＡＣＫパケット又は単にその最高のＡＣＫＮｏについて、生成された純ＡＣＫを即座に既に送信することによって準拠した。

ＲＴＴの誤った推定を与え得る経路の再ルーティングの問題を避けるために、我々は、ホップバイホップＲＴＴ推定及び帯域幅プロービングを採用することができる。実用的実施態様のためにアクティブネットワーキングテクノロジを使用することによって、セクションごとのダイアログが、ルータを含む隣接ノードの間で実行される。

注：ＲＦＣでは、ＴＣＰレシーバは、受信するアプリケーションが新しいデータを消費する際に、提供されるウィンドウを更新するためのもの以外には、すべての着信セグメントについて複数のＡＣＫを生成してはならない。

ＤＩＦＦ（ＲＴＴ，非輻輳ＲＴＴ／ＲＴＴｅｓｔ）に応じて、ウィンドウサイズを減らし／「ポーズ」期間を増やすことができる。パーセンテージレート減分／「ポーズ」インターバル長は、経路に沿って経験されるバッファ遅延のサイズ、例えばＯＴＴ−ＯＴＴｅｓｔ（又はＯＴＴ−既知の非輻輳ＯＴＴ）、又はＲＴＴ−ＲＴＴｅｓｔ（又はＲＴＴ−既知の非輻輳ＲＴＴ）に応じて調整することができる。

変更されたレシーバＴＣＰが、「ポーズ」している間のセンダのバッファリングされたＡＣＫパケットに関する変更されたセンダＴＣＰが生成した純ＡＣＫ（又はすべてのＡＣＫさえ）を受信する時に、変更されたレシーバは、任意選択で／特に、最後のＡＣＫ番号−１をセットされたＳｅｑ番号を有する１バイトを生成する、すなわち、変更されたセンダＴＣＰが、確かに受信されたことを知っている、戻るＡＣＫを生成することができる（この場合に、各すべてのバッファリングされたパケットが最大Ｓｅｑ番号のＡＣＫのみではなく、個別に生成された純ＡＣＫであることを保証する必要がある場合がある）。センダＴＣＰは、この１バイトデータの生成された純ＡＣＫがレシーバによって返されないかどうかを「パケット複製ＡＣＫ」で推論することができる（複製されたパケットがレシーバ側のアプリケーションに渡されない場合であっても） → その後、それ相応に反応する（例えば、逆経路の輻輳／輻輳ロス／送信エラー又は転送の輻輳／輻輳ロス／送信エラーである可能性があり、後者の場合に、生成された１バイトデータ純ＡＣＫをもう一度送信したいと望んでもよい．．．など）。

両端のモニタソフトウェア、又はセンダのみ、又はレシーバのみ：レシーバの最新のＳｅｑＮｏ（複製されたパケット）又は最新のＳｅｑＮｏ及び１バイトデータ又は最新のリモートのＡＣＫ番号−１さえ使用するＡｃｋｉｎｇｔｈｅＡＣＫ（ＲＴＯすなわち失われたＡＣＫの主原因を除去するため。失われたデータセグメントは、通常、ＤＵＰＡＣＫされる → 高速再送信）。

レシーバベースド：ＡＣＫが戻って受信されて確認されない場合にＡＣＫを再送信する。最初のセグメント送信時刻から例えば１秒前にもう一度到着するためにＤＵＰＡＣＫ（高速再送信）を送信して、ＴＣＰにＣＷＮＤ＝１のスロースタートに再入させるＲＴＯを防ぐ。先行するＲＴＴインターバル中に、推定されたセンダの最大の実際の送信ウィンドウサイズ（実際のレートに対応する。この実際の送信するウィンドウサイズが全フライトパケットと同等であると仮定することができる）の％として、レシーバウィンドウサイズを動的に調整することができる。

ＴＣＰの将来のＲＦＣは、１つの余分のＡｃｋｉｎｇＡＣＫフィールド（ＡｃｋｉｎｇｔｈｅＡＣＫｓ制御フィードバックループ）を有しなければならず、これは、制御ループを完成させ（すなわち、既存ＴＣＰは、ＲＴＯが転送するリンク上のデータセグメントロス又は戻るリンク上の対応するＡＣＫロスのどちらに起因するかに関して盲目である）、両方のＴＣＰの、イベント状態の知識を改善する。あるいは、モニタソフトウェアが、ＳｅｑＮｏを有するＡＣＫ（複製されたセグメント）．．．などを介してこのＡＣＫｉｎｇｔｈｅＡＣＫｓを実行することができる。

両端にモニタソフトウェアがある状態で、レシーバは、一方向送信時間を両方向で互いに渡すために調整することができる。レシーバベースドのモニタソフトウェアは、ＳＹＮＣ接続確立で要求されたタイムスタンプオプションから、外部インターネットノードのＯＷＤ（一方向遅延）を導出することができる。センダベースドのモニタソフトウェアは、タイムスタンプオプションを介するレシーバからセンダへのＯＷＤの間に、ＩＰＭＰ、ＮＴＰ．．．を介してリモートレシーバへのＯＷＤを推定することができる。両端が協力するモニタソフトウェアを有する場合に、両方向のＯＷＤを推定することができ → ＡＣＫｓＡＣＫｉｎｇループと一緒に、これは、送信方向でのパケットドロップ又は戻る方向でのＡＣＫロス又は物理送信エラーに起因するパケットロスの区別を可能にする。

Ｏｗｄは、導出するためのタイムスタンプ、又はｉｐｍｐ／ｉｃｍｐプローブ／ｎｔｐ．．．．などを必要とする。両端にモニタソフトウェアがある状態で、タイムスタンプセグメントだけが、受信された時及びＡｃｋｉｎｇｔｈｅＳｅｇｍｅｎｔＳｅｑＮｏを返す時に（この２つのタイムスタンプ値のすべてが、イベントリストに保持されるセグメントｓｅｑｎｏ送信時間の送信側モニタ記録、及びＳｅｑＮｏのＡＣＫの到着時間と組み合わされて、すべてのＯＷＤ、端処理遅延などを提供する。

既知ＯＷＤの両方の方向、例えば海底ケーブル、ＷＡＮリンク、及び／又は既知のタイムスタンプドリフト／正確さ及び／又は輻輳／非輻輳動作環境境界の下での既知のスイッチ／ルータ／エンドホスト処理待ち時間は、性能を改善するはずである。

両方向ＯＷＤを与える準備のできた送信、受信、戻りのタイムスタンプを有するパケットだけに関するＩＣＭＰは、ｗａｎ／ｌａｎ／小さいインターネットサブセットで、両方の方向でｔｃｐ／ｕｄｐと同一の経路をトラバースする。ｔｃｐ／ｕｄｐに関するＲＦＣは、これらのタイムスタンプをイネーブルしなければならない。周期的ｉｃｍｐプローブは、パッシブｔｃｐｒｔｔ測定を補足することができる。ＩＰＭＰは、類似するタイムスタンプ機能を提供し、且つ、送信されたＴＣＰセグメントと同一の経路をトラバースし、且つ、フロー（１つ又は複数）ＴＣＰＩＰアドレスと同一のＩＰアドレスを用いるが異なるポートアドレスを用いて送信されるプローブパケットとして利用され得る。両端が変更されたＴＣＰ／変更されたモニタソフトウェアを実施する場合に、周期的プローブパケットは、フロー（１つ又は複数）ＴＣＰＩＰアドレスと同一のＩＰアドレスを有するが異なるポートアドレスを有する、この２つの端の変更されたＴＣＰ／変更されたモニタソフトウェアの間で確立される別々の独立のＴＣＰ接続又はＵＤＰ接続又はＩＰＭＰ接続の形をとることができ、両方の端の変更されたＴＣＰ／モニタソフトウェアは、今や、Ｓｅｑ番号を有するセグメントが最初に到着する時刻及び／又は同一Ｓｅｑ番号を有するセグメントがＡＣＫされ、返される時刻のタイムスタンプを含めることができ、両端によるＯＷＤ測定を可能にする。

外部インターネットを介して働くためのＴＣＰ変更の実施
ソースセンダ又はレシーバのいずれか一方（又は両方）が外部インターネットに存在する場合に、このソースセンダとレシーバとの間のデータパケット通信は、例えば、外部インターネットサイトからのｈｔｔｐウェブページダウンロード／ｆｔｐなど、我々の制御を超える輻輳パケットドロップを受ける可能性がある。本明細書の方法（１つ又は複数）は、ソースセンダ又はレシーバのいずれか一方（又は両方）が外部インターネットに存在する場合にも適用可能になるように我々の変更／発明を拡張するが、本説明に含まれるさまざまな前に説明した方法と同様に、両方がインターネットサブセット／ＷＡＮ／ＬＡＮ／プロプラエタリインターネット内に存在する場合にも適用できることに留意されたい。

輻輳パケットドロップの上記の影響は、ＲＴＯパケット再送信タイムアウト及びソースセンダＴＣＰでＣＷＮＤに１セグメントサイズがセットされた「スロースタート」への付随する復帰をトリガするはずであり、ＲＴＴ／ＴＣＰ輻輳ウィンドウサイズＣＷＮＤあたりのソースセンダＴＣＰ送信レートが例えば１Ｋ＊セグメントサイズまで戻って上昇するためには、初期「スロースタート」からのＣＷＮＤの約１０の指数関数的増加を要するはずである（２＾１０＝１Ｋ）、すなわち、ソースセンダは、レシーバから１０個の連続する成功の中断されないＡＣＫ（輻輳ドロップなし）を受信する必要があり、これは、２００ｍｓのＲＴＴでは、１Ｋ＊セグメントサイズのＣＷＮＤまで戻って上昇するのに１０＊３００ｍｓ＝３秒を要するはずである。ＣＷＮＤがＳＳＴｈｒｅｓｈ値に達したならば、ＣＷＮＤは、今や、「スロースタート」中のＡＣＫごとの指数関数的増分ではなく、ＲＴＴごとに線形に増分するのみであるはずである。ＲＦＣ２００１ｈｔｔｐ：／／ｗｗｗ．ｆａｑｓ．ｏｒｇ／ｒｆｃｓ／ｒｆｃ２００１．ｈｔｍｌを参照されたい。

エンド−エンド転送性能における最大の劣化を引き起こすのは、輻輳パケットドロップの際の、ＲＴＯパケット再送信タイムアウト及びＣＷＮＤに１セグメントがセットされた「スロースタート」への付随する再入の始まりである。したがって、リモートソースセンダＴＣＰで．．．を用いる高速再送信をトリガするためにそれらのＤＵＰＡＣＫを生成するためによりすばやく反応するようにソースセンダＴＣＰを変更することが、有利であるはずである。

現在ほとんどのＴＣＰで一般的に実施されているＤＵＰＡＣＫ高速再送信／回復アルゴリズムを用いて、センダソースＴＣＰは、今や、次の２つのシナリオの下でのみ、「スロースタート」への付随する再入を伴うＲＴＯパケット再送信タイムアウトを行うのみであるはずである。

（Ａ）センダソースＴＣＰは、データパケット（１つ又は複数）をレシーバに送信し（１つの単一のパケット又はパケットの連続するブロック）これらのパケットは、すべて、失われて／捨てられて絶対に到着せず、この故に、レシーバＴＣＰは、これらの未到着の次の期待されるＳｅｑ番号のパケット（１つ又は複数）のＤＵＰＡＣＫを生成するために、これらのパケットが実際に送信されたか否かを知るすべがない。パケットのこれらの送信された連続するブロックのうちのより後のパケットのいずれかが実際に到着した場合には、これらのパケットのうちのより以前のパケットのいくつかが捨てられた場合であっても、レシーバＴＣＰは、それでも、その代わりにＣＷＮＤを半分にするだけである高速再送信／回復をトリガするためにセンダソースＴＣＰへのＤＵＰＡＣＫを生成できる立場にあるはずであり、したがって、センダソースＴＣＰに１セグメントのＣＷＮＤを有する「スロースタート」に再入させるセンダソースＴＣＰのＲＴＯパケット再送信タイムアウトイベントが回避されることに留意されたい。既存ＲＦＣは、どの状況の下でも１秒というデフォルトＲＴＯタイムアウト最低最小フロアを規定し、したがって、高速再送信／回復をトリガするＤＵＰＡＣＫは、これらの再送信されるパケットの後続の肯定応答が例えば最小１秒のＲＴＯタイムアウト以内にセンダソースＴＣＰに戻って到着する場合に、保留中の通常のＲＴＯパケット再送信タイムアウトイベントを防ぐはずであることに留意されたい。

（Ｂ）レシーバによって生成された、センダソースＴＣＰに戻る肯定応答は、失われ／捨てられ、したがって絶対にセンダソースＴＣＰに戻って到着せず、したがって、センダソースＴＣＰは、今や、ＲＴＯタイムアウトし、１セグメントサイズのＣＷＮＤを有する「スロースタート」に再入する。

上記のシナリオ（Ａ）は、センダソースＴＣＰを変更し、その結果、例えば、直後に次に送信されるデータパケットの肯定応答が、例えば戻って受信された直前に送信されたデータパケットの肯定応答から３００ｍｓ（又は、ユーザ入力値、又は、ＲＴＴｅｓｔ（ｍｉｎ）及び／又はＯＴＴｅｓｔ（ｍｉｎ）．．．などに基づくものとすることができるアルゴリズム的に導出される値、３００ｍｓは、ここでは、２００ｍｓという遅延肯定応答最大期間より大きいものとして選択された例であった）又は例えば３００ｍｓ＋この直後に送信されるデータパケットの送信時刻以降に経過した最新のＲＴＴｅｓｔ（すなわち、我々は、今、この直後に送信されるパケットが失われ／捨てられたか、レシーバからセンダソースＴＣＰに戻るその肯定応答が失われ／捨てられたと全く安全に仮定することができる）のうちの遅い方の後に戻って受信されない場合に、（以下ではアルゴリズムＡと呼称する）（すべての送信されたデータセグメント／データパケットが、すべて、既に返され、肯定応答し返されている場合、すなわち、最新の送信された「最大の」有効なＳｅｑＮｏ＝最新の受信された「最大の」有効なＡＣＫＮｏの場合を除く）、すなわち、センダＴＣＰは、今は、経過タイムインターバルイベントによって普通に影響されずに継続しなければならない）センダソースＴＣＰは、今、即座に「連続ポーズ」状態に入らなければならないが、肯定応答パケット／通常のデータパケットが次にレシーバＴＣＰから戻って受信される（したがって、ラウンドトリップ経路が、今は完全に輻輳してはいない、すなわち、どちらの方向でも各すべてのパケットを捨ててはいない）まで、例えば、この「連続ポーズ」状態中に経過する各例えば１５０ｍｓ（又は、ユーザ入力値、又はＲＴＴｅｓｔ（ｍｉｎ）及び／又はＯＴＴｅｓｔ（ｍｉｎ）．．．などに基づくものとすることができるアルゴリズム的に導出された値）の間の１つだけの通常のデータパケット及び／又は複数の純ＡＣＫパケット送信を許容しなければならず、肯定応答パケット／通常のデータパケットが次にレシーバＴＣＰから戻って受信された時には、「連続ポーズ」は即座に停止し、「連続ポーズ」をトリガした最初に経過した３００ｍｓの前と同一の送信レート／ＣＷＮＤサイズに戻るようにすることによって、防ぐことができる。

アルゴリズムＡの諸部分を、そのさまざまな異なる組合せで異なって適合させることができる。

１．最初に経過した３００ｍｓの時に「連続ポーズ」に入るのではなく、センダソースＴＣＰは、そのＣＷＮＤをｘ％に減らすのみである（例えば、９５％、９０％、５０％．．．、これは、ユーザ入力とするか、ある考案されるアルゴリズムに基づくものとすることができる）。

及び／又は
２．最初に経過した３００ｍｓの時に「連続ポーズ」に入るのではなく、センダソースＴＣＰは、ＣＷＮＤサイズを変更せずに、「ポーズ−インターバル」の間だけ「ポーズ」し、このポーズ−インターバルは、ユーザ入力とするか、ある考案されるアルゴリズムから導出されるものとすることができる（例えば、１００ｍｓのポーズ−インターバルは、上記のステップ１でＣＷＮＤを９０％に減らすことと同等になるはずである）。

及び／又は
１．上記のステップ１及び２に加えて、最初の３００ｍｓが経過した時に「連続ポーズ」に入るのではなく、即座に「初期ポーズ−インターバル」のみの間に「ポーズ」するのみであり、この初期ポーズ−インターバルは、ユーザ入力とするかあるアルゴリズムから導出することができ、例えば、センダソースＴＣＰからレシーバＴＣＰまでパケットによってトラバースされるルータ／スイッチノードに沿って築き上げられた累積的なバッファリングされたパケット遅延のすべてが、この例えば５００ｍｓの量によってクリアされることを保証し、その後に送信されるパケットによって経験されるバッファ待ち時間を減らすために５００ｍｓとすることができる。

及び／又は
４．アルゴリズムＡ又は上記のステップ１、２、及び３に加えて、パケット送信レートが、アルゴリズムＡのように「連続ポーズ」中又は「ポーズ−インターバル」中又は「初期ポーズ−インターバル」中の例えば１５０ｍｓの経過した期間ごとに１つの通常のデータパケット及び／又は複数の純ＡＣＫパケットに制限される場合に、センダソースＴＣＰは、今や、その代わりに、「連続ポーズ」中又は「ポーズ−インターバル」中又は「初期ポーズ−インターバル」中の新しいＣＷＮＤサイズによって許容されるレートで送信し、あるいは、パケットを全く送信しない。

及び／又は
５．アルゴリズムＡ又は上記のステップ１、２、３、又は４に加えて、肯定応答パケットが、レシーバＴＣＰから戻って次に受信される（したがって、ラウンドトリップ経路が、今は完全に輻輳してはいない、すなわち、どちらの方向でも各すべてのパケットを捨ててはいない）（この時には、「連続ポーズ」又は「ポーズ−インターバル」又は「初期ポーズ−インターバル」が即座に止まり、「連続ポーズ」をトリガした最初に経過した例えば３００ｍｓの前と同一の送信レート／ＣＷＮＤサイズに戻る）までの場合に、この場合に、センダソースＴＣＰは、新しいＣＷＮＤサイズによる制限に従って適用可能な送信レートを再開する。

上記の有用な組合せの単に１つの例は、例えば５００ｍｓの間「初期ポーズ」して、この例えば５００ｍｓ中にパケットを全く送信しないこと又はこの例えば５００ｍｓ中に１つの通常のデータパケット及び／又は複数の純ＡＣＫパケットを例えば１５０ｍｓごとに許容することのいずれかによってバッファ遅延をクリアし、これに続いて、「ポーズ−インターバル」中にパケットを全く送信しないこと又はこの例えば１００ｍｓの「ポーズ−インターバル」中に例えば５０ｍｓおきに１つの通常のデータパケット及び／又は複数の純ＡＣＫパケットを許容することのいずれかによって例えば５００ｍｓが経過した時に「ポーズ−インターバル」に従うことと、その後、肯定応答パケットが次にレシーバＴＣＰから戻って受信された時に、即座に「ポーズ−インターバル」を止め、最初に経過した例えば３００ｍｓイベントの前と同一の送信レート／ＣＷＮＤサイズ又は新しいＣＷＮＤサイズによって制限される新しい送信レートに戻ることとであるはずである。最初の例えば５００ｍｓの導出の適切な選択は、ＶｏＩＰ／マルチメディアなどの他のタイムクリティカルパケットが深刻なバッファ遅延を経験しないようにするのを助けるはずであることに留意されたい。タイムスタンプオプションは、ＯＴＴｅｓｔ情報をセンダソースＴＣＰ判断で利用することを可能にすることができ、ＳＡＣＫオプションは、使用される場合に、ＤＵＰＡＣＫイベントの発生を減らすはずである。

センダソースＴＣＰを、上記のようにさらに変更して、パケットロスが輻輳ドロップ又は物理送信エラー．．．などのどれに起因するのであれ、すべての状況の下で「スロースタート」に再入する要件をなしですますことができる、すなわち、ＴＣＰを、今や、ＲＴＯ「スロースタート」再入、高速再送信レート半分化．．．などではなく、ＲＴＯパケット再送信タイムアウト又はＤＵＰＡＣＫ高速再送信の前の送信レート／ＣＷＮＤの例えば９０％まで（又は、ＣＷＮＤを変更せずに１００ｍｓの同等「ポーズ−インターバル」）に送信レート／ＣＷＮＤを維持することができる。これは、本説明で記述した方法／サブコンポーネント方法のどれにでも適用可能であるはずである。ここで、さらに変更されたＴＣＰは、例えば１秒という既存ＲＦＣの最小ＲＴＯデフォルト最低フロアの累積的なバッファリングされた遅延をクリアするための「初期ポーズ−インターバル」を含めることなど、それ相応に輻輳ドロップ反応にはるかによりすばやく反応することができる。

上記のアルゴリズムＡ自体及び／又はそのさまざまな変更された組合せを、さらに変更し／適合させることができるが、それらは、それでもそこで開示される原理に含まれるはずである。多数の中の１つの例として、変更が、ＴＣＰスタック自体の中で直接にではなく、変更されたモニタソフトウェア／変更されたプロキシＴＣＰ／変更されたＩＰフォワーダ．．．などの中で実施される場合に、変更されたモニタソフトウェア／変更されたプロキシＴＣＰ／変更されたＩＰフォワーダ．．．などは、現在のウィンドウ分の送信されるデータセグメント／データパケットのコピーを保持し、例えば送信された特定のデータセグメント／データパケットがＡＣＫされて返されていないことを変更されたモニタソフトウェア／変更されたプロキシＴＣＰ／変更されたＩＰフォワーダ．．．などが認めた時に実際の３ＤＵＰＡＣＫ高速再送信及び実際のＲＴＯパケット再送信（今は単に高速再送信及びＲＴＯ再送信をいずれにせよ全く実行しないはずのＴＣＰではなく）を実行し、ＴＣＰはすぐにＲＴＯタイムアウトを実行して、その特定の「スーンレート（ｓｏｏｎｌａｔｅ）」データセグメント／データパケットの特定の肯定応答を「スプーフィングし」、ここで実際のデータセグメント／データパケット再送信を実行し、且つ、高速再送信ＤＵＰＡＣＫの受信時に、これらをＴＣＰに転送せず、その代わりに、ここで高速再送信を実行する（したがって、この変更された端のＴＣＰは、そのＣＷＮＤ／送信レートを全く変更せず、このＣＷＮＤ／送信レートは、最大ＴＣＰウィンドウサイズ送信レートに留まることができるが、ここでの「ポーズ」期間は、センダの実際の有効送信レートを、すなわち、各秒内の制限されないＴＣＰ送信に使用可能なタイムスライスを制限することによって、調整するはずである）。

非常にしばしば、変更されたＴＣＰは、ユーザローカルホストＰＣだけでインストールされ、ｈｔｔｐウェブサーバ／ｆｔｐサーバ／マルチメディアストリーミングサーバなどのリモートセンダソースＴＣＰは、上記の変更されたＴＣＰをまだ実施していない。この故に、変更されたローカルホストＰＣのＴＣＰは、ここでは、レシーバベースドの変更されたＴＣＰとして働く、すなわち、リモートセンダソースＴＣＰにリモートに影響する必要があるはずである。ローカルホストＴＣＰがリモートセンダソースＴＣＰ輻輳制御／回避に影響できるいくつかの形は、リモートセンダソースＴＣＰにレシーバウィンドウサイズ更新を送信すること、リモートセンダソースＴＣＰでのＲＴＯパケット再送信タイムアウトを防ぐ高速再送信／回復のためにリモートセンダソースＴＣＰにＤＵＰＡＣＫを送信すること．．．などを介する。

ここで、モニタソフトウェア内で実施される非常に単純化されたレシーバベースドの変更されたＴＣＰの概要を説明する（これを、さらに変更し／適合させることができ、モニタソフトウェアではなく直接にＴＣＰ自体の中で実施することもできる）。

１．リモートセンダからＴＣＰパケットを受信する時には、必ず、フローごとのＴＣＰのテーブル内に既に存在する場合にはソースアドレス及びポートをチェックし、そうでない場合には、さまざまなパラメータを用いて新しいフローごとのＴＣＰＴＣＢを作成する（すべてのインターセプトされたパケットについて以前のＳＥＱＮＯ／送信時刻テーブルエントリを維持する必要はない）。

．最新のパケット受信ローカルシステム時刻（リモートセンダ、純ＡＣＫ、又は通常のデータパケットから受け取られる）、最新のレシーバパケットのアドバタイズされたウィンドウサイズ（ローカルＭＳＴＣＰによってリモートセンダに送信される）、最新のレシーバパケットのＡＣＫ番号すなわちリモートセンダから期待される次の期待されるＳｅｑ番号（ローカルＭＳＴＣＰによってリモートセンダに送信され、フローごとの着信パケット及び発信パケットの検査を必要とし、我々は、今や、通常の１２０秒インアクティビティを待たずに、ＦＩＮ／ＦＩＮＡＣＫの際にフローごとのＴＣＰテーブルエントリを即座に除去できなければならない）．．．など。

（任意選択）Ｓｙｎｃ／ＳｙｎｃＡＣＫ完了時に、即座に、リモートセンダのＣＷＮＤに例えば８Ｋをセットする。これは、好ましくは、例えばＡＣＫＮｏ＝リモートセンダの初期ＳｅｑＮｏ＋１を有する例えば１５個の即座のＤＵＰＡＣＫを介して行われ、ＤｉｖｉｓｉｏｎａｌＡＣＫは、一部のＴＣＰが、その代わりにＡＣＫされたバイト数だけＣＷＮＤを増分するのみなので、良好に動作しない場合があり、最適のＡＣＫ挙動は、すべてのＴＣＰで同一でない可能性がある。

注：代替案では、我々は、リモートセンダから受信される最初のデータパケットを待ち、その後、リモートセンダからの受信されたばかりのＳｅｑＮｏと同一にセットされたＡＣＫＮｏを有する（１バイトだけの不必要な再送信出費で）例えば１５個のＤＵＰＡＣＫを生成し、あるいはＤｉｖｉｓｉｏｎａｌＡＣＫを使用する。

ＴＣＰは、接続をセットアップするのに３ウェイハンドシェーキングプロシージャを使用する。接続は、開始側が、ＳＹＮフラグをセットされ、シーケンス番号フィールド内の提案される初期シーケンス番号（ｓｅｑ＝Ｘ）を有するセグメントを送信することによってセットアップされる。次に、リモートは、ＳＹＮフラグとＡＣＫフラグの両方をセットされ、シーケンス番号フィールドに逆方向のそれ自体の割り当てられた値（ｓｅｑ＝Ｙ）をセットされ、Ｘ＋１の肯定応答フィールド（ａｃｋ＝Ｘ＋１）を有するセグメントを返す。これを受信した時に、開始側は、Ｙを記憶し、ＡＣＫフラグだけをセットされ、Ｙ＋１の肯定応答フィールドを有するセグメントを返す。

２．次のパケットを受信せずに３００ｍｓが満了する場合には、
→ 我々は、ソフトウェア内で、ＡＣＫ番号に未到着の次の期待されるＳｅｑＮｏをセットされた３つのＤＵＰＡＣＫを生成するために、前の最後に受信されたパケットから３００ｍｓ以内に次の期待されるＳｅｑＮｏが到着しないことを検出し、それと同時に３つのＤＵＰＡＣＫ以内に１８００バイトのウィンドウ更新を伝え（センダの「ポーズ」＋１パケットと同等）、例えば１００ｍｓが純ＡＣＫ又は通常のデータパケットを全く受信せずに経過する場合に、毎回１８００バイトだけ増分される１８００バイトの同一の３つのＤＵＰＡＣＫウィンドウ更新を送信し続けることだけを必要とするが、ＡＣＫ又は通常のデータパケットが実際に次に受信される場合には、リモートからＡＣＫ又は通常のデータパケットが次にもう一度受信されるまで、１００ｍｓおきに繰り返して、前のウィンドウサイズを復元して（ＡＣＫＮｏフィールドにローカルＭＳＴＣＰからリモートに送信された「；記録された」最新の「最大の」ＣＫＮｏをセットする）通常の（３つのＤＵＰＡＣＫではない）同一の単一のウィンドウ更新を送信し、その後、上記の例えば３００ｍｓの満了検出ループを、上記のステップ２のまさに始めに繰り返す。

ここでは、我々が、単一のウィンドウ更新パケットの代わりに３つのＤＵＰＡＣＫを送信することもできるが、２つのさらなる１００ｍｓが経過した後に、単一のウィンドウ更新ＡＣＫパケットが、合計３つのＤＵＰＡＣＫウィンドウ更新パケットになるはずであり、もちろん、ここでの代替案を、任意のウィンドウ更新パケット、例えばＤＵＰＳｅｑＮｏウィンドウ更新パケット．．．などとすることができることに留意されたい。

（これは、保留中のリモートＭＳＴＣＰＲＴＯタイムアウトのスロースタート再入を引き起こすシナリオＡが、回避され、保留中のＲＴＯがＤＵＰＡＣＫ高速再送信／回復イベントによって置換されることを保証する。送信されたパケットが実際には全くない場合には、我々が不必要にＡＣＫ番号＝次の期待されるＳｅｑ番号を有する３つのＤＵＰＡＣＫを送信したことは、実際には問題でない。

シナリオＢは、次のＡＣＫ又はデータパケットがリモートから受信される（すなわち、ボトルネックが、現在、すべてのリモート送信されたパケットを捨ててはいない）まで、１００ｍｓおきに同一の３つのＤＵＰＡＣＫを送信し続けることによって管理され、次のＡＣＫ又はデータパケットがリモートから受信された時には、我々は、いずれかの次のパケットが受信されるまで、１００ｍｓおきに単一のウィンドウサイズ復元パケットを送信し続ける（すなわち、ワーストケースですべてのウィンドウ復元パケットが捨てられる場合であっても、３００ｍｓ後に、このプロセスが繰り返され、やはりウィンドウ「ポーズ」とその後のウィンドウ復元の試みが保証される）。

注：我々は、アドバタイズされるレシーバウィンドウサイズを連続して増分する。というのは、リモートが、以前の使用可能なレシーバがアドバタイズしたウィンドウサイズを使い果たしている可能性があるが、送信されたパケット（１つ又は複数）が捨てられ、一度もレシーバに達していないからである。リモートが一度もスロースタートすなわち通常ＲＴＯに起因するＣＷＮＤ＝１に再入していないことを確かめることによって、我々は、非常に大きいウェブページダウンロード時間削減を達成した。高速再送信は、スロースタートを引き起こさず、３つのＤＵＰＡＣＫは、リモートの既存ＣＷＮＤを半分にするだけであることに留意されたい。

上記のアルゴリズムを、次のように、他端のＴＣＰを「ポーズ」させるためにレシーバウィンドウサイズ更新を送信することを必要とせずに、さらに単純化することができる。

１．リモートセンダからＴＣＰパケットを受信する時には、必ず、フローごとのＴＣＰのテーブル内に既にある場合にはソースアドレス及びポートをチェックし、そうでない場合には、さまざまなパラメータを用いて新しいフローごとのＴＣＰＴＣＢを作成する（すべてのインターセプトされたパケットについて以前のＳＥＱＮＯ／送信時刻テーブルエントリを維持する必要はない）。

．最新のパケット受信ローカルシステム時刻（リモートセンダ、純ＡＣＫ、又は通常のデータパケットから受け取られる）、最新のレシーバパケットのＡＣＫ番号すなわちリモートセンダから期待される次の期待されるＳｅｑ番号（ローカルＭＳＴＣＰによってリモートセンダに送信され、フローごとの着信パケット及び発信パケットの検査を必要とし、我々は、今や、通常の１２０秒インアクティビティを待たずに、ＦＩＮ／ＦＩＮＡＣＫの際にフローごとのＴＣＰテーブルエントリを即座に除去できなければならない）．．．など。

（任意選択）Ｓｙｎｃ／ＳｙｎｃＡＣＫ完了時に、即座に、リモートセンダのＣＷＮＤに例えば８Ｋをセットする。これは、好ましくは、ＡＣＫＮｏ＝リモートセンダの初期シーケンス番号＋１を有する例えば１５個の即座のＤＵＰＡＣＫを介して行われ、一部のＴＣＰが、その代わりにＡＣＫされたバイト数だけＣＷＮＤを増分するのみなので、ＤｉｖｉｓｉｏｎａｌＡＣＫは、良好に動作しない場合があり、最適のＡＣＫ挙動は、すべてのＴＣＰで同一でない場合がある。

注：代替案では、我々は、リモートセンダから受信される最初のデータパケットを待ち、その後、リモートセンダからの受信されたばかりのシーケンス番号と同一にセットされたＡＣＫＮｏを有する（１バイトだけの不必要な再送信出費で）例えば１５個のＤＵＰＡＣＫを生成し、あるいはＤｉｖｉｓｉｏｎａｌＡＣＫを使用する。

２．次のパケットを受信せずに３００ｍｓが満了する場合には、
→ 我々は、ソフトウェア内で、ＡＣＫＮｏに未到着の次の期待されるＳｅｑをセットされた３つのＤＵＰＡＣＫを生成するために、前の最後に受信されたパケットから例えば３００ｍｓ以内に次の期待されるＳｅｑＮｏが到着しないことを検出することだけを必要とする。

例えば１００ｍｓが純ＡＣＫ又は通常のデータパケットを全く受信せずに経過する場合に、同一の３つのＤＵＰＡＣＫを送信し続けるが、ＡＣＫ又は通常のデータパケットが実際に次に受信される場合には、上記の例えば３００ｍｓの満了検出ループを、上記のステップ２のまさに始めに繰り返す。

シナリオＢは、次のＡＣＫ又はデータパケットがリモートから受信される（すなわち、ボトルネックが、現在、すべてのリモート送信されたパケットを捨ててはいない）まで、１００ｍｓおきに同一の３つのＤＵＰＡＣＫを送信し続けることによって管理される：次のＡＣＫ又はデータパケットがリモートから受信された時には、我々は、いずれかの次のパケットが受信されるまで、１００ｍｓおきに単一のウィンドウサイズ復元パケットを送信し続ける（すなわち、ワーストケースですべてのウィンドウ復元パケットが捨てられる場合であっても、３００ｍｓ後に、このプロセスが繰り返され、やはりウィンドウ「ポーズ」とその後のウィンドウ復元の試みが保証される）。

上記の非常に単純化されたアルゴリズムは、本明細書のさまざまな他の類似するアルゴリズムから導出される：
１．レシーバベースドの目的は、この変更を実施していないリモートセンダソースＴＣＰにできる限り「ミラーイメージ」センダベースドのように振る舞わせることである（しかし、例えばレシーバベースドは、センダソースＴＣＰが、未到着の次の期待されるＳｅｑＮｏデータセグメントを既に送信したかどうかを知るすべがない．．．など、ワークアラウンドを必要とするいくつかの些細な相違がある）。センダベースドは、通常のデータパケットのＡＣＫが遅れている時に「ポーズ」するが、ＭＳＴＣＰタイムアウト再送信（ＳｅｑＮｏ＝＜記録された最後に送信されたＳｅｑＮｏによって検出される時に、ポーズ−インターバルあたり１つの通常のデータパケットがプローブとして転送されることを可能にし、その後、ＣＷＮＤをＲＴＯの前の以前のレベルまで戻すためにインターバルＡＣＫＴｉｍｅｏｕｔに関してＭＳＴＣＰへのＡＣＫを「スプーフィングする」。我々は、今、後で機能強化するために、まず単純化されたベアボーンバージョンアップを得る。

２．ＳｅｑＮｏ／送信時刻主イベントリスト及び再送信イベントリストを使用する通常データパケットプローブ法は、十分に単純である。インターセプトされたＳＹＮＣ／ＳＹＮＣＡＣＫパケット及び／又はＰＣレジストリセッティングを変更することによって、ＳＹＮＣ／ＳＹＮＣＡＣＫ中にネゴシエートされるＴｉｍｅｓｔａｍｐオプションを保証する必要がある。

３．到着するＯＴＴｅｓｔ＞現在の記録されたＯＴＴｅｓｔ（ｍｉｎ）＋３００ｍｓの時には、これは、輻輳バッファ遅延をシグナリングする（ＯＴＴｅｓｔ（ｍｉｎ）は、リモートセンダから我々への非輻輳ＯＴＴの我々の最新の最良の推定値である） → １つの通常の１５００バイトイーサネットパケットが受信されることを可能にするために１８００バイトのウィンドウ更新を送信し、且つ、複数の小さい純ＡＣＫをも送信する。

４．到着するＯＴＴｅｓｔ＞現在の記録されたＯＴＴｅｓｔ（ｍｉｎ）＋３００ｍｓで通常のデータパケット又は純ＡＣＫを受信せずにＯＴＴｅｓｔ（ｍｉｎ）が経過する場合に、１８００バイトだけ増分された１８００バイトの同一のウィンドウ更新を送信し続ける（したがって、経過したＯＴＴｅｓｔ（ｍｉｎ）ごとに、リモートは、単一の新しい通常のデータパケットをプローブとして転送することができる）。どの時点でも、到着するオンタイムＯＴＴｅｓｔ＝＜現在の記録されたＯＴＴｅｓｔ（ｍｉｎ）＋３００ｍｓの場合には、前のレシーバウィンドウサイズを復元するウィンドウ更新を即座に送信する、すなわち、リモートは、今や、以前の通常の送信レートを再開する。

（注：これは、レートをスロットリングすることによってパケットドロップを防ぐことを試み、したがって、リモートは、もう一度スロースタートする必要が絶対にないが、外部インターネットであることは、実際には良好に動作しない！。この故に、上記の段落４は、下の段落４によって置換されなければならず、下の段落４は、現在、パケットロスイベントの際にできる限り早くリモート送信レートを復元することに単純に集中する、すなわち、我々は、再送信されたパケットを検出した際にセンダベースドの「スプーフィング」に似てリモート送信レートを即座に復元できる場合に、パケットドロップがリモートでのスロースタートを引き起こすかどうかをもはや気にしない）。

４．リモートセンダパケット「保留中」再送信は、到着するＳｅｑＮｏ＞次の期待されるＳｅｑＮｏ且つ欠けているギャップＳｅｑＮｏ（１つ又は複数）が受信されずに３００ｍｓが経過した時に、必ず検出される（すなわち、今や、ギャップパケットが失われたと安全に仮定することができ、リモートセンダは、現在、スロースタートがＲＦＣの１秒最小シーリングの満了で保留中の状態で再送信し終えるはずである） → しかし、我々のＭＳＴＣＰは、リモートにもう一度スロースタートに入らずに高速再送信させる３つの順序はずれのＳｅｑＮｏパケットの受信時に、３つのＤＵＰＡＣＫをそれ自体で既に生成するはずである（リモートセンダが、単に、送信するたまたま２つの順序はずれのＳｅｑＮｏだけを有し、それ以外は有しない場合に、これが、ものごとを混乱させてはならない。というのは、リモートがこの時に多くを送信しようとしていないので、我々は、単純に、リモートがスロースタートすることを許容することができるからである） → 我々は、ＡＣＫＮｏに未到着の期待されるＳｅｑＮｏをセットされた３つのＤＵＰＡＣＫを生成するために、次の期待されるＳｅｑＮｏが以前に受信されたパケットから３００ｍｓ以内に到着しないことを検出することだけを必要とする。

（ＳＡＣＫは、ＤＵＰＡＣＫの発生を減らすのに有用である可能性があり、ＤｉｖｉｓｉｏｎａｌＡＣＫ、ＤＵＰＡＣＫ、ＯｐｔｉｍｉｓｔｉｃＡＣＫは、センダベースドの「ＡＣＫスプーフィング」に似てリモート送信レートを復元するのに有用である可能性があることに留意されたい。ｈｔｔｐ：／／ｗｗｗ−２．ｃｓ．ｃｍｕ．ｅｄｕ／〜ｋｇａｏ／ｃｏｕｒｓｅ／ｎｅｔｗｏｒｋ．ｐｄｆ、ｈｔｔｐ：／／ｗｗｗ−２．ｃｓ．ｃｍｕ．ｅｄｕ／〜ｋｇａｏ／ｃｏｕｒｓｅ／ｎｅｔｗｏｒｋ．ｐｄｆ、及びＧｏｏｇｌｅＳｅａｒｃｈ用語「Ａｃｋｓｐｏｏｆｉｎｇ」を参照されたい）。

ここで、レシーバベースドの方法の（サンプルのみの）アルゴリズムを添付する。

１．サブネットユーザ入力、指定されたサブネットへ−からのＴＣＰフローを監視するのみ
２．外部ソース／デスティネーションを伴うＴＣＰフローは、異なって監視される
２．１外部ソース（すなわち、カスタマイズされたＴＣＰは、レシーバベースドフローコントローラとして働く）。

．接続確立中にこれらのフローのＴｉｍｅｓｔａｍｐオプションを選択する（Ｓｙｎｃパケットを変更することができるか？あるいは、上記の段落１、２のすべてのフローもタイムスタンプを用いてひとまとめにするためにＰＣレジストリをセットする必要がある可能性があるか？Ｗｉｎｄｏｗｓｅｒｖｅｒ２００３は、リモートＴＣＰによって開始される場合にタイムスタンプオプションを可能にするだけである！？）。

．リモートセンダＴＳＶａｌについてこのＴＣＰの着信パケットをチェックし、これを、受信されたまさに最初のパケットのＯＴＴｅｓｔ（ｍａｘ）として及びＯＴＴｅｓｔ（ｍｉｎ）としても記録する（現在のレシーバシステム時刻−ＴＳＶａｌ）。ＯＴＴｅｓｔは、ｏｎｅｗａｙｔｒｉｐｔｉｍｅｅｓｔｉｍａｔｅ（一方向トリップ時間推定値）すなわち、これまでに観察された最大及び最小のＯＴＴを表す。ＯＴＴｅｓｔ（ｍａｘ）及びＯＴＴｅｓｔ（ｍｉｎ）は、受信されるすべての後続パケットから更新される。

．着信パケットのＯＴＴｅｓｔ−ＯＴＴｅｓｔ（ｍｉｎ）＞例えば１００ｍｓ（ユーザ入力パラメータ）である場合には、リモートセンダは、「ポーズ」しなければならず、カスタマイズされたＴＣＰは、レシーバの最後に送信されたシーケンス番号又は最後に受信されたＡＣＫＮｏ−１をＳｅｑＮｏにセットされた（したがって、レシーバがボールでリモートセンダにデータセグメントを送信しない場合には、レシーバの最後に送信したＳｅｑＮｏがない）、例えば５０バイトの１バイトガーベジ（又はデータなし）セグメントウィンドウサイズアドバタイズメントパケット（リモートセンダＴＣＰが応答する／純粋ＡＣＫを可能にするために、必ずしも０ではない）を生成する。

レシーバは、同一の生成されたウィンドウアドバタイズメントパケット（ただし、ＳｅｑＮｏ又は最後に受信されたＡＣＫＮｏ−１が変更されている場合がある）を、これらの「複製されたパケットウィンドウ更新」パケットのうちの１つに対して受信された応答確認があり、したがって、これらのウィンドウ更新パケットのうちの少なくとも１つがセンダで受信済みであり、その応答確認が今到着する（いずれかの方向で失われる可能性がある）ことが示されるまで、送信し続け、そのＯＴＴｅｓｔ−ＯＴＴｅｓｔ（ｍｉｎ）は＜例えば１００ｍｓでなければならない（我々は、輻輳がなくなるまで「ポーズ」を停止しない）。

「ポーズ」は、ＯＴＴｅｓｔ（ｍｉｎ）＋１００ｍｓ以内に到着する任意の他のパケット、例えば通常のデータパケットの際にも停止させることができる。その際には、レシーバが、同一であるがウィンドウサイズフィールドにその「ポーズ」の直前の値をセットされたウィンドウ更新パケットを送信する（この値は、例えば５０バイトアドバタイズメントをもたらす前に記録される。

２．２リモートデスティネーション（すなわち、カスタマイズされたＴＣＰは、センダベースドとして働く）
．タイムスタンプオプションは、必要ではないが、ＲＴＴ＜タイムアウト（逆経路輻輳によって引き起こされる可能性がある）の原因をよりよく判定するために、戻る一方向遅延を知るのに有用である。

．ＳｅｑＮｏ＜最後に送信されたＳｅｑＮｏを有するＭＳＴＣＰが発するパケット（１つ又は複数）が送信される（パケットドロップ再送信）時に、ＭＳＴＣＰは、もう一度スロースタートに入るはずである：カスタマイズされたＴＣＰは、今や、例えば１００ｍｓの期間の間、ＭＳＴＣＰが発するすべてのパケットについて、ＭＳＴＣＰに戻る「ＡＣＫ」をスプーフィングするはずである。これは、輻輳ウィンドウを、例えばＴＣＰウィンドウサイズに戻すはずである。すべての後続の転送されるバッファリングされるパケットドロップは、受信されるレシーバの３つのＤＵＰＡＣＫを介して高速再送信することができる（その際に、カスタマイズされたＴＣＰは、やはり戻してＡＣＫをスプーフィングすることができる）。

我々のアルゴリズム：
１．ＴＣＰパケットを受信する時には、必ず、フローごとのＴＣＰのテーブル内に既にある場合にはソースアドレス及びポートをチェックし、そうでない場合には、さまざまなパラメータを用いて新しいフローごとのＴＣＰＴＣＢを作成する（すべてのインターセプトされたパケットについて以前のＳｅｑＮｏ／送信時刻テーブルエントリを維持する必要はない）。

．最新のパケット受信ローカルシステム時刻（純ＡＣＫ、又は通常のデータパケット）、最新のレシーバパケットのアドバタイズされたウィンドウサイズ、最新のレシーバパケットのＡＣＫ番号すなわち次の期待されるＳｅｑ番号（フローごとの着信パケット及び発信パケットの検査を必要とし、我々は、今や、１２０秒を待たずに、ＦＩＮ／ＦＩＮＡＣＫの際にフローごとのＴＣＰテーブルエントリを即座に除去できなければならない）。

２．次のパケットを受信せずに３００ｍｓが満了する場合には、
→ 我々は、ソフトウェア内で、ＡＣＫＮｏに未到着の次の期待されるＳｅｑＮｏをセットされた３つのＤＵＰＡＣＫを生成するために、前の最後に受信されたパケットから３００ｍｓ以内に次の期待されるＳｅｑＮｏが到着しないことを検出し、これと同時に３つのＤＵＰＡＣＫ以内に１８００バイトのウィンドウ更新を伝える（センダの「ポーズ」＋１パケットと同等）ことだけを必要とする：ここで、我々は、３つのＤＵＰＡＣＫがやはりリモートによって戻ってＡＣＫされることを期待し、例えば１００ｍｓが戻りＡＣＫを受信せずに経過する場合にそのたびに１８００バイトだけ増分された１８００バイトの同一の３つのＤＵＰＡＣＫウィンドウ更新を送信し続けなければならないが、戻りＡＣＫ又は通常のデータパケットが次に受信される場合には（ＯＴＴ時間に関わりなく）、前のウィンドウサイズを復元する３つのＤＵＰＡＣＫウィンドウ更新を送信する。

シナリオＢは、「ＡＣＫｉｎｇｔｈｅＡＣＫ」が受信されるまで、又は次の通常のデータパケットが受信される（すなわち、ボトルネックが、現在はすべてのリモート送信されたパケットを捨ててはいない）まで同一の３つのＤＵＰＡＣＫを１００ｍｓおきに送信し続けることによって管理される：「ＡＣＫｉｎｇｔｈｅＡＣＫ」又は次の通常のデータパケットがリモートから受信された時には、我々は、「ＡＣＫｉｎｇｔｈｅＡＣＫ」が受信されるまで、１００ｍｓおきに、アドバタイズされたウィンドウサイズを復元する３つのＤＵＰＡＣＫを送信し続ける。

次の期待されるＳｅｑＮｏのセグメントについて３つのＤＵＰＡＣＫを送信することの代替案として、我々は、３つのＤＵＰＡＣＫのＡＣＫＮｏフィールドに、その代わりに次の期待されるＳｅｑＮｏ−１をセットすることができ（再送信される１つの余分のバイトだけという犠牲で）、この場合に、我々は、回転する次の期待されるＳｅｑＮｏ −１００、−９９、−９８．．．．−１を使用してＳｅｑＮｏフィールドをセットする必要が明確にある。

しかし、ｈｔｔｐ：／／ｗｗｗ．ｃｓ．ｒｕｔｇｅｒｓ．ｅｄｕ／〜ｍｕｔｈｕ／ｗｔｃｐ．ｐｄｆを参照されたく、このサイトでは、ＴＣＰが、この場合に、「現在の輻輳ウィンドウ内の最低の肯定応答されていないパケット又は最初の未送信のパケットから始めて」再送信することが提案されている。

これが仕様により近くなることを期待されたく、ソフトウェアは、それでも、受信されるパケット及び送信されるパケットのいずれをも変更せずに「パッシブパススルー」のままになる。リモートＭＳＴＣＰは、今や、決してＲＴＯ再入スロースタートしなくなる。

単一ＰＣシェアウェアについて、我々は、プローブ及びタイムスタンプ機能を全く必要としない（段落２）：ウィンドウ更新は、純ＡＣＫ又は通常のデータパケットを受信するまで（受信時刻は問題でない）、１００ｍｓおきに単純に繰り返すことができる（段落４の３＊ＯＴＴｅｓｔ（ｍｉｎ）の代わりに）。ここで、我々のフローがパケットを捨てる時に、我々は、パケットが捨てられるのと同一のボトルネックをトラバースする他のフローのＭＳＴＣＰが、我々自身のＭＳＴＣＰと同一の時刻前後にＲＴＯレートすることを知る → 我々は、リモートセンダのＣＷＮＤを安全に復元することができる。

１．目的は、リモートに、できる限り「ミラーイメージ」センダベースドのように振る舞わせることである：センダベースドは、通常のデータパケットのＡＣＫが遅れている時に「ポーズ」するが、ＭＳＴＣＰがタイムアウト再送信する（ＳｅｑＮｏ＝＜記録された最後の送信されたＳｅｑＮｏによって検出される時に、ポーズ−インターバルあたり１つの通常のデータパケットがプローブとして転送されることを可能にし、その後、ＣＷＮＤをＲＴＯの前の以前のレベルまで戻すために、ＡＣＫＴｉｍｅｏｕｔインターバルの間にＭＳＴＣＰへのＡＣＫを「スプーフィング」する。我々は、今、後に機能強化するために（例えば、ＳＡＣＫギャップパケット機能が有用である可能性がある）、まず、単純化されたミラーリングされるベアボーンレシーバベースドバージョンアップを得なければならない。

２．ＳｅｑＮｏ／送信時刻主イベントリスト及び再送信イベントリストを使用する、通常データパケットプローブ法は、十分に単純である。インターセプトされたＳＹＮＣ／ＳＹＮＣＡＣＫパケット及び／又はＰＣレジストリセッティングを変更することによって、ＳＹＮＣ／ＳＹＮＣＡＣＫ中にネゴシエートされるＴｉｍｅｓｔａｍｐオプションを保証する必要がある。

［単純化されたアルゴリズムではもはや不要である
３．到着するＯＴＴｅｓｔ＞現在の記録されたＯＴＴｅｓｔ（ｍｉｎ）＋３００ｍｓの時には、これは、輻輳バッファ遅延をシグナリングする（ＯＴＴｅｓｔ（ｍｉｎ）は、リモートセンダから我々への非輻輳ＯＴＴの我々の最新の最良の推定値である） → １つの通常の１５００バイトイーサネットパケットが受信されることを可能にするために１８００バイトのウィンドウ更新を送信し、且つ、複数の小さい純ＡＣＫをも送信する。］。

［単純化されたアルゴリズムではもはや不要である
４．到着するＯＴＴｅｓｔ＞現在の記録されたＯＴＴｅｓｔ（ｍｉｎ）＋３００ｍｓで通常のデータパケット又は純ＡＣＫを受信せずにＯＴＴｅｓｔ（ｍｉｎ）が経過する場合に、１８００バイトだけ増分された１８００バイトの同一のウィンドウ更新を送信し続ける（したがって、経過したＯＴＴｅｓｔ（ｍｉｎ）ごとに、リモートは、単一の新しい通常のデータパケットをプローブとして転送することができる）。どの時点でも、到着するオンタイムＯＴＴｅｓｔ＝＜現在の記録されたＯＴＴｅｓｔ（ｍｉｎ）＋３００ｍｓの場合には、以前のレシーバウィンドウサイズを復元するウィンドウ更新を即座に送信する、すなわち、リモートは、今や、前の通常の送信レートを再開する。］。

（注：これは、レートをスロットリングすることによってパケットドロップを防ぐことを試み、したがって、リモートは、もう一度スロースタートする必要が絶対にないが、外部インターネットであることは、実際には良好に動作しない！。パケットドロップの直前にＯＴＴｅｓｔを知ることは非常にむずかしく、この故に、上記の段落４は、下の段落４によって置換されなければならず、下の段落４は、現在、パケットロスイベントの際にできる限り早くリモート送信レートを復元することに単純に集中する、すなわち、我々は、再送信されたパケットを検出した際にセンダベースドの「スプーフィング」に似てリモート送信レートを即座に復元できる場合に、パケットドロップがリモートでのスロースタートを引き起こすかどうかをもはや気にしない）。

４．リモートセンダパケット「保留中」再送信は、到着するＳｅｑＮｏ＞次の期待されるＳｅｑＮｏ且つ欠けているギャップＳｅｑＮｏ（１つ又は複数）が受信されずに３００ｍｓが経過した時に、ソフトウェアによって必ず検出される（すなわち、今や、ギャップパケットが失われたと安全に仮定することができ、リモートセンダは、現在、スロースタートがＲＦＣの１秒最小シーリングの満了で保留中の状態で再送信し終えるはずである） → しかし、我々のＭＳＴＣＰは、リモートにもう一度スロースタートに入って／入らずに高速再送信させる３つの順序はずれのＳｅｑＮｏパケットの受信時に、３つのＤＵＰＡＣＫをそれ自体で既に生成するはずである（リモートセンダが、単に、送信するたまたま２つの順序はずれのＳｅｑＮｏだけを有し、それ以外は有しない場合に、これが、ものごとを混乱させてはならない。というのは、リモートがこの時に多くを送信しようとしていないので、我々は、単純に、リモートがスロースタートすることを許容することができるからである） → 我々は、ＡＣＫＮｏに未到着の次の期待されるＳｅｑＮｏをセットされた３つのＤＵＰＡＣＫを生成するために、次の期待されるＳｅｑＮｏが前に最後に受信されたパケットから３００ｍｓ以内に到着しないことをソフトウェア内で検出すると同時に、３つのＤＵＰＡＣＫ内で１８００バイトのウィンドウ更新を伝える（センダの「ポーズ」＋１パケットと同等）ことだけを必要とする：ここで、我々は、３つのＤＵＰＡＣＫがやはりリモートによって戻ってＡＣＫされることを期待し、例えば３＊ＯＴＴｅｓｔ（ｍｉｎ）が戻りＡＣＫを受信せずに経過する場合にそのたびに１８００バイトだけ増分された１８００バイトの同一の３つのＤＵＰＡＣＫウィンドウ更新を送信し続けなければならないが、戻りＡＣＫ又は通常のデータパケットが次に受信される場合には（ＯＴＴ時間に関わりなく）、前のウィンドウサイズを復元する３つのＤＵＰＡＣＫウィンドウ更新を送信する。

（ここで、我々は、レシーバウィンドウサイズを更新するために、早期にパケットドロップを検出するだけであり、これは、センダベースの「ポーズ」＋１パケットと同等である）。

５．リモートに高速再送信させる実際のＤＵＰＡＣＫは、すべてがＭＳＴＣＰ自体によって処理される。ソフトウェアは、インターセプトされたＭＳＴＣＰの２つの追加のＤＵＰＡＣＫ（より以前に通常に肯定応答されたものを含める場合には全部で３つ）を検出して、その後、ＤｉｖｉｓｉｏｎａｌＡＣＫ／ＤＵＰＡＣＫ／ＯｐｔｉｍｉｓｔｉｃＡＣＫ技法を介してリモートＣＷＮＤを即座に復元することだけを必要とする。ｈｔｔｐ：／／ａｒｓｔｅｃｈｎｉｃａ．ｃｏｍ／ｒｅｖｉｅｗｓ／２ｑ００／ｎｅｔｗｏｒｋｉｎｇ／ｎｅｔｗｏｒｋｉｎｇ−３．ｈｔｍｌ及びｈｔｔｐ：／／ｗｗｗ．ｕｓｅｎｉｘ．ｏｒｇ／ｅｖｅｎｔｓ／ｕｓｉｔｓ９９／ｓｕｍｍａｒｉｅｓ／を参照されたい。

（ここで、我々は、ＭＳＴＣＰが２つの追加のＤＵＰＡＣＫを送信する際に、センダベースド「スプーフ」ＡＣＫに似たことを行っている）
注：シナリオＢは、「ＡＣＫｉｎｇｔｈｅＡＣＫ」が受信されるまで、又は次の通常のデータパケットが受信される（すなわち、ボトルネックが、現在はすべてのリモート送信されたパケットを捨ててはいない）まで同一の３つのＤＵＰＡＣＫを１００ｍｓおきに送信し続けることによって世話される：「ＡＣＫｉｎｇｔｈｅＡＣＫ」又は次の通常のデータパケットがリモートから受信された時には、我々は、「ＡＣＫｉｎｇｔｈｅＡＣＫ」が受信されるまで、１００ｍｓおきに、アドバタイズされたウィンドウサイズを復元する３つのＤＵＰＡＣＫを送信し続ける。

次の場合に、
ＭＳＴＣＰは、必ず、すべての順序はずれのＡＣＫ（すなわち、まだ送信されていないセグメントを肯定応答するＡＣＫ）を肯定応答し、さもなければ、ＡＣＫＮｏフィールドのすべてに同一の期待されるＳｅｑ番号がセットされている場合に３つのＤＵＰＡＣＫのＳｅｑＮｏフィールドを含める必要があるはずである（注：ＤＵＰＳｅｑＮｕｍｂｅｒパケットは、ＲＦＣでは必ずＡＣＫされる！？）。

我々は、ＡＣＫＮｏフィールドのすべてに同一の次の期待されるＳｅｑ番号がセットされたＤＵＰＡＣＫ内の１００個の以前のＳｅｑＮｕｍｂｅｒフィールド（すなわち、「記録された」次の期待されるＡＣＫ−１００）を回転式に使用するという前に述べた方法を使用してもよく、その結果、ＤＵＰＡＣＫは、今や、それぞれ、異なるＳｅｑＮｏフィールドに、記録された次の期待されるＳｅｑＮｏ−１００のいずれかをセットされる（２つのＤＵＰＡＣＫが同一のＳｅｑ番号を有することはない）。

注：まだ未送信のセグメントの３つのＤＵＰＡＣＫが、必ずしも、リモートＭＳＴＣＰによるＣＷＮＤ半分化をトリガせず、ＳＳＴＨＲＥＳＨに現在のＣＷＮＤの半分をセットしない（パケットは、送信済みであるが捨てられている（この場合には、確かにＣＷＮＤを半分にして高速再送信を行う）か、まだ送信されていない（この場合には、不必要にＣＷＮＤを半分にして高速再送信を行っても行わなくてもよい）かのいずれかである可能性がある）とも仮定され、さもなければ、わずかに不必要な性能減損がある。

輻輳表示としてパケット到着間（Ｉｎｔｅｒ−ｐａｃｋｅｔ−ａｒｒｉｖａｌ）遅延を使用する方法
この本体の説明で以前に説明した方法、サブコンポーネント方法のどれにおいても、輻輳表示又はパケットドロップ表示を、その代わりに、変更されたＴＣＰ／変更されたモニタソフトウェア／変更されたプロキシ／変更されたポートフォワーダ．．．などによって、パケット到着間の間の遅延、例えば、具体的には、直接に連続するパケットの間の「経過タインインターバル」が、リモート送信ソースＴＣＰ又はリモートレシーバＴＣＰから受信された最後のパケット（純ＡＣＫ又は通常のデータパケット．．．などのいずれか）以降に、あるユーザ入力インターバル（又は、ＲＴＴｅｓｔ、ＯＴＴｅｓｔ、ＲＴＴｅｓｔ（ｍｉｎ）、ＯＴＴｅｓｔ（ｍｉｎ）．．．などに基づくものとすることができるあるアルゴリズムから導出される）を超える時を観察することによって、検出し／推論することができる。ここで、各端が同時に送信でき、受信できる対称の間のＴＣＰ接続に留意されたく、一端が送信したデータセグメント／データパケット及びそれらに対応する他端からの戻り応答ＡＣＫ（以下ではサブフローＡと称する）を、他端が独立に送信したデータセグメント／データパケット及びそれらの独立の対応する他端からの戻り応答ＡＣＫ（以下ではサブフローＢと称する）と混合することができる：したがって、変更されたＴＣＰ／変更されたモニタソフトウェア／変更されたプロキシ／変更されたポートフォワーダ．．．などは、上記のパケット到着間の遅延を観察する時に、サブフローＡ及び／又はサブフローＢのパケット到着間を完全に独立に「見分け」、別々に観察しなければならない → その結果、一端のすなわちサブフローＡの送信データセグメント／データパケットが他端への前方の経路に沿って捨てられ、これによってそれに対応する戻り応答ＡＣＫが他端から戻り経路に沿って返されない時に、独立に、戻り経路に沿って到着する他端のすなわちサブフローＢの送信データセグメント／データパケットは（存在する場合に）、この端に、今や、独立のサブフローＡの「経過時間インターバル」がまだ満了していないと誤って仮定させなくなる。一端の変更されたＴＣＰ／変更されたモニタソフトウェア／変更されたプロキシ／変更されたポートフォワーダ．．．などは、センダとして働く時に、「経過時間インターバル」満了についてパケット到着間遅延についてそれ自体のサブフローＡの対応する戻り応答ＡＣＫだけを観察し、他端の独立のサブフローの送信セグメント／パケットを無視するはずである。一端の変更されたＴＣＰ／変更されたモニタソフトウェア／変更されたプロキシ／変更されたポートフォワーダ．．．などは、レシーバとして働く時に、「経過時間インターバル」満了についてパケット到着間遅延について他端自体のサブフローＢの着信セグメント／パケットを観察するだけであり、この端自体の独立のサブフローＡの（存在する場合に）対応する到着する返される応答ＡＣＫストリームを無視する。このタスクは、十分に単純でなければならない：一端は、センダベースドとして働く時には、「経過時間インターバル」満了について「インターパケットインターバル」遅延についてそれ自体の送信パケットの対応する着信戻り応答ＡＣＫを監視することだけを必要とするが、レシーバベースドとして働く時には、他端の送信データセグメント／データパケットを監視することだけを必要とするはずである：さらに、その「インターパケットインターバル」遅延が今や「経過時間インターバル」満了した他端からの、この端の独立サブフローの送信パケットの対応する戻り応答ＡＣＫの「経過時間インターバル」満了の前に、他端の独立のサブフローの送信パケットが到着し続ける場合には、これは、それ相応に反応するために、他端からこの端への一方向経路が「ＵＰ」であることと、この端から他端への一方向経路が「ＤＯＷＮ」であることとの追加の確かな表示／確かな推論を提供するはずである。これは、例えば、ＲＴＴｅｓｔ又はＯＴＴｅｓｔ又はＲＴＴｅｓｔ（ｍｉｎ）又はＯＴＴｅｓｔ（ｍｉｎ）．．．などよりはるかに小さい「経過時間インターバル」を指定でき、輻輳イベント及び／又はパケットドロップイベント及び／又は物理送信エラーイベントを検出でき／推論できることによるはるかにより高速のレートの応答時間を可能にするという利益を有する（非輻輳ＲＴＴ、ＯＴＴなどでさえ、インターネット上で数百ミリ秒になる可能性があり、確認できず、あるいは、その最大限界が、前もって確認できないが、パケットの最後の受信からの上記の経過時間インターバルは、数百ミリ秒ではなく例えば５０ｍｓもの小さい値になるように選択することができる）。

例えばｆｔｐ／ｈｔｔｐウェブサイトダウンロード中に、通常のデータパケットは、ＲＴＯパケット再送信がＣＷＮＤを１又はセグメントサイズにリセットされたスロースタートに再入することによって中断されない時に、継続的に送信される。この場合のパケットによってトラバースされる経路の最低帯域幅リンクが、送信するソースＴＣＰのファーストマイルの最低帯域幅リンク、例えば５００ＫｂｓＤＳＬであると仮定すると、単一のパケットが送信するソースからＤＳＬ伝送媒体に完全に出るための送信時間遅延は、この場合には重要な要因ではないはずであり、小さく、例えば、大きい１５００バイトイーサネットサイズを有するパケットについて２４ｍｓである（１５００＊８／５０００００＝２４ｍｓ）。一方、ラストマイルの５６Ｋｂｓモデムダイヤルアップについて、通常の５００バイトパケットの送信遅延時間は、約７１ｍｓになるはずである（５００＊８／５６０００＝７１ｍｓ）。今日のインターネットでは、パケットによってトラバースされる経路に沿った最低の可能な帯域幅のリンクは、ワーストケースシナリオで５６Ｋｂｓになるはずである。デフォルトパケットサイズは、通常は接続確立中にＴＣＰによってネゴシエートされるとおり、通常は約５００バイトである。「パケット到着間」法（及び／又は「同期化」パケット法、後のセクションを参照されたい）は、この経路に沿った５６ｋｂｓ最低帯域幅リンクの仮定及びネゴシエートされた最大パケットサイズに基づく「経過時間インターバル」値セッティング及び「同期化」インターバル値セッティングから開始し、その後、通常のデータパケットの間（又は実際に送信されたデータパケットに関するＡＣＫの間）の受信されたパケット到着間インターバルの実際に観察された最新の最小値を監視し続けて、「経過時間インターバル」値セッティング及び「同期化」インターバル値セッティングを動的に調整することができ、例えば、最新の最小「パケット到着間」インターバルが、現在は２０ｍｓに過ぎない場合に、「経過時間インターバル」値に現在は例えば８０ｍｓをセットすることができ、「同期化」インターバル値に現在は例えば４０ｍｓをセットすることができ．．．などであり、あるいは、考案されるアルゴリズムに基づいて導出することができる。データパケットが送信するソースＴＣＰから継続的に送信され、レシーバＴＣＰで受信される時のパケット間間隔は、トラバースされたリンクがさまざまな遅延及び／又はバッファ遅延を導入した場合であっても、それぞれ２４ｍｓ又は７１ｍｓ前後を中心とする上と同一のパケット到着間間隔と、ノードがストアアンドフォワードスイッチング（ストアアンドフォワードと比較して、各ノードで出会う単一パケット送信時間遅延を表すはずのカットスルースイッチングではなく）を使用する場合にトラバースされる経路に沿った各ノードで出会う単一パケット送信時間遅延に起因するインターバルの総量との合計を示さなければならない。というのは、これが、バッファ遅延がもちろん続く次のパケットに前のパケットからの余分の例えば２００ｍｓを非常に突然に即座に追加せず（すなわち、追加のバッファ遅延は各連続する続くパケットに連続的に徐々に追加されるはずである）パケットがルートに沿って捨てられず／失われない（そうである場合には、これは、この続くパケットに直前の送信されたパケットからの「無限の」遅延を追加し、この続くパケットは捨てられ／失われる可能性がある）と仮定すると、データパケットに均一に影響し、これらのデータパケットは、それぞれ上記の２４ｍｓ又は７１ｍｓ付近を中心として離隔されてレシーバに到着するからである（我々は、この輻輳イベント及び／又はパケットロスイベント及び／又は物理送信エラーイベントを、パケット間遅延が現在突然にある値、例えば１００ｍｓを超えることすなわち、最後のパケットが受信されてから１００ｍｓであることすなわち、１００ｍｓが直接に続くパケットすなわち正しい次の期待されるシーケンス番号を有するパケットを受信せずに経過したことを観察することによって検出し／推論することができる：しかし、他の後の続くパケットをこの１００ｍｓ以内に受信でき、且つ、この特定の直接に続くパケットが受信されない場合であっても、我々は、望まれる場合に、同様に、これを「ギャップ」輻輳イベント及び／又はパケットドロップイベント及び／又は物理送信エラーイベントとみなし、同様の又はわずかに異なる形で処理することができる）。

ノードがストアアンドフォワードスイッチング（ストアアンドフォワードと比較して、各ノードで出会う単一パケット送信時間遅延を表すはずのカットスルースイッチングではなく）を使用する場合にトラバースされる経路に沿った各ノードで出会う単一パケット送信時間遅延に起因するインターバルの総量は、トラバースされる経路に沿ったノードが高帯域幅容量リンクである場合（カットスルースイッチングではなくストアアンドフォワードスイッチングが使用される場合であっても）の２〜３ミリ秒から、トラバースされるリンクが低帯域幅容量である場合の数十又は２〜３百ミリ秒まで変化し得る。例えば、５００Ｋｂｓファーストマイル、１０Ｍｂｓの次のリンク、１００Ｍｂｓの次のリンク、１０Ｍｂｓの次のリンク、及び５００ＫｂｓＤＳＬの最後のレシーバラストマイルリンクに関して、ここではトラバースされるノードのそれぞれでの輻輳バッファ遅延が全くないと仮定されるカットスルースイッチングと比較してすべてがストアアンドフォワードスイッチングを実施するノードを有する転送するリンクの各連続するステージで単一の１５００バイトサイズパケットが出会う総送信完了時間遅延は、約２４ｍｓ＋１．２ｍｓ＋０．１２ｍｓ＋１．２ｍｓ＋２４ｍｓ＝５０．５２ｍｓになるはずである、すなわち、最終的にデスティネーションで受信される時に、パケット到着間インターバルは、直接に連続するパケットの間で５０．５２ｍｓ付近を中心とするはずである。一方、５６Ｋｂｓファーストマイルモデムリンク、１０Ｍｂｓの次のリンク、１００Ｍｂｓの次のリンク、１０Ｍｂｓの次のリンク、及び最後に５６Ｋｂｓレシーバラストマイルモデムリンクに関して、ここではトラバースされるノードのそれぞれで輻輳バッファ遅延が全くないと仮定されるカットスルースイッチングと比較してすべてがストアアンドフォワードスイッチングを実施するノードを有する転送するリンクの各連続するステージで単一の５００バイトサイズパケットが出会う総送信完了時間遅延は、約７１ｍｓ＋０．４ｍｓ＋０．０４ｍｓ＋０．４ｍｓ＋７１ｍｓ＝１４２．８４ｍｓになるはずである、すなわち、最終的にデスティネーションで受信される時に、パケット到着間インターバルは、直接に連続するパケットの間で５０．５２ｍｓ付近を中心とするはずである。パケットがソースからデスティネーションに最終的に到着する時間を増やし、はるかに後に送信されたパケット（すなわち、参照される、より以前に送信されたパケットに直接に続く次のパケットではなく、例えば数秒又は数十秒をまたぐ）がデスティネーションレシーバに実際に到着するのに、はるかにより以前の参照される送信されたパケットより例えば３００ｍｓ長い時間を要するようにさせる場合がある任意の輻輳バッファ遅延は、トラバースされるノードで出会う累積輻輳バッファ遅延によって引き起こしたが、しかし、任意の２つの直接に連続する次の送信パケットと直前の送信パケットとの間で、直前の送信パケットと比較して直接に続く次のパケットが出会う「余分の」増加した累積輻輳バッファ遅延は、例えば３ｍｓに過ぎない、すなわち、離れた数秒にまたがる２つの離れた送信パケットの間の、上記の例えば３００ｍｓより数桁非常にはるかに小さい可能性があるので（ここでは輻輳レベルが高まりつつあると仮定するが、同一の論法が、輻輳レベルが下がりつつある場合に同様にあてはまる）。この「余分」の追加の輻輳バッファ遅延は、直接に続く次のパケットとその直前の送信パケットとの間と同様に小さいはずであり、直接に続く次のパケットとその直前の対応物との任意の後続の対の間で徐々に増加するだけであるはずである。直接に続く次のパケットとその直前の対応物との任意の後続の対の間の、この可能な余分の少ない量の輻輳バッファ遅延は、輻輳レベルが安定し／直接に隣接するその後に送信される対の他の後続対の間で均等に平滑化される場合には小さく、均等に中和されるけれども、しかし、輻輳イベント及び／又はパケットドロップイベント及び／又は物理送信エラーイベントを検出し／推論するために、センダソースＴＣＰから次の／直接に次のパケットを受信していない時に経過時間期間値を選択し／導出する時に考慮しなければならない／考慮することができる。しかし、非常に希な場合に、輻輳レベルは、例えば着信リンクが１００Ｍｂｓ且つ発信リンクがわずか１０Ｍｂｓ．．．などである時などに、短い期間、例えば１００ｍｓ以内に例えば２００ｍｓのバッファ遅延を突然に築き上げることができ（不可能ではない）、その場合に、我々は、ここで、便利に、輻輳イベント及び／又はパケットドロップイベント及び／又は物理送信エラーイベントに加えて、この非常に希な非常に突然の輻輳バッファ遅延イベントを検出し／推論するために、経過時間インターバルを考慮するシナリオを含めることができる。直接に続く次のパケットとその直前の対応物との任意の後の後続のさらなる送信される対の間と同様に、この突然の非常に希な輻輳レベル増加は、今はもう、突然の輻輳増加が安定し／直接に隣接する後に送信される対の他の後続のさらなる送信される対の間で均等に平滑化される時に、「経過時間インターバル」に均等に中和されて満了させることをしなくなるはずであることに留意されたい。

ＴＣＰ接続が全二重である、すなわち、接続の両端のそれぞれが、同時にセンダソースＴＣＰ及びレシーバＴＣＰとして送信し、且つ受信していることができることに留意されたい。例えばｆｔｐファイルダウンロード／ｈｔｔｐウェブページダウンロード．．．など、接続の１つの端だけが、通常のデータパケットの送信のほとんどすべて又はすべてを行っている場合であっても、受信端ＴＣＰは、必ず、受信された通常のデータパケットに応答して、通常のデータパケットの送信のほとんどすべて又はすべてを行っている端のＴＣＰに向けて肯定応答を送り返しているはずである。この故に、上記の前述の段落で概要を示した「経過時間インターバル」法は、「経過時間インターバル」が、ダウンロードを受信している他端のＴＣＰから純ＡＣＫパケット及び／又はピギーバックＡＣＫパケットを受信せずに満了する際に、通常のデータパケットの送信のほとんどすべて又はすべてを行っている端のＴＣＰが、今や、輻輳イベント及び／又はパケットドロップイベント及び／又は物理送信エラーイベント及び／又は「非常に希な」「非常に突然の」輻輳レベル増加イベントの検出を推論でき、それ相応に反応できるという点で、通常のデータパケットの送信のほとんどすべて又はすべてを行っている端のＴＣＰに同様に適用される。しかし、この場合に、レシーバ端ＴＣＰが、ＤｅｌａｙｅｄＡｃｋｎｏｗｌｅｄｇｅｍｅｎｔ（１つおきのパケット又は２００ｍｓ満了のどちらが先であれ、それが発生した時に生成されるＡＣＫ）を実施し、このＤｅｌａｙｅｄＡＣＫオプションが、特定のフローごとのＴＣＰ接続についてアクティブ化される時に、選択されるかアルゴリズム的に導出される「経過時間インターバル」値のセッティングにおいて、ＤｅｌａｙｅｄＡＣＫ機構によって導入される可能な追加の２００ｍｓ遅延を含めるために考慮を払わなければならず、例えば、ＤｅｌａｙｅｄＡＣＫの場合に、「経過時間インターバル」は、２００ｍｓを加算されなければならず、あるいは、任意選択として、「経過時間インターバル」に２００ｍｓを加算するのではなく、その代わりに、この出会ったワーストケースの２００ｍｓ遅延イベントを、「経過時間インターバル」満了時に推論可能な／検出されるさまざまなイベントの間に含める。このイベントは、希であり、例えばレシーバ端ＴＣＰへのパケットのセンダソースＴＣＰ送信によどみがある時などに発生するはずであり、したがって、ワーストケースＤｅｌａｙｅｄＡＣＫシナリオに起因してスループット性能に大きくは影響しないはずである。

次のパケットを受信せずに「経過時間インターバル」が満了する時の上記のイベントの検出／推論の際に（ここで、我々は、情報を一切必要とせず、任意選択でＲＴＴ、ＯＴＴ．．．などの使用を全く必要とせず、ヒストリカルＲＴＴ値に基づくＲＴＯ計算を必要とせず（その代わりに、実際のパケット再送信タイムアウトを、例えばあるユーザ入力値又は例えばヒストリカルパケット到着間インターバル値．．．などに基づくアルゴリズムから導出される値に基づいて、トリガすることができる）、任意選択として、そのような要件を、今は要件に対する冗長な余りなので、変更されたＴＣＰから除去することができることに留意されたい）、変更されたＴＣＰ／変更されたソフトウェアモニタ／変更されたプロキシ／変更されたＩＰフォワーダ／変更されたファイヤウォール．．．などは、本説明における先の方法／サブコンポーネント方法で記述した、ＣＷＮＤ減少／レート減少と同時の既存の結合された実際のパケット再送信、及び／又は実際のパケット再送信だけが付随しない変更された分離されたＣＷＮＤ減少／レート減少、及び／又は付随するＣＷＮＤ減少／レート減少を伴う又は伴わないさまざまな変更された「ポーズ」法．．．などに進むことができる。上記のプロセスが、「パケット間インターバル」遅延の「経過時間インターバル」が満了した時にトリガされたならば、その後に、送信するソースＴＣＰからの同一サブフローから次に到着する到着するパケットの際に、そのトリガされたプロセスを、即座に又は任意選択としてある定義されたインターバルの後にのいずれかに終了することができ、ＣＷＮＤサイズ／レートリミットを、「経過時間インターバル」が満了する前の以前の値に任意選択で復元することができ、且つ／又は、任意選択で、進行中の「ポーズ」を「アンポーズ」すること．．．などができる。このパケットの到着は、今や、センダソースＴＣＰからレシーバＴＣＰへの経路が、現在、すべてのパケットを捨てる完全な輻輳ではないことを示す：任意選択として、我々は、さらに、通常のデータが、正しい次の期待されるシーケンス番号を有するまさに次の期待されるパケットでなければならない場合に、及び／又は純ＡＣＫパケットが、そのＳｅｑｕｅｎｃｅＮｕｍｂｅｒフィールド＝センダソースＴＣＰからレシーバＴＣＰに受信された最後に受信された有効なシーケンス番号（又は、レシーバＴＣＰからセンダソースＴＣＰに送信された最新の最大の有効な肯定応答番号−１）を有しなければならない場合に、この到着するパケットを要求することができる。

同様に、変更されたＴＣＰ／変更されたソフトウェアモニタ／変更されたプロキシ／変更されたＩＰフォワーダ／変更されたファイヤウォール．．．などは、任意選択として及び／又はさらに、この本体の説明の以前の方法／サブコンポーネント方法で説明した、ＣＷＮＤ減少／レート減少と同時の既存の結合された実際のパケット再送信、及び／又は実際のパケット再送信の付随だけが伴わない変更された分離されたＣＷＮＤ減少／レート減少、及び／又は付随するＣＷＮＤ減少／レート減少を伴う又は伴わないさまざまな変更された「ポーズ」法．．．などを他端のＴＣＰに実行させることに進むことができる。あるいは、変更されたＴＣＰ／変更されたソフトウェアモニタ／変更されたプロキシ／変更されたＩＰフォワーダ／変更されたファイヤウォール．．．などは、任意選択として及び／又はさらに、その後、本説明における先の方法／サブコンポーネント方法で記述した、ＣＷＮＤ減少／レート減少と同時の既存の結合された実際のパケット再送信、及び／又は実際のパケット再送信の付随だけが伴わない変更された分離されたＣＷＮＤ減少／レート減少、及び／又は付随するＣＷＮＤ減少／レート減少を伴う又は伴わないさまざまな変更された「ポーズ」法．．．などを他端のＴＣＰに実行させる（ローカルＴＣＰにそれを全く行わせずに！。そのような機能は、例えば、通常のデータパケット送信のほとんどすべて又はすべてを行う他端のＴＣＰが、既存の未変更の標準ＴＣＰである時に有用であるはずである）ことに進むことだけができる。上記のプロセスが、「経過時間インターバル」が満了した時にトリガされたならば、他端のＴＣＰからの同一のサブフローから到着する到着するパケットの際に、上記のトリガされたプロセスを、即座に又は任意選択としてある定義されたインターバルの後にのいずれかに終了することができ、ＣＷＮＤサイズ／レートリミットを、「経過時間インターバル」が満了する前の以前の値に任意選択で復元することができ、且つ／又は、任意選択で、進行中の「ポーズ」を「アンポーズ」すること．．．などができる。他端のＴＣＰが、既存の未変更のＴＣＰであるか、まだそのような機構を可能にするために特に変更されてはいない場合に、他端のＴＣＰに、リモートＴＣＰ／リモートアプリケーション／リモートプロセスのために、あるプロトコルコマンドを介して直接に、その他端のＴＣＰの内部ＣＷＮＤサイズ／送信レートを変更させることは、たやすく実現できない。しかし、他端のＴＣＰが、既存の未変更のＴＣＰであるか、まだそのような機構を可能にするために特に変更されてはいない場合であっても、他端のＴＣＰに、この本体の説明のさまざまな以前の方法／サブコンポーネント方法で概要を示したように、「ポーズ」させ、且つ／又は「アンポーズ」させ、且つ／又は「ポーズ」するが定義された最大個数のバイト／パケットの送信を可能にさせる．．．ことなどはたやすく実現でき、例えば、他端のＴＣＰでさまざまな「ポーズ」を引き起こすための「０」バイト及び／又は「１６００バイト」．．．などのレシーバウィンドウサイズ更新パケットの送信、他端のＴＣＰを「アンポーズ」させ／その通常動作を復元するための「トリガされた」イベントの前の以前のサイズのレシーバウィンドウサイズ更新パケットの送信．．．などがたやすく可能である（外部インターネットを介して働くためのＴＣＰ変更の実施に関する以前のセクションをも参照されたい）。

独立に及び／又は任意選択として、前述のさまざまな方法、例えば「経過時間インターバル」法に加えて、既存の又は先に説明したＴＣＰ／モニタソフトウェア／ＴＣＰプロキシ／ＩＰフォワーダ／ファイヤウォール．．．などを、変更し／さらに変更して、ＴＣＰ接続の両方の変更された端のそれぞれが、他方の変更された端への「同期化」データパケットを自動的に生成する（又は、単にＴＣＰ接続の一方の変更された端が、他方の未変更の又は変更された端への「同期化」データパケットを自動的に生成する）ことを保証することができ、例えば、同一サブフローの単一パケットが他端のＴＣＰに向けて送信されずに「同期化」インターバルが満了する時に必ず、「同期化する」パケットを生成し、他端のＴＣＰに送信することによって、必要な場合に少なくともすべての「同期化する」インターバル期間に他端の変更されたＴＣＰに向けて送信される１つのパケットが必ずあることが保証される（例えば、「経過時間インターバル」選択された値の半分、又は、単一のパケットが伝送媒体に完全に出るためのパケットのトラバースした経路の最低帯域幅リンクの送信時間遅延＊被乗数のうちの大きい方：ここでの「経過時間インターバル」値が、必ず上記の「同期化」値より大きくなければならないことに留意されたい）。したがって、両端が、変更され、それぞれが、他方の変更された端に「同期化」パケットを送信する場合に、両方の変更された端のＴＣＰの各端は、サブフローの「経過時間インターバル」が満了し、且つ、同一サブフローからのどのタイプのパケットも（サブフローの生成された「同期化」パケットタイプを含む）他端のＴＣＰから受信されていない時に、他端からローカル端ＴＣＰへの一方向経路が、輻輳イベント及び／又はパケットドロップイベント及び／又は物理送信エラーイベント及び／又は非常に希な非常に突然の輻輳レベル増加イベント（しかし、ここでは希な２００ｍｓＤｅｌａｙｅｄＡＣＫイベントを含まない：さらに、両端のうちの一方だけが、変更され、他方の未変更の端のＴＣＰに例えば他方の未変更の端のＴＣＰから戻る戻り応答ＡＣＫを誘発する通常ウィンドウの外のＤＵＰＳｅｑｕｅｎｃｅＮｕｍｂｅｒパケットの形で「同期化パケット」を送信する場合に、ローカルの変更された端のＴＣＰは、ローカルの変更された端のＴＣＰと他方の未変更の端のＴＣＰとの間の転送する経路又は戻る経路のいずれかが（どちらであるかは確かには知らない）、輻輳イベント及び／又はパケットドロップイベント及び／又は物理送信エラーイベント及び／又は非常に希な非常に突然の輻輳レベル増加イベント（しかし、ここでは希な２００ｍｓＤｅｌａｙｅｄＡＣＫイベントを含まない）に出会っていることを即座に知り／推論し／検出することだけができるはずである）に出会っていることを即座に知り／推論し／検出するはずである。一端から他端へ及び／又は他端からこの端への一方向経路がこの時に確かに「ＵＰ」又は確かに「ＤＯＷＮ」であることのこの追加の確かな検出／確かな推論は、それ相応によりよく反応するのに有用であるはずである。これは、戻り一方向経路がたまたま「ＤＯＷＮ」である場合に、進む一方向経路が「ＵＰ」又は「ＤＯＷＮ」であるかどうかを知るすべが全くないことに留意すれば、実用的に有用に利用されてもされなくてもよい。また、失われた／捨てられたが、例えば他のより後の順序はずれの物理的に到着するパケットが「経過時間インターバル」内に到着することに起因して、パケット到着間（物理的に到着するパケットの）遅延「経過時間期間」を満了させなかった、すべての欠けている「ギャップ」パケットは、通常は、通常の３つのＤＵＰＡＣＫ高速再送信機構を介して世話されるはずであり：代替案で、パケット到着間遅延「経過時間インターバル」機構が、その代わりに、隣接した順序通りの先行送信パケット（パケットのシーケンス番号による順序付けによるなど．．．）の到着時刻から「経過時間インターバル」以内に受信されない場合に、すべての欠けている「ギャップ」パケットが「経過タイムアウト」満了をトリガしなければならないと主張することができる．．．などであることに留意されたい。

サブフローのパケット到着間遅延「経過時間インターバル」が満了し、同一サブフローからのすべてのタイプのパケット（しかし、そのサブフローの生成された「同期化」パケットタイプ又は適用可能な場合にそのサブフローの対応する戻り応答ＡＣＫを除く）が発生していない時に、ローカル端の変更されたＴＣＰは、この本体の説明の以前の方法／サブコンポーネント方法で説明した、ＣＤＮＷ減少／レート減少と同時の既存の結合された実際のパケット再送信、及び／又は実際のパケット再送信が付随しない変更された分離されたＣＷＮＤ減少／レート減少だけ、及び／又は付随するＣＷＮＤ減少／レート減少を伴う又は伴わないさまざまな変更された「ポーズ」法．．．などを、即座にトリガし、ローカル端の変更されたＴＣＰにこれらを行わせる（及び／又は任意選択として他端のＴＣＰにこれらを「リモートに」行わせる）か、あるいは、同一サブフローからのすべてのタイプの最後の／最新のパケット（しかし、そのサブフローの生成された「同期化」パケットタイプ又は適用可能な場合にそのサブフローの対応する戻り応答ＡＣＫを除く）が他端の変更されたＴＣＰから受信され（及び、同一サブフローからのすべてのタイプの後続の新しい介在する到着するパケット（しかし、そのサブフローの生成された「同期化」パケットタイプ又は適用可能な場合にそのサブフローの対応する戻り応答ＡＣＫを除く）が他端の変更されたＴＣＰからこの例えば２５０ｍｓ時間中に受信されることなく）．．．など且つ／又は同一サブフローのパケットの現在の有効ウィンドウ分全体が送信済みであり、まだパケットのどれもが肯定応答し返されていない時以降のさらなるある期間、例えば２５０ｍｓ（ユーザ入力値又はＲＴＴｅｓｔ、ＯＴＴｅｓｔ、ＲＴＴｅｓｔ（ｍｉｎ）、ＯＴＴｅｓｔ（ｍａｘ）．．．などの要因を含むアルゴリズムに基づくある導出された値）が過ぎた後に限ってそれを行うか、のいずれかを行うことができる。

両端が、「パケット到着間」法及び「同期化」パケット法を実施する場合に、他方の変更された端のＴＣＰに送信される「同期化」パケットは、例えば、他の受信する変更された端のＴＣＰが戻る応答ＡＣＫを生成することを誘発することを必要とせずに、例えばソースＩＰアドレスポート番号及び／又はデスティネーションＩＰアドレスポート番号を含む、データフィールド部分又は挿入される「パディング」フィールド部分内の特殊な固定長一意識別．．．など、「同期化」パケットとしてそのようなパケットを一意に識別する適切な識別と一緒に、特定のフローごとのＴＣＰ接続と同一のソースＩＰアドレスポート番号と、同一のデスティネーションＩＰアドレス及びポート番号とを有する生成されたパケットの形とすることができる。端の一方だけが変更され、他端が未変更である場合に（しかし、両端が変更される場合であっても適用可能である）、変更された端によって他方の未変更の端に向けて送信される時の「同期化」パケットは、例えば、受信する未変更の端からの戻り応答ＡＣＫを誘発しないウィンドウ内でない複製されたＳｅｑｕｅｎｃｅＮｕｍｂｅｒフィールドと一緒に、特定のフローごとのＴＣＰ接続と同一のソースＩＰアドレスポート番号と、同一のデスティネーションＩＰアドレス及びポート番号とを有する生成されたパケットなど、受信する未変更の端からの戻り応答ＡＣＫを誘発するパケットの形である必要がある（例えば、受信するＴＣＰが必ず「何もしない」戻りＡＣＫを生成するウィンドウ内でない順序はずれＳｅｑＮｏパケットの送信など。インターネットニュースグループトピック「ＡｃｋｉｎｇｏｕｔｏｆＯｒｄｅｒｐａｃｋｅｔ」ｈｔｔｐ：／／ｇｒｏｕｐｓ−ｂｅｔａ．ｇｏｏｇｌｅ．ｃｏｍ／ｇｒｏｕｐ／ｃｏｍｐ．ｐｒｏｔｏｃｏｌｓ．ｔｃｐ−ｉｐ１ＰｈｉｌＫａｒｎ１９８８年３月２日、２ＣＥＲＦ１９８８年３月２日．．．．．、及びＧｏｏｇｌｅＳｅａｒｃｈ用語「ＡＣＫｉｎｇｔｈｅＡＣＫ」を参照されたい。単一のＤＵＰＡＣＫの送信が高速再送信を引き起こさないことにも留意されたい。あるいは、その代わりに、例えば順序はずれＡＣＫの送信など。ＧｏｏｇｌｅＳｅａｒｃｈ用語「ｏｕｔｏｆｏｒｄｅｒＡＣＫ」、「ｅｌｉｃｉｔｉｎｇａｎＡＣＫ」、「ＤＵＰＳｅｑｕｅｎｃｅＮｕｍｂｅｒＡＣＫ」、「ＡＣＫｆｏｒｕｎｓｅｎｔｄａｔａ」、「ｕｎｅｘｐｅｃｔｅｄＡＣＫ」．．．．などを参照されたい）。他方の未変更の端からの誘発された返される応答ＡＣＫは、単純に、そのＡＣＫフィールド値を、変更された端から他方の未変更の端によって受信される次の期待されるＳｅｑ番号になるようにセットされるはずであり、この戻り応答ＡＣＫの受信時に、変更された端は、この、次の期待されるシーケンス番号のデータセグメントがまだ送信されていないので、この返された応答ＡＣＫを単に破棄し、無視するはずである。この、次に期待されるシーケンス番号のデータセグメントが、返される応答ＡＣＫが受信される前のまさにその瞬間に実際に送信された、非常に希な「滅多にない」シナリオでは、変更された端は、今や、すべてがまさに同一のＡＣＫ番号を有する３つの戻り応答ＤＵＰＡＣＫを受信した時及びその後に「不必要に」高速再送信するだけであり、これは、やはり、非常に非常に可能性が低い。というのは、最初の返される応答ＡＣＫ及び／又は後続の続く送信されたデータセグメントを受信する前のまさにその瞬間に実際に送信されるデータセグメントは、今や、他方の未変更の端の次の期待されるシーケンス番号を増分し、次の戻り応答ＡＣＫが今や異なるより大きい増分されたＡＣＫＮｕｍｂｅｒフィールド値を担持するようにするはずであるからである。

上記の直前の段落は、主に、両端のＴＣＰが他端のＴＣＰへの「同期化する」パケットの送信を実施する場合のシナリオを説明した。これは、各端のＴＣＰが、他端のＴＣＰから同一サブフローのいかなるパケット（同一サブフローに関する生成された「同期化」パケットを含む）も受信せずに「経過時間インターバル」が満了する時に、必ず、他端のＴＣＰからローカル端のＴＣＰへの一方向経路が輻輳し及び／又はパケットドロップ及び／又は物理送信エラー及び／又は非常に希な非常に突然の輻輳レベル増加である（しかし、この場合には「同期化する」パケット機構が実施されているので、２００ｍｓＤｅｌａｙｅｄＡＣＫ機構は現在は原因ではない）ことを確かに確かめ／確かに推論できることを可能にする。より完全な組合せシナリオは、下記を含む（両端の変更されＴＣＰが、さらに、「同期化する」パケット法を含むと仮定する）。

１．「経過時間インターバル」が、他端の変更されたＴＣＰから同一サブフローのいかなるパケット（そのサブフローの生成された「同期化」パケットタイプの両方を含む）をも受信せずにローカル端の変更されたＴＣＰで満了する時 → 他端の変更されたＴＣＰからローカル端の変更されたＴＣＰへの一方向経路が「ＤＯＷＮ」であると確かに知る／確かに推論する → ローカル端の変更されたＴＣＰは、今、即座にそれ相応に反応し、且つ／又は他端の変更されたＴＣＰにそれ相応に反応させなければならない。

２．他端の変更されたＴＣＰからローカル端の変更されたＴＣＰへの一方向経路が「ＵＰ」である、すなわち、連続するパケット（及び／又は「同期化する」パケット）が、「経過時間インターバル」を満了させずに他端の変更されたＴＣＰから受信される時、且つ、期待される肯定応答（ローカル端の変更されたＴＣＰによって送信されたデータパケットに関する）が、ある判断基準（分離されたレート減分タイムアウト、結合されたＲＴＯパケット再送信タイムアウト、「ポーズ」を引き起こす分離されたＡＣＫｔｉｍｅｏｕｔ．．．など）以内に他端の変更されたＴＣＰから戻って受信されない場合に、ローカル端の変更されたＴＣＰは、今や、ローカル端の変更されたＴＣＰから他端の変更されたＴＣＰへの一方向経路が「ＤＯＷＮ」であることの確かな知識／確かな推論と共に、即座にそれ相応に反応し、且つ／又は他端の変更されたＴＣＰにそれ相応に反応させなければならない。

ＴＣＰ接続の一端だけが「同期」パケット法を実施する場合に、この状況で、その端の、「同期」パケット法を実施する変更されたＴＣＰに、伝統的に他端の未変更のＴＣＰからの肯定応答応答を誘発する「パケット」の形で他端の未変更のＴＣＰに「同期」パケットを送出させることによって、前述を適合させることができる（例えば、受信するＴＣＰが必ず「何もしない」戻りＡＣＫを生成するウィンドウ内でない順序はずれＳｅｑＮｏパケットの送信など。インターネットニュースグループトピック「ＡｃｋｉｎｇｏｕｔｏｆＯｒｄｅｒｐａｃｋｅｔ」ｈｔｔｐ：／／ｇｒｏｕｐｓ−ｂｅｔａ．ｇｏｏｇｌｅ．ｃｏｍ／ｇｒｏｕｐ／ｃｏｍｐ．ｐｒｏｔｏｃｏｌｓ．ｔｃｐ−ｉｐ１ＰｈｉｌＫａｒｎ１９８８年３月２日、２ＣＥＲＦ１９８８年３月２日．．．．．、及びＧｏｏｇｌｅＳｅａｒｃｈ用語「ＡＣＫｉｎｇｔｈｅＡＣＫ」を参照されたい。単一のＤＵＰＡＣＫの送信が高速再送信を引き起こさないことにも留意されたい。あるいは、その代わりに、例えば順序はずれＡＣＫの送信など。ＧｏｏｇｌｅＳｅａｒｃｈ用語「ｏｕｔｏｆｏｒｄｅｒＡＣＫ」、「ｅｌｉｃｉｔｉｎｇａｎＡＣＫ」、「ＤＵＰＳｅｑｕｅｎｃｅＮｕｍｂｅｒＡＣＫ」、「ＡＣＫｆｏｒｕｎｓｅｎｔｄａｔａ」、「ｕｎｅｘｐｅｃｔｅｄＡＣＫ」．．．．などを参照されたい）。

「同期化」パケット法は、「経過時間インターバル」値より短いインターバル（例えば「経過時間インターバル」値の半分．．．など）でローカル端の変更されたＴＣＰから他端のＴＣＰ（変更されていようといまいと）に送信される「パケット」が少なくともあることを保証しなければならない。両端が「同期化」パケット法を実施する場合に、両方の変更されたＴＣＰプロトコルは、例えばＴＣＰ接続フェーズ中又はその直後．．．などの、互いの存在の検出、「同期化」インターバルパラメータの合意．．．などを好ましく可能にすることができる。しかし、この場合に、「経過時間インターバル」満了以内に他端の未変更のＴＣＰからパケットを全く受信しない時に、ローカル端の変更されたＴＣＰは、一方向経路のいずれか（しかし、ローカル端の変更されたＴＣＰから他端の未変更のＴＣＰへ又は他端の未変更のＴＣＰからローカル端の変更されたＴＣＰへのどちらが「ＤＯＷＮ」であるかは確かでない（両端が変更され、「同期化」パケット技法を実施する時と比較されたい）を確かに推論することだけができる。

先の本説明で示したさまざまな方法／サブコンポーネント方法を、例えばＡＣＫＴｉｍｅｏｕｔ時の分離されたレート減分ではなく、「経過時間インターバル」法及び／又は「同期化」パケット法の使用に適合させることができる（すなわち、それ相応に反応するために例えば非輻輳ＲＴＴ＊被乗数以内に受信されない送信されたＳｅｑＮｏセグメントの肯定応答の監視ではなく、受信されるすべての次のパケットの「経過時間インターバル」がその代わりに監視される）。これは、おそらくはるかにより長い非輻輳ＲＴＴ＊被乗数よりはるかに高速の反応時間（「経過時間インターバル」）を可能にする。

タイムスタンプオプションが選択される場合に、これは、一方向経路遅延の両方の待ち時間（すなわち、ＲＴＴｅｓｔ及びＲＴＴｅｓｔ（ｍｉｎ）．．．などだけではなくＯＴＴｅｓｔ及びＯＴＴｅｓｔ（ｍｉｎ）．．．などが導出される）が、それ相応によりよく反応することを可能にするはずである。ＳＡＣＫオプションは、既に順序はずれで受信されているパケットの、より少ない不必要な再送信を可能にするはずである。「同期化」パケット及び／又はより以前の周期的プローブパケット法を、必要な場合に、デスティネーションＩＰアドレス及びポートと、未変更であるがソースポートに今は異なる未使用のポート番号が割り当てられたソースＩＰアドレスとを有するＴＣＰごとのフロー（１つ又は複数）の間で確立される新しいＴＣＰ接続の形で独立に送信することができる。

注：フローごとのＴＣＰのそれぞれの中の「パケット到着間」（及び／又は任意選択で）「同期」パケット法を、例えば初期Ｓｙｎｃ／ＳｙｎｃＡＣＫの後でのみ、及び／又は少数ｎの連続するパケットが他端のＴＣＰ（変更されていようといまいと）から受信された後でのみ、及び／又は各他の直前の以前のパケットから「経過時間インターバル」以内にすべてが到着する、少数ｍの連続するパケットが他端のＴＣＰから受信された後でのみなど、ある判断基準／イベントが満足される時に、フローごとのＴＣＰ内で安定するために動作するようにすることができる。「同期化」インターバルが満了し、「同期化」パケットの送信が必要である時に、ローカル端の変更されたＴＣＰは、純「同期化」パケットの代わりに、まだ肯定応答されていない、以前に送信された通常のデータパケット（１つ又は複数）を他端のＴＣＰにその代わりに再送／再送信することができる（これは、他端のＴＣＰから返される肯定応答応答をも誘発するはずである）。

本明細書の１つ又は複数の方法が、ソースセンダ又はレシーバのいずれか１つ（あるいは両方）が外部インターネットに存在する場合にも適用可能になるように我々の変更／発明を拡張するが、この説明本体のさまざまな以前に説明した方法と同様に、両方がインターネットサブセット／ＷＡＮ／ＬＡＮ／プロプラエタリインターネット内に存在する場合にも適用できることに留意されたい。

ユーザインターフェースを、本説明のさまざまな先に記述した変更されたＴＣＰ／変更されたモニタソフトウェア／変更されたＴＣＰフォワーダ／変更されたＩＰフォワーダ／変更されたファイヤウォール内に設けて、さまざまなＴＣＰチューニング／レジストリパラメータ（例えば、初期ｓｓｔｈｒｅｓｈ、初期ＲＴＴ、ＭＴＵ、ＭＳＳ、ＤｅｌａｙＡＣＫオプション、ＳＡＣＫオプション、Ｔｉｍｅｓｔａｍｐオプション．．．など）のユーザ入力、プロプラエタリＬＡＮ／ＷＡＮサブネットＩＰアドレス（これらのサブネット内にソースとデスティネーションとの両方を有するパケットトラフィックを、外部インターネットへ／からと比較して「内部トラフィック」として確かめることができるようにするために）とこれらのサブネットアドレスのそれぞれ及びすべての間のＡＣＫＴｉｍｅｏｕｔ及び／又は「経過時間インターバル」及び／又は「ポーズ−インターバル」及び／又は「同期化」インターバルとのユーザ入力（よりよい性能のために、例えばサブネット全体の中で最も離れたノードの対の間の最大非輻輳ＲＴＴ＊被乗数と等しいものなどの例えば最大ＡＣＫｔｉｍｅｏｕｔ値だけを使用するのではなく）、共通ＴＣＰポート（そのような共通ポートへ／からのパケットトラフィックを異なって処理できるように）及び／又は追加の使用されるＴＣＰポート及び／又はそのような特殊処理から除外されるソースポート又はデスティネーションポートのいずれか（例えば、一部のマルチメディアストリームは、ＵＤＰではなく指定されたポート番号を有するＴＣＰを使用する）のユーザ入力．．．などを可能にすることができる。

ここに、この本説明で記述する方法／サブコンポーネント方法及び／又はパケット到着間法及び／又は「同期化」パケット法の組合せのさまざまな多数の可能性の中の、いくつかのシナリオでの概略のみでのいくつかの例の事例がある（ＴＣＰ接続の一端だけが変更されている場合に、両端が変更されるならば、これは、明らかに、両端が互いの変更の存在を検出した後のタスクをはるかにより簡単にする）。

１．外部インターネットへのセンダソースとして働く、ローカル端の変更されたＴＣＰ。ＴＣＰスタックは直接に変更される。

「トリガ」イベント（例えば３００ｍｓの「経過時間インターバル」、３つのＤＵＰＡＣＫ、ＲＴＯの実際のパケット再送信タイムアウト．．．など）の際に、他の可能性の中でも、これは、ＴＣＰ自体が、定義されたポーズ−インターバルの間に「ポーズ」するだけ（又は、全くポーズすらせず）且つ／又はプローブとして働くためにポーズ中に少数のパケット送信を可能にすることと、その後、ＣＷＮＤ／レートリミットを変更せずに再開する（又はポーズなしで継続する）か、例えば５％、１０％、５０％．．．などのｘ％だけＣＷＮＤ／レートリミットを減らすかのいずれかを行うことと必要とするだけであるはずである。

ここでは、「ポーズすること」が、例えば３００ｍｓの「パケット到着間」満了時に実施される場合に、センダベースド変更は、例えば３００ｍｓの「パケット到着間」満了が、ローカル端センダが他端に送信すべきデータパケットを有しておらず、したがって不必要に「ポーズする」必要がなく、且つ／又は不必要にそれ相応に反応する必要がないという事実だけに起因したかどうかを知るという利益を有することに留意されたい（ローカル端がレシーバとして働く場合に、そのローカル端は、例えば３００ｍｓの「パケット到着間」満了が、「トリガ」イベントに起因するのか、単に他端のセンダが一時的に送信すべきさらなるデータパケットを有しないからのどちらであるかを知るすべがないことと比較されたい）。

パケット到着間法は、それ相応に反応するためのトリガイベントとして「非輻輳ＲＴＴ＊被乗数」法の代わりに使用することができ、さらに、「同期化」パケット法（ここでは、ローカル端の変更された送信するソースＴＣＰから生成されるだけであるが、例えば他端の未変更のＴＣＰからの戻るＡＣＫなどの応答を誘発する）及び／又はタイムスタンプオプションが組み込まれた場合に、どの方向のリンクが確かに「ＤＯＷＮ」又は確かに「ＵＰ」であるかの確かな検出／確かな推論を可能にするはずである。

２．外部インターネットへのセンダソースとして働くローカル端の変更されたＴＣＰ。ＴＣＰスタックを直接に変更することはできない。

本明細書の変更されたソフトウェアモニタ／変更されたＴＣＰプロキシ／変更されたファイヤウォール．．．などは、ＴＣＰスタック自体の代わりにこのタスクを実行する必要があるはずである。「トリガ」イベント（例えば、３００ｍｓの「経過時間インターバル」、３つのＤＵＰＡＣＫ、ＲＴＯの実際のパケット再送信タイムアウト．．．など）の際に、他の可能性の中でも、これは、本明細書の変更されたソフトウェアモニタ／変更されたＴＣＰプロキシ／変更されたファイヤウォール．．．などが、定義されたポーズ−インターバルの間に、インターセプトされたＴＣＰパケット転送を「ポーズ」するだけであり、且つ／又はプローブとして働くためにポーズ中に少数のパケット送信を可能にし、その後、再開する時に、例えばすべての到着するインターセプトされる発信ＴＣＰパケットに対して固定された個数のＡＣＫを「スプーフィング」し（例えば、「スロースタート」に再入する時に１セグメントサイズにリセットされた可能性があるＴＣＰのＣＷＮＤ／レートリミットをすばやく復元するために）、且つ／又は例えば変更されたソフトウェアモニタ／変更されたＴＣＰプロキシ／変更されたファイヤウォール．．．など（今や送信されたパケットのどれを再送信することも要求すらされないはずのＴＣＰ自体ではなく）の中で、すべての高速再送信３ＤＵＰＡＣＫＳ／ＲＴＯタイムアウトの実際のパケット再送信を、そのようなＤＵＰ純ＡＣＫをＴＣＰに転送しないこと及び／又はＴＣＰに転送する前にチェックサムを再計算しながらピギーバックされたＤＵＰＡＣＫパケット内のＡＣＫビットを除去することによってすべての高速再送信ＤＵＰＡＣＫパケットを抑止しながら送信されるデータのウィンドウ分の実際のコピーを保持することによって処理することすら行い、且つ／又はＴＣＰがＲＴＯタイムアウト．．．など）を有する直前にＴＣＰへのＡＣＫを「スプーフィング」し．．．などを必要とするのみであるはずである。ここでは、「ポーズすること」が、例えば３００ｍｓの「パケット到着間」満了時に実施される場合に、センダベースド変更は、例えば３００ｍｓの「パケット到着間」満了が、ローカル端センダが他端に送信すべきデータパケットを有しておらず、したがって不必要に「ポーズする」必要がなく、且つ／又は不必要にそれ相応に反応する必要がないという事実だけに起因したかどうかを知るという利益を有することに留意されたい（ローカル端がレシーバとして働く場合に、そのローカル端は、例えば３００ｍｓの「パケット到着間」満了が、「トリガ」イベントに起因するのか、単に他端のセンダが一時的に送信すべきさらなるデータパケットを有しないからのどちらであるかを知るすべがないことと比較されたい）。

パケット到着間法は、それ相応に反応するためのトリガイベントとして「非輻輳ＲＴＴ＊被乗数」法の代わりに使用することができ、さらに、「同期化」パケット法（ここでは、ローカル端の変更されたソフトウェアから生成されるだけであるが、例えば他端の未変更のＴＣＰからの戻るＡＣＫなどの応答を誘発する）及び／又はタイムスタンプオプションが組み込まれた場合に、どの方向のリンクが確かに「ＤＯＷＮ」又は確かに「ＵＰ」であるかの確かな検出／確かな推論を可能にするはずである。

３．外部インターネットセンダソースからのレシーバとして働くローカル端の変更されたＴＣＰ。ＴＣＰスタックは直接に変更される。

パケット到着間法は、それ相応に反応するためのトリガイベントとして「非輻輳ＲＴＴ＊被乗数」法の代わりに使用することができ、さらに、「同期化」パケット法（ここでは、ローカル端の変更されたレシーバＴＣＰから生成されるだけであるが、例えば他端の未変更のＴＣＰからの戻るＡＣＫなどの応答を誘発する）及び／又はタイムスタンプオプションが組み込まれた場合に、どの方向のリンクが確かに「ＤＯＷＮ」又は確かに「ＵＰ」であるかの確かな検出／確かな推論を可能にするはずである。さらに、ＤｉｖｉｓｉｏｎａｌＡＣＫ／ＤＵＰＡＣＫ／ＯｐｔｉｍｉｓｔｉｃＡＣＫなどの技法を使用して、必要な時に必ず、他端の未変更の送信するソースＴＣＰのＣＷＮＤ／送信レートを増分することができ、ウィンドウサイズ更新パケット技法を使用して、他端の未変更の送信するソースＴＣＰに「ポーズ」させることができ．．．などである。

４．外部インターネットセンダソースからのレシーバとして働くローカル端の変更されたＴＣＰ。ＴＣＰスタックを直接に変更することはできない。

本明細書の変更されたソフトウェアモニタ／変更されたＴＣＰプロキシ／変更されたファイヤウォール．．．などは、ＴＣＰスタック自体の代わりにこのタスクを実行する必要があるはずである。「トリガ」イベント（例えば、特定のサブフローの３００ｍｓの「経過時間インターバル」など）の際に、他の可能性の中でも、これは、本明細書の変更されたソフトウェアモニタ／変更されたＴＣＰプロキシ／変更されたファイヤウォール．．．などが、定義されたポーズ−インターバルの間に、他端のセンダＴＣＰにその特定のサブフローのパケット転送をリモートから「ポーズ」させるだけであり、且つ／又はプローブとして働くためにポーズ中に少数のパケット送信を可能にし、その後、再開する時に、例えば、固定された個数のＤＵＰＡＣＫを他端のセンダＴＣＰにすばやく送信させる（例えば、「スロースタート」に再入する時に１セグメントサイズにリセットされた可能性がある他端のＴＣＰのＣＷＮＤ／レートリミットをすばやく復元するために）だけである。パケット到着間法は、それ相応に反応するためのトリガイベントとして「非輻輳ＲＴＴ＊被乗数」法の代わりに使用することができ、さらに、「同期化」パケット法（ここでは、ローカル端の変更されたレシーバＴＣＰから生成されるだけであるが、例えば他端の未変更のＴＣＰからの戻るＡＣＫなどの応答を誘発する）及び／又はタイムスタンプオプションが組み込まれた場合に、どの方向のリンクが確かに「ＤＯＷＮ」又は確かに「ＵＰ」であるかの確かな検出／確かな推論を可能にするはずである。ＤｉｖｉｓｉｏｎａｌＡＣＫ／ＤＵＰＡＣＫ／ＯｐｔｉｍｉｓｔｉｃＡＣＫなどのさらなる技法を使用して、必要な時に必ず、他端の未変更の送信するソースＴＣＰのＣＷＮＤ／送信レートを増分することができ、ウィンドウサイズ更新パケット技法を使用して、他端の未変更の送信するソースＴＣＰに「ポーズ」させることができ．．．などである。

ＴＣＰ接続は、対称である、すなわち、ローカル端は、同時にデータの送信と受信との両方を行っていることができる（実際のデータを全く送信していない場合であっても、必ず、他端に向かって生成される戻るＡＣＫがある）ので、ローカル端の変更されたＴＣＰ／変更されたモニタソフトウェア／変更されたＴＣＰプロキシ／変更されたファイヤウォール．．．などは、もちろん、同時にセンダベースドとレシーバベースドとの両方として働くことができる。さらに、両端のすべてが変更される場合に、各端は、やはり、同時にセンダベースドとレシーバベースドとの両方として働き、一緒に働くことができる：しかし、好ましくは及び／又はその代わりに、両端が互いの変更の存在を検出したならば、これらの端は、それぞれがセンダベースドのみとしてのみ働くことのみによって働くか、それぞれレシーバベースドとしてのみ働くか、一端だけがレシーバベースドとセンダベースドとの両方として働き、他端の変更された動作がディスエーブルされることに合意することができる。互いの変更された存在を検出する多数の可能な形の１例が、例えば、「パディングフィールド」又は固定長データ部分内の特殊な一意の固定長識別パターンを有するパケットを他端に送信することである。

本説明で開示されるさまざまな方法及び／又はサブコンポーネント方法の組合せから導出可能な方法例
（さまざまな一方向トリップ時間ＯＴＴ、ＯＴＴｅｓｔ及び推定された非輻輳ＯＴＴｅｓｔ（ｍｉｎ）．．．などの測定及び／又は推定を可能にすることは、ＴＣＰ接続確立ＳＹＮＣ／ＳＹＮＣＡＣＫフェーズ中にタイムスタンプオプションをネゴシエートすることを必要とするはずである。特定の送信されたセグメント／パケットに関する送信するソースからレシーバへの一方向トリップ時間ＯＴＴは、センダによって、戻る対応するＡＣＫのさまざまなタイムスタンプフィールド値から導出することができる。明らかに、ＯＴＴ値、ＯＴＴｅｓｔ値、ＯＴＴｅｓｔ（ｍｉｎ）値は、送信するソース又はレシーバのいずれかから使用可能にされる時に、よりよくより効率的な伝送制御を可能にするはずである。というのは、ＲＴＴ、ＲＴＴｅｓｔ、ＲＴＴｅｓｔ（ｍｉｎ）が、前進経路及び戻り経路の非対称性によって導入される不確定性要素を固有に含むからである）。

（Ａ）ＬＡＮ／ＷＡＮ／プロプラエタリインターネットなどのプロプラエタリネットワークでの、パケットがバッファリングされ始めること及び／又はパケットロスの始まりを検出するための最新の非輻輳ＲＴＴｅｓｔ（ｍｉｎ）及び／又は最新の非輻輳ＯＴＴｅｓｔ（ｍｉｎ）．．．などのセンダベースド監視。

プロプラエタリネットワークでは、ギャランティードサービス機能をイネーブルするのに必要なものは、そのプロプラエタリネットワーク内の各すべてのＰＣ／サーバ．．．など（又は単に実質的な個数の高トラフィックソース）に、先に記述した変更ＴＣＰアップグレード又はモニタソフトウェアのいずれかをインストールさせること（又は、それらのＰＣ／サーバ．．．などに存在するアプリケーションソフトウェアが、そのアプリケーション内で直接に、例えばＲＴＳＰストリーミングアプリケーション内で直接に、これらの変更を実施すること）．．．などである。

各すべてのサブネット間の非輻輳ＲＴＴ値又は非輻輳ＯＴＴ値がプロプラエタリネットワーク内で前もって既知である（非輻輳ＲＴＴ値又は非輻輳ＯＴＴ値が、異なるサイズのデータパケットについて、特に媒体リンクがＩＳＤＮなどの低帯域幅リンクである場合に変化する可能性があり、ほとんどのＴＣＰパケットサイズが、ＴＣＰ接続確立フェーズ中に事前ネゴシエートされ、一般にネゴシエートされる最大セグメントサイズＭＳＳ値が約８００バイト、１５００バイト．．．などであることに留意されたい）場合に、本明細書の変更されたＴＣＰアップグレード又はモニタソフトウェア．．．などのそれぞれは、例えば特定のソース−デスティネーションフローの非輻輳ＲＴＴ又は非輻輳ＯＴＴ時間期間＋指定された時間期間Ｂが、特定の送信されたパケット（１つ又は複数）の対応するＡＣＫを戻って受信せずに経過した時に、個々のＴＣＰごとのフローの送信レートを単純にスロットルバックすることができる（「ポーズ」期間を介して又はＣＷＮＤウィンドウサイズパーセンテージ減分を介して．．．など）。ここでの時間期間Ｂは、トラバースされる経路に沿ったさまざまなノードでバッファリングされる間に累積的に導入され、パケットによって経験される総パケットバッファ遅延に対応する：この値に例えば２０ｍｓの短い期間をセットすることは、他のリアルタイムクリティカルＶｏＩＰ／ビデオ会議ＵＤＰパケットの享受する非常によいギャランティードサービスレベルを保証するはずである。というのは、この場合のＵＤＰパケットが、トラバースされるさまざまなノードに沿った２０ｍｓより非常にはるかに多い累積総バッファ遅延に出会う可能性が低いからである。この場合にＢ＝０をセットすることは、ＴＣＰフローが、パケットバッファリング遅延のすべての始まりを即座に回避することを必ず試みることを保証し、ネットワークを、バッファ遅延なし、又はたまたま発生する時にたまたまのインターバル中の非常に些細なバッファ遅延だけに保つ。ＴＣＰレートスロットル減分パーセンテージは、さまざまな固定された値をセットすることができ、あるいは、さまざまな動的な値になるようにアルゴリズム的に導出することができ、例えば、（Ｂｍｓ＋例えばＴｍｓ）／１０００ｍｓであり、Ｂ＝５０ｍｓ且つＴ＝５０ｍｓの場合に、ここでのレート減分パーセンテージは、１０％である、すなわち、ＴＣＰ送信レートは、今や、既存送信レートの９０％にスロットルバックされる → したがって、ボトルネックリンクをトラバースするフローが今さらにその後全くその送信レートを増分も減分もしないと仮定すると、そのボトルネックリンクのスループットレベルが、その後、今、そのボトルネックリンクの帯域幅容量の定常９０％付近で維持されることが、今わかる。ＴＣＰレートスロットル減分パーセンテージのアルゴリズムによって導出される値の他の可能な非網羅的な例は、単に、例えば、Ｂｍｓ／ＴＣＰごとのフローの非輻輳ＲＴＴ値とすることができ、Ｂ＝５０ｍｓ及び非輻輳ＲＴＴ＝４００ｍｓでは、ここでのレート減分パーセンテージは、１２．５％になるはずである。時間期間Ｔｍｓは、以前に加算されたものであり／ここで加算することもでき、その結果、より大きいレート減分パーセンテージを用いると、そのボトルネックリンクをトラバースするフロー（ＴＣＰに関して通常そうであるように、その送信レートを増分する）は、今、１００％リンクスループットレベル以上にもう一度達するのにより長い時間を要して、その後、バッファリングを必要とするはずであり、このバッファリングは、その後、他のリアルタイムクリティカルギャランティードサービスＵＤＰパケットにわずかに影響するはずである。

変更されたＴＣＰアップグレード又はモニタソフトウェア．．．などは、要求された時に必ず、さまざまな指定された「トリガイベント（１つ又は複数）」（例えば、Ｂｍｓの累積総バッファリングされた遅延に出会った．．．など）の後に必要な所望のボトルネックリンクのスループットを達成するために（例えば、付随するパケットバッファリング遅延を伴う現在の１００％超の利用度レベルではなく、１００％、９９％、９５％、８５％．．．などのボトルネックリンク帯域幅利用度をその後に引き起こすために）、ＣＷＮＤパーセンテージ減分を介して及び／又はそのような形での「ポーズ」を介して．．．など、ＴＣＤＰごとのフロー（１つ又は複数）レートスロットルをもたらすことができる。さまざまなアルゴリズムとポリシとプロシージャとを、さらに考案して、すべての種類の「トリガイベント」をさまざまな異なる形で処理することができる。

ここで、変更されたＴＣＰアップグレード又はモニタソフトウェア．．．などが、プロプラエタリネットワーク内のさまざまなサブネットの間の、サブネット間の非輻輳ＲＴＴ及びサブネット間の非輻輳ＯＴＴの以前の知識を必ずしも必要としないことに留意されたい。そうではなく、ここでは、変更されたＴＣＰアップグレード又はモニタソフトウェア．．．などは、個々のＴＣＰごとのフローの現在の最新の観察された最小のＲＴＴ値又は現在の最新の観察された最小のＯＴＴ値を記憶し、これを個々のＴＣＰごとのフローの非輻輳ＲＴＴ又は非輻輳ＯＴＴと動的に同等として扱うことができる。これらのＲＴＴｅｓｔ（ｍｉｎ）又はＯＴＴｅｓｔ（ｍｉｎ）の常識的な上限及び下限：例えば、これらの最大上側シーリング限度に、プロプラエタリネットワーク内の既知の最も離れた位置の対のＲＴＴｍａｘ値をセットすることができる．．．などである。

（Ａ１）ＬＡＮ／ＷＡＮ／プロプラエタリインターネットなどのプロプラエタリネットワークでの、パケットがバッファリングされ始めること及び／又はパケットロスの始まりを検出するための最新の非輻輳ＲＴＴｅｓｔ（ｍｉｎ）及び／又は最新の非輻輳ＯＴＴｅｓｔ（ｍｉｎ）．．．などのレシーバベースド監視
（これは、リモートＡＣＫＤｉｖｉｓｉｏｎ／複数のＤＵＰＡＣＫ／ＯｐｔｉｍｉｓｔｉｃＡＣＫと、「ポーズ（１つ又は複数）」を引き起こすためのさまざまなサイズのウィンドウサイズ更新と、複製パケット法を介する「何もしない」ＡＣＫ応答の誘発、ＲＴＯ再送信をプリエンプトするための高速再送信をトリガするための３つのＤＵＰＡＣＫと、．．．などを使用する、前のレシーバベースドの方法／サブコンポーネント方法と、このセクション及びこの説明本体のさまざまな部分で説明されるさまざまな方法／サブコンポーネント方法とから十分に明白である）。

（Ｂ）ＬＡＮ／ＷＡＮ／プロプラエタリインターネットなどのプロプラエタリネットワーク及び／又は外部ネットワークでの、パケットがバッファリングされ始めること及び／又はパケットロスの始まりを検出するための最新の非輻輳ＲＴＴｅｓｔ（ｍｉｎ）及び／又は最新の非輻輳ＯＴＴｅｓｔ（ｍｉｎ）．．．などのセンダベースド監視
外部インターネットは、プロプラエタリネットワーク内のように、制御内ではない他の既存の未変更のＴＣＰフローを受ける。上記の（Ａ）の例（１つ又は複数）は、これを考慮に入れるためにさらに変更される必要があるはずである。

ＣＷＮＤパーセンテージ減分及び／又は「ポーズ（１つ又は複数）」．．．などを介するレートスロットル減分を引き起こすための「トリガイベント」は、ここで、例えば１００％／９９％／９５％／８５％．．．などへのフォールバックの後の指定された又は動的にアルゴリズム的に導出されるｓ秒の間に増分しないなど、さらに変更される必要があり、もう一度ボトルネックリンクのスループット利用度がその後に１００％以上に戻って達し、上記のｓ秒以内のパケットバッファリング遅延の始まりを引き起こす場合に、「トリガイベント（１つ又は複数）」（パケットドロップ／バッファリング遅延閾値超過．．．などとすることができる）まで、送信レートがもう一度増分／増加し始めることを可能にし、そうでない場合に、ｓ秒が経過した後に、送信レート増分／増加を可能にし始める。さまざまなアルゴリズムとポリシとプロシージャとを、さらに考案して、すべての種類の「トリガイベント」をさまざまな異なる形で処理することができる。

ここで、非輻輳ＲＴＴ及び／又は非輻輳ＯＴＴが、新たに確立されるＴＣＰごとのフローについて前もってたやすくはわからない外部インターネット上では、この故に、現在の最新の観察されたＲＴＴｅｓｔ（ｍｉｎ）又はＯＴＴｅｓｔ（ｍｉｎ）が、その代わりに、非輻輳ＲＴＴ及び／又はＯＴＴ値と同等の動的推定値を提供するはずである。

既存の標準ＴＣＰは、競合するＴＣＰフローの公平なシェア及びフレンドリネスを強調するが、単に単一のパケットドロップＲＴＯタイムアウトの後又は特に高帯域幅及び長ＲＴＴ待ち時間を有する長距離ファットパイプ上での３ＤＵＰＡＣＫ高速再送信の後に、以前に確立された送信レート／スループットを再達成するのに必要な非常に長い期間（主に、スロースタートの指数関数的ＣＷＮＤ増大中にＳｓｔｈｒｅｓｈＣＷＮＤサイズを達成した後の輻輳回避モードでの既存ＴＣＰの保守的な線形ＣＷＮＤ増分に起因する）で明示されているように、最大スループットのための使用可能帯域幅の十分な利用度において非効率的である。変更されたＴＣＰの新しい改善された判断基準は、今は、非効率的で遅い非常にフレンドリな公平な共有だけではなく、最大ＴＣＰスループットのための使用可能帯域幅及び／又は使用可能バッファの高い利用度を含まなければならない。さまざまな「トリガイベント」の際に「ポーズ」し且つ／又はＣＷＮＤを減らすための本明細書の変更されたＴＣＰの超高速反応時間（動的に導出されるＲＴＯ値の１秒という既存ＲＦＣのデフォルト最小下側シーリング値ではなく）は、パケットドロップパーセンテージを最小にするはずであり、前に説明した「連続ポーズ」は、さらに、送信レート減分サイズを非常に柔軟にすなわち例えばＲＴＴあたり６４Ｋバイトから例えば３００ｍｓあたり４０バイトのみに減らすはずである）。

本明細書の変更されたＴＣＰは、多数のさまざまな異なる形で、ＣＷＮＤ増分サイズ（及び／又は、例えばより小さい値にされる、同等の「ポーズ」インターバル、「連続ポーズ」インターバルセッティング）においてよりアグレッシブにすることができる。ＣＷＮＤを、例えば、既存ＲＦＣの受信されたＡＣＫあたり及び／又はＲＴＴあたり１ＭＳＳではなく受信されたＡＣＫあたり及び／又はＲＴＴあたり指定された整数倍数又は動的に導出される整数倍数のＭＳＳだけ増分することができ、Ｓｓｔｈｒｅｓｈ値を、指定された値に初期化することができ、及び／又はＴＣＰ接続フェーズ中にネゴシエートされる最大ウィンドウサイズと同一になるようになど、非常に大きい値に永久的に固定することができ．．．などである。「トリガイベント」（パケットドロップ（１つ又は複数）結合され／分離されたＲＴＯタイムアウト、３ＤＵＰＡＣＫ高速再送信、ＡＣＫが外部の厳しくセットされた指定されたインターバルの外で返される際の分離されたレート減分．．．など）の際にレート減分をもたらす間に、変更されたＴＣＰは、ボトルネックリンク（１つ又は複数）利用度が例えば１００％／９９％／９５％／８５％．．．などの高いスループットで又はさまざまな１００％を超える輻輳的バッファリング遅延レベルなどでさえ維持されることを保証するはずであるようにレートを減分しようとすることができる（経路をトラバースするすべてのＴＣＰが、すべて変更されたＴＣＰであると仮定して）。

さまざまな多数の可能性の中の１例として、本明細書の変更されたＴＣＰ（センダ又はレシーバのいずれかあるいは両方での）は、非輻輳ソース−レシーバ−ソースＲＴＴ値又は非輻輳ソース−レシーバＯＴＴ値、あるいは上記の動的最良推定ＲＴＴｅｓｔ（ｍｉｎ）／ＯＴＴｅｓｔ（ｍｉｎ）同等物の以前の知識を有するはずである：トラバースされるすべてのリンクのそれぞれが、そのめいめいの１００％使用可能帯域幅を超えない（すなわち、パケットバッファリングが、トラバースされるノードのどれにおいても発生しない）時に、例えば戻るＡＣＫから導出されるＲＴＴ値又はＯＴＴ値又はＲＴＴｅｓｔ（ｍｉｎ）値又はＯＴＴｅｓｔ（ｍｉｎ）値は、今や、現実の実際の非輻輳ＲＴＴ値又は非輻輳ＯＴＴ値と同一になる（以下でＶｍｓと称する、ノード処理遅延／ソース又はレシーバホスト処理遅延．．．などによって導入される非常に小さいランダム変動を伴う：この値Ｖｍｓ変動は、通常、指定された又は動的に導出されるＢｍｓ．．．などの他の以前に説明したシステムパラメータより小さい桁（ｍａｇｎｉｔｕｄｅｏｒｄｅｒ）になるはずである。Ｖｍｓが非常に希な機会に期待されない場合に短く非常に大きくなる例えばＷｉｎｄｏｗＯＳはリアルタイムＯＳではない．．．これは、その代わりに出会うノードバッファリング遅延によって生じる／導入される／引き起こされるのと同一の形で「例外的に」扱うことができる）。例えば戻るＡＣＫから導出されるＲＴＴ値又はＯＴＴ値又はＲＴＴｅｓｔ（ｍｉｎ）値又はＯＴＴｅｓｔ（ｍｉｎ）値が、トラバースされる経路（１つ又は複数）に沿って出会うバッファリング遅延がないことを示し続ける限り、変更されたＴＣＰは、既存ＲＦＣのように送信レートの増分／増大を保守的に許容し続けるか、よりアグレッシブな増分／増大を続けるかのいずれかを行うことができる。戻るＡＣＫから示される／導出されるバッファリング遅延のあるレベル（１つ又は複数）を超える時、すなわち［（戻るＲＴＴ又はＯＴＴ）−（ＲＴＴｅｓｔ（ｍｉｎ）又はＯＴＴｅｓｔ（ｍｉｎ））］というミリ秒単位の値は、今、トラバースされる経路（１つ又は複数）に沿ったさまざまなノードで出会う累積総バッファリング遅延（１つ又は複数）を示す（以下ではＣｍｓと称する）。例えば、Ｃの値の２０ｍｓ／５０ｍｓ／１００ｍｓ．．．などを超える時に、変更されたＴＣＰは、今、例えば、送信レートを減らすことができ、その結果、ボトルネック（１つ又は複数）のリンク利用度は、その後、それらのボトルネックリンク（１つ又は複数）をトラバースするすべてのＴＣＰが、すべて変更されたＴＣＰであると仮定して、例えば１００％／９９％／９５％／８５％．．．などに維持されるはずである（今、ＴＣＰごとのフローの実際の非輻輳ＲＴＴ又は非輻輳ＯＴＴの最新の推定同等値とＣの値とを知っているので、必要なＣＷＮＤ減分パーセンテージ及び／又は「ポーズ」インターバル又は適当な必要な「ポーズ」のシーケンスを、今、確かめて、必要な所望の最終結果を達成することができる）。変更されたＴＣＰは、今、例えば前に説明したように期間ｓ秒（指定される又は動的にアルゴリズム導出される）の間にＴＣＰフローのさらなるレート増分／増大のすべてを停止して、その後、例えば前に説明したように又はさらに考案されるさまざまな異なる形でそれ相応に応答することができる。この特定の例は、既存ＲＦＣのフレンドリ公平共有に加えて高い利用度スループットを達成するという効果を有し、また、トラバースされる経路（１つ又は複数）の累積バッファリング遅延をＣ値に相関する低いレベルに維持されるように保つのを助ける：他の強い支配的な未変更のＴＣＰフローがない場合に（その場合に、本明細書の変更されたＴＣＰフローは、ｓ秒以内にレート増分／増大を可能にし始めるはずである／始めることができる）、すべての他の未変更のＴＣＰフローと一緒に、最終的にパケットドロップイベントを引き起こす：その際に、未変更のＴＣＰフローは、「スロースタート」に再入し、前に達成された送信レートを再達成するのに非常に長い時間を要するはずであるが、変更されたＴＣＰフローは、前に達成された送信レート／スループットの任意に高い比率を保持することができる（長ＲＴＴ長距離ファットパイプに特に関連する既存の応答性問題を解決する）。例えばその後の９５％ボトルネックリンク（１つ又は複数）利用度を達成するための変更されたＴＣＰレート減分を用いて、新しいＴＣＰフロー（１つ又は複数）（及び／又は他の新しいＵＤＰフロー（１つ又は複数）．．．など）は、必ず、ルートに沿ったパケットバッファリング遅延（１つ又は複数）を導入せずにフローレート増分／増大を開始するために使用可能ボトルネックリンク（１つ又は複数）帯域幅の５％までを即座に利用できるはずであり、さらに、ボトルネックリンク（１つ又は複数）は、パケットを捨てずに使用可能帯域幅のＸミリ秒同等物の新しい追加の突然の瞬間的トラフィックサージに即座に対処できるはずであり（ほとんどのインターネットノードは、一般に、３００ｍｓ〜５００ｍｓの間と同等のバッファサイズを有する）：これは、既存フローの確立されたスループットを保存するという一般的な知恵と一貫すると同時に、漸進的な制御された新しい追加のフローの増大を可能にする。

代替案では、変更されたＴＣＰは、既存ＲＦＣの線形増大と同様に保守的に又はよりアグレッシブに（Ｃｍｓの累積総バッファリング遅延が検出された時にスロットルバックする．．．などではなく）レート増分／増大を必ず可能にし、「パケットドロップ」イベントの際にそれ相応にスロットルバックするだけとすることができる：これは、ＴＣＰフローのスループットの最大化の利益のためのみであり、他のリアルタイムクリティカルＵＤＰフローには良くないはずであるが、トラバースされるノードは、使用可能な物理帯域幅の保証された最小パーセンテージをＵＤＰパケット優先順位転送に単純に予約することによって、リアルタイムクリティカルＵＤＰパケットの非常によいギャランティードサービス性能を簡単に保証すること．．．などができる。

ウェブサイトサーバ／サーバファームは、上で説明された変更されたＴＣＰ実施態様を有利に実施することができる。通常のウェブサイトは、しばしば、スピーディなダウンロードのために約３０Ｋバイト〜６０Ｋバイトになるように最適化される（パケット（１つ又は複数）ドロップによって継続的に中断されずに約５Ｋバイト／秒でダウンロードするアナログ５６Ｋモデム．．．などについて、これは、それでも、約６秒〜１２秒を要する）。ＳＹＮＣ／ＳＹＮＣＡＣＫ／ＡＣＫＴＣＰ接続確立フェーズの直後に、送信するソースサーバの変更されたＴＣＰは、現在の最新の観察された最小ソース−レシーバ−ソースＲＴＴｅｓｔ（ｍｉｎ）又はソース−レシーバＯＴＴｅｓｔ（ｍｉｎ）値の形（それが実際の非輻輳ＲＴＴ又は非輻輳ＯＴＴ値を表すか否かに関わりなく）で、ＴＣＰごとのフロー（１つ又は複数）の非輻輳ＲＴＴ又は非輻輳ＯＴＴの初期のまさに最初の推定値を有するはずである。送信するソースサーバの変更されたＴＣＰは、任意選択として、今、Ｗ個のセグメントというＣＷＮＤウィンドウサイズから即座に開始してまさに最初のデータセグメント／パケットの送信を即座に開始することができ、例えば、約１６００バイトのネゴシエートされた最大セグメントサイズＭＳＳ及びＷ＝２０を用いると、６０Ｋバイトのコンテンツのすべてをクライアントウェブブラウザによって受信するのに、２＊ＲＴＴだけを要するはずである（送信でパケット（１つ又は複数）が捨てられず、壊されず、経路に沿った最小のリンクの帯域幅がエンドユーザのラストマイル５００Ｋビット／秒ブロードバンドであると仮定して）。Ｗ＝６４を用いると、クライアントウェブブラウザが６０Ｋバイトのウェブサイトコンテンツを完全にダウンロードするのに、１ＲＴＴ又は１ＯＴＴだけを要する可能性がある（通常のインターネットＲＴＴは、経路（１つ又は複数）に沿ったバッファリングによって導入される遅延（１つ又は複数）を含めて、一般に約数十ミリ秒から数百ミリ秒である）。経路に沿った最小のリンクの帯域幅が、エンドユーザのラストマイル５６Ｋビット／秒アナログモデムダイヤルアップである場合に、上記の時間期間は、ラストマイルリンクを介する伝送が最大約５Ｋバイト毎秒に過ぎない可能性があるので、少なくとも６秒又は１２秒であったはずである（３０Ｋバイト分又は６０Ｋバイト分のセグメント／パケットが、ダイヤルアップを介して前方にエンドユーザのウェブブラウザに送信される前に、まず、エンドユーザのラストマイルＩＳＰで、ＡＯＬウェブプロキシサーバでバッファリングされると仮定して）。まさにワーストケースで、最初の２０個又は６４個のＭＳＳＣＷＮＤウィンドウ分のセグメント／パケットが、即座にバッファオーバーフローを引き起こし、この故に、それらのセグメント／パケットが、ボトルネックリンク（１つ又は複数）で捨てられる場合であっても、本明細書の変更されたＴＣＰは、（既存のＲＦＣのレートの代わりに帯域幅利用度の延長期間を半減又は保証する）例えばあるレベルの後続ボトルネックリンク（１つ又は複数）利用度／スループットを保証するためのレート減分、及び／又はより制御されたアグレッシブな後続のレート増分／増大、及び／又はより制御されたバッファ遅延レベル輻輳回避（例えば、「パケット（１つ又は複数）ドロップを待つ」という現在の既存ＲＦＣの唯一の方式ではなく、レート増分／増大を可能にする前にｓ秒待つ．．．など）．．．など、前述の上で説明した／短く示した形でそれ相応に非常にすばやく反応することができる（１秒最小値という既存ＲＦＣの最小最低フロアデフォルト反応時間よりはるかに高速に）。

変更されたＴＣＰすなわちウェブサーバ用の変更されたＴＣＰが、モニタソフトウェア／プロキシＴＣＰ．．．などの形で（例えば、変更のためのホストＴＣＰスタックソースコードへの直接アクセスなしで）実施される必要がある場合に、これは、本質的に、単に、本説明のさまざまな先の方法／サブコンポーネント方法で説明したように、送信するソースサーバに常駐するモニタソフトウェア／ＴＣＰプロキシが、制御されてよりアグレッシブにＣＷＮＤウィンドウサイズ／送信レートを増分するために、常駐する送信するソースサーバのＴＣＰスタックに対して、要求された時に必ず「ＡＣＫをスプーフィングし」、且つ／又は一時的に送信を止めるか送信レートを減分するために、常駐する送信するソースサーバのＴＣＰスタックに対して、要求された時に必ず０又は小さいレシーバウィンドウサイズ更新パケットをスプーフィングし、及び／又はモニタソフトウェアが、インターセプトされたＴＣＰの発したパケットの前方への転送で、「ポーズ」／「連続ポーズ」を介して同等の送信レート減分をもたらし（及び／又は各ポーズインターバル中に１つ又は少数のパケット転送を可能にし）、且つ／又は常駐するホストのＴＣＰスタックによって送信されたフルウィンドウ分のすべての実際のデータセグメント／パケットを保存して、その後、すべての結合された又は分離されたＲＴＯ再送信／３ＤＵＰＡＣＫ高速再送信を実行し、常駐ホストＴＣＰスタックをすべてのそのような責任から解放し、且つ／又は常駐ホストＴＣＰスタックによって送信された複数のフルウィンドウ分のすべての実際のデータセグメント／パケットを保存し、したがって、モニタソフトウェアが制御されたよりアグレッシブなレート増分／増大をもたらすために常駐ホストＴＣＰスタックに対して「ＡＣＫをスプーフィング」する時及び／又はそれを行うためにＡＣＫＤｉｖｉｓｉｏｎ／複数ＤＵＰＡＣＫ／ＯｐｔｉｍｉｓｔｉｃＡＣＫ技術を利用する時に、複数ウィンドウ分のセグメント／パケットを単一ＲＴＴ以内に常駐ホストＴＣＰスタックによって生成できるようにし、且つ／又はネットワークからの着信して戻るＡＣＫパケットを検査し、及び／又は前方に常駐ホストＴＣＰスタックに転送するか破棄する前に、さまざまなフィールド（ＡＣＫＮｕｍｂｅｒ、ＳｅｑＮｕｍｂｅｒ、Ｔｉｍｅｓｔａｍｐ値、さまざまなフラグ、アドバタイズされたウィンドウサイズ．．．など）を変更するかどうかを含めてそれ相応に反応するためにそのＲＴＴ／ＯＴＴを検査し、且つ／又は．．．．．．．．などを必要とするはずであることに留意されたい。

ここでは、モニタソフトウェア／ＴＣＰプロキシ．．．などが、送信レートを「ポーズ」／連続「ポーズ」だけを介して制御されるままにしながら、且つ／又は「プローブ」として働くために１つの単一の又は少ない固定された個数のパケットを各ポーズインターバル中に転送することを可能にしながら、技法、方法、及びサブコンポーネント方法の上で述べた組合せを用いて、常駐ホストの有効送信ウィンドウ及び／又はＣＷＮＤを、ある必要なサイズに又は常時最大のネゴシエートされたウィンドウサイズにさえ永久的に固定して保つことさえできることに留意されたい。

（ＳＹＮＣ／ＳＹＮＣＡＣＫ／ＡＣＫＴＣＰ接続確立フェーズの直後に、送信するソースサーバの変更されたＴＣＰは、その代わりに、今や、既存ＲＦＣのスロースタートの１ＭＳＳセグメントサイズのＣＷＮＤウィンドウを用いて即座に開始してまさに最初のデータセグメント／パケットの送信を即座に開始することができるが、これは、エンドユーザの通常の一般的な毎日の経験でそうであるようにコンテンツ転送を完了するのに今は多数のＲＴＴ、数十秒から数分前後を要する可能性がある）。

（Ｂ１）ＬＡＮ／ＷＡＮ／プロプラエタリインターネットなどのプロプラエタリネットワーク及び／又は外部ネットワークでの、パケットがバッファリングされ始めること及び／又はパケットロスの始まりを検出するための最新の非輻輳ＲＴＴｅｓｔ（ｍｉｎ）及び／又は最新の非輻輳ＯＴＴｅｓｔ（ｍｉｎ）．．．などのレシーバベースド監視
（これは、リモートＡＣＫＤｉｖｉｓｉｏｎ／複数ＤＵＰＡＣＫ／ＯｐｔｉｍｉｓｔｉｃＡＣＫ及び／又は「ポーズ（１つ又は複数）」を引き起こすためのさまざまなサイズのウィンドウサイズ更新及び／又は複製パケット法を介する「何もしない」ＡＣＫ応答の誘発及び／又はＲＴＯ再送信をプリエンプトするための高速再送信をトリガするための３つのＤＵＰＡＣＫ及び．．．などを使用する、以前のレシーバベースドの方法／サブコンポーネント方法と、このセクション及びこの説明本体のさまざまな部分で説明されるさまざまな方法／サブコンポーネント方法から十分に明白である。外部インターネットを介して働くためのＴＣＰ変更の実施に関する前のセクションを参照されたい）。

１例として、ＴＣＰ接続確立フェーズ中にネゴシエートされるＴｉｍｅｓｔａｍｐオプションを用いて、レシーバの変更されたＴＣＰ又はモニタソフトウェアは、今や、到着するパケットの実際の非輻輳一方向トリップ時間と同等のソース−レシーバ経路の推定値すなわち現在の最新の観察されたＯＴＴｅｓｔ（ｍｉｎ）を導出することができる。任意の到着するパケットが出会う累積総バッファリング遅延は、存在する場合に、到着するパケットのＯＴＴからＯＴＴｅｓｔ（ｍｉｎ）を減算することによって導出することができる（ノードのパケット処理／転送時間動揺によって導入されるすべての通常は非常に小さいランダム変動を無視して）。ＳｅｌｅｃｔｉｖｅＡｃｋｎｏｗｌｅｄｇｅｍｅｎｔオプションを利用すること及びＤｅｌａｙｅｄＡｃｋｎｏｗｌｅｄｇｅｍｅｎｔオプションをディスエーブルすることが好ましい（例えば、ホストＰＣのＴＣＰ／ＩＰレジストリエントリセッティングによって、しかし、これらは、全く、厳密な要件ではない）。変更されたＴＣＰ又はモニタソフトウェアは、今、正しい位置にあり、今、輻輳していないソース−レシーバ経路の実際の非輻輳ＯＴＴ及びバッファリング遅延レベルと同等の推定値を用意していて、フレンドリな公平共有を保ちながら最大の帯域幅利用度／スループット判断基準を達成するために望まれる通りにそれ相応に反応するはずである（リモートから、送信するソースＴＣＰに、「ポーズ」させ、且つ／又はポーズインターバルごとに１つの単一のパケット転送を許容しながら「連続ポーズ」させ、且つ／又は「アンポーズ」させ、且つ／又はＤｉｖｉｓｉｏｎａｌＡＣＫ／複数ＤＵＰＡＣＫ／ＯｐｔｉｍｉｓｔｉｃＡＣＫを介してＣＷＮＤサイズを増分させ、且つ／又は早期３ＤＵＰＡＣＫ高速再送信を介してＲＴＯタイムアウトをプリエンプトさせ、且つ／又は．．．．．．など）。

直前の例は、Ｔｉｍｅｓｔａｍｐｓオプションの使用を全く必要としなくなるようにさらに単純化することができ（すなわち、到着するＯＴＴ値、ＯＴＴｅｓｔ（ｍｉｎ）値、及び導出された累積総出会うバッファリング遅延値を導出することも利用することも全く必要としない：レシーバの変更されたＴＣＰ又はモニタソフトウェアは、その代わりに、最新の最後の受信された直前のパケットの到着時刻以降に次のパケットが到着するのを指定されたＷミリ秒（例えば２５０ｍｓ）インターバルだけ非常に単純に待つことができ、これがＷミリ秒以内に到着しない場合には、フレンドリで公平な共有を保ちながら指定された最大帯域幅利用度／スループット判断基準を達成するために（しかし、直前の例よりアグレッシブに）望みに応じて、その後に、これを「トリガイベント」として扱って（次のパケットがバッファオーバーフロード輻輳ドロップされた可能性が最も高い）、続いて即座に（リモートから、送信するソースＴＣＰに「ポーズ」させ、且つ／又はポーズインターバルごとに１つの単一のパケット転送を許容して「連続ポーズ」させ、且つ／又は「アンポーズ」させ、且つ／又はＤｉｖｉｓｉｏｎａｌＡＣＫ／複数ＤＵＰＡＣＫ／ＯｐｔｉｍｉｓｔｉｃＡＣＫを介してＣＷＮＤサイズを増分させ、且つ／又は早期３ＤＵＰＡＣＫ高速再送信を介してＲＴＯタイムアウトをプリエンプトさせ、且つ／又は．．．．．．など）。ここでは、パケットが、３つの異なるノードＡ／Ｂ／Ｃのそれぞれで例えば３００ｍｓの３つのバッファリング遅延に出会い、その後、経路に沿って別のノードＤ（例えば４００ｍｓと同等のバッファ容量を有する）でバッファオーバーフロード輻輳ドロップされる場合に、且つ、送信するソースＴＣＰでの例えば２５０ｍｓの「ポーズ」は、今、ノードＤでのバッファ輻輳レベルをわずか１５０ｍｓに減らすだけではなく、同様に、ノードＡ／Ｂ／Ｃのそれぞれでのバッファ輻輳レベルをそれぞれわずか５０ｍｓに減らしもするはずである。４５０ｍｓの指定された又はアルゴリズム的に導出される「ポーズ」インターバル値は、確かに、ノードＡ／Ｂ／Ｃ／Ｄのそれぞれで完全にすべてのバッファリングを完全にクリアするはずであるのに対して（すなわち、すべてが、今、パケットが全くバッファリングされない状態で全然輻輳していない）。しかし、直前の例は、ＯＴＴとＯＴＴｅｓｔ（ｍｉｎ）と導出された累積的な出会うバッファリング輻輳遅延の知識を用意していて、上記の値の知識に依存してより微細なレベルの制御を伴ってそれ相応に反応することができ、これが、主にバッファオーバーフロードパケットドロップイベントの後に反応することだけができるさらに単純化された例を提示することと比較されたい（トラバースされるすべてのノードのすべてのバッファ（それぞれ４００ｍｓと同等のバッファ容量を仮定する）が、一貫して安定してますます、オーバーフロー済みに近いがまだオーバーフロー済みでなく変化する時であっても、直前に受信されたパケットに直接に続くパケットは、それでも、その直前のパケットから例えば５０ｍｓ／１００ｍｓ／２００ｍｓ／２５０ｍｓ．．．など以内に到着することに留意されたい）。

最後に受信されたパケット（任意の長さの）以降に到着する、長さＬ＝１からネゴシエートされた最大セグメントサイズＭＳＳまでの続く次のパケットの現在の最新の最小の観察された経過インターバルＥ（Ｌ）を記憶することが好ましく、これは、長さＬの単一のパケットが経路に沿った最低帯域幅リンク伝送媒体（例えば、通常のエンドユーザラストマイル５６Ｋｂｓダイヤルアップ又は５００Ｋｂｓブロードバンド、本説明の１９２〜１９５ページをも参照されたい）に完全に出るための送信時間遅延の知識／同等の推定値を我々に与える。送信時間遅延Ｅ（Ｌ）は、パケットの長さＬに線形に比例すると期待される。我々は、今、変更されたＴＣＰ又はモニタソフトウェアが、例えば（Ｗミリ秒＋最大のネゴシエートされたセグメントサイズＭＳＳの長さのパケットのＥ（Ｌ））がパケット到着なしで経過する時にそれ相応に反応するために、又は例えば最大のネゴシエートされたセグメントサイズＭＳＳの長さのパケットのＥ（Ｌ）が既にＷの値の導出／指定で考慮に入れられていると仮定する場合に例えばＷミリ秒だけの際にそれ相応に反応するためにイベントを「トリガする」だけになるように、Ｗミリ秒を指定することができる。

多数の中のもう１つのさらに単純化された例として、ここで、例えばはるかにより高速のウェブページダウンロード、ｆｔｐダウンロード．．．など、外部インターネット上のよりよい性能を与える、パケット到着間インターバル技法（これは、さらに変更する／適合させることができ、モニタソフトウェアではなく、直接にＴＣＰ自体のなかで実施することもできる）を利用してモニタソフトウェア内で実施される非常に単純化されたレシーバベースドの変更されたＴＣＰの概要を説明する。

．最新のパケット受信ローカルシステム時刻（リモートセンダから受信される。純ＡＣＫ、又は通常のデータパケット）、最新のレシーバパケットのアドバタイズされたウィンドウサイズ（ローカルＭＳＴＣＰによってリモートセンダに送信される）、最新のレシーバパケットのＡＣＫ番号すなわちリモートセンダから期待される次の期待されるＳｅｑ番号（ローカルＭＳＴＣＰによってリモートセンダに送信され、フローごとの着信パケット及び発信パケットの検査を必要とし、我々は、今や、通常の１２０秒インアクティビティを待たずに、ＦＩＮ／ＦＩＮＡＣＫの際にフローごとのＴＣＰテーブルエントリを即座に除去できなければならない）．．．など。

（任意選択）Ｓｙｎｃ／ＳｙｎｃＡＣＫ完了時に、即座に、リモートセンダのＣＷＮＤに例えばユーザ指定の又は動的にアルゴリズム導出された６４Ｋバイトをセットし、例えば、エンドユーザラストマイルリンクの帯域幅容量に依存してより小さい又はより大きいスケーリングされたサイズをセットすることもできる。例えば６４Ｋ（これは、ウインドウスケーリングオプションが選択されない限り、ネゴシエートされる通常のデフォルト最大ウィンドウサイズであり、これは、リモート外部インターネットウェブサイトのコンテンツを、経験される通常の数十秒と比較して、単一のＲＴＴだけのうちにダウンロードすることを可能にすることができる）がセットされる。これは、好ましくは、例えばＡＣＫＮｏ＝リモートセンダの初期ＳｅｑＮｏ＋１を有する例えば１５個の即座のＤＵＰＡＣＫを介して行われ、一部のＴＣＰが、その代わりにＡＣＫされたバイト数だけＣＷＮＤを増分するのみなので、ＤｉｖｉｓｉｏｎａｌＡＣＫは、良好に動作しない場合があり、最適のＡＣＫ挙動は、すべてのＴＣＰで同一でない場合がある。

２．次のパケットを受信せずに例えば３００ｍｓ（ユーザ指定の又は動的にアルゴリズム導出される）が満了する場合には、
→ 我々は、ソフトウェア内で、ＡＣＫＮｏに未到着の次の期待されるＳｅｑＮｏをセットされた３つのＤＵＰＡＣＫを生成するために、前の最後に受信されたパケットから例えば３００ｍｓ以内に次の期待されるＳｅｑＮｏが到着しないことを検出し、それと同時に、３つのＤＵＰＡＣＫ以内に例えば１８００バイトのウィンドウ更新を伝え（センダの「ポーズ」＋１パケットと同等）：例えば１００ｍｓが純ＡＣＫ又は通常のデータパケットを全く受信せずに経過する場合に、毎回１８００バイトだけ増分される１８００バイトの同一の３つのＤＵＰＡＣＫウィンドウ更新を送信し続けることだけを必要とするが、ＡＣＫ又は通常のデータパケットが実際に次に受信される場合には、リモートからＡＣＫ又は通常のデータパケットが次にもう一度受信されるまで、１００ｍｓおきに繰り返して、前のウィンドウサイズを復元する通常の（３つのＤＵＰＡＣＫではない）同一の単一のウィンドウ更新（ＡＣＫＮｏフィールドにローカルＭＳＴＣＰからリモートに送信された「；記録された」最新の「最大の」ＡＣＫＮｏ又は−１をセットする）を送信し、その後、上記の例えば３００ｍｓの満了検出ループを、上記のステップ２のまさに始めに繰り返す（任意選択として、我々は、まずこの点で、もう一度ループする前に、ここでＤｉｖｉｓｉｏｎａｌＡＣＫ／固定された個数のＤＵＰＡＣＫ／ＯｐｔｉｍｉｓｔｉｃＡＣＫ技法を利用して、送信するソースのＣＷＮＤサイズに例えばネゴシエートされた最大ウィンドウサイズ６４Ｋバイト／３２Ｋバイトをセットし、又は例えば送信するソースのＣＷＮＤサイズを１６ＤＵＰＡＣＫによって増分する．．．ことなどができる）。

利用できるいくつかのサブコンポーネント技法に関するさまざまな注：
．ＴＣＰ接続確立ＳＹＮＣ／ＳＹＮＣＡＣＫの後の最初の受信されたパケットから開始し、現在の観察されたＲＴＴ−現在の最新の記録されたＲＴＴｅｓｔ（ｍｉｎ）又は現在の観察されたＯＴＴ現在の最新の記録されたＯＴＴｅｓｔ（ｍｉｎ）が、妥当な累積総バッファリング遅延（例えば、ソースパケット生成における一時的に長くされた停止／ギャップによって引き起こされる）より大きい場合には、そのような発生を無視し、「トリガイベント」を引き起こさない。

．ＣＷＮＤサイズパーセンテージ縮小、例えば［（現在の観察されたＲＴＴ−現在の最新の記録されたＲＴＴｅｓｔ（ｍｉｎ）又は現在の観察されたＯＴＴ−現在の最新の記録されたＯＴＴｅｓｔ（ｍｉｎ））＋Ｔｍｓ］／現在の観察されたＲＴＴ又はＯＴＴを介する送信レート減分、しかし、ここで、Ｔ＝０ｍｓを用い、後続のボトルネックリンクのスループットが使用可能帯域幅の１００％になることを引き起こすことを暗示する留意し、及び／又は［（現在の観察されたＲＴＴ−現在の最新の記録されたＲＴＴｅｓｔ（ｍｉｎ）又は現在の観察されたＯＴＴ−現在の最新の記録されたＯＴＴｅｓｔ（ｍｉｎ））＋Ｔｍｓ］をセットされたポーズインターバル
．対応する適当な方法／アルゴリズムを作動させるための、内部プロプラエタリネットワークのサブネットアドレスと外部インターネットとの間の区別
．パケット到着間技法を、「同期化パケット」技法と同様に、使用のために適合させることができる。

．例えばｐａｔｈｃｈａｒ／ｐｉｐｅｃｈａｒ／ｐａｔｈｃｈｉｒｐ．．．などの帯域幅／リンクプロービング技法を、連合して展開して、トラバースされる経路／ノード／リンクの知識のより微細なレベルを導出して、それ相応によりよく反応することができる。

．最大ウィンドウサイズネゴシエーションを可能にするためのユーザ入力外部インターネット接続速度、例えばダイヤルアップから５Ｋバイト、しかし、ＩＳＰは、６４Ｋバイト／秒さえバッファリングし、例えば５Ｋバイト毎秒でユーザの５６Ｋｂｓダイヤルアップに転送することができ、これは、例えばトラバースされる経路が長々しい、例えば数秒のＲＴＴ又はＯＴＴを導入した時に非常に便利になるはずである。

．「ポーズ」する／ＣＷＮＤを減らす非常に早い反応時間は、パケットドロップパーセンテージを最小にし、「連続ポーズ」は、さらに、送信レート減分サイズを非常に柔軟に、すなわち、例えばＲＴＴあたり６４Ｋバイトから例えば３００ｍｓあたりわずか４０バイトに減らす。

．ＴＣＰは、高ＲＴＴフローに生得的に不公平であり、我々は、例えばパケット到着間インターバル技法を利用して、これを除去する。

．送信するソースＴＣＰの送信レート／スループットを減らすための、複数のＡＣＫの抑制すなわち送信するソースへの前方への転送でのわずかな遅延
．１００％に近いボトルネックリンク（１つ又は複数）の帯域幅容量利用度／スループットを常時維持することができることによって、バッファオーバーフロード輻輳パケットドロップ及び／又は物理送信エラーパケットドロップの後であっても、変更されたＴＣＰは、リンク（１つ又は複数）の帯域幅容量を非常に不十分に利用する既存ＲＦＣのＴＣＰ（既存ＲＦＣのＴＣＰのＡＩＭＤ加法増加乗法減少「鋸歯」利用度／スループットグラフから非常に明白であるとおり）と比較して、よいスループット／ボトルネック帯域幅利用度を約２倍にすることを可能にする。

さらなる注及びさらなる方法
パケット到着間インターバル（例えば３００ｍｓ）技法は、任意選択として、有効ウィンドウ全体分より少ないパケットが受信／送信される時に限ってアクティブにすることができる：そうでない場合には、３００ｍｓは、例えばＯＴＴ又はＲＴＴ＞例えば３００ｍｓ（戻るＡＣＫがセンダに戻って到着するために）の時に新しいパケット（１つ又は複数）を受信せずに経過する可能性がある：例えば現在の有効ウィンドウサイズより大きい、より小さい、又はこれと等しいかどうかを調べるために、最新の受信されたＳｅｑＮｏ−最新の送信されたＡＣＫ番号をチェックしてもよい。

リモートサーバがタイムアウトせず、ＣＷＮＤ及び／又はＳＳｔｈｒｅｓｈに１ＭＳＳ又は２ＭＳＳをセットしないように、任意選択として、ＳＹＮＣ／ＳＹＮＣＡＣＫ／ＡＣＫの後（又は１つ若しくは２つのまさに最初の受信された通常のデータパケットの後．．．）に例えば５００ｍｓおきに３＋ＤｕｐＮｕｍ個のＤＵＰＡＣＫを送信し続けてもよい。センダＴＣＰは、例えば送信された最初の通常のデータパケットの戻るＡＣＫ−送信されたＳＹＮＣＡＣＫの戻るＡＣＫＲＴＴ＞Ｃｍｓ、例えば１００ｍｓ（トラバースされる経路の輻輳レベルの非常に突然の増加に起因する）である場合に、データパケット転送の最初の６４Ｋバイト中にアルゴリズムを利用してもしなくてもよい。

洗練された仕様：
まず、レジストリエントリをセットし、はるかに好ましくＳＡＣＫをイネーブルし、ＤｅｌａｙＡｃｋｎｏｗｌｅｄｇｅｍｅｎｔをディスエーブルする。

コマンドライン入力パラメータ：
− ＷａｉｔＴｉｍｅＳｔａｍｐ（ｍｓ） − 「ネットワーク輻輳ドロップ」を推論するための、経過したパケット到着間インターバル
− ＰａｕｓｅＴｉｍｅＳｔａｍｐ（ｍｓ） − 「輻輳」時のリモートサーバポーズインターバル
− ＤｕｐＮｕｍ − リモートサーバは、３ＤＵＰＡＣＫ高速再送信フェーズ中に、受信される追加のＤＵＰＡＣＫごとにＣＷＮＤサイズをさらに増分し、我々は、この技法を使用して、大きい数ＤｕｐＮｕｍ個のＤＵＰＡＣＫを送信して、ＣＷＮＤをランプアップする。

− Ｏｆｆｓｅｔ − ０又は１、記録された最新の更新されたｄｗＡＣＫＮｕｍｂｅｒ（すなわち、レシーバＭＳＴＣＰによってリモートサーバに送信されたＡＣＫＮｏの最新の最大値）をセットされた場合にはＤＵＰＡＣＫ内のＡＣＫＮｏフィールドが働くかどうかは非常に確かではなく、あるいは、１バイトを減算した後に限って働く。

１．発信ＴＣＰパケット（我々のＭＳＴＣＰからリモートホストへのパケット）を処理するプロシージャ
必要な場合にはこのパケットのＴＣＰ接続の新しいエントリを作成する。私は、次のいくつかの変数を記録しなければならない。

− ｄｗＡＣＫＮｕｍｂｅｒ（ＡＣＫフラグがシグナリングされる場合） − ＴＣＰヘッダのＡＣＫフィールド
− ｄｗＳＥＱＮｕｍｂｅｒ − ＴＣＰヘッダのＳｅｑＮｕｍｂｅｒフィールド
− ｄｗＴＣＰＳｔａｔｅ − このＴＣＢ変数は、あなたが好む任意の形で、ＴＣＰ接続状態を制御するためにあなた自身が使用するためのものである。

シーケンスＳＹＮ／ＡＣＫ内の第３ＡＣＫパケット内のｄｗＭａｘＲｃｖＷｉｎｄｏｗＳｉｚｅを記録するためにＳＹＮＣ／ＳＹＮＣＡＣＫ／ＡＣＫを監視する：フローごとのＴＣＰは、リモートサーバに送信する我々のレシーバＭＳＴＣＰからのＳＹＮＣを検出した時にのみ作成されなければならない（それ以外の場合に作成してはならない）。

ＴＣＰ接続ＳＹＮＣ／ＳＹＮＣＡＣＫ／ＡＣＫでＡＣＫ応答パケットを送信した直後に、最初のデータパケットを受信する前であっても（これがリモートサーバのＣＷＮＤを増分するように働くと仮定して）、ＡＣＫ番号＝ｄｗＡＣＫＮｕｍｂｅｒ−Ｏｆｆｓｅｔ（ｄｗＡｃｋＮｕｍｂｅｒ − はＴＣＰ接続ＳＹＮＣ／ＳＹＮＣＡＣＫ／ＡＣＫシーケンスの３番目のＡＣＫ応答パケットのＡＣＫ番号である）とｄｗＭａｘＲｃｖＷｉｎｄｏｗＳｉｚｅフィールド値とｄｗＳＥＱＮｕｍｂｅｒフィールド値とを有する３＋ＤｕｐＮｕｍ個のＤＵＰＡＣＫを生成する。まさに最初のデータパケットが到着するまで、ＷａｉｔＴｉｍｅＳｔａｍｐインターバルおきに３＋ＤｕｐＮｕｍ個のＤＵＰＡＣＫを送信し続ける（＊＊＊注：ステップ３は、プログラムフロー内でまさに最初のデータパケットが到着した後に限ってアクティブ化され、ステップ２は、実際に、常時即座にアクティブである）。

２．リモートセンダＴＣＰからのＦＩＮ又はＲＳＴ及びローカルＭＳＴＣＰからのＲＳＴに関する着信パケットを監視する → 次に、ＴＣＰフローを即座に終了し、そうでない場合には、進行中のプロセス／ループアクティビティにかかわりなく、１６秒の総インアクティビティ（すなわち、あらゆるタイプの着信／発信パケットなし）の後に終了する。

３．ＴＣＰフローをチェックするプロシージャ（３＋ＤｕｐＮｕｍ個のＤＵＰＡＣＫの送信及び／又はウィンドウ更新パケットループの途中であっても、ＡＣＫＮｏ及びＳｅｑＮｏは、必ず、ローカルレシーバのＭＳＴＣＰからの、瞬間的な最新の送信された「最大の」ＡＣＫＮｏ、「最大」なのでＭＳＴＣＰ再送信のより小さいＡＣＫＮｏは無視される、及び最新の送信された「最大の」ＳｅｑＮｏを反映しなければならないことに留意されたい）。

接続が確立され、任意のＴＣＰフローについてリモートホストから我々のＭＳＴＣＰへの次のパケットを受信せずにＷａｉｔＴｉｍｅＳｔａｍｐミリ秒が満了する場合には、３つのＤＵＰＡＣＫ＋ＤｕｐＮｕｍ個のＤＵＰＡＣＫを次々にすばやく連続して送信して、ＡＣＫ番号＝最新の更新されたｄｗＡＣＫＮｕｍｂｅｒ（上で記録された）引くＯｆｆｓｅｔフィールド値及びｄｗＳＥＱＮｕｍｂｅｒフィールド値を伴う、０バイトのウィンドウサイズをアドバタイズする。

ＡＣＫ又は通常のデータパケットが次にもう一度リモートホストから受信されるまで、上記の３＋ＤｕｐＮｕｍ個のＤＵＰＡＣＫを１００ｍｓおきに送信し続ける。

あるいは、ＰａｕｓｅＴｉｍｅＳｔａｍｐミリ秒が、今、次のパケットを受信せずに経過し、そのどちらが先に発生しても（注：３＋ＤｕｐＮｕｍ個のＤＵＰＡＣＫのすべての保留中だが未送信の部分は、今、次のパケット又は経過したＰａｕｓｅＴｉｍｅＳｔａｍｐの時に即座に停止しなければならない）、その後、次の通常のデータパケット（純ＡＣＫではなく）がリモートホストからもう一度到着するまで、サイズ＝ｄｗＭａｘＲｃｖＷｉｎｄｏｗＳｉｚｅの単一の純ウィンドウサイズ更新（ＡｃｋＮｏフィールドにｄｗＡＣＫＮｕｍｂｅｒ−ＯＦＦＳＥＴをセットされ、ＤＵＰＡＣＫではなく．．．など、且つｄｗＳＥＱＮｕｍｂｅｒフィールド値を有する）を５０ｍｓインターバルおきに繰り返して送信し続け、次の通常のデータパケットが到着した時には、この後に、我々は、上記のステップ３の先頭でもう一度ループする（すなわち、リモートサーバを「ポーズ」するためにリモートホストからパケットを受信せずにＷａｉｔＴｉｍｅＳｔａｍｐをもう一度待つ．．．．．．など）。

ブロードバンドネットワーク（国際バックボーントランスポートを介するものであっても）は、非常に非常に低ロスレートであり、非常に非常に低輻輳である。

ｈｔｔｐ（ポート８０シグネチャ）フローは、例えば６４Ｋバイトのコンテンツ全体を例えば１ＲＴＴで送信することを許可されなければならない。ＳＹＮＣ／ＳＹＮＣＡＣＫ／ＡＣＫフェーズが再送信（ＲＦＣは１秒をデフォルトとする．．．）に出会う場合であっても、これは、最初の６４ＫバイトＣＷＮＤの使用を奨励するだけであるはずである。というのは、ボトルネックリンクに沿ったフローが、今や、レートを半分にされる可能性が高く．．．おそらく間隔をおかれてもよく（Ｒｍｓごとに１パケットを送信するレートペーシング、その結果、６４Ｋバイトは、１秒にわたって均等に間隔をおかれて送信されるようになる．．．．）、したがって、戻るＡＣＫ到着間経過インターバル、例えば１００又は３００ｍｓなどから（送信されたＳｅｑＮｏと期待され且つ経過したインターバルの後に到着しない対応する戻るＡＣＫと．．．が、遅延肯定応答を使用してはならないが、利用される場合に遅延肯定応答について調整することができる場合．．．）ＲＦＣデフォルト１秒ではなくＲＴＴ＋（例えば１００ｍｓ又は３００ｍｓ）以内に「検出された」トリガイベント（通常はパケットドロップ．．．）について即座に「ポーズ」する → 捨てられる可能性が高い場合に不必要にパケットを送信しない！。６４Ｋバイト初期ＣＷＮＤは、よい選択であるはずである．．．ラストマイル５６Ｋとブロードバンド媒体物理回線レートとの両方にうまく対処する。

さらに、記録された戻るＡＣＫ到着間インターバルの最小値．．．などから、ラストマイル媒体物理回線レート（５６Ｋ、ブロードバンド．．．など）を、曖昧でなく有用に導出することができる。

レシーバは、ローカルＭＳＴＣＰが自力で通常に自発的にＡＣＫＮｏフィールド＝＜リモートＴＣＰからの最新の記録された最大の受信されたＳｅｑＮｏを有するパケットを送信する（すなわち、例えば、受信されたＳｅｑＮｏ内の「ギャップ」．．．など）のを検出する時に必ず、又は、リモートＴＣＰからタイムアウト再送信を受信して（例えば、戻るＡＣＫｓ又は送信された３＋ＤｕｐＮｕｍ個のＤＵＰＡＣＫが失われた．．．など）、リモートＣＷＮＤをもう一度ランプアップする（リモートＣＷＮＤは、今や、タイムアウト後に１ＭＳＳ又は２ＭＳＳへ下に戻って下落する．．．）時に、３＋ＤｕｐＮｕｍ個のＤＵＰＡＣＫ（ＡＣＫＮｏフィールドに最新の最大の記録された送信された発信ＡＣＫＮｏをセットされて）を送信してもよい。

既存ＴＣＰ輻輳制御に対する新しい形は、次になるはずである。

１．例えばＴＣＰ接続ネゴシエーション中にＷｉｎｄｏｗＳｃａｌｉｎｇオプション（例えば６４Ｋ＋ウィンドウスケール）を使用して、スケーリングファクタ０−１４を介して「任意の」大きい値、例えば２＾３０（１ギガバイト）．．．に初期化されたセンダＴＣＰＷｉｎｄｏｗＳｉｚｅ及びレシーバＴＣＰＷｉｎｄｏｗＳｉｚｅ（スケールファクタ０＝スケーリングオプションをセットする必要がない、ＲＦＣ１３２３を参照されたい）。

２．レシーバＴＣＰ（又はレシーバモニタソフトウェア．．．など）は、ＳＹＮＣ／ＳＹＮＣＡＣＫの際に４Ｋバイト／１６Ｋバイト／６４Ｋバイト／又はＷ１Ｋバイト．．．などのウィンドウサイズを用いてＡＣＫし、４Ｋバイト／１６Ｋバイト／６４Ｋバイト／又は任意の指定された個数のＷ１若しくはＷ１Ｋバイトの分数を受信した時に、アドバタイズされるレシーバウィンドウサイズをＷ２Ｋバイト、例えばＮ２＊（４Ｋバイト／１６Ｋバイト／６４Ｋバイト／又はＷ１Ｋバイトなど）に増やし、ここで、Ｎ２は、データ通信が完了するまで、分数、例えば１．５／２．０／３．５／５．０などであり、又は、Ｗ３、Ｗ４．．．．．Ｗｎ．．．．などについて．．．．などのアルゴリズム的に導出された部分である（合計２＾３０すなわち１Ｇバイト未満）。

レシーバベースドモニタソフトウェア．．．などが、インターセプトされたレシーバＭＳＴＣＰ発信パケットを変更し、アドバタイズされるレシーバウィンドウサイズ．．．を変更し（変更されたパケットをリモートセンダＴＣＰに転送する前に）、したがって、継続的に増分されるアドバタイズされるレシーバウィンドウサイズだけに基づく新しいＴＣＰ輻輳制御方法を達成できることに留意されたい。

及び／又は
センダＴＣＰ（又はセンダモニタソフトウェア．．．など）は、ＳＹＮＣ時に、例えば４Ｋバイト／１６Ｋバイト／６４Ｋバイト／又はＷ１Ｋバイト．．．などのウィンドウサイズを用いてＳＹＮＣＡＣＫし、４Ｋバイト／１６Ｋバイト／６４Ｋバイト／又は任意の指定された個数のＷ１若しくはＷ１Ｋバイトの分数を肯定応答する戻るＡＣＫを受信した時に、センダウィンドウサイズをＷ２Ｋバイト、例えばＮ２＊（４Ｋバイト／１６Ｋバイト／６４Ｋバイト／又はＷ１Ｋバイトなど）に増やし、ここで、Ｎ２は、データ通信が完了するまで、分数、例えば１．５／２．０／３．５／５．０などであり、又は、Ｗ３、Ｗ４．．．．．Ｗｎ．．．．などについて．．．．などのアルゴリズム的に導出された部分である（合計２＾３０すなわち１Ｇバイト未満、超える場合にはおそらく例えばＳｅｑＮｏラップアラウンドの際のようにウィンドウサイズをラップアラウンドし、あるいは新しいＴＣＰ接続を継続する．．．など）。

センダベースドモニタソフトウェア．．．などが、リモートレシーバからのインターセプトされた着信パケットを変更し、アドバタイズされるレシーバウィンドウサイズ．．．を変更し（変更されたパケットをセンダＴＣＰに転送する前に）、したがって、継続的に増分されるアドバタイズされるレシーバウィンドウサイズだけに基づく新しいＴＣＰ輻輳制御方法を達成できることに留意されたい。

ＴＣＰが、対称であることができ、一端が、センダとレシーバとの両方であることができる、すなわち、上記の方法が、方向性で実施される必要があることにも留意されたい。

この方法は、任意により微細でより柔軟なよりさまざまなパケット送信の制御／ペーシングを可能にすると同時に、（必要な場合に）スロースタート／輻輳制御線形増加／３ＤＵＰＡＣＫ高速再送信／タイムアウト．．．などのすべての他の既存のＴＣＰエラー制御／輻輳制御機構を保存する（又は、類似する対応する機構を提供した）。

例えば、ＣＷＮＤをランプアップするための３＋ＤｕｐＮｕｍ個のＤＵＰＡＣＫの送信の以前の方法（又はＤｉｖｉｓｉｏｎａｌＡＣＫ技法若しくはＯｐｔｉｍｉｓｔｉｃＳＡＣＫ技法．．．など）（例えば、初期高速再送信でのＳＳｔｈｒｅｓｈ値への付随する損害、ＯｐｔｉｍｉｓｔｉｃＡＣＫを使用する場合のエンドツーエンドＴＣＰセマンティクス．．．などを伴う）ではなく、同一の目的及びより多くを、よりよく達成することができる（例えば、付随する不利益なしの、例えば３＋ＤｕｐＮｕｍ個のＤＵＰＡＣＫによるアドバタイズされるウィンドウサイズ値の増分．．．など）。

センダのＣＷＮＤは、所望の初期値４Ｋバイト／１６Ｋバイト／６４Ｋバイト／又はＷＫバイト．．．などになるように初期化されなければならず、あるいは、レシーバは、例えば３＋ＤｕｐＮｕｍ個のＤＵＰＡＣＫ又はさまざまな時の一連のそのようなＤＵＰＡＣＫ又はＯｐｔｉｍｉｓｔｉｃＡＣＫ．．．などを送信して、ＣＷＮＤを当初にランプアップすることができる（既存ＲＦＣ２４１４／３３９０は、既に、４Ｋバイト初期ＣＷＮＤ値を許容し、その場合に、ＣＷＮＤをランプアップする必要はない）。現在のインターネット上の既存サーバは、既に、ＳＳｔｈｒｅｓｈに任意の大きい値（例えば＝ＴＣＰウィンドウサイズ値）をセットし、これは、ＣＷＮＤ値のすばやい指数関数的ランプアップを可能にするはずであるが、大きいＳＳｔｈｒｅｓｈセッティングがない場合に、レシーバは、多数例えば３＋ＤｕｐＮｕｍ個のＤＵＰＡＣＫを送信して、ＣＷＮＤの線形ランプアップを引き起こすことができる（例えば、１０００個のＤＵＰＡＣＫ＝４０Ｋバイト＝３２０Ｋビット、これは、ブロードバンドを用いて十分に１秒未満ですべてを送信して、１ＫバイトのＳＭＳＳを仮定すれば１ＭバイトまでＣＷＮＤをランプアップし、あるいは１６というスケーリングされたウィンドウファクタの場合に１６ＭバイトまでＣＷＮＤをランプアップすることができる）。例えば１６のスケーリングされたウィンドウファクタを用いると、最小ウィンドウサイズ増分分解能は、１６バイトになるすなわち、例えば５／８／１５．．．バイトなどによる増分は不可能になるはずである。連続的に増分されるアドバタイズされたレシーバウィンドウサイズ法を用いると、レシーバは、センダが均等に間隔を置かれた／パケット間で均等に遅延されたパケットを送出する必要なしに、パケット注入のセンダのレートを「レート制限する」ことができる。この方法を十分に利用するのに、ウィンドウスケールファクタなしで十分である可能性がある（例えば、スケーリングオプションなしの例えば６４ＫバイトのＴＣＰウィンドウサイズ）ことに留意されたい。というのは、許容可能な送信ウィンドウが、受信されるすべての戻るＡＣＫに伴って「大きくなる」すなわち、レシーバが、ネットワーク状態のトリガイベントの知識（及び／又は例えば受信された最新の有効ＳｅｑＮｏ／送信された最新の有効ＡＣＫＮｏの知識．．．など）を利用して、アドバタイズされたレシーバウィンドウサイズを継続的に増分し／減分し／調整して、輻輳したネットワークが「トリガイベント」を介して検出され、ｒｗｎｄを例えば４８／５６／６４Ｋバイト．．．などに拡大する時に、ｒｗｎｄを、したがって例えば４／１６／３２／４０Ｋバイト．．．などのｒｗｎｄ値のｍｉｎ（ｃｗｎｄ，ｒｗｎｄ，ｓｗｎｄ）であるセンダの有効ウィンドウサイズを、したがって、ネットワークが輻輳していない／十分に利用されていないことが検出される時にセンダの有効ウィンドウサイズを継続的に調整することができるからである。この方法を、それ自体で又は例えば「ポーズ」法などの任意の他の方法と組み合わせて利用できることに留意されたい。注：同期化パケット法は、継続的に調整されるｒｗｎｄ値を搬送することができる。

リモートサーバでの変更（初期ＣＷＮＤ、ＳＳｔｈｒｅｓｈ値セッティングに対する）を一切伴わずにレシーバ側のみでこの方法を実施するために、レシーバは、この方法をアクティブ化し、したがってＣＷＮＤが十分に大きくなる前に、ある秒数又はある個数のＲＴＴ又はある個数のパケットが経過し／受信されるのを待つために（介在するセンダのＲＴＯタイムアウト及び／又はレシーバ高速再送信要求なしで：これらが発生する場合には、レシーバは、センダの保留中のＲＴＯタイムアウトの前であってもすぐにこの方法をアクティブ化し．．．など、センダのＲＴＯタイムアウトを避けること）を選択することができる、この故に、すべての高速再送信要求が十分に高いＳＳｔｒｅｓｈ（＝既にフライト中のすべてのパケットの後、３ＤＵＰＡＣＫｓ高速再送信要求の前のＣＷＮＤ／２）を維持するはずである。要求された場合に、又はコンテンツ全体が通常は＜６４Ｋバイトであるｈｔｔｐウェブサイトアクセスで有利に）、レシーバは、ＳＹＮＣ／ＳＹＮＣＡＣＫ／ＡＣＫの直後に又は受信された１つ若しくは２つの通常のデータパケットの直後に、ＯｐｔｉｍｉｓｔｉｃＡＣＫ（ＡＣＫＮｏ＝受信された最新の有効なＳｅｑＮｏ＋例えば４／１６／３２／６４Ｋバイト．．．などを有する、これは、ＳＳｔｈｒｅｓｈに影響しない）によってＣＷＮＤを即座にランプアップすることができ、それと同時に、同一リモートＩＰ番号と同一ポート番号と同一ソースＩＰ番号とを有するが異なる指定されたポート番号を有する並列ＴＣＰ接続を確立することができ、ここで、ＳＹＮＣ／ＳＹＮＣＡＣＫ／ＡＣＫの直後又は受信された１つ又は２つの通常のデータパケットの直後に任意選択でセンダのＣＷＮＤを３＋ＤｕｐＮｕｍ個のＤＵＰＡＣＫを用いてランプアップし、その結果、センダのＣＷＮＤは、今＝例えば４／１６／３２／６４Ｋバイト．．．などになる（又は、オリジナルＴＣＰの初期データパケットがすべて成功して受信されてはいない時に限ってランプアップする）：オリジナル接続が例えば４／１６／３２／６４Ｋバイトのすべてを成功して受信した場合に、第２ＴＣＰ接続を、今や、ＲＳＴリセットを介して即座に終了することができ、そうでない場合に（又は、オリジナルＴＣＰと同時に）すべての欠けている初期４／１６／３２／６４Ｋバイト分のパケット／セグメントを、第２ＴＣＰ接続から入手することができる（例えば、変更されたソフトウェアによってオリジナルＴＣＰレシーバソケットに転送する．．．変更されたソフトウェアは、必要な場合に、例えば最初の４／１６／３２／６４Ｋバイト受信中のオリジナルＴＣＰ接続の認証パケットが存在する場合にその認証パケットなど、両方向でのすべてのパケットフローを記録することもでき、且つ、スクリプトは、最初の４／１６／３２／６４Ｋバイト受信中の第２平行ＴＣＰ接続に正確に同一のシーケンスを注入する）。ＣＷＮＤが、例えばここで最大値６４Ｋバイトに初期化された場合であっても、レシーバは、それでも、当初に２／４／８Ｋバイトのｒｗｎｄを送信し、イベントに従ってｒｗｎｄを増分し／調整する（例えば、ウィンドウ更新パケット又は通常のデータパケット）ことによって、例えば２／４／８バイト．．．などで開始して、センダの注入レートをペーシングすることができる。

注：例えば受信される最初の通常のデータパケット（又はより多くの．．．、又はセンダＴＣＰからのＳＹＮＣＡＣＫの受信の直後にさえ）を待って、その後にセンダのＣＷＮＤを例えばＡＣＫＮｏフィールドに通常の最大の最新の有効なＳｅｑＮｏ−１ではなく受信された最大の最新の有効なＳｅｑＮｏをセットされた３＋ＤｕｐＮｕｍ個のＤＵＰＡＣＫによってランプアップし（すなわち、ＴＣＰセッション全体を通じて最大の受信された１バイトをＡＣＫするのを抑制する、又は任意選択で）、且つ、その後、連続的に増分するアドバタイズされるレシーバウィンドウサイズ法を（両端での十分に大きいウィンドウスケーリングと一緒に）利用することによって、我々は、今、両端のＴＣＰ送信レートをトータルコントロール及び保存されたＴＣＰセマンティクスの下に成功して置いている（且つ、「ポーズ」法を用いて、両端のＴＣＰは、今、「ポーズ」輻輳制御だけを受けるフルワイヤスピードで送信することができる、すなわち、ＣＷＮＤ、両端のＴＣＰのウィンドウサイズ、ＳＳｔｈｒｅｓｈ．．．などは、ＴＣＰフローが安定したならば、ある時点でさらなる役目を演じる必要がない．．．しかし、適当なより小さい値から開始し、例えばフル許容可能物理ワイヤスピードレート又は現在のｒｗｎｄサイズによって許容される伝送速度まで増加する、連続的増分ｒｗｎｄを使用することが好ましい（フローは、今、「安定化」されるように増加した．．．）。

明らかに、センダの最大送信レートは、ｍｉｎ（ｓｗｎｄ，ｃｗｎｄ，ｒｗｎｄ）−肯定応答されていない送信されたセグメントに依存し（又は、ここでのｓｗｎｄが、同一の当初にネゴシエートされたウィンドウサイズスループットで固定されている場合に、肯定応答されていない送信されたセグメントは、ｓｗｎｄを減らし、肯定応答されたセグメントは、ｓｗｎｄを増やす）、且つ、ＲＷＮＤ連続増分／減分／調整法は、これをｒｗｎｄ更新で考慮する。

また、リモートサーバＴＣＰ送信レートを、今、ｒｗｎｄだけを調整することによってペーシングすることができる（リモートサーバのｃｗｎｄ、ｓｓｔｈｒｅｓｈ、ｓｗｎｄは、今、必ず、任意に大きい又は非常に大きい値に維持することができる）ので、レシーバベースドソフトウェアは、ｒｗｎｄウィンドウ更新の値の動的選択を介してリモートセンダの送信レートを動的にペーシングすることができ、したがって、リモートサーバＴＣＰ宛のすべてのインターセプトされたレシーバＭＳＴＣＰ生成パケット内のすべてのｒｗｎｄフィールド値を、センダの送信レートをペーシングするのに必要なｒｗｎｄ値に変更することができる（これは、パケットチェックサム再計算変更を必要とするはずである）。

レシーバベースドソフトウェア／ＴＣＰ（センダベースドソフトウェア／ＴＣＰ変更として実施することもできる）は、タイムスタンプフィールドから到着するＯＴＴ値を有利に監視することができ、ＯＴＴ値が、小さい許容される変動（例えば、センダのＯＳ／スタックＣＰＵ処理時間での小さい変動に起因する）の中で最新のＯＴＴｅｓｔ（ｍｉｎ）と同一（又は、以前に既知の実際の非輻輳ＯＴＴと同一）のままになる間に、レシーバベースドソフトウェア／ＴＣＰは、達成された最新の最大のｒｗｎｄを書き留める → これは、その間に経路をトラバースするパケットが多くとも上と同一の小さい許容される変動（及び／又は＋許容される累積バッファ遅延、例えば０ｍｓ／５０ｍｓ／１００ｍｓ．．．などの追加のＢｍｓ）のバッファ遅延又は累積バッファ遅延に全く出会わない、これまでに達成された最大のｒｗｎｄ値を与える → その後、パケットが輻輳ドロップされる時に必ず、レシーバベースドソフトウェアは、有利に／任意選択でｒｗｎｄ更新値（インターセプトされたパケット内の変更されるｒｗｎｄフィールド値）に、前述で定義されるこの最新の最大の記録されたｒｗｎｄ値をセットすることができる → すなわち、輻輳ドロップイベント及び／又は高速再送信イベント．．．などの際に、レシーバは、センダの送信レートの維持されたペースに継続し、その結果、レートを、輻輳していないトラバースされた経路条件の下のフローによって達成されたヒストリカル最高レートで維持することができるようになり、したがって、非常に理想的な高いリンク帯域幅利用度が維持されるようになる。さらに、レシーバソフトウェア／ＴＣＰは、到着するＯＴＴ値が最新の（又は実際の非輻輳ＯＴＴ）ＯＴＴｅｓｔ（ｍｉｎ）を超えないすなわち、経路に沿ったバッファ遅延がない限り、継続的にｒｗｎｄを増分することができ（スロースタート指数関数ｒｗｎｄ増大及び／又は輻輳回避線形増大のどちらをエミュレートするにせよ）（及び／又は任意選択で、到着するＯＴＴがＯｔｔｅｓｔ（ｍｉｎ）を超える場合に下向きに減分する、さらに、しかし、到着するＯＴＴ値が、例えば指定された１０ｍｓ／５０ｍｓ／１００ｍｓ．．．などだけ最新の（又は既知の実際の非輻輳ＯＴＴ）ＯＴＴｅｓｔ（ｍｉｎ）を超える（例えば、パケットがバッファリングされ始める時であってもそのレートを増分する他の未変更既存ＴＣＰフロー又はＵＤＰトラフィックに起因する)時に、レシーバベースドソフトウェア／ＴＣＰは、今や、ｒｗｎｄをもう一度増分することを許可することを選択することができる．．．。

経路に沿ったすべてのＴＣＰフロー（その帯域幅の最小の保証された部分をＴＣＰフローに、及びある部分をＵＤＰに．．．などに便利に割り当てることもできる）が、直前の段落で述べた変更されたＴＣＰである場合に、そのようなＴＣＰが、必ずバッファリングが要求されることを全く引き起こさないことに留意されたい → ほとんど完全に輻輳していない／バッファリングされない経路が常時維持される。先在する変更されたＴＣＰがトラバースされるリンクの全帯域幅のフル利用度を既に一緒に達成した時に、新たに確立される変更されたＴＣＰの増大を可能にする公平な共有を保証するために、新たに確立されるＴＣＰは、例えばＯＴＴｅｓｔ（ｍｉｎ）又はＲＴＴｅｓｔ（ｍｉｎ）又はそれらの既知の実際の値の１００ｍｓの余分の遅延を超えないところまでその送信レート又はｒｗｎｄ又はｃｗｎｄを増大させることを許可されることができ、すべての変更されたＴＣＰは、例えば＞１００ｍｓの余分の遅延を経験する時に、すべてが、ある比率、例えば１０％／１５％／２５％．．．などだけその送信レート又はｒｗｎｄ又はｃｗｎｄを減らすはずである（これは、先在する確立されたフローに味方するが、新しい確立されたＴＣＰがその送信レート増大を達成し始めることをも可能にする）。ここで、トラバースされるすべてのノードが例えば１００ｍｓ同等分より多いバッファを有する限り、輻輳ドロップがないはずであることに留意されたい。もう１つの方式は、パケットがバッファリングされ始めることの始まり（最新のＯＴＴ又はＲＴＴのＯＴＴｅｓｔ（ｍｉｎ）又はＲＴＴｅｓｔ（ｍｉｎ）の余分の遅延によって示される）まで、連続的な送信レート又はｒｗｎｄ又はｃｗｎｄ．．．などの増大を許容することであり、パケットがバッファリングされ始めることの始まりの時には、その送信レート又はｒｗｎｄ又はｃｗｎｄは、後ろ向きに１ステップだけ減分される（したがって、１００％利用度レベルの前後での振動する前向きの増分及び後ろ向きの減分）。

上記のさまざまな方式を、センダベースドＴＣＰとして同様に簡単に実施できることにも留意されたい。

単純に例えば輻輳ドロップイベント（その時には、変更されたＴＣＰは、全体的な輻輳していない条件の下での最大の達成された送信レート若しくはｒｗｎｄ若しくはｃｗｎｄサイズ又はそのパーセンテージ、あるいは単純に輻輳ドロップが発生する時の現在の送信レート若しくはｒｗｎｄ若しくはｃｗｎｄサイズのパーセンテージ．．．などに戻る）まで送信レート又はｒｗｎｄ又はｃｗｎｄの増大を可能にすることは、現在のＲＦＣ標準ＴＣＰフローとのよい共存を可能にする。「ポーズ」法が組み込まれる場合に、「ポーズ」インターバルは、検出された輻輳ドロップの直前の最新のＯＴＴ値又はＲＴＴ値及びＯＴＴｅｓｔ（ｍｉｎ）又はＲＴＴｅｓｔ（ｍｉｎ）あるいは既知の輻輳していない実際のＯＴＴ値又はＲＴＴ値から導出することもできる：例えば、輻輳ドロップイベントの直前の最新のＯＴＴが７００ｍｓであり、ＯＴＴｅｓｔ（ｍｉｎ）が２００ｍｓである場合には、今や、すべてのノードのバッファリングされたパケットを完全にクリアするために、「必要な」ポーズインターバルに例えば５００ｍｓ（７００ｍｓ−２００ｍｓ）を、又は必要に応じてより多く、例えば６００ｍｓ又はより少なく、例えば４００ｍｓさえセットすることができる。

複数の可能性の中の、例のレシーバベースド実施態様（センダベースドは、類似するがより単純になるはずであることに留意されたい）は、単に、レシーバが、ウィンドウスケールオプションを要求することであり、例えば、２５６Ｍバイトの最大値へのスケーリング（最大の可能なスケーリングは、１ギガバイトすなわち、２＾１４＊６４Ｋバイト又は通常のスケーリングされない１６ビットウィンドウサイズを左に１４回シフトするが、ここで、最大値２５６Ｍバイトは、１２のウィンドウスケールファクタすなわち、２＾１２＊６４Ｋバイト又は通常のスケーリングされない１６ビットウィンドウサイズを左シフトする：ＧｏｏｇｌｅＳｅａｒｃｈ用語「ｗｉｎｄｏｗｓｃａｌｅｓｉｚｅ」、ｈｔｔｐ：／／ｒｄｗｅｂ．ｃｎｓ．ｖｔ．ｅｄｕ／ｐｕｂｌｉｃ／ｎｏｔｅｓ／ｗｉｎ２ｋ−ｔｃｐｉｐ．ｈｔｍ、ｈｔｔｐ：／／ｓｕｐｐｏｒｔ．ｍｉｃｒｏｓｏｆｔ．ｃｏｍ／ｄｅｆａｕｌｔ．ａｓｐｘ？ｓｃｉｄ＝ｋｂ；ｅｎ−ｕｓ；１９９９４７、ｈｔｔｐ：／／ｗｗｗ．ｎｅｔｐｅｒｆ．ｏｒｇ／ｎｅｔｐｅｒｆ／ｔｒａｉｎｉｎｇ／ｎｅｔｐｅｒｆ−ｔａｌｋ／０２０７．ｈｔｍｌ、ｈｔｔｐ：／／ｗｗｗ．ｎｃｓａ．ｕｉｕｃ．ｅｄｕ／Ｐｅｏｐｌｅ／ｖｗｅｌｃｈ／ｎｅｔ＿ｐｅｒｆ／ｔｃｐ＿ｗｉｎｄｏｗｓ．ｈｔｍｌ、ｈｔｔｐ：／／ｗｗｗ．ｍｏｎｋｅｙ．ｏｒｇ／ｏｐｅｎｂｓｄ／ａｒｃｈｉｖｅ／ｂｕｇｓ／０００７／ｍｓｇ０００２２．ｈｔｍｌ、ｈｔｔｐ：／／ｗｗｗ．ｆｒｅｅｓｏｆｔ．ｏｒｇ／ＣＩＥ／ＲＦＣ／１０７２／４．ｈｔｍ、ｈｔｔｐ：／／ｗｗｗ．ｆｒｅｅｓｏｆｔ．ｏｒｇ／ＣＩＥ／ＲＦＣ／１３２３／５．ｈｔｍ、ｈｔｔｐ：／／ｗｗｗ．ｎｅｔｗｏｒｋｓｏｒｃｅｒｙ．ｃｏｍ／ｅｎｐ／ｐｒｏｔｏｃｏｌ／ｔｃｐ／ｏｐｔｉｏｎ００３．ｈｔｍ、ｈｔｔｐ：／／ｗｗｗ．ｅｈｓｃｏ．ｃｏｍ／ｒｅａｄｉｎｇ／１９９９０６２８ｎｃｗｌ．ｈｔｍｌ、ＧｏｏｇｌｅＧｒｏｕｐＳｅａｒｃｈ用語「ｗｉｎｄｏｗｓｃａｌｅｓｉｚｅ」、ｈｔｔｐ：／／ｒｄｗｅｂ．ｃｎｓ．ｖｔ．ｅｄｕ／ｐｕｂｌｉｃ／ｎｏｔｅｓ／ｗｉｎ２ｋ−ｔｃｐｉｐ．ｈｔｍを参照されたい）は、４Ｋバイトレシーバウィンドウサイズ（４Ｋバイトは、たまたま、実験的ＲＦＣの初期ＣＷＮＤ値に対応する）の最小の可能な分解能を与える。

１．リモートサーバは、スケーリングされたセンダウィンドウサイズを対応して選択することができるが、単純に、レシーバがスケーリングするが、それ自体のセンダのウィンドウサイズをスケーリングしないことを選択することを許容することもできる：これは、さほど重要ではない（そのようなネゴシエートされたウィンドウサイズ（１つ又は複数）が、ラストマイル及び／又はファーストマイルの物理帯域幅、例えば５６Ｋ／５００Ｋｂｓ．．．などについて大きすぎる場合であっても）。

注：センダが、レシーバに類似するウィンドウスケーリングファクタを行う場合に、これは、例えば単純にレシーバＰＣのＴＣＰＷｉｎｄｏｗＳｉｚｅレジストリ値に例えば１をセットし、例えば２＾１４の例えばスケールファクタ（最小ウィンドウサイズ分解能は、今は約４Ｋバイトである）をセットすることによって、必要なすべての新しいソフトウェア又は変更されたＴＣＰなしで、この方法の非常に単純で準備のできた使用を可能にすることができ、したがって、センダの有効送信ウィンドウは、レシーバが今はそのｒｗｎｄに多くとも４Ｋバイトを常時セットするだけであるはずなので、常時、約４Ｋバイトまでに制限される（２のＴＣＰＷｉｎｄｏｗＳｉｚｅレジストリ値及び１４のスケーリングされたファクタというレシーバＰＣのレジストリセッティング又はアプリケーションソケットバッファのセッティングを用いると、これは、約１６Ｋバイト＊２すなわち３２Ｋバイトの分解能を与える）。

２．レシーバは、必要な場合に、すべてのインターセプトされた発信パケットを変更し、それらのレシーバウィンドウサイズフィールドのそれぞれが、常時、適切な上側シーリング値、例えば５６Ｋレシーバラストマイルのダイヤルアップについて１６Ｋバイト、又は例えば５００ｋｂｓレシーバのラストマイルＤＳＬについて９６Ｋバイト．．．などを超えないことを保証する。

［ここでの単純な非常にエレガントな配置は、今、ＴＣＰセッションの全体を通じた超高速指数関数的センダのＣＷＮＤ増大を保証し終えているはずであり、例えば、常時、６４ＫのＣＷＮＤに達するために例えば約６４ＲＴＴ時間を必要とするのではなく、多くとも６ＲＴＴ時間だけを必要とする（センダの初期ＳＳＴｈｒｅｓｈに、非常に大きく、スケーリングされたレシーバウィンドウサイズと同一の値がセットされることに留意されたい）、しかし、センダの最大有効送信レートは、常時、受信された変更されたレシーバのウィンドウサイズ上側シーリングの値までに制限されるはずである → センダの送信レートは、常時、必ず、レシーバのウィンドウサイズ上側シーリングによって許容されるものを超えず、センダの「スラインディングウィンドウ」サイズ及び戻るＡＣＫを介する「セルフクロッキング」特性によってさらに支配される（戻るＡＣＫのレートが、通常はファーストマイル又はラストマイルの媒体リンクにある、最小ボトルネックリンクの使用可能帯域幅を反映することに留意されたい）。経路に沿ったバッファ遅延の始まりは、センダのＢＤＰスループットを低速化するはずであるが、制限された輻輳パケットドロップは、レシーバに３ＤＵＰＡＣＫ高速再送信を要求させ、このセンダの今は半分にされているＣＷＮＤ及びＳＳｔｈｒｅｓｈ値が、最も確かに、常時レシーバのウィンドウサイズ上側シーリング値より非常にはるかに大きいままになり続けるはずであるが、持続される輻輳パケットドロップは、センダにＲＴＯ再送信をタイムアウトさせ、このセンダのＣＷＮＤは、今、例えば４ＭＳＳでもう一度スロースタートするが、やはりすばやく指数関数的に増大するはずである → すべてのそのようなＴＣＰフローのセンダのＣＷＮＤが、今、それらのセンダのレシーバのウィンドウサイズの上側シーリングまでに制限されるが、ほぼ常時その近くに維持されることがわかる．．．。

３．任意選択で、レシーバは、発信パケットのレシーバウィンドウサイズフィールドをゆっくり増加することによって、センダのネットワークへのパケットの注入レートをペーシングすることができ、例えば、ＴＣＰ確立直後に、レシーバは、４Ｋバイトから開始し、次に８Ｋバイト、次に１２Ｋバイト．．．次に６４Ｋバイトで、例えば１秒の間に例えば６２．５ｍｓおきに、等間隔で均等なタイミングの一連の例えば１６個の純ウィンドウ更新パケットを送信することができ（即座に６４Ｋバイト上側シーリングウィンドウサイズをアドバタイズするのではなく、このアドバタイズは、パケットバーストを引き起こすはずである）、したがって、センダからの突然の大きいパケットバーストがないことを保証する（戻るＡＣＫは、この一連のウィンドウサイズ更新中に存在する場合に、可能なパケット注入レートを増やすはずであるが、しかし、レシーバは、任意選択として、これを考慮に入れてウィンドウ更新サイズ値を減らすことができることに留意されたい）。レシーバは、任意選択として、進行中のパケットのレシーバウィンドウサイズフィールド値を、適当な場合にいつでも変更することができる。同様に、そのようなウィンドウサイズ更新／変更は、おそらくは最新の発信する送信された戻るＡＣＫの値．．．などを考慮に入れて、いつでも増分／減分／調整の任意の所望の形で実行することができる。これは、ＴＣＰ接続確立の直後に最高速の最適の形でｈｔｔｐウェブサイトコンテンツをフェッチするのに有用になり得る（すなわち、その後、例えばレシーバの可能なラストマイル物理最大回線レートで送信するためのセンダのペーシング：センダに１ＲＴＴで例えば６４Ｋバイトコンテンツのすべてを即座にバーストさせることが、非生産的である場合があることに留意されたい．．．）。

４．さらに、任意選択として、これを、「ポーズ」法及び／又は「パケット到着間」法及び／又は前の段落で説明したさまざまな方法．．．などと一緒に実施することができる。例えば、ここでの非輻輳ＲＴＴ／ＯＴＴが例えば５０ｍｓである場合に、「ポーズ」法は、ここで、２つの端の間の非輻輳ＲＴＴ／ＯＴＴ（又は最新の推定された非輻輳ＲＴＴ／ＯＴＴ）値と例えば２００ｍｓのバッファ遅延との和であるタイムアウト期間と、例えば１５０ｍｓのタイムアウトの際の「ポーズ−インターバル」とを指定することができる→ここでのボトルネックリンクの帯域幅を、常時コンスタントに１００％利用することができる。というのは、ここでの「ポーズ」法が、１バッファ内で占有される累積的なトラバースされる経路のバッファの占有をいつでも小さい範囲に保つように努力する、すなわち、ボトルネックリンクを常に１００％利用できるからである。

この故に、本明細書のセンダのＣＷＮＤ機構は、いくつかのステージで輻輳制御目的の達成における要件に対して冗長であることに留意されたい（ＲＴＯタイムアウトイベントを避ける、輻輳トリガイベントの際にＣＷＮＤサイズをすばやく増分するためのパケット到着間法プラス３＋ＤｕｐＮｕｍ個のＤＵＰＡＣＫ．．．などの他のコンポーネント方法が組み込まれない場合を除く）。この場合には、この故に、ＣＷＮＤが、非常に大きい値を達成するためのまさに初期ステージの指数関数的及び／又は線形の増大中のネットワーク使用可能帯域幅プロービングの部分役割だけを演じ続け（接続の最大送信レートが、いつでも、例えば、レシーバが例えば６４Ｋのｒｗｎｄ値をアドバタイズするのではなくスケーリングされシフトされたフォーマットでアドバタイズする例えば比較的非常に小さいｒｗｎｄ値までに制限されはするが）、レシーバＴＣＰは、今や、最大のスケーリングされたファクタ１４が利用される場合に、１２位置だけ左シフトされた４すなわち６４Ｋと同一のｒｗｎｄ値を示す、４だけをアドバタイズする：両端が、今は非常に大きい最大のスケーリングされたウィンドウサイズを許容する／ネゴシエートしたが、レシーバＴＣＰは、その通常の物理的な現在の最新の使用可能最大レシーバウィンドウサイズをアドバタイズすることだけができ、例えば、その物理的な最大の可能な受信ウィンドウバッファリソースが１６Ｋである場合に、１４の最大のスケーリングされたファクタが利用されると仮定して、レシーバＴＣＰによって生成されるすべてのパケット内のアドバタイズされる受信ウィンドウサイズフィールドは、常時１の最大の可能な値を示すだけになるはずであることに留意されたい）その後、３ＤＵＰＡＣＫ高速再送信／回復の際のＣＷＮＤ値及び／又はＳＳｔｈｒｓｈ値を半分にする場合であっても、半分にされたＣＷＮＤ値及び／又はＳＳｔｈｒｓｈ値は、ｒｗｎｄと比較して非常に大きいままである：ネットワークが非輻輳したままになる場合に、センダは、スライディングウィンドウ内の使用可能セグメント／バイト（戻るＡＣＫのセルフクロッキング特性に依存する）及び／又はｒｗｎｄ若しくはｃｗｎｄサイズによってのみ制限される最大レートで幸福に送信し続けることができ、３ＤＵＰＡＣＫ高速再送信要求の際に、センダの最大送信レートは、今や、スライディングウィンドウ内の使用可能セグメント／バイトによってのみ制限され（スライディングウィンドウ内のこの使用可能セグメント／バイトは、今、まだ肯定応答されていない送信されたフライトパケットの比率／個数によって適当に減らされるが、ここで、ＣＷＮＤとＳＳＴｈｒｅｓｈとの両方が半分にされても、半分にされたＣＷＮＤ及びＳＳｔｒｅｓｈが、それでもＲＷＮＤ又はＳＷＮＤよりはるかに大きいので、このＣＷＮＤ及びＳＳｔｒｅｓｈは、全く影響を有しない）、したがって、事実上、送信レートは、今、適当に比例して減らされ、ＲＴＯタイムアウトの際に（通常、１秒というＲＦＣの最小下側シーリング時間期間の後）、センダ送信レートすなわち１又は複数ＳＭＳＳのリスタートＣＷＮＤによって支配される値は、今、最小値まで減らされるが、実際に、ＲＴＯタイムアウトの前と同一の送信レートをほぼ必ず保持することができ、というのは、ここでのセンダが、通常、ＲＴＯタイムアウトの前に有効ウィンドウ分のセグメント／バイトの非常に大きい部分又は全体全部を送信し終えているからであり、したがって、多数のＲＴＯタイムアウトの連続する即座の送信は、続くまだ肯定応答されていない送信されたセグメント／パケットの連なりによって引き起こされる連続ですばやく続き、有効スライディングウィンドウ内の送信された肯定応答されていないすべてのセグメント内のそのような「輻輳ドロップ」パケットの比率のサイズ／個数は（すべてが輻輳ドロップされた場合であっても）、例えば１秒ＲＴＯタイムアウトイベントの後にセンダの送信レートを減らさないが、センダは、ＲＴＯタイムアウトの前の例えば１秒の期間中にすべての送信を停止しているはずである → すべての介在するノードのバッファリングされたパケットは、この／これらの特定の変更されたＴＣＰごとのフローのバッファリングされたパケットの例えば１秒と同等の量（又は他のフローのバッファリングされたパケットの同等の量）をクリアされ、また、例えば１秒と同等の量は２００ｍｓ〜５００ｍｓというノードの通常のバッファ同等容量をはるかに超えるので、ほとんどの他の未変更の既存ＴＣＰフローのバッファリングされたパケットの例えば１秒と同等の量（又は他のフローのバッファリングされたパケットの同等の量）をクリアされる可能性が非常に高く、いくつかの他のＴＣＰフローは、変更されていようといまいと、後に、ＲＦＣの最小値１秒より長くタイムアウトすることができ（そのＲＴＴが普通でなく非常に長い場合に）、すべてのトラバースされたノードのバッファリングされたパケットの全体的なクリアを保証するのを助ける（すべてのフローが、いくつかがわずかに後の時になる可能性はあるが、ＲＴＯタイムアウトするはずなので）［注：これは、１秒の大きい「ポーズ」インターバルと同義である］。

この方法は、その最も単純な形で、ユーザがローカルＰＣＴＣＰレジストリパラメータをセットして、例えば１２のスケールファクタなど、大きいウィンドウスケールファクタを利用することだけを必要とするが、１６ビットの通常のＴＣＰＷｉｎｄｏｗＳｉｚｅ値は、例えば１バイトから６４Ｋバイトなど、必要なだけ小さく又は大きくセットすることができる：１２のユーザＰＣスケールファクタすなわち２５６Ｍバイトの最大の可能なスケーリングされたウィンドウサイズ値及びわずか１のユーザＰＣＴＣＰＷｉｎｄｏｗＳｉｚｅ値と、例えば１２のリモートサーバのネゴシエートされたスケールファクタ及び例えば６４ＫバイトのリモートサーバＴＣＰＷｉｎｄｏｗＳｉｚｅとを用いると、リモートサーバ最大送信レートは、いつでも、ＲＴＴあたり４Ｋバイト（１＊２＾１２）のユーザＰＣのスケーリングされたウィンドウサイズを超えない（中間ソフトウェアがある場合に、その中間ソフトウェアが、ユーザＰＣからの発信パケットをインターセプトせず、４Ｋバイトより大きくなるようにそのｒｗｎｄフィールド値を変更しないと仮定して）。リモートサーバのＳｓｔｈｒｅｓｈ値が、通常は、ＴＣＰ接続確立中にネゴシエートされたｒｗｎｄ値と同一になるように初期化されることに留意されたい。センダでこの方法を実施するために、リモートサーバは、リモートサーバのＴＣＰスタックがそのＳＳｔｒｅｓｈ値を任意に非常に大きくなるように、例えば「無限大に」固定し、ＴＣＰ接続ネゴシエーションに関してウィンドウスケールオプションを利用する（且つ／又は、そのＣＷＮＤ値をその最大の達成された増大スループットに固定するすなわち、ＣＷＮＤは、例えば１ＳＭＳＳの初期ＲＦＣ値から継続的に増分することができるが、絶対に減分できない）ことだけを必要とする。

変更されたＴＣＰを利用することは、スループットを増やし、例えば専用回線／ＤＳＬ上のデータストレージサイトバックアップアプリケーション．．．など、大きいファイルのｆｔｐ転送完了時間を減らすことが注目されてきた。これは、既存ＴＣＰを用いると、センダが、必ず、常時その送信レートを増やす、すなわち、ＣＷＮＤが、輻輳に起因してパケットが捨てられるまで単調に増加するからであり、輻輳に起因してパケットが捨てられる時には、センダＴＣＰは、その送信レートをアグレッシブに減らす、すなわち、ＣＷＮＤを例えば１ＳＭＳＳにリセットし、ＲＴＯタイムアウトの直前（又は、３ＤＵＰＡＣＫ高速再送信要求の直前、この時には、センダの送信レートすなわちＣＷＮＤが半分にされる）の達成された送信レート又は達成されたＣＷＮＤサイズまで戻る非常に長く遅いクライムアップを開始する。ＴＣＰフローが、３ＤＵＰＡＣＫ高速再送信機構をイネーブルしていないと仮定すると、ここでのフローの送信レート又はスループット又はＣＷＮＤグラフは、繰り返される最大値までの既知の「鋸歯」パターン低速線形クライミング及びその後の「０」付近に戻る突然の下落を示す、すなわち、リンクの物理使用可能帯域幅の半分までが浪費され使用されていないことが、即座に明白であるが、変更されたＴＣＰフローは、ほぼ一定の１００％のリンクの物理使用可能帯域幅利用度の送信レート又はスループット又はＣＷＮＤグラフすなわち、未変更のＴＣＰフローのスループットの２倍までを示す／転送完了時間を半分にするはずである。３ＤＵＰＡＣＫ高速再送信機構がイネーブルされた状態で、ＴＣＰフローのグラフは、前の送信レートレベルの半分及び「０」付近への突然の下落の混成を示すはずであり、したがって、変更されたＴＣＰフローは、未変更のＴＣＰフローと比較して、３３％〜１００％だけより多いスループットの間のどこかを示すはずである→リンクの「見かけの」物理帯域幅を瞬間的に２倍にすることまでをおそらくはイネーブルした、ここで、リンクは、専用回線／大陸間海底光ケーブル／衛星／無線．．．などとすることができる。

要点を繰り返すと、上記の直前の段落の「大きいセンダのスケーリングされたウィンドウサイズ」法は（いずれかの端での接続が実際にそのような大スケールウィンドウサイズの実際の必要を有しない場合であっても）、ソフトウェア又は既存の標準ＴＣＰに対する変更を全く必要とさえせずに、ＰＣユーザによって即座に利用されることができる：ユーザは、彼らのＰＣのＴＣＰシステムパラメータを手動でセットし、大きいスケーリングされたセンダウィンドウサイズ（例えば、ＴＣＰＷｉｎｄｏｗＳｉｚｅ及び／又はｍａｘｇｌｏｂａｌＴＣＰＷｉｎｄｏｗＳｉｚｅ、Ｗｉｎｄｏｗ２０００では、ＴＣＰＷｉｎｄｏｗＳｉｚｅを６４Ｋバイトより大きくセットすると、ウィンドウスケールファクタが自動的にイネーブルされるはずである）、ＴＣＰ１３２３ｏｐｔ１又は３（１は、ウィンドウスケールファクタをイネーブルするがＴｉｍｅＳｔａｍｐオプションなしであり、３は、ＴｉｍｅＳｔａｍｐオプションを伴う）、１と２＾１４との間のＷｉｎｄｏｗＳｃａｌｅＦａｃｔｏｒ値をイネーブルすることができる。レシーバＴＣＰは、センダＴＣＰがウィンドウスケールオプションをネゴシエートすることを可能にしなければならないが、レシーバＴＣＰ自体の受信最大ウィンドウサイズは、ＩＰパケットによってトラバースされる経路の「ボトルネックリンクの帯域幅容量」を完全に利用できるようになるだけのために、好ましくは比較的小さく保たれなければならない（ここでのボトルネックリンクは、通常、センダのファーストマイル媒体、例えばＤＳＬ又はレシーバのファーストマイル、例えば専用回線のいずれかである）：例えば、この２つの端の間の非輻輳ＲＴＴが例えば１００ｍｓであり、全体を通して、この例えば１００ｍｓ値で完全に一定のままであり、ボトルネックリンクの帯域幅容量が２ｍｂｓであると仮定すると、ここでのレシーバ最大ウィンドウサイズは、比較的小さく、例えばわずか２５．６Ｋバイトまでに保たれ／セットされなければならない（これは、センダＴＣＰのＣＷＮＤが例えば２５．６Ｋバイトのレシーバの最大ウィンドウサイズをすばやく達成する／はるかに超えるために増大し、その後、この非常に大きいスケーリングされた最大ウィンドウサイズ値によって許容される非常に大きい値で完全に維持される場合であっても（これは、高速再送信を引き起こすパケットロス／破壊イベントが、今や、センダＴＣＰの半分にされたＣＷＮＤサイズ及び半分にされたＳｓｔｒｅｓｈ値にほとんどいつでも例えば２５．６Ｋバイトのレシーバの最大ウィンドウサイズの下まで急降下させないことを保証する）センダＴＣＰの「有効ウィンドウサイズ」がいつでも２５．６Ｋバイトを超えず、したがっていつでも２ｍｂｓより高いレートで送信しないことを保証する。センダＣＷＮＤサイズが例えば１ＳＭＳＳにリセットされたＲＴＯタイムアウト再送信を引き起こすパケットロスイベントの後には、非常により希に、センダＴＣＰのＣＷＮＤが、わずか５＊例えば１００ｍｓＲＴＴすなわちわずか５００ｍｓで例えば２５．６Ｋバイトのレシーバの最大ウィンドウサイズを非常にすばやく再達成し、これを超えることができる）。ここでの送信レートグラフ／瞬間スループットレートグラフ（Ｅｔｈｅｒｅａｌ’ｓＩＯ−Ｇｒａｐｈｓトラフィックディスプレイ分析ファシリティｈｔｔｐ：／／ｅｔｈｅｒｅａｌ．ｃｏｍを使用して見ることができる）は、ほぼ一定の１００％により近いリンク帯域幅利用度を示すはずである、すなわち、ここでのグラフは、１００％リンク利用度レベルからはるかにより遠い鋸歯の谷に平坦部を有する「鋸歯」形をほとんど一定不変に示す既存の標準ＴＣＰと比較して、１００％リンク利用度レベルにより近い最上部の平らな平坦部を有する「方形波信号形」に似るはずである。

しかし、現実の公衆インターネットでは、２つの端の間のＲＴＴは、エンドツーエンド接続のＲＴＴがキャリアのＩＰトランジットサービスレベル契約保証されたＲＴＴ／帯域幅によって保証されない限り、経時的に桁だけ（例えば数十ミリ秒から２００ｍｓに）変化する可能性があり、したがって、例えばレシーバ最大ウィンドウサイズ．．．などを介するボトルネックリンクの帯域幅容量へのセンダの送信レートのその「スロットリング」は、公衆インターネット上のそのようなＲＴＴが長くなる時に、そのような時間中に桁のスループット及び／又は「グッドプット」の劣化をこうむるはずである：そのような長くなる公衆インターネットのＲＴＴのシナリオに対処できるようになるために、ここでのレシーバの最大ウィンドウサイズにはるかに大きい値をセットすることがはるかによく、例えば、レシーバの最大ウィンドウサイズに、今、例えば８＊以前の例えば２５．６Ｋバイトがセットされる場合に、エンドツーエンドスループット及び／又は「グッドプット」は、ＲＴＴがこの２つの端の間の非輻輳ＲＴＴの８倍を超えて長くはならないと仮定して、いつでも１００％ボトルネックリンクの帯域幅容量の近くに維持することができる。

センダＴＣＰのＣＷＮＤが、安定し、増加していない時（例えば、ＣＷＮＤが、最大センダウィンドウサイズ値に達し終えている時）に、センダＴＣＰが送信できる量（ＴＣＰスライディングウィンドウ）を支配するのは、ＡＣＫセルフクロッキング機能である、すなわち、到着する戻るＡＣＫのレートに従ってであり、この戻るＡＣＫの最大レートは、やはり、トラバースされた経路のボトルネックリンクの帯域幅容量すなわち、センダからどれほど高速にボトルネックリンクに沿ってデータを転送できるかに制限され、これが、バイト毎秒単位でのボトルネックの帯域幅とほぼ等しい（非データＩＰパケットヘッダに必要な例えば４０バイトのオーバーヘッドを無視する場合に）ことに留意されたい。センダＴＣＰのＣＷＮＤが、「スロースタート」フェーズで指数関数的に増分し続ける時に、ＣＷＮＤは、実際に、各連続するＲＴＴ中に、戻るＡＣＫの個数に従って増分する（必ずしも各連続するＲＴＴ中に指数関数的に２倍にするのではなく）、すなわち、ＴＣＰの現在のＣＷＮＤが、８Ｋバイトであり、８Ｋバイトのデータセグメント（最大センダサイズ及び最大ウィンドウサイズによって許容され、十分な返されるＡＣＫを伴う十分な「有効ウィンドウ」．．．を仮定して）を送出し、次のＲＴＴで６つだけが返され、２つが捨てられる場合に、ＣＷＮＤは、「スロースタート」であると仮定して、今や、１４Ｋバイトに増分するだけ（１６Ｋバイトに２倍にされるのではなく）になるはずである。輻輳は、現在の増分されたＣＷＮＤサイズ（したがって、受信された戻るＡＣＫの個数の増加によって引き起こされるのではなく現在増やされている有効ウィンドウ）は、送信レートにボトルネックリンクの帯域幅容量によって転送できるものを超えさせるはずの値未満のままである限り、生じない。しかし、送信レートが、今、ボトルネックリンクの帯域幅容量の送信レートより大きい場合に、いくつかの送信されたパケットは、今、ボトルネックリンクでバッファリングされ始める（インターネットノードは、通常、約２００〜４００ｍｓと同等のバッファ容量を有する）。センダの送信レートが、ボトルネックリンクの帯域幅容量の送信レートと正確に一致する段階で、ＣＷＮＤが次のＲＴＴでサイズにおいて今や「２倍にされた」時に、ここでのＲＴＴが１００ｍｓ前後に留まると仮定すると、この、次のＲＴＴで、この余分の帯域幅容量を超える１００ｍｓと同等分のパケットは、ボトルネックリンクノードでバッファリングされることを必要とする。連続するＲＴＴでの戻るＡＣＫのレートが、今、最大ボトルネックリンクの帯域幅容量又はその前後に留まる（すなわち、ボトルネックリンクは、１００％リンクの帯域幅利用度でデータを転送し続ける）と仮定すると、センダのＣＷＮＤは、ボトルネックノードが今やバッファを使い果たし、したがってパケットを捨てさせる、例えば４番目の連続するＲＴＴまで、各続く連続するＲＴＴでボトルネックリンクの帯域幅容量と等しい量だけ連続して増分され、各連続するＲＴＴは、増分されたＣＷＮＤ（又は増分された有効ウィンドウ）によって導入される余分のバッファリングされるパケットトラフィックの連続する例えば１００ｍｓ同等量に起因して、直前のＲＴＴよりわずかに長い。次に、センダは、レシーバＴＣＰから３つのＤＵＰＡＣＫを受信した時に、捨てられたパケットを高速再送信する可能性が高く、その場合に、現在は半分にされているＣＷＮＤ及びＳＳｔｈｒｅｓｈ値さえもが、それでも、ほぼ一定不変に、相対的に小さいレシーバ最大ウィンドウサイズ値よりはるかに大きいままになる→したがって、センダＴＣＰは、その後、これらのパケットドロップイベントによって減らされない同一の以前のレートで送信し続けるはずであり、ＡＣＫがボトルネックリンクの帯域幅容量と等しいレートで戻るので、センダの送信レートは、今や、ボトルネックリンクの帯域幅容量（これが、レシーバの最大ウィンドウサイズ以下であると仮定して）と等しい正確な最大レートであり続けるはずである。センダが、まだレシーバの３ＤＵＰＡＣＫ高速再送信要求によって世話されていない場合に、最小１秒の既存ＲＦＣデフォルト最小時間期間の後に限って、捨てられたパケットのＲＴＯタイムアウト再送信も行うことができるが、これらが、非常にはるかに希であり：その場合に、センダのＣＷＮＤは、それでも、比較的小さいレシーバの最大ウィンドウサイズ値を再達成し／超えるために、わずか２〜３ＲＴＴで非常にすばやく指数関数的に増加するはずである（「任意の」大きいＳｓｔｈｒｅｓｈ値によって助けられて）ことに留意されたい。ここでのセンダのＣＷＮＤは、周期的な高速再送信がＣＷＮＤ及びＳｓｔｒｅｓｈ値を半分にするにもかかわらず、非常に大きい値まで「指数関数的に」増加する（「維持される」任意の大きいＳｓｔｈｒｅｓｈ値に向かう傾向がある）はずである。センダのＴＣＰのＣＷＮＤが、レシーバの最大ウィンドウサイズを達成し／超えたならば、そのＣＷＮＤは、その後、主に、戻るＡＣＫのセルフクロッキングレートの受信されたシェアになり、その総レートは、多くとも、どの時点でもボトルネックリンクの帯域幅容量と等しく、これは、今後、センダＴＣＰ送信レートを規定する。応答ＡＣＫを生成する際の他端のＴＣＰ応答変動は、戻るＡＣＫのレートをボトルネックリンクの帯域幅容量のレート未満まで減らす可能性があり、トラバースされる経路に沿った介在するノードでのバッファ遅延（ＲＴＴを長くする）．．．などは、ボトルネックリンクをトラバースするすべてのＴＣＰフローに対する総合的な戻るＡＣＫのレートを、ボトルネックリンクの帯域幅容量の１００％より少なく／未満まで減らす可能性がある（この故に、そのような変動について補償するのに十分に、ＴＣＰセッション全体で同一の非輻輳ＲＴＴを仮定してボトルネックリンクの帯域幅容量の１００％を完全に利用するために、レシーバの最大ウィンドウサイズをまさに必要な最小サイズより大きくなるようにセットすることは、そのような変動にかかわりない、常時１００％ボトルネックリンクの帯域幅利用度を可能にするはずである）。

ここで、センダの最大ウィンドウサイズ値及びＣＷＮＤ値をいつでも任意に大きくすることができ（「任意の」大きいＳｓｔｈｒｅｓｈ値によってそのように維持されて助けられる）を用い、比較的小さいレシーバ最大ウィンドウサイズ値を用いて、上記の本明細書の「要求されないが意図的な」大きいスケーリングされたセンダウィンドウサイズ及び比較的小さい「レシーバ最大ウィンドウ法」を利用するエンドツーエンドＴＣＰ接続が、ボトルネックリンクの帯域幅容量と等しい安定化された送信レートに向かう傾向がある、すなわち、ここでの送信レート又はスループットグラフが、１００％に近いリンク利用度レベル「方形波形」を示すはずであることがわかる。

ＦＴＰなどの従来のファイル転送テクノロジは、すべてのパケットロスに応答してデータレートを劇的に下げ、長期的スループットを高速リンクの容量で維持することができない。例えば、メトロポリタンエリアネットワーク内のＯＣ−３リンク（１５５Ｍｂｐｓ）を介する単一のＦＴＰファイル転送は、０．１％のパケットロスパーセンテージ及び１０ｍｓの待ち時間を仮定すると、２２Ｍｂｐｓで安定する。

我々は、ここで、センダのローカルインターセプトソフトウェアが、ローカルＭＳＴＣＰプリエンプトタイムアウト送信レート低下に対して３＋ＤｕｐＮｕｍ個のＤＵＰＡＣＫ（ＡＣＫＮｏ＝レシーバＴＣＰからの最新の受信されたＡＣＫ番号及び／又はＳｅｑＮｏ＝レシーバＴＣＰからの最新の受信されたＳｅｑＮｏフィールドを伴う）を生成するために、レシーバＴＣＰからセンダＴＣＰで受信された最新の到着するＡＣＫのＡＣＫパケット−リターン間インターバル＞例えば３００ｍｓ（必ずしも輻輳ドロップではなく、物理エラーによっても引き起こされ得る：我々はここで両方をキャッチする）をチェックするだけの単純なコードを追加することができる。送信されたパケットでの０．１％の物理エラー破壊（輻輳ではなく）であっても、８０％だけスループットを厳密に制限するはずであることが周知であり、ｈｔｔｐ：／／ｗｗｗ．ａｓｐｅｒａｓｏｆｔ．ｃｏｍ／ｔｅｃｈｎｏｌｏｇｙ−ｆａｓｐｖｆｔｐ．ｈｔｍｌ＃ｃｏｎｔｉｎｅｎｔａｌを参照されたい。

概要：
１．着信／発信パケットインターセプトコア及びＴＣＰフローごとのＴＣＢを組み込むことだけを必要とする。

２．ローカルＭＳＴＣＰからリモートに送信された最新の「最大の」ＳｅｑＮｏフィールド「ｌａｓｔｓｅｎｔＳｅｑＮｏ」を記録する。

３．リモートから受信された最新の「最大の」着信パケットのＡＣＫＮｏフィールド「ｌａｓｔｒｃｖＡＣＫＮｏ」（及びそのパケットのＳｅｑＮｏ、すなわち「ｌａｓｔｒｃｖＳｅｑＮｏ」）及び受信された時刻「ｌａｓｔｐｋｔｒｃｖｔｉｍｅ」と、この完全なパケットのコピー「ｌａｓｔｒｃｖｐｋｔ」とを記録する。

４．ＩＦ現在時刻−ｌａｓｔｐｋｔｒｃｖｔｉｍｅ＞例えば３００ｍｓＡＮＤｌａｓｔｓｅｎｔＳｅｑＮｏ＋１＞ｌａｓｔｒｃｖＡＣＫＮｏ
ＴＨＥＮ３つの「ｌａｓｔｒｃｖｐｋｔ」を送信する（より簡単であり、生成されたパケットのチェックサムを計算する必要がない：複製ＳｅｑＮｏ／複製データ．．．などは、ｌａｓｔｒｃｖｐｋｔ内に存在する場合に、３ＤＵＰＡＣＫ高速再送信を引き起こしている間にローカルＭＳＴＣＰによって無視されるだけである）。

５．ソフトウェア初期化の時に、ＴＣＰレジストリ（及び／又は任意選択で個々のアプリケーション自体のソケットごとのバッファサイズ）を編集し、すべての新しいＴＣＰが大きいウィンドウスケールファクタ１４及びＴＣＰＷｉｎｄｏｗサイズ６４Ｋ（すなわち、最大１ギガバイト）を要求するようにし、好ましくはＳＡＣＫをイネーブルし、好ましくはＤｅｌａｙ−ＡＣＫなし
［参考文献：ＧｏｏｇｌｅＳｅａｒｃｈ用語「ｓｅｔｓｏｃｋｅｔｂｕｆｆｅｒｏｖｅｒｒｉｄｅｌａｒｇｅｓｃａｌｅｗｉｎｄｏｗｓｉｚｅ」（又は類似する関連用語）、ｗｗｗ．ｐｓｃ．ｅｄｕ／ｎｅｔｗｏｒｋｉｎｇ／ｐｅｒｆ＿ｔｕｎｅ．ｈｔｍｌ、ｐｕｂｌｉｂ．ｂｏｕｌｄｅｒ．ｉｂｍ．ｃｏｍ／ｉｎｆｏｃｅｎｔｅｒ／ｐｓｅｒｉｅｓ／ｔｏｐｉｃ／ｃｏｍ．ｉｂｍ．ａｉｘ．ｄｏｃ／ａｉｘｂｍａｎ／ｐｒｆｔｕｎｇｄ／２３６５ａ８３．ｈｔｍ、ｗｗｗ．ｄｓｌｎｕｔｓ．ｃｏｍ／２ｋｘｐ．ｓｈｔｍｌ、ｈｔｔｐ：／／ｗｗｗ．ｃｅｓ．ｎｅｔ／ｄｏｃ／２００３／ｒｅｓｅａｒｃｈ／ｑｏｓ．ｈｔｍｌ、ｆｏｒｕｍ．ｊａｖａ．ｓｕｎ．ｃｏｍ／ｔｈｒｅａｄ．ｊｓｐａ？ｔｈｒｅａｄＩＤ＝５９６０３０＆ｍｅｓｓａｇｅＩＤ＝３１６５５５２、ｎｅｔｌａｂ．ｃａｌｔｅｃｈ．ｅｄｕ／ＦＡＳＴ／ｍｅｅｔｉｎｇｓ／２００２ｊｕｌｙ／ｒｅｌａｔｅｄＷｏｒｋ．ｐｐｔ、ｗｗｗ．ｎｃｎｅ．ｏｒｇ／ｒｅｓｅａｒｃｈ／ｔｃｐ／ｄｅｂｕｇｇｉｎｇ／ｆｉｒｓｔｐａｃｋｅｔｓ．ｈｔｍｌ）。

以上、これは、データストレージアプリケーションの要求を完全に満たす。

注：両端が大きいウィンドウスケールファクタ及び大きいウィンドウサイズをネゴシエートした状態で、フローごとのＴＣＰは、１０ＲＴＴ、例えば２．５秒以内に、ＣＷＮＤ値を例えば１０２４＊１５００バイトのＭＳＳすなわち１．５Ｍバイトまで非常にすばやく増加する。ソフトウェア生成（例えば、ＲＴＯタイムアウトをプリエンプトする）又はリモートからのいずれであれ、どの高速再送信要求の際にも、ＣＷＮＤの半分化及びＳＳＴｈｒｅｓｈにＣＷＮＤ／２をセットすることは、「有効ウィンドウ」を減らす効果を一切有することがなく、ＳＹＮＣ／ＳＹＮＣＡＣＫ／ＡＣＫの後のどの時にも、「有効ウィンドウ」は、必ず次のいずれかになる。

１．常時レシーバのアドバタイズされた受信ウィンドウサイズまでに制限される：レシーバは、通常、例えば１６Ｋバイトを有し、したがって、すべての後続パケットで、レシーバは、「１」の受信ウィンドウサイズ（１４位置スケールシフトされる＝１６Ｋバイト）をアドバタイズする → ローカルセンダの送信レートは、いつでも、必ず、この「１６Ｋ」のレシーバのアドバタイズしたウィンドウサイズに対するレートになり、ＡＣＫ固有のセルフクロッキング特性によって非常に効果的に「レートペーシングされる」（我々が過去２〜３日で非常に意識するようになったとおり）。注：ＣＷＮＤ及びセンダウィンドウサイズは、任意に大きくすることができ、輻輳制御においてさらなる役割を全く演じない（ＣＷＮＤがレシーバの最大ウィンドウサイズよりはるかに大きいサイズを達成すると！！！その後に、最大の可能な送信レートを使用可能ボトルネックリンクの帯域幅に調整するそのＡＣＫセルフクロッキング特徴、しかしもちろん、レシーバは、アドバタイズされるレシーバウィンドウサイズを動的に調整し続けて、センダの送信レートに対する制御をさらに働かせることができ、あるいは、センダ端に常駐するインターセプトソフトウェアが、任意選択として、着信パケットのレシーバウィンドウサイズを動的に変更して、送信するＭＳＴＣＰの送信レート／「有効ウィンドウ」に対する類似する制御を働かせることができる）。

又は
２．我々は、シエートされる両方のセンダの最大ウィンドウサイズに任意に大きいスケーリングされたウィンドウサイズ値（又は単に大きいスケーリングされない６４Ｋ、スケーリングされた２５６Ｋ．．．などの値）を意図的に過剰にセットし、レシーバの最大ウィンドウサイズはネゴシエーション中に例えば実際に要求される／必要になるものより４倍大きくなるように（最大デフォルト１６Ｋという通常要求される／必要になるサイズではなく、例えば６４Ｋ、２５６Ｋ．．．など）わずかに過剰にセットされ、その結果、センダのＣＷＮＤ及びＳＳｔｈｒｅｓｈ（通常はネゴシエートされるレシーバ最大ウィンドウサイズ値と同一にセットされる）は、ほぼ常に、頻繁な高速再送信半分化にかかわらず、非常にはるかにより大きい値（レシーバの比較的小さい実際のシステムリソースによって制約されたアドバタイズされたレシーバウィンドウサイズよりはるかに大きい値）を維持し、非常に効率的な１００％に近いボトルネックリンクの「利用度方形波形」を保証する：これを保証するのは、多くともボトルネックリンク回線レートでのみ戻って到着する戻るＡＣＫセルフクロッキングの最大の可能なレートである。というのは、ＣＷＮＤとセンダウィンドウサイズとの両方が今はほぼ一定不変に必ずいつでもトラバースされるボトルネックリンクの帯域幅容量の１００％を利用するために十分に高速なレートでセンダＴＣＰが送信できることを保証するために必要な特定のセンダウィンドウサイズ値より多数の桁だけ大きいからであり（これは、周知の帯域幅遅延積すなわち周知のＲＴＴ＊ウィンドウサイズの等式に関係付けられる）、さらに、ＣＷＮＤがレシーバのネゴシエートされたウィンドウサイズ値（上記の例えば６４Ｋ、２５６Ｋ．．．などの）より大きいサイズをすばやく達成した後に、本明細書のセンダＴＣＰは、その後、連続するＲＴＴ中のウィンドウサイズ増大を介してレシーバのネゴシエートされた最大ウィンドウサイズ（上記の例えば６４Ｋ、２５６Ｋ．．．などの）を超えて実際の「有効ウィンドウ」を増分することはせず、したがって、その後、戻るＡＣＫストリームを受信した時にさらなるパケットをクロックアウトし／送出するだけであるはずである（戻るＡＣＫの最大レートは、ここでは、必ず、ボトルネックリンクの帯域幅容量以内になるように制約される）。

注：上記のケース１と２との両方で、インターセプトソフトウェア（又はＴＣＰソースコード）は、リモートレシーバからの着信パケット内のレシーバウィンドウサイズフィールド値を、任意の必要なより小さい最大値（例えば最新の記録された最小戻るＡＣＫ間インターバル及び非輻輳ＲＴＴ／ＯＴＴ値又は推定値．．．などから動的に導出される、あるいは、ユーザがトラバースされるボトルネックリンクの帯域幅容量の以前の知識から特定の値を指定することができるのいずれか）になるように必ず変更することができ、したがって、センダＴＣＰの有効ウィンドウサイズがトラバースされるボトルネックリンクの帯域幅容量と一致するのに必要なサイズレベルを絶対に超えないことを保証することができる → 今は、動的なレシーバのアドバタイズされるウィンドウサイズフィールド値を制限するのにレシーバのシステムリソース制約に頼る必要がなく、センダとレシーバとの両方の最大ウィンドウサイズ値を、同一の任意に非常に非常に大きいスケーリングされたウィンドウサイズ値になるように両方とも一緒にネゴシエートすることができる。

注：我々は、センダのＣＷＮＤがｆｔｐのＴＣＰデータ転送チャネル確立時に最初から十分に大きい値又は非常に大きい値まで確かに増やされることをさらに保証してもよく／必要があり、さもなければ、このまさに初期ステージでの即座のパケットドロップは、センダのＳＳＴｈｒｅｓｈに現在の初期の非常に小さいＣＷＮＤ値の半分をセットさせる場合がある：これは、例えば、ある個数例えば１０個のまさに最初の初期に送信されるデータパケットを保管するインターセプトソフトウェアによって達成することができ、例えば１０個の受信されなかったパケットのいずれかのリモートレシーバへの実際の再送信を実行する（すなわち、リモートレシーバＴＣＰで受信されない欠けているパケットを検出するための、この時間の間の着信する戻るＡＣＫＮｏのチェック、及びローカルＭＳＴＣＰがＳｓｔｒｅｓｈ値を現在の初期の非常に小さいＣＷＮＤ値の半分にこの時にリセットするのを防ぐためのローカルＭＳＴＣＰに戻るそのような到着するパケットの破棄／変更／又は転送しないこと）。

注：センダのＴＣＰソースコードが直接変更のために使用可能である場合には、これは、はるかに単純になる：例えば、ここでは、Ｓｓｔｈｒｅｓｈ値が、今、任意の非常に大きい値に「永久的に」固定され、且つ／又は送信するＴＣＰの最大センダウィンドウサイズが、今、任意の非常に大きい値に「永久的」に固定され．．．などになるようにするためにソースコードを変更することだけが必要である（この目的を達成する多数の形がありえる．．．）。また、すべての方法／技法を、レシーバベースド制御（センダベースド制御ではなく）として働くように対応して変更することができる。

注：さらに、次の非常に基本的な形で、ソフトウェアを全く必要とせずに、上記の「方形波形」技法を手動で即座に利用することができなければならない。

１．大きいウィンドウスケール、大きいウィンドウ、ＳＡＣＫ、ＤｅｌａｙＡＣＫなしについて、それ相応に２つのＰＣのレジストリを手動でセットする
２．この２つのＰＣの間の大きいＦＴＰ
３．ここでのＦＴＰの送信レート／スループットグラフは、「一定の１００％に近いボトルネックリンクの利用度レベル方形波形」を示さなければならない。

我々は、さらに、観察された最新の最小の「記録された」戻るＡＣＫ間インターバルで通常のデータパケットを送出する最小パケット間遅延を追加し（例えばバイト毎秒（ボトルネックリンクの容量に対応しなければならない）に関して、この値を、さらに、例えば、例えば３００ｍｓおきに導出され／更新されるなどの直前の指定された前の時間インターバルからのみ導出し／更新することができる）、必要な場合にパケットをバッファリングしてもよい → 実際の輻輳ではなく不必要な過渡的輻輳パケットドロップに寄与する場合があるルータでの「バーストバッファリング」がない。

このインターセプトソフトウェアが、ＣＷＮＤの連続するＲＴＴ指数関数的増分から輻輳ドロップを引き起こすことが可能である（指数関数的に増分されたＣＷＮＤが、レシーバのアドバタイズされたウィンドウサイズ以下に留まり、例えば、以前に既にボトルネックリンクの帯域幅の１００％を利用しながらＡＣＫセルフクロッキングにかかわりなく送信レートを２倍にすることを可能にするが、一部のユーザは、実際の物理受信バッファサイズシステムリソースを実際に大きくなるようにセットすることさえできる）。

既存の「ポーズ」技法すなわち、「タイムアウト」の外部のすべての戻るＡＣＫに関する最新の最小の「記録された」戻るＡＣＫ間インターバル（ボトルネックリンクの容量に対応する）に関する「ポーズ」すなわち、指定されたインターバルが前の戻るＡＣＫ以降の新しい次の着信する戻るＡＣＫを受信せずに満了する（例えば、１．８＊最新の最小の記録された戻るＡＣＫ間インターバル）場合に、例えば同一の最新の最初の記録された戻るＡＣＫ間インターバルすなわち最小戻るＡＣＫ間インターバルと等しい期間の間、前方にリモートレシーバＴＣＰに次の保留中のインターセプトされたパケットを単純に転送しないことを組み込まなければならない → ここで、センダＴＣＰは、最初の送信のＡＣＫが１．８＊最新の最小の記録された戻るＡＣＫ間インターバル、例えば９０ｍｓの外で戻ることによってトリガされる「ポーズ」の前に、多くとも２つのパケット（それぞれは、送信の間の例えば５０ｍｓのレートペーシングされた最小の最小戻るＡＣＫ間インターバルである）を送信することだけができる → ソフトウェアは、それ自体では輻輳ドロップを引き起こさない＋外部インターネット上で増分展開可能＋ＴＣＰフレンドリ＋他のＴＣＰがパケットドロップを引き起こす時であっても達成された非輻輳レベル送信レートスループットを保つ（変動なし）。リモートレシーバＴＣＰへの転送を待っているインターセプトされたパケット及び／又はバッファに受信された時刻などのそのようなバッファリングされたパケットに関するさまざまな情報．．．などを保管するバッファを実施し、且つ、次に、例えば特定のバッファリングされたパケットのバッファキュー内での待ち時間が例えば１秒の標準ＲＦＣのデフォルト最小ＲＴＯ時間期間に達する場合にローカルＭＳＴＣＰへの３ＤＵＰＡＣＫ高速再送信要求を生成し（ローカルＭＳＴＣＰでのＲＴＯタイムアウトをプリエンプトするために）、さらに、キュー内のこの特定のバッファリングされたパケットを任意の最新の新しい「高速再送信された」パケットに置換することを、さらに必要とする可能性がある／行ってもよい。

注：既存の標準ＲＦＣのスライディングウィンドウ／ＡＩＭＤ機構．．．などのいずれをも必ずしも必要としない、及び／又は既存の標準ＲＦＣのスライディングウィンドウ／ＡＩＭＤ機構．．．などと共にインターセプトソフトウェア（及び／又は直接ＴＣＰソースコード変更）として並列に働く、代替ＴＣＰ輻輳制御機構は、「送信レートポーズ」技法と一緒に上記の直前の段落の到着するＡＣＫ間インターバル「送信レートペーシングされた」技法を組み込まなければならず（例えば次の戻るＡＣＫが前に到着したＡＣＫ以来の指定された時間期間の外で到着する際に、リモートレシーバへのパケット転送をポーズし／スキップするために）、例えば最新の連続するパケットの間の戻るＡＣＫ間インターバルの最新の値及び／又は特定のパケットの実際のＲＴＴ値又はＯＴＴ値（トラバースされる経路に沿った輻輳バッファリングの始まり、又はそれが全く存在しないことを非常によく示さなければならない）に従って調整して、ＭＳＴＣＰパケット生成レート（より高速の増分レート／より低速の減分レートでの転送のために使用可能にされる）の増分／減分のいずれかを行わなければならず、あるいは、既存の標準ＲＦＣＴＣＰのまさにそれ自体の既存ＡＩＭＤ機能を並列に利用しなければならない（ならびに／あるいはリモートレシーバに転送されるのを待っているパケットのバッファリング、及び／又は古いキューイングされたパケットのＲＴＯタイムアウトをプリエンプトするためのローカルＭＳＴＣＰへの３ＤＵＰＡＣＫ高速再送信要求生成、及び／又は戻るＡＣＫ間インターバル「送信／ポーズレートペーシング」技法をもたらすための、バッファ内でキューイングされた旧バージョンパケットを置換する最新の新しい再送信パケット及び／又はイベントリストの受信時刻／送信時刻情報及び／又はパケットごとのＲＴＴ／ＯＴＴ監視．．．などと一緒に）。周期的な指定された時間期間に、上記のスキーマは、トラバースされる経路のボトルネックリンクの帯域幅容量の最新の最良の推定値が、後に到着する最新の記録された最小の戻るＡＣＫ間インターバル値から継続的に更新されることを保証するために、２つ又は少数のパケットが、隣接したファーストマイルリンクの帯域幅によって許容できる可能な非常にすばやい連続で即座に次々に前方にリモートレシーバに転送するのに使用可能であることを保証することができる（例えば、２つ又は少数のパケットが、それらを一緒に前方に転送する前に使用可能になるまで待つ．．．など、実際のボトルネックリンクの帯域幅容量を、あるサイズのパケット毎秒ではなくバイト毎秒というより微細なレベルでさらに導出できることと、送信レートペーシング技法及び／又は送信レートポーズ技法を、前方に送信される保留中のパケットサイズの実際のサイズを知って、バイト毎秒というこの導出される共通のより微細な粒度を利用するように適合させることができることに留意されたい）。ここでのスキーマは、既存ＲＦＣのスライディングウィンドウ輻輳回避機構と異なる、ペーシングされた送信レートを増分／減分するそれ自体の考案されたアルゴリズムを利用することができる。ここでの送信レートは、同一の一定の１００％に近いボトルネックリンクの利用度レベル「方形波形」を示さなければならず、常に、送信レートは、１００％に近いボトルネックリンクの利用度レベルの前後の非常に狭い帯域内で発振する。

注：ここでのローカルインターセプトソフトウェアは、インターセプトソフトウェアの転送バッファパケットキュー内のパケットの個数がある個数又は総サイズを超える時などに、ローカルＭＳＴＣＰが新しいパケットを生成し／送出するのを一時的に「止める」（又はローカルＭＳＴＣＰのパケット送信レートを下げる）ために、ウィンドウサイズ更新パケットを生成するか、ローカルＭＳＴＣＰへのリモートレシーバＴＣＰからの着信パケット内のレシーバウィンドウサイズフィールド値を必要に応じて例えば「０」又は非常に小さい値に変更することができる。これは、ローカルＭＳＴＣＰでの最終的なＲＴＯタイムアウトを引き起こす場合がある過度の非常に大きいパケットキューの増加を防ぐ。
大きいＦＴＰ転送改善の定量化：単純化された。

最小５０％スループット改善（例えば、１ＭＢＳから１．５ＭＢＳへ、他の要因からのさらなるかなり大きい改善があるはずである）を達成するために、一定の周期的パケットロス（及び高速再送信）は、センダ送信レートが最大回線レートに達するまさにその瞬間に発生する。

（１）一定の周期的な１０００個おきに１個のパケットロスレート及び２００ｍｓのＲＴＴを仮定すると、最大ウィンドウサイズは、すべてを送信し、１秒に１０００個のパケットにレートをスロットリングするために、２００パケット（３００ｋバイト）である必要がある。

ＳＳｔｈｒｅｓｈ値は、一般に、連続的な高速再送信半分化に起因して、１／２＊最大ウィンドウサイズ（１００パケット又は３００ｋバイト）前後でさまよい、ＣＷＮＤは、最大帯域幅送信レートを再達成するために１００パケット（１５０ｋバイト）だけ増分する必要がある → １００ＲＴＴが必要（２０秒）。

最小リンクの帯域幅は、１０００個のパケットを２０秒で送信するために６００ｋｂ／ｓである必要がある（１０００＊１５００＊８／２０）。

（２）一定の周期的な１００個おきに１個のパケットロスレート及び２００ｍｓのＲＴＴを仮定すると、最大ウィンドウサイズは、すべてを送信し、１秒に１０００個のパケットにレートをスロットリングするために、２０パケット（３０ｋバイト）である必要がある。

ＳＳｔｈｒｅｓｈ値は、一般に、連続的な高速再送信半分化に起因して、１／２＊最大ウィンドウサイズ（１０パケット又は１５ｋバイト）前後でさまよい、ＣＷＮＤは、最大帯域幅送信レートを再達成するために１０パケット（１５ｋバイト）だけ増分する必要がある → １０ＲＴＴが必要（２秒）。

最小リンクの帯域幅は、１００個のパケットを２秒で送信するために６００ｋｂ／ｓである必要がある（１００＊１５００＊８／２）。

そのような「方形波形」ＴＣＰは、ＴＣＰフレンドリであるはずであり、ボトルネックリンクをトラバースするＴＣＰフローが、すべてそのような「方形波形」フロー又はそのような「方形波形」フローと既存の標準ＲＦＣＴＣＰフローとの混合物からなる場合には、すべてのそのようなフロー／すべてのそのようなフローの混合物への戻るＡＣＫの総合レート／総数は、それでも、トラバースされる経路のボトルネックリンクの帯域幅容量に対応するものを超えないものまでに制限されるはずである→そのような「方形波形」ＴＣＰフローは、外部インターネット上で増分的に展開され、他の既存の標準ＲＦＣのＴＣＰフロー及び／又はフローの混合物の「鋸歯」効果及び／又は公衆インターネット輻輳パケットドロップ及び／又はＢＥＲパケット破壊（ビットエラーレート）によって引き起こされるパケットドロップにもかかわらずその達成された送信レートを維持し／保持することができると同時に、すべてのそのような「方形波形」ＴＣＰフロー及び／又は他の既存の標準ＲＦＣのＴＣＰフローに対してＴＣＰフレンドリなままであることができる（注：新しいＴＣＰフローは、どの場合でも、ほとんど必ず、ネットワークノードバッファの容量を利用してその送信レート増大を開始することができる）。

変更されたＴＣＰを用いると、リンクのトラフィックがバッファリングされ始める場合に、それに対応するエコーされるＲＴＴは、今や、ある指定された被乗数＊特定のソース−デスティネーションの非輻輳ＲＴＴ値（特定のパケットサイズに関する、通常はシステムＭＴＵサイズ又はＭＳＳサイズによって決定される）を超えるはずであり、ソフトウェアは、今や、指定された「ポーズ」インターバルの間にＴＣＰごとのフローの送信を停止することができる → これは、すべてのトラバースされるノードのバッファが、この「ポーズ」インターバル中にこのＴＣＰごとのフローのバッファリングされたパケット（又は同等物）のすべてを即座にクリアされることを保証する → したがって、輻輳パケットドロップは決してない！しかし、常に、ＲＴＯタイムアウト及び１ＭＳＳへのＣＷＮＤリセットを引き起こす物理送信エラーの可能性がある（これは、非常に希であり、改善されたスループット性能に大きくは影響しない）が、我々は、センダＲＴＯタイムアウトイベントをプリエンプトする／センダの送信レート半分化又は「０」へのリセットをプリエンプトするために、我々の「レシーバベースド」パケット到着間技法及び３ＤＵＰＡＣＫ高速再送信法を、前の段落の「大きいスケーリングされたウィンドウサイズ」法と一緒に組み込むこともできる。

この故に、ここでのＴＣＰごとのフローは、一定不変に物理使用可能帯域幅の半分を浪費する「鋸歯」送信レート／スループットグラフを引き起こすために送信レートを下げる（１ＭＳＳへのＣＷＮＤリセット）ためにＲＴＯタイムアウトはしないはずであり、輻輳パケットドロップを避けるための送信レートの同等の必要な減少は、今や、「ポーズ」インターバルを介してもたらされるのみである → この送信レート／スループットグラフは、今や、ほとんどいつも１００％に近い利用度である物理帯域幅を示さなければならない。

変更されたＴＣＰを利用せずに上記の「鋸歯」現象をプリエンプトする代替の方法は、センダＴＣＰの最大送信ウィンドウサイズすなわちＴＣＰＷｉｎｄｏｗＳｉｚｅシステムパラメータ値（及び／又はさまざまな他の関連するパラメータ値）をセットし、その結果、センダＴＣＰの最大の可能な帯域幅遅延積（最大ウィンドウサイズ／ＲＴＴ）値が、絶対にリンクの物理帯域幅を超えず、したがって、このＴＣＰフローがその時にこのリンクを利用する唯一のフローであると仮定して、輻輳パケットドロップが存在し得ないようにすることである。適当な最大ＴＣＰＷｉｎｄｏｗＳｉｚｅ値を選択する時に、最大の許容されるサイズ（ＭＴＵ値又はＭＳＳ値によって決定される）のパケットが、トラバースされる経路に沿った最低帯域幅リンクに完全に出るのに要する有限の時間期間は、その特定のソース−デスティネーションの非輻輳ｐｉｎｇＲＴＴ（非常に小さい無視できるパケットサイズの）値に加算される必要があるはずであり、これは、帯域幅遅延積式で使用される最小ＲＴＴ値を我々に与える（実生活では、実際のＲＴＴ値は、さまざまなコンポーネント、例えばＣＰＵＡＣＫ生成処理．．．などによって導入される変動を考慮に入れると、より大きくなるはずである）：さらに、戻るＡＣＫが、おそらくは通常のデータパケットにピギーバックされて搬送される場合（例えば、レシーバがデータを対称に送信してもいる場合）に、戻る最大サイズのデータパケットの、戻りのトラバースされる経路に沿った最低帯域幅リンクに完全に出るための有限の時間は、やはり、帯域幅遅延積式で使用される最小ＲＴＴ値を我々に与えるために上記に加算される必要があるはずである。データパケットストリームが連続的であると仮定し、最大の許容されるサイズのデータパケットが、トラバースされる経路／戻り経路に沿った最低帯域幅リンクに出るのに要する有限の時間が、無視できる（すなわち、最低帯域幅リンクは、それでも、大きい帯域幅容量を有し、例えば、１５００バイトのデータパケットが２４０ｋｂｓの次の前方リンクに出るのに５０ｍｓを要するが、１５００バイトのデータパケットが５６ｋｂｓの次の前方リンクに出るのに約２５０ｍｓを要する：例えば５０ｍｓというソース−デスティネーションの非常に小さいバイトサイズのｐｉｎｇパケットＲＴＴについて、そのような出る時間は、最大ウィンドウサイズＴＣＰＷｉｎｄｏｗＳｉｚｅ計算で使用すべき最小ＲＴＴ値の計算を構成する値を支配する）と仮定すると、ＳｅｌｅｃｔｉｖｅＡｃｋｎｏｗｌｅｄｇｅｍｅｎｔオプションは、ここでの性能を高めるはずであり、ＤｅｌａｙＡｃｋｎｏｗｌｅｄｇｅｍｅｎｔオプションは、イネーブルされた場合であっても、実際の効果を一切有しない。

外部インターネット上での増分的に即座に展開可能なＴＣＰ変更
現在、標準ＲＦＣＴＣＰデータ転送スループットは、高い輻輳ドロップレート及び／又は高いＢＥＲレート（物理送信ビットエラーレート）を有する経路／ネットワーク上で、特に高いＲＴＴ値及び非常に大きい帯域幅経路を有する長距離ファットパイプネットワーク（ＬＦＮ）で、良好に動作しない。標準ＲＦＣＴＣＰの常に変動する固有のＡＩＭＤ（加法増加乗法減少）鋸歯送信波形は、物理リンク／ボトルネックリンクの帯域幅容量の０％と１００％をはるかに超える値との間で激しく変動し、これもパケットドロップ自体に寄与し得る。

現在、ＴＣＰは、３ＤＵＰＡＣＫ高速再送信要求又はＲＴＯ再送信タイムアウトを介して通知されるパケットロスイベントの際に、その輻輳ウィンドウＣＷＮＤサイズを半分にし、したがって、その送信レートを半分にする。現在、ＴＣＰは、ＢＥＲ効果など、パケットドロップイベントの輻輳関連でない原因を見分けることもできず、すべてのパケットロスイベントを経路／ネットワークの輻輳によって引き起こされたものとして扱う。

わずか１％の総ロスレートを有する経路が、達成可能なＴＣＰフローのスループットを半分にすることは、一般的な明確に文書化された現象である。ｈｔｔｐ：／／ｉｎｔｅｒｎｅｔｔｒａｆｆｉｃｒｅｐｏｒｔ．ｃｏｍからわかるように、アジアでの通常のロスレートは、５％〜４０％であり、北米では２％〜１０％である。

ここで、高いロスレートの経路／ネットワーク上の上で説明した欠点のすべてを完全に除去でき、外部インターネット上で増分的に即座に展開可能であり、ＴＣＰフローフレンドリとすることもできる、次の全般的な原理（又はそのステップ若しくはサブコンポーネントステップ／プロセス若しくはサブコンポーネントプロセスのさまざまな組合せ）に基づく、既存の標準ＲＦＣのＴＣＰＳＡＣＫに対する改善変更の概要を示す。

（１）３つのＤＵＰＡＣＫによって通知されるパケットドロップイベントの際に、本明細書の変更されたＴＣＰは、失われる／捨てられると通知された総セグメント／パケットに対応するバイト数だけ輻輳ウィンドウＣＷＮＤサイズを減らすことだけを必要とするはずである（着信ＤＵＰＡＣＫパケット（１つ又は複数）（半分にされたＣＷＮＤサイズを増やす／膨張させる高速再送信及び／又は後続の複数のＤＵＰＡＣＫをトリガする）ＡＣＫＮｕｍｂｅｒフィールドは、最初の失われたパケットのシーケンス番号を示すが、ＳｅｌｅｃｔｉｖｅＡｃｋｎｏｗｌｅｄｇｅｍｅｎｔフィールドは、順序はずれで成功して受信された連続するシーケンス番号のブロックを示す；すなわち、ＡＣＫＮｏと最小のＳｅｑＮｏＳＡＣＫされたブロックとの間の「欠けているギャップ（１つ又は複数）シーケンス」及びＳＡＣＫされたブロック自体の間の欠けているギャップ（１つ又は複数）ＳｅｑＮｏは、欠けている捨てられたギャップ（１つ又は複数）パケット（１つ又は複数）のシーケンス番号を、したがって、捨てられると示されるバイトの総数を我々に与える）。ところが、ＤＵＰＡＣＫ内の最大のＳＡＣＫＮｏは、成功して受信された最大のＳｅｑＮｏを示し、これは、変更されたＴＣＰのＣＷＮＤサイズをそれ相応に増分するのに任意選択で利用することができ（変更されたＴＣＰの最大の受信されたＡＣＫＮｏに、今、高速再送信及び／又は後続の複数のＤＵＰＡＣＫをトリガする第３ＤＵＰＡＣＫ内の最大の受信されたＳＡＣＫＮｏがセットされているかのように、しかし、ＣＷＮＤのサイズ／「有効ウィンドウ」サイズの増分に関する目的／効果だけのためであって、確かに、変更されたＴＣＰのスライディングウィンドウの左エッジを進める目的／効果のためでは全くない：すなわち、ＴＣＰのＡＣＫＮｏフィールドのエンドツーエンドセマンティクスは、それ以外の点では既存の標準ＴＣＰで指定されたままに完全に保たれなければならない）、したがって、着信ＡＣＫＮｏフィールドが既存の標準ＴＣＰの有効ウィンドウサイズ増分に対して有する効果に関して同一の形で、しかし、決してスライディングウィンドウの左エッジの前進（これは、「欠けているギャップ（１つ又は複数）ＳｅｑＮｏ」に、もはや、もう一度高速再送信される／ＲＴＯタイムアウト再送信されることのできる現在のウィンドウサイズ分のデータ内で保持されなくするはずである：ここで、受信されたＡＣＫＮｏの後続の増分は、ＣＷＮＤ／有効ウィンドウサイズを増分するのに利用される上記の最大のＳＡＣＫＮｏより小さい場合に、変更されたＴＣＰのＣＷＮＤ／有効ウィンドウサイズをもう一度増やす効果を有してはならないが、変更されたＴＣＰのスライディングウィンドウ左エッジを前進させる効果を有することに留意されたい）の効果に関してではなく、ＡＣＫされた時ではなくＳＡＣＫされた時に、変更されたＴＣＰによってネットワークにより多くのセグメント／パケットを送信／注入することを可能にする。

及び／又は
（２）第３のＤＵＰＡＣＫによって通知されるパケットドロップイベントの際に、本明細書の変更されたＴＣＰフローは、ネットワーク内の未解決の送信済みのフライトバイトの総数（すなわち、現在の第３ＤＵＰＡＣＫのＡＣＫＮｏと同一のＳｅｑＮｏを有するデータを搬送するパケットが送信された時と、同一のＳｅｑＮｏを有するこの現在の第３ＤＵＰＡＣＫの到着の時との間にネットワークに送信された、データを搬送するパケットであれデータを搬送しない制御パケットであれ、カプセル化／ヘッダを含む、すべての送信されたパケットの総バイト数）が、現在、次で計算されるものと同一の個数に調整され／その個数まで減らされることを保証することだけを必要とするはずである：高速再送信をトリガするこの特定の第３ＤＵＰＡＣＫのＲＴＴ中にネットワークに送信された送信済みフライトバイトの総数、すなわち、高速再送信をトリガする第３の戻るＤＵＰＡＣＫのＡＣＫＮｏと同一のＳｅｑＮｏを有するパケットの送信の時とこの特定の第３ＤＵＰＡＣＫの受信の時との間にネットワークに送信されたバイトの総数を、ｍｉｎＲＴＴをこの特定の第３ＤＵＰＡＣＫのＲＴＴで割ったものによって割った値である。

ｍｉｎＲＴＴは、ＴＣＰフローのエンドポイントの間の実際に全く輻輳していないＲＴＴの最新の推定値であり、したがって、輻輳ドロップノードをトラバースするすべてのフローが、すべて、調和して働くそのような変更されたＴＣＰフローである場合に、ここでのこの特定のノードは、その後、輻輳しない又は輻輳に近くならなければならない：ここでのｍｉｎＲＴＴは、単に、変更されたＴＣＰフローのこれまでに観察されたもののうちで最小の記録されたＲＴＴの値であり、このフローの実際の物理的非輻輳ＲＴＴの最新の最良の推定値として働くはずである（明らかに、フローの実際の物理的非輻輳ＲＴＴが既知であるか前もって供給される場合には、それを代わりに使用しなければならず、あるいは使用することができる）。

高速再送信をトリガするこの特定の第３ＤＵＰＡＣＫのＲＴＴ中にネットワークに送信された送信済みフライトバイトの総数、すなわち、高速再送信をトリガする第３の戻るＤＵＰＡＣＫと同一のＳｅｑＮｏを有するパケットの送信の時と、この特定の第３ＤＵＰＡＣＫの受信の時との間に送信された送信済みフライトバイトの総数は、送信されたパケットのＳｅｑＮｏと、ＴｉｍｅＳｅｎｔと、カプセル化／ヘッダを含むこのパケットのｔｏｔａｌ＿ｎｕｍｂｅｒ＿ｏｆ＿ｂｙｔｅｓとという３つ組フィールドからなる時間によって順序付けられたイベントエントリリスト（すなわち、ネットワークへの送信の順序に純粋に基づく）を維持することによって導出することができる。したがって、特定の肯定応答番号を有する第３ＤＵＰＡＣＫのＲＴＴ値は、この現在の第３ＤＵＰＡＣＫの現在の到着時刻−現在の第３の戻るＤＵＰＡＣＫと同一のＳｅｑＮｏを有するデータを搬送するパケットのＴｉｍｅＳｅｎｔとして導出することができる。総送信済みフライトバイト数は、戻る第３ＤＵＰＡＣＫと同一のＳｅｑＮｏを有するイベントリストのエントリとイベントリストのまさに最後のエントリとの間のすべてのエントリのすべてのｔｏｔａｌ＿ｎｕｍｂｅｒ＿ｏｆ＿ｂｙｔｅｓフィールドの合計として導出することができる。

このイベントリストのサイズは、第３ＤＵＰＡＣＫのＡＣＫＮｏ未満のＳｅｑＮｏを有するすべてのエントリを除去することによって、小さく保つことができる。

送信済み総フライトバイト数の計算の代わりの単純化された代替案は、現在の戻る第３ＤＵＰＡＣＫのＡＣＫＮｏと同一のＳｅｑＮｏを有するデータパケットの送信／受信の時の、送信された最大のＳｅｑＮｏ−受信された最大のＡＣＫＮｏとしてこれらを近似することである：これは、フライトデータセグメントバイトすなわち、カプセル化／ヘッダ／データを搬送しない制御パケットを含まないフライト中の純データセグメントの総数を与える。

第３ＤＵＰＡＣＫによって通知されるパケットドロップイベントの際にネットワーク内の未解決の送信済みフライトバイトの総数を調整し／減らすために既存の標準ＲＦＣのＴＣＰソースコードに対する変更を実施するさまざまな可能な形の中に、次のものがある。

．高速再送信をトリガするこの特定の第３ＤＵＰＡＣＫのＲＴＴ中にネットワークに送信された送信済みフライトバイトの総数すなわち高速再送信をトリガする第３の戻るＤＵＰＡＣＫのＡＣＫＮｏと同一のＳｅｑＮｏを有するパケットの送信の時とこの特定の第３ＤＵＰＡＣＫの受信の時との間にネットワークに送信されたバイトの総数を［この特定の第３ＤＵＰＡＣＫのＲＴＴでｍｉｎＲＴＴを割った値］で割った値を最も近いバイトに丸めたものと同一の数になるように輻輳ウィンドウすなわちＣＷＮＤサイズを減らすことを介して現在の「有効ウィンドウ」サイズを即座に減らす。これは、任意の新しい到着する戻るＡＣＫ（１つ又は複数）がネットワークに新しいパケットを「クロック」アウトできるようになる前に、輻輳ウィンドウＣＷＮＤサイズが、その以前のサイズを再達成するために適当な個数の後続の戻るＡＣＫによって増分されることを必要とするので、適当な個数の後続の戻るＡＣＫが、もはや、ネットワークに新しいパケットを「クロック」アウトするという効果を有しなくなることをもたらすはずである：ここで新しいパケット（１つ又は複数）を「クロック」アウトできるようになる前に必要な戻るＡＣＫの個数は、ＣＷＮＤがそれだけ減らされたバイト数と同一個数のバイトを肯定応答するのに必要な戻るＡＣＫの個数になるはずであり、あるいは、通常はそれに対応する。

．代替案では、上記の減少プロシージャの代わりに、ここでのＣＷＮＤが、到着する第３ＤＵＰＡＣＫのＲＴＴ／ｍｉｎＲＴＴ＊この到着する第３ＤＵＰＡＣＫによって肯定応答される送信されたセグメントバイトの個数を最も近いバイトに丸めるか分数を繰り越したものという比率で増分されるだけになる（通常の標準ＲＦＣのＴＣＰの、到着する新しいＡＣＫによって肯定応答される送信されたセグメントバイトの個数による増分ではなく）：これは、減少が達成されるまで、すべての後続の複数の同一の又は増分されたＡＣＫＮｏのＤＵＰＡＣＫ又は新しいＡＣＫについて継続され、減少が達成された時には、この減少プロセスは停止する。一部のより古いＴＣＰ実施態様は、到着する新しいＡＣＫによって肯定応答される送信されたセグメントバイトの個数による増分ではなく、各到着する新しいＡＣＫについて１ＳＭＳＳだけＣＷＮＤを増分する場合があり、この場合に、この減少プロセスは、その代わりに、すべての他のＲＴＴ／ｍｉｎＲＴＴ個の受信された到着するＡＣＫについて１回だけの１ＳＭＳＳだけのＣＷＮＤの増分のみによってもたらすこともできる（ＤＵＰＡＣＫであれ新しいＡＣＫであれ、しかし、最も近い整数に丸められ、例えば、ＲＴＴ／ｍｉｎＲＴＴ＝２．５の場合には、すべての５つの到着する新しいＡＣＫについて、２つだけＣＷＮＤを増分することができる）。これは、フライトバイト減少プロセスを平滑化するという効果を有し、したがって、このフライトバイト減少プロセス全体を通じた、新しいパケットの適当に減らされた連続的な送信及び受信が、それでもある。

ＲＴＯタイムアウト再送信によって引き起こされる輻輳ドロップ（１つ又は複数）通知イベントは、次の形で扱うことができる。

．上で説明した、第３ＤｕｐＡＣＫ又は後続のまさに同一のＡＣＫＮｏの複数のＤＵＰＡＣＫと同一の形で扱う、すなわち、フライトバイトの減少プロセスに、バッファリングされたレジデンシパケット（ｒｅｓｉｄｅｎｃｙｐａｃｋｅｔ）を除去させるが、ＣＷＮＤサイズのリセット／減少は行わせない。

又は
．既存の標準ＲＦＣ仕様と正確に同一の形で扱う、すなわち、ＣＷＮＤを１ＳＭＳＳにリセットし、スロースタート指数関数的増分に再入する：しかし、ここで、本明細書の変更されたＴＣＰではＳｓｔｈｒｅｓｈ値が一度も半分にされていないはずなので、スロースタートが、初期Ｓｓｔｈｒｅｓｈ値（どの連続する高速再送信イベントによっても減らされていない）までもう一度すばやく増加することに留意されたい。

さらに、例えば未変更の同一のＡＣＫＮｏを有する後続の複数のＤＵＰＡＣＫ、新しい増分されたＡＣＫＮｏを有する第３ＤＵＰＡＣＫ（又は、例えば高速再送信をトリガする第３ＤＵＰＡＣＫなしのＴＣＰ再送信によって検出される、ＲＴＯタイムアウト再送信さえ）などの後続の輻輳ドロップ通知イベントは、新しい計算がより大きい減少を必要としない（すなわち、より小さい総フライトバイトをもたらすことを必要としない）場合には、既存の「フライトバイト減少」プロセス／プロシージャを完了することを可能にしなければならず、そうでない場合には、この新しいプロセス／プロシージャは、任意選択として引き継ぐことができる（また、その代わりに、特定の「マークされた」ＳｅｑＮｏが返されること及びその後にこのＲＴＴ中に輻輳ドロップ通知イベント（１つ又は複数）があったかどうかをチェックすることに基づいて、そのようなプロセス／プロシージャがＲＴＴごとに１回だけ開始することを可能にすることができる）。

本明細書の変更されたＴＣＰは、輻輳ドロップ（１つ又は複数）イベント通知を引き起こす特定の戻りＡＣＫ（又はＲＴＯタイムアウト再送信の直前の戻りＡＣＫ）のＲＴＴを導出することができるので、変更されたソフトウェアは、さらに、上と同一のイベントが実際に「誤った」輻輳ドロップ（１つ又は複数）通知であったかどうかを見分け、そうである場合に異なって反応することができる：すなわち、特定の輻輳ドロップ（１つ又は複数）イベント通知に関連するＲＴＴが、エンドポイントの最新の推定された非輻輳ＲＴＴと同一である（又は既知／前もって供給される）か、ミリ秒単位の単一ノードの最小バッファ容量同等物の境界内のある指定された変動量だけ異なるのではない場合に、この特定の輻輳ドロップ（１つ又は複数）通知を、そうではなく物理送信エラー／破壊／ＢＥＲ（ビットエラーレート）から生じるものとして正しく扱うことができ、変更されたソフトウェアは、フライトバイト減少プロセスを引き起こす／これに入ることを全く必要とせずに、通知された捨てられたセグメント／パケットを単純に再送信することができる。

ここでは、既存の標準ＲＦＣのＴＣＰと異なって、本明細書の変更されたＴＣＰが、新しい第３ＤＵＰＡＣＫ／新しい第３ＤＵＰＡＣＫに続く同一ＡＣＫＮｏの複数のＤＵＰＡＣＫ及び／又はＲＴＯタイムアウト再送信によって引き起こされる輻輳ドロップ（１つ又は複数）通知イベントの際にＣＷＮＤサイズを減らす／半分にする／リセットすることを必ずしも自動的に必要とはしない：本明細書の変更されたＴＣＰは、未解決のフライトバイトの個数を適当に導出された値まで減らすために、輻輳ドロップ（１つ又は複数）通知イベント（１つ又は複数）の際に、必ずＣＷＮＤサイズを適当に減らすことだけを必要とすることに留意されたい。

すべてのボトルネックリンクが、いつでも、ボトルネックノードでのバッファレジデンシ占有レベル及び／又は輻輳ドロップ（１つ又は複数）発生に関わりなく、送信されたパケットを、そのボトルネックの物理回線レートでレシーバＴＣＰに向かって継続的に転送するはずである→したがって、すべてのセンダＴＣＰで受信される戻るＡＣＫに関連するＲＴＴ期間（１つ又は複数）中に肯定応答されるすべてのバイトの合計は、ボトルネック帯域幅が十分に利用される場合に、いつでも、ほぼ一定不変にボトルネックリンクの物理帯域幅と等しくなるはずであることに留意されたい。また、ＴＣＰの輻輳回避アルゴリズムは、輻輳ドロップ（１つ又は複数）通知イベント（１つ又は複数）時にＣＷＮＤサイズ半分化によって引き起こされる既存の標準ＲＦＣＴＣＰの著しい低い利用度ではなく、帯域幅利用度をできる限りボトルネック（１つ又は複数）のリンク帯域幅の１００％近くに保つように努力しなければならないことに留意されたい。さまざまな異なるフライトバイト減少レベル／減少量／減少比／アルゴリズムを、考案することができ、例えば輻輳ドロップ（１つ又は複数）通知イベント（１つ又は複数）及び／又はそのようなヒストリカルイベントの時の最大の受信されたＡＣＫＮｏ及び／又は最大の送信されたＳｅｑＮｏ及び／又はＣＷＮＤサイズ及び／又は有効ウィンドウサイズ及び／又はＲＴＴ及び／又はｍｉｎＲＴＴ．．．など（例えば、変更されたＴＣＰフローのすべてのバッファレジデンシパケット／「余分な」バッファリングされたフライトバイトを完全にクリアするのではなく、バッファレジデンシ占有のある許容されるレベルを考慮に入れることなど）のさまざまな他のパラメータに基づくものとすることもできる。

及び／又は
（３）インターネット上のＴＣＰ接続の物理ボトルネックリンクは、通常、レシーバＴＣＰのラストマイル伝送媒体又はセンダＴＣＰのファーストマイル伝送媒体のいずれかである：これらは、通常は、５６Ｋｂｓ／１２８ＫｂｓＰＳＴＮダイヤルアップ又は通常の２５６Ｋｂｓ／５１２Ｋｂｓ／１Ｍｂｓ／２ＭｂｓＡＤＳＬリンクである。これらの状況で、センダＴＣＰの送信レートがどれほど速いかに関わりなく（既存の標準ＲＦＣのＴＣＰは、各後続ＲＴＴでますます増加するより大きいバイトを注入することによって経路の帯域幅を不可避的に継続的にプロービングし、スロースタート中にＣＷＮＤを指数関数的に２倍にするか、輻輳回避中にＣＷＮＤを線形に増分するかのいずれかを行う）、ボトルネックリンクは、すべてのフローのトラフィックを、その帯域幅によって制限される最大回線レートで転送することだけができる → 現在のボトルネックリンクの回線レートを超えて送信レートを増やすこと（現在のボトルネックリンクは、ネットワークのトラフィックに応じて時々変化する場合がある）は、ボトルネックリンクの物理回線レートを超えるＴＣＰフロー（１つ又は複数）のより高いスループットをもたらさない。したがって、ここでのＴＣＰを、ボトルネックリンクの最大の可能な物理回線レートより高いレートで送信しないように有利に変更することができる。ボトルネックリンクの最大の可能な物理回線レートより高いレートで送信することは、各ＲＴＴ中に送信されるパケット／バイトの「余分な」ボトルネック物理回線レートを超える量を、ＴＣＰフローの２つの端点に沿ったどこかで不可避的にバッファリングさせるか捨てさせるだけである。

ここに、経路のボトルネックリンクの物理帯域幅を判定する、複数の可能なものの中の例のプロシージャがある：
．連続するＲＴＴ値を、たやすく導出することができる。というのは、既存の標準ＲＦＣＴＣＰが、既に、各連続するＲＴＴ期間について特定のＳｅｑＮｏを有する「マークされた」ＴＣＰパケットに基づいて、連続するＲＴＴ値の計算／導出を実行しているからである。

．各連続するＲＴＴのスループットレートは、この特定の「マークされた」ＳｅｑＮｏパケットのＲＴＴ中にネットワークに送信された送信済みフライトバイトの総数すなわち、この特定の「マークされた」ＳｅｑＮｏを有するパケットの送信の時とその戻るＡＣＫ（又はＳＡＣＫｅｄ）の時との間に送信された送信済みフライトバイトの総数をまず記録し又は導出することによって導出することができ、この総数は、送信されたパケットのＳｅｑＮｏと、ＴｉｍｅＳｅｎｔと、カプセル化／ヘッダを含むこのパケットのｔｏｔａｌ＿ｎｕｍｂｅｒ＿ｏｆ＿ｂｙｔｅｓとという３つ組フィールドからなる時間によって順序付けられたイベントエントリリスト（すなわち、ネットワークへの送信の順序に純粋に基づく）を維持することによって導出することができる。したがって、特定のＳｅｑＮｏを有する特定の「マークされた」パケットのＲＴＴ値は、この現在の戻るＡＣＫ（又はＳＡＣＫｅｄ）の現在の到着時刻−特定の「マークされた」ＳｅｑＮｏを有するデータを搬送するパケットのＴｉｍｅＳｅｎｔとして導出することができる。総送信済みフライトバイト数は、戻る第３ＤＵＰＡＣＫと同一のＳｅｑＮｏを有するイベントリストのエントリとイベントリストのまさに最後のエントリとの間のすべてのエントリのすべてのｔｏｔａｌ＿ｎｕｍｂｅｒ＿ｏｆ＿ｂｙｔｅｓフィールドの合計として導出することができる。このイベントリストのサイズは、第３ＤＵＰＡＣＫのＡＣＫＮｏ未満のＳｅｑＮｏを有するすべてのエントリを除去することによって、小さく保つことができる。送信済み総フライトバイト数の計算の代わりの単純化された代替案は、第３ＤＵＰＡＣＫの到着の時の、送信された最大のＳｅｑＮｏ＋この最大のＳｅｑＮｏのパケットのデータバイトの個数−受信された最大のＡＣＫＮｏとしてこれらを近似することである：これは、フライトデータセグメントバイトすなわち、カプセル化／ヘッダ／データを搬送しない制御パケットを含まないフライト中の純データセグメントの総数を与える。

その代わりに、特定の「マークされた」ＳｅｑＮｏを有するパケットの送信の時とその戻るＡＣＫ（又はＳＡＣＫｅｄ）の時との間に送信された送信済みフライトバイトの総数の近似及び／又は単純化として、各連続するＲＴＴのスループットレート計算／導出を、特定の「マークされた」パケットのＳｅｑＮｏ＋特定の「マークされた」パケットのバイト単位のデータペイロードサイズ−特定の「マークされた」ＳＥＱＮｏパケットが送信された時の受信された最大のＡＣＫＮｏに基づくものとすることができる。

ここでのＲＴＴのスループットレートは、この故に、ＲＴＴ期間中にネットワークに送信された送信済みフライトバイトの上で導出された総数／このＲＴＴ値（秒単位）として計算することができる。

．すべてのＲＴＴで達成された最大のスループットレート値のレコードが、保持され、継続的に更新され、以下ではｍａｘＴと称する。以下でＲＴＴ＿ｍａｘＴと称する、最大のスループットレートｍａｘＴが達成された期間に関連するＲＴＴ値も、以下でＩｎ＿Ｆｌｉｇｈｔｓ＿ＢＹＴＥＳ＿ｍａｘＴと称する、最大のスループットレートｍａｘＴが達成された期間に関連する送信済みフライトバイトの総数と一緒に記録される。

．任意のＲＴＴ期間内のスループットレート＜＝ｍａｘＴすなわち、このＲＴＴ期間内のスループットレートが＞ｍａｘＴにならない時に必ず、且つ、ＩＦ［このＲＴＴ期間中のフライトバイトの総数／Ｉｎ＿Ｆｌｉｇｈｔｓ＿Ｂｙｔｅｓ＿ｍａｘＴ］＞［この期間中のミリ秒単位のＲＴＴ値／ミリ秒単位のＲＴＴ＿ｍａｘＴ］ＴＨＥＮボトルネックリンクの物理帯域幅容量又は回線レートが、今や、導出され／入手される。ここでの原理は、このＲＴＴ期間内のフライトバイト数が、例えばｍａｘＴ期間に関連するフライトバイト数の２倍であり、この期間のＲＴＴ値が、例えばＲＴＴ＿ｍａｘＴと同一（又はその２倍未満）のままである場合に、このＲＴＴのスループットレートがｍａｘＴを超えない理由は、ｍａｘＴが既にボトルネックリンクの物理帯域幅容量／回線レートと既に同一であるからであり、したがって、このＲＴＴ期間中のさらに多くのフライトバイト及びこのＲＴＴ値が不釣り合いに増加はしなかったにもかかわらず、ボトルネックの回線レートで制限されているこのＲＴＴ内のスループットレートが、ｍａｘＴを超えて増加しないからである。このテスト式に、数学的分散許容値、例えばＩＦ［このＲＴＴ期間中のフライトバイトの総数／Ｉｎ＿Ｆｌｉｇｈｔｓ＿Ｂｙｔｅｓ＿ｍａｘＴ］＞［この期間中のミリ秒単位のＲＴＴ値／ミリ秒単位のＲＴＴ＿ｍａｘＴ］＊分散許容値（例えば、１．０５／１．１０．．．など）を含めることができる。

．真のボトルネックリンクの物理帯域幅容量／回線レートが導出され／入手されたならば（＝ｍａｘＴ）、変更されたＴＣＰは、もはや、不必要な輻輳パケットドロップ及び／又はバーストパケットドロップを引き起こそうと一定不変に努力する既存ＲＦＣ標準ＴＣＰのＲＴＴごとのスロースタート指数関数的ＣＷＮＤ増分／輻輳回避線形ＣＷＮＤ増分のようにアグレッシブに経路の帯域幅について継続的にプローブすることはできない。ここで、変更されたＴＣＰは、その後、すべての後続の次のＲＴＴ期間内のＣＷＮＤサイズ（任意選択として及び／又は有効ウィンドウサイズ）のすべての後続の増分を、［ｍａｘＴ（今はボトルネック回線レートと等しい）が達成される時のｍａｘＴに関連するＣＷＮＤサイズ（任意選択として及び／又は有効ウィンドウサイズ）＊（ミリ秒単位の最後の以前のすなわち最新のＲＴＴ値／ミリ秒単位のＲＴＴ＿ｍａｘＴ）の５％を超えないように制限することができる。非常に可能性は低いが、いずれかの後続ＲＴＴでのスループットレートが、ｍａｘＴより大きくなる場合には、ｍａｘＴが更新され、ボトルネック回線レート判定プロセスが、もう一度繰り返される。したがって、変更されたＴＣＰは、ボトルネックリンクをその回線レートでビジーに保つのに必ず必要なものを超えて、不必要にアグレッシブにＣＷＮＤサイズ及び／又は有効ウィンドウサイズを増分して輻輳ドロップ及び／又はバーストパケットドロップを引き起こすことはしない。

代替案では、変更されたＴＣＰは、任意選択として、そのパケット生成／ネットワークへのパケット送信をレートペーシングすることができる、すなわち、変更されたＴＣＰは、ｍａｘＴボトルネック回線レートで：例えば、ｍａｘＴがボトルネックの真の回線レートを達成した／これと等しくなった後には最小Ｉｎｔｅｒ−Ｂｙｔｅｓ＿ｆｏｒｗａｒｄｉｎｇ＿Ｉｎｔｅｒｖａｌ＝（１／（ｍａｘＴ／８））をセットし、そうでない場合には、任意選択として、最小Ｉｎｔｅｒ−Ｂｙｔｅｓ＿ｆｏｒｗａｒｄｉｎｇ＿Ｉｎｔｅｒｖａｌ＝（１／（ｍａｘＴ／８））＊２をセットする（この時のＣＷＮＤ増大が、多くとも前のＲＴＴ期間のＣＷＮＤを指数関数的に２倍にするはずなので）ことによって、パケットを生成する／パケットを送信するのみである。

．さらに、任意選択として、変更されたＴＣＰは、「余分な」フライトバイトのクリア及び／又は輻輳ドロップ（１つ又は複数）通知イベント（１つ又は複数）の際の説明された捨てられたパケットに関する適当なレート減少の対象となる、戻るＡＣＫ（又はＳＡＣＫｅｄ）レートによって許容される／「クロック」アウトされるパケット生成／パケット送信レートではなく、パケット生成／パケット送信レートが常に対応するｍａｘＴレートであることを保証することができる（ｍａｘＴが、ボトルネックの真の回線レートと等しいレートを既に達成していようと、単に最新の最大のｍａｘＴであろうと）：すなわち、変更されたＴＣＰは、任意選択として、フライトバイトをクリアする／減らすために適当なレート減少をもたらすこと及び／又は捨てられたパケットの個数に対応してレートを減らすこと（例えば、輻輳ドロップ通知イベント（第３ＤＵＰＡＣＫ及び／又は後続の複数の同一ＡＣＫＮｏのＤＵＰＡＣＫ及び／又はＲＴＯタイムアウト再送信とすることができる）の際に、同等ビット毎秒単位でのパケット生成／送信レートを、例えばｍａｘＴ＊ｍｉｎＲＴＴ／この期間のＲＴＴ値又はｍａｘＴ−このＲＴＴ中に捨てられたバイト数＊８まで減らす）を要求されない限り、最新のＡＣＫ（又はＳＡＣＫｅｄ）戻るレートによって制限されない制限されない最新のｍａｘＴレートでパケットを生成する／送信するようにされる。

既存ＴＣＰソースコードを直接には変更しない実施態様：
ＴＣＰソースコードを直接に変更せずに、直前の段落で説明された発明を、独立のＴＣＰパケットインターセプトソフトウェア／エージェントとして実施することができ、ここで、このソフトウェアは、１スライディングウィンドウ分の転送されるすべての送信されたデータセグメントのコピーを保持し、すべての高速再送信及び／又はＲＴＯタイムアウト再送信、及び／又はローカルＴＣＰから／に向かうインターセプトされたパケットの前方への転送のレートペーシング（ｍａｘＴ値に従う）すなわち輻輳ドロップ通知イベント時の転送レート調整プロセスを実行する。

ここに、純粋に、改善でき／／変更できる必要なステップの概要を提供するための、そのような実施態様の概要がある。さらに、すべての洗練された詳細なアルゴリズム的／コーディングステップは、純粋に、例示的概要のためのみであり、且つ、改善する／変更することができる：
．インターセプトソフトウェアは、ＴＣＰから来る／ＭＳＴＣＰ宛の各すべてのパケットをインターセプトする。

．ソフトウェアは、すべてのデータペイロードを搬送するパケットのコピーを、上昇するＳｅｑＮｏに従って明確に順序付けられたリストエントリ内で維持する。

．第３ＤＵＰＡＣＫ通知の際に、ソフトウェアは、第３ＤＵＰＡＣＫ及び同一ＡＣＫＮｏの後続の複数ＤＵＰＡＣＫと同一のＳｅｑＮｏを有するリスト上のデータペイロードパケットコピーエントリからの高速再送信を実行する。ソフトウェアは、ＤｕｐＮｕｍと同一のＡＣＫＮｏ値のＤＵＰＡＣＫ（１つ又は複数）の累積個数を記憶し、さらに、ＳｅｌｅｃｔｉｖｅＡｃｋｎｏｗｌｅｄｇｅｍｅｎｔフィールド内の「ギャップ（１つ又は複数）」によって示されるすべての捨てられたパケットを高速再送信する。ソフトウェアは、各すべてのＤＵＰＡＣＫ（１つ又は複数）のＡＣＫＮｏを、このパケット（１つ又は複数）のＡＣＫＮｏ値をＡＣＫＮｏ−ＤｕｐＮｕｍ＊例えば１５００まで減分することによって変更し、したがって、ＴＣＰは、絶対に、同一のＡＣＫＮｏを有するＤＵＰＡＣＫを全く受信しない → ＴＣＰは、高速再送信に起因してＣＷＮＤサイズを絶対に減らさない／半分にしない（これは、現在はソフトウェアによって世話される）。ソフトウェアは、どのＣＷＮＤサイズ値も減らさない（このパラメータは、ソフトウェアによってアクセス可能ですらない）。

．ソフトウェアは、前に説明した全般的な原理で概要を示した原理／プロセス／プロシージャ又はその組合せ／サブコンポーネントを組み込む。

さらに、
．ソフトウェアは、ＭＳＴＣＰの代わりにＲＴＯタイムアウト再送信を完全に実行することすらできる（ヒストリカルな戻るＡＣＫのＲＴＴ値からのＲＴＯ計算を組み込むことによって）：したがって、ソフトウェアは、転送のためにＴＣＰからパケット（１つ又は複数）を受信した時に、即座にすべての単一のパケットの「ＡＣＫをスプーフィング」することができる → ＴＣＰは、今は、ＲＴＯタイムアウト再送信を行うことすらしない。ソフトウェアは、さらに、ＴＣＰパケット生成レート／ＴＣＰパケット送信レートを制御する技法として、ＴＣＰからパケット（１つ又は複数）を受信する時にＡＣＫのスプーフィングを「遅延させる」ことができる。

．ＴＣＰのＣＷＮＤサイズ／有効ウィンドウサイズを変更するのではなく（ソフトウェアからアクセス可能ですらない）これは必要な本質的な要求される特徴ではないが、ソフトウェアは、その代わりに、ソフトウェア自体の中で「ミラーＣＷＮＤ機構／ミラー有効ウィンドウ機構」をシミュレートするか、あるいは、その代わりに、例えばｌａｒｇｅｓｔＲｃｖＡＣＫＮｏ、ｌａｒｇｅｓｔＳｅｎｔＳｅｑＮｏなどの他のパラメータ値を制御する／調整するためのレートペーシング、その減算差が必要なサイズになることを保証すること．．．などを介するフライトバイトの減少などの他の同等の形で同等の効果を与えるかのいずれかを行うことができる。

．ソフトウェアは、既存の標準ＲＦＣで定義された、各すべてのインターセプトされたパケットに対するチェックサム検証、ＳｅｑＮｏラップアラウンド検出及び比較、タイムスタンプラップアラウンド検出及び比較．．．などのさまざまな標準ＴＣＰ技法をも実施することができる。

ここに、純粋に例示のみのための、さらに訂正し／改善し／変更し且つ／又は完全に異なって設計することができる、ソフトウェア設計に関するいくつかの単純な概要がある。

１．純粋なインターセプト転送：
２．＋チェックサム＋ラップアラウンド：
３．＋同一のＤＵＰＡＣＫＮｏについて１回だけの、同一のＤＵＰＡＣＫされたパケットコピーだけの高速再送信：
４．＋同一のＤＵＰＡＣＫＮｏについて１回だけの、すべてのパケットコピーの高速再送信：
５．＋同一ＡＣＫＮｏのＤＵＰＡＣＫについて１回だけの、最大のＳＡＣＫされた「ギャップ（１つ又は複数）」までのすべてのパケットコピーのみの高速再送信：
６．＋各ＤＵＰＡＣＫでの、最大のＳＡＣＫされた「ギャップ（１つ又は複数）」までで＞ＬＡＲＧＥＳＴＲＴＸＳＥＱＮｏのすべてのパケットコピーだけの高速再送信：（ソフトウェアが各後続の同一ＡＣＫＮｏのＤＵＰＡＣＫ及び／又は新しい増分されたＡＣＫＮｏのＤＵＰＡＣＫについて不必要に複数回繰り返して高速送信することを望まず、後続の同一ＡＣＫＮｏのＤＵＰＡＣＫの受信時に既に高速再送信されたパケットをもう一度不必要に再送信しないようにするために、最大の高速再送信されたパケットのＳｅｑＮｏすなわちＬａｒｇｅｓｔＲｔｘＳｅｑＮｏを記録する／更新することができる。

後に、
７．＋パケット転送間インターバル（事前に既知のボトルネック回線レートのユーザ入力によって決定される）：
８．＋（７）と同様に、ユーザ入力ではなく最新の推定されたボトルネック回線レートの使用
９．＋パケット転送間インターバル値の制御／調整を介して動作するＴＣＰフレンドリアルゴリズム
初期基本レートペースモジュールの単純な概要：
追加されなければならない第１ステージレートペースモジュール仕様（この仕様は、ネットワークへのパケット送信の平滑化だけを実行し、他には何も実行しない）：
１．ユーザに、ボトルネックリンクのｋｂｓ単位の帯域幅を入力させる、例えばＳＡＮ．ｅｘｅＢ（例えば５１２ｋｂｓ）：これは、通常はセンダ／ユーザのファーストマイルアップロード帯域幅であるが、時にはレシーバのラストマイルとすることができる（ユーザがレシーバのラストマイルの帯域幅を知らない場合には、単にユーザのファーストマイルを入力する：ＤＳＬ加入者のアップロード帯域幅は、通常はダウンロード帯域幅よりはるかに少ない）［より後のソフトウェアは、ユーザ入力を全く必要とせずに、最新の推定されたＢの値を提供することができる］。

２．最小バイトインターバル間転送を保証する単純なレートペースモジュールを組み込む、例えば、サイズＳ１（例えば１０００バイト全長、カプセル化＋ヘッダ＋ペイロード）のパケットを転送する場合に、Ｓ２（例えば、今回は７５０バイト）の次パケットサイズを転送する前に１０００バイト／（Ｂ／８）が経過すること．．．などを確実にし．．．総パケットサイズＳは、ＴＣＰヘッダから確かめることができる。

３．新しいＭＳＴＣＰパケット／高速再送信／ＲＴＯ再送信．．．などのどれであれ、転送されるべきすべてのパケットは、まず、これから転送されるパケットバッファにアペンドされる：このバッファは、明確に順序付けされることを最もよく必要とするが、「ギャップレス」でないことを必要とし、ＭＳＴＣＰ又はソフトウェア高速再送信のいずれかからの到着するパケットは、ＳｅｑＮｏ昇順でアペンド／挿入される（すなわち、高速再送信／ＭＳＴＣＰＲＴＯ再送信パケットが、より大きいＳｅｑＮｏを有する他のデータパケットの前にまず転送されるようにするために）。同一ＳｅｑＮｏの純ＡＣＫ／データパケットは、互いに関する相対的な到着の順序で挿入される必要があるはずである。

（注：ここでのＭＳＴＣＰは、すべてのＲＴＯ再送信を行い続ける）。

［より後の仕様機能強化：
．ラウンドトリップ単一のマークされたパケットのＳｅｑＮｏ．．．及びラウンドトリップ完了に続く後続の次の転送されるパケットのＳｅｑＮｏ．．．などに基づく、各ＲＴＴの総送信済みバイトの簡単なカウントのために、このこれから転送されるリスト内のパケットエントリにＴｏｔａｌＰａｃｋｅｔＬｅｎｇｔｈｉｎＢｙｔｅｓ（バイト単位の総パケット長）フィールドを追加することが有用である。このリストは、ペーシングを実施する必要があり、ここでこの第１ステージで明確に順序付けられなければならない「ギャップレス」でない必要があるＰａｃｋｅｔＣｏｐｙリストとは異なる。

．これから転送されるバッファ＞例えば１０Ｋバイトである時には、必ず、ＭＳＴＣＰに「０」ウィンドウ更新を送信し、すべての着信パケットのウィンドウサイズを「０」再計算チェックサムに変更する。

．パケットのＳｅｑＮｏ（ＳＹＮＣ／ＳＹＮＣＡＣＫ／ＡＣＫの後の最初のパケットから開始して）を「マーク」し／時刻を送信し／ｔｈｉｓ＿ＲＴＴ＿ｔｏｔａｌ＿ｂｙｔｅｓ＿ｆｏｒｗａｒｄｅｄ＝この「マーク」パケットの長さをセットし、即座にｎｅｘｔ＿ＲＴＴ＿ｔｏｔａｌ＿ｂｙｔｅｓ＿ｆｏｒｗａｒｄｅｄのカウントを開始する（この「マーク」パケットを含まない）。戻るパケットのＡＣＫＮｏ＞「マーク」ＳｅｑＮｏである場合には、このＲＴＴ値（現在のシステム時刻−送信時刻）を記録し、ｔｈｉｓ＿ＲＴＴ＿ｔｏｔａｌ＿ｂｙｔｅｓ＿ｆｏｒｗａｒｄｅｄを記録する。その後、まさに最新の転送されたパケットのＳｅｑＮｏとして次の「マーク」ＳｅｑＮｏを選択し（前の「マーク」ＳｅｑＮｏが戻る前に転送される純ＡＣＫではなくデータパケットがある場合、そうでない場合には、次のデータパケットが転送されるのを待つ）．．．．．．など．．．．．など。

（ＲＴＴ値及びｔｈｉｓ＿ＲＴＴ＿ｔｏｔａｌ＿ｂｙｔｅｓ＿ｆｏｒｗａｒｄｅｄの最新の更新されたインスタンスのレコードオンリーを保つことだけが必要）
．ソフトウェアは、ＤＵＰＡＣＫパケットが純ＡＣＫであるすなわちデータを搬送していない場合又はＳＡＣＫフラグをセットされたデータを搬送するパケットである場合に限って、ＤｕｐＮｕｍカウントを増分しなければならない（リモートクライアントもデータを送信する場合に、我々は、ドロップがない場合であっても多数の同一ＳｅｑＮｏのパケットを得始める可能性がある）。また、もう１つの変数ＤｕｐＮｕｍＤａｔａ（同一ＳｅｑＮｏを有するデータペイロードパケットの個数）を増分し、同一ＳｅｑＮｏを有するすべての着信パケットを−（ＤｕｐＮｕｍ＋ＤｕｐＮｕｍＤａｔａ）に変更する：ＤｕｐＮｕｍＤａｔａは、ＤｕｐＮｕｍに似た形で更新され、ＤｕｐＮｕｍ処理は、今や、純ＤＵＰＡＣＫパケットとデータペイロードを伴うパケットとの間で区別する必要がある。

本明細書で説明するすべての方法及び原理のさまざまなコンポーネント特徴は、さらに、示される方法のいずれかに組み込まれて一緒に働くようにすることができ、さまざまなトポロジネットワークタイプ及び／又はさまざまなトラフィック／グラフ分析の方法及び原理は、さらに、リンクの帯域幅の経済を使用可能にすることができる。本説明のどこに現れようとも、使用される数字が、可能な値の特定の実例だけを示すことを意図され、例えば、ＲＴＴ＊１．５では、数字１．５を、目的及び特定のネットワークに適当な別の値セッティング（しかし、必ず１．０より大きい）、例えば０．１秒／０．２５秒．．．などの知覚期間によって置換することができることにも留意されたい。さらに、示される特定の例及び数字のすべては、基礎になるアイデア、概念、及びその相互作用も伝えることを意図されているが、使用される実際の数字及び例に限定されない。

上記で説明した実施形態は、単に、本発明の原理を示す。当業者は、その本発明の原理を実施し、それに含まれるさまざまな修正及び変更を作ることができる。

２００５年１０月１１日ファイリング
増分展開可能な外部インターネットＮｅｘｔＧｅｎＴＣＰの単純な実施態様のいくつかの例
背景材料
．第３ＤＵＰＡＣＫ高速再送信をトリガするかＲＴＯタイムアウトをトリガするパケットの最新のＲＴＴは、最後の測定されたラウンドトリップ時間ＲＴＴに関する既存のＬｉｎｕｘＴＣＢで維持される変数からたやすく入手可能である。

．最小の記録されたｍｉｎ（ＲＴＴ）は、既存のＷｅｓｔｗｏｏｄ／ＦａｓｔＴＣＰ／ＶｅｇａｓＴＣＢで維持される変数からたやすく入手可能であるのみであるが、ｍｉｎ（ＲＴＴ）＝［ｍｉｎ（ＲＴＴ），最後の測定されたラウンドトリップ時間ＲＴＴの］の最小値を継続的に更新する２〜３行のコードを記述することは、十分に簡単であるに違いない。また、レシーバベースドＴＣＰ変更／レシーバベースドＴＣＰレート制御があれば、ＯＴＴ及びｍｉｎ（ＯＴＴ）を、センダベースドのＲＴＴ及びｍｉｎ（ＲＴＴ）の代わりに利用することができ、これは、センダのＴｉｍｅｓｔａｍｐオプションから利益を得ることができ、あるいは、レシーバベースドＴＣＰは、ＯＴＴ及びｍｉｎ（ＯＴＴ）を確かめる必要に依存するのではなく、パケット到着間技法を利用することができる。

参考文献：
ｈｔｔｐ：／／ｗｗｗ．ｃｓ．ｕｍｄ．ｅｄｕ／〜ｓｈａｎｋａｒ／４１７−Ｎｏｔｅｓ／５−ｎｏｔｅ−ｔｒａｎｓｐｏｒｔＣｏｎｇＣｏｎｔｒｏｌ．ｈｔｍ：ＬｉｎｕｘＴＣＢによって維持されるＲＴＴ変数
ｈｔｔｐ：／／ｗｗｗ．ｓｃｉｔ．ｗｌｖ．ａｃ．ｕｋ／ｒｆｃ／ｒｆｃ２９ｘｘ／ＲＦＣ２９８８．ｈｔｍｌ：ＲＴＯ計算
ＧｏｏｇｌｅＳｅａｒｃｈ用語「ｔｃｐｒｔｔｖａｒｉａｂｌｅｓ」
ｈｔｔｐ：／／ｗｗｗ．ｐｓｃ．ｅｄｕ／ｎｅｔｗｏｒｋｉｎｇ／ｐｅｒｆ＿ｔｕｎｅ．ｈｔｍｌ：ＬｉｎｕｘＴＣＰＲＴＴパラメータのチューニング
ＧｏｏｇｌｅＳｅａｒｃｈ：「ｔｃｐｍｉｎｉｍｕｍｒｅｃｏｒｄｅｄｒｔｔ」又は「ｌｉｎｕｘｔｃｐｍｉｎｉｍｕｍｒｅｃｏｒｄｅｄｒｔｔｖａｒｉａｂｌｅ」。注：ＴＣＰＷｅｓｔｗｏｏｄは最小ＲＴＴを測定する。

ＧｏｏｇｌｅＳｅａｒｃｈ用語「ＣＷＮＤｓｉｚｅｔｒａｃｋｉｎｇ」、「ＣＷＮＤｓｉｚｅｅｓｔｉｍａｔｉｏｎ」、「ＲｅｃｅｉｖｅｒｂａｓｅｄＣＷＮＤｓｉｚｅｔｒａｃｋｉｎｇｅｓｔｉｍａｔｉｏｎ」、「ＲＴＴｔｒａｃｋｉｎｇ」、「ＲＴＴｅｓｔｉｍａｔｉｏｎ」、「ＲｅｃｅｉｖｅｒｂａｓｅｄＲＴＴｔｒａｃｋｉｎｇｅｓｔｉｍａｔｉｏｎ」、「ＯＴＴｔｒａｃｋｉｎｇ」、「ＯＴＴｅｓｔｉｍａｔｉｏｎ」、「ＲｅｃｅｉｖｅｒｂａｓｅｄＯＴＴｔｒａｃｋｉｎｇｅｓｔｉｍａｔｉｏｎ」、「ｔｏｔａｌｉｎ−ｆｌｉｇｈｔｓ−ｐａｃｋｅｔｓｔｒａｃｋｉｎｇ」、「ｔｏｔａｌｉｎ−ｆｌｉｇｈｔｓ−ｐａｃｋｅｔｓｅｓｔｉｍａｔｉｏｎ」、「Ｒｅｃｅｉｖｅｒｂａｓｅｄｔｏｔａｌｉｎ−ｆｌｉｇｈｔ−ｐａｃｋｅｔｓｔｒａｃｋｉｎｇｅｓｔｉｍａｔｉｏｎ」．．．など。

初期の単純な実施態様のアイデア
変更されたｌｉｎｕｘを使用するテスティングを検証するためには：
最も単純で十分なもので、１行を変更し、ループ遅延コード（ＬｉｎｕｘＴＣＰ実行を「ポーズ」させるため）を挿入することだけが必要である。

１．Ｌｉｎｕｘ高速再送信モジュールコードでは、３つのＤＵＰＡＣＫの際に、ＣＷＮＤを半分にしない、すなわち、ＣＷＮＤは、現在は変更されない（ＣＷＮＤ＝ＣＷＮＤ／２ではなく）。

２．それと同時に、同一のコードセクション位置で、単純に２〜３行のコードを挿入して、０．３秒だけＬｉｎｕｘＴＣＰプログラムの実行を「ポーズ」させる（「ポーズ」をシミュレートする）。［後でのみ：まさに最初のＤＵＰＡＣＫされたパケットを制約されずに再送信し、次に、この同一の位置で３００ｍｓカウントダウングローバル変数「Ｐａｕｓｅ」をセットするのみにし、その後、ＬｉｎｕｘＴＣＰがその「最終パケット送信」コードセクションで、何であれすべての種類の送信を可能にするためにこの「Ｐａｕｓｅ」変数＝０であることをチェックする（Ｌｉｎｕｘがこの「Ｐａｕｓｅ」によって停止されたパケットを保持するために「最終送信」キューを実施すると仮定して）ことを可能にして、
パケットを捨て、パケットを送信する前に待ち時間遅延を導入する２〜３行のコードを記述し、単に、ユーザ入力の一定の周期的ドロップインターバルと、連続するドロップの回数（例えば、０．１２５及び１すなわち、８つの生成されたパケットおきに１回だけ１つのパケットを捨てる［１２．５％パケットロスレートと同等］又は０．１２５及び３すなわち、８つの生成されたパケットおきに１回だけ３つの連続するパケットを捨てる［３７．５％パケットロスレートと同等］）と、ＲＴＴ待ち時間（例えば、２００ｍｓ）とを可能にする
ことがはるかに好ましい。

コードは、単にドロップインターバル及び連続ドロップ回数に基づいて前方に転送しないことと、スケジューリングされたすべての生き残っているパケットがその受信されたローカルｓｙｓｔｉｍｅより例えば２００ｍｓ後に転送されることとを必要とする → これらの前方に転送されるようにスケジューリングされた生き残っているパケットは、ネットワークへの前方への転送のためにキュー内に保持される必要がある（それ自体の個々のスケジューリングされた前方転送ローカルｓｙｓｔｉｍｅと共に）。

１０ｍｂｓＬＡＮ及び５００ｋｂｓに調整された無線ルータリンク上で（イーサネットを「半二重」モードにセットすることを忘れないように）、さまざまなシミュレートされたロスレート及び待ち時間と一緒にすばやく検証することができる。その最も単純で十分なものでは、１行を変更し、ループ遅延コード（ＬｉｎｕｘＴＣＰ実行を「ポーズ」させるため）を挿入することだけが必要である。

２．それと同時に、同一のコードセクション位置で、単純に２〜３行のコードを挿入して、０．３秒だけＬｉｎｕｘＴＣＰプログラムの実行を「ポーズ」させる（「ポーズ」をシミュレートする）。

高ロスレート長待ち時間外部インターネット／ＬＦＮを介する大きいファイル転送ＳＡＮＦＴＰは、現在、１００％に近い使用可能帯域幅利用度を示さなければならない！。例えばＳｈｕｎｒａ社のソフトウェアを間にはさんで、例えば１０％ドロップレート及び／又は３００ｍｓ待ち時間をシミュレートするすなわち長距離高ロスレートをシミュレートすることができ、あるいは、単純に、パケットを捨て、パケットを送信する前に待ち時間遅延を導入するコードを記述することができる。ＮＳ２などのシミュレーションを使用してこれを簡単に検証することもできる。

今は、センダＴＣＰのＣＷＮＤの現在のサイズは、このサイズが達成されたならば、センダＴＣＰが戻るＡＣＫレートに正確に対応して新しいパケットを注入するだけなので、いかなる形でも輻輳ドロップを引き起こさないことが非常に明瞭である：これがＣＷＮＤサイズの加速瞬間増加であることに留意されたい（戻るＡＣＫレートより多数のパケットをネットワークに瞬間的に注入すること、例えば、戻るＡＣＫレートのそれを２倍にする指数関数的増分、これはパケットドロップの主原因である：ＣＷＮＤが現在の既存のサイズを既に達成したならば、どれほど大きくても、それは、戻るＡＣＫレートより多数の新しいパケットがネットワークに注入されることを引き起こさず、これは、ＣＷＮＤの瞬間的サイズ増分の時に限って発生し得る）。

２〜３行のＬｉｎｕｘソースコードを変更することは、実に単純であり、Ｗｉｎｄｏｗｓでは、まず、ＭＳＴＣＰからすべての高速再送信機能を引き継ぐインターセプトソフトウェアモジュールを準備する必要だけがある。Ｗｉｎｄｏｗｓで実施するためには、ＭＳＴＣＰが失われたパケットの高速再送信要求について全く通知されない／知らないようにするために、各着信／発信パケットをインターセプトし、着信ＤＵＰＡＣＫのＡｃｋｎｏｗｌｅｄｇｅｍｅｎｔＮｕｍｂｅｒフィールドを変更する必要がある（ＭＳＴＣＰではなく、我々のインターセプトソフトウェアが、今や、すべての高速再送信機能を行う）：このインターセプトソフトウェアモジュールは、さらに、ＭＳＴＣＰからすべてのＲＴＯタイムアウト再送信機能を引き継ぐことができる（例えば、まさにＭＳＴＣＰ自体のＲＴＯタイムアウトトラッキングアルゴリズムをミラーリングするか、新しい変更された所望のアルゴリズムを考案することができる）。インターセプトソフトウェアモジュールが、今や、既存ＭＳＴＣＰのＤＵＰＡＣＫ高速再送信機能及びＲＴＯタイムアウト再送信機能のすべてを引き継いだ状態で、インターセプトソフトウェアは、今や、インターセプトされたパケットに関するＭＳＴＣＰに戻るＳＰＯＯＦＡＣＫの即座のスプーフィング／一時的停止及び／又はＭＳＴＣＰパケット生成を停止するためにＳＰＯＯＦＡＣＫ内のレシーバウィンドウサイズフィールドに「０」をセットすることを介して、ＭＳＴＣＰの新規パケット生成／送信レートに対する完全なトータルコントロールを有することができる。

例えばＬｉｎｕｘ／ＦｒｅｅＢＳＤ／Ｗｉｎｄｏｗｓソースコードでは、次の非常に基本的な形で働くことを即座に示されるこのＮｅｘｔＧｅｎＦＴＰを有するために２〜３行を修正する／挿入することができなければならない。

１．Ｌｉｎｕｘの３ＤＵＰＡＣＫ高速再送信モジュールでは、ＣＷＮＤをＣＷＮＤ／２に変更するコードラインを除去することだけが必要である（すなわち、ＣＷＮＤは、今や、変更されなくなる）。すべての他のコードラインは、全く修正される必要がない：例えば、ＳＳｔｈｒｅｓｈには、今や、ＣＷＮＤがセットされる（すなわち、ＴＣＰは、今や、指数関数的２倍化ではなく、すべてのＲＴＴについて１セグメントだけ加法的に増加するのみである）。これ自体は、今や、高ドロップレートを有するＬＦＮ／外部インターネットで１００％に近いリンク利用度を示さなければならない！（すなわち、ここでの非常に未完成の形で働くことを示される）。

テストを助けるために、％パケットドロップを導入し且つ／又は経路待ち時間をシミュレートすることのできるＳｈｕｎｒａなどのソフトウェアを使用し、このソフトウェアを、ＮｅｘｔＧｅｎＦＴＰとネットワークの送信する側との間に置くか、類似する単純なユーティリティをコーディングしてもよい。

２．［任意選択であるが確かに後に必要になる］ＮｅｘｔＧｅｎＦＴＰは、実際に、３つのＤＵＰＡＣＫなどのパケットドロップイベントの際に適当なインターバルの間だけ「ポーズ」して、バッファリングされているそれ自体の「余分な」送信されたフライトパケットのすべてをクリアしなければならない（が、すべての既存の通常のＴＣＰ／ＦＴＰは、そのＣＷＮＤを劇的に半分にし、深刻な不必要な明確に文書化されたスループット問題を引き起こす）。例えばＬｉｎｕｘでは、実際の現実の非輻輳ＲＴＴ又は非輻輳ＯＴＴが前もって既知でない場合に、フローの最小の観察されたＲＴＴのレコードｍｉｎ（ＲＴＴ）又はｍｉｎ（ＯＴＴ）を保持し、３ＤＵＰＡＣＫの際に、例えば０．３秒（同等秒数単位での最も一般的なルータバッファサイズである）又はあるアルゴリズム的に導出された期間（．．．後に）の間だけネットワークへのすべてのパケット注入を「停止」させる、あるコードを挿入することだけが必要である［ポーズの代わりに、ＣＷＮＤに適当な対応するアルゴリズム的に決定された値（１つ又は複数）をセットすることもできることに留意されたい！。考案される所望のアルゴリズムに応じて、｛最新のＲＴＴ値（又は適当な場合にＯＴＴ）−記録されたｍｉｎ（ＲＴＴ）値（又は適当な場合にｍｉｎ（ＯＴＴ））｝／ｍｉｎ（ＲＴＴ）倍だけＣＷＮＤサイズを減らすこと、あるいは、［｛最新のＲＴＴ値（又は適当な場合にＯＴＴ）−記録されたｍｉｎ（ＲＴＴ）値（又は適当な場合にｍｉｎ（ＯＴＴ））｝／最新のＲＴＴ値］倍だけＣＷＮＤサイズを減らすことすなわちＣＷＮＤには今やＣＷＮＤ＊［１−［｛最新のＲＴＴ値（又は適当な場合にＯＴＴ）−記録されたｍｉｎ（ＲＴＴ）値（又は適当な場合にｍｉｎ（ＯＴＴ））｝／最新のＲＴＴ値］］がセットされる、あるいは、ＣＷＮＤサイズにＣＷＮＤ＊ｍｉｎ（ＲＴＴ）（又は適当な場合にｍｉｎ（ＯＴＴ））／最新のＲＴＴ値（又は適当な場合にＯＴＴ）をセットすること、．．．．などである］。ｍｉｎ（ＲＴＴ）が、記録された経路の非輻輳ＲＴＴの最新の推定値であることに留意されたい。

３．［任意選択であるが確かに後に必要になる］フローの経路に沿ったボトルネックリンクの使用可能帯域幅は、簡単に判定することができ（非常に明確に文書化されているが、我々自身の開発された技法と比較して不完全である）、したがって、使用可能帯域幅のこの上限がわかった／判定されたならば、ＮｅｘｔＧｅｎＴＣＰは、その後、もはや、ＣＷＮＤ増分を引き起こしてはならない（指数関数的２倍化であれ線形増分であれ） → ＮｅｘｔＧｅｎＴＣＰは、この達成された上限レートで送信したならば、もはや不必要にＣＷＮＤ増分を引き起こさず、不必要にパケットドロップを引きこさない！。

初期の単純な実施態様のアイデア（洗練１）：
変更されたｌｉｎｕｘを使用するテスティングを検証するためには：
最も単純で十分なもので、１行を変更し、ループ遅延コード（ＬｉｎｕｘＴＣＰ実行を「ポーズ」させるため）を挿入することだけが必要である。

２．それと同時に、同一のコードセクション位置で、単純に２〜３行のコードを挿入して、０．３秒だけＬｉｎｕｘＴＣＰプログラムの実行を「ポーズ」させる（「ポーズ」をシミュレートする）。［後に：まさに最初のパケットを再送信し、次に、この同一の位置で３００ｍｓカウントダウングローバル変数「Ｐａｕｓｅ」をセットするのみにし、その後、ＬｉｎｕｘＴＣＰがその「最終パケット送信」コードセクションで、何であれすべての種類の送信を可能にするためにこの「Ｐａｕｓｅ」変数＝０であることをチェックする（Ｌｉｎｕｘがこの「Ｐａｕｓｅ」によって停止されたパケットを保持するために「最終送信」キューを実施すると仮定して）ことを可能にすることがはるかに好ましい。

［後でのみ：まさに最初のパケットを再送信し、次に、この同一の位置で３００ｍｓカウントダウングローバル変数「Ｐａｕｓｅ」をセットするのみにし、その後、ＬｉｎｕｘＴＣＰがその「最終パケット送信」コードセクションで、何であれすべての種類の送信を可能にするためにこの「Ｐａｕｓｅ」変数＝０であることをチェックする（Ｌｉｎｕｘがこの「Ｐａｕｓｅ」によって停止されたパケットを保持するために「最終送信」キューを実施すると仮定して）ことを可能することがはるかに好ましい。

はるかに後でのみ：これは、便利に、次によって達成する／実装することができる（提案としてのみ）。

２．それと同時に、同一のコードセクション位置で、単純にこの同一の位置（正確に、ＣＷＮＤが今やＣＷＮＤ／２ではなく変更されなくなるように変更される場所）で３００ｍｓカウントダウングローバル変数「Ｐａｕｓｅ」をセットし、その後、ＬｉｎｕｘＴＣＰがその「最終パケット送信」コードセクションで、パケットのＳｅｑＮｏ＝＜最大の送信された肯定応答されていないＳｅｑＮｏ（このＳｅｑＮｏは、既存ＴＣＰパラメータから簡単に入手することができる、すなわち、パケットが再送信される古いＳｅｑＮｏのパケットである場合に限って、「Ｐａｕｓｅ」変数＞０に関わりなくパケットを前方に転送することを許容するのみ）である場合を除いて、すべての種類の送信を可能にするためにこの「Ｐａｕｓｅ」変数＝０であることをチェックする。

すなわち、ＬｉｎｕｘＴＣＰは、必ず、すべての高速再送信パケット及び／又はＲＴＯタイムアウト再送信パケットを、ＣＷＮＤ又は有効ウィンドウサイズ制約に一切関わりなく、即座に制約されずに前方に転送することを可能にする（再送信パケットは、いかなる形でも既存のフライトパケットを全く増分しない！。しかし、ＳｅｑＮｏ＞最大の送信された肯定応答されていないＳｅｑＮｏを有する新しいパケットの前方への転送が、既存の総フライトパケット数を増加させる可能性があることに留意されたい）。

もう１つの実施形態は、単純に、輻輳ドロップイベント（１つ又は複数）の際に「ｐａｕｓｅ」変数（固定された例えば３００ｍｓのインターバル又は最新のＲＴＴ−ｍｉｎ（ＲＴＴ）インターバル．．．などの導出されたもののいずれか）をカウントダウンするために、絶対にＣＷＮＤを全く減分せず、「ｐａｕｓｅ」変数＞０の場合にＣＷＮＤ増分を一切可能にしないことであるはずである → この実施態様が、バッファリングされている余分のフライトパケットを減らすのを助けないという点でアグレッシブ［また、ＣＷＮＤを、ステップ１とステップ２との両方と一緒に、「０」又はｌａｒｇｅｓｔ．ＵＮＡ．ＳｅｑＮｏ−ＳＥｎｔ．ＵＮＡ．ＳｅｑＮｏをセットするのではなく、単純に必ず変更されない／減分されないものとすることができる］。

「ｐａｕｓｅ」変数＞０である間にこの非増分部分を下の以前の実施態様に導入することもでき、したがって、戻るＡＣＫがスライディングウィンドウの左エッジを進めることは、戻るＡＣＫ−クロッキングレートに対応する同一のレートで新しいパケット（１つ又は複数）（すなわち、ＳｅｑＮｏ＞ｌａｒｇｅｓｔ．Ｓｅｎｔ．ＳｅｑＮｏを有するパケット（１つ又は複数））が注入されることを引き起こすだけであって、戻るＡＣＫのレート−クロッキングレートを超える「加速的」ＣＷＮＤ増分／余分の加速的な指数関数的又は線形の新しいパケット（１つ又は複数）注入を引き起こさない。カウントダウン「ｐａｕｓｅ」グローバル変数＞０の時に、ＬｉｎｕｘＴＣＰは、着信ＡＣＫが今やスライディングウィンドウ左エッジを進める場合であってもＣＷＮＤを一切増分してはならない．．．すなわち、ＬｉｎｕｘＴＣＰは、戻るＡＣＫ−クロッキングレートと同一のレートでネットワークに新しいパケットを注入することができるが、戻るＡＣＫのレート−クロッキングレートを超えて「指数関数的に２倍にする」又は「線形に増やす」ことを行ってはならない（すべてのＣＷＮＤ増分コード行を、まずカウントダウン「ｐａｕｓｅ」＞０であるかどうかをチェックし、そうである場合に増分をバイパスするように変更することによって簡単に実施される）。

また、代替案では、Ｌｉｎｕｘ変更は、単に単純に次を要求することができる。

１．輻輳ドロップイベント（１つ又は複数）の際にＣＷＮＤ値を全く変更せず／減分せず、また、輻輳ドロップイベントによってトリガされる、続く「ポーズインターバル」、例えば３００ｍｓ（あるいは、最新ＲＴＴ−ｍｉｎ（ＲＴＴ）．．．又はｍａｘ［最新ＲＴＴ−ｍｉｎ（ＲＴＴ）、例えば３００ｍｓ］．．．などのアルゴリズム的に導出されたインターバル）中にＣＷＮＤを全く増分しない → 輻輳ドロップイベント（１つ又は複数）の際に、変更されたＬｉｎｕｘＴＣＰは、「トリガされたポーズインターバル」中の戻るＡＣＫクロッキングレートを超えて新しい「加速的」パケット（１つ又は複数）をネットワークに（すなわち、ＳｅｑＮｏ＞ｌａｒｇｅｓｔ．Ｓｅｎｔ．ＳｅｑＮｏを有する）注入しない［すなわち、ＣＷＮＤは、ＣＷＮＤ＜センダ／レシーバ最大ウィンドウサイズの場合であっても、スライディングウィンドウの左エッジを進めた戻るＡＣＫによって増分はされない］。

及び／又は任意選択として、
２．必ず、再送信パケット（すなわち、ＳｅｑＮｏ＝＜ｌａｒｇｅｓｔ．Ｓｅｎｔ．ＳｅｑＮｏを有するパケット）を、スライディングウィンドウ機構によって一切制約されずに前方に転送することを可能にする。

ステップ１．．．．．に対してより洗練されて．．．．．例えばＣＷＮＤに（Ｌａｒｇｅｓｔ．ＳＥＮＴ．ＳｅｑＮｏ−ＳＥＮＴ．ＵＮＡ．ＳｅｑＮｏ）をセットする３００ｍｓの「ポーズ」カウントダウンをセットし、カウントダウンされた後にＣＷＮＤを復元する．．． → この形で、Ｌｉｎｕｘ高速再送信モジュールは、各後に到着する複数の同一ＳｅｑＮｏのＤＵＰＡＣＫがＣＷＮＤをＬａｒｇｅｓｔ．ＳＥＮＴ．ＳｅｑＮｏ−ＳＥＮＴ．ＵＮＡ．ＳｅｑＮｏ＋１に増分するので、着信する同一ＳｅｑＮｏの複数の後続ＤＵＰＡＣＫのＳＡＣＫフィールドによって示される欠けているギャップパケットを「ストロークアウト」することができる［ＣＷＮＤに「０」をセットする場合に、欠けているギャップパケットの前方に転送する再送信を防ぐことができるが］ → ステップ１の変更自体単独は、ステップ２を必要とせずにかなりうまく働かなければならないが、ステップ１及びステップ２の変更を一緒に用いると、ＣＷＮＤに「０」がセットされている場合であってもあまり問題にならない。

ＣＷＮＤにＬａｒｇｅｓｔ．ＳＥＮＴ．ＳｅｑＮｏ−ＳＥＮＴ．ＵＮＡ．ＳｅｑＮｏをセットすることは、「加速的な」新しい追加のパケットがネットワークに注入されるのを防ぐことにおいて、「０」をセットすることと同一の効果を有するが、再送信パケット（ＳｅｑＮｏ＝＜Ｌａｒｇｅｓｔ．ＳＥＮＴ．ＳｅｑＮｏを有する）を制約されずに前方に転送することを可能にする。

既存ＲＦＣのＴＣＰソースコード変更及び単純化されたテストの概要：
テストベッドは、次の通りでなければならない（未変更のＬｉｎｕｘＴＣＰサーバと比較して）。

変更されたＬｉｎｕｘＴＣＰサーバ［＋例えば２／５／２０％のシミュレートされたパケットドロップ＋例えば１００／２５０／５００ｍｓのＲＴＴ待ち時間］−＞ルータ−＞既存ＬｉｎｕｘＴＣＰクライアント
ルータとクライアントとの間のリンクは、５００ｋｂｐｓとすることができ、ルータは、１０個又は２５個のパケットバッファを有することができる。例えば３２／６４／２５６Ｋバイトのセンダ及びレシーバのウィンドウサイズ。

ＬｉｎｕｘＴＣＰ変更仕様の提案：
（簡単な実世界Ｌｉｎｕｘ変更実施態様のための、例えば３００ｍｓインターバル中にＣＷＮＤ＝０をセットすることによって「送信ポーズ」を達成する単純な技法）
１．既存ＬｉｎｕｘＴＣＰが、輻輳ドロップイベント（ＣＷＮＤを半分にする３つのＤＵＰＡＣＫ及びＣＷＮＤを０にリセットするＲＴＯタイムアウト）の際にその代わりにＣＷＮＤを変更されないままにするためにＣＷＮＤを乗法的に減らし（ＣＷＮＤ＝ＣＷＮＤ／２）、ＣＷＮＤに（Ｌａｒｇｅｓｔ．ＳＥＮＴ．ＳｅｑＮｏ−ＳＥＮＴ．ＵＮＡ．ＳｅｑＮｏ）をセットする３００ｍｓ「ポーズ」カウントダウンをセットし、カウントダウンされた後にＣＷＮＤを復元する場合には、必ず、半分にされた又はＬａｒｇｅｓｔ．ＳＥＮＴ．ＳｅｑＮｏ−ＳＥＮＴ．ＵＮＡ．ＳｅｑＮｏのＣＷＮＤ値ではなくオリジナルのＣＷＮＤ値をＳＳＴｈｒｅｓｈにセットすることもしなければならない＝＝＞これは、０．３秒「ポーズ」する簡単な実施態様と正確に同等である。

［ここでのステップ２は、任意選択であるが好むことができ、ステップ１だけを伴うテストの後で追加することができる］
２．ＣＷＮＤ／有効ウィンドウスライディングウィンドウスロット可用性に関わりなく、ＳｅｑＮｏ＝＜最大の既存の送信されたＳｅｑＮｏを有するすべての再送信パケットを制約されずにイネーブルする。

パケットを前方に即座に転送することを可能にするかどうかをＬｉｎｕｘＴＣＰがチェックする（すなわち、Ｌａｒｇｅｓｔ．ＳＥＮＴ．ＳｅｑＮｏ−ＳＥＮＴ．ＵＮＡ．ＳｅｑＮｏ＜有効ウィンドウサイズであるかどうかに依存する）スライディングウィンドウコードセクションで、我々は、パケットのＳＥｑＮｏ＝＜Ｌａｒｇｅｓｔ．ＳＥＮＴ．ＳｅｑＮｏである（すなわち、再送信パケット、これは、何にも関わりなく前方への転送を妨げられてはならない）場合に、このチェックを「バイパスする」コードを非常に単純に挿入することができる → この形で、ＬｉｎｕｘＴＣＰ再送信モジュールは、必ず、第３ＤＵＰＡＣＫ／後続の複数のＤＵＰＡＣＫによって示されるすべての「欠けているギャップパケット」を即座に「ストロークアウト」することができる。［ＳｅｑＮｏラップアラウンド保護を組み込むことを忘れないように］。

Ｗｉｎｄｏｗｓプラットフォームインターセプト高速再送信モジュールに関する有用な注
このモジュールは（ＭＳＴＣＰからすべての高速再送信機能を引き継ぎ、ＭＳＴＣＰが絶対にどのＤＵＰＡＣＫイベントについても全く知ることがなくなるように着信ＤＵＰＡＣＫの着信ＡＣＫＮｏを変更する）、着信する同一ＳｅｑＮｏのＤＵＰＡＣＫのＳＡＣＫフィールドによって示されるすべての「欠けているギャップパケット」を再送信しなければならず、この同一ＳｅｑＮｏの複数のＤＵＰＡＣＫ中に再送信されるすべてのＳｅｑＮｏのリストを保持し、後続の同一ＳｅｑＮｏのＤＵＰＡＣＫが今やこの「再送信済みリスト」上記の再送信されたＳｅｑＮｏパケット（１つ又は複数）の受信を示す場合（この場合に、このモジュールは、ＳｅｑＮｏ＜新たに到着する同一ＳｅｑＮｏのＤＵＰＡＣＫによって示される受信された最大の再送信されたＳｅｑＮｏを有する「より以前に再送信された欠けているギャップパケット」（すなわち、既に再送信済みリストにある）をもう一度再送信することだけを行わなければならない）を除いて、後続の同一の一連のＳｅｑＮｏのＤＵＰＡＣＫ中に既に再送信されたものを不必要に再送信はしない。

もちろん、後続の新しい増分されたＳｅｑＮｏの第３ＤＵＰＡＣＫ（ＳｅｑＮｏは、今は異なり、増分されている）の際に、このモジュールは、着信する同一ＳｅｑＮｏのＤＵＰＡＣＫのＳＡＣＫフィールドによって示されるすべての「欠けているギャップパケット」をもう一度新たに再送信することができる。

明らかに、上で説明されたバージョン／アルゴリズムに対する後続バージョン（１つ又は複数）では、次を行うことが好ましい：
「１．既存ＬｉｎｕｘＴＣＰが、輻輳ドロップイベント（ＣＷＮＤを半分にする３つのＤＵＰＡＣＫ及びＣＷＮＤを１にリセットするＲＴＯタイムアウト）の際にその代わりにＣＷＮＤを変更されないままにするために乗法的にＣＷＮＤを減らし（ＣＷＮＤ＝ＣＷＮＤ／２又はＲＴＯタイムアウトの際にはＣＷＮＤ＝１）、ＣＷＮＤに１をセットする（第３ＤＵＰＡＣＫ高速再送信をトリガするかＲＴＯタイムアウトをトリガするパケットの最新のＲＴＴ−ｍｉｎ（ＲＴＴ），３００ｍｓ）の最小値「ポーズ」カウントダウンをセットし、カウントダウンされた後にＣＷＮＤを「ポーズ」がカウントダウンした後の現在のＬａｒｇｅｓｔ．ＳＥＮＴ．ＳｅｑＮｏ−ＳＥＮＴ．ＵＮＡ．ＳｅｑＮｏ（「ポーズ」が最初にアクティブ化された時と全く異なる値である場合がある）に復元する場合には、必ず、半分にされた又は「１」のＣＷＮＤ値ではなくＬａｒｇｅｓｔ．ＳＥＮＴ．ＳｅｑＮｏ−ＳＥＮＴ．ＵＮＡ．ＳｅｑＮｏ値（「ポーズ」がトリガされた時の）をＳＳＴｈｒｅｓｈにセットすることもしなければならない＝＝＞これは、０．３秒「ポーズ」する簡単な実施態様と正確に同等である」。

注：この形で、「ポーズ」がカウントダウンした後に、変更されたＬｉｎｕｘＴＣＰは、リンクをもう一度即座にもう一度輻輳ドロップするための、「トリガされたポーズ」インターバル中に累積された戻るＡＣＫ−クロッキングを利用する突然の「バースト」送信を引き起こさない：しかし、「ポーズ」がカウントダウンした後に、後続の戻るＡＣＫ−クロッキングレートで送信するのみである（すなわち、「ポーズ」インターバル中に累積された戻るＡＣＫ−クロッキングトークンのいずれをも含まない。

さらにおそらくより好ましくは：「１．既存ＬｉｎｕｘＴＣＰが、輻輳ドロップイベント（ＣＷＮＤを半分にする３つのＤＵＰＡＣＫ及びＣＷＮＤを１にリセットするＲＴＯタイムアウト）の際にその代わりにＣＷＮＤを変更されないままにするために乗法的にＣＷＮＤを減らし（ＣＷＮＤ＝ＣＷＮＤ／２又はＲＴＯタイムアウトの際にはＣＷＮＤ＝１）、ＣＷＮＤにＬａｒｇｅｓｔ．ＳＥＮＴ．ＳｅｑＮｏ−ＳＥＮＴ．ＵＮＡ．ＳｅｑＮｏをセットする［注：１ではなくこのＣＷＮＤ値をセットすることは、スライディングウィンドウスロット可用性によって全く制約されずに即座にすべての再送信パケットすなわちＳｅｑＮｏ＝＜Ｌａｒｇｅｓｔ．ＳＥＮＴ．ＳｅｑＮｏを有するパケットを前方に転送することを可能にするが、「ポーズ」がカウントダウンした後に、現在のＬａｒｇｅｓｔ．ＳＥＮＴ．ＳｅｑＮｏ−ＳＥＮＴ．ＵＮＡ．ＳｅｑＮｏが、それでも、必ず、「ポーズ」カウントダウンの前にＣＷＮＤにその代わりに「１」がセットされる場合と同一であることに留意されたい］（第３ＤＵＰＡＣＫ高速再送信をトリガするかＲＴＯタイムアウトをトリガするパケットの最新のＲＴＴ−ｍｉｎ（ＲＴＴ），３００ｍｓ）の最小値「ポーズ」カウントダウンをセットし、カウントダウンされた後にＣＷＮＤを「ポーズ」がカウントダウンした後の現在のＬａｒｇｅｓｔ．ＳＥＮＴ．ＳｅｑＮｏ−ＳＥＮＴ．ＵＮＡ．ＳｅｑＮｏ（「ポーズ」が最初にアクティブ化された時と全く異なる値である場合がある）に復元する場合には、必ず、半分にされた又は「１」のＣＷＮＤ値ではなくＬａｒｇｅｓｔ．ＳＥＮＴ．ＳｅｑＮｏ−ＳＥＮＴ．ＵＮＡ．ＳｅｑＮｏ値（「ポーズ」がトリガされた時の）をＳＳＴｈｒｅｓｈにセットすることもしなければならない → これは、０．３秒「ポーズ」する簡単な実施態様と正確に同等である」。

既存ＲＦＣのＴＣＰソースコード変更及び単純化されたテストの概要（洗練１）：
この初期の最も単純なステップ１ＴＣＰソースコード変更は、単独で、当初に１００％に近い使用可能リンクの帯域幅利用度を確認するために行わなければならない。

特定のセッティングテストベッドは、次の通りでなければならない（例えば未変更のＬｉｎｕｘ／ＦｒｅｅＢＳＤ／ＷｉｎｄｏｗｓＴＣＰサーバと比較して）：
変更されたＬｉｎｕｘＴＣＰサーバ−＞（ＩＰＣＨＡＩＮを使用して実施することができる）シミュレートされた１０パケット中１個のドロップ２００ｍｓＲＴＴ待ち時間（より大きいことが好ましい）−＞ルータ−＞既存ＬｉｎｕｘＴＣＰクライアント
ルータとクライアントとの間のリンクは、１ｍｐｓとすることができ（より大きいことが好ましい）、ルータは、１ｍｎｓ＊例えば０．３＊選択されたポーズ値／８＝４０Ｋバイト（すなわち、４０個の１Ｋバイトパケット）バッファサイズを有することができる。６４Ｋバイト（より大きいことが好ましい）のセンダ及びレシーバのウィンドウサイズ。

最初の最も単純な１ステップＬｉｎｕｘＴＣＰ変更仕様の提案：
（簡単な実世界Ｌｉｎｕｘ変更実施態様のための、例えば３００ｍｓインターバル中にＣＷＮＤ＝０をセットすることによって「送信ポーズ」を達成する単純な技法）
１．既存ＬｉｎｕｘＴＣＰが、輻輳ドロップイベント（ＣＷＮＤを半分にする３つのＤＵＰＡＣＫ及びＣＷＮＤを１にリセットするＲＴＯタイムアウト）の際にその代わりにＣＷＮＤを変更されないままにするために乗法的にＣＷＮＤを減らし（ＣＷＮＤ＝ＣＷＮＤ／２又はＲＴＯタイムアウトの際にはＣＷＮＤ＝１）、ＣＷＮＤに１をセットする３００ｍｓ「ポーズ」カウントダウンをセットし、カウントダウンされた後にＣＷＮＤをオリジナル値に復元する場合には、必ず、半分にされた又は「１」のＣＷＮＤ値ではなくオリジナルのＣＷＮＤ値をＳＳＴｈｒｅｓｈにセットすることもしなければならない → これは、０．３秒「ポーズ」する簡単な実施態様と正確に同等である。

注：これは、第３ＤＵＰＡＣＫが高速再送信機構をトリガする時及びＲＴＯタイムアウトの時のまさに最初の再送信パケットを除いて（これらは、スライディングウィンドウスロット可用性に関わりなく、必ずＬｉｎｕｘＴＣＰによって前方に転送される！）、第３ＤＵＰＡＣＫ及びＲＴＯタイムアウトの時に例えば３００ｍｓだけ前方に転送するすべての送信／再送信を止める（バッファをクリアするために）。また、この３００ｍｓ「ポーズ」によって止められ／停止されるすべての後続の複数の高速再送信パケットは、３００ｍｓがカウントダウンしたならば即座に前方に転送される（ＣＷＮＤが最大送信／受信ウィンドウサイズに達していない場合に限って、我々はどのＣＷＮＤも減分しないので、ＣＷＮＤは、既に最大送信／受信ウィンドウサイズを超えている可能性が高く、したがって、この３００ｍｓ「ポーズ」によって止められ／停止される後続の複数の高速再送信パケットは、３００ｍｓがカウントダウンした時に、戻るＡＣＫ−クロッキングレートと同一のレートでのみ前方に転送されるのみである可能性が高い（しかし、幸運にもこの３００ｍｓポーズ期間中に累積されたすべての戻るＡＣＫを含む）＝＝＞この変更のうちで最も単純なものは、既に、Ｇｏｏｇｌｅ／Ｙａｈｏｏ／Ａｍａｚｏｎ／ＲｅａｌＰｌａｙｅｒ．．．などに関する「驚異的な」商業的成功となっているであろう。

既存ＲＦＣのＴＣＰソースコード変更及び単純化されたテストの概要（洗練２）：
「１．既存ＬｉｎｕｘＴＣＰが、輻輳ドロップイベント（ＣＷＮＤを半分にする３つのＤＵＰＡＣＫ及びＣＷＮＤを１にリセットするＲＴＯタイムアウト）の際にその代わりにＣＷＮＤを変更されないままにするために乗法的にＣＷＮＤを減らし（ＣＷＮＤ＝ＣＷＮＤ／２又はＲＴＯタイムアウトの際にはＣＷＮＤ＝１）、ＣＷＮＤに１をセットする（第３ＤＵＰＡＣＫ高速再送信をトリガするかＲＴＯタイムアウトをトリガするパケットの最新のＲＴＴ−ｍｉｎ（ＲＴＴ），３００ｍｓ）の最小値「ポーズ」カウントダウンをセットし、カウントダウンされた後にＣＷＮＤをオリジナルの値に復元する場合には、必ず、半分にされた又は「１」のＣＷＮＤ値ではなくオリジナルのＣＷＮＤ値をＳＳＴｈｒｅｓｈにセットすることもしなければならない → これは、０．３秒「ポーズ」する簡単な実施態様と正確に同等である」。

注：この形で、パケットドロップイベントが、ドロップを引き起こす期待される通常の完全なバッファ枯渇（通常のバッファサイズは３００ｍｓである）ではなく、物理送信エラー／ＢＥＲによってトリガされる場合に、変更されたＬｉｎｕｘＴＣＰは、前方への転送のいずれをも、全く、不必要に「ポーズ」させず、停止させない：パケットドロップがＢＥＲによって引き起こされ、リンクが輻輳していない場合には、「ポーズ」カウントダウンは、今や、永久に連続する３００ｍｓの永久「ポーズ」をループするのではなく、正しく０ｍｓをセットされる。パケットドロップイベントをシミュレートする、より以前のＩＰＣＨＡＩＮ法は、輻輳又は満杯バッファ枯渇イベントに全く対応しないことに留意されたい。

しかし、下の、より以前の変更仕様は、それでも働くが、テストベッドは、今や、その代わりに下記でなければならない。

例えば１ｍｂｓリンクを介するルータ１への５つの複数の大きいＦＴＰ及び／又は輻輳的トラフィックジェネレータ（又は例えば１．５秒おきの周期的な短い３００ｍｓＵＤＰ輻輳バースト生成とすることさえできる）を有する未変更のＬｉｎｕｘＴＣＰサーバ
↓ （１ｍｂｓリンク）
変更されたＬｉｎｕｘＴＣＰサーバ−＞（１ｍｂｓリンク）ルータ１（１ｍｂｓリンク）−＞既存ＬｉｎｕｘＴＣＰクライアント
ルータとクライアントとの間のリンクは、１ｍｐｓとすることができ（より大きいことが好ましい）、ルータは、１ｍｎｓ＊例えば０．３＊選択されたポーズ値／８＝４０Ｋバイト（すなわち、４０個の１Ｋバイトパケット）バッファサイズを有することができる。６４Ｋバイト（より大きいことが好ましい）のセンダ及びレシーバのウィンドウサイズ。注：この形で、すべてのパケットドロップ（１つ又は複数）イベントは、必ずフルバッファ枯渇シナリオに厳密に対応し、３００ｍｓの「ポーズ」は、今や、よく道理にかなう（又は、例えば非常に小さいバッファ容量が展開される、＝＜３００ｍｓの場合に、トリガするパケットのＲＴＴ−ｍｉｎ（ＲＴＴ）の「ポーズ」インターバル）。

最後に、ＩＰＣＨＡＩＮを用いる、より以前のテストベッドセットアップは、どの「ポーズ」も必要とせずにどのＣＷＮＤサイズも減分としないことと連動する＝＝＞１００％リンク利用度を示すが、アグレッシブ非ＴＣＰフレンドリである。

「１．既存ＬｉｎｕｘＴＣＰが、輻輳ドロップイベント（ＣＷＮＤを半分にする３つのＤＵＰＡＣＫ及びＣＷＮＤを１にリセットするＲＴＯタイムアウト）の際にその代わりにどのＣＷＮＤも変更されないままにするために乗法的にＣＷＮＤを減らす（ＣＷＮＤ＝ＣＷＮＤ／２又はＲＴＯタイムアウトの際にはＣＷＮＤ＝１）場合には、必ず、半分にされた又は「１」のＣＷＮＤ値ではなく未変更のＣＷＮＤ値をＳＳＴｈｒｅｓｈにセットすることもしなければならない＝＝＞これ自体は、ドロップレート及びＲＴＴ待ち時間に関わりなく、１００％に近いリンク利用度を保証する」。

レシーバベースド増分展開可能ＴＣＰフレンドリ外部インターネットＴＣＰ
変更
レシーバＴＣＰソースコードは、直接に変更することができ（あるいは、同様に、インターセプトモニタを、同一のことを実行する／同一のことにとりかかるように適合させる）、すべての既存ＲＦＣのＴＣＰを扱いさえする。

概要（さまざまな前に説明した技法ｔ及びサブコンポーネント技法をも参照されたい）［注：ＣＷＮＤサイズが一度達成されたので、どれほど大きくても、それ自体では輻輳ドロップを引き起こさないことは明らかである：輻輳パケット（１つ又は複数）ドロップの主原因であるのは、ＣＷＮＤサイズの「加速的瞬間的増加」、例えば指数関数的増大又は線形増大である（戻るＡＣＫ−クロッキングレート．．．）。

１．レシーバＴＣＰは、３つのＤＵＰＡＣＫを送信する際に、アルゴリズム的に決定された導出された個数／シリーズの複数の同一ＳＥＱＮｏのＤＵＰＡＣＫを即座に完遂し（そのような複数の同一ＳＥＱＮｏのＤＵＰＡＣＫの送信のレートも、センダＴＣＰのＣＷＮＤサイズを、したがって送信レートを望み通りに制御するためにアルゴリズム的に制御することができる）、したがって、センダＣＷＮＤサイズは、例えば高速再送信３ＤＵＰＡＣＫの時に半分にされないように．．．あるいは、経路輻輳レベル（輻輳していない／ある値の／ある値を超えるバッファ遅延の始まり、輻輳パケットドロップ．．．など）のレシーバによる検出に従う規定されたＣＷＮＤサイズ時限増分で、制御することができる。大きいウィンドウサイズ、パケットドロップを早期に検出するためのパケット到着間、レシーバウィンドウサイズの調整（例えば、センダの有効ウィンドウサイズ送信レートを完全にポーズさせるための「０」、したがって、レシーバウィンドウサイズは、今や、ＣＷＮＤではなくセンダの有効ウィンドウ送信レートを制御する）．．．など、さまざまな以前の技法と組み合わせることができる。レシーバは、センダのＣＷＮＤサイズトラッキング法を利用して、複数ＤＵＰＡＣＫ生成レートを判定するのを助けることもでき、センダが正確にどのＤＵＰＡＣＫがセンダＴＣＰで受信されたかについてレシーバに通知するように、生成されたあるＡＣＫに１バイトデータを含めることもできる。

又は
１．レシーバＴＣＰは、ある以前に受信されたＳｅｑＮｏに関するＡＣＫの送信を抑制し、したがって、センダＴＣＰは、今や、複数の同一ＳｅｑｎｏのＡＣＫの生成のレシーバのレート（望み通りにアルゴリズム的に導出される）で送信するのみになるようにされることができ（すなわち、センダのＣＷＮＤサイズ時限増分）、したがって、レシーバは、センダのレートを制御することができる → 効果的に、センダＴＣＰは、今や、ほとんど必ず高速再送信モードである。十分に大きいレシーバ及びセンダのウィンドウサイズがネゴシエートされれば、１つの同一のＳｅｑＮｏの複数のＤＵＰＡＣＫが、その１つの同一のＳｅｑＮｏシリーズのＤＵＰＡＣＫに留まりながらギガバイトを最後まで転送させることができ、あるいは、ＳｅｑＮｏは、センダのウィンドウエッジを「シフトする」ために、有効ウィンドウサイズ枯渇の前の任意の時に成功して受信されたより大きい（又は最大の）ＳｅｑＮｏに増分されてもよい（センダのＣＷＮＤサイズを常に十分に大きく保つ技法（１つ又は複数）と組み合わせることができる）。

及び／又は
１．レシーバＴＣＰは、絶対に３つのＤＵＰＡＣＫを生成せず、センダＲＴＯタイムアウトを再送信させるだけである（好ましくは、より長いＲＴＯタイムアウト期間がトリガされる前に止められた肯定応答されていない再送信によって止められないセンダの連続的再送信を保証するために、十分に大きいウィンドウスケールドサイズがネゴシエートされる）が、センダのＣＷＮＤは、ＲＴＯタイムアウトの際に「０」又は「１」にリセットされ、レシーバは、ＲＴＯタイムアウト再送信を検出した後の複数の続けられる同一のＤＵＰＡＣＫを介するセンダのＣＷＮＤのすばやい指数関数的増分復元を保証するためにこれを必要とする。
注：
．ルータは、バッファにより小さい大きさ．．．５０ｍｓなどを便利にセットすることができ（そのような小さいバッファセッティングの改善された効力に関する公表されたｇｏｏｇｌｅ検索リサーチレポートを参照されたい）、また、ＲＥＤ機構は、例えば、バッファリングされたパケット（１つ又は複数）レジデンシを有する任意のフロー（１つ又は複数）の例えばまさに最初のバッファリングされたパケットを例えば捨てるように適合させることができる → そのようなインターネットサブセット上でリアルタイム送信／ＴＣＰトラフィック入力レートを達成するのを助ける。また、ＴＣＰは、単純にレートスロットリングして／「ポーズ」して、すべてのバッファリングの始まりを即座にクリアする／すべてのバッファリングの始まりのクリアをイネーブルするために適当にＣＷＮＤサイズを減らすことができる。

．上記のレシーバＴＣＰは、好ましくは、ＳＡＣＫフィールドを使用して、複数のＤＵＰＡＣＫのシリーズの「クランプされた」同一のＳｅｑＮｏを超える受信されたＳＥｑＮｏのブロックを伝えることができ、さらに、ＳＡＣＫフィールドは、時折の後続の欠けている「ギャップ」パケットを伝えるのに利用することもできる（ＲＦＣは、３つのブロックをＳＡＣＫすることを許容し、ＳＡＣＫされたＳＥｑＮｏは、既存ＲＦＣのＴＣＰによって不必要に再送信はされない）。

．ここでのレシーバＴＣＰは、「ＳＡＣＫフィールドのブロック」技法、一連の同一ＳｅｑＮｏのＤＵＰＡＣＫの「時限」「クランプされた」ＳｅｑＮｏを生成する技法（したがって、有効ウィンドウサイズを制御するためにセンダのスライディングウィンドウＳｎｄ．ＵＮＡ値を制御し、センダのＣＷＮＤサイズを制御するために生成される同一ＳｅｑＮｏの複数のＤＵＰＡＣＫの個数も制御する）、レシーバウィンドウサイズをセットする技法、センダのＣＷＮＤサイズをトラッキングする技法．．．などを利用することができ、レシーバが、輻輳／バッファ枯渇パケットドロップの経路の始まり（ＯＴＴ時間がこれまでに記録されたｍｉｎ（ＯＴＴ）を超えるかどうか．．．で区別可能である、輻輳していない間のＢＥＲパケットドロップ（１つ又は複数）から区別可能）のレシーバによる監視に従って、センダのレート／有効ウィンドウサイズ／ＣＷＮＤサイズを制御し又は「ポーズ」することをイネーブルする。

さまざまな注
．多数のさまざまなおそらくは単純でさえある形で所望の変更を実施する、可能な説明されたサブコンポーネント法の多数の異なる形及びさまざまな異なる組合せがある。例えば、ネットワーク内のすべてのＴＣＰがすべて同様に変更される場合に、ネットワーク／インターネットサブセット（１つ又は複数）全体を通じたＰＳＴＮ様伝送品質を保証するために、例えば最新ＲＴＴ（又は適当な場合にＯＴＴ）−記録されたｍｉｎ（ＲＴＴ）（又は適当な場合にｍｉｎ（ＯＴＴ））のインターバルだけ、各すべてのＴＣＰセンダが単に「ポーズする」（又はレシーバベースドＴＣＰがセンダＴＣＰに「ポーズさせる」）ことは、非常に簡単である。上記の「ポーズ」の代わりに、変更されたＴＣＰは、例えば、バッファリングを引き起こすか必要とする可能性があるすべての余分なフライトパケット（リンク（１つ又は複数）の使用可能物理帯域幅容量より多くが、バッファリングの始まりを引き起こさずに対処することができる）を完全にクリアできるようにする（又は単にあるレベルだけバッファリングを減らす）ためにフライトパケットの総数が即座にできる限り速く減らされることを保証するためすなわち、すべての後続のまだ未解決のフライトパケットが今は経路に沿ったバッファリングを必要としない（又は単にあるレベルだけバッファリングを減らす）ことを保証するために、例えば考案される所望のアルゴリズムに応じて、そのＣＷＮＤサイズを例えばＣＷＮＤ＊（最新のＲＴＴ−ｍｉｎ（ＲＴＴ））／最新のＲＴＴ又は例えばＣＷＮＤ＊（最新のＲＴＴ−ｍｉｎ（ＲＴＴ））／ｍｉｎ（ＲＴＴ）．．．などにそれぞれ、代わりに減らすことができる。

．ネットワーク内のすべてのレシーバＴＣＰが、すべてそのように上で説明したように変更される場合に、レシーバＴＣＰは、考案される所望のアルゴリズム．．．例えばＲＴＴ（又はＯＴＴ）が現在の最新の記録されたｍｉｎ（ＲＴＴ）（又は現在の最新の記録されたｍｉｎ（ＯＴＴ））未満のままである限りの複数ＤＵＰＡＣＫレートすべてのＲＴＴ（又はＯＴＴ）の乗法増加及び／又は線形増加．．．などに従って、複数ＤＵＰＡＣＫの同一ＳｅｑＮｏシリーズ生成レート／スペーシング／一時的停止．．．などの全体的な完全な制御を介してセンダＴＣＰ送信レートの完全な制御を有することができる。さらに、ＲＴＴ（又はＯＴＴ）が、現在の最新の記録されたｍｉｎ（ＲＴＴ）（又は現在の最新の記録されたｍｉｎ（ＯＴＴ）より大きくなるすなわち輻輳の始まりが検出されたならば、レシーバベースドの変更されたＴＣＰ（又はインターセプトソフトウェア／転送するプロキシ．．．など）は、アルゴリズム的に考案された期間だけ「ポーズ」することができ、この期間中に、レシーバベースドの変更されたＴＣＰは、着信する新しいＳｅｑＮｏのパケット（１つ又は複数）と一致するのに必要なものと一致する（すなわち、着信する新しいＳｅｑＮｏのパケット（１つ又は複数）の１つごとに１つのＤＵＰＡＣＫを生成する）ためを除いて、追加の余分なＤＵＰＡＣＫの生成を「フリーズ」することができ、これは、余分なセンダの総フライトパケットの減少／クリア／経路に沿ったバッファリングの防止を可能にするはずである。

．レシーバベースドＴＣＰは、後に受信されるセンダのＡＣＫＮｏ及びＳｅｑＮｏ．．．などを使用して、ＲＴＴ／ＯＴＴ／総フライトパケット．．．などをレシーバが検出する／計算するのを助けるために、「選択されたマークされた」ＤＵＰＡＣＫ（１つ又は複数）に含められる例えば１バイトのガーベジデータを含むことができる。

２００５年１１月２１日ファイリング
さまざまな洗練及び注
増分展開可能ＴＣＰフレンドリ外部インターネット１００％リンク利用度データストレージ転送ＮｅｘｔＧｅｎＴＣＰ：
一番上の最も多いレベルで、ＣＷＮＤは、今、どれであっても絶対に決して全く減らされない。

Ｗｉｎｄｏｗｓデスクトップ「フォルダストリング検索」ファシリティを使用して、すべてのサブフォルダ／ファイル内のＣＷＮＤ変数の各すべての出現を突き止めることは簡単である．．．．．．ＲＴＯタイムドアウトの際に完全であるために．．．その輻輳が誘導した場合であっても、我々はＣＷＮＤを全く減らさない／リセットしない．．．．．
既存ＲＦＣの仕様を変更する、我々のＲＴＯタイムドアウトアルゴリズム擬似コードは、次のようになるはずである（「実際の輻輳ドロップ」表示について）。

Ｔｉｍｅｏｕｔ：／＊乗法減少＊／
．ｒｅｃｏｒｄｅｄＣＷＮＤ＝ＣＷＮＤ（しかし、別のＲＴＯタイムアウトが進行中の「ポーズ」中に発生する場合には、ｒｅｃｏｒｄｅｄＣＷＮＤ＝ｒｅｃｏｒｄｅｄＣＷＮＤ！／＊ＣＷＮＤサイズが減らされることを誤って引きこしたくはない＊／）。

．ｓｓｔｈｒｅｓｈ＝ｃｗｎｄ（しかし、別のＲＴＯタイムアウトが進行中の「ポーズ」中に発生する場合には、ＳＳｔｒｅｓｈ＝ｒｅｃｏｒｄｅｄＣＷＮＤ！／＊ＳＳＴｒｅｓｈサイズが減らされることを誤って引きこしたくはない＊／）。

．「ポーズ」インターバルを計算し、ＣＷＮＤ＝「１＊ＭＳＳ」をセットし、「ポーズ」がカウントダウンした後にＣＷＮＤ＝ｒｅｃｏｒｄｅｄＣＷＮＤに復元する；
既存ＲＦＣの仕様を変更する、我々のＲＴＯタイムドアウトアルゴリズム擬似コードは、次のようになるはずである（「非輻輳ドロップ」表示について）。

Ｔｉｍｅｏｕｔ：／＊乗法減少＊／
ｓｓｔｈｒｅｓｈ＝ｓｓｔｒｅｓｈ；
ＣＷＮＤ＝ＣＷＮＤ；
／＊両方が変更されない！＊／
ＲＦＣのＴＣＰがこれらの単純な経験則に従って変更したことを保証することだけが必要である：
１．「実際の輻輳」表示の際に「ポーズ」を一時的にもたらす（その後にＣＷＮＤをｒｅｃｏｒｄｅｄＣＷＮＤに復元する）ためを除いて、絶対に決してどのＣＷＮＤ値も減らさない。実際の輻輳表示（第３ＤＵＰＡＣＫの時又はＲＴＯＴｉｍｅｏｕｔ−ｍｉｎ（ＲＴＴ）＞例えば２００ｍｓの時の最新ＲＴＴ）の際に、ＳＳＴｒｅｓｈには、後続ＣＷＮＤ増分が加法的線形になるように、先在するＣＷＮＤがセットされる必要があることに留意されたい。

２．非輻輳表示（第３ＤＵＰＡＣＫの時又はＲＴＯＴｉｍｅｏｕｔ−ｍｉｎ（ＲＴＴ）＜例えば２００ｍｓの時の最新ＲＴＴ）の場合に、高速再送信モジュールとＲＴＯタイムドアウトモジュールとの両方について、「ポーズ」せず、既存ＲＦＣがＣＷＮＤ値又はＳＳｔｒｅｓｈ値を変更することを全く許可しない。

進行中の現在のポーズ（「実際の輻輳」表示によってトリガされたものであることだけができる）は、存在する場合に、カウンテッドダウンに進行することを許可されなければならない（高速再送信モジュールとＲＴＯタイムアウトモジュールとの両方について）。

３．既に、進行中の現在の「ポーズ」がある場合には、後続の介在する「実際の輻輳」表示は、今や、現在の「ポーズ」を完全に終了し、新しい「ポーズ」を開始する（単に新しい「ポーズ」カウントダウン値をセットする／上書きするという問題）：高速再送信モジュールとＲＴＯタイムアウトモジュールとの両方について、ｒｅｃｏｒｄｅｄＣＷＮＤは今や＝ｒｅｃｏｒｄｅｄＣＷＮＤ（＝ＣＷＮＤではなく）及び今やＳＳｔｒｅｓｈ＝ｒｅｃｏｒｄｅｄＣＷＮＤ（ＣＷＮＤではなく）であることを管理する。

非常に単純な基本的な働く第１バージョン完全仕様：ごく少数行の非常に単純なＦＲＥＥＢＳＤ／ＬＩＮＵＸＴＣＰソースコード変更
［当初に、非常に大きい初期化されたｍｉｎ（ＲＴＴ）値＝例えば３００００ｍｓをセットすることを必要とし、その後、継続的にｍｉｎ（ＲＴＴ）＝ｍｉｎ（最新の到着するＡＣＫのＲＴＴ，ｍｉｎ（ＲＴＴ））をセットする］。
１．１ＩＦ第３ＤＵＰＡＣＫＴＨＥＮ
ＩＦ３ＤＵＰＡＣＫ高速再送信の時の最新の戻るＡＣＫのＲＴＴ−現在の記録されたｍｉｎ（ＲＴＴ）＝＜例えば２００ｍｓ（すなわち、我々は、今、このパケットドロップがおそらくは「輻輳イベント」によって引き起こされ得ず、したがって不必要にＳＳｔｒｅｓｈにＣＷＮＤ値をセットしてはならないことを知る）ＴＨＥＮＣＷＮＤ／ＳＳＴｒｅｓｈ値を変更しない（すなわち、既存の高速再送信ＲＦＣで現在行われているようにＣＷＮＤ＝ＣＷＮＤ／２又はＳＳｔｈｒｓｈにＣＷＮＤ／２をセットすることすらしない）。

ＥＬＳＥＳＳＴｈｒｅｓｈを、この記録された既存のＣＷＮＤサイズと同一になるようにセットしなければならず（既存の高速再送信ＲＦＣのＣＷＮＤ／２ではなく）ＡＮＤ代わりに、既存ＣＷＮＤサイズのレコードを保持し、ＣＷＮＤ＝「１＊ＭＳＳ」をセットし、「ポーズ」カウントダウングローバル変数＝（第３ＤＵＰＡＣＫ高速再送信をトリガする又はＲＴＯタイムアウトをトリガするパケットの最新のＲＴＴ−ｍｉｎ（ＲＴＴ），３００ｍｓ）の最小値をセットする。

注：ＣＷＮＤ値＝１＊ＭＳＳをセットすることは、ＴＣＰが送信を再開する前に、経路に沿ったバッファリングされたパケットをクリアすることを可能にするために、まさに最初の高速再送信パケット再送信パケット（１つ又は複数）を除く、パケットのすべての前方への転送の所望の一時的ポーズ／停止を引き起こす］。

ＥＮＤＩＦ
ＥＮＤＩＦ
１．２「ポーズ」時間変数がカウントダウンした後に、ＣＷＮＤを、記録された前のＣＷＮＤ値に復元する（すなわち、センダは、今や、「ポーズ」が終わった後の通常の送信を再開することができる）。

２．１ＩＦＲＴＯタイムアウトＴＨＥＮ
ＩＦＲＴＯタイムドアウトの時の最新の戻るＡＣＫのＲＴＴ−現在の記録されたｍｉｎ（ＲＴＴ）＝＜例えば２００ｍｓ（すなわち、我々は、今、このパケットドロップがおそらくは「輻輳イベント」によって引き起こされ得ず、したがって不必要にＣＷＮＤ値を１＊ＭＳＳにリセットしてはならないことを知る）ＴＨＥＮＣＷＮＤ値を１＊ＭＳＳにリセットせず、ＣＷＮＤ値を全く変更しない（すなわち、現在、既存ＲＴＯタイムアウトＲＦＣで行われているようにＣＷＮＤをリセットすることさえ全く行わない）。

ＥＬＳＥその代わりに、既存ＣＷＮＤサイズのレコードを保持し、ＣＷＮＤ＝「１＊ＭＳＳ」をセットし、「ポーズ」カウントダウングローバル変数＝（ＲＴＯタイムドアウトの時のパケットの最新のＲＴＴ−ｍｉｎ（ＲＴＴ），３００ｍｓ）の最小値をセットしなければならない。

注：ＣＷＮＤ値＝１＊ＭＳＳをセットすることは、ＴＣＰが送信を再開する前に、経路に沿ったバッファリングされたパケットをクリアすることを可能にするために、ＲＴＯタイムドアウト再送信パケット（１つ又は複数）を除く、パケットのすべての前方への転送の所望の一時的ポーズ／停止を引き起こす］。

２．２「ポーズ」時間変数がカウントダウンした後に、ＣＷＮＤを、記録された前のＣＷＮＤ値に復元する（すなわち、センダは、今や、「ポーズ」が終わった後の通常の送信を再開することができる）。

以上、これで終了である！。

背景材料
．第３ＤＵＰＡＣＫ高速再送信をトリガするかＲＴＯタイムアウトをトリガするパケットの最新のＲＴＴは、最後の測定されたラウンドトリップ時間ＲＴＴに関する既存のＬｉｎｕｘＴＣＢで維持される変数からたやすく入手可能である。最小の記録されたｍｉｎ（ＲＴＴ）は、既存のＷｅｓｔｗｏｏｒｄ／ＦａｓｔＴＣＰ／ＶｅｇａｓＴＣＢで維持される変数からたやすく入手可能であるのみであるが、ｍｉｎ（ＲＴＴ）＝［ｍｉｎ（ＲＴＴ），最後の測定されたラウンドトリップ時間ＲＴＴの］の最小値を継続的に更新する２〜３行のコードを記述することは、十分に簡単であるに違いない参考文献：ｈｔｔｐ：／／ｗｗｗ．ｃｓ．ｕｍｄ．ｅｄｕ／〜ｓｈａｎｋａｒ／４１７−Ｎｏｔｅｓ／５−ｎｏｔｅ−ｔｒａｎｓｐｏｒｔＣｏｎｇＣｏｎｔｒｏｌ．ｈｔｍ：ＬｉｎｕｘＴＣＢによって維持されるＲＴＴ変数＜ｈｔｔｐ：／／ｗｗｗ．ｓｃｉｔ．ｗｌｖ．ａｃ．ｕｋ／ｒｆｃ／ｒｆｃ２９ｘｘ／ＲＦＣ２９８８．ｈｔｍｌ＞：ＲＴＯ計算ＧｏｏｇｌｅＳｅａｒｃｈ用語「ｔｃｐｒｔｔｖａｒｉａｂｌｅｓ」＜ｈｔｔｐ：／／ｗｗｗ．ｐｓｃ．ｅｄｕ／ｎｅｔｗｏｒｋｉｎｇ／ｐｅｒｆ＿ｔｕｎｅ．ｈｔｍｌ＞：ＬｉｎｕｘＴＣＰＲＴＴパラメータのチューニングＧｏｏｇｌｅＳｅａｒｃｈ：「ｌｉｎｕｘＴＣＰｍｉｎｉｍｕｍｒｅｃｏｒｄｅｄＲＴＴ」又は「ｌｉｎｕｘｔｃｐｍｉｎｉｍｕｍｒｅｃｏｒｄｅｄｒｔｔｖａｒｉａｂｌｅ」注：ＴＣＰＷｅｓｔｗｏｏｄは最小ＲＴＴを測定する。
注：
１．上記の「輻輳通知トリガイベント」は、代替案では、最新のＲＴＴ−ｍｉｎ（ＲＴＴ）＞＝指定されたインターバル、例えば５ｍｓ／５０／３００ｍｓｍｓ．．．などの時と定義することができる（パケットドロップ表示イベントではなく、純非輻輳ＲＴＴ又はその推定ｍｉｎ（ＲＴＴ）上及びこれを超える経路に沿って経験されたバッファリングによって導入される遅延に対応する。

２．実際の輻輳ドロップ（１つ又は複数）表示によってトリガされた「ポーズ」がカウントダウンし終えたならば、上記のアルゴリズム／方式を適合させ、その結果、ＣＷＮＤに、今、この瞬間的な「ポーズ」カウンテッドダウンタイムでの総未解決フライトパケット数と等しい（すなわち、最新の最大の転送されたＳｅｑＮｏ−最新の最大の戻るＡＣＫＮｏと等しい）値がセットされるようにする → これは、パケットの突然の大きいバーストがソースＴＣＰによって生成されるのを防ぐはずである。というのは、「ポーズ」期間中に、スライディングウィンドウのエッジを非常に実質的に進めた可能性がある受信された多数の戻るＡＣＫがある可能性があるからである。

また、多数の可能なものの中の代替の例として、ＣＷＮＤには、当初に、「ポーズ」カウントダウンをトリガする第３ＤＵＰＡＣＫ高速再送信要求の際に、未変更のＣＷＮＤ（「１＊ＭＳＳ」ではなく）又はまさにこの瞬間の総未解決フライトパケット数と等しい値のいずれかをセットすることができ、さらに、「ポーズ」がカウントダウンし終えた時にこの瞬間的総未解決フライトパケット数［任意選択で、この瞬間的「ポーズ」カウンテッドダウンタイムで「ポーズ」がカウントダウンする前に受信された総数追加同一ＳｅｑＮｏ複数ＤＵＰＡＣＫ（高速再送信をトリガする最初の３つのＤＵＰＡＣＫを超える）を引く（すなわち、まさにこの瞬間の最新の最大の転送されたＳｅｑＮｏ−最新の最大の戻るＡＣＫＮｏと等しい）］と等しい値に復元することができる → 変更されたＴＣＰは、今、「ポーズ」インターバル中に受信された各追加の複数の同一ＳｅｑＮｏのＤＵＰＡＣＫに対応する新しいパケットをネットワークにストロークアウトすることができ、ＣＷＮＤが、今、「ポーズ」がカウントダウンし終えた時に、今の瞬間的総未解決フライトパケット数引く「ポーズ」中に受信された総数追加同一ＳｅｑＮｏ複数ＤＵＰＡＣＫと等しい値に復元された場合に、経路に沿った介在するバッファリングをクリアするために、「ポーズ」がカウントダウンした後に、任意選択として遅れ馳せに送信レートを「スローダウン」することができる。

もう１つの可能な例は、ＣＷＮＤに、当初に、「ポーズ」カウントダウンをトリガする第３ＤＵＰＡＣＫ高速再送信要求の際に「１＊ＭＳＳ」をセットし、その後、「ポーズ」がカウントダウンし終えた時に、この瞬間的総未解決フライトパケット数引く総数追加同一ＳｅｑＮｏ複数ＤＵＰＡＣＫと等しい値に復元することである→この形で、「ポーズ」がカウントダウンした時に、変更されたＴＣＰは、新しいパケットを「バースト」アウトするのではなく、後続の新しい戻るＡＣＫレートに対応する新しいパケットのネットワークへのストロークアウトを開始するだけである。

３．上記のアルゴリズム／方式の、上記の「ポーズ」カウントダウングローバル変数＝（第３ＤＵＰＡＣＫ高速再送信をトリガするかＲＴＯタイムアウトをトリガするパケットの最新のＲＴＴ−ｍｉｎ（ＲＴＴ），３００ｍｓ）の最小値は、その代わりに＝（第３ＤＵＰＡＣＫ高速再送信をトリガするかＲＴＯタイムアウトをトリガするパケットの最新のＲＴＴ−ｍｉｎ（ＲＴＴ），３００ｍｓ，ｍａｘ（ＲＴＴ））の最小値をセットすることができ、ここで、ｍａｘ（ＲＴＴ）は、これまでに観察された最大のＲＴＴである。このｍａｘ（ＲＴＴ）の包含は、ノードのバッファ容量が極端に小さい（例えば、ＬＡＮ内又はＷＡＮ内でさえ）非常に希なありそうにない状況であっても、「ポーズ」期間が、例えば指定された３００ｍｓ値など、不必要に大きくなりすぎるようにセットされないことを保証するためである。また、上記の例の３００ｍｓではなく、この値を、その代わりに、異なる経路ごとに動的にアルゴリズム的に導出することができる。

４．準備のできたギャランティードサービス対応ネットワーク（又は単に輻輳ドロップのないネットワーク及び／又は単にはるかにより少ないバッファリング遅延を有するネットワーク）の簡単な広く行き渡った実施を可能にする単純な方法は、ネットワーク内の１ノードのすべての（又はほとんどすべての）ルータ及びスイッチを変更して／ソフトウェアアップグレードして、トラバースするＴＣＰフローのソースへの３つのＤＵＰＡＣＫの全体を即座に生成して、そのソースに、トラバースするＴＣＰフローのパケットをノードがバッファリングし始める（すなわち、転送するリンクは、今、１００％利用されており、総計としてのトラバースするＴＣＰフローのソースのパケットが、バッファリングされ始める）時にその送信レートを減らすように示すことであるはずである。３ＤＵＰＡＣＫ生成は、その代わりに、例えば転送するリンクが指定された利用度レベル、例えば９５％／９８％．．．など又は指定されたある他のトリガ条件に達する時に、トリガすることができる。３つの擬似ＤＵＰＡＣＫに対応するパケットが、デスティネーションで実際に正しく受信されるかどうかすら問題ではない。というのは、デスティネーションからソースへの後続ＡＣＫが、これを矯正するからである。

生成された３つのＤＵＰＡＣＫパケットのフィールドは、最小の必要なソースアドレス、デスティネーションアドレス、及びＳｅｑＮｏを含む（これは、今現在バッファリングされているパケット（１つ又は複数）を検査し、３つの擬似ＤＵＰＡＣＫのＡＣＫフィールドが検査されたバッファリングされたパケットのＡＣＫＮｏから入手される／又は導出されることを世話することによってたやすく得ることができる）。ところが、擬似の３つのＤＵＰＡＣＫのＡＣＫＺＮｏフィールドは、特定の一方向ソース／デスティネーションＴＣＰフロー（１つ又は複数）のデスティネーションＴＣＰによって生成された最新の最大のＡＣＫＮｏの、例えばスイッチ／ルータの維持されるテーブルから入手する／又は導出することができ、あるいはその代わりに、スイッチ／ルータは、まず、デスティネーションからソースへのパケットがそのノードに到着するのを待って、次に、戻るパケットのＡＣＫフィールドを検査することから３つの擬似ＤＵＰＡＣＫのＡＣＫＮｏフィールドを入手する／又は導出することができる。

上記の方式に似て、既存のＲＥＤ及びＥＣＮ．．．などは、同様に、上で概要を示したように変更されたアルゴリズムを有し、リアルタイムギャランティードサービス対応ネットワーク（又は輻輳ドロップなし及び／又ははるかにより少ないバッファ遅延のネットワーク）を使用可能にすることができる。

５．ｗｉｎｄｏｗｓでのもう１つの変形実施態様：
まず、モジュールが、ＭＳＴＣＰからすべての高速再送信／ＲＴＯタイムアウトを引き継ぐすなわち、ＭＳＴＣＰが絶対に決してＤＵＰＡＣＫもＲＴＯタイムアウトも一切見ないことを必要とする：モジュールは、単純に、ＭＳＴＣＰからの肯定応答されたすべてのインターセプトされた新しいパケットをスプーフィングする（後にのみ：且つ、必要な場合に、ＭＳＴＣＰに「０」ウィンドウサイズ更新を送信するか、着信ネットワークパケットのウィンドウサイズフィールドを「０」に変更して、ＭＳＴＣＰパケット生成をポーズさせる／スローダウンさせる：輻輳通知、例えば３ＤＵＰＡＣＫ又はＲＴＯタイムアウトの際に）。モジュールは、すべての転送されるパケットのＳｅｑＮｏ／パケットコピー／ｓｙｓｔｉｍｅのリスト（ＳｅｑＮｏで明確に順序付けられる）を構築し、このリストから高速再送信／ＲＴＯ再送信を行う。ＳｅｑＮｏ＜現在の最大の受信されたＡＣＫを有するこのリスト上のすべてのアイテムが、除去され、ＳＡＣＫされたすべてのＳｅｑＮｏも除去される。

このモジュールに「ＳｅｑＮｏラップアラウンド」保護及び「タイムラップアラウンド」保護を組み込む必要があることもお忘れなく。

すべてのインターセプトされたＭＳＴＣＰ発信パケットの肯定応答をスプーフィングすることによって、我々のｗｉｎｄｏｗｓソフトウェアは、今、ＭＳＴＣＰへの着信ネットワークパケットのどれをも全く変更することを必要としない．．．ＭＳＴＣＰは、単純にすべての受信された３つのＤＵＰＡＣＫが既にスライディングウィンドウの外にある（既に肯定応答されている！）のでこれらを無視し、タイムアウトしたパケットを送信せず（既に肯定応答されている！）、さらに、我々は、今や、レシーバウィンドウサイズフィールド変更．．．などを介してＭＳＴＣＰパケット生成レートをいつでも簡単に制御することができる。ソフトウェアは、任意の時に、フライトパケットの最大値がエミュレートされた／追跡されたＭＳＴＣＰのＣＷＮＤサイズと等しくなることを可能にすることによって、ＭＳＴＣＰ自体のＷｉｎｄｏｗｓ増分／輻輳制御／ＡＩＭＤ機構をエミュレートすることができる：概要の輪郭の例（多数の可能なものの中の）として、これは、例えば、各戻るＡＣＫについて、エミュレートされた／追跡された擬似ミラーＣＷＮＤサイズが、３ＤＵＰＡＣＫ高速再送信がまだない時に各ＲＴＴ内で２倍にされるが、３ＤＵＰＡＣＫ高速再送信が発生したならば、エミュレートされた／追跡された擬似ミラーＣＷＮＤサイズが、今やＲＴＴごとに１＊ＭＳＳだけ増分されるのみであると仮定することによって達成することができる。ソフトウェアは、瞬間総未解決フライトパケット数の最大値が、エミュレートされた／追跡された擬似ＣＷＮＤサイズを超えないことを可能にし、擬似ＣＷＮＤサイズを超える時にＭＳＴＣＰ送信を「ポーズ」させるために「０」のレシーバウィンドウサイズ更新／着信パケットのレシーバウィンドウサイズを「０」に変更することを介してＭＳＴＣＰパケット生成をスロットリングするだけであるはずである。

このＷｉｎｄｏｗソフトウェアは、その後、最新の最大の前方に転送されたＭＳＴＣＰパケットのＳｅｑＮｏ及び最新の最大のネットワークの着信パケットのＡＣＫＮｏ（その差は、ＭＳＴＣＰのＣＷＮＤ値に全く非常によく対応する未解決の総フライトパケット数を与える）を追跡することによって、常にＭＳＴＣＰＣＷＮＤサイズを記憶するか推定することができる。ここでのＷｉｎｄｏｗソフトウェアは、フライトパケットの総数＞＝上で述べたＣＷＮＤ推定値（又は、代替的に、上記のＣＷＮＤ推定値及びＲＷＮＤ及び／又はＳＷＮＤから導出される有効ウィンドウサイズ）になったならば、ＭＳＴＣＰへの「ＡＣＫの自動スプーフィング」を確実に停止するようにすることだけが必要である。

Claims

ＴＣＰ及び／又はＴＣＰ様プロトコル及び／又は他のプロトコルを改善する方法であって、輻輳パケットドロップなどの輻輳イベントが検出される時及び／又は戻るＡＣＫのラウンドトリップ時間ＲＴＴ／一方向トリップ時間ＯＴＴが例えばフロー経路の非輻輳ＲＴＴ／ＯＴＴ又はその最新の使用可能な最良の推定値ｍｉｎ（ＲＴＴ）／ｍｉｎ（ＯＴＴ）の既知の値などのある閾値に近くなるかこれを超える時に、センダのデータ送信の完全な又は部分的な「ポーズ」／「一時停止」を介してネットワーク輻輳を回避し且つ／又は防止し且つ／又はそれから回復する方法。
ＴＣＰ及び／又はＴＣＰ様プロトコル及び／又は他のプロトコルを改善する方法であって、（ａ）から（ｃ）、すなわち：
（ａ）ＴＣＰのスライディングウィンドウ機構の「有効ウィンドウ」及び／又は輻輳ウィンドウＣＷＮＤが、輻輳を回避し且つ／又は防止し且つ／又はそれから回復するためにサイズが減らされる必要がないことの新しい実現／技法をよく利用し、
（ｂ）輻輳パケットドロップなどの輻輳イベントが検出される時及び／又は戻るＡＣＫのラウンドトリップ時間ＲＴＴ／一方向トリップ時間ＯＴＴが、例えばフロー経路の非輻輳ＲＴＴ／ＯＴＴ又はその最新の使用可能な最良の推定値ｍｉｎ（ＲＴＴ）／ｍｉｎ（ＯＴＴ）の既知の値などのある閾値に近くなるかこれを超える時に、センダのデータ送信の完全な又は部分的な「ポーズ」／「一時停止」を介して、その代わりに輻輳が回避され且つ／又は防止され且つ／又はそれから回復され、
（ｃ）上記の（ｂ）ではなく、又はその代わりに、又はそれと組み合わせて、ＴＣＰのスライディングウィンドウ機構の「有効ウィンドウ」及び／又は輻輳ウィンドウＣＷＮＤ値が、輻輳が検出される時の最新の返されたラウンドトリップ時間ＲＴＴ／一方向トリップ時間ＯＴＴ値、及び／又は特定のフロー経路の既知の非輻輳ラウンドトリップ時間ＲＴＴ／一方向トリップ時間ＯＴＴ値若しくはその最新の使用可能な最良の推定値ｍｉｎ（ＲＴＴ）／ｍｉｎ（ＯＴＴ）、及び／又は特定のフロー経路の最新の観察された最長のラウンドトリップ時間ｍａｘ（ＲＴＴ）／一方向トリップ時間ｍａｘ（ＯＴＴ）に少なくとも部分的に依存してアルゴリズム的に導出される値まで減らされる
の任意の組合せ／サブセットを含む方法。
事実上輻輳のないギャランティードサービス対応データ通信ネットワーク／インターネット／インターネットサブセット／プロプラエタリインターネットセグメント／ＷＡＮ／ＬＡＮ（以下ではネットワークと称する）の方法であって、特徴（ａ）から（ｆ）、すなわち：
（ａ）ネットワーク内のソースから送信されネットワーク内のデスティネーションに到着するすべてのパケット／データユニットが、ネットワーク輻輳に起因して単一のパケットが捨てられることなしにすべてが到着する点と、
（ｂ）ギャランティードサービス機能性を必要とするすべてのパケット／データユニットにのみ適用される点と、
（ｃ）前記パケット／データユニットのトラフィックが、前方に転送される前にインターセプトされ、処理される点と、
（ｄ）前記送信する１つ又は複数のソースのトラフィックが、インターセプトされ処理され、前方に転送され、且つ／又は前記パケット／データユニットのトラフィックが、起点の送信する１つ又は複数のソースでインターセプトされ処理され、前方に送信されるのみである点と、
（ｅ）送信するソース及び／又は受信するデスティネーションでの既存のＴＣＰ／ＩＰスタックが、既存のＱｏＳ／ＭＰＬＳ技法の使用を必要とせず、前記ネットワーク内のスイッチ／ルータソフトウェアのいずれかがエンドツーエンド性能結果を達成するために変更され又は寄与することを必要とせず、前記ネットワーク内の各すべてのノード間リンクでの制限されない帯域幅の提供を必要とせずに、前記ネットワーク内の任意のソース／デスティネーションノード対の間で同一のエンドツーエンド性能結果を達成するために変更される点と、
（ｆ）前記ネットワーク内のトラフィックがほとんどＴＣＰトラフィックからなり、ＵＤＰ／ＩＣＭＰ．．．などの他のトラフィックタイプが、いつでも前記ネットワーク内の１つ又は複数のノード間リンクのいずれかの使用可能帯域幅全体を超えず、他のトラフィックタイプを生成するアプリケーションが、いつでも前記ネットワーク内の１つ又は複数のノード間リンクのいずれかの使用可能帯域幅全体を超えない場合に、ＵＤＰ／ＩＣＭＰ．．などの他のトラフィックタイプが、任意の時に前記ネットワーク内の１つ又は複数のノード間リンクのいずれかの使用可能帯域幅全体を超えるならば、前記ネットワーク内のそのように影響される１つ又は複数のノード間リンクをトラバースするソース／デスティネーションノード対トラフィックだけが、必ずしも、この時間中に事実上輻輳のないギャランティードサービス対応ではなくなり、且つ／又は前記ネットワーク内のソースから送信され前記ネットワーク内のデスティネーションに到着するすべてのパケット／データユニットが、必ずしも、すべてが到着しない、すなわち、１つ又は複数のパケットが、ネットワーク輻輳に起因して捨てられる点と
の任意の組合せ／サブセットを伴う方法。
前記方法において、前記プロトコルの改善／変更が、センダＴＣＰでもたらされる請求項１から３のいずれか１項に記載の方法。
前記方法において、前記プロトコルの改善／変更が、レシーバ側ＴＣＰでもたらされる請求項１から３のいずれか１項に記載の方法。
前記方法において、前記プロトコルの改善／変更が、前記ネットワークのスイッチ／ルータノードでもたらされる請求項１から３のいずれか１項に記載の方法。
前記プロトコルの改善／変更が請求項４から６のいずれか１項で指定される位置の任意の組合せでもたらされる方法。
前記プロトコルの改善／変更が請求項４から６のいずれか１項で指定される位置の任意の組合せでもたらされる方法であって、前記方法において、既存の「ランダム早期検出」ＲＥＤ及び／又は「明示的輻輳通知」ＥＣＮが請求項１から７のいずれか１項で開示される効果を与えるために変更／適合される方法。
前記ネットワーク内の前記スイッチ／ルータが請求項１から８のいずれか１項で開示される効果を与えるために、例えばバッファサイズ調整など、その構成又はセットアップ又は動作において調整される請求項１から８のいずれか１項に記載の方法。
前記方法において、
．既存プロトコルＲＦＣは、センダのＣＷＮＤ値が、検出された輻輳の際にセンダのデータ送信の「ポーズ」／「停止」を一時的にもたらす（例えば、「ポーズ」／「停止」中に一時的にセンダのＣＷＮＤ＝１＊ＭＳＳをセットし、「ポーズ」／「停止」が完了した後に、センダのＣＷＮＤ値を例えば「ポーズ」／停止の前の既存のＣＷＮＤ値又はあるアルゴリズム的に導出された値に回複することによって）ためを除いて、今はどれもが絶対に減らされず／減分されないように変更され、前記「ポーズ」／「停止」のインターバルは、例えば任意の３００ｍｓをセットされるか、Ｍｉｎｉｍｕｍ（第３ＤＵＰＡＣＫ高速再送信をトリガする戻るＡＣＫパケットの最新のＲＴＴ若しくはＲＴＯタイムアウトした時の戻るＡＣＫパケットの最新のＲＴＴ，３００ｍｓ）など、アルゴリズム的に導出されるか、Ｍｉｎｉｍｕｍ（第３ＤＵＰＡＣＫ高速再送信をトリガする戻るＡＣＫパケットの最新のＲＴＴ若しくはＲＴＯタイムアウトした時の戻るＡＣＫパケットの最新のＲＴＴ，３００ｍｓ，ｍａｘ（ＲＴＴ））など、アルゴリズム的に導出されることができ、
且つ／又は
．既存のプロトコルＲＦＣは、ＳＳＴｈｒｅｓｈが、その代わりに今は、「ポーズ」／「停止」をトリガする輻輳検出の前の既存ＣＷＮＤ値をセットされるように変更され、すなわち、後続ＣＷＮＤ増分は、ＣＷＮＤ値を超えて線形加法的であるのみである
請求項１から９のいずれか１項に記載の方法。
前記方法において、前記輻輳検出が、非輻輳ドロップ、例えば物理送信エラー、すなわちＢＥＲに起因する、すなわち、輻輳パケットドロップに起因しない場合に、「ポーズ」／「停止」カウントダウンインターバルは、その代わりに「０」をセットされ、すなわち、データ送信の実際の「ポーズ」／「停止」は開始されず、また、進行中のすべての先在する現在の「ポーズ」／「停止」は、カウンテッドダウンに通常に進行することを許可されることに留意されたく、輻輳検出は、例えば第３ＤＵＰＡＣＫが高速再送信をトリガする時の最新の返されたＡＣＫのＲＴＴ又はＲＴＯタイムアウトした時の最新の返されたＡＣＫのＲＴＴ−ｍｉｎ（ＲＴＴ）＜例えば２００ｍｓである場合に、輻輳以外の理由に帰することができる請求項１０に記載の方法。
前記方法において、進行中の現在の「ポーズ」／「停止」が既にある場合に、後続の「実際の」輻輳イベント表示は、今や、前記現在の「ポーズ」／「停止」のインターバルを拡張し、単に、前記現在の「ポーズ」／「停止」のカウントダウンに、例えばＭｉｎｉｍｕｍ（第３ＤＵＰＡＣＫ高速再送信をトリガする戻るＡＣＫパケットの最新のＲＴＴ若しくはＲＴＯタイムアウトした時の戻るＡＣＫパケットの最新のＲＴＴ，３００ｍｓ，ｍａｘ（ＲＴＴ））などの新しい値をセットし／これに上書きする請求項１０から１１に記載の方法。
前記方法において、
ノードが前記トラバースするＴＣＰフローのパケットのバッファリングを開始する（すなわち、転送するリンクが、今や、１００％利用され、総計としてのトラバースするＴＣＰフローの「ソースの」パケットが、バッファリングされ始める）時に送信レートを減らすように前記ソースに示すために前記トラバースするフローのソースへの３つのＤＵＰＡＣＫの全体を即座に生成するために変更され／ソフトウェアアップグレードされなければならない前記ネットワーク内のノードのルータ及びスイッチのいずれか１つ又はすべて又はほとんどすべて：前記３つのＤＵＰＡＣＫの生成は、代替案では、その代わりに、例えば前記転送するリンクが、指定された利用度レベル、例えば９５％／９８％．．．など又は指定されたある他のトリガ条件に達する時にトリガすることができる
請求項１から１２のいずれか１項に記載の方法。
前記方法において、
既存のＲＥＤ及びＥＣＮは請求項１から１３のいずれか１項に含まれる原理及び方式で概要を示されたようにそのアルゴリズムを同様に変更され、リアルタイムギャランティードサービス対応ネットワーク（又は、輻輳ドロップのない、及び／若しくははるかにより少ないバッファ遅延のネットワーク）を可能にする
請求項１，２，７，及び９から１３のいずれか１項に記載の方法。