draft-ietf-tcpm-initcwnd-02.txt   draft-ietf-tcpm-initcwnd-03.txt 
Internet Draft J. Chu Internet Draft J. Chu
draft-ietf-tcpm-initcwnd-02.txt N. Dukkipati draft-ietf-tcpm-initcwnd-03.txt N. Dukkipati
Intended status: Standard Y. Cheng Intended status: Experimental Y. Cheng
Updates: 3390, 5681 M. Mathis Updates: 3390, 5681 M. Mathis
Creation date: October 16, 2011 Google, Inc. Expiration date: August 2012 Google, Inc.
Expiration date: April 2012 February 26, 2012
Increasing TCP's Initial Window Increasing TCP's Initial Window
Status of this Memo Status of this Memo
Distribution of this memo is unlimited. Distribution of this memo is unlimited.
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on October, 2011. This Internet-Draft will expire on August, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 14 skipping to change at page 2, line 14
Abstract Abstract
This document proposes an increase in the permitted TCP initial This document proposes an increase in the permitted TCP initial
window (IW) from between 2 and 4 segments, as specified in RFC 3390, window (IW) from between 2 and 4 segments, as specified in RFC 3390,
to 10 segments. It discusses the motivation behind the increase, the to 10 segments. It discusses the motivation behind the increase, the
advantages and disadvantages of the higher initial window, and advantages and disadvantages of the higher initial window, and
presents results from several large scale experiments showing that presents results from several large scale experiments showing that
the higher initial window improves the overall performance of many the higher initial window improves the overall performance of many
web services without risking congestion collapse. The document closes web services without risking congestion collapse. The document closes
with a discussion of a list of concerns, and some results from recent with a discussion of usage and deployment recommended by the IETF TCP
studies to address the concerns. Maintenance and Minor Extensions (TCPM) working group.
Terminology Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. TCP Modification . . . . . . . . . . . . . . . . . . . . . . . 3 2. TCP Modification . . . . . . . . . . . . . . . . . . . . . . . 4
3. Implementation Issues . . . . . . . . . . . . . . . . . . . . . 4 3. Implementation Issues . . . . . . . . . . . . . . . . . . . . . 5
4. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Advantages of Larger Initial Windows . . . . . . . . . . . . . 6 5. Advantages of Larger Initial Windows . . . . . . . . . . . . . 7
5.1 Reducing Latency . . . . . . . . . . . . . . . . . . . . . . 6 5.1 Reducing Latency . . . . . . . . . . . . . . . . . . . . . . 7
5.2 Keeping up with the growth of web object size . . . . . . . 7 5.2 Keeping up with the growth of web object size . . . . . . . 7
5.3 Recovering faster from loss on under-utilized or wireless 5.3 Recovering faster from loss on under-utilized or wireless
links . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 links . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Disadvantages of Larger Initial Windows for the Network . . . . 9 7. Disadvantages of Larger Initial Windows for the Network . . . . 9
8. Mitigation of Negative Impact . . . . . . . . . . . . . . . . . 9 8. Mitigation of Negative Impact . . . . . . . . . . . . . . . . 10
9. Interactions with the Retransmission Timer . . . . . . . . . . 9 9. Interactions with the Retransmission Timer . . . . . . . . . 10
10. Experimental Results From Large Scale Cluster Tests . . . . . 10 10. Experimental Results From Large Scale Cluster Tests . . . . . 10
10.1 The benefits . . . . . . . . . . . . . . . . . . . . . . 10 10.1 The benefits . . . . . . . . . . . . . . . . . . . . . . 10
10.2 The cost . . . . . . . . . . . . . . . . . . . . . . . . 11 10.2 The cost . . . . . . . . . . . . . . . . . . . . . . . . 11
11. List of Concerns and Corresponding Test Results . . . . . . . 12 11. Other Studies . . . . . . . . . . . . . . . . . . . . . . . . 12
12. Related Proposals . . . . . . . . . . . . . . . . . . . . . . 14 12. Usage and Deployment Recommendations . . . . . . . . . . . . 13
14. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 15 13. Related Proposals . . . . . . . . . . . . . . . . . . . . . . 13
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 14. Security Considerations . . . . . . . . . . . . . . . . . . . 14
16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 15. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 14
Normative References . . . . . . . . . . . . . . . . . . . . . . 16 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
Informative References . . . . . . . . . . . . . . . . . . . . . 16 17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Normative References . . . . . . . . . . . . . . . . . . . . . . 15
Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . . 20 Informative References . . . . . . . . . . . . . . . . . . . . . 15
Appendix A - List of Concerns and Corresponding Test Results . . 19
Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
This document updates RFC 3390 to raise the upper bound on TCP's
initial window (IW) to 10 segments or roughly 15KB. It is patterned This document proposes to update RFC 3390 to raise the upper bound on
after and borrows heavily from RFC 3390 [RFC3390] and earlier work in TCP's initial window (IW) to 10 segments or roughly 15KB. It is
this area. patterned after and borrows heavily from RFC 3390 [RFC3390] and
earlier work in this area. Due to lingering concerns about possible
side effects, some of the recommendations are conditional on
additional monitoring and evaluation.
The primary argument in favor of raising IW follows from the evolving The primary argument in favor of raising IW follows from the evolving
scale of the Internet. Ten segments are likely to fit into queue scale of the Internet. Ten segments are likely to fit into queue
space available at any broadband access link, even when there are a space available at any broadband access link, even when there are a
reasonable number of concurrent connections. reasonable number of concurrent connections.
Lower speed links can be treated with environment specific Lower speed links can be treated with environment specific
configurations, such that they can be protected from being configurations, such that they can be protected from being
overwhelmed by large initial window bursts without imposing a overwhelmed by large initial window bursts without imposing a
suboptimal initial window on the rest of the Internet. suboptimal initial window on the rest of the Internet.
skipping to change at page 3, line 30 skipping to change at page 3, line 35
larger initial window, and includes summaries of several large scale larger initial window, and includes summaries of several large scale
experiments showing that an initial window of 10 segments provides experiments showing that an initial window of 10 segments provides
benefits across the board for a variety of BW, RTT, and BDP classes. benefits across the board for a variety of BW, RTT, and BDP classes.
These results show significant benefits for increasing IW for users These results show significant benefits for increasing IW for users
at much smaller data rates than had been previously anticipated. at much smaller data rates than had been previously anticipated.
However, at initial windows larger than 10, the results are mixed. We However, at initial windows larger than 10, the results are mixed. We
believe that these mixed results are not intrinsic, but are the believe that these mixed results are not intrinsic, but are the
consequence of various implementation artifacts, including overly consequence of various implementation artifacts, including overly
aggressive applications employing many simultaneous connections. aggressive applications employing many simultaneous connections.
We propose that all TCP implementations should have a settable TCP IW We recommend that all TCP implementations have a settable TCP IW
parameter; the default setting may start at 10 segments and should be parameter. As of 2011 an appropriate value for this parameter is 10
raised as we come to understand and and correct things that conflict. segments as long as there is a reasonable effort to monitor for
possible interactions with other Internet applications and services.
Furthermore, it is understood that the appropriate value for IW is
likely to continue to rise in the future, but this document does not
include any supporting evidence for larger values of IW.
In addition, we introduce a minor revision to RFC 3390 and RFC 5681 In addition, we introduce a minor revision to RFC 3390 and RFC 5681
[RFC5681] to eliminate resetting the initial window when the SYN or [RFC5681] to eliminate resetting the initial window when the SYN or
SYN/ACK is lost. SYN/ACK is lost.
The document closes with a discussion of a list of concerns that have The document closes with a discussion of the consensus from the TCPM
been brought up, and some recent test results showing most of the working group on the near-term usage and deployment of IW10 in the
concerns can not be validated. Internet.
A complementary set of slides for this proposal can be found at A complementary set of slides for this proposal can be found at
[CD10]. [CD10].
2. TCP Modification 2. TCP Modification
This document proposes an increase in the permitted upper bound for This document proposes an increase in the permitted upper bound for
TCP's initial window (IW) to 10 segments. This increase is optional: TCP's initial window (IW) to 10 segments depending on the MSS. This
a TCP MAY start with a larger initial window up to 10 segments. increase is optional: a TCP MAY start with an initial window that is
smaller than 10 segments.
More precisely, the upper bound for the initial window will be
min (10*MSS, max (2*MSS, 14600)) (1)
This upper bound for the initial window size represents a change from This upper bound for the initial window size represents a change from
RFC 3390 [RFC3390], which specified that the congestion window be RFC 3390 [RFC3390], which specified that the congestion window be
initialized between 2 and 4 segments depending on the MSS. initialized between 2 and 4 segments depending on the MSS.
This change applies to the initial window of the connection in the This change applies to the initial window of the connection in the
first round trip time (RTT) of data transmission following the TCP first round trip time (RTT) of data transmission during or following
three-way handshake. Neither the SYN/ACK nor its acknowledgment (ACK) the TCP three-way handshake. Neither the SYN/ACK nor its
in the three-way handshake should increase the initial window size. acknowledgment (ACK) in the three-way handshake should increase the
initial window size.
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.
Furthermore, RFC 3390 and RFC 5681 [RFC5681] state that Furthermore, RFC 3390 and RFC 5681 [RFC5681] state that
"If the SYN or SYN/ACK is lost, the initial window used by a "If the SYN or SYN/ACK is lost, the initial window used by a
sender after a correctly transmitted SYN MUST be one segment sender after a correctly transmitted SYN MUST be one segment
consisting of MSS bytes." consisting of MSS bytes."
The proposed change to reduce the default RTO to 1 second [RFC6298] The proposed change to reduce the default RTO to 1 second [RFC6298]
increases the chance for spurious SYN or SYN/ACK retransmission, thus increases the chance for spurious SYN or SYN/ACK retransmission, thus
unnecessarily penalizing connections with RTT > 1 second if their unnecessarily penalizing connections with RTT > 1 second if their
skipping to change at page 4, line 42 skipping to change at page 5, line 11
the minimum of the value used for the initial window and the current 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 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 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 change the loss window, which must remain 1 segment of MSS bytes (to
permit the lowest possible window size in the case of severe permit the lowest possible window size in the case of severe
congestion). congestion).
Furthermore, to limit any negative effect that a larger initial Furthermore, to limit any negative effect that a larger initial
window may have on links with limited bandwidth or buffer space, window may have on links with limited bandwidth or buffer space,
implementations SHOULD fall back to RFC 3390 for the restart window implementations SHOULD fall back to RFC 3390 for the restart window
(RW), if any packet loss is detected during either the initial (RW) if any packet loss is detected during either the initial window,
window, or a restart window, when more than 4KB of data is sent. or a restart window, and more than 4KB of data is sent.
3. Implementation Issues 3. Implementation Issues
[Need to decide if a different formula is needed for PMTU != 1500.]
HTTP 1.1 specification allows only two simultaneous connections per HTTP 1.1 specification allows only two simultaneous connections per
domain, while web browsers open more simultaneous TCP connections domain, while web browsers open more simultaneous TCP connections
[Ste08], partly to circumvent the small initial window in order to [Ste08], partly to circumvent the small initial window in order to
speed up the loading of web pages as described above. speed up the loading of web pages as described above.
When web browsers open simultaneous TCP connections to the same When web browsers open simultaneous TCP connections to the same
destination, they are working against TCP's congestion control destination, they are working against TCP's congestion control
mechanisms [FF99]. Combining this behavior with larger initial mechanisms [FF99]. Combining this behavior with larger initial
windows further increases the burstiness and unfairness to other windows further increases the burstiness and unfairness to other
traffic in the network. A larger initial window will incentivize traffic in the network. A larger initial window will incentivize
skipping to change at page 5, line 24 skipping to change at page 5, line 39
in [Duk10]), effectively limiting how much window a remote host may in [Duk10]), effectively limiting how much window a remote host may
use. In order to realize the full benefit of the large initial use. In order to realize the full benefit of the large initial
window, implementations are encouraged to advertise an initial window, implementations are encouraged to advertise an initial
receive window of at least 10 segments, except for the circumstances receive window of at least 10 segments, except for the circumstances
where a larger initial window is deemed harmful. (See the Mitigation where a larger initial window is deemed harmful. (See the Mitigation
section below.) section below.)
TCP SACK option ([RFC2018]) was thought to be required in order for TCP SACK option ([RFC2018]) was thought to be required in order for
the larger initial window to perform well. But measurements from both the larger initial window to perform well. But measurements from both
a testbed and live tests showed that IW=10 without the SACK option a testbed and live tests showed that IW=10 without the SACK option
still beats the performance of IW=3 with the SACK option [CW10]. outperforms IW=3 with the SACK option [CW10].
4. Background 4. Background
TCP congestion window was introduced as part of the congestion TCP congestion window was introduced as part of the congestion
control algorithm by Van Jacobson in 1988 [Jac88]. The initial value control algorithm by Van Jacobson in 1988 [Jac88]. The initial value
of one segment was used as the starting point for newly established of one segment was used as the starting point for newly established
connections to probe the available bandwidth on the network. connections to probe the available bandwidth on the network.
Today's Internet is dominated by web traffic running on top of short- Today's Internet is dominated by web traffic running on top of short-
lived TCP connections [IOR2009]. The relatively small initial window lived TCP connections [IOR2009]. The relatively small initial window
skipping to change at page 5, line 50 skipping to change at page 6, line 17
global broadband (> 2Mbps) adoption has surpassed 50%, propelling the global broadband (> 2Mbps) adoption has surpassed 50%, propelling the
average connection speed to reach 1.7Mbps, while the narrowband (< average connection speed to reach 1.7Mbps, while the narrowband (<
256Kbps) usage has dropped to 5%. In contrast, TCP's initial window 256Kbps) usage has dropped to 5%. In contrast, TCP's initial window
has remained 4KB for a decade [RFC2414], corresponding to a bandwidth has remained 4KB for a decade [RFC2414], corresponding to a bandwidth
utilization of less than 200Kbps per connection, assuming an RTT of utilization of less than 200Kbps per connection, assuming an RTT of
200ms. 200ms.
A large proportion of flows on the Internet are short web A large proportion of flows on the Internet are short web
transactions over TCP, and complete before exiting TCP slow start. transactions over TCP, and complete before exiting TCP slow start.
Speeding up the TCP flow startup phase, including circumventing the Speeding up the TCP flow startup phase, including circumventing the
initial window limit, has been an area of active research [PWSB09, initial window limit, has been an area of active research [RFC6077,
Sch08]. Numerous proposals exist [LAJW07, RFC4782, PRAKS02, PK98]. Sch08]. Numerous proposals exist [LAJW07, RFC4782, PRAKS02, PK98].
Some require router support [RFC4782, PK98], hence are not practical Some require router support [RFC4782, PK98], hence are not practical
for the public Internet. Others suggested bold, but often radical for the public Internet. Others suggested bold, but often radical
ideas, likely requiring more years of research before standardization ideas, likely requiring more years of research before standardization
and deployment. and deployment.
In the mean time, applications have responded to TCP's "slow" start. In the mean time, applications have responded to TCP's "slow" start.
Web sites use multiple sub-domains [Bel10] to circumvent HTTP 1.1 Web sites use multiple sub-domains [Bel10] to circumvent HTTP 1.1
regulation on two connections per physical host [RFC2616]. As of regulation on two connections per physical host [RFC2616]. As of
today, major web browsers open multiple connections to the same site today, major web browsers open multiple connections to the same site
(up to six connections per domain [Ste08] and the number is growing). (up to six connections per domain [Ste08] and the number is growing).
skipping to change at page 6, line 28 skipping to change at page 6, line 42
connections improves performance most of the time. While raising the connections improves performance most of the time. While raising the
initial congestion window may cause congestion for certain users initial congestion window may cause congestion for certain users
using these browsers, we argue that the browsers and other using these browsers, we argue that the browsers and other
application need to respect HTTP 1.1 regulation and stop increasing application need to respect HTTP 1.1 regulation and stop increasing
number of simultaneous TCP connections. We believe a modest increase number of simultaneous TCP connections. We believe a modest increase
of the initial window will help to stop this trend, and provide the of the initial window will help to stop this trend, and provide the
best interim solution to improve overall user performance, and reduce best interim solution to improve overall user performance, and reduce
the server, client, and network load. the server, client, and network load.
Note that persistent connections and pipelining are designed to Note that persistent connections and pipelining are designed to
address some of the issues with HTTP above [RFC2616]. Their presence address some of the above issues with HTTP [RFC2616]. Their presence
does not diminish the need for a larger initial window. E.g., data does not diminish the need for a larger initial window. E.g., data
from the Chrome browser show that 35% of HTTP requests are made on from the Chrome browser show that 35% of HTTP requests are made on
new TCP connections. Our test data also confirm significant latency new TCP connections. Our test data also shows significant latency
reduction with the large initial window even with these two HTTP reduction with the large initial window even in conjunction with
features ([Duk10]). these two HTTP features ([Duk10]).
Also note that packet pacing has been suggested as an effective Also note that packet pacing has been suggested as a possible
mechanism to avoid large bursts and their associated damage [VH97]. mechanism to avoid large bursts and their associated harm [VH97].
We do not require pacing in our proposal due to our strong preference Pacing is not required in this proposal due to a strong preference
for a simple solution. We suspect for packet bursts of a moderate for a simple solution. We suspect for packet bursts of a moderate
size, packet pacing will not be necessary. This seems to be confirmed size, packet pacing will not be necessary. This seems to be confirmed
by our test results. by our test results.
More discussion of the increase in initial window, including the More discussion of the increase in initial window, including the
choice of 10 segments can be found in [Duk10, CD10]. choice of 10 segments can be found in [Duk10, CD10].
5. Advantages of Larger Initial Windows 5. Advantages of Larger Initial Windows
5.1 Reducing Latency 5.1 Reducing Latency
An increase of the initial window from 3 segments to 10 segments An increase of the initial window from 3 segments to 10 segments
reduces the total transfer time for data sets greater than 4KB by up reduces the total transfer time for data sets greater than 4KB by up
to 4 round trips. to 4 round trips.
The table below compares the number of round trips between IW=3 and The table below compares the number of round trips between IW=3 and
IW=10 for different transfer sizes, assuming infinite bandwidth, no IW=10 for different transfer sizes, assuming infinite bandwidth, no
packet loss, and the standard delayed acks with large delayed-ack packet loss, and the standard delayed acks with large delayed-ACK
timer. timer.
--------------------------------------- ---------------------------------------
| total segments | IW=3 | IW=10 | | total segments | IW=3 | IW=10 |
--------------------------------------- ---------------------------------------
| 3 | 1 | 1 | | 3 | 1 | 1 |
| 6 | 2 | 1 | | 6 | 2 | 1 |
| 10 | 3 | 1 | | 10 | 3 | 1 |
| 12 | 3 | 2 | | 12 | 3 | 2 |
| 21 | 4 | 2 | | 21 | 4 | 2 |
skipping to change at page 7, line 47 skipping to change at page 8, line 12
then were less than 4KB, and could be completed in a single RTT then were less than 4KB, and could be completed in a single RTT
[All00]. [All00].
Since RFC 3390 was published, web objects have gotten significantly Since RFC 3390 was published, web objects have gotten significantly
larger [Chu09, RJ10]. Today only a small percentage of web objects larger [Chu09, RJ10]. Today only a small percentage of web objects
(e.g., 10% of Google's search responses) can fit in the 4KB initial (e.g., 10% of Google's search responses) can fit in the 4KB initial
window. The average HTTP response size of gmail.com, a highly window. The average HTTP response size of gmail.com, a highly
scripted web-site, is 8KB (Figure 1. in [Duk10]). The average web scripted web-site, is 8KB (Figure 1. in [Duk10]). The average web
page, including all static and dynamic scripted web objects on the page, including all static and dynamic scripted web objects on the
page, has seen even greater growth in size [RJ10]. HTTP pipelining page, has seen even greater growth in size [RJ10]. HTTP pipelining
[RFC2616] and new web transport protocols like SPDY [SPDY] allow [RFC2616] and new web transport protocols such as SPDY [SPDY] allow
multiple web objects to be sent in a single transaction, potentially multiple web objects to be sent in a single transaction, potentially
requiring even larger initial window in order to transfer a whole web benefiting from an even larger initial window in order to transfer an
page in one round trip. entire web page in a small number of round trips.
5.3 Recovering faster from loss on under-utilized or wireless links 5.3 Recovering faster from loss on under-utilized or wireless links
A greater-than-3-segment initial window increases the chance to A greater-than-3-segment initial window increases the chance to
recover packet loss through Fast Retransmit rather than the lengthy recover packet loss through Fast Retransmit rather than the lengthy
initial RTO [RFC5681]. This is because the fast retransmit algorithm initial RTO [RFC5681]. This is because the fast retransmit algorithm
requires three duplicate acks as an indication that a segment has requires three duplicate ACKs as an indication that a segment has
been lost rather than reordered. While newer loss recovery techniques been lost rather than reordered. While newer loss recovery techniques
such as Limited Transmit [RFC3042] and Early Retransmit [RFC5827] such as Limited Transmit [RFC3042] and Early Retransmit [RFC5827]
have been proposed to help speeding up loss recovery from a smaller have been proposed to help speeding up loss recovery from a smaller
window, both algorithms can still benefit from the larger initial window, both algorithms can still benefit from the larger initial
window because of a better chance to receive more ACKs to react upon. window because of a better chance to receive more ACKs to react upon.
6. Disadvantages of Larger Initial Windows for the Individual Connection 6. Disadvantages of Larger Initial Windows for the Individual Connection
The larger bursts from an increase in the initial window may cause The larger bursts from an increase in the initial window may cause
buffer overrun and packet drop in routers with small buffers, or buffer overrun and packet drop in routers with small buffers, or
routers experiencing congestion. This could result in unnecessary routers experiencing congestion. This could result in unnecessary
retransmit timeouts. For a large-window connection that is able to retransmit timeouts. For a large-window connection that is able to
recover without a retransmit timeout, this could result in an recover without a retransmit timeout, this could result in an
unnecessarily-early transition from the slow-start to the congestion- unnecessarily-early transition from the slow-start to the congestion-
avoidance phase of the window increase algorithm. [Note: knowing the avoidance phase of the window increase algorithm.
large initial window may cause premature segment drop, should one
make an exception for it, i.e., by allowing ssthresh to remain
unchanged if loss is from an enlarged initial window?]
Premature segment drops are unlikely to occur in uncongested networks Premature segment drops are unlikely to occur in uncongested networks
with sufficient buffering, or in moderately-congested networks where with sufficient buffering, or in moderately-congested networks where
the congested router uses active queue management (such as Random the congested router uses active queue management (such as Random
Early Detection [FJ93, RFC2309, RFC3150]). Early Detection [FJ93, RFC2309, RFC3150]).
Insufficient buffering is more likely to exist in the access routers Insufficient buffering is more likely to exist in the access routers
connecting slower links. A recent study of access router buffer size connecting slower links. A recent study of access router buffer size
[DGHS07] reveals the majority of access routers provision enough [DGHS07] reveals the majority of access routers provision enough
buffer for 130ms or longer, sufficient to cover a burst of more than buffer for 130ms or longer, sufficient to cover a burst of more than
skipping to change at page 9, line 12 skipping to change at page 9, line 23
congestion window by either network congestion or by the receiver's congestion window by either network congestion or by the receiver's
advertised window. advertised window.
7. Disadvantages of Larger Initial Windows for the Network 7. Disadvantages of Larger Initial Windows for the Network
An increase in the initial window may increase congestion in a An increase in the initial window may increase congestion in a
network. However, since the increase is one-time only (at the network. However, since the increase is one-time only (at the
beginning of a connection), and the rest of TCP's congestion backoff beginning of a connection), and the rest of TCP's congestion backoff
mechanism remains in place, it's highly unlikely the increase will mechanism remains in place, it's highly unlikely the increase will
render a network in a persistent state of congestion, or even render a network in a persistent state of congestion, or even
congestion collapse. This seems to have been confirmed by our large congestion collapse. This seems to have been confirmed by the large
scale experiments described later. scale experiments described later.
Until this proposal is widely deployed, a fairness issue may exist
between flows adopting a larger initial window vs flows that are
RFC3390-compliant. Although no severe unfairness has been detected on
all the known tests so far, further study on this topic may be
warranted.
Some of the discussions from RFC 3390 are still valid for IW=10. Some of the discussions from RFC 3390 are still valid for IW=10.
Moreover, it is worth noting that although TCP NewReno increases the Moreover, it is worth noting that although TCP NewReno increases the
chance of duplicate segments when trying to recover multiple packet chance of duplicate segments when trying to recover multiple packet
losses from a large window [RFC3782], the wide support of TCP losses from a large window [RFC3782], the wide support of TCP
Selective Acknowledgment (SACK) option [RFC2018] in all major OSes Selective Acknowledgment (SACK) option [RFC2018] in all major OSes
today should keep the volume of duplicate segments in check. today should keep the volume of duplicate segments in check.
Recent measurements [Get11] provide evidence of extremely large Recent measurements [Get11] provide evidence of extremely large
queues (in the order of one second) at access networks of the 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 Internet. While a significant part of the buffer bloat is contributed
by large downloads/uploads such as video files, emails with large by large downloads/uploads such as video files, emails with large
attachments, backups and download of movies to disk, some of the attachments, backups and download of movies to disk, some of the
problem is also caused by Web browsing of image heavy sites [Get11]. problem is also caused by Web browsing of image heavy sites [Get11].
This queuing delay is generally considered harmful for responsiveness This queuing delay is generally considered harmful for responsiveness
of latency sensitive traffic such as DNS queries, ARP, DHCP, VoIP and of latency sensitive traffic such as DNS queries, ARP, DHCP, VoIP and
Gaming. IW=10 can exacerbate this problem when doing short downloads Gaming. IW=10 can exacerbate this problem when doing short downloads
such as Web browsing. The mitigations proposed for the broader such as Web browsing [Get11-1]. The mitigations proposed for the
problem of buffer bloating are also applicable in this case, such as broader problem of buffer bloating are also applicable in this case,
the use of ECN, AQM schemes and traffic classification (QoS). such as the use of ECN, AQM schemes and traffic classification (QoS).
8. Mitigation of Negative Impact 8. Mitigation of Negative Impact
Much of the negative impact from an increase in the initial window is 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. likely to be felt by users behind slow links with limited buffers.
The negative impact can be mitigated by hosts directly connected to a The negative impact can be mitigated by hosts directly connected to a
low-speed link advertising a smaller initial receive window than 10 low-speed link advertising a smaller initial receive window than 10
segments. This can be achieved either through manual configuration by segments. This can be achieved either through manual configuration by
the users, or through the host stack auto-detecting the low bandwidth the users, or through the host stack auto-detecting the low bandwidth
links. links.
More suggestions to improve the end-to-end performance of slow links Additional suggestions to improve the end-to-end performance of slow
can be found in RFC 3150 [RFC3150]. links can be found in RFC 3150 [RFC3150].
[Note: if packet loss is detected during IW through fast retransmit,
should cwnd back down to 2 rather than FlightSize / 2?]
9. Interactions with the Retransmission Timer 9. Interactions with the Retransmission Timer
A large initial window increases the chance of spurious RTO on a low- A large initial window increases the chance of spurious RTO on a low-
bandwidth path because the packet transmission time will dominate the bandwidth path because the packet transmission time will dominate the
round-trip time. To minimize spurious retransmissions, round-trip time. To minimize spurious retransmissions,
implementations MUST follow RFC 2988 [RFC2988] to restart the implementations MUST follow RFC 6298 [RFC6298] to restart the
retransmission timer with the current value of RTO for each ack retransmission timer with the current value of RTO for each ACK
received that acknowledges new data. received that acknowledges new data.
10. Experimental Results From Large Scale Cluster Tests 10. Experimental Results From Large Scale Cluster Tests
In this section we summarize our findings from large scale Internet In this section we summarize our findings from large scale Internet
experiments with an initial window of 10 segments, conducted via experiments with an initial window of 10 segments, conducted via
Google's front-end infrastructure serving a diverse set of Google's front-end infrastructure serving a diverse set of
applications. We present results from two data centers, each chosen applications. We present results from two data centers, each chosen
because of the specific characteristics of subnets served: AvgDC has because of the specific characteristics of subnets served: AvgDC has
connection bandwidths closer to the worldwide average reported in connection bandwidths closer to the worldwide average reported in
skipping to change at page 12, line 15 skipping to change at page 12, line 30
the baseline, e.g. the 99% latency for maps has increased by 2.3% the baseline, e.g. the 99% latency for maps has increased by 2.3%
(80ms) when compared to the baseline. There is no evidence from our (80ms) when compared to the baseline. There is no evidence from our
measurements that such a cost on latency is a result of subnet 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 bandwidth alone. Although we have no way of knowing from our data, we
conjecture that the amount of buffering at bottleneck links plays a conjecture that the amount of buffering at bottleneck links plays a
key role in performance of these applications. key role in performance of these applications.
Further details on our experiments and analysis can be found in Further details on our experiments and analysis can be found in
[Duk10, DCCM10]. [Duk10, DCCM10].
11. List of Concerns and Corresponding Test Results 11. Other Studies
Concerns have been raised since we first published our proposal based
on a set of large scale experiments. To better understand the impact
of a larger initial window in order to confirm or dismiss these
concerns, we, as well as people outside of Google have conducted
numerous additional tests in the past year, using either Google's
large scale clusters, simulations, or real testbeds. The following is
a list of concerns and some of the findings.
A complete list of tests conducted, their results and related studies
can be found at [IW10].
o How complete are our tests in traffic pattern coverage?
Google today offers a large portfolio of services beyond web
search. The list includes Gmail, Google Maps, Photos, News, Sites,
Images, Videos,..., etc. Our tests included most of Google's
services, covering 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.
[CW10] contains some result from a testbed study on how short flows
with a larger initial window might affect the throughput
performance of other co-existing, long lived, bulk data transfers.
o Larger bursts from the increase in the initial window cause
significantly more packet drops
All the known tests conducted on this subject so far [Duk10, Sch11,
Sch11-1, CW10] show that, although bursts from the larger initial
window tend to cause more packet drops, the increase tends to be
very modest. The only exception is from our own testbed study
[CW10] when under extremely high load and/or simultaneous opens.
But both IW=3 and IW=10 suffered very high packet loss rates under
those conditions.
o A large initial window may severely impact TCP performance over
highly multiplexed links still common in developing regions
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 Google
services that employ multiple simultaneous connections, at the cost
of 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.
Similar phenomenon have also been observed from our testbed study
[CW10].
o Why 10 segments?
Questions have been raised on how the number 10 was picked. We have Besides the large scale Internet experiments described above, a
tried different sizes in our large scale experiments, and found number of other studies have been conducted on the effects of IW10 in
that 10 segments seem to give most of the benefits for the services various environments. These tests were summarized below, with more
we tested while not causing significant increase in the discussion in Appendix A.
retransmission rates. Going forward 10 segments may turn out to be
too small when the average of web object sizes continue to grow. A
scheme to attempt to right size the initial window automatically
over long timescales has been proposed in [Tou10].
o Need more thorough analysis of the impact on slow links A complete list of tests conducted, with their results and related
studies can be found at the [IW10] link.
Although data from [Duk10] showed the large initial window reduced 1. [Sch08] described an earlier evaluation of various Fast Startup
the average latency even for the dialup link class of only 56Kbps approaches, including the "Initial-Start" of 10 MSS.
in bandwidth, it is only prudent to perform more microscopic
analysis on its effect on slow links. We set up two testbeds for
this purpose [CW10].
Both testbeds were used to emulate a 300ms RTT, bottleneck link 2. [DCCM10] presented the result from Google's large scale IW10
bandwidth as low as 64Kbps, and route queue size as low as 40 experiments, with a focus on areas with highly multiplexed links or
packets. Although we've tried a large combination of test limited broadband deployment such as Africa and South America.
parameters, almost all tests we ran managed to show some 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 our own large scale data center
experiments [CD10, DCCM10] and a separate study using NSC
simulations [Sch11, Sch11-1].
o How will the larger initial window affect flows with initial 3. [CW10] contained a testbed study on IW10 performance over slow
windows 4KB or less? links. It also studied how short flows with a larger initial window
might affect the throughput performance of other co-existing, long
lived, bulk data transfers.
Flows with the larger initial window will likely grab more 4. [Sch11] compared IW10 against a number of other fast startup
bandwidth from a bottleneck link when competing against flows with schemes, and concluded that IW10 works rather well and is also quite
smaller initial window, at least initially. How long will this fair.
"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 5. [JNDK10] and later [JNDK10-1] studied the effect of IW10 over
initial windows, it did not show up in our large scale experiments, cellular networks.
as the average latency for the bucket of all responses < 4KB 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].
The same phenomenon seems to exist in our testbed experiments. 6. [AERG11] studied the effect of larger ICW sizes, among other
Flows with IW=3 only suffered slightly when competing against flows things, on end users' page load time from Yahoo!'s Content Delivery
with IW=10 in light to median loads. Under high load both flows' Network.
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 IW=10 enabled short
flows to complete sooner, leaving more room for the long-lived,
background flows.
An independent study using NSC simulator has also concluded that 12. Usage and Deployment Recommendations
IW=10 works rather well and is quite fair against IW=3 [Sch11,
Sch11-1].
o How will a larger initial window perform over cellular networks? 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.
Some simulation studies [JNDK10, JNDK10-1] have been conducted to Therefore, special care is needed when using this experimental TCP
study the effect of a larger initial window on wireless links from extension, in particular on large-scale systems originating a
2G to 4G networks (EGDE/HSPA/LTE). The overall result seems mixed significant amount of Internet traffic. Anyone (stack vendors,
in both raw performance and the fairness index. network administrators, etc.) turning on a larger initial window
SHOULD ensure that the performance is monitored before and after that
change. Relevant performance metrics include the percentages of
packet losses or segment retransmissions as well as application-level
metrics such as data transfer completion times or media quality. Note
that it is important also to take into account hosts that do not
implement a larger initial window. Furthermore, non-TCP traffic (such
as VoIP) should be monitored as well. 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 SHOULD NOT be turned on by default on
systems without such monitoring capabilities.
There has been on-going studies by people from Nokia on the effect The IETF TCPM working group is very much interested in further
of a larger initial window on GPRS and HSDPA networks. Initial test reports from experiments with this specification and encourages the
results seem to show no or little improvement from flows with a publication of such measurement data. If no significant harm is
larger initial window. More studies are needed to understand why. 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.
12. Related Proposals 13. Related Proposals
Two other proposals [All10, Tou10] have been made with the goal to Two other proposals [All10, Tou12] have been published to raise TCP's
raise TCP's initial window size over a large timescale. Both aim at initial window size over a large timescale. Both aim at reducing the
addressing the concern about the uncertain impact from raising the uncertain impact of a larger initial window at an Internet wide
initial window size at an Internet wide scale. Moreover, [Tou10] scale. Moreover, [Tou12] seeks an algorithm to automate the
seeks an algorithm to automate the adjustment of IW safely over long adjustment of IW safely over long haul period.
haul period.
Based on our test results from the past couple of years, we believe Although a modest, static increase of IW to 10 may address the near-
our proposal - a modest, static increase of IW to 10, to be the best term need for better web performance, much work is needed from the
near-term solution that is both simple and effective. The other TCP research community to find a long term solution to the TCP flow
proposals, with their added complexity and much longer deployment startup problem.
cycles, seem best suited for growing IW beyond 10 in the long run.
13. Security Considerations 14. Security Considerations
This document discusses the initial congestion window permitted for This document discusses the initial congestion window permitted for
TCP connections. Changing this value does not raise any known new TCP connections. Although changing this value may cause more packet
security issues with TCP. 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.
14. Conclusion 15. Conclusion
This document suggests a simple change to TCP that will reduce the This document suggests a simple change to TCP that will reduce the
application latency over short-lived TCP connections or links with application latency over short-lived TCP connections or links with
long RTTs (saving several RTTs during the initial slow-start phase) long RTTs (saving several RTTs during the initial slow-start phase)
with little or no negative impact over other flows. Extensive tests with little or no negative impact over other flows. Extensive tests
have been conducted through both testbeds and large data centers with have been conducted through both testbeds and large data centers with
most results showing improved latency with only a small increase in most results showing improved latency with only a small increase in
the packet retransmission rate. Based on these results we believe a the packet retransmission rate. Based on these results we believe a
modest increase of IW to 10 is the best near-term proposal while modest increase of IW to 10 is the best solution for the near-term
other proposals [All10, Tou10] may be best suited to grow IW beyond deployment, while scaling IW over the long run remains a challenge
10 in the long run. for the TCP research community.
15. IANA Considerations 16. IANA Considerations
None None
16. Acknowledgments 17. Acknowledgments
Many people at Google have helped to make the set of large scale Many people at Google have helped to make the set of large scale
tests possible. We would especially like to acknowledge Amit Agarwal, tests possible. We would especially like to acknowledge Amit Agarwal,
Tom Herbert, Arvind Jain and Tiziana Refice for their major Tom Herbert, Arvind Jain and Tiziana Refice for their major
contributions. contributions.
Normative References Normative References
[RFC6298] Paxson, V., Allman, M., Chu, J. and M. Sargent, "Computing
TCP's Retransmission Timer", RFC6298, June 2011.
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP [RFC2018] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP
Selective Acknowledgement Options", RFC 2018, October 1996. Selective Acknowledgment Options", RFC 2018, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter,
L., Leach, P. and T. Berners-Lee, "Hypertext Transfer L., Leach, P. and T. Berners-Lee, "Hypertext Transfer
Protocol -- HTTP/1.1", RFC 2616, June 1999. Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission
Timer", RFC 2988, November 2000.
[RFC3390] Allman, M., Floyd, S. and C. Partridge, "Increasing TCP's [RFC3390] Allman, M., Floyd, S. and C. Partridge, "Increasing TCP's
Initial Window", RFC 3390, October 2002. Initial Window", RFC 3390, October 2002.
[RFC5681] Allman, M., Paxson, V. and E. Blanton, "TCP Congestion [RFC5681] Allman, M., Paxson, V. and E. Blanton, "TCP Congestion
Control", RFC 5681, September 2009. Control", RFC 5681, September 2009.
[RFC5827] Allman, M., Avrachenkov, K., Ayesta, U., Blanton, J. and P. [RFC5827] Allman, M., Avrachenkov, K., Ayesta, U., Blanton, J. and P.
Hurtig, "Early Retransmit for TCP and SCTP", RFC 5827, Hurtig, "Early Retransmit for TCP and SCTP", RFC 5827, May
April 2010. 2010.
[RFC6298] Paxson, V., Allman, M., Chu, J. and M. Sargent, "Computing
TCP's Retransmission Timer", RFC 6298, June 2011.
Informative References Informative References
[AKAM10] "The State of the Internet, 3rd Quarter 2009", Akamai [AKAM10] "The State of the Internet, 3rd Quarter 2009", Akamai
Technologies, Inc., January 2010. Technologies, Inc., January 2010.
URL=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.
[All00] Allman, M., "A Web Server's View of the Transport Layer", [All00] Allman, M., "A Web Server's View of the Transport Layer",
ACM Computer Communication Review, 30(5), October 2000. ACM Computer Communication Review, 30(5), October 2000.
[All10] Allman, M., "Initial Congestion Window Specification", [All10] Allman, M., "Initial Congestion Window Specification",
Internet-draft draft-allman-tcpm-bump-initcwnd-00.txt work Internet-draft draft-allman-tcpm-bump-initcwnd-00.txt, work
in progress. in progress, last updated November 2010.
[Bel10] Belshe, M., "A Client-Side Argument For Changing TCP Slow [Bel10] Belshe, M., "A Client-Side Argument For Changing TCP Slow
Start", January, 2010. URL Start", January, 2010. URL
http://sites.google.com/a/chromium.org/dev/spdy/ http://sites.google.com/a/chromium.org/dev/spdy/
An_Argument_For_Changing_TCP_Slow_Start.pdf An_Argument_For_Changing_TCP_Slow_Start.pdf
[CD10] Chu, J. and N. Dukkipati, "Increasing TCP's Initial [CD10] Chu, J. and N. Dukkipati, "Increasing TCP's Initial
Window", Presented to 77th IRTF ICCRG & IETF TCPM working Window", Presented to 77th IRTF ICCRG & IETF TCPM working
group meetings, March 2010. URL group meetings, March 2010. URL
http://www.ietf.org/proceedings/77/slides/tcpm-4.pdf http://www.ietf.org/proceedings/77/slides/tcpm-4.pdf
skipping to change at page 17, line 29 skipping to change at page 16, line 31
http://www.ietf.org/proceedings/78/slides/iccrg-3.pdf http://www.ietf.org/proceedings/78/slides/iccrg-3.pdf
[DGHS07] Dischinger, M., Gummadi, K., Haeberlen, A. and S. Saroiu, [DGHS07] Dischinger, M., Gummadi, K., Haeberlen, A. and S. Saroiu,
"Characterizing Residential Broadband Networks", Internet "Characterizing Residential Broadband Networks", Internet
Measurement Conference, October 24-26, 2007. Measurement Conference, October 24-26, 2007.
[Duk10] Dukkipati, N., Refice, T., Cheng, Y., Chu, J., Sutin, N., [Duk10] Dukkipati, N., Refice, T., Cheng, Y., Chu, J., Sutin, N.,
Agarwal, A., Herbert, T. and J. Arvind, "An Argument for Agarwal, A., Herbert, T. and J. Arvind, "An Argument for
Increasing TCP's Initial Congestion Window", ACM SIGCOMM Increasing TCP's Initial Congestion Window", ACM SIGCOMM
Computer Communications Review, vol. 40 (2010), pp. 27-33. Computer Communications Review, vol. 40 (2010), pp. 27-33.
July 2010. URL July 2010.
http://www.google.com/research/pubs/pub36640.html
[FF99] Floyd, S., and K. Fall, "Promoting the Use of End-to-End [FF99] Floyd, S., and K. Fall, "Promoting the Use of End-to-End
Congestion Control in the Internet", IEEE/ACM Transactions Congestion Control in the Internet", IEEE/ACM Transactions
on Networking, August 1999. on Networking, August 1999.
[FJ93] Floyd, S. and V. Jacobson, "Random Early Detection gateways [FJ93] Floyd, S. and V. Jacobson, "Random Early Detection gateways
for Congestion Avoidance", IEEE/ACM Transactions on for Congestion Avoidance", IEEE/ACM Transactions on
Networking, V.1 N.4, August 1993, p. 397-413. Networking, V.1 N.4, August 1993, p. 397-413.
[Get11] Gettys, J., "Bufferbloat: Dark buffers in the Internet", [Get11] Gettys, J., "Bufferbloat: Dark buffers in the Internet",
Presented to 80th IETF TSV Area meeting, March 2011. URL Presented to 80th IETF TSV Area meeting, March 2011. URL
http://www.ietf.org/proceedings/80/slides/tsvarea-1.pdf http://www.ietf.org/proceedings/80/slides/tsvarea-1.pdf
[Get11-1] Gettys, J., "IW10 Considered Harmful", Internet-draft
draft-gettys-iw10-considered-harmful-00, work in progress,
August 2011.
[IOR2009] Labovitz, C., Iekel-Johnson, S., McPherson, D., Oberheide, [IOR2009] Labovitz, C., Iekel-Johnson, S., McPherson, D., Oberheide,
J. Jahanian, F. and M. Karir, "Atlas Internet Observatory J. Jahanian, F. and M. Karir, "Atlas Internet Observatory
2009 Annual Report", 47th NANOG Conference, October 2009. 2009 Annual Report", 47th NANOG Conference, October 2009.
[IW10] "TCP IW10 links", URL [IW10] "TCP IW10 links", URL
http://code.google.com/speed/protocols/tcpm-IW10.html http://code.google.com/speed/protocols/tcpm-IW10.html
[Jac88] Jacobson, V., "Congestion Avoidance and Control", Computer [Jac88] Jacobson, V., "Congestion Avoidance and Control", Computer
Communication Review, vol. 18, no. 4, pp. 314-329, Aug. Communication Review, vol. 18, no. 4, pp. 314-329, Aug.
1988. 1988.
skipping to change at page 18, line 30 skipping to change at page 17, line 35
http://www.icir.org/mallman/papers/jumpstart-pfldnet07.pdf http://www.icir.org/mallman/papers/jumpstart-pfldnet07.pdf
[PK98] Padmanabhan V.N. and R. Katz, "TCP Fast Start: A technique [PK98] Padmanabhan V.N. and R. Katz, "TCP Fast Start: A technique
for speeding up web transfers", in Proceedings of IEEE for speeding up web transfers", in Proceedings of IEEE
Globecom '98 Internet Mini-Conference, 1998. Globecom '98 Internet Mini-Conference, 1998.
[PRAKS02] Partridge, C., Rockwell, D., Allman, M., Krishnan, R. and [PRAKS02] Partridge, C., Rockwell, D., Allman, M., Krishnan, R. and
J. Sterbenz, "A Swifter Start for TCP", Technical Report J. Sterbenz, "A Swifter Start for TCP", Technical Report
No. 8339, BBN Technologies, March 2002. No. 8339, BBN Technologies, March 2002.
[PWSB09] Papadimitriou, D., Welzl, M., Scharf, M. and B. Briscoe,
"Open Research Issues in Internet Congestion Control",
section 3.4, Internet-draft draft-irtf-iccrg-welzl-
congestion-control-open-research-05.txt, work in progress.
[RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering,
S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G.,
Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, S., Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, S.,
Wroclawski, J. and L. Zhang, "Recommendations on Queue Wroclawski, J. and L. Zhang, "Recommendations on Queue
Management and Congestion Avoidance in the Internet", RFC Management and Congestion Avoidance in the Internet", RFC
2309, April 1998. 2309, April 1998.
[RFC2414] Allman, M., Floyd, S. and C. Partridge, "Increasing TCP's [RFC2414] Allman, M., Floyd, S. and C. Partridge, "Increasing TCP's
Initial Window", RFC 2414, September 1998. Initial Window", RFC 2414, September 1998.
[RFC3042] Allman, M., Balakrishnan, H. and S. Floyd, "Enhancing TCP's [RFC3042] Allman, M., Balakrishnan, H. and S. Floyd, "Enhancing TCP's
Loss Recovery Using Limited Transmit", RFC 3042, January Loss Recovery Using Limited Transmit", RFC 3042, January
2001. 2001.
[RFC3150] Dawkins, S., Montenegro, G., Kojo, M. and V. Magret, "End- [RFC3150] Dawkins, S., Montenegro, G., Kojo, M. and V. Magret, "End-
to-end Performance Implications of Slow Links", RFC 3150, to-end Performance Implications of Slow Links", BCP 0048,
July 2001. July 2001.
[RFC3782] Floyd, S., Henderson, T., and A. Gurtov, "The NewReno [RFC3782] Floyd, S., Henderson, T., and A. Gurtov, "The NewReno
Modification to TCP's Fast Recovery Algorithm", RFC 3782, Modification to TCP's Fast Recovery Algorithm", RFC 3782,
April 2004. April 2004.
[RFC4782] Floyd, S., Allman, M., Jain, A. and P. Sarolahti, "Quick- [RFC4782] Floyd, S., Allman, M., Jain, A. and P. Sarolahti, "Quick-
Start for TCP and IP", RFC 4782, January 2007. Start for TCP and IP", RFC 4782, January 2007.
[RFC6077] Papadimitriou, D., Welzl, M., Scharf, M. and B. Briscoe,
"Open Research Issues in Internet Congestion Control",
section 3.4, RFC 6077, February 2011.
[RJ10] Ramachandran, S. and A. Jain, "Aggregate Statistics of Size [RJ10] Ramachandran, S. and A. Jain, "Aggregate Statistics of Size
Related Metrics of Web Pages metrics", 2010. URL Related Metrics of Web Pages metrics", May 2010. URL
http://code.google.com/speed/articles/web-metrics.html http://code.google.com/speed/articles/web-metrics.html
[Sch08] Scharf, M., "Quick-Start, Jump-Start, and Other Fast [Sch08] Scharf, M., "Quick-Start, Jump-Start, and Other Fast
Startup Approaches", November 17, 2008. URL Startup Approaches", Internet Research Task Force ICCRG,
http://www.ietf.org/old/2009/proceedings/08nov/slides/ November 17, 2008. URL
iccrg-2.pdf http://www.ietf.org/proceedings/73/slides/iccrg-2.pdf
[Sch11] Scharf, M., "Performance and Fairness Evaluation of IW10 [Sch11] Scharf, M., "Performance and Fairness Evaluation of IW10
and Other Fast Startup Schemes", Presented to 80th IRTF and Other Fast Startup Schemes", Internet Research Task
ICCRG working group meeting, Nov. 2010. URL Force ICCRG, March 2011. URL
http://www.ietf.org/proceedings/80/slides/iccrg-1.pdf http://www.ietf.org/proceedings/80/slides/iccrg-1.pdf
[Sch11-1] Scharf, M., "Comparison of end-to-end and network- [Sch11-1] Scharf, M., "Comparison of end-to-end and network-
supported fast startup congestion control schemes", supported fast startup congestion control schemes",
Computer Networks, Feb. 2011. URL Computer Networks, Feb. 2011. URL
http://dx.doi.org/10.1016/j.comnet.2011.02.002 http://dx.doi.org/10.1016/j.comnet.2011.02.002
[SPDY] "SPDY: An experimental protocol for a faster web", URL [SPDY] "SPDY: An experimental protocol for a faster web", URL
http://dev.chromium.org/spdy http://dev.chromium.org/spdy
[Ste08] Sounders S., "Roundup on Parallel Connections", High [Ste08] Sounders S., "Roundup on Parallel Connections", High
Performance Web Sites blog. URL Performance Web Sites blog. March 2008. URL
http://www.stevesouders.com/blog/2008/03/20/roundup-on- http://www.stevesouders.com/blog/2008/03/20/roundup-on-
parallel-connections parallel-connections
[Tou10] Touch, J., "Automating the Initial Window in TCP", [Tou12] Touch, J., "Automating the Initial Window in TCP",
Internet-draft draft-touch-tcpm-automatic-iw-01.txt, work Internet-draft draft-touch-tcpm-automatic-iw-02.txt, work
in progress. in progress, January 2012.
[VH97] Visweswaraiah, V. and J. Heidemann, "Improving Restart of [VH97] Visweswaraiah, V. and J. Heidemann, "Improving Restart of
Idle TCP Connections", Technical Report 97-661, University Idle TCP Connections", Technical Report 97-661, University
of Southern California, November 1997. of Southern California, November 1997.
Appendix A - List of Concerns and Corresponding Test Results
Concerns have been raised since this proposal was first published
based on a set of large scale experiments. To better understand the
impact of a larger initial window 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?
The large scale Internet experiments conducted at Google front-end
infrastructure covered a large portfolio of services beyond web
search. It includes Gmail, Google Maps, Photos, News, Sites,
Images,..., etc, covering 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.
[CW10] contains some result from a testbed study on how short flows
with a larger initial window might affect the throughput
performance of other co-existing, long lived, bulk data transfers.
o Larger bursts from the increase in the initial window cause
significantly more packet drops
All the tests conducted on this subject [Duk10, Sch11, Sch11-1,
CW10] so far have shown only modest increase on packet drops. The
only exception is from the testbed study [CW10] when under
extremely high load and/or simultaneous opens. But under those
conditions both IW=3 and IW=10 suffered very high packet loss rates
though.
o A large initial window may severely impact TCP performance over
highly multiplexed links still common in developing regions
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 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.
Similar phenomenon have also been observed from testbed study
[CW10].
o Why 10 segments?
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 continue to grow.
But a scheme to right size the initial window automatically over
long timescales has yet to be developed.
o Need more thorough analysis of the impact on slow links
Although [Duk10] showed the large initial window reduced the
average latency even for the dialup link class of only 56Kbps in
bandwidth, more studied were needed in order to understand the
effect of IW10 on slow links at the microscopic level. [CW10] was
conducted for this purpose.
Testbeds in [CW10] emulated a 300ms RTT, bottleneck link bandwidth
as low as 64Kbps, and route queue size as low as 40 packets. A
large combination of test parameters were used. Almost all tests
showed varying degree 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 NSC simulations [Sch11, Sch11-1].
o How will the larger initial window affect flows with initial
windows 4KB or less?
Flows with the larger initial window will likely grab more
bandwidth from a bottleneck link when competing against flows with
smaller initial window, 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 < 4KB 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].
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 median 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 IW=10 enabled
short flows to complete sooner, leaving more room for the long-
lived, background flows.
A study using NSC simulator has also concluded that IW=10 works
rather well and is quite fair against IW=3 [Sch11, Sch11-1].
o How will a larger initial window perform over cellular networks?
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.
Author's Addresses Author's Addresses
Jerry Chu Jerry Chu
Google, Inc. Google, Inc.
1600 Amphitheatre Parkway 1600 Amphitheatre Parkway
Mountain View, CA 94043 Mountain View, CA 94043
USA USA
EMail: hkchu@google.com EMail: hkchu@google.com
Nandita Dukkipati Nandita Dukkipati
skipping to change at page 20, line 35 skipping to change at page 22, line 35
USA USA
EMail: ycheng@google.com EMail: ycheng@google.com
Matt Mathis Matt Mathis
Google, Inc. Google, Inc.
1600 Amphitheatre Parkway 1600 Amphitheatre Parkway
Mountain View, CA 94043 Mountain View, CA 94043
USA USA
EMail: mattmathis@google.com EMail: mattmathis@google.com
Acknowledgement Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 76 change blocks. 
238 lines changed or deleted 316 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/