RFC2414 日本語訳

Network Working Group                                          M. Allman
Request for Comments: 2414                  NASA Lewis/Sterling Software
Category: Experimental                                          S. Floyd
                                                                    LBNL
                                                            C. Partridge
                                                        BBN Technologies
                                                          September 1998

コメントを求めるワーキンググループM.オールマン要求をネットワークでつないでください: 2414年のNASAのルイス/りっぱなソフトウェアカテゴリ: 実験的なS.のLBNL C.ヤマウズラBBN技術フロイド1998年9月

                    Increasing TCP's Initial Window

増加するTCPの初期の窓

Status of this Memo

このMemoの状態

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

Copyright(C)インターネット協会(1998)。 All rights reserved。

Abstract

要約

   This document specifies an increase in the permitted initial window
   for TCP from one segment to roughly 4K bytes.  This document
   discusses the advantages and disadvantages of such a change,
   outlining experimental results that indicate the costs and benefits
   of such a change to TCP.

このドキュメントは1つのセグメントからおよそ4Kのバイトまで受入れられた初期の窓の増加をTCPに指定します。 このドキュメントはそのような変化の利点と損失について議論します、TCPへのそのような変化のコストと利益を示す実験結果について概説して。

Terminology

用語

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?

1.  TCP Modification

1. TCP変更

   This document specifies an increase in the permitted upper bound for
   TCP's initial window from one segment to between two and four
   segments.  In most cases, this change results in an upper bound on
   the initial window of roughly 4K bytes (although given a large
   segment size, the permitted initial window of two segments could be
   significantly larger than 4K bytes).  The upper bound for the initial
   window is given more precisely in (1):

このドキュメントは1つのセグメントから2〜4つのセグメントまでTCPの初期の窓に受入れられた上限の増加を指定します。 多くの場合、この変化はおよそ4Kのバイトの初期の窓で上限をもたらします(大きいセグメントサイズを与えますが、2つのセグメントの受入れられた初期の窓は4Kのバイトよりかなり大きいかもしれません)。 (1)で、より正確に初期の窓への上限を与えます:

          min (4*MSS, max (2*MSS, 4380 bytes))               (1)

分(4*MSS、(2*MSS、4380バイト)に最大限にしてください)(1)

Allman, et. al.               Experimental                      [Page 1]

RFC 2414            Increasing TCP's Initial Window       September 1998

etオールマン、アル。 TCPの初期の窓の1998年9月に増加する実験的な[1ページ]RFC2414

   Equivalently, the upper bound for the initial window size is based on
   the maximum segment size (MSS), as follows:

同等に、初期のウィンドウサイズのための上限は以下の通り最大のセグメントサイズ(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;

次に、(1095MSS<=バイト)が勝つなら、<は4*MSSと等しいです。 (1095バイトの<MSS<2190バイト)であるなら、<=4380を獲得してください。 次に、(2190バイトの<=MSS)が勝つなら、<は2*MSSと等しいです。

   This increased initial window is optional: that a TCP MAY start with
   a larger initial window, not that it SHOULD.

この増強された初期の窓は任意です: そのa TCP MAYは、より大きい初期の窓から始まって、それはそれであるというわけではありません。SHOULD。

   This upper bound for the initial window size represents a change from
   RFC 2001 [S97], which specifies that the congestion window be
   initialized to one segment.  If implementation experience proves
   successful, then the intent is for this change to be incorporated
   into a revision to RFC 2001.

初期のウィンドウサイズのためのこの上限はRFC2001[S97]から変化を表します。(RFCは混雑ウィンドウが1つのセグメントに初期化されると指定します)。 実装経験が成功するなら、意図はこの変化がRFC2001への改正に組み入れられることです。

   This change applies to the initial window of the connection in the
   first round trip time (RTT) of transmission following the TCP three-
   way handshake.  Neither the SYN/ACK nor its acknowledgment (ACK) in
   the three-way handshake should increase the initial window size above
   that outlined in equation (1).  If the SYN or SYN/ACK is lost, the
   initial window used by a sender after a correctly transmitted SYN
   MUST be one segment.

この変化はトランスミッションがTCP three道に従う周遊旅行1回目(RTT)の接続の初期の窓に握手を適用します。 3方向ハンドシェイクにおけるSYN/ACKもその承認(ACK)も方程式(1)で概説されたそれの上で初期のウィンドウサイズを増強するべきではありません。 SYNかSYN/ACKが無くなるなら、初期の窓は送付者を使用しました。正しく伝えられたSYN MUSTの後に、1つのセグメントになってください。

   TCP implementations use slow start in as many as three different
   ways: (1) to start a new connection (the initial window); (2) to
   restart a transmission after a long idle period (the restart window);
   and (3) to restart after a retransmit timeout (the loss window).  The
   change proposed in this document affects the value of the initial
   window.  Optionally, a TCP MAY set the restart window to the minimum
   of the value used for the initial window and the current value of
   cwnd (in other words, using a larger value for the restart window
   should never increase the size of cwnd).  These changes do NOT change
   the loss window, which must remain 1 segment (to permit the lowest
   possible window size in the case of severe congestion).

TCP実装は最大3つの異なった方法で遅れた出発を使用します: (1) 新しい接続(初期の窓)を始めるために。 (2) 長い活動していない期間(再開ウィンドウ)の後にトランスミッションを再開するために。 (3) そして、後aを再開するには、タイムアウト(損失の窓)を再送してください。 本書では提案された変化は初期の窓の値に影響します。 任意に、TCP MAYは初期の窓に使用される値の最小限とcwndの現行価値に再開ウィンドウを設定しました(言い換えれば、再開ウィンドウにより大きい値を使用すると、cwndのサイズは決して増強されるべきではありません)。 これらの変化は損失の窓を変えません。(それは、1つのセグメント(厳しい混雑の場合で可能な限り低いウィンドウサイズを可能にする)のままで残らなければなりません)。

2.  Implementation Issues

2. 導入問題

   When larger initial windows are implemented along with Path MTU
   Discovery [MD90], and the MSS being used is found to be too large,
   the congestion window `cwnd' SHOULD be reduced to prevent large
   bursts of smaller segments.  Specifically, `cwnd' SHOULD be reduced
   by the ratio of the old segment size to the new segment size.

より大きい初期の窓が実装されたらPath MTUディスカバリー[MD90]、および使用されるのが大き過ぎる混雑ウィンドウ'cwnd'SHOULDになるように見つけられるMSSと共に、減少して、より小さいセグメントの大きい炸裂を防いでください。 明確に'cwnd'SHOULD、古いセグメントサイズ対新しいセグメントサイズの比率で、減少されてください。

Allman, et. al.               Experimental                      [Page 2]

RFC 2414            Increasing TCP's Initial Window       September 1998

etオールマン、アル。 TCPの初期の窓の1998年9月に増加する実験的な[2ページ]RFC2414

   When larger initial windows are implemented along with Path MTU
   Discovery [MD90], alternatives are to set the "Don't Fragment" (DF)
   bit in all segments in the initial window, or to set the "Don't
   Fragment" (DF) bit in one of the segments.  It is an open question
   which of these two alternatives is best; we would hope that
   implementation experiences will shed light on this.  In the first
   case of setting the DF bit in all segments, if the initial packets
   are too large, then all of the initial packets will be dropped in the
   network.  In the second case of setting the DF bit in only one
   segment, if the initial packets are too large, then all but one of
   the initial packets will be fragmented in the network.  When the
   second case is followed, setting the DF bit in the last segment in
   the initial window provides the least chance for needless
   retransmissions when the initial segment size is found to be too
   large, because it minimizes the chances of duplicate ACKs triggering
   a Fast Retransmit.  However, more attention needs to be paid to the
   interaction between larger initial windows and Path MTU Discovery.

より大きい初期の窓がPath MTUディスカバリー[MD90]と共に実装されるとき、選択肢は、初期の窓のすべてのセグメントで「断片化しないでください」という(DF)ビットを設定するか、またはセグメントの1つで「断片化しないでください」という(DF)ビットを設定することです。 これらの2つの選択肢のどれが最も良いかは、未決問題です。 私たちは、実装経験がこれを解明することを望んでいるでしょう。 前者の場合、初期のパケットが大き過ぎるなら、すべてのセグメントにDFビットをはめ込むのにおいて、初期のパケットのすべてがネットワークで下げられるでしょう。 1つのセグメントだけにDFビットをはめ込む2番目の場合では、初期のパケットが大き過ぎるなら、初期のパケットの1つ以外のすべてがネットワークで断片化されるでしょう。 2番目のケースが従われているとき、初期のセグメントサイズが大き過ぎるのがわかっているとき、初期の窓における最後のセグメントにDFビットをはめ込むと、最少の見込みは不必要な「再-トランスミッション」に供給されます、写しACKsがFast Retransmitの引き金となるという可能性を最小にするので。 しかしながら、より多くの注意が、より大きい初期の窓とPath MTUディスカバリーとの相互作用に支払われる必要があります。

   The larger initial window proposed in this document is not intended
   as an encouragement for web browsers to open multiple simultaneous
   TCP connections all with large initial windows.  When web browsers
   open simultaneous TCP connections to the same destination, this works
   against TCP's congestion control mechanisms [FF98], regardless of the
   size of the initial window.  Combining this behavior with larger
   initial windows further increases the unfairness to other traffic in
   the network.

本書では提案されたより大きい初期の窓は奨励としてウェブブラウザが大きい初期の窓とのすべて、複数の同時のTCP接続を開くことを意図しません。 ウェブブラウザが同時のTCP接続を同じ目的地に開くと、これはTCPの混雑制御機構[FF98]に不利に働きます、初期の窓のサイズにかかわらず。 より大きい初期の窓にこの振舞いを結合すると、不公平はネットワークで他のトラフィックにさらに増強されます。

3.  Advantages of Larger Initial Windows

3. より大きい初期のWindowsの利点

   1.  When the initial window is one segment, a receiver employing
       delayed ACKs [Bra89] is forced to wait for a timeout before
       generating an ACK.  With an initial window of at least two
       segments, the receiver will generate an ACK after the second data
       segment arrives.  This eliminates the wait on the timeout (often
       up to 200 msec).

1. 初期の窓が1つのセグメントであるときに、ACKを生成する前に、受信機の雇用の遅れたACKs[Bra89]はやむを得ずタイムアウトを待ちます。 少なくとも2つのセグメントの初期の窓で、2番目のデータ・セグメントが到着した後に受信機はACKを生成するでしょう。 これはタイムアウト(しばしば最大200msec)で待ちを排除します。

   2.  For connections transmitting only a small amount of data, a
       larger initial window reduces the transmission time (assuming at
       most moderate segment drop rates).  For many email (SMTP [Pos82])
       and web page (HTTP [BLFN96, FJGFBL97]) transfers that are less
       than 4K bytes, the larger initial window would reduce the data
       transfer time to a single RTT.

2. 少量のデータだけを送る接続のために、より大きい初期の窓はトランスミッション時間を減少させます(適度のセグメント低下率を高々仮定して)。 4K未満のバイトである多くのメール(SMTP[Pos82])とウェブページ(HTTP[BLFN96、FJGFBL97])転送のために、より大きい初期の窓はデータ転送時間を独身のRTTに変えるでしょう。

   3.  For connections that will be able to use large congestion
       windows, this modification eliminates up to three RTTs and a
       delayed ACK timeout during the initial slow-start phase.  This

3. 大きい混雑ウィンドウを使用できる接続のために、この変更は初期の遅れた出発段階の間、最大3RTTsと遅れたACKタイムアウトを排除します。 これ

Allman, et. al.               Experimental                      [Page 3]

RFC 2414            Increasing TCP's Initial Window       September 1998

etオールマン、アル。 TCPの初期の窓の1998年9月に増加する実験的な[3ページ]RFC2414

       would be of particular benefit for high-bandwidth large-
       propagation-delay TCP connections, such as those over satellite
       links.

衛星中継の上のそれらなどの高帯域の大きい伝播遅延TCP接続のための特別の利益があるでしょう。

4.  Disadvantages of Larger Initial Windows for the Individual
    Connection

4. 個々の接続のための、より大きい初期のWindowsの損失

   In high-congestion environments, particularly for routers that have a
   bias against bursty traffic (as in the typical Drop Tail router
   queues), a TCP connection can sometimes be better off starting with
   an initial window of one segment.  There are scenarios where a TCP
   connection slow-starting from an initial window of one segment might
   not have segments dropped, while a TCP connection starting with an
   initial window of four segments might experience unnecessary
   retransmits due to the inability of the router to handle small
   bursts.  This could result in an unnecessary retransmit timeout.  For
   a large-window connection that is able to recover without a
   retransmit timeout, this could result in an unnecessarily-early
   transition from the slow-start to the congestion-avoidance phase of
   the window increase algorithm.  These premature segment drops are
   unlikely to occur in uncongested networks with sufficient buffering
   or in moderately-congested networks where the congested router uses
   active queue management (such as Random Early Detection [FJ93,
   RFC2309]).

高混雑環境と、特にburstyトラフィック(典型的なDrop Tailルータ待ち行列のように)に対して偏見を持っているルータにおいてTCP接続は1つのセグメントの初期の窓から時々始まることができるほうがよいです。 シナリオが1つのセグメントの初期の窓からの遅い始めのTCP接続がセグメントを下げさせないかもしれないところにあります、不要な状態でセグメントがなるかもしれない4の初期の窓から始まるTCP接続はルータが小さい炸裂を扱うことができないことのため再送しますが。 これがもたらすかもしれない、不要である、タイムアウトを再送してください。 aなしで回復できる大きいウィンドウ接続には、タイムアウトを再送してください、そして、これは窓の増加の輻輳回避フェーズへの遅い始めのアルゴリズムからの不必要に早めの変遷をもたらすかもしれません。 これらの時期尚早なセグメント低下は十分なバッファリングがある非充血しているネットワークか混雑しているルータが活発な待ち行列管理(Random Early Detection[FJ93、RFC2309]などの)を使用する適度に混雑しているネットワークで起こりそうにはありません。

   Some TCP connections will receive better performance with the higher
   initial window even if the burstiness of the initial window results
   in premature segment drops.  This will be true if (1) the TCP
   connection recovers from the segment drop without a retransmit
   timeout, and (2) the TCP connection is ultimately limited to a small
   congestion window by either network congestion or by the receiver's
   advertised window.

初期の窓のburstinessが時期尚早なセグメント低下をもたらしても、何人かのTCP接続が、より高い初期の窓による、より良い性能を受け取るでしょう。 (2) TCP接続がセグメント低下からaなしで回復する(1)がタイムアウトを再送するなら、これは本当になるでしょう、そして、TCP接続は結局、ネットワークの混雑か受信機の広告を出している窓によって小さい混雑ウィンドウに制限されます。

5.  Disadvantages of Larger Initial Windows for the Network

5. ネットワークのための、より大きい初期のWindowsの損失

   In terms of the potential for congestion collapse, we consider two
   separate potential dangers for the network.  The first danger would
   be a scenario where a large number of segments on congested links
   were duplicate segments that had already been received at the
   receiver.  The second danger would be a scenario where a large number
   of segments on congested links were segments that would be dropped
   later in the network before reaching their final destination.

混雑崩壊の可能性に関して、私たちはネットワークのために2つの別々の潜在的危険を考えます。 最初の危険は混雑しているリンクの上の多くのセグメントが受信機に既に受け取られた写しセグメントであったシナリオでしょう。2番目の危険は混雑しているリンクの上の多くのセグメントがそれらの最終的な目的地に達する前に後でネットワークで下げられるセグメントであったシナリオでしょう。

   In terms of the negative effect on other traffic in the network, a
   potential disadvantage of larger initial windows would be that they
   increase the general packet drop rate in the network.  We discuss
   these three issues below.

ネットワークにおける他のトラフィックへのマイナスの効果に関して、より大きい初期の窓の潜在的難点はネットワークで一般的なパケット低下率を増強するということでしょう。 私たちは以下のこれらの3冊について議論します。

Allman, et. al.               Experimental                      [Page 4]

RFC 2414            Increasing TCP's Initial Window       September 1998

etオールマン、アル。 TCPの初期の窓の1998年9月に増加する実験的な[4ページ]RFC2414

   Duplicate segments:

セグメントをコピーしてください:

       As described in the previous section, the larger initial window
       could occasionally result in a segment dropped from the initial
       window, when that segment might not have been dropped if the
       sender had slow-started from an initial window of one segment.
       However, Appendix A shows that even in this case, the larger
       initial window would not result in the transmission of a large
       number of duplicate segments.

前項で説明されるように、より大きい初期の窓は時折1つのセグメントの初期の窓から遅く始められた状態でそのセグメントが下げられていないかもしれないとき送付者が下げられたなら初期の窓から下げられたセグメントをもたらすかもしれません。 しかしながら、Appendix Aは、この場合さえより大きい初期の窓が多くの写しセグメントの送信をもたらさないのを示します。

   Segments dropped later in the network:

セグメントは後でネットワークをちょっと立ち寄らせました:

       How much would the larger initial window for TCP increase the
       number of segments on congested links that would be dropped
       before reaching their final destination?  This is a problem that
       can only occur for connections with multiple congested links,
       where some segments might use scarce bandwidth on the first
       congested link along the path, only to be dropped later along the
       path.

TCPのための、より大きい初期の窓はそれらの最終的な目的地に達する前に下げられる混雑しているリンクでセグメントの数をどれほど増強するでしょうか? これはいくつかのセグメントが経路に沿って最初の混雑しているリンクにおける不十分な帯域幅を使用するかもしれない後で経路に沿って下げられる複数の混雑しているリンクとの接続のために起こることができるだけである問題です。

       First, many of the TCP connections will have only one congested
       link along the path.  Segments dropped from these connections do
       not "waste" scarce bandwidth, and do not contribute to congestion
       collapse.

まず最初に、TCP接続の多くが経路に沿って1個の混雑しているリンクしか持たないでしょう。 これらの接続から下げられたセグメントは、不十分な帯域幅を「浪費しない」で、また混雑崩壊に貢献しません。

       However, some network paths will have multiple congested links,
       and segments dropped from the initial window could use scarce
       bandwidth along the earlier congested links before ultimately
       being dropped on subsequent congested links.  To the extent that
       the drop rate is independent of the initial window used by TCP
       segments, the problem of congested links carrying segments that
       will be dropped before reaching their destination will be similar
       for TCP connections that start by sending four segments or one
       segment.

しかしながら、いくつかのネットワーク経路には、複数の混雑しているリンクがあるでしょう、そして、結局その後の混雑しているリンクで下げられる前に初期の窓から下げられたセグメントが以前の混雑しているリンクに沿って不十分な帯域幅を使用するかもしれません。 混雑しているリンクが目的地に到着する前に下げられるセグメントを運ぶという問題は低下率がTCPセグメントによって使用される初期の窓から独立しているという範囲と、4つのセグメントか1つのセグメントを送ることによって始まるTCP接続に同様になるでしょう。

   An increased packet drop rate:

増強されたパケット低下率:

       For a network with a high segment drop rate, increasing the TCP
       initial window could increase the segment drop rate even further.
       This is in part because routers with Drop Tail queue management
       have difficulties with bursty traffic in times of congestion.
       However, given uncorrelated arrivals for TCP connections, the
       larger TCP initial window should not significantly increase the
       segment drop rate.  Simulation-based explorations of these issues
       are discussed in Section 7.2.

高いセグメント低下率があるネットワークのために、TCPの初期の窓を増強すると、セグメント低下率はさらにさえ増強されるかもしれません。 これはDrop Tail待ち行列管理があるルータが混雑の時代にburstyトラフィックに一部苦労するからです。 しかしながら、TCP接続のための非相関到着を考えて、より大きいTCP初期の窓はセグメント低下率をかなり増強するはずがありません。 セクション7.2でこれらの問題のシミュレーションベースの探検について議論します。

Allman, et. al.               Experimental                      [Page 5]

RFC 2414            Increasing TCP's Initial Window       September 1998

etオールマン、アル。 TCPの初期の窓の1998年9月に増加する実験的な[5ページ]RFC2414

   These potential dangers for the network are explored in simulations
   and experiments described in the section below.  Our judgement would
   be, while there are dangers of congestion collapse in the current
   Internet (see [FF98] for a discussion of the dangers of congestion
   collapse from an increased deployment of UDP connections without
   end-to-end congestion control), there is no such danger to the
   network from increasing the TCP initial window to 4K bytes.

ネットワークのためのこれらの潜在的危険は下のセクションで説明されたシミュレーションと実験で調査されます。 私たちの判断があって、混雑崩壊の危険が現在のインターネット(混雑という危険の議論のための[FF98]がUDP接続の増強された展開から終わりからエンドへの輻輳制御なしで崩れるのを見る)にありますが、TCPの初期の窓を増強するのからの4Kのバイトへのネットワークへのどんなそのような危険もありません。

6.  Typical Levels of Burstiness for TCP Traffic.

6. TCPトラフィックのためのBurstinessの典型的なレベル。

   Larger TCP initial windows would not dramatically increase the
   burstiness of TCP traffic in the Internet today, because such traffic
   is already fairly bursty.  Bursts of two and three segments are
   already typical of TCP [Flo97]; A delayed ACK (covering two
   previously unacknowledged segments) received during congestion
   avoidance causes the congestion window to slide and two segments to
   be sent.  The same delayed ACK received during slow start causes the
   window to slide by two segments and then be incremented by one
   segment, resulting in a three-segment burst.  While not necessarily
   typical, bursts of four and five segments for TCP are not rare.
   Assuming delayed ACKs, a single dropped ACK causes the subsequent ACK
   to cover four previously unacknowledged segments.  During congestion
   avoidance this leads to a four-segment burst and during slow start a
   five-segment burst is generated.

より大きいTCP初期の窓は今日インターネットでTCPトラフィックのburstinessを劇的に増強しないでしょう、そのようなトラフィックが既にかなりburstyであるので。 2と3つのセグメントの炸裂はTCP[Flo97]の既に典型です。 遅れたACK(2つの以前に不承認のセグメントをカバーしている)は混雑ウィンドウが回避で滑らせる混雑と送られる2つのセグメントの間、受信しました。 同じ遅れたACKは2つのセグメントで滑って、次に、1つのセグメントによって増加されるように遅れた出発原因の間、窓を受けました、3セグメントの炸裂をもたらして。 必ず典型的であるというわけではありませんが、TCPのための4と5つのセグメントの炸裂はまれではありません。 遅れたACKsを仮定して、独身の下げられたACKはその後のACKに4つの以前に不承認のセグメントをカバーさせます。 これが通じる輻輳回避のときに、4セグメントが、はち切れて、5セグメントが押し破いた遅れた出発の間、発生しています。

   There are also changes in progress that reduce the performance
   problems posed by moderate traffic bursts.  One such change is the
   deployment of higher-speed links in some parts of the network, where
   a burst of 4K bytes can represent a small quantity of data.  A second
   change, for routers with sufficient buffering, is the deployment of
   queue management mechanisms such as RED, which is designed to be
   tolerant of transient traffic bursts.

適度のトラフィック炸裂によって引き起こされた性能問題を減少させる進行中の変化もあります。 そのような変化の1つはネットワークのいくつかの部分での、より高い速度リンクの展開です。(そこでは、4Kのバイトの炸裂が少量のデータを表すことができます)。 十分なバッファリングがあるルータのために、2番目の変化はREDなどの待ち行列管理メカニズムの展開です。(REDは、一時的なトラフィック炸裂において許容性があるように設計されています)。

7.  Simulations and Experimental Results

7. シミュレーションと実験結果

7.1 Studies of TCP Connections using that Larger Initial Window

そのLarger Initial Windowを使用するTCPコネクションズの7.1研究

   This section surveys simulations and experiments that have been used
   to explore the effect of larger initial windows on the TCP connection
   using that larger window.  The first set of experiments explores
   performance over satellite links.  Larger initial windows have been
   shown to improve performance of TCP connections over satellite
   channels [All97b].  In this study, an initial window of four segments
   (512 byte MSS) resulted in throughput improvements of up to 30%
   (depending upon transfer size).  [KAGT98] shows that the use of
   larger initial windows results in a decrease in transfer time in HTTP
   tests over the ACTS satellite system.  A study involving simulations

このセクションは、より大きい初期の窓のTCP接続への効果について調査するのにそのより大きい窓を使用することで使用されたシミュレーションと実験について調査します。 実験の第一セットは衛星中継の上の性能を探ります。 より大きい初期の窓は、衛星チャンネル[All97b]の上のTCP接続の性能を向上させるために見せられました。 この研究では、4つのセグメント(512バイトのMSS)の初期の窓は最大30%のスループット改良をもたらしました(転送サイズによって)。 [KAGT98]は、より大きい初期の窓の使用が転送時間に条例サテライト・システムの上のHTTPテストで減少をもたらすのを示します。 シミュレーションにかかわる研究

Allman, et. al.               Experimental                      [Page 6]

RFC 2414            Increasing TCP's Initial Window       September 1998

etオールマン、アル。 TCPの初期の窓の1998年9月に増加する実験的な[6ページ]RFC2414

   of a large number of HTTP transactions over hybrid fiber coax (HFC)
   indicates that the use of larger initial windows decreases the time
   required to load WWW pages [Nic97].

ハイブリッドファイバーの上のトランザクションがおだてる多くのHTTPでは、(HFC)は、より大きい初期の窓の使用がWWWページ[Nic97]をロードするのに必要である時間を減少させるのを示します。

   A second set of experiments has explored TCP performance over dialup
   modem links.  In experiments over a 28.8 bps dialup channel [All97a,
   AHO98], a four-segment initial window decreased the transfer time of
   a 16KB file by roughly 10%, with no accompanying increase in the drop
   rate.  A particular area of concern has been TCP performance over low
   speed tail circuits (e.g., dialup modem links) with routers with
   small buffers.  A simulation study [SP97] investigated the effects of
   using a larger initial window on a host connected by a slow modem
   link and a router with a 3 packet buffer.  The study concluded that
   for the scenario investigated, the use of larger initial windows was
   not harmful to TCP performance.  Questions have been raised
   concerning the effects of larger initial windows on the transfer time
   for short transfers in this environment, but these effects have not
   been quantified.  A question has also been raised concerning the
   possible effect on existing TCP connections sharing the link.

2番目の1セットの実験はダイアルアップモデムリンクの上のTCP性能を探りました。 28.8ビーピーエスダイアルアップチャンネル[All97a、AHO98]の上の実験では、4セグメントの初期の窓は16KBのファイルの転送時間をおよそ10%減少させました、低下率の付随の増加なしで。 関心の特定の領域は低速テール回路(例えば、ダイアルアップモデムリンク)の上の小さいバッファがあるルータがあるTCP性能です。 シミュレーション研究[SP97]は遅いモデムリンクとルータによって3パケットバッファに接続されたホストの上の、より大きい初期の窓を使用するという効果を調査しました。 研究は、シナリオのためのそれが調査されたと結論づけて、より大きい初期の窓の使用はTCP性能に有害ではありませんでした。 疑問はこの環境における短い転送のための転送時間への、より大きい初期の窓の効果に関して引き起こされましたが、これらの効果は定量化されていません。 また、疑問はリンクを共有している既存のTCP接続への可能な効果に関して引き起こされました。

7.2 Studies of Networks using Larger Initial Windows

より大きい初期のWindowsを使用するネットワークの7.2研究

   This section surveys simulations and experiments investigating the
   impact of the larger window on other TCP connections sharing the
   path.  Experiments in [All97a, AHO98] show that for 16 KB transfers
   to 100 Internet hosts, four-segment initial windows resulted in a
   small increase in the drop rate of 0.04 segments/transfer.  While the
   drop rate increased slightly, the transfer time was reduced by
   roughly 25% for transfers using the four-segment (512 byte MSS)
   initial window when compared to an initial window of one segment.

このセクションは、経路を共有している他のTCP接続のときに、より大きい窓の影響を調査しながら、シミュレーションと実験について調査します。 100人のインターネット・ホストに16KB移す[All97a、AHO98]ショーにおける実験、4セグメントの初期の窓は0.04回のセグメント/転送の低下速度の微増をもたらしました。 低下率はわずかに増加しましたが、転送時間は、転送のために1つのセグメントの初期の窓と比べると初期の4セグメント(512バイトのMSS)の窓を使用することでおよそ25%短縮されました。

   One scenario of concern is heavily loaded links.  For instance, a
   couple of years ago, one of the trans-Atlantic links was so heavily
   loaded that the correct congestion window size for a connection was
   about one segment.  In this environment, new connections using larger
   initial windows would be starting with windows that were four times
   too big.  What would the effects be?  Do connections thrash?

関心の1つのシナリオが大いに積み込まれたリンクです。 例えば、2、3年前に大西洋横断のリンクの1つが大いにあまりにロードされていたので、接続に、正しい混雑ウィンドウサイズはおよそ1つのセグメントでした。 この環境で、より大きい初期の窓を使用している新しい接続があまりに大きく4回であった窓から始まっているでしょう。 効果は何でしょうか? 接続は打ちますか?

   A simulation study in [PN98] explores the impact of a larger initial
   window on competing network traffic.  In this investigation, HTTP and
   FTP flows share a single congested gateway (where the number of HTTP
   and FTP flows varies from one simulation set to another).  For each
   simulation set, the paper examines aggregate link utilization and
   packet drop rates, median web page delay, and network power for the
   FTP transfers.  The larger initial window generally resulted in
   increased throughput, slightly-increased packet drop rates, and an
   increase in overall network power.  With the exception of one
   scenario, the larger initial window resulted in an increase in the

[PN98]のシミュレーション研究は競争しているネットワークトラフィックの、より大きい初期の窓の影響について調査します。 この調査では、HTTPとFTP流れは混雑している1つの門(HTTPとFTP流れの数が1つのシミュレーションセットから別のものに異なるところ)を共有します。 それぞれのシミュレーションセットがないかどうか、論文は集合リンク利用とパケット低下率を調べます、中央のウェブページ遅れ、そして、FTPのためのネットワークパワーは移されます。 一般に、もたらされるより大きい初期の窓は総合的なネットワークパワーでスループット、わずかに増強されたパケット低下率、および増加を増強しました。 あるシナリオを除いて、より大きい初期の窓は中で増加をもたらしました。

Allman, et. al.               Experimental                      [Page 7]

RFC 2414            Increasing TCP's Initial Window       September 1998

etオールマン、アル。 TCPの初期の窓の1998年9月に増加する実験的な[7ページ]RFC2414

   drop rate of less than 1% above the loss rate experienced when using
   a one-segment initial window; in this scenario, the drop rate
   increased from 3.5% with one-segment initial windows, to 4.5% with
   four-segment initial windows.  The overall conclusions were that
   increasing the TCP initial window to three packets (or 4380 bytes)
   helps to improve perceived performance.

1セグメントの初期の窓を使用するとき経験された損失率より高い1%未満のレートを下げてください。 このシナリオでは、低下率は1セグメントの初期の窓で3.5%から4セグメントの初期の窓がある4.5%まで増えました。 総合的な結論はTCPの初期の窓を3つのパケット(4380バイト)まで増強するのが、知覚された性能を向上させるのを助けるということでした。

   Morris [Mor97] investigated larger initial windows in a very
   congested network with transfers of size 20K.  The loss rate in
   networks where all TCP connections use an initial window of four
   segments is shown to be 1-2% greater than in a network where all
   connections use an initial window of one segment.  This relationship
   held in scenarios where the loss rates with one-segment initial
   windows ranged from 1% to 11%.  In addition, in networks where
   connections used an initial window of four segments, TCP connections
   spent more time waiting for the retransmit timer (RTO) to expire to
   resend a segment than was spent when using an initial window of one
   segment.  The time spent waiting for the RTO timer to expire
   represents idle time when no useful work was being accomplished for
   that connection.  These results show that in a very congested
   environment, where each connection's share of the bottleneck
   bandwidth is close to one segment, using a larger initial window can
   cause a perceptible increase in both loss rates and retransmit
   timeouts.

モリス[Mor97]は20Kのサイズの転送で非常に混雑しているネットワークで、より大きい初期の窓を調査しました。 すべてのTCP接続が4つのセグメントの初期の窓を使用するネットワークにおける損失率は、すべての接続が1つのセグメントの初期の窓を使用するネットワークより何%もすばらしい1-2になるように示されます。 この関係は1セグメントの初期の窓がある損失率が1%から11%まで及んだシナリオで成立しました。 さらに、接続が4つのセグメントの初期の窓を使用したネットワークに、TCP接続はセグメントを再送するために吐き出す再送信タイマ(RTO)の1つのセグメントの初期の窓を使用するとき、費やされたより多くの時間の待ちを費やしました。 RTOタイマが期限が切れるのを待ちながら費やされた時間は実質的な仕事が全くその接続のために実行されていなかった遊休時間を表します。 これらの結果は、より大きい初期の窓を使用すると各接続のボトルネック帯域幅のシェアがおよそ1つのセグメントである非常に混雑している環境で、両方の損失率の知覚可能な増加が引き起こされる場合があるのを示して、タイムアウトを再送します。

8.  Security Considerations

8. セキュリティ問題

   This document discusses the initial congestion window permitted for
   TCP connections.  Changing this value does not raise any known new
   security issues with TCP.

このドキュメントはTCP接続のために受入れられた初期の混雑ウィンドウについて議論します。 この値を変えるのはTCPの少しの知られている新しい安全保障問題も提起しません。

9.  Conclusion

9. 結論

   This document proposes a small change to TCP that may be beneficial
   to short-lived TCP connections and those over links with long RTTs
   (saving several RTTs during the initial slow-start phase).

このドキュメントは長いRTTs(初期の遅れた出発段階の間、数個のRTTsを取っておく)とのリンクの上に短命なTCP接続とそれらに有益であるかもしれないTCPに小銭を提案します。

10.  Acknowledgments

10. 承認

   We would like to acknowledge Vern Paxson, Tim Shepard, members of the
   End-to-End-Interest Mailing List, and members of the IETF TCP
   Implementation Working Group for continuing discussions of these
   issues for discussions and feedback on this document.

議論のためのこれらの問題とこのドキュメントのフィードバックの継続する議論のためにバーン・パクソン、ティム・シェパード、Endから終わりの関心へのMailing Listのメンバー、およびIETF TCP Implementation作業部会のメンバーを承認したいと思います。

Allman, et. al.               Experimental                      [Page 8]

RFC 2414            Increasing TCP's Initial Window       September 1998

etオールマン、アル。 TCPの初期の窓の1998年9月に増加する実験的な[8ページ]RFC2414

11.  References

11. 参照

   [All97a]    Mark Allman.  An Evaluation of TCP with Larger Initial
               Windows.  40th IETF Meeting -- TCP Implementations WG.
               December, 1997.  Washington, DC.

[All97a]はオールマンをマークします。 より大きい初期のWindowsとのTCPの評価。 第40IETFミーティング--TCP実装WG。 1997年12月。 ワシントン(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".

[AHO98] より大きい初期のWindows、1998年3月とのマークオールマン、クリス・ヘイズとショーン・オステルマン、TCPの評価。 ACMコンピュータコミュニケーションレビューに提出します。 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.

[All97b]はオールマンをマークします。 衛星チャンネルの上のTCP性能を向上させます。 修士論文、オハイオ大学、1997年6月。

   [BLFN96]    Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext
               Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.

[BLFN96] バーナーズ・リー、T.、フィールディング、R.、およびH.ニールセン、「HTTP/1インチ、RFC1945、1996年ハイパーテキスト転送プロトコル--5月。」

   [Bra89]     Braden, R., "Requirements for Internet Hosts --
               Communication Layers", STD 3, RFC 1122, October 1989.

[Bra89]ブレーデン、R.、「インターネットのためのホスト--コミュニケーションが層にされるという要件」、STD3、RFC1122、10月1989日

   [FF96]      Fall, K., and Floyd, S., Simulation-based Comparisons of
               Tahoe, Reno, and SACK TCP.  Computer Communication
               Review, 26(3), July 1996.

[FF96] 秋、K.とフロイド、S.、タホ、リノ、および袋のTCPのシミュレーションベースの比較。 コンピュータコミュニケーションレビュー、26(3)、1996年7月。

   [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".

[FF98]はフロイド、ケビンFallを出撃させます。 インターネットでの終わりからエンドへの輻輳制御の使用を促進します。 ネットワークのときにIEEEトランザクションに提出します。 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.

[FJGFBL97] フィールディング、R.、ムガール人、J.、Gettys、J.、Frystyk、H.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2068、1997年ハイパーテキスト転送プロトコル--1月。」

   [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.

[FJ93] Congestion Avoidanceのためのフロイド、S.とジェーコブソン、V.、Random Early Detectionゲートウェイ。 Networking、V.1 N.4、1993年8月、pのIEEE/ACM Transactions。 397-413.

   [Flo94]     Floyd, S., TCP and Explicit Congestion Notification.
               Computer Communication Review, 24(5):10-23, October 1994.

[Flo94] フロイド、S.、TCP、および明白な混雑通知。 コンピュータコミュニケーションレビュー、24(5): 10-23と、1994年10月。

   [Flo96]     Floyd, S., Issues of TCP with SACK. Technical report,
               January 1996.  Available from http://www-
               nrg.ee.lbl.gov/floyd/.

フロイド(S.)が発行する袋があるTCPの[Flo96。] 1996年1月の技術報告書。 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".

[Flo97] フロイド、S.、増加するTCPの初期の窓。 Viewgraphs、第40IETFミーティング--TCP実装WG。 1997年12月。 URL" ftp://ftp.ee.lbl.gov/talks/sf-tcp-ietf97.ps "。

Allman, et. al.               Experimental                      [Page 9]

RFC 2414            Increasing TCP's Initial Window       September 1998

etオールマン、アル。 TCPの初期の窓の1998年9月に増加する実験的な[9ページ]RFC2414

   [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".

[KAGT98]ハンス・クルーゼ、オールマン、ジムGriner、Diepchiチャンをマークしてください。 HTTPページ転送は静止衛星中継の上で評価します。 1998年3月。 通信システム" http://gigahertz.lerc.nasa.gov/~mallman/papers/nash98.ps "というURLにおける第6国際会議の議事。

   [MD90]      Mogul, J., and S. Deering, "Path MTU Discovery", RFC
               1191, November 1990.

[MD90] ムガール人、J.とS.デアリング、「経路MTU発見」、RFC1191、1990年11月。

   [MMFR96]    Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
               Selective Acknowledgment Options", RFC 2018, October
               1996.

[MMFR96] マシスとM.とMahdaviとJ.とフロイド、S.とA.Romanow、「TCPの選択している承認オプション」、RFC2018、1996年10月。

   [Mor97]     Robert Morris.  Private communication, 1997.  Cited for
               acknowledgement purposes only.

[Mor97]ロバート・モリス。 私信、1997。 承認目的だけのために、引用されます。

   [Nic97]     Kathleen Nichols.  Improving Network Simulation with
               Feedback.  Com21, Inc. Technical Report.  Available from
               http://www.com21.com/pages/papers/068.pdf.

[Nic97]キャサリーン・ニコルズ。 フィードバックとのネットワーク・シミュレーションを改良します。 Com21Inc.技術報告書。 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.

[PN98] Poduri、K.、およびK.ニコルズ、「増強された初期のTCPウィンドウサイズのシミュレーション研究」、RFC2415、1998年9月。

   [Pos82]     Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
               821, August 1982.

[Pos82] ポステル、J.、「簡単なメール転送プロトコル」、STD10、RFC821、1982年8月。

   [RF97]      Ramakrishnan, K., and S. Floyd, "A Proposal to Add
               Explicit Congestion Notification (ECN) to IPv6 and to
               TCP", Work in Progress.

K.、およびS.フロイド、「明白な混雑通知(電子証券取引ネットワーク)をIPv6と、そして、TCPに加えるという提案」という[RF97]Ramakrishnanは進行中で働いています。

   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

   [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.

[RFC2309] ブレーデン、B.、クラーク、D.、クロウクロフト、J.、デイビー、B.、デアリング、S.、Estrin、D.、フロイド、S.、ジェーコブソン、V.、Minshall、G.、ヤマウズラ、C.、ピーターソン、L.、Ramakrishnan、K.、Shenker、S.、Wroclawski、J.、およびL.チャン、「インターネットの待ち行列管理と輻輳回避の推薦」、RFC2309(1998年4月)。

   [S97]       Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast
               Retransmit, and Fast Recovery Algorithms", RFC 2001,
               January 1997.

[S97] スティーブンスと、W.と、「遅れた出発、輻輳回避が速く再送するTCP、および速い回復アルゴリズム」、RFC2001、1月1997日

   [SP97]      Shepard, T., and C. Partridge, "When TCP Starts Up With
               Four Packets Into Only Three Buffers", RFC 2416,
               September 1998.

[SP97] シェパード、T.、およびC.ヤマウズラ、「いつTCPは4つのパケットと共に3つのバッファだけに始動する」RFC2416(1998年9月)。

Allman, et. al.               Experimental                     [Page 10]

RFC 2414            Increasing TCP's Initial Window       September 1998

etオールマン、アル。 TCPの初期の窓の1998年9月に増加する実験的な[10ページ]RFC2414

12.  Author's Addresses

12. 作者のアドレス

   Mark Allman
   NASA Lewis Research Center/Sterling Software
   21000 Brookpark Road
   MS 54-2
   Cleveland, OH 44135

Brookpark Road MS54-2クリーブランド、マークオールマンNASAルイス・リサーチセンター/英貨のSoftware21000OH 44135

   EMail: mallman@lerc.nasa.gov
   http://gigahertz.lerc.nasa.gov/~mallman/

メール: mallman@lerc.nasa.gov http://gigahertz.lerc.nasa.gov/~mallman/

   Sally Floyd
   Lawrence Berkeley National Laboratory
   One Cyclotron Road
   Berkeley, CA 94720

サリー・フロイド・ローレンス・バークレーの国家の研究所1サイクロトロンRoadバークレー、カリフォルニア 94720

   EMail: floyd@ee.lbl.gov

メール: floyd@ee.lbl.gov

   Craig Partridge
   BBN Technologies
   10 Moulton Street
   Cambridge, MA 02138

クレイグヤマウズラBBN技術10モールトン・通りケンブリッジ、MA 02138

   EMail: craig@bbn.com

メール: craig@bbn.com

Allman, et. al.               Experimental                     [Page 11]

RFC 2414            Increasing TCP's Initial Window       September 1998

etオールマン、アル。 TCPの初期の窓の1998年9月に増加する実験的な[11ページ]RFC2414

13.  Appendix - Duplicate Segments

13. 付録--セグメントをコピーしてください。

   In the current environment (without Explicit Congestion Notification
   [Flo94] [RF97]), all TCPs use segment drops as indications from the
   network about the limits of available bandwidth.  We argue here that
   the change to a larger initial window should not result in the sender
   retransmitting a large number of duplicate segments that have already
   been received at the receiver.

現在の環境(Explicit Congestion Notification[Flo94][RF97]のない)で、すべてのTCPsが指摘として利用可能な帯域幅の限界に関するネットワークからセグメント低下を使用します。 私たちは、ここで、より大きい初期の窓への変化が受信機に既に受け取られた多くの写しセグメントを再送する送付者をもたらすはずがないと主張します。

   If one segment is dropped from the initial window, there are three
   different ways for TCP to recover: (1) Slow-starting from a window of
   one segment, as is done after a retransmit timeout, or after Fast
   Retransmit in Tahoe TCP; (2) Fast Recovery without selective
   acknowledgments (SACK), as is done after three duplicate ACKs in Reno
   TCP; and (3) Fast Recovery with SACK, for TCP where both the sender
   and the receiver support the SACK option [MMFR96].  In all three
   cases, if a single segment is dropped from the initial window, no
   duplicate segments (i.e., segments that have already been received at
   the receiver) are transmitted.  Note that for a TCP sending four
   512-byte segments in the initial window, a single segment drop will
   not require a retransmit timeout, but can be recovered from using the
   Fast Retransmit algorithm (unless the retransmit timer expires
   prematurely).  In addition, a single segment dropped from an initial
   window of three segments might be repaired using the fast retransmit
   algorithm, depending on which segment is dropped and whether or not
   delayed ACKs are used.  For example, dropping the first segment of a
   three segment initial window will always require waiting for a
   timeout.  However, dropping the third segment will always allow
   recovery via the fast retransmit algorithm, as long as no ACKs are
   lost.

1つのセグメントが初期の窓から落とされるなら、TCPが回復する3つの異なった方法があります: (1) あるセグメントの窓から始まります遅い、された後aのように、タホTCPでタイムアウト、または後Fast Retransmitを再送してください。 (2) 3がリノTCPにACKsをコピーした後にするような選択している承認(SACK)のない速いRecovery (3) そして、送付者と受信機の両方がSACKオプション[MMFR96]をサポートするTCPのためのSACKと速いRecovery。 すべての3つの場合では、ただ一つのセグメントが初期の窓から落とされるなら、写しセグメント(すなわち、受信機に既に受け取られたセグメント)は全く伝えられません。 TCPが初期の窓で4つの512バイトのセグメントを送ると、単一のセグメント低下がaを必要としないので、タイムアウトを再送しますが、Fast Retransmitアルゴリズム(再送信タイマが早まって期限が切れない場合)を使用するのを取り戻すことができる注意。 さらに、3つのセグメントの初期の窓から落とされたただ一つのセグメントは速さを使用することで修理されて、アルゴリズムを再送してください、どのセグメントによるかが落とされて、遅らせられるか否かに関係なく、ACKsが使用されているということであるかもしれません。 例えば、3のセグメントの初期のウィンドウの最初のセグメントを落とすのは、いつもタイムアウトを待つのを必要とするでしょう。 しかしながら、3番目のセグメントが速さであることを通していつも回復を許す低下はアルゴリズムを再送します、どんなACKsも無くならない限り。

   Next we consider scenarios where the initial window contains two to
   four segments, and at least two of those segments are dropped.  If
   all segments in the initial window are dropped, then clearly no
   duplicate segments are retransmitted, as the receiver has not yet
   received any segments.  (It is still a possibility that these dropped
   segments used scarce bandwidth on the way to their drop point; this
   issue was discussed in Section 5.)

次に、私たちは初期の窓が2〜4つのセグメントを含むシナリオを考えます、そして、少なくともそれらの2つのセグメントが落とされます。 初期の窓のすべてのセグメントが落とされるなら、明確に写しセグメントは全く再送されません、受信機がまだどんなセグメントも受けていないとき。 (それでも、それはこれらの低下しているセグメントがそれらの低下ポイントへの途中で不十分な帯域幅を使用した可能性です; セクション5でこの問題について議論しました。)

   When two segments are dropped from an initial window of three
   segments, the sender will only send a duplicate segment if the first
   two of the three segments were dropped, and the sender does not
   receive a packet with the SACK option acknowledging the third
   segment.

2つのセグメントが3つのセグメントの初期の窓から落とされるとき、3つのセグメントのうち最初の2が落とされて、送付者が3番目のセグメントを承認しながらSACKオプションでパケットを受けない場合にだけ、送付者は写しセグメントを送るでしょう。

   When two segments are dropped from an initial window of four
   segments, an examination of the six possible scenarios (which we
   don't go through here) shows that, depending on the position of the

2つのセグメントが4つのセグメントの初期の窓から落とされます、と6つの可能なシナリオ(私たちがここを通らない)の試験はそれを示しています、位置によっていつで

Allman, et. al.               Experimental                     [Page 12]

RFC 2414            Increasing TCP's Initial Window       September 1998

etオールマン、アル。 TCPの初期の窓の1998年9月に増加する実験的な[12ページ]RFC2414

   dropped packets, in the absence of SACK the sender might send one
   duplicate segment.  There are no scenarios in which the sender sends
   two duplicate segments.

低下しているパケットであり、SACKが不在のとき送付者は1つの写しセグメントを送るかもしれません。 送付者が2つの写しセグメントを送るシナリオが全くありません。

   When three segments are dropped from an initial window of four
   segments, then, in the absence of SACK, it is possible that one
   duplicate segment will be sent, depending on the position of the
   dropped segments.

次に、3つのセグメントがSACKが不在のとき4つのセグメントの初期の窓から落とされるとき、1つの写しセグメントを送るのは可能です、低下しているセグメントの位置によって。

   The summary is that in the absence of SACK, there are some scenarios
   with multiple segment drops from the initial window where one
   duplicate segment will be transmitted.  There are no scenarios where
   more that one duplicate segment will be transmitted.  Our conclusion
   is that the number of duplicate segments transmitted as a result of a
   larger initial window should be small.

概要はSACKが不在のとき初期の窓からの複数のセグメント低下があるいくつかのシナリオが1つの写しセグメントが伝えられるところにあるということです。 シナリオが全くある写しが区分する以上が伝えられるところにありません。 私たちの結論は、より大きい初期の窓の結果、伝えられた写しセグメントの数が少ないはずであるということです。

Allman, et. al.               Experimental                     [Page 13]

RFC 2414            Increasing TCP's Initial Window       September 1998

etオールマン、アル。 TCPの初期の窓の1998年9月に増加する実験的な[13ページ]RFC2414

14.  Full Copyright Statement

14. 完全な著作権宣言文

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

Copyright(C)インターネット協会(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.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   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.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Allman, et. al.               Experimental                     [Page 14]

etオールマン、アル。 実験的[14ページ]