|
Network Working Group Request for Comments: 2414 Category: Experimental |
M. Allman NASA Lewis/Sterling Software S. Floyd LBNL C. Partridge BBN Technologies September 1998 |
このドキュメントは、インターネット社会の為の実験的プロトコルを定義している。このメモは、いかなる種類のインターネット標準も規定しない。改善の為の議論と提案が求められる。このメモの配布は制限されない。
Copyright (C) The Internet Society (1998). All Rights Reserved.
このドキュメントは、TCP の許された初期ウィンドウを 1 セグメントから大体 4K バイトに増やすことを規定する。このドキュメントはこの変更の長所と短所を論じ、TCP に対するこの変更のコストと利益を示す実験結果の概要を示している。
Table of Contents
用語
1. TCP の修正
2. 実装問題
3. 大きい初期ウィンドウの利点
4. 個別のコネクションにおける大きい初期ウィンドウの欠点
5. ネットワークにおける大きい初期ウィンドウの欠点
6. TCP トラフィック爆発の典型的なレベル
7. シミュレーションと実験結果
7.1 大きい初期ウィンドウを使用する TCP コネクションの研究
7.2 大きい初期ウィンドウを使用するネットワークの研究
8. セキュリティの考慮
9. 結論
10. 謝辞
11. 参照
12. 作者のアドレス
13. 付録 - 重複セグメント
14. 完全なコピーライト宣言
このドキュメント中のキーワードである "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL" は、RFC 2119 [RFC2119] で説明されている様に解釈される。
このドキュメントは、許された TCP の初期ウィンドウの上限を 1 セグメントから 2 〜 4 セグメントに増やすことを規定する。ほとんどの場合、この変更により (大きいセグメントサイズの提供により、2 セグメントの許された初期ウィンドウは暗黙的に 4K バイトより大きいが)、 結果として初期ウィンドウの上限が大体 4K バイトになる。初期ウィンドウの上限は、より正確には (1) で提示される。
min (4*MSS, max (2*MSS, 4380 bytes)) (1)
同様に、初期ウィンドウサイズの上限は、以下の様に最大セグメントサイズ (MSS) に基づいている。
If (MSS <= 1095 bytes)
then win <= 4 * MSS;
If (1095 bytes < MSS < 2190 bytes)
then win <= 4380;
If (2190 bytes <= MSS)
then win <= 2 * MSS;
この増やされた初期ウィンドウはオプションであり、TCP は大きい初期ウィンドウで開始してよく (MAY)、これは SHOULD ではない。
初期ウィンドウサイズの上限は、輻輳ウィンドウが 1 セグメントに初期化されることを規定する RFC 2001 [S97] からの変更を表す。もし実装経験で成功したならば、この変更の意図は RFC 2001 への改訂に取り入れられる。
この変更は、TCP 3 方向ハンドシェークに続く一番最初の転送の往復時間 (RTT: round trip time) におけるコネクションの初期ウィンドウに適用される。3 方向ハンドシェーク中の SYN/ACK もその肯定応答 (ACK) も (1) の式で概説された、上記の初期ウィンドウサイズに拡大すべきである。もし SYN か SYN/ACK が消失したら、送信側によって使用される初期ウィンドウサイズは、正常に SYN が送信された後、1 セグメントでなければならない (MUST)。
TCP 実装体は、3 つの異なる方法でスロースタートを使用する。(1) 新しいコネクションを開始する (初期ウィンドウ)。(2) 長いアイドル時間の後に転送を再開する (ウィンドウの再開)。(3) 再送タイマ後に再開 (ウィンドウ欠損)。このドキュメントで提案されている変更は、初期ウィンドウの値に影響する。オプションで、TCP は再開ウィンドウに初期ウィンドウと cwnd の現在の値として使用される最小値を設定してもよい (MAY)。(言い換えると、再開ウィンドウに大きい値を使用することは cwnd のサイズを決して増やさない)。これらの変更は欠損ウィンドウを変更しない (NOT)。それは 1 セグメントのままでなければならない (サーバ輻輳の場合に、可能な最も低いウィンドウサイズを許すために)。
大きい初期ウィンドウがパス MTU 検出 [MD90] に従って実装され、使用される MSS が大き過ぎることが判明した時、輻輳ウィンドウである cwnd は、小さいセグメントの突発的な流入を避けるために減らすべきである (SHOULD)。特に cwnd は古いセグメントサイズ対新しいセグメントサイズの割合で減らすべきである (SHOULD)。
大きい初期ウィンドウがパス MTU 検出 [MD90] に従って実装された場合、初期ウィンドウ内の全てのセグメントに "フラグメント不可 (DF)" ビットを設定するか、"フラグメント不可 (DF)" をセグメントの一つに設定するかの選択肢がある。これら二つの選択肢のどちらが最善かについては、オープンな問題である。実装経験による解決を期待したい。全てのセグメントに DF ビットを設定する最初のケースでは、もし最初のパケットが大きすぎるとネットワークで欠損するだろう。一つのセグメントにしか DF ビットを設定しない二番目のケースでは、もし最初のパケットが大きすぎると最初以外のパケットはネットワークで分割されるだろう。二番目のケースに従う場合、初期ウィンドウ内の最後のセグメントに DF ビットを設定すると、初期セグメントサイズが大き過ぎると判明した時、不必要な再送の機会が少なくなる。なぜなら、早期再送を引き起こす重複 ACK の機会が少ないからである。しかし、大きい初期ウィンドウとパス MTU 検出との間の相互動作に、より多くの注意を払う必要がある。
このドキュメントで提案された大きい初期ウィンドウは、ウェッブブラウザが複数の TCP コネクションを同時に同じ宛先にオープンすることを奨励する意図はない。ウェッブブラウザが TCP コネクションを同じ宛先に同時にオープンする時、これは初期ウィンドウのサイズに関わらず、TCP の輻輳制御メカニズム [FF98] に逆らって作用する。この振る舞いを大きい初期ウィンドウと結合すると、不公平な他のトラフィックをネットワーク中に更に増やす。
高い輻輳環境では、特に膨大なトラフィックに対して偏りを持つルータ (通常ドロップテイルキューで) にとって、TCP コネクションは時々 1 セグメントの初期ウィンドウで開始する方がより都合がよいことがある。4 セグメントの初期ウィンドウで開始した TCP コネクションの場合、小規模な突発的流入を扱う能力をルータが持たないために不必要な再送を経験するかもしれない一方で、1 セグメントの初期ウィンドウからスロースタートする TCP コネクションの場合は、セグメントの欠損が無いというシナリオがある。これは不必要な再送タイムアウトを結果として引き起こし得る。再送タイムアウト無しで回復できる大きいウィンドウのコネクションでは、これはスロースタートからウィンドウ増加アルゴリズムの輻輳回避フェーズへの不必要に早い遷移を結果として引き起こし得る。これらの早すぎるセグメント欠損は、十分なバッファリングを持つ輻輳の無いネットワークや、輻輳したルータが活性キュー管理 (例えばランダム早期検出 [FJ93], [RFC2309]) を使用する適度な輻輳ネットワークでは発生しないようである。
たとえ初期ウィンドウの突発的流入が結果として早過ぎるセグメント欠損を引き起こしても、幾つかの TCP コネクションはより高い初期ウィンドウでより良いパフォーマンスを得られる。もし (1) TCP コネクションが再送タイムアウト無しでセグメント欠損から回復する、(2) TCP コネクションが、ネットワーク輻輳か受信側より通知されたウィンドウのいずれかによって小さい輻輳ウィンドウに最終的に制限されるならば、これは真である。
輻輳崩壊の可能性の意味において、ネットワークに対する別の二つの潜在的な危険性が考えられる。最初の危険性は、輻輳したリンク上の膨大な個数のセグメントが、受信側で既に受信した重複セグメントであるというシナリオだろう。二番目の危険性は、輻輳したリンク上の膨大な個数のセグメントが、最終宛先に到達する前に後でネットワーク中で欠損するであろうセグメントであるというシナリオである。
ネットワーク中の他のトラフィック上での否定的効果の意味において、大きい初期ウィンドウの潜在的短所は、それらがネットワーク中の一般的なパケット欠損率を増やすことである。これらの三つの問題を以下に論じる。
重複セグメント:
前のセクションで説明されているように、もし送信側が一セグメントの初期ウィンドウからスロースタートしたらセグメントの欠損はなかったかもしれない場合、大きい初期ウィンドウは、時々初期ウィンドウからのセグメント欠損を結果として引き起こす。しかし付録
A は、この場合でさえ大きい初期ウィンドウが、膨大な個数の重複セグメントの送信を結果として引き起こさないことを示している。
ネットワーク中で後で欠損するであろうセグメント:
TCP の大きい初期ウィンドウは、最終宛先に到達する前に欠損した、輻輳したリンク上のセグメントの数をどの程度増やすだろうか?
これは複数の輻輳リンクを持つコネクションでしか発生し得ない問題である。それは、幾つかのセグメントがパスに沿って後で欠損させるためだけに、パスに沿った最初の輻輳リンク上で不足している帯域を使用するかもしれない。
第一に、TCP コネクションの多くはパスに沿って一つの輻輳リンクしか持たないだろう。これらのコネクションから欠損したセグメントは不足している帯域を "浪費" せず、輻輳崩壊に寄与しない。
しかし、あるネットワークパスは複数の輻輳パスを持ち、初期ウィンドウから欠損したセグメントは、最終的に次の輻輳リンク上で欠損する前に、前の輻輳リンクに沿った不足した帯域を使用し得る。欠損率が TCP セグメントによって使用される初期ウィンドウに依存しない限り、それらの宛先に到達する前に欠損するだろうセグメントを運ぶ輻輳リンクの問題は、TCP コネクションを 4 セグメント送信して開始しても、1 セグメント送信して開始しても同じである。
パケット欠損率の増加:
高いセグメント欠損率を持つネットワークでは、TCP
の初期ウィンドウを増やすことはセグメントの欠損率を更に増加させ得る。ドロップテイルキュー管理を持つルータは輻輳時のトラフィック増大に対して困難なので、これは一部分である。しかし、TCP
コネクションで関係ない到着物が与えられると、大きい TCP 初期ウィンドウはセグメント欠損率を際立って増加させないはずである。シミュレーションに基づくこれらの問題の調査については、セクション
7.2 で論じられる。
ネットワークのこれらの潜在的危険性は、以下のセクションで説明されているシミュレーションや実験で調査されている。我々の判断は、現在のインターネットに輻輳崩壊の危険性はあるが (エンドツーエンドの輻輳制御の無い UDP コネクションの実装が増えることによる輻輳崩壊の危険性についての議論は [FF98] を参照されたい)、TCP 初期ウィンドウを 4K バイトに増やすことによるそのような危険性はネットワークに無い。
大きい初期ウィンドウは、今日のインターネットにおける TCP トラフィックの爆発を劇的に増やすことはないだろう。なぜなら、そのようなトラフィックは既にかなり爆発しているからである。2、3 個のセグメントの突発的な流入は、既に TCP [Flo97] の典型であり、輻輳回避中に受信した遅延 ACK (二つの未確認のセグメントをカバーする) は、輻輳ウィンドウをスライドさせ、二つのセグメントを送信させる。スロースタート中に受信した同じ遅延 ACK は二つのセグメントによりウィンドウをスライドさせ、その後セグメントを一つ増やし、結果的に 3 セグメントの突発的流入を引き起こす。必ずしも典型的ではないが、TCP における 4、5 個のセグメントの突発的流入は希ではない。遅延 ACK を想定すると、一個の ACK 欠損により次の ACK で 4 個の未確認のセグメントをカバーさせる。輻輳回避中は、これは 4 セグメントの突発的流入を導き、スロースタート中は 4 セグメントの突発的流入が生成される。
適度なトラフィックの流入によるパフォーマンス問題を減らす変更も進行中である。一つの変更は、ネットワークのある部分で高速回線を配置することである。そこでは 4K バイトの突発的流入がデータの小さい量を表すことができる。二番目の変更は、十分なバッファリングを持つルータが RED 等のキュー管理メカニズムを実装することである。それは、一時的なトラフィックの突発的流入に耐えられるよう設計されている。
このセクションは、大きいウィンドウを使用する TCP コネクション上で、大きい初期ウィンドウの影響を調査するために用いられたシミュレーションと実験について記述する。実験の最初のセットは、衛星回線上のパフォーマンスを調査する。大きい初期ウィンドウは、衛星チャネル [All97b] 上の TCP コネクションのパフォーマンス改善するために示された。この調査では、4 セグメント (512 バイト MSS) の初期ウィンドウとした結果、最大 30% までスループットが改善した (転送サイズに依存)。[KAGT98] は、大きい初期ウィンドウの使用により、ACTS 衛星システム上での HTTP テストにおける転送時間が減ったという結果を示している。Hybrid Fiber Coax (HFC: CATV システムにおいて、従来の同軸ケーブルと光ファイバーケーブルとを組み合わせて使用する方式) 上の多数の HTTP トランザクションのシミュレーションを伴う調査では、大きい初期ウィンドウの使用により、WWW ページをロードするために必要な時間が減ったことを示している [Nic97]。
実験の二番目のセットは、ダイアルアップモデム回線上の TCP パフォーマンスを調査している。28.8bps ダイアルアップチャネル [All97a], [AHO98] 上での実験では、4 セグメント初期ウィンドウにより、欠損率の増加を伴わず 16 KB ファイルの転送時間が大体 10 % 減った。関連する特定の領域は、小さいバッファを持つルータと低速テイル回線 (例えばダイアルアップモデム回線) 上の TCP パフォーマンスである。シミュレーション調査 [SP97] は、低速モデム回線と 3 パケットのバッファを持つルータに接続されたホストで、大きい初期ウィンドウを使用することの影響を調査した。その調査では、調査したシナリオに対して、大きい初期ウィンドウの使用は TCP パフォーマンスに害を及ぼさないと結論づけた。大きい初期ウィンドウによる、この環境での短い転送にかかる転送時間への影響に関して疑問が上がったが、これらの影響は数量化されていない。さらに、回線を共有する既存の TCP コネクションに対して起こり得る影響に関する疑問も上がった。
このセクションは、パスを共有する他の TCP コネクションへの大きいウィンドウの影響を調査するシミュレーションと実験について記述する。[All97a], [AHO98] の実験は、100 個のインターネットホストへの 16 KB 転送で、4 セグメントの初期ウィンドウにより 0.04 セグメント/転送の欠損率が若干増加する結果となったことを示している。欠損率が若干増加する一方、4 セグメント (512 バイトの MSS) の初期ウィンドウを使用する転送時間は、1 セグメントの初期ウィンドウと比較して大体 25 % 減少した。
懸念される一つのシナリオは、負荷の高い回線である。例えば 2, 3 年前、大西洋横断回線の一つで非常に負荷がかかり、そのコネクションにおける適切な輻輳ウィンドウサイズは約 1 セグメントだった。この環境では、大きい初期ウィンドウを使用する新しいコネクションは、4 倍大き過ぎるウィンドウで開始されることになる。どんな影響が起こるだろうか? コネクションはスラッシング状態になるか?
[PN98] のシミュレーション研究は、競合するネットワークトラフィック上での大きい初期ウィンドウの影響を調査している。この調査では、HTTP と FTP フローが一つの輻輳したゲートウェイを共有する (HTTP と FTP フローの数は、シミュレーションのセット毎に異なる)。各シミュレーションのセットに対し、その資料は回線使用率とパケット欠損率の総計、中間ウェッブページの遅延、FTP 転送でのネットワークパワーを調査している。大きい初期ウィンドウにした結果、スループットが増え、パケット欠損率が若干増え、ネットワークパワーが全体的に増えた。一つのシナリオの例外を除いて、大きい初期ウィンドウは、1 セグメントの初期ウィンドウを使用した実験での欠損率よりも、1 % 以下の欠損率の増加を結果的に招いた。例外のシナリオでは、1 セグメントの初期ウィンドウで 3.5 % の欠損率を、4 セグメントの初期ウィンドウで 4.5 % に増加させた。全体的な結論は、TCP 初期ウィンドウを 3 パケット (あるいは 4380 バイト) に増加させることは、認知されるパフォーマンス改善を助けるということである。
モリス [Mor97] は大きい初期ウィンドウに対し、非常に輻輳したネットワークで 20 K サイズを転送して調査した。全ての TCP コネクションが 4 セグメントの初期ウィンドウを使用するネットワークの欠損率は、全てのコネクションが 1 セグメントの初期ウィンドウを使用するネットワークよりも 1-2 % 大きいことが示されている。この関係は 1 セグメント初期ウィンドウの欠損率が 1 % から 11 % の範囲であるシナリオに限られる。さらに、コネクションが 4 セグメントの初期ウィンドウを使用するネットワークでは、TCP コネクションがセグメントを再送する再送タイマ (RTO) の満了を待つために、1 セグメントの初期ウィンドウを使用する時に費やされるよりも多くの時間が費やされた。RTO タイマ満了待ち時間で費やされる時間は、そのコネクションで有効な動作がなされていないアイドル時間を表す。これらの結果は、非常に輻輳したネットワークでは、各々のコネクションのボドルネックとなる帯域の共有が一つのセグメントに閉じる場合、大きい初期ウィンドウを使用することは、欠損率と再送タイムアウトの両方において認識できる増加を引き起こし得ることを示す。
このドキュメントは、TCP コネクションで許された初期輻輳ウィンドウについて論じている。この値を変更することは、TCP における既知の新たなセキュリティ問題を起こさない。
このドキュメントは、存在時間の短い TCP コネクションや長い RTT の回線上のコネクション (最初のスロースタートフェーズ間で幾つかの RTT を節約する) で有益な、TCP に対する小さい変更を提案する。
Vern Paxson、Tim Shepard、エンドツーエンドインターネットメーリングリストのメンバ、IETF TCP 実装ワーキンググループのメンバに対し、このドキュメントの議論やフィードバックのためにこれらの問題を継続して議論して頂いたことを感謝したい。
[All97a]
Mark Allman. An Evaluation of TCP with Larger Initial Windows.
40th IETF Meeting -- TCP Implementations WG. December, 1997.
Washington, DC.
[AHO98]
Mark Allman, Chris Hayes, and Shawn Ostermann, An Evaluation of
TCP with Larger Initial Windows, March 1998. Submitted to ACM
Computer Communication Review. URL: "http://gigahertz.lerc.nasa.gov/~mallman/papers/initwin.ps".
[All97b]
Mark Allman. Improving TCP Performance
Over Satellite Channels. Master's thesis, Ohio University, June
1997.
[BLFN96]
Berners-Lee, T., Fielding, R., and
H. Nielsen, "Hypertext Transfer Protocol -- HTTP/1.0",
RFC 1945, May 1996.
[Bra89]
Braden, R., "Requirements for
Internet Hosts -- Communication Layers", STD 3, RFC 1122,
October 1989.
[FF96]
Fall, K., and Floyd, S., Simulation-based
Comparisons of Tahoe, Reno, and SACK TCP. Computer Communication
Review, 26(3), July 1996.
[FF98]
Sally Floyd, Kevin Fall. Promoting
the Use of End-to-End Congestion Control in the Internet. Submitted
to IEEE Transactions on Networking. URL "http://www-nrg.ee.lbl.gov/floyd/end2end-paper.html".
[FJGFBL97]
Fielding, R., Mogul, J., Gettys,
J., Frystyk, H., and T. Berners-Lee, "Hypertext Transfer
Protocol -- HTTP/1.1", RFC 2068, January 1997.
[FJ93]
Floyd, S., and Jacobson, V., Random
Early Detection gateways for Congestion Avoidance. IEEE/ACM Transactions
on Networking, V.1 N.4, August 1993, p. 397-413.
[Flo94]
Floyd, S., TCP and Explicit Congestion
Notification. Computer Communication Review, 24(5):10-23, October
1994.
[Flo96]
Floyd, S., Issues of TCP with SACK.
Technical report, January 1996. Available from http://www-nrg.ee.lbl.gov/floyd/.
[Flo97]
Floyd, S., Increasing TCP's Initial
Window. Viewgraphs, 40th IETF Meeting - TCP Implementations WG.
December, 1997. URL "ftp://ftp.ee.lbl.gov/talks/sf-tcp-ietf97.ps".
[KAGT98]
Hans Kruse, Mark Allman, Jim Griner,
Diepchi Tran. HTTP Page Transfer Rates Over Geo-Stationary Satellite
Links. March 1998. Proceedings of the Sixth International Conference
on Telecommunication Systems. URL "http://gigahertz.lerc.nasa.gov/~mallman/papers/nash98.ps".
[MD90]
Mogul, J., and S. Deering, "Path
MTU Discovery", RFC 1191, November 1990.
[MMFR96]
Mathis, M., Mahdavi, J., Floyd, S.,
and A. Romanow, "TCP Selective Acknowledgment Options",
RFC 2018, October 1996.
[Mor97]
Robert Morris. Private communication,
1997. Cited for acknowledgement purposes only.
[Nic97]
Kathleen Nichols. Improving Network
Simulation with Feedback. Com21, Inc. Technical Report. Available
from http://www.com21.com/pages/papers/068.pdf.
[PN98]
Poduri, K., and K. Nichols, "Simulation
Studies of Increased Initial TCP Window Size", RFC 2415,
September 1998.
[Pos82]
Postel, J., "Simple Mail Transfer
Protocol", STD 10, RFC 821, August 1982.
[RF97]
Ramakrishnan, K., and S. Floyd, "A
Proposal to Add Explicit Congestion Notification (ECN) to IPv6
and to TCP", Work in Progress.
[RFC2119]
Bradner, S., "Key words for
use in RFCs to Indicate Requirement Levels", BCP 14, RFC
2119, March 1997.
[RFC2309]
Braden, B., Clark, D., Crowcroft,
J., Davie, B., Deering, S., Estrin, D., Floyd, S., Jacobson, V.,
Minshall, G., Partridge, C., Peterson, L., Ramakrishnan, K., Shenker,
S., Wroclawski, J., and L. Zhang, "Recommendations on Queue
Management and Congestion Avoidance in the Internet", RFC
2309, April 1998.
[S97]
Stevens, W., "TCP Slow Start,
Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms",
RFC 2001, January 1997.
[SP97]
Shepard, T., and C. Partridge, "When
TCP Starts Up With Four Packets Into Only Three Buffers",
RFC 2416, September 1998.
Mark Allman NASA Lewis Research Center/Sterling Software 21000 Brookpark Road MS 54-2 Cleveland, OH 44135 EMail: mallman@lerc.nasa.gov http://gigahertz.lerc.nasa.gov/~mallman/ Sally Floyd Lawrence Berkeley National Laboratory One Cyclotron Road Berkeley, CA 94720 EMail: floyd@ee.lbl.gov Craig Partridge BBN Technologies 10 Moulton Street Cambridge, MA 02138 EMail: craig@bbn.com
現在の環境 (明示的輻輳通知無し [Flo94],[RF97]) では、全ての TCP は利用できる帯域の制限に関するネットワークからの指示として、セグメント欠損を使用する。大きな初期ウィンドウへの変更により、受信側で既に受信した多くの重複セグメントを送信側が再送することにはならないことについて、ここで論じる。
もし初期ウィンドウから 1 セグメントが欠損したら、TCP が回復するための 3 つの異なる方法が存在する。(1) 再送タイムアウト後、あるいは Tahoe TCP での高速再送後に行う、1 セグメントのウィンドウからのスロースタート。(2) Reno TCP で 3 つの重複 ACK 後に行われる、選択的肯定応答 (SACK) 無しの高速回復。(3) 送信側と受信側の両方が SACK オプション [MMFR96] をサポートしている TCP で、SACK 有りの高速回復。三つの全てのケースで、もし初期ウィンドウから単一のセグメントが欠損したら、重複セグメント (すなわち受信側によって既に受信されたセグメント) は再送されない。初期ウィンドウで 4 つの 512 バイトのセグメントを送信する TCP では、単一のセグメント欠損は再送タイムアウトを必要としないだろうが、(再送タイマが早々に満了しなければ) 高速回復アルゴリズムを使用することによって回復できることに注意されたい。さらに、3 セグメントの初期ウィンドウから欠損した単一セグメントは、どのセグメントが欠損したか、遅延 ACK が使用されているか否かに従って、高速再送アルゴリズムを使用して修復されるかもしれない。例えば、3 セグメント初期ウィンドウの最初のセグメントの欠損は、常にタイムアウト待ちを必要とする。しかし、三番目のセグメントの欠損は、ACK が消失しない限り常に高速再送アルゴリズムによる回復を可能にする。
次に、初期ウィンドウが 2 〜 4 個のセグメントを含み、少なくともそれらのセグメントのうち二つが欠損するシナリオを考察する。もし初期ウィンドウの全てのセグメントが欠損したら、受信側は何のセグメントもまだ受信していないので、明らかに重複セグメントは再送されない。(これらの欠損したセグメントが、欠損点までの道のりで不足した帯域を使用する可能性は依然としてある。この問題については、セクション 5 で論じている。)
3 セグメントの初期ウィンドウから二つのセグメントが欠損した時、もし三つのセグメントのうち最初の二つが欠損したならば、送信側は重複セグメントのみを送信するだろう。そして、送信側は三番目のセグメントに応答する SACK オプション付きのパケットを受信しない。
4 セグメントの初期ウィンドウから二つのセグメントが欠損した時、6 つの有り得るシナリオの例 (ここでは触れない) は、SACK を付け無い場合、送信側は一つの重複セグメントを欠損したパケットの位置に従って、一つの重複セグメントを送信するかもしれないことを示している。送信側が二つの重複セグメントを送信するシナリオは存在しない。
4 セグメントの初期ウィンドウから三つのセグメントが欠損した時、SACK を付けない場合、欠損したパケットの位置に従って、一つの重複セグメントが送信されることが有り得る。
つまり、SACK を付けない場合、初期ウィンドウからの複数のセグメンと欠損により、一つの重複セグメントが送信される幾つかのシナリオがある。一つのセグメントよりも多く送信されるシナリオは存在しない。結論としては、大きい初期ウィンドウの結果により数多くの重複セグメントが送信されることは小さいはずである。
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
(このドキュメントと翻訳は全体または一部を、如何なる種類の制限無しで、上記のコピーライト記述を提供し、このパラグラフを全てのコピーや派生作業に含めて、他者へコピーや供給してもよく、コメントしたり、別途説明したり、実装を援助するといった派生作業を準備、コピー、出版、配布してもよい。しかし、このドキュメント自身は、インターネット標準プロセスで定義された手続きに従わなければならず、インターネット標準を開発する目的で必要な場合や、英語以外の言語に翻訳するために必要な場合を除いて、コピーライト記述やインターネット社会、他のインターネット組織への参照等を、如何なる方法でも修正してはならない。
上記で認められた制限された許可は永久的であり、インターネット社会や継承者や割当て者によって無効にされることはないだろう。)
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.