[要約] RFC 6928は、TCPの初期ウィンドウサイズを増やすための提案です。その目的は、ネットワークの効率性とパフォーマンスを向上させることです。
Internet Engineering Task Force (IETF) J. Chu
Request for Comments: 6928 N. Dukkipati
Category: Experimental Y. Cheng
ISSN: 2070-1721 M. Mathis
Google, Inc.
April 2013
Increasing TCP's Initial Window
TCPの初期ウィンドウを増やす
Abstract
概要
This document proposes an experiment to increase the permitted TCP initial window (IW) from between 2 and 4 segments, as specified in RFC 3390, to 10 segments with a fallback to the existing recommendation when performance issues are detected. It discusses the motivation behind the increase, the advantages and disadvantages of the higher initial window, and presents results from several large-scale experiments showing that the higher initial window improves the overall performance of many web services without resulting in a congestion collapse. The document closes with a discussion of usage and deployment for further experimental purposes recommended by the IETF TCP Maintenance and Minor Extensions (TCPM) working group.
このドキュメントは、RFC 3390で指定されているように、許可されるTCP初期ウィンドウ（IW）を2〜4セグメントから10セグメントに増やす実験を提案し、パフォーマンスの問題が検出されたときに既存の推奨にフォールバックします。増加の背後にある動機、より高い初期ウィンドウの利点と欠点について説明し、いくつかの大規模な実験の結果を示します。より高い初期ウィンドウは、輻輳の崩壊を招くことなく、多くのWebサービスの全体的なパフォーマンスを向上させることを示しています。このドキュメントは、IETF TCPメンテナンスおよびマイナーエクステンション（TCPM）ワーキンググループによって推奨されるさらなる実験目的のための使用法と展開の説明で締めくくられます。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントでは、インターネットコミュニティの実験プロトコルを定義します。このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6928.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6928で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Terminology ................................................4
2. TCP Modification ................................................4
3. Implementation Issues ...........................................5
4. Background ......................................................6
5. Advantages of Larger Initial Windows ............................7
5.1. Reducing Latency ...........................................7
5.2. Keeping Up with the Growth of Web Object Size ..............8
5.3. Recovering Faster from Loss on Under-Utilized or
Wireless Links .............................................8
6. Disadvantages of Larger Initial Windows for the Individual ......9
7. Disadvantages of Larger Initial Windows for the Network ........10
8. Mitigation of Negative Impact ..................................11
9. Interactions with the Retransmission Timer .....................11
10. Experimental Results From Large-Scale Cluster Tests ...........11
10.1. The Benefits .............................................11
10.2. The Cost .................................................12
11. Other Studies .................................................13
12. Usage and Deployment Recommendations ..........................14
13. Related Proposals .............................................15
14. Security Considerations .......................................16
15. Conclusion ....................................................16
16. Acknowledgments ...............................................16
17. References ....................................................16
17.1. Normative References .....................................16
17.2. Informative References ...................................17
Appendix A. List of Concerns and Corresponding Test Results .......21
This document proposes to raise the upper bound on TCP's initial window (IW) to 10 segments (maximum 14600 B). It is patterned after and borrows heavily from RFC 3390 [RFC3390] and earlier work in this area. Due to lingering concerns about possible side effects to other flows sharing the same network bottleneck, some of the recommendations are conditional on additional monitoring and evaluation.
このドキュメントでは、TCPの初期ウィンドウ（IW）の上限を10セグメント（最大14600 B）に引き上げることを提案しています。これは、RFC 3390 [RFC3390]およびこの領域での以前の作業を模倣し、大幅に取り入れています。同じネットワークボトルネックを共有する他のフローへの副作用の可能性に関する懸念が長引いているため、一部の推奨事項は追加の監視と評価を条件としています。
The primary argument in favor of raising IW follows from the evolving scale of the Internet. Ten segments are likely to fit into queue space available at any broadband access link, even when there are a reasonable number of concurrent connections.
IWの引き上げを支持する主な議論は、インターネットの進化する規模から来ています。 10個のセグメントは、適切な数の同時接続がある場合でも、ブロードバンドアクセスリンクで利用可能なキュースペースに収まる可能性があります。
Lower speed links can be treated with environment-specific configurations, such that they can be protected from being overwhelmed by large initial window bursts without imposing a suboptimal initial window on the rest of the Internet.
低速リンクは環境固有の構成で処理できるため、インターネットの残りの部分に次善の初期ウィンドウを課すことなく、大きな初期ウィンドウバーストによって圧倒されないように保護できます。
This document reviews the advantages and disadvantages of using a larger initial window and includes summaries of several large-scale experiments showing that an initial window of 10 segments (IW10) provides benefits across the board for a variety of bandwidth (BW), round-trip time (RTT), and bandwidth-delay product (BDP) classes. These results show significant benefits for increasing IW for users at much smaller data rates than had been previously anticipated. However, at initial windows larger than 10, the results are mixed. We believe that these mixed results are not intrinsic but are the consequence of various implementation artifacts, including overly aggressive applications employing many simultaneous connections.
このドキュメントでは、より大きな初期ウィンドウを使用することの利点と欠点を確認し、10セグメントの初期ウィンドウ（IW10）がさまざまな帯域幅（BW）、ラウンドトリップでボード全体にメリットをもたらすことを示すいくつかの大規模実験の概要を示します時間（RTT）、および帯域幅遅延積（BDP）クラス。これらの結果は、以前に予想されていたよりもはるかに小さいデータレートでユーザーのIWを増やすことの大きな利点を示しています。ただし、10より大きい初期ウィンドウでは、結果はさまざまです。これらの混合結果は本質的なものではなく、多数の同時接続を使用する過度にアグレッシブなアプリケーションを含む、さまざまな実装アーティファクトの結果であると考えています。
We recommend that all TCP implementations have a settable TCP IW parameter, as long as there is a reasonable effort to monitor for possible interactions with other Internet applications and services as described in Section 12. Furthermore, Section 10 details why 10 segments may be an appropriate value, and while that value may continue to rise in the future, this document does not include any supporting evidence for values of IW larger than 10.
セクション12で説明されているように、他のインターネットアプリケーションおよびサービスとの相互作用の可能性を監視する合理的な努力がある限り、すべてのTCP実装に設定可能なTCP IWパラメータを設定することをお勧めします。さらに、セクション10は、10セグメントが適切である理由を詳しく説明しています値、およびその値は今後も上昇し続ける可能性がありますが、このドキュメントには、10より大きいIWの値を裏付ける証拠は含まれていません。
In addition, we introduce a minor revision to RFC 3390 and RFC 5681 [RFC5681] to eliminate resetting the initial window when the SYN or SYN/ACK is lost.
さらに、RFC 3390およびRFC 5681 [RFC5681]にマイナーリビジョンを導入し、SYNまたはSYN / ACKが失われた場合の初期ウィンドウのリセットを排除しました。
The document closes with a discussion of the consensus from the TCPM working group on the near-term usage and deployment of IW10 in the Internet.
この文書は、インターネットでのIW10の短期的な使用と展開に関するTCPMワーキンググループの合意についての議論で締めくくられています。
A complementary set of slides for this proposal can be found at [CD10].
この提案の補足的なスライドのセットは、[CD10]にあります。
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」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
This document proposes an increase in the permitted upper bound for TCP's initial window (IW) to 10 segments, depending on the maximum segment size (MSS). This increase is optional: a TCP MAY start with an initial window that is smaller than 10 segments.
このドキュメントでは、最大セグメントサイズ（MSS）に応じて、TCPの初期ウィンドウ（IW）の許容上限を10セグメントに増やすことを提案しています。この増加はオプションです。TCPは、10セグメントより小さい初期ウィンドウで開始する場合があります。
More precisely, the upper bound for the initial window will be
より正確には、初期ウィンドウの上限は
min (10*MSS, max (2*MSS, 14600)) (1)
最小（10 * MSS、最大（2 * MSS、14600））（1）
This upper bound for the initial window size represents a change from RFC 3390 [RFC3390], which specified that the congestion window be initialized between 2 and 4 segments, depending on the MSS.
初期ウィンドウサイズのこの上限は、MSSに応じて輻輳ウィンドウを2セグメントと4セグメントの間で初期化することを指定したRFC 3390 [RFC3390]からの変更を表しています。
This change applies to the initial window of the connection in the first round-trip time (RTT) of data transmission during or following the TCP three-way handshake. Neither the SYN/ACK nor its ACK in the three-way handshake should increase the initial window size.
この変更は、TCP 3ウェイハンドシェイク中またはその後のデータ送信の最初のラウンドトリップ時間（RTT）における接続の初期ウィンドウに適用されます。 3ウェイハンドシェイクでのSYN / ACKもそのACKも、初期ウィンドウサイズを増加させるべきではありません。
Note that all the test results described in this document were based on the regular Ethernet MTU of 1500 bytes. Future study of the effect of a different MTU may be needed to fully validate (1) above.
このドキュメントに記載されているすべてのテスト結果は、1500バイトの通常のイーサネットMTUに基づいていることに注意してください。上記（1）を完全に検証するには、別のMTUの影響を将来調査する必要があるかもしれません。
Furthermore, RFC 3390 states (and RFC 5681 [RFC5681] has similar text):
さらに、RFC 3390には次のように記載されています（RFC 5681 [RFC5681]にも同様のテキストがあります）。
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.
SYNまたはSYN / ACKが失われた場合、正しく送信されたSYNの後に送信者が使用する初期ウィンドウは、MSSバイトで構成される1つのセグメントでなければなりません。
The proposed change to reduce the default retransmission timeout (RTO) to 1 second [RFC6298] increases the chance for spurious SYN or SYN/ACK retransmission, thus unnecessarily penalizing connections with RTT > 1 second if their initial window is reduced to 1 segment. For this reason, it is RECOMMENDED that implementations refrain from resetting the initial window to 1 segment, unless there have been more than one SYN or SYN/ACK retransmissions or true loss detection has been made.
デフォルトの再送信タイムアウト（RTO）を1秒に削減するために提案された変更[RFC6298]は、偽のSYNまたはSYN / ACK再送信の可能性を高め、そのため、初期ウィンドウが1セグメントに削減されると、RTT> 1秒の接続に不必要にペナルティを課します。このため、複数のSYNまたはSYN / ACKの再送信が行われていないか、真の損失検出が行われていない限り、実装は初期ウィンドウを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 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 permit the lowest possible window size in the case of severe congestion).
TCP実装は、3つの異なる方法でスロースタートを使用します。（1）新しい接続を開始する（初期ウィンドウ）。 （2）長いアイドル期間の後に送信を再開する（再開ウィンドウ）。 （3）再送信タイムアウト（損失ウィンドウ）の後で送信を再開する。このドキュメントで指定されている変更は、初期ウィンドウの値に影響します。オプションで、TCPは再起動ウィンドウを初期ウィンドウに使用される値と現在のcwndの値の最小値に設定できます（つまり、再起動ウィンドウに大きな値を使用しても、cwndのサイズが大きくなることはありません）。これらの変更は、MSSバイトの1セグメントのままでなければならない損失ウィンドウを変更しません（深刻な輻輳の場合に可能な限り最小のウィンドウサイズを許可するため）。
Furthermore, to limit any negative effect that a larger initial window may have on links with limited bandwidth or buffer space, implementations SHOULD fall back to RFC 3390 for the restart window (RW) if any packet loss is detected during either the initial window or a restart window, and more than 4 KB of data is sent. Implementations must also follow RFC 6298 [RFC6298] in order to avoid spurious RTO as described in Section 9.
さらに、より大きな初期ウィンドウが限られた帯域幅またはバッファスペースのリンクに与える可能性のある悪影響を制限するために、初期ウィンドウまたはパケットの間にパケット損失が検出された場合、実装は再起動ウィンドウ（RW）のRFC 3390にフォールバックする必要があります（SHOULD）。ウィンドウを再起動すると、4 KBを超えるデータが送信されます。実装はまた、セクション9で説明されているような偽のRTOを回避するために、RFC 6298 [RFC6298]に従う必要があります。
The HTTP 1.1 specification allows only two simultaneous connections per domain, while web browsers open more simultaneous TCP connections [Ste08], partly to circumvent the small initial window in order to speed up the loading of web pages as described above.
HTTP 1.1仕様では、ドメインごとに2つの同時接続のみが許可されますが、Webブラウザーはより多くの同時TCP接続[Ste08]を開きます。これは、上記のようにWebページのロードを高速化するために小さな初期ウィンドウを部分的に回避するためです。
When web browsers open simultaneous TCP connections to the same destination, they are working against TCP's congestion control mechanisms [FF99]. Combining this behavior with larger initial windows further increases the burstiness and unfairness to other traffic in the network. If a larger initial window causes harm to any other flows, then local application tuning will reveal that having fewer concurrent connections yields better performance for some users. Any content provider deploying IW10 in conjunction with content distributed across multiple domains is explicitly encouraged to perform measurement experiments to detect such problems, and to consider reducing the number of concurrent connections used to retrieve their content.
Webブラウザーが同じ宛先への同時TCP接続を開くとき、それらはTCPの輻輳制御メカニズム[FF99]に反対しています。この動作と大きな初期ウィンドウを組み合わせると、ネットワーク内の他のトラフィックのバースト性と不公平さがさらに増大します。大きい初期ウィンドウが他のフローに悪影響を与える場合、ローカルアプリケーションのチューニングにより、同時接続数が少ないほど、一部のユーザーのパフォーマンスが向上することがわかります。複数のドメインに分散されたコンテンツと組み合わせてIW10を展開するコンテンツプロバイダーは、そのような問題を検出するために測定実験を実行し、コンテンツの取得に使用される同時接続の数を減らすことを検討することを明示的に推奨します。
Some implementations advertise a small initial receive window (Table 2 in [Duk10]), effectively limiting how much window a remote host may use. In order to realize the full benefit of the large initial window, implementations are encouraged to advertise an initial receive window of at least 10 segments, except for the circumstances where a larger initial window is deemed harmful. (See Section 8 below.) The TCP Selective Acknowledgment (SACK) option [RFC2018] was thought to be required in order for the larger initial window to perform well. But measurements from both a testbed and live tests showed that IW=10 without the SACK option outperforms IW=3 with the SACK option [CW10].
一部の実装は、小さな初期受信ウィンドウ（[Duk10]の表2）を通知し、リモートホストが使用できるウィンドウの量を効果的に制限します。大きな初期ウィンドウのメリットを最大限に引き出すために、実装では、大きな初期ウィンドウが有害であると見なされる状況を除いて、少なくとも10セグメントの初期受信ウィンドウをアドバタイズすることが推奨されます。 （以下のセクション8を参照してください。）TCPの選択的確認応答（SACK）オプション[RFC2018]は、より大きな初期ウィンドウを適切に実行するために必要であると考えられていました。しかし、テストベッドとライブテストの両方からの測定により、SACKオプションなしのIW = 10は、SACKオプション付きのIW = 3よりも優れていることがわかりました[CW10]。
The TCP congestion window was introduced as part of the congestion control algorithm by Van Jacobson in 1988 [Jac88]. The initial value of one segment was used as the starting point for newly established connections to probe the available bandwidth on the network.
TCP輻輳ウィンドウは、1988年にVan Jacobsonによって輻輳制御アルゴリズムの一部として導入されました[Jac88]。 1つのセグメントの初期値は、ネットワークで使用可能な帯域幅をプローブするために新しく確立された接続の開始点として使用されました。
Today's Internet is dominated by web traffic running on top of short-lived TCP connections [IOR2009]. The relatively small initial window has become a limiting factor for the performance of many web applications.
今日のインターネットは、存続期間の短いTCP接続上で実行されるWebトラフィックによって支配されています[IOR2009]。比較的小さな初期ウィンドウが、多くのWebアプリケーションのパフォーマンスを制限する要因になっています。
The global Internet has continued to grow, both in speed and penetration. According to the latest report from Akamai [AKAM10], the global broadband (> 2 Mbps) adoption has surpassed 50%, propelling the average connection speed to reach 1.7 Mbps, while the narrowband (< 256 Kbps) usage has dropped to 5%. In contrast, TCP's initial window has remained 4 KB for a decade [RFC2414], corresponding to a bandwidth utilization of less than 200 Kbps per connection, assuming an RTT of 200 ms.
グローバルなインターネットは、速度と浸透の両方で成長を続けています。アカマイの最新レポート[AKAM10]によると、グローバルブロードバンド（> 2 Mbps）の採用は50％を超え、平均接続速度は1.7 Mbpsに達し、ナローバンド（<256 Kbps）の使用率は5％に低下しています。対照的に、TCPの初期ウィンドウは10年間4 KBのままで[RFC2414]、RTTを200ミリ秒とすると、接続あたりの帯域幅使用率は200 Kbps未満に相当します。
A large proportion of flows on the Internet are short web
transactions over TCP and complete before exiting TCP slow start.
Speeding up the TCP flow startup phase, including circumventing the
initial window limit, has been an area of active research (see
[Sch08] and Section 3.4 of [RFC6077]). Numerous proposals exist
[LAJW07] [RFC4782] [PRAKS02] [PK98]. Some require router support
[RFC4782] [PK98], hence are not practical for the public Internet.
Others suggested bold, but often radical ideas, likely requiring more
years of research before standardization and deployment.
In the mean time, applications have responded to TCP's "slow" start. Web sites use multiple subdomains [Bel10] to circumvent HTTP 1.1 regulation on two connections per physical host [RFC2616]. As of today, major web browsers open multiple connections to the same site (up to six connections per domain [Ste08] and the number is growing). This trend is to remedy HTTP serialized download to achieve parallelism and higher performance. But it also implies that today most access links are severely under-utilized, hence having multiple TCP connections improves performance most of the time. While raising the initial congestion window may cause congestion for certain users of these browsers, we argue that the browsers and other application need to respect HTTP 1.1 regulation and stop increasing the number of simultaneous TCP connections. We believe a modest increase of the initial window will help to stop this trend and provide the best interim solution to improve overall user performance and reduce the server, client, and network load.
その間、アプリケーションはTCPの「遅い」開始に応答しました。 Webサイトは複数のサブドメイン[Bel10]を使用して、物理ホストごとに2つの接続でのHTTP 1.1規制を回避します[RFC2616]。現在、主要なWebブラウザーは、同じサイトへの複数の接続を開いています（ドメインあたり最大6つの接続[Ste08]で、数は増え続けています）。この傾向は、HTTPのシリアル化されたダウンロードを改善して、並列処理と高いパフォーマンスを実現することです。ただし、今日のほとんどのアクセスリンクは十分に活用されていないため、複数のTCP接続を使用すると、ほとんどの場合パフォーマンスが向上します。初期の輻輳ウィンドウを上げると、これらのブラウザの特定のユーザーに輻輳が発生する可能性がありますが、ブラウザやその他のアプリケーションはHTTP 1.1の規制を遵守し、同時TCP接続の数を増やすのをやめる必要があると主張しています。初期ウィンドウの適度な増加は、この傾向を止め、全体的なユーザーパフォーマンスを向上させ、サーバー、クライアント、およびネットワークの負荷を軽減するための最良の暫定ソリューションを提供するのに役立つと考えています。
Note that persistent connections and pipelining are designed to address some of the above issues with HTTP [RFC2616]. Their presence does not diminish the need for a larger initial window, e.g., data from the Chrome browser shows that 35% of HTTP requests are made on new TCP connections. Our test data also shows significant latency reduction with the large initial window even in conjunction with these two HTTP features [Duk10].
永続的な接続とパイプラインは、HTTP [RFC2616]に関する上記の問題のいくつかに対処するように設計されていることに注意してください。それらの存在は、より大きな初期ウィンドウの必要性を減少させません。たとえば、Chromeブラウザーからのデータは、HTTPリクエストの35％が新しいTCP接続で行われることを示しています。私たちのテストデータは、これら2つのHTTP機能[Duk10]と組み合わせた場合でも、大きな初期ウィンドウで大幅な遅延の削減を示しています。
Also note that packet pacing has been suggested as a possible mechanism to avoid large bursts and their associated harm [VH97]. Pacing is not required in this proposal due to a strong preference for a simple solution. We suspect for packet bursts of a moderate size, packet pacing will not be necessary. This seems to be confirmed by our test results.
また、パケットペーシングは、大きなバーストとそれに関連する害を回避するための可能なメカニズムとして提案されていることにも注意してください[VH97]。シンプルなソリューションを強く好むため、この提案ではペーシングは必要ありません。中程度のサイズのパケットバーストが発生する可能性があるため、パケットペーシングは必要ありません。これは当社のテスト結果で確認されているようです。
More discussion of the increase in initial window, including the choice of 10 segments, can be found in [Duk10] and [CD10].
[Duk10]と[CD10]には、10セグメントの選択を含む、初期ウィンドウの増加に関する詳細な説明があります。
An increase of the initial window from 3 segments to 10 segments reduces the total transfer time for data sets greater than 4 KB by up to 4 round trips.
初期ウィンドウが3セグメントから10セグメントに増加すると、4 KBを超えるデータセットの合計転送時間が、最大4回のラウンドトリップで短縮されます。
The table below compares the number of round trips between IW=3 and IW=10 for different transfer sizes, assuming infinite bandwidth, no packet loss, and the standard delayed ACKs with large delayed-ACK timer.
以下の表は、無限の帯域幅、パケット損失がないこと、および大きな遅延ACKタイマーを備えた標準の遅延ACKを想定して、さまざまな転送サイズに対するIW = 3とIW = 10の間の往復回数を比較しています。
---------------------------------------
| total segments | IW=3 | IW=10 |
---------------------------------------
| 3 | 1 | 1 |
| 6 | 2 | 1 |
| 10 | 3 | 1 |
| 12 | 3 | 2 |
| 21 | 4 | 2 |
| 25 | 5 | 2 |
| 33 | 5 | 3 |
| 46 | 6 | 3 |
| 51 | 6 | 4 |
| 78 | 7 | 4 |
| 79 | 8 | 4 |
| 120 | 8 | 5 |
| 127 | 9 | 5 |
---------------------------------------
For example, with the larger initial window, a transfer of 32 segments of data will require only 2 rather than 5 round trips to complete.
たとえば、初期ウィンドウが大きい場合、32セグメントのデータの転送は、5回ではなく2回のラウンドトリップで完了します。
RFC 3390 stated that the main motivation for increasing the initial window to 4 KB was to speed up connections that only transmit a small amount of data, e.g., email and web. The majority of transfers back then were less than 4 KB and could be completed in a single RTT [All00].
RFC 3390によると、初期ウィンドウを4 KBに増やす主な動機は、電子メールやWebなどの少量のデータのみを送信する接続を高速化することでした。それまでの転送の大部分は4 KB未満であり、単一のRTT [All00]で完了することができました。
Since RFC 3390 was published, web objects have gotten significantly larger [Chu09] [RJ10]. Today only a small percentage of web objects (e.g., 10% of Google's search responses) can fit in the 4 KB initial window. The average HTTP response size of gmail.com, a highly scripted web site, is 8 KB (Figure 1 in [Duk10]). The average web page, including all static and dynamic scripted web objects on the page, has seen even greater growth in size [RJ10]. HTTP pipelining [RFC2616] and new web transport protocols such as SPDY [SPDY] allow multiple web objects to be sent in a single transaction, potentially benefiting from an even larger initial window in order to transfer an entire web page in a small number of round trips.
RFC 3390が公開されて以来、Webオブジェクトは大幅に大きくなっています[Chu09] [RJ10]。現在、4 KBの初期ウィンドウに収まるのは、ごく一部のWebオブジェクト（Googleの検索応答の10％など）のみです。高度にスクリプト化されたWebサイトであるgmail.comの平均HTTP応答サイズは8 KBです（[Duk10]の図1）。ページ上のすべての静的および動的スクリプトWebオブジェクトを含む平均的なWebページでは、サイズがさらに大きくなっています[RJ10]。 HTTPパイプライン処理[RFC2616]およびSPDY [SPDY]などの新しいWebトランスポートプロトコルにより、単一のトランザクションで複数のWebオブジェクトを送信でき、Webページ全体を少数のラウンドで転送するために、さらに大きな初期ウィンドウから利益を得る可能性があります。旅行。
A greater-than-3-segment initial window increases the chance to recover packet loss through Fast Retransmit rather than the lengthy initial RTO [RFC5681]. This is because the fast retransmit algorithm requires three duplicate ACKs as an indication that a segment has been lost rather than reordered. While newer loss recovery techniques such as Limited Transmit [RFC3042] and Early Retransmit [RFC5827] have been proposed to help speeding up loss recovery from a smaller window, both algorithms can still benefit from the larger initial window because of a better chance to receive more ACKs.
3セグメントより大きい初期ウィンドウは、長い初期RTO [RFC5681]ではなく、高速再送信によるパケット損失を回復する機会を増やします。これは、高速再送信アルゴリズムでは、セグメントが並べ替えられたのではなく失われたことを示すために、3つの重複ACKが必要になるためです。リミテッドトランスミット[RFC3042]やアーリーリトランスミット[RFC5827]などの新しいロスリカバリーテクニックは、小さなウィンドウからのロスリカバリーをスピードアップするのを助けるために提案されましたが、両方のアルゴリズムは、より多くのチャンスを得るより良い初期ウィンドウから利益を得ることができます。 ACK。
6. Disadvantages of Larger Initial Windows for the Individual Connection
6. 個々の接続のための大きな初期ウィンドウの短所
The larger bursts from an increase in the initial window may cause buffer overrun and packet drop in routers with small buffers, or routers experiencing congestion. This could result in unnecessary retransmit timeouts. 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.
初期ウィンドウの増加によりバーストが大きくなると、小さいバッファーを備えたルーター、またはルーターで輻輳が発生しているルーターで、バッファーオーバーランとパケットドロップが発生することがあります。これにより、不必要な再送信タイムアウトが発生する可能性があります。再送信タイムアウトなしで回復できる大きなウィンドウの接続では、スロースタートからウィンドウ増加アルゴリズムの輻輳回避フェーズに不必要に早い移行が発生する可能性があります。
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] [RFC3150]).
十分なバッファリングがある輻輳していないネットワーク、または輻輳しているルーターがアクティブなキュー管理を使用する中程度に輻輳しているネットワーク（ランダム早期検出[FJ93] [RFC2309] [RFC3150]など）では、時期尚早のセグメントドロップは発生しません。
Insufficient buffering is more likely to exist in the access routers connecting slower links. A recent study of access router buffer size [DGHS07] reveals the majority of access routers provision enough buffer for 130 ms or longer, sufficient to cover a burst of more than 10 packets at 1 Mbps speed, but possibly not sufficient for browsers opening simultaneous connections.
遅いリンクに接続しているアクセスルータでは、バッファリングが不十分である可能性が高くなります。アクセスルーターのバッファーサイズ[DGHS07]に関する最近の調査によると、アクセスルーターの大多数は130ミリ秒以上の十分なバッファーを提供し、1 Mbpsの速度で10パケットを超えるバーストをカバーするには十分ですが、ブラウザーが同時接続を開くには十分でない可能性があります。
A testbed study [CW10] on the effect of the larger initial window with five simultaneously opened connections revealed that, even with limited buffer size on slow links, IW=10 still reduced the total latency of web transactions, although at the cost of higher packet drop rates as compared to IW=3.
5つの同時接続が開かれた、より大きな初期ウィンドウの影響に関するテストベッド調査[CW10]により、低速リンクのバッファーサイズが制限されている場合でも、IW = 10は、より高いパケットを犠牲にしても、Webトランザクションの総遅延を削減することが明らかになりましたIW = 3と比較した場合のドロップ率。
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.
一部のTCP接続では、初期ウィンドウのバースト性が原因で早期セグメントがドロップした場合でも、初期ウィンドウが大きいほどパフォーマンスが向上します。これは、（1）TCP接続が再送タイムアウトなしでセグメントのドロップから回復し、（2）TCP接続が最終的に、ネットワークの輻輳または受信側のアドバタイズされたウィンドウのいずれかによって小さな輻輳ウィンドウに制限されている場合に当てはまります。
An increase in the initial window may increase congestion in a network. However, since the increase is one time only (at the beginning of a connection), and the rest of TCP's congestion backoff mechanism remains in place, it's unlikely the increase by itself will render a network in a persistent state of congestion, or even congestion collapse. This seems to have been confirmed by the large-scale web experiments described later.
初期ウィンドウが増加すると、ネットワークの輻輳が増加する可能性があります。ただし、増加は1回だけ（接続の開始時）であり、TCPの残りの輻輳バックオフメカニズムはそのままであるので、それだけでは、ネットワークが持続的な輻輳状態になり、さらには輻輳になることはほとんどありません。崩壊。これは、後述する大規模なウェブ実験によって確認されたようです。
It should be noted that the above may not hold if applications open a large number of simultaneous connections.
アプリケーションが多数の同時接続を開いた場合、上記が成立しない場合があることに注意してください。
Until this proposal is widely deployed, a fairness issue may exist between flows adopting a larger initial window vs. flows that are compliant with RFC 3390. Although no severe unfairness has been detected on all the known tests so far, further study on this topic may be warranted.
この提案が広く展開されるまでは、RFC 3390に準拠するフローとより大きい初期ウィンドウを採用するフローとの間に公平性の問題が存在する可能性があります。これまでのところ、すべての既知のテストで重大な不公平が検出されていませんが、このトピックに関するさらなる調査は保証される。
Some of the discussions from RFC 3390 are still valid for IW=10.
RFC 3390の一部の議論は、IW = 10でも有効です。
Moreover, it is worth noting that although TCP NewReno increases the chance of duplicate segments when trying to recover multiple packet losses from a large window, the wide support of the TCP Selective Acknowledgment (SACK) option [RFC2018] in all major OSes today should keep the volume of duplicate segments in check.
さらに、TCP NewRenoは大きなウィンドウから複数のパケット損失を回復しようとするときに重複セグメントの可能性を高めますが、今日のすべての主要なOSでのTCP選択的確認応答（SACK）オプション[RFC2018]の幅広いサポートにより、チェック中の重複セグメントの量。
Recent measurements [Get11] provide evidence of extremely large queues (in the order of one second or more) at access networks of the Internet. While a significant part of the buffer bloat is contributed by large downloads/uploads such as video files, emails with large attachments, backups and download of movies to disk, some of the problem is also caused by web browsing of image-heavy sites [Get11]. This queuing delay is generally considered harmful for responsiveness of latency-sensitive traffic such as DNS queries, Address Resolution Protocol (ARP), DHCP, Voice over IP (VoIP), and gaming. IW=10 can exacerbate this problem when doing short downloads, such as web browsing [Get11-1]. The mitigations proposed for the broader problem of buffer bloating are also applicable in this case, such as the use of Explicit Congestion Notification (ECN), Active Queue Management (AQM) schemes [CoDel], and traffic classification (QoS).
最近の測定[Get11]は、インターネットのアクセスネットワークで非常に大きなキュー（1秒以上のオーダー）の証拠を提供します。バッファブロートの大部分は、ビデオファイル、大きな添付ファイルを含む電子メール、バックアップ、および映画のディスクへのダウンロードなどの大量のダウンロード/アップロードによって提供されますが、一部の問題は、画像の多いサイトのWebブラウジングによっても発生します[Get11 ]。このキューイングの遅延は、DNSクエリ、アドレス解決プロトコル（ARP）、DHCP、Voice over IP（VoIP）、ゲームなどの遅延の影響を受けやすいトラフィックの応答性に対して有害であると一般的に考えられています。 IW = 10は、Webブラウジング[Get11-1]などの短いダウンロードを行うときにこの問題を悪化させる可能性があります。バッファ膨満のより広い問題に対して提案された緩和策は、明示的輻輳通知（ECN）、アクティブキュー管理（AQM）スキーム[CoDel]、およびトラフィック分類（QoS）の使用など、この場合にも適用できます。
Much of the negative impact from an increase in the initial window is likely to be felt by users behind slow links with limited buffers. The negative impact can be mitigated by hosts directly connected to a low-speed link advertising an initial receive window smaller than 10 segments. This can be achieved either through manual configuration by the users or through the host stack auto-detecting the low-bandwidth links.
初期ウィンドウの増加による悪影響の多くは、バッファーが制限された低速リンクの背後にいるユーザーが感じる可能性があります。マイナスの影響は、10セグメント未満の初期受信ウィンドウをアドバタイズする低速リンクに直接接続されているホストによって軽減できます。これは、ユーザーが手動で構成するか、ホストスタックが低帯域幅リンクを自動検出することで実現できます。
Additional suggestions to improve the end-to-end performance of slow links can be found in RFC 3150 [RFC3150].
低速リンクのエンドツーエンドのパフォーマンスを改善するための追加の提案は、RFC 3150 [RFC3150]にあります。
A large initial window increases the chance of spurious RTO on a low-bandwidth path, because the packet transmission time will dominate the round-trip time. To minimize spurious retransmissions, implementations MUST follow RFC 6298 [RFC6298] to restart the retransmission timer with the current value of RTO for each ACK received that acknowledges new data.
パケットの送信時間がラウンドトリップ時間を支配するため、初期ウィンドウが大きいと、低帯域幅パスで偽のRTOが発生する可能性が高くなります。偽の再送信を最小限に抑えるために、実装はRFC 6298 [RFC6298]に従い、新しいデータを確認する各ACKのRTOの現在の値で再送信タイマーを再起動する必要があります。
For a more detailed discussion, see RFC 3390, Section 6.
詳細については、RFC 3390のセクション6をご覧ください。
In this section, we summarize our findings from large-scale Internet experiments with an initial window of 10 segments conducted via Google's front-end infrastructure serving a diverse set of applications. We present results from two data centers, each chosen because of the specific characteristics of subnets served: AvgDC has connection bandwidths closer to the worldwide average reported in [AKAM10], with a median connection speed of about 1.7 Mbps; SlowDC has a larger proportion of traffic from slow-bandwidth subnets with nearly 20% of traffic from connections below 100 Kbps; and a third was below 256 Kbps.
このセクションでは、大規模なインターネット実験から得られた調査結果を要約し、さまざまなアプリケーションセットにサービスを提供するGoogleのフロントエンドインフラストラクチャを介して実施された10セグメントの初期ウィンドウについて説明します。 2つのデータセンターの結果を示します。それぞれがサービス対象のサブネットの特定の特性のために選択されました。AvgDCの接続帯域幅は[AKAM10]で報告された世界平均に近く、中央接続速度は約1.7 Mbpsです。 SlowDCは低速帯域幅サブネットからのトラフィックの割合が高く、100 Kbps未満の接続からのトラフィックのほぼ20％を占めます。 3分の1は256 Kbps未満でした。
Guided by measurements data, we answer two key questions: what is the latency benefit when TCP connections start with a higher initial window, and on the flip side, what is the cost?
測定データに基づいて、2つの重要な質問に答えます。TCP接続がより高い初期ウィンドウで開始する場合のレイテンシの利点は何ですか。反対に、コストはどれくらいですか。
The average web search latency improvement over all responses in AvgDC is 11.7% (68 ms) and 8.7% (72 ms) in SlowDC. We further analyzed the data based on traffic characteristics and subnet properties such as bandwidth (BW), round-trip time (RTT), and bandwidth-delay product (BDP). The average response latency improved across the board for a variety of subnets with the largest benefits of over 20% from high RTT and high BDP networks, wherein most responses can fit within the pipe. Correspondingly, responses from low RTT paths experienced the smallest improvements -- about 5%.
AvgDCのすべての応答に対する平均Web検索遅延の改善は、SlowDCで11.7％（68ミリ秒）および8.7％（72ミリ秒）です。さらに、トラフィック特性と、帯域幅（BW）、往復時間（RTT）、帯域幅遅延積（BDP）などのサブネットプロパティに基づいてデータを分析しました。さまざまなサブネットの平均応答レイテンシが全体的に改善され、高RTTおよび高BDPネットワークからの20％以上の最大の利点が得られました。ほとんどの応答はパイプ内に収まります。これに対応して、RTTの低いパスからの応答では、わずか5％程度の改善が見られました。
Contrary to what we expected, responses from low-bandwidth subnets experienced the best latency improvements (between 10-20%) in the 0-56 Kbps and 56-256 Kbps buckets. We speculate low-BW networks observe improved latency for two plausible reasons: 1) fewer slow-start rounds: unlike many large-BW networks, low-BW subnets with dial-up modems have inherently large RTTs; and 2) faster loss recovery: an initial window larger than 3 segments increases the chances of a lost packet to be recovered through Fast Retransmit as opposed to a lengthy RTO.
予想とは逆に、低帯域幅サブネットからの応答では、0〜56 Kbpsバケットと56〜256 Kbpsバケットで最高の遅延改善（10〜20％）が見られました。 2つの考えられる理由から、低帯域幅ネットワークでは遅延の改善が見られると推測しています。1）スロースタートラウンドが少ない：多くの大帯域幅ネットワークとは異なり、ダイヤルアップモデムを備えた低帯域幅サブネットには、本質的に大きなRTTがあります。 2）損失回復の高速化：3セグメントよりも大きい初期ウィンドウでは、長いRTOではなく、高速再送信によって失われたパケットが回復される可能性が高くなります。
Responses of different sizes benefited to varying degrees; those larger than 3 segments naturally demonstrated larger improvements, because they finished in fewer rounds in slow start as compared to the baseline. In our experiments, response sizes less than or equal to 3 segments also demonstrated small latency benefits.
さまざまなサイズの応答がさまざまな程度に利益をもたらしました。 3セグメントを超えるセグメントは、ベースラインと比較してスロースタートでのラウンド数が少ないため、自然に大きな改善が見られました。私たちの実験では、応答サイズが3セグメント以下の場合にも、レイテンシのメリットが小さいことがわかりました。
To find out how individual subnets performed, we analyzed average latency at a /24 subnet level (an approximation to a user base that is offered similar set of services by a common ISP). We find that, even at the subnet granularity, latency improved at all quantiles ranging from 5-11%.
個々のサブネットのパフォーマンスを確認するために、/ 24サブネットレベルでの平均遅延を分析しました（共通のISPによって同様の一連のサービスが提供されるユーザーベースの概算）。サブネットの粒度でさえ、レイテンシは5〜11％の範囲のすべての分位点で向上したことがわかります。
To quantify the cost of raising the initial window, we analyzed the data specifically for subnets with low bandwidth and BDP, retransmission rates for different kinds of applications, as well as latency for applications operating with multiple concurrent TCP connections. From our measurements, we found no evidence of negative latency impacts that correlate to BW or BDP alone, but in fact both kinds of subnets demonstrated latency improvements across averages and quantiles.
初期ウィンドウを上げるコストを定量化するために、帯域幅とBDPが低いサブネット、特にさまざまな種類のアプリケーションの再送信率、および複数の同時TCP接続で動作するアプリケーションのレイテンシのデータを分析しました。私たちの測定から、BWまたはBDPのみに関連する負のレイテンシの影響の証拠は見つかりませんでしたが、実際には、両方の種類のサブネットが平均と変位値全体でレイテンシの改善を示しました。
As expected, the retransmission rate increased modestly when operating with larger initial congestion window. The overall increase in AvgDC is 0.3% (from 1.98% to 2.29%) and in SlowDC is 0.7% (from 3.54% to 4.21%). In our investigation, with the exception of one application, the larger window resulted in a retransmission increase of less than 0.5% for services in the AvgDC. The exception is the Maps application that operates with multiple concurrent TCP connections, which increased its retransmission rate by 0.9% in AvgDC and 1.85% in SlowDC (from 3.94% to 5.79%).
予想どおり、より大きな初期輻輳ウィンドウで動作している場合、再送信率は適度に増加しました。 AvgDCの全体的な増加は0.3％（1.98％から2.29％へ）であり、SlowDCの場合は0.7％（3.54％から4.21％へ）です。私たちの調査では、1つのアプリケーションを除いて、ウィンドウが大きいほど、AvgDCのサービスの再送信が0.5％未満増加しました。例外は、複数の同時TCP接続で動作するマップアプリケーションです。これにより、再送信率がAvgDCで0.9％、SlowDCで1.85％増加しました（3.94％から5.79％に）。
In our experiments, the percentage of traffic experiencing retransmissions did not increase significantly, e.g., 90% of web search and maps experienced zero retransmission in SlowDC (percentages are higher for AvgDC); a break up of retransmissions by percentiles indicate that most increases come from the portion of traffic already experiencing retransmissions in the baseline with initial window of 3 segments.
私たちの実験では、再送信が発生したトラフィックの割合はそれほど増加しませんでした。たとえば、Web検索とマップの90％でSlowDCの再送信が発生していません（割合はAvgDCの方が高い）。パーセンタイルによる再送信の分割は、ほとんどの増加が、最初のウィンドウが3セグメントのベースラインですでに再送信が発生しているトラフィックの部分が原因であることを示しています。
One of the worst-case scenarios where latency can be adversely impacted due to bottleneck buffer overflow is represented by traffic patterns from applications using multiple concurrent TCP connections, all operating with a large initial window. Our investigation shows that such a traffic pattern has not been a problem in AvgDC where all these applications, specifically maps and image thumbnails, demonstrated improved latencies varying from 2-20%. In the case of SlowDC, while these applications continued showing a latency improvement in the mean, their latencies in higher quantiles (96 and above for maps) indicated instances where latency with larger window is worse than the baseline, e.g., the 99% latency for maps has increased by 2.3% (80 ms) when compared to the baseline. There is no evidence from our measurements that such a cost on latency is a result of subnet bandwidth alone. Although we have no way of knowing from our data, we conjecture that the amount of buffering at bottleneck links plays a key role in the performance of these applications.
ボトルネックバッファオーバーフローが原因でレイテンシが悪影響を受ける最悪のシナリオの1つは、複数の同時TCP接続を使用するアプリケーションからのトラフィックパターンで表され、すべてが大きな初期ウィンドウで動作します。私たちの調査によると、このようなトラフィックパターンはAvgDCでは問題ではなく、これらすべてのアプリケーション、具体的にはマップと画像のサムネイルが2〜20％の範囲で改善されたレイテンシを示したことがわかります。 SlowDCの場合、これらのアプリケーションは平均でレイテンシの改善を示し続けていますが、より高い変位値（マップでは96以上）のレイテンシは、ベースラインよりもレイテンシがベースラインよりも悪い場合を示しています。マップはベースラインと比較して2.3％（80 ms）増加しました。このようなレイテンシのコストがサブネット帯域幅のみの結果であるという測定結果からの証拠はありません。データから知る方法はありませんが、ボトルネックリンクでのバッファリングの量がこれらのアプリケーションのパフォーマンスに重要な役割を果たすと推測します。
Further details on our experiments and analysis can be found in [Duk10] and [DCCM10].
実験と分析の詳細については、[Duk10]と[DCCM10]をご覧ください。
Besides the large-scale Internet experiments described above, a number of other studies have been conducted on the effects of IW10 in various environments. These tests were summarized below, with more discussion in Appendix A.
上記の大規模なインターネット実験に加えて、さまざまな環境でのIW10の影響について他の多くの研究が行われてきました。これらのテストは以下に要約されており、詳細については付録Aを参照してください。
A complete list of tests conducted, with their results and related studies, can be found at the [IW10] link.
実施されたテストとその結果および関連する研究の完全なリストは、[IW10]リンクにあります。
1. [Sch08] described an earlier evaluation of various Fast Startup approaches, including the "Initial-Start" of 10 MSS.
1. [Sch08]は、10 MSSの「Initial-Start」を含む、さまざまなFast Startupアプローチの以前の評価について説明しました。
2. [DCCM10] presented the result from Google's large-scale IW10 experiments, with a focus on areas with highly multiplexed links or limited broadband deployment such as Africa and South America.
2. [DCCM10]は、高度に多重化されたリンクまたはアフリカや南アメリカなどのブロードバンドの展開が制限されている領域に焦点を当てて、Googleの大規模なIW10実験の結果を提示しました。
3. [CW10] contained a testbed study on IW10 performance over slow links. It also studied how short flows with a larger initial window might affect the throughput performance of other coexisting, long-lived, bulk data transfers.
3. [CW10]には、低速リンクでのIW10パフォーマンスに関するテストベッド調査が含まれていました。また、初期ウィンドウが大きい短いフローが、他の共存する長寿命のバルクデータ転送のスループットパフォーマンスにどのように影響するかについても調査しました。
4. [Sch11] compared IW10 against a number of other fast startup schemes, and concluded that IW10 works rather well and is also quite fair.
4. [Sch11]は、IW10を他の多くの高速スタートアップスキームと比較し、IW10はかなりうまく機能し、かなり公平であると結論付けました。
5. [JNDK10] and later [JNDK10-1] studied the effect of IW10 over cellular networks.
5. [JNDK10]以降[JNDK10-1]は、セルラーネットワークに対するIW10の影響を調査しました。
6. [AERG11] studied the effect of larger sizes of initial congestion windows, among other things, on end users' page load time from Yahoo!'s Content Delivery Network.
6. [AERG11]は、特に、Yahoo！のコンテンツ配信ネットワークからのエンドユーザーのページ読み込み時間に対する、より大きなサイズの初期輻輳ウィンドウの影響を調査しました。
Further experiments are required before a larger initial window shall be enabled by default in the Internet. The existing measurement results indicate that this does not cause significant harm to other traffic. However, widespread use in the Internet could reveal issues not known yet, e.g., regarding fairness or impact on latency-sensitive traffic such as VoIP.
インターネットでデフォルトで大きな初期ウィンドウを有効にする前に、さらに実験が必要です。既存の測定結果は、これが他のトラフィックに重大な害を及ぼすことはないことを示しています。ただし、インターネットで広く使用されると、VoIPなどの遅延の影響を受けやすいトラフィックに対する公平性や影響など、まだ知られていない問題が明らかになる可能性があります。
Therefore, special care is needed when using this experimental TCP extension, in particular on large-scale systems originating a significant amount of Internet traffic or on large numbers of individual consumer-level systems that have similar aggregate impact. Anyone (stack vendors, network administrators, etc.) turning on a larger initial window SHOULD ensure that the performance is monitored before and after that change. Key metrics to monitor are the rate of packet losses, ECN marking, and segment retransmissions during the initial burst. The sender SHOULD cache such information about connection setups using an initial window larger than allowed by RFC 3390, and new connections SHOULD fall back to the initial window allowed by RFC 3390 if there is evidence of performance issues. Further experiments are needed on the design of such a cache and corresponding heuristics.
したがって、この実験的なTCP拡張機能を使用するときは、特に大量のインターネットトラフィックを発信する大規模なシステムや、同様の集約的な影響を持つ多数の個々のコンシューマーレベルのシステムで特に注意が必要です。誰でも（スタックベンダー、ネットワーク管理者など）より大きな初期ウィンドウをオンにすることで、その変更の前後にパフォーマンスが確実に監視されるようにする必要があります（SHOULD）。監視する主要なメトリックは、初期バースト中のパケット損失率、ECNマーキング、およびセグメント再送信です。送信者は、RFC 3390で許可されているよりも大きい初期ウィンドウを使用して、接続設定に関するそのような情報をキャッシュする必要があり（SHOULD）、パフォーマンス問題の証拠がある場合、新しい接続は、RFC 3390で許可されている初期ウィンドウにフォールバックする必要があります。このようなキャッシュの設計と対応するヒューリスティックについては、さらに実験が必要です。
Other relevant metrics that may indicate a need to reduce the IW include an increased overall percentage of packet loss or segment retransmissions as well as application-level metrics such as reduced data transfer completion times or impaired media quality.
IWを削減する必要があることを示す他の関連するメトリックには、パケット損失またはセグメントの再送信の全体的な割合の増加、およびデータ転送完了時間の短縮やメディア品質の低下などのアプリケーションレベルのメトリックが含まれます。
It is important also to take into account hosts that do not implement a larger initial window. Furthermore, any deployment of IW10 should be aware that there are potential side effects to real-time traffic (such as VoIP). If users observe any significant deterioration of performance, they SHOULD fall back to an initial window as allowed by RFC 3390 for safety reasons. An increased initial window MUST NOT be turned on by default on systems without such monitoring capabilities.
より大きな初期ウィンドウを実装していないホストを考慮することも重要です。さらに、IW10の展開では、リアルタイムトラフィック（VoIPなど）に潜在的な副作用があることを認識しておく必要があります。ユーザーがパフォーマンスの大幅な低下を観察した場合、安全上の理由からRFC 3390で許可されている初期ウィンドウにフォールバックする必要があります（SHOULD）。このような監視機能のないシステムでは、初期ウィンドウの拡大をデフォルトでオンにしてはなりません（MUST NOT）。
The IETF TCPM working group is very much interested in further reports from experiments with this specification and encourages the publication of such measurement data. By now, there are no adequate studies available that either prove or do not prove the impact of IW10 to real-time traffic. Further experimentation in this direction is encouraged.
IETF TCPMワーキンググループは、この仕様での実験からのさらなるレポートに非常に関心があり、そのような測定データの公開を奨励しています。現在のところ、リアルタイムトラフィックに対するIW10の影響を証明する、または証明しない適切な調査はありません。この方向でのさらなる実験が推奨されます。
If no significant harm is reported, a follow-up document may revisit the question on whether a larger initial window can be safely used by default in all Internet hosts. Resolution of these experiments and tighter specifications of the suggestions here might be grounds for a future Standards Track document on the same topic.
重大な危害が報告されていない場合、フォローアップドキュメントは、すべてのインターネットホストでデフォルトでより大きな初期ウィンドウをデフォルトで安全に使用できるかどうかに関する質問を再検討する場合があります。これらの実験の解決とここでの提案のより厳密な仕様は、同じトピックに関する将来のスタンダードトラックドキュメントの根拠になる可能性があります。
It is recognized that if IW10 is causing harm to other traffic, that this may not be readily apparent to the software on the hosts using IW10. In some cases, a local system or network administrator may be able to detect this and to selectively disable IW10. In the general case, however, since the harm may occur on a remote network to other cross-traffic, there may be no good way at all for this to be detected or corrected. Current experience and analysis does not indicate whether this is a real issue, beyond a hypothetical one. As use of IW10 becomes more prevalent, monitoring and analysis of flows throughout the network will be needed to assess the impact across the spectrum of scenarios found on the real Internet.
IW10が他のトラフィックに害を及ぼしている場合、IW10を使用しているホスト上のソフトウェアにはこれがすぐにはわからない場合があることが認識されています。場合によっては、ローカルシステムまたはネットワーク管理者がこれを検出し、IW10を選択的に無効にすることができます。ただし、一般的なケースでは、リモートネットワークで他のクロストラフィックに害が及ぶ可能性があるため、これを検出または修正するための良い方法はまったくありません。現在の経験と分析は、これが仮想的な問題を超えて、実際の問題であるかどうかを示していません。 IW10の使用が普及するにつれて、実際のインターネットで見られるさまざまなシナリオにわたる影響を評価するために、ネットワーク全体のフローの監視と分析が必要になります。
Two other proposals [All10] [Tou12] have been published to raise TCP's initial window size over a large timescale. Both aim at reducing the uncertain impact of a larger initial window at an Internet-wide scale. Moreover, [Tou12] seeks an algorithm to automate the adjustment of IW safely over a long period.
他の2つの提案[All10] [Tou12]が公開され、TCPの初期ウィンドウサイズを大きなタイムスケールで拡大しています。どちらも、インターネット全体の規模で大きな初期ウィンドウの不確実な影響を減らすことを目的としています。さらに、[Tou12]は、長期にわたって安全にIWの調整を自動化するアルゴリズムを求めています。
Although a modest, static increase of IW to 10 may address the near-term need for better web performance, much work is needed from the TCP research community to find a long-term solution to the TCP flow startup problem.
IWが10にわずかに静的に増加することで、Webパフォーマンスを向上させるという短期的なニーズに対処できる可能性がありますが、TCPフローの起動問題の長期的な解決策を見つけるには、TCPの研究コミュニティから多くの作業が必要です。
This document discusses the initial congestion window permitted for TCP connections. Although changing this value may cause more packet loss, it is highly unlikely to lead to a persistent state of network congestion or even a congestion collapse. Hence, it does not raise any known new security issues with TCP.
このドキュメントでは、TCP接続で許可される初期の輻輳ウィンドウについて説明します。この値を変更すると、より多くのパケット損失が発生する可能性がありますが、ネットワークの輻輳状態が持続したり、輻輳が崩壊したりする可能性はほとんどありません。したがって、TCPに関する既知の新しいセキュリティ問題は発生しません。
This document suggests a simple change to TCP that will reduce the application latency over short-lived TCP connections or links with long RTTs (saving several RTTs during the initial slow-start phase) with little or no negative impact over other flows. Extensive tests have been conducted through both testbeds and large data centers with most results showing improved latency with only a small increase in the packet retransmission rate. Based on these results, we believe a modest increase of IW to 10 is the best solution for the near-term deployment, while scaling IW over the long run remains a challenge for the TCP research community.
このドキュメントは、他のフローにほとんどまたはまったく悪影響を与えずに、存続期間の短いTCP接続または長いRTTを持つリンク（最初のスロースタートフェーズ中にいくつかのRTTを節約する）でアプリケーションレイテンシを削減するTCPへの簡単な変更を提案します。テストベッドと大規模なデータセンターの両方で広範なテストが行われ、ほとんどの結果は、パケットの再送信率を少し上げるだけで遅延が改善されたことを示しています。これらの結果に基づいて、IWを10に少し増やすことが短期間の展開に最適なソリューションであると考えていますが、TCP研究コミュニティにとっては、長期にわたるIWのスケーリングは依然として課題です。
Many people at Google have helped to make the set of large-scale tests possible. We would especially like to acknowledge Amit Agarwal, Tom Herbert, Arvind Jain, and Tiziana Refice for their major contributions.
Googleの多くの人々が、一連の大規模なテストを可能にするのを助けてきました。特に、Amit Agarwal、Tom Herbert、Arvind Jain、およびTiziana Reficeの主要な貢献に謝意を表します。
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996.
[RFC2018] Mathis、M.、Madhavi、J.、Floyd、S。、およびA. Romanow、「TCP選択的確認応答オプション」、RFC 2018、1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「Hypertext Transfer Protocol-HTTP / 1.1」 、RFC 2616、1999年6月。
[RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's Initial Window", RFC 3390, October 2002.
[RFC3390]オールマン、M。、フロイド、S。、およびC.パートリッジ、「TCPの初期ウィンドウの増加」、RFC 3390、2002年10月。
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, September 2009.
[RFC5681] Allman、M.、Paxson、V。、およびE. Blanton、「TCP Congestion Control」、RFC 5681、2009年9月。
[RFC5827] Allman, M., Avrachenkov, K., Ayesta, U., Blanton, J., and P. Hurtig, "Early Retransmit for TCP and Stream Control Transmission Protocol (SCTP)", RFC 5827, May 2010.
[RFC5827] Allman、M.、Avrachenkov、K.、Ayesta、U.、Blanton、J。、およびP. Hurtig、「TCPおよびStream Control Transmission Protocol（SCTP）の早期再送信」、RFC 5827、2010年5月。
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, "Computing TCP's Retransmission Timer", RFC 6298, June 2011.
[RFC6298] Paxson、V.、Allman、M.、Chu、J。、およびM. Sargent、「Computing TCP's Retransmission Timer」、RFC 6298、2011年6月。
[AKAM10] Akamai Technologies, Inc., "The State of the Internet, 3rd Quarter 2009", January 2010, <http://www.akamai.com/html/ about/press/releases/2010/press_011310_1.html>.
[AKAM10] Akamai Technologies、Inc.、「インターネットの現状、2009年第3四半期」、2010年1月、<http://www.akamai.com/html/ about / press / releases / 2010 / press_011310_1.html>。
[AERG11] Al-Fares, M., Elmeleegy, K., Reed, B., and I. Gashinsky, "Overclocking the Yahoo! CDN for Faster Web Page Loads", Internet Measurement Conference, November 2011.
[AERG11] Al-Fares、M.、Elmeleegy、K.、Reed、B。、およびI. Gashinsky、「より高速なWebページロードのためのYahoo! CDNのオーバークロック」、インターネット測定会議、2011年11月。
[All00] Allman, M., "A Web Server's View of the Transport Layer", ACM Computer Communication Review, 30(5), October 2000.
[All00] Allman、M。、「トランスポート層のWebサーバーのビュー」、ACM Computer Communication Review、30（5）、2000年10月。
[All10] Allman, M., "Initial Congestion Window Specification", Work in Progress, November 2010.
[All10] Allman、M。、「Initial Congestion Window Specification」、Work in Progress、2010年11月。
[Bel10] Belshe, M., "A Client-Side Argument For Changing TCP Slow Start", January 2010, <http://sites.google.com/a/chromium.org/dev/spdy/ An_Argument_For_Changing_TCP_Slow_Start.pdf>.
[Bel10] Belshe、M。、「TCPスロースタートを変更するためのクライアント側の引数」、2010年1月、<http://sites.google.com/a/chromium.org/dev/spdy/ An_Argument_For_Changing_TCP_Slow_Start.pdf>。
[CD10] Chu, J. and N. Dukkipati, "Increasing TCP's Initial Window", presented to the IRTF ICCRG and IETF TCPM working group meetings, IETF 77, March 2010, <http://www.ietf.org/ proceedings/77/slides/tcpm-4.pdf>.
[CD10] Chu、J.およびN. Dukkipati、「Increeasing TCP's Initial Window」は、IRTF ICCRGおよびIETF TCPMワーキンググループミーティング、IETF 77、2010年3月、<http://www.ietf.org/procedings/に発表されました。 77 / slides / tcpm-4.pdf>。
[Chu09] Chu, J., "Tuning TCP Parameters for the 21st Century", presented to TCPM working group meeting, IETF 75, July 2009. <http://www.ietf.org/proceedings/75/slides/tcpm-1>.
[Chu09] Chu、J。、「Tuning TCP Parameters for the 21st Century」は、TCPMワーキンググループミーティング、IETF 75、2009年7月に提出されました。<http://www.ietf.org/proceedings/75/slides/tcpm- 1>。
[CoDel] Nichols, K. and V. Jacobson, "Controlling Queue Delay", ACM QUEUE, May 6, 2012.
[CoDel] Nichols、K。およびV. Jacobson、「Controlling Queue Delay」、ACM QUEUE、2012年5月6日。
[CW10] Chu, J. and Wang, Y., "A Testbed Study on IW10 vs IW3", presented to the TCPM working group meeting, IETF 79, November 2010, <http://www.ietf.org/proceedings/79/slides/tcpm-0>.
[CW10] Chu、J.とWang、Y。、「A Testbed Study on IW10 vs IW3」、TCPMワーキンググループミーティング、IETF 79、2010年11月、<http://www.ietf.org/proceedings/ 79 / slides / tcpm-0>。
[DCCM10] Dukkipati, D., Cheng, Y., Chu, J., and M. Mathis, "Increasing TCP initial window", presented to the IRTF ICCRG meeting, IETF 78, July 2010, <http://www.ietf.org/proceedings/78/slides/iccrg-3.pdf>.
[DCCM10] Dukkipati、D.、Cheng、Y.、Chu、J。、およびM. Mathisは、「TCPの初期ウィンドウの増加」をIRTF ICCRG会議、IETF 78、2010年7月、<http：// www。 ietf.org/proceedings/78/slides/iccrg-3.pdf>。
[DGHS07] Dischinger, M., Gummadi, K., Haeberlen, A., and S. Saroiu, "Characterizing Residential Broadband Networks", Internet Measurement Conference, October 24-26, 2007.
[DGHS07] Dischinger、M.、Gummadi、K.、Haeberlen、A。、およびS. Saroiu、「Characterizing Residential Broadband Networks」、インターネット測定会議、2007年10月24〜26日。
[Duk10] Dukkipati, N., Refice, T., Cheng, Y., Chu, J., Sutin, N., Agarwal, A., Herbert, T., and J. Arvind, "An Argument for Increasing TCP's Initial Congestion Window", ACM SIGCOMM Computer Communications Review, vol. 40 (2010), pp. 27-33. July 2010.
[Duk10] Dukkipati、N.、Refice、T.、Cheng、Y.、Chu、J.、Sutin、N.、Agarwal、A.、Herbert、T。、およびJ. Arvind、「TCPの初期値を増やすための引数Congestion Window」、ACM SIGCOMM Computer Communications Review、vol。 40（2010）、27-33ページ。 2010年7月。
[FF99] Floyd, S., and K. Fall, "Promoting the Use of End-to-End Congestion Control in the Internet", IEEE/ACM Transactions on Networking, August 1999.
[FF99]フロイド、S。、およびK.フォール、「インターネットにおけるエンドツーエンドの輻輳制御の使用の促進」、IEEE / ACM Transactions on Networking、1999年8月。
[FJ93] Floyd, S. and V. Jacobson, "Random Early Detection gateways for Congestion Avoidance", IEEE/ACM Transactions on Networking, V.1 N.4, August 1993, p. 397-413.
[FJ93] Floyd、S。およびV. Jacobson、「輻輳回避のためのランダム早期検出ゲートウェイ」、IEEE / ACM Transactions on Networking、V.1 N.4、1993年8月、p。 397-413。
[Get11] Gettys, J., "Bufferbloat: Dark buffers in the Internet", presented to the TSV Area meeting, IETF 80, March 2011, <http://www.ietf.org/proceedings/80/slides/tsvarea-1.pdf>.
[Get11] Gettys、J。、「Bufferbloat：Dark buffers in the Internet」、TSV Areaミーティング、IETF 80、2011年3月、<http://www.ietf.org/proceedings/80/slides/tsvarea- 1.pdf>。
[Get11-1] Gettys, J., "IW10 Considered Harmful", Work in Progress, August 2011.
[Get11-1] Gettys、J。、「IW10は有害と見なされる」、作業中、2011年8月。
[IOR2009] Labovitz, C., Iekel-Johnson, S., McPherson, D., Oberheide, J. Jahanian, F., and M. Karir, "Atlas Internet Observatory 2009 Annual Report", 47th NANOG Conference, October 2009.
[IOR2009] Labovitz、C.、Iekel-Johnson、S.、McPherson、D.、Oberheide、J。Jahanian、F。、およびM. Karir、「Atlas Internet Observatory 2009 Annual Report」、第47回NANOG会議、2009年10月。
[IW10] "TCP IW10 links", January 2012, <http://code.google.com/speed/protocols/tcpm-IW10.html>.
[IW10]「TCP IW10リンク」、2012年1月、<http://code.google.com/speed/protocols/tcpm-IW10.html>。
[Jac88] Jacobson, V., "Congestion Avoidance and Control", Computer Communication Review, vol. 18, no. 4, pp. 314-329, Aug. 1988.
[Jac88] Jacobson、V。、「輻輳回避と制御」、コンピュータ通信レビュー、vol。 18、いいえ。 4、pp。314-329、1988年8月。
[JNDK10] Jarvinen, I., Nyrhinen. A., Ding, A., and M. Kojo, "A Simulation Study on Increasing TCP's IW", presented to the IRTF ICCRG meeting, IETF 78, July 2010, <http://www.ietf.org/proceedings/78/slides/iccrg-7.pdf>.
[JNDK10]ヤルビネン、I。、ニーリネン。 A.、Ding、A。、およびM. Kojo、「TCPのIWの増加に関するシミュレーション研究」、IRTF ICCRG会議、IETF 78、2010年7月、<http://www.ietf.org/proceedings/78に発表/slides/iccrg-7.pdf>。
[JNDK10-1] Jarvinen, I., Nyrhinen. A., Ding, A., and M. Kojo, "Effect of IW and Initial RTO changes", presented to the TCPM working group meeting, IETF 79, November 2010, <http://www.ietf.org/proceedings/79/slides/tcpm-1.pdf>.
[JNDK10-1]ヤルビネン、I。、ニーリネン。 A.、Ding、A。、およびM. Kojo、「IWおよび初期RTO変更の影響」は、TCPMワーキンググループミーティング、IETF 79、2010年11月、<http://www.ietf.org/proceedings/に提出されました。 79 / slides / tcpm-1.pdf>。
[LAJW07] Liu, D., Allman, M., Jin, S., and L. Wang, "Congestion Control Without a Startup Phase", Protocols for Fast, Long Distance Networks (PFLDnet) Workshop, February 2007, <http://www.icir.org/mallman/papers/ jumpstart-pfldnet07.pdf>.
[LAJW07] Liu、D.、Allman、M.、Jin、S。、およびL. Wang、「起動フェーズなしの輻輳制御」、高速長距離ネットワーク（PFLDnet）ワークショップのプロトコル、2007年2月、<http： //www.icir.org/mallman/papers/ jumpstart-pfldnet07.pdf>。
[PK98] Padmanabhan V.N. and R. Katz, "TCP Fast Start: A technique for speeding up web transfers", in Proceedings of IEEE Globecom '98 Internet Mini-Conference, 1998.
[PK98] Padmanabhan V.N.そしてR. Katz、「TCP Fast Start：A Technicing for Speeding Web Transfers」の中で、Proceedings of IEEE Globecom '98 Internet Mini-Conference、1998。
[PRAKS02] Partridge, C., Rockwell, D., Allman, M., Krishnan, R., and J. Sterbenz, "A Swifter Start for TCP", Technical Report No. 8339, BBN Technologies, March 2002.
[PRAKS02]パートリッジ、C。、ロックウェル、D。、オールマン、M。、クリシュナン、R。、およびJ.スターベンツ、「A Swifter Start for TCP」、テクニカルレポートNo. 8339、BBN Technologies、2002年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。、エストリン、D。、フロイド、S。、ジェイコブソン、V。、ミンシャル、G。、パートリッジ、 C.、Peterson、L.、Ramakrishnan、K.、Shenker、S.、Wroclawski、J。、およびL. Zhang、「インターネットでのキュー管理と輻輳回避に関する推奨事項」、RFC 2309、1998年4月。
[RFC2414] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's Initial Window", RFC 2414, September 1998.
[RFC2414] Allman、M.、Floyd、S。、およびC. Partridge、「Increeasing TCP's Initial Window」、RFC 2414、1998年9月。
[RFC3042] Allman, M., Balakrishnan, H., and S. Floyd, "Enhancing TCP's Loss Recovery Using Limited Transmit", RFC 3042, January 2001.
[RFC3042] Allman、M.、Balakrishnan、H。、およびS. Floyd、「Enhancing TCP's Loss Recovery Using Limited Transmit」、RFC 3042、2001年1月。
[RFC3150] Dawkins, S., Montenegro, G., Kojo, M., and V. Magret, "End-to-end Performance Implications of Slow Links", BCP 48, RFC 3150, July 2001.
[RFC3150] Dawkins、S。、モンテネグロ、G.、Kojo、M。、およびV. Magret、「エンドツーエンドのパフォーマンス低下と低速リンク」、BCP 48、RFC 3150、2001年7月。
[RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick-Start for TCP and IP", RFC 4782, January 2007.
[RFC4782] Floyd、S.、Allman、M.、Jain、A。、およびP. Sarolahti、「Quick-Start for TCP and IP」、RFC 4782、2007年1月。
[RFC6077] Papadimitriou, D., Ed., Welzl, M., Scharf, M., and B. Briscoe, "Open Research Issues in Internet Congestion Control", RFC 6077, February 2011.
[RFC6077] Papadimitriou、D.、Ed。、Welzl、M.、Scharf、M.、and B. Briscoe、 "Open Research Issues in Internet Congestion Control"、RFC 6077、February 2011。
[RJ10] Ramachandran, S. and A. Jain, "Aggregate Statistics of Size Related Metrics of Web Pages metrics", May 2010, <http://code.google.com/speed/articles/web-metrics.html>.
[RJ10] Ramachandran、S。およびA. Jain、「Webページメトリックのサイズ関連メトリックの集約統計」、2010年5月、<http://code.google.com/speed/articles/web-metrics.html>。
[Sch08] Scharf, M., "Quick-Start, Jump-Start, and Other Fast Startup Approaches", presented to the IRTF ICCRG meeting, IETF 73, November 2008, <http://www.ietf.org/proceedings/73/slides/iccrg-2.pdf>.
[Sch08] Scharf、M。、「Quick-Start、Jump-Start、およびその他の高速起動アプローチ」は、IRTF ICCRG会議、IETF 73、2008年11月、<http://www.ietf.org/proceedings/に提出されました。 73 / slides / iccrg-2.pdf>。
[Sch11] Scharf, M., "Performance and Fairness Evaluation of IW10 and Other Fast Startup Schemes", presented to the IRTF ICCRG meeting, IETF 80, March 2011, <http://www.ietf.org/proceedings/80/slides/iccrg-1.pdf>.
[Sch11] Scharf、M。、「IW10とその他の高速スタートアップスキームのパフォーマンスと公平性の評価」、IRTF ICCRG会議、IETF 80、2011年3月、<http://www.ietf.org/proceedings/80/ slides / iccrg-1.pdf>。
[Sch11-1] Scharf, M., "Comparison of end-to-end and network-supported fast startup congestion control schemes", Computer Networks, Feb. 2011, <http://dx.doi.org/10.1016/j.comnet.2011.02.002>.
[Sch11-1] Scharf、M。、「エンドツーエンドおよびネットワークサポートの高速起動輻輳制御方式の比較」、コンピュータネットワーク、2011年2月、<http://dx.doi.org/10.1016/j .comnet.2011.02.002>。
[SPDY] "SPDY: An experimental protocol for a faster web", <http://dev.chromium.org/spdy>.
[SPDY]「SPDY：より高速なWebのための実験的なプロトコル」、<http://dev.chromium.org/spdy>。
[Ste08] Sounders S., "Roundup on Parallel Connections", High Performance Web Sites blog, March 2008, <http://www.stevesouders.com/blog/2008/03/20/ roundup-on-parallel-connections>.
[Ste08] Sounders S。、「Roundup on Parallel Connections」、高性能Webサイトのブログ、2008年3月、<http://www.stevesouders.com/blog/2008/03/20/ roundup-on-parallel-connections> 。
[Tou12] Touch, J., "Automating the Initial Window in TCP", Work in Progress, July 2012.
[Tou12] Touch、J。、「TCPの初期ウィンドウの自動化」、作業中、2012年7月。
[VH97] Visweswaraiah, V. and J. Heidemann, "Improving Restart of Idle TCP Connections", Technical Report 97-661, University of Southern California, November 1997.
[VH97] Visweswaraiah、V。およびJ. Heidemann、「Improving Restart of Restart of Idle TCP Connections」、Technical Report 97-661、南カリフォルニア大学、1997年11月。
Concerns have been raised since the initial draft of this document was posted, based on a set of large-scale experiments. To better understand the impact of a larger initial window and in order to confirm or dismiss these concerns, additional tests have been conducted using either large-scale clusters, simulations, or real testbeds. The following attempts to compile the list of concerns and summarize findings from relevant tests.
このドキュメントの最初のドラフトが投稿されてから、一連の大規模な実験に基づいて懸念が表明されています。より大きな初期ウィンドウの影響をよりよく理解し、これらの懸念を確認または却下するために、大規模なクラスター、シミュレーション、または実際のテストベッドを使用して追加のテストが行われました。以下の試みは、懸念事項のリストをまとめ、関連するテストからの結果を要約するものです。
o How complete are various tests in covering many different traffic patterns?
o さまざまなトラフィックパターンをカバーするさまざまなテストはどの程度完了していますか？
The large-scale Internet experiments conducted at Google's front-end infrastructure covered a large portfolio of services beyond web search. It included Gmail, Google Maps, Photos, News, Sites, Images, etc., and covered a wide variety of traffic sizes and patterns. One notable exception is YouTube, because we don't think the large initial window will have much material impact, either positive or negative, on bulk data services.
Googleのフロントエンドインフラストラクチャで行われた大規模なインターネット実験は、ウェブ検索以外の幅広いサービスポートフォリオをカバーしていました。これには、Gmail、Googleマップ、写真、ニュース、サイト、画像などが含まれ、さまざまなトラフィックのサイズとパターンがカバーされていました。注目すべき例外の1つはYouTubeです。これは、大きな初期ウィンドウがバルクデータサービスにプラスまたはマイナスの大きな影響を与えるとは考えられていないためです。
[CW10] contains some results from a testbed study on how short flows with a larger initial window might affect the throughput performance of other coexisting, long-lived, bulk data transfers.
[CW10]には、初期ウィンドウが大きい短いフローが、他の共存する長寿命のバルクデータ転送のスループットパフォーマンスにどのように影響するかに関するテストベッド調査の結果が含まれています。
o Larger bursts from the increase in the initial window cause significantly more packet drops.
o 初期ウィンドウの増加によりバーストが大きくなると、パケットドロップが大幅に増加します。
All the tests conducted on this subject ([Duk10] [Sch11] [Sch11-1] [CW10]) so far have shown only a modest increase of packet drops. The only exception is from the testbed study [CW10] under extremely high load and/or simultaneous opens. But under those conditions, both IW=3 and IW=10 suffered very high packet loss rates.
この問題（[Duk10] [Sch11] [Sch11-1] [CW10]）に対してこれまでに行われたすべてのテストでは、パケットドロップの増加がわずかであることが示されています。唯一の例外は、非常に高い負荷および/または同時オープンでのテストベッド調査[CW10]からです。しかし、これらの条件下では、IW = 3とIW = 10の両方で非常に高いパケット損失率が発生しました。
o A large initial window may severely impact TCP performance over highly multiplexed links still common in developing regions.
o 大きな初期ウィンドウは、開発途上地域で依然として一般的な高度に多重化されたリンク上のTCPパフォーマンスに深刻な影響を与える可能性があります。
Our large-scale experiments described in Section 10 above also covered Africa and South America. Measurement data from those regions [DCCM10] revealed improved latency, even for those services that employ multiple simultaneous connections, at the cost of a small increase in the retransmission rate. It seems that the round-trip savings from a larger initial window more than make up the time spent on recovering more lost packets.
上記のセクション10で説明した大規模な実験では、アフリカと南アメリカも対象としていました。それらの地域の測定データ[DCCM10]は、複数の同時接続を使用するサービスであっても、再送信率がわずかに増加するという犠牲を払って、遅延が改善されていることを明らかにしました。より大きな初期ウィンドウからの往復の節約は、より多くの失われたパケットを回復するために費やされた時間を補っているようです。
Similar phenomena have also been observed from the testbed study [CW10].
同様の現象は、テストベッド調査[CW10]からも観察されています。
o Why 10 segments?
o なぜ10セグメントなのですか？
Questions have been raised on how the number 10 was picked. We have tried different sizes in our large-scale experiments, and found that 10 segments seem to give most of the benefits for the services we tested while not causing significant increase in the retransmission rates. Going forward, 10 segments may turn out to be too small when the average of web object sizes continues to grow. But a scheme to "right size" the initial window automatically over long timescales has yet to be developed.
数10がどのように選ばれたかについての質問が提起されました。大規模な実験でさまざまなサイズを試しましたが、10個のセグメントがテストしたサービスにほとんどの利点をもたらす一方で、再送信率を大幅に増加させることはないようです。今後、Webオブジェクトの平均サイズが増加し続けると、10個のセグメントが小さすぎる可能性があります。しかし、長いタイムスケールで初期ウィンドウを自動的に「適切なサイズ」にするスキームはまだ開発されていません。
o More thorough analysis of the impact on slow links is needed.
o 低速リンクへの影響をより徹底的に分析する必要があります。
Although [Duk10] showed the large initial window reduced the average latency even for the dialup link class of only 56 Kbps in bandwidth, more studies were needed in order to understand the effect of IW10 on slow links at the microscopic level. [CW10] was conducted for this purpose.
[Duk10]は、帯域幅がわずか56 Kbpsのダイヤルアップリンククラスの場合でも、大きな初期ウィンドウによって平均遅延が減少することを示しましたが、微視的レベルでの低速リンクに対するIW10の影響を理解するには、さらに調査が必要でした。 [CW10]はこの目的のために行われました。
Testbeds in [CW10] emulated a 300 ms RTT, bottleneck link bandwidth as low as 64 Kbps, and route queue size as low as 40 packets. A large combination of test parameters were used. Almost all tests showed varying degrees of latency improvement from IW=10, with only a modest increase in the packet drop rate until a very high load was injected. The testbed result was consistent with both the large-scale data center experiments [CD10] [DCCM10] and a separate study using the Network Simulation Cradle (NSC) framework [Sch11] [Sch11-1].
[CW10]のテストベッドは、300 msのRTT、ボトルネックのリンク帯域幅が64 Kbps、ルートキューのサイズが40パケットという低さをエミュレートしました。テストパラメータの大きな組み合わせが使用されました。ほとんどすべてのテストで、IW = 10からさまざまな程度のレイテンシの改善が見られ、非常に高い負荷が注入されるまで、パケットドロップ率の増加はわずかでした。テストベッドの結果は、大規模データセンターの実験[CD10] [DCCM10]と、ネットワークシミュレーションクレードル（NSC）フレームワークを使用した別の研究[Sch11] [Sch11-1]の両方と一致していました。
o How will the larger initial window affect flows with initial windows of 4 KB or less?
o より大きい初期ウィンドウは、初期ウィンドウが4 KB以下のフローにどのように影響しますか？
Flows with the larger initial window will likely grab more bandwidth from a bottleneck link when competing against flows with smaller initial windows, at least initially. How long will this "unfairness" last? Will there be any "capture effect" where flows with larger initial window possess a disproportional share of bandwidth beyond just a few round trips?
初期ウィンドウが大きいフローは、少なくとも初期ウィンドウが小さいフローと競合する場合、ボトルネックリンクからより多くの帯域幅を取得する可能性があります。この「不公平」はどのくらい続くでしょうか？大きな初期ウィンドウを持つフローが、数回のラウンドトリップを超えて帯域幅の不均衡なシェアを所有する「キャプチャ効果」はありますか？
If there is any "unfairness" issue from flows with different initial windows, it did not show up in the large-scale experiments, as the average latency for the bucket of all responses less than 4 KB did not seem to be affected by the presence of many other larger responses employing large initial window. As a matter of fact, they seemed to benefit from the large initial window too, as shown in Figure 7 of [Duk10].
初期ウィンドウが異なるフローからの「不公平」の問題がある場合、4 KB未満のすべての応答のバケットの平均レイテンシはプレゼンスの影響を受けないようだったため、大規模な実験では表示されませんでした大きな初期ウィンドウを使用する他の多くのより大きな応答の。実際のところ、[Duk10]の図7に示されているように、大きな初期ウィンドウからも利益を得ているようです。
The same phenomenon seems to exist in the testbed experiments [CW10]. Flows with IW=3 only suffered slightly when competing against flows with IW=10 in light to medium loads. Under high load, both flows' latency improved when mixed together. Also long-lived, background bulk-data flows seemed to enjoy higher throughput when running against many foreground short flows of IW=10 than against short flows of IW=3. One plausible explanation was that IW=10 enabled short flows to complete sooner, leaving more room for the long-lived, background flows.
同じ現象がテストベッド実験[CW10]にも存在するようです。 IW = 3のフローは、軽度から中程度の負荷でIW = 10のフローと競合するときにわずかに影響を受けました。高負荷下では、両方のフローを混合するとレイテンシが向上しました。また、IW = 3の短いフローに対してよりも、IW = 10の多くのフォアグラウンドの短いフローに対して実行した場合、長寿命のバックグラウンドバルクデータフローは、より高いスループットを享受するように見えました。 1つのもっともらしい説明は、IW = 10が短いフローをより早く完了することを可能にし、長命のバックグラウンドフローのためにより多くの余地を残したことでした。
A study using an NSC simulator has also concluded that IW=10 works rather well and is quite fair against IW=3 [Sch11] [Sch11-1].
NSCシミュレータを使用した調査では、IW = 10はかなりうまく機能し、IW = 3 [Sch11] [Sch11-1]に対してかなり公平であると結論付けています。
o How will a larger initial window perform over cellular networks?
o より大きな初期ウィンドウは、携帯電話ネットワークでどのように機能しますか？
Some simulation studies [JNDK10] [JNDK10-1] have been conducted to study the effect of a larger initial window on wireless links from 2G to 4G networks (EGDE/HSPA/LTE). The overall result seems mixed in both raw performance and the fairness index.
2Gから4Gネットワーク（EGDE / HSPA / LTE）へのワイヤレスリンクに対する大きな初期ウィンドウの影響を調査するために、いくつかのシミュレーション研究[JNDK10] [JNDK10-1]が行われました。全体的な結果は、生のパフォーマンスと公平性指数の両方に混在しているようです。
Authors' Addresses
著者のアドレス
Jerry Chu Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 USA
Jerry Chu Google、Inc. 1600 Amphitheatre Parkway Mountain View、CA 94043 USA
EMail: hkchu@google.com
Nandita Dukkipati Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 USA
Nandita Dukkipati Google、Inc. 1600 Amphitheatre Parkway Mountain View、CA 94043 USA
EMail: nanditad@google.com
Yuchung Cheng Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 USA
Yuchung Cheng Google、Inc. 1600 Amphitheatre Parkway Mountain View、CA 94043 USA
EMail: ycheng@google.com
Matt Mathis Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 USA
Matt Mathis Google、Inc. 1600 Amphitheatre Parkway Mountain View、CA 94043 USA
EMail: mattmathis@google.com