RFC3390 日本語訳

Network Working Group                                          M. Allman
Request for Comments: 3390                                  BBN/NASA GRC
Obsoletes: 2414                                                 S. Floyd
Updates: 2581                                                       ICIR
Category: Standards Track                                   C. Partridge
                                                        BBN Technologies
                                                            October 2002

コメントを求めるワーキンググループM.オールマン要求をネットワークでつないでください: 3390BBN/NASA GRCは以下を時代遅れにします。 2414秒間フロイドUpdates: 2581年のICIRカテゴリ: 標準化過程C.ヤマウズラBBN技術2002年10月

                    Increasing TCP's Initial Window

増加するTCPの初期の窓

Status of this Memo

このMemoの状態

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

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

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

Abstract

要約

   This document specifies an optional standard for TCP to increase the
   permitted initial window from one or two segment(s) to roughly 4K
   bytes, replacing RFC 2414.  It discusses the advantages and
   disadvantages of the higher initial window, and includes discussion
   of experiments and simulations showing that the higher initial window
   does not lead to congestion collapse.  Finally, this document
   provides guidance on implementation issues.

TCPが受入れられた初期の窓を1か2つのセグメントからおよそ4Kのバイトまで増強するように、このドキュメントは任意の規格を指定します、RFC2414を取り替えて。 それは、より高い初期の窓の利点と難点について議論して、実験の議論を含んでいます、そして、より高い初期の窓が混雑に通じないのを示すシミュレーションが崩れます。 最終的に、このドキュメントは導入問題で指導を提供します。

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 obsoletes [RFC2414] and updates [RFC2581] and specifies
   an increase in the permitted upper bound for TCP's initial window
   from one or two segment(s) 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 may be significantly larger than 4K
   bytes).

このドキュメントは、1か2つのセグメントから2〜4つのセグメントまで[RFC2414]とアップデート[RFC2581]を時代遅れにして、TCPの初期の窓に受入れられた上限の増加を指定します。 多くの場合、この変化はおよそ4Kのバイトの初期の窓で上限をもたらします(大きいセグメントサイズを与えますが、2つのセグメントの受入れられた初期の窓は4Kのバイトよりかなり大きいかもしれません)。

Allman, et. al.             Standards Track                     [Page 1]

RFC 3390            Increasing TCP's Initial Window         October 2002

etオールマン、アル。 TCPの初期の窓の2002年10月に増加する標準化過程[1ページ]RFC3390

   The upper bound for the initial window is given more precisely in
   (1):

(1)で、より正確に初期の窓への上限を与えます:

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

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

   Note: Sending a 1500 byte packet indicates a maximum segment size
   (MSS) of 1460 bytes (assuming no IP or TCP options).  Therefore,
   limiting the initial window's MSS to 4380 bytes allows the sender to
   transmit three segments initially in the common case when using 1500
   byte packets.

以下に注意してください。 1500年のバイトのパケットを送ると、最大1460バイトのセグメントサイズ(MSS)は示されます(IPかどんなTCPもオプションでないと仮定して)。 したがって、初期の窓のMSSを4380バイトに制限するのに、初めは1500年のバイトのパケットを使用するとき、送付者はよくある例で3つのセグメントを伝えることができます。

   Equivalently, the upper bound for the initial window size is based on
   the 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: a TCP MAY start with a
   larger initial window.  However, we expect that most general-purpose
   TCP implementations would choose to use the larger initial congestion
   window given in equation (1) above.

この増強された初期の窓は任意です: より大きい初期の窓によるTCP MAY始め。 しかしながら、私たちは、ほとんどの汎用TCP実装が、方程式(1)で上に与えられたより大きい初期の混雑ウィンドウを使用するのを選ぶと予想します。

   This upper bound for the initial window size represents a change from
   RFC 2581 [RFC2581], which specified that the congestion window be
   initialized to one or two segments.

初期のウィンドウサイズのためのこの上限は混雑ウィンドウが初期化されると指定したRFC2581年[RFC2581]から1か2つのセグメントまでの変化を表します。

   This change applies to the initial window of the connection in the
   first round trip time (RTT) of data 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 consisting of MSS bytes.

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

   TCP implementations use slow start in as many as three different
   ways: (1) to start a new connection (the initial window); (2) to
   restart transmission after a long idle period (the restart window);
   and (3) to restart transmission after a retransmit timeout (the loss
   window).  The change specified 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 of MSS bytes (to

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

Allman, et. al.             Standards Track                     [Page 2]

RFC 3390            Increasing TCP's Initial Window         October 2002

etオールマン、アル。 TCPの初期の窓の2002年10月に増加する標準化過程[2ページ]RFC3390

   permit the lowest possible window size in the case of severe
   congestion).

許可証、厳しい混雑の場合における可能な限り低いウィンドウサイズ)

2.  Implementation Issues

2. 導入問題

   When larger initial windows are implemented along with Path MTU
   Discovery [RFC1191], 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ディスカバリー[RFC1191]、および使用されるのが大き過ぎる混雑ウィンドウ'cwnd'SHOULDになるように見つけられるMSSと共に、減少して、より小さいセグメントの大きい炸裂を防いでください。 明確に'cwnd'SHOULD、古いセグメントサイズ対新しいセグメントサイズの比率で、減少されてください。

   When larger initial windows are implemented along with Path MTU
   Discovery [RFC1191], 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 as
   to which of these two alternatives is best; we would hope that
   implementation experiences will shed light on this question.  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ディスカバリー[RFC1191]と共に実装されるとき、選択肢は、初期の窓のすべてのセグメントで「断片化しないでください」という(DF)ビットを設定するか、またはセグメントの1つで「断片化しないでください」という(DF)ビットを設定することです。 最善がこれらの2つの選択肢のどれをあるかとき、それは未決問題です。 私たちは、実装経験がこの質問を解明することを望んでいるでしょう。 前者の場合、初期のパケットが大き過ぎるなら、すべてのセグメントにDFビットをはめ込むのにおいて、初期のパケットのすべてがネットワークで下げられるでしょう。 1つのセグメントだけにDFビットをはめ込む2番目の場合では、初期のパケットが大き過ぎるなら、初期のパケットの1つ以外のすべてがネットワークで断片化されるでしょう。 2番目のケースが従われているとき、初期のセグメントサイズが大き過ぎるのがわかっているとき、初期の窓における最後のセグメントにDFビットをはめ込むと、最少の見込みは不必要な「再-トランスミッション」に供給されます、写しACKsがFast Retransmitの引き金となるという可能性を最小にするので。 しかしながら、より多くの注意が、より大きい初期の窓とPath MTUディスカバリーとの相互作用に支払われる必要があります。

   The larger initial window specified in this document is not intended
   as 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, they are
   working against TCP's congestion control mechanisms [FF99],
   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.  We suggest the use of HTTP/1.1
   [RFC2068] (persistent TCP connections and pipelining) as a way to
   achieve better performance of web transfers.

本書では指定されたより大きい初期の窓は奨励としてウェブブラウザが複数の同時のTCP接続を開くことを意図しません、すべて大きい初期の窓で。 ウェブブラウザが同時のTCP接続を同じ目的地に開くと、彼らはTCPの混雑制御機構[FF99]に不利に働いています、初期の窓のサイズにかかわらず。 より大きい初期の窓にこの振舞いを結合すると、不公平はネットワークで他のトラフィックにさらに増強されます。 私たちはウェブ転送の、より良い性能を達成する方法としてHTTP/1.1[RFC2068](永続的なTCP接続とパイプライン処理)の使用を勧めます。

3.  Advantages of Larger Initial Windows

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

   1.  When the initial window is one segment, a receiver employing
       delayed ACKs [RFC1122] 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, and possibly up to 500 msec [RFC1122]).

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

Allman, et. al.             Standards Track                     [Page 3]

RFC 3390            Increasing TCP's Initial Window         October 2002

etオールマン、アル。 TCPの初期の窓の2002年10月に増加する標準化過程[3ページ]RFC3390

   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 [RFC1945, RFC2068]) 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[RFC1945、RFC2068])転送のために、より大きい初期の窓はデータ転送時間を独身の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
       will be of particular benefit for high-bandwidth large-
       propagation-delay TCP connections, such as those over satellite
       links.

3. 大きい混雑ウィンドウを使用できる接続のために、この変更は初期の遅れた出発段階の間、最大3RTTsと遅れたACKタイムアウトを排除します。 これは衛星中継の上のそれらなどの高帯域の大きい伝播遅延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 larger
   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

混雑崩壊の可能性に関して、私たちはネットワークのために2つの別々の潜在的危険を考えます。 危険がシナリオがどこであったかでそうする1番目 混雑しているリンクの上の多くのセグメント

Allman, et. al.             Standards Track                     [Page 4]

RFC 3390            Increasing TCP's Initial Window         October 2002

etオールマン、アル。 TCPの初期の窓の2002年10月に増加する標準化過程[4ページ]RFC3390

   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番目の危険は混雑しているリンクの上の多くのセグメントがそれらの最終的な目的地に達する前に後でネットワークで下げられるセグメントであったシナリオでしょう。

   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冊について議論します。

   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接続に同様になるでしょう。

Allman, et. al.             Standards Track                     [Page 5]

RFC 3390            Increasing TCP's Initial Window         October 2002

etオールマン、アル。 TCPの初期の窓の2002年10月に増加する標準化過程[5ページ]RFC3390

   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でこれらの問題のシミュレーションベースの探検について議論します。

   These potential dangers for the network are explored in simulations
   and experiments described in the section below.  Our judgment is that
   while there are dangers of congestion collapse in the current
   Internet (see [FF99] 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.

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

6.  Interactions with the Retransmission Timer

6. 再送信タイマーとの相互作用

   Using a larger initial burst of data can exacerbate existing problems
   with spurious retransmit timeouts on low-bandwidth paths, assuming
   the standard algorithm for determining the TCP retransmission timeout
   (RTO) [RFC2988].  The problem is that across low-bandwidth network
   paths on which the transmission time of a packet is a large portion
   of the round-trip time, the small packets used to establish a TCP
   connection do not seed the RTO estimator appropriately.  When the
   first window of data packets is transmitted, the sender's retransmit
   timer could expire before the acknowledgments for those packets are
   received.  As each acknowledgment arrives, the retransmit timer is
   generally reset.  Thus, the retransmit timer will not expire as long
   as an acknowledgment arrives at least once a second, given the one-
   second minimum on the RTO recommended in RFC 2988.

データの、より大きいイニシャル・バーストを使用すると、TCP再送タイムアウト(RTO)[RFC2988]を決定するために低バンド幅経路でタイムアウトを再送して、標準のアルゴリズムを仮定しながら、偽りに関する既存の問題を悪化させることができます。 問題はパケットのトランスミッション時間が往復の現代の大半である低バンド幅ネットワーク経路中では、TCP接続を証明するのに使用される小型小包が適切にRTO見積り人をシードしないということです。 データ・パケットの最初の窓が伝えられるとき、それらのパケットのための承認が受け取られている前に送付者の再送信タイマは期限が切れることができました。 各承認が到着するとき、一般に、再送信タイマはリセットされます。 したがって、承認が少なくとも1秒に一度到着する限り、再送信タイマは期限が切れないでしょう、RFC2988のお勧めのRTOの上の2番目の1つの最小限を考えて。

   For instance, consider a 9.6 Kbps link.  The initial RTT measurement
   will be on the order of 67 msec, if we simply consider the
   transmission time of 2 packets (the SYN and SYN-ACK), each consisting
   of 40 bytes.  Using the RTO estimator given in [RFC2988], this yields
   an initial RTO of 201 msec (67 + 4*(67/2)).  However, we round the
   RTO to 1 second as specified in RFC 2988.  Then assume we send an
   initial window of one or more 1500-byte packets (1460 data bytes plus
   overhead).  Each packet will take on the order of 1.25 seconds to
   transmit.  Therefore, the RTO will fire before the ACK for the first
   packet returns, causing a spurious timeout.  In this case, a larger
   initial window of three or four packets exacerbates the problems
   caused by this spurious timeout.

例えば、9.6Kbpsがリンクすると考えてください。 67msecの注文には初期のRTT測定があるでしょう、私たちが、2つのパケットのトランスミッション時間が(SYNとSYN-ACK)であると単に考えるなら、40バイトからそれぞれ成って。 [RFC2988]で与えられているRTO見積り人を使用して、これは201msec(67+4*(67/2))の初期のRTOをもたらします。 しかしながら、私たちはRTOをRFC2988の指定されるとしての1秒まで一周させます。 そして、私たちが1つ以上の1500年のバイトのパケット(1460データ・バイトとオーバーヘッド)の初期の窓を送ると仮定してください。 各パケットは1.25秒が伝わる命令を帯びるでしょう。 したがって、偽りのタイムアウトを引き起こして、最初のパケットのためのACKが戻る前にRTOは発火するでしょう。 この場合、3か4つのパケットの、より大きい初期の窓はこの偽りのタイムアウトによって引き起こされた問題を悪化させます。

Allman, et. al.             Standards Track                     [Page 6]

RFC 3390            Increasing TCP's Initial Window         October 2002

etオールマン、アル。 TCPの初期の窓の2002年10月に増加する標準化過程[6ページ]RFC3390

   One way to deal with this problem is to make the RTO algorithm more
   conservative.  During the initial window of data, for instance, the
   RTO could be updated for each acknowledgment received.  In addition,
   if the retransmit timer expires for some packet lost in the first
   window of data, we could leave the exponential-backoff of the
   retransmit timer engaged until at least one valid RTT measurement,
   that involves a data packet, is received.

この問題に対処する1つの方法はRTOアルゴリズムをより保守的にすることです。 データの初期の窓の間、例えば、受けられた各承認のためにRTOをアップデートできました。 再送信タイマがデータの最初の窓で失われたあるパケットのために期限が切れるなら、さらに、私たちが少なくとも1時まで噛み合っている再送信タイマの指数のbackoffの有効なRTTを測定に残すかもしれなくて、それは、データ・パケットにかかわって、受け取られています。

   Another method would be to refrain from taking an RTT sample during
   connection establishment, leaving the default RTO in place until TCP
   takes a sample from a data segment and the corresponding ACK.  While
   this method likely helps prevent spurious retransmits, it also may
   slow the data transfer down if loss occurs before the RTO is seeded.
   The use of limited transmit [RFC3042] to aid a TCP connection in
   recovering from loss using fast retransmit rather than the RTO timer
   mitigates the performance degradation caused by using the high
   default RTO during the initial window of data transmission.

別のメソッドはコネクション確立の間、RTTのサンプルを取るのを控えるだろうことです、TCPがデータ・セグメントと対応するACKからサンプリングするまで適所でデフォルトをRTOに出発して。 ありそうな力添えが防ぐこのメソッドをゆったり過ごしてください、偽り、再送する、また、RTOが種を蒔かれる前に損失が発生するなら、それはデータ転送を減速させるかもしれません。 制限されることの使用は、使用が速くむしろ再送する損失から回復する際にTCP接続を支援するためにRTOタイマがデータ伝送の初期の窓の間、高いデフォルトRTOを使用することによって引き起こされた性能退行を緩和するより[RFC3042]を伝えます。

   This specification leaves the decision about what to do (if anything)
   with regards to the RTO, when using a larger initial window, to the
   implementer.  However, the RECOMMENDED approach is to refrain from
   sampling the RTT during the three-way handshake, keeping the default
   RTO in place until an RTT sample involving a data packet is taken.
   In addition, it is RECOMMENDED that TCPs use limited transmit
   [RFC3042].

より大きい初期の窓を使用するとき、この仕様はあいさつでRTOにするべき(どちらかと言えば)ことに関する決定を任せます、implementerに。 しかしながら、RECOMMENDEDアプローチは3方向ハンドシェイクの間、RTTを抽出するのを控えることです、データ・パケットにかかわるRTTのサンプルを取るまでデフォルトRTOを適所に保って。 さらに、制限されたTCPs使用が[RFC3042]を伝えるのは、RECOMMENDEDです。

7.  Typical Levels of Burstiness for TCP Traffic.

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

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

Allman, et. al.             Standards Track                     [Page 7]

RFC 3390            Increasing TCP's Initial Window         October 2002

etオールマン、アル。 TCPの初期の窓の2002年10月に増加する標準化過程[7ページ]RFC3390

   queue management mechanisms such as RED, which is designed to be
   tolerant of transient traffic bursts.

REDなどの管理メカニズムを列に並ばせてください。(REDは、一時的なトラフィック炸裂において許容性があるように設計されています)。

8.  Simulations and Experimental Results

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

8.1 Studies of TCP Connections using that Larger Initial Window

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

   This section surveys simulations and experiments that explore the
   effect of larger initial windows on TCP connections.  The first set
   of experiments explores performance over satellite links.  Larger
   initial windows have been shown to improve the 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 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 [Nic98].

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

   A second set of experiments 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 simulation study [RFC2416] 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.

2番目の1セットの実験はダイアルアップモデムリンクの上のTCP性能を探りました。 28.8ビーピーエスダイアルアップチャンネル[All97a、AHO98]の上の実験では、4セグメントの初期の窓は16KBのファイルの転送時間をおよそ10%減少させました、低下率の付随の増加なしで。 シミュレーション研究[RFC2416]は遅いモデムリンクとルータによって3パケットバッファに接続されたホストの上の、より大きい初期の窓を使用するという効果を調査しました。 研究は、シナリオのためのそれが調査されたと結論づけて、より大きい初期の窓の使用はTCP性能に有害ではありませんでした。

   Finally, [All00] illustrates that the percentage of connections at a
   particular web server that experience loss in the initial window of
   data transmission increases with the size of the initial congestion
   window.  However, the increase is in line with what would be expected
   from sending a larger burst into the network.

最終的に、[All00]は、初期の混雑ウィンドウのサイズに従って特定のウェブサーバーにおけるデータ伝送の初期の窓の損失を経験する接続の割合が増加するのを例証します。 しかしながら、より大きい炸裂をネットワークに送るので予想されることに沿って増加があります。

8.2 Studies of Networks using Larger Initial Windows

より大きい初期のWindowsを使用するネットワークの8.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%短縮されました。

Allman, et. al.             Standards Track                     [Page 8]

RFC 3390            Increasing TCP's Initial Window         October 2002

etオールマン、アル。 TCPの初期の窓の2002年10月に増加する標準化過程[8ページ]RFC3390

   A simulation study in [RFC2415] 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 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.

[RFC2415]のシミュレーション研究は競争しているネットワークトラフィックの、より大きい初期の窓の影響について調査します。 この調査では、HTTPとFTP流れは混雑している1つの門(HTTPとFTP流れの数が1つのシミュレーションセットから別のものに異なるところ)を共有します。 それぞれのシミュレーションセットがないかどうか、論文は集合リンク利用とパケット低下率を調べます、中央のウェブページ遅れ、そして、FTPのためのネットワークパワーは移されます。 一般に、もたらされるより大きい初期の窓は総合的なネットワークパワーでスループット、わずかに増強されたパケット低下率、および増加を増強しました。 1つのシナリオを除いて、より大きい初期の窓は1セグメントの初期の窓を使用するとき経験された損失率より高い1%未満の低下率の増加をもたらしました。 このシナリオでは、低下率は1セグメントの初期の窓で3.5%から4セグメントの初期の窓がある4.5%まで増えました。 総合的な結論はTCPの初期の窓を3つのパケット(4380バイト)まで増強するのが、知覚された性能を向上させるのを助けるということでした。

   Morris [Mor97] investigated larger initial windows in a highly
   congested network with transfers of 20K in size.  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 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つのセグメントである非常に混雑している環境で、両方の損失率の知覚可能な増加が引き起こされる場合があるのを示して、タイムアウトを再送します。

9.  Security Considerations

9. セキュリティ問題

   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の少しの知られている新しい安全保障問題も提起しません。

10. Conclusion

10. 結論

   This document specifies a small change to TCP that will likely 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に小銭を指定します。

Allman, et. al.             Standards Track                     [Page 9]

RFC 3390            Increasing TCP's Initial Window         October 2002

etオールマン、アル。 TCPの初期の窓の2002年10月に増加する標準化過程[9ページ]RFC3390

11. Acknowledgments

11. 承認

   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 and for feedback on this document.

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

12. References

12. 参照

   [AHO98]   Mark Allman, Chris Hayes, and Shawn Ostermann, An
             Evaluation of TCP with Larger Initial Windows, March 1998.
             ACM Computer Communication Review, 28(3), July 1998.  URL
             "http://roland.lerc.nasa.gov/~mallman/papers/initwin.ps".

[AHO98] より大きい初期のWindows、1998年3月とのマークオールマン、クリス・ヘイズとショーン・オステルマン、TCPの評価。 ACMコンピュータコミュニケーションレビュー、28(3)、1998年7月。 URL" http://roland.lerc.nasa.gov/~mallman/papers/initwin.ps "。

   [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)。

   [All97b]  Mark Allman.  Improving TCP Performance Over Satellite
             Channels.  Master's thesis, Ohio University, June 1997.

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

   [All00]   Mark Allman. A Web Server's View of the Transport Layer.
             ACM Computer Communication Review, 30(5), October 2000.

[All00]はオールマンをマークします。 ウェブサーバーのトランスポート層の視点。 ACMコンピュータコミュニケーションレビュー、30(5)、2000年10月。

   [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月。

   [FF99]    Sally Floyd, Kevin Fall.  Promoting the Use of End-to-End
             Congestion Control in the Internet.  IEEE/ACM Transactions
             on Networking, August 1999.  URL
             "http://www.icir.org/floyd/end2end-paper.html".

[FF99]はフロイド、ケビンFallを出撃させます。 インターネットでの終わりからエンドへの輻輳制御の使用を促進します。 1999年8月のネットワークのIEEE/ACM取引。 URL" http://www.icir.org/floyd/end2end-paper.html "。

   [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.             Standards Track                    [Page 10]

RFC 3390            Increasing TCP's Initial Window         October 2002

etオールマン、アル。 TCPの初期の窓の2002年10月に増加する標準化過程[10ページ]RFC3390

   [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://roland.lerc.nasa.gov/~mallman/papers/nash98.ps".

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

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

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

   [Nic98]   Kathleen Nichols. Improving Network Simulation With
             Feedback, Proceedings of LCN 98, October 1998. URL
             "http://www.computer.org/proceedings/lcn/8810/8810toc.htm".

[Nic98]キャサリーン・ニコルズ。 1998年10月にフィードバックとのネットワーク・シミュレーション、LCN98の議事を改良します。 URL" http://www.computer.org/proceedings/lcn/8810/8810toc.htm "。

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

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

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

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

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

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

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

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

   [RFC2068] Fielding, R., Mogul, J., Gettys, J., Frystyk, H. and T.
             Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
             2616, January 1997.

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

   [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月)。

   [RFC2414] Allman, M., Floyd, S. and C. Partridge, "Increasing TCP's
             Initial Window", RFC 2414, September 1998.

[RFC2414] オールマンとM.とフロイドとS.とC.ヤマウズラ、「増加するTCPの初期の窓」、RFC2414、1998年9月。

   [RFC2415] Poduri, K. and K. Nichols, "Simulation Studies of Increased
             Initial TCP Window Size", RFC 2415, September 1998.

[RFC2415] PoduriとK.とK.ニコルズ、「増加する初期のTCPウィンドウサイズのシミュレーション研究」、RFC2415、1998年9月。

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

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

Allman, et. al.             Standards Track                    [Page 11]

RFC 3390            Increasing TCP's Initial Window         October 2002

etオールマン、アル。 TCPの初期の窓の2002年10月に増加する標準化過程[11ページ]RFC3390

   [RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion
             Control", RFC 2581, April 1999.

[RFC2581] オールマンとM.とパクソンとV.とW.スティーブンス、「TCP輻輳制御」、RFC2581、1999年4月。

   [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
             April 2001.

[RFC2821] Klensin、J.、「簡単なメール転送プロトコル」、RFC2821、2001年4月。

   [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission
             Timer", RFC 2988, November 2000.

[RFC2988] パクソンとV.とM.オールマン、「コンピューティングTCPの再送信タイマー」、RFC2988、2000年11月。

   [RFC3042] Allman, M., Balakrishnan, H. and S. Floyd, "Enhancing TCP's
             Loss Recovery Using Limited Transmit", RFC 3042, January
             2001.

[RFC3042] オールマンとM.とBalakrishnanとH.とS.フロイド、「株式会社を使用することでTCPの損失回復を機能アップして、伝わってください」、RFC3042、2001年1月。

   [RFC3168] Ramakrishnan, K.K., Floyd, S. and D. Black, "The Addition
             of Explicit Congestion Notification (ECN) to IP", RFC 3168,
             September 2001.

[RFC3168]RamakrishnanとK.K.とフロイドとS.とD.黒、「明白な混雑通知(電子証券取引ネットワーク)のIPへの追加」、RFC3168、2001年9月。

Allman, et. al.             Standards Track                    [Page 12]

RFC 3390            Increasing TCP's Initial Window         October 2002

etオールマン、アル。 TCPの初期の窓の2002年10月に増加する標準化過程[12ページ]RFC3390

Appendix A - Duplicate Segments

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

   In the current environment (without Explicit Congestion Notification
   [Flo94] [RFC2481]), 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 arrived at the receiver.

現在の環境(Explicit Congestion Notification[Flo94][RFC2481]のない)で、すべての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 by 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, in the absence of Limited Transmit [RFC3042].  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のセグメントの初期のウィンドウの最初のセグメントを落とすのは、いつもタイムアウトを待つのを必要とするでしょう、株式会社Transmit[RFC3042]が不在のとき。 しかしながら、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.             Standards Track                    [Page 13]

RFC 3390            Increasing TCP's Initial Window         October 2002

etオールマン、アル。 TCPの初期の窓の2002年10月に増加する標準化過程[13ページ]RFC3390

   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 in
   which more than one duplicate segment will be transmitted.  Our
   conclusion is than the number of duplicate segments transmitted as a
   result of a larger initial window should be small.

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

Author's Addresses

作者のアドレス

   Mark Allman
   BBN Technologies/NASA Glenn Research Center
   21000 Brookpark Rd
   MS 54-5
   Cleveland, OH 44135
   EMail: mallman@bbn.com
   http://roland.lerc.nasa.gov/~mallman/

Brookpark第MS54-5クリーブランド、マークオールマンBBN技術/NASAグレンリサーチセンタ21000OH 44135はメールされます: mallman@bbn.com http://roland.lerc.nasa.gov/~mallman/

   Sally Floyd
   ICSI Center for Internet Research
   1947 Center St, Suite 600
   Berkeley, CA 94704
   Phone: +1 (510) 666-2989
   EMail: floyd@icir.org
   http://www.icir.org/floyd/

バークレー、Suite600カリフォルニア 1947センター通り、94704が電話をするインターネット調査のためにフロイドICSIセンターを出撃させてください: +1 (510) 666-2989 メールしてください: floyd@icir.org http://www.icir.org/floyd/

   Craig Partridge
   BBN Technologies
   10 Moulton St
   Cambridge, MA 02138
   EMail: craig@bbn.com

クレイグヤマウズラBBN技術10モールトン・Stケンブリッジ、MA 02138はメールされます: craig@bbn.com

Allman, et. al.             Standards Track                    [Page 14]

RFC 3390            Increasing TCP's Initial Window         October 2002

etオールマン、アル。 TCPの初期の窓の2002年10月に増加する標準化過程[14ページ]RFC3390

Full Copyright Statement

完全な著作権宣言文

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

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

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

Acknowledgement

承認

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Allman, et. al.             Standards Track                    [Page 15]

etオールマン、アル。 標準化過程[15ページ]