draft-ietf-tcpm-initcwnd-03.txt   draft-ietf-tcpm-initcwnd-04.txt 
Internet Draft J. Chu Internet Draft J. Chu
draft-ietf-tcpm-initcwnd-03.txt N. Dukkipati draft-ietf-tcpm-initcwnd-04.txt N. Dukkipati
Intended status: Experimental Y. Cheng Intended status: Experimental Y. Cheng
Updates: 3390, 5681 M. Mathis Updates: 3390, 5681 M. Mathis
Expiration date: August 2012 Google, Inc. Expiration date: December 2012 Google, Inc.
February 26, 2012 June 28, 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 August, 2012. This Internet-Draft will expire on December, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 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
described in the Simplified BSD License. described in the Simplified BSD License.
Abstract Abstract
This document proposes an increase in the permitted TCP initial This document proposes an experiment to increase the permitted TCP
window (IW) from between 2 and 4 segments, as specified in RFC 3390, initial window (IW) from between 2 and 4 segments, as specified in
to 10 segments. It discusses the motivation behind the increase, the RFC 3390, to 10 segments, with a fallback to the existing
advantages and disadvantages of the higher initial window, and recommendation when performance issues are detected. It discusses the
presents results from several large scale experiments showing that motivation behind the increase, the advantages and disadvantages of
the higher initial window improves the overall performance of many the higher initial window, and presents results from several large
web services without risking congestion collapse. The document closes scale experiments showing that the higher initial window improves the
with a discussion of usage and deployment recommended by the IETF TCP overall performance of many web services without resulting in a
Maintenance and Minor Extensions (TCPM) working group. congestion collapse. The document closes with a discussion of usage
and deployment for further experimental purpose recommended by the
IETF TCP 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. TCP Modification . . . . . . . . . . . . . . . . . . . . . . . 4 2. TCP Modification . . . . . . . . . . . . . . . . . . . . . . . 4
3. Implementation Issues . . . . . . . . . . . . . . . . . . . . . 5 3. Implementation Issues . . . . . . . . . . . . . . . . . . . . . 5
4. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Advantages of Larger Initial Windows . . . . . . . . . . . . . 7 5. Advantages of Larger Initial Windows . . . . . . . . . . . . . 7
5.1 Reducing Latency . . . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . 8
5.3 Recovering faster from loss on under-utilized or wireless 5.3 Recovering faster from loss on under-utilized or wireless
links . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . 10 8. Mitigation of Negative Impact . . . . . . . . . . . . . . . . 10
9. Interactions with the Retransmission Timer . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . . . . 11
10.2 The cost . . . . . . . . . . . . . . . . . . . . . . . . 11 10.2 The cost . . . . . . . . . . . . . . . . . . . . . . . . 11
11. Other Studies . . . . . . . . . . . . . . . . . . . . . . . . 12 11. Other Studies . . . . . . . . . . . . . . . . . . . . . . . . 12
12. Usage and Deployment Recommendations . . . . . . . . . . . . 13 12. Usage and Deployment Recommendations . . . . . . . . . . . . 13
13. Related Proposals . . . . . . . . . . . . . . . . . . . . . . 13 13. Related Proposals . . . . . . . . . . . . . . . . . . . . . . 14
14. Security Considerations . . . . . . . . . . . . . . . . . . . 14 14. Security Considerations . . . . . . . . . . . . . . . . . . . 14
15. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 14 15. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 14
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
Normative References . . . . . . . . . . . . . . . . . . . . . . 15 Normative References . . . . . . . . . . . . . . . . . . . . . . 16
Informative References . . . . . . . . . . . . . . . . . . . . . 15 Informative References . . . . . . . . . . . . . . . . . . . . . 16
Appendix A - List of Concerns and Corresponding Test Results . . 19 Appendix A - List of Concerns and Corresponding Test Results . . 21
Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . . 22 Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
This document proposes to update RFC 3390 to raise the upper bound on This document proposes to raise the upper bound on TCP's initial
TCP's initial window (IW) to 10 segments or roughly 15KB. It is window (IW) to 10 segments or roughly 15KB. It is patterned after and
patterned after and borrows heavily from RFC 3390 [RFC3390] and borrows heavily from RFC 3390 [RFC3390] and earlier work in this
earlier work in this area. Due to lingering concerns about possible area. Due to lingering concerns about possible side effects to other
side effects, some of the recommendations are conditional on flows sharing the same network bottleneck, some of the
additional monitoring and evaluation. 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 36 skipping to change at page 3, line 39
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 recommend that all TCP implementations have a settable TCP IW We recommend that all TCP implementations have a settable TCP IW
parameter. As of 2011 an appropriate value for this parameter is 10 parameter as long as there is a reasonable effort to monitor for
segments as long as there is a reasonable effort to monitor for possible interactions with other Internet applications and services
possible interactions with other Internet applications and services. as described in Section 12. Furthermore, Section 10 details why 10
Furthermore, it is understood that the appropriate value for IW is segments may be an appropriate value, and while that value may
likely to continue to rise in the future, but this document does not continue to rise in the future, this document does not include any
include any supporting evidence for larger values of IW. supporting evidence for values of IW larger than 10.
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 the consensus from the TCPM 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 working group on the near-term usage and deployment of IW10 in the
Internet. 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
skipping to change at page 9, line 21 skipping to change at page 9, line 29
connection recovers from the segment drop without a retransmit connection recovers from the segment drop without a retransmit
timeout, and (2) the TCP connection is ultimately limited to a small timeout, and (2) the TCP connection is ultimately limited to a small
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 unlikely the increase by itself 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 the large congestion collapse. This seems to have been confirmed by the large
scale experiments described later. scale web experiments described later.
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 Until this proposal is widely deployed, a fairness issue may exist
between flows adopting a larger initial window vs flows that are between flows adopting a larger initial window vs flows that are
RFC3390-compliant. Although no severe unfairness has been detected on RFC3390-compliant. Although no severe unfairness has been detected on
all the known tests so far, further study on this topic may be all the known tests so far, further study on this topic may be
warranted. 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
skipping to change at page 9, line 50 skipping to change at page 10, line 13
queues (in the order of one second or more) 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 [Get11-1]. The mitigations proposed for the such as Web browsing [Get11-1]. The mitigations proposed for the
broader problem of buffer bloating are also applicable in this case, broader problem of buffer bloating are also applicable in this case,
such as the use of ECN, AQM schemes and traffic classification (QoS). such as the use of ECN, AQM schemes [CoDel] 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.
skipping to change at page 13, line 27 skipping to change at page 13, line 39
Further experiments are required before a larger initial window shall Further experiments are required before a larger initial window shall
be enabled by default in the Internet. The existing measurement be enabled by default in the Internet. The existing measurement
results indicate that this does not cause significant harm to other results indicate that this does not cause significant harm to other
traffic. However, widespread use in the Internet could reveal issues traffic. However, widespread use in the Internet could reveal issues
not known yet, e.g., regarding fairness or impact on latency- not known yet, e.g., regarding fairness or impact on latency-
sensitive traffic such as VoIP. sensitive traffic such as VoIP.
Therefore, special care is needed when using this experimental TCP Therefore, special care is needed when using this experimental TCP
extension, in particular on large-scale systems originating a extension, in particular on large-scale systems originating a
significant amount of Internet traffic. Anyone (stack vendors, significant amount of Internet traffic, or on large numbers of
network administrators, etc.) turning on a larger initial window individual consumer-level systems that have similar aggregate impact.
SHOULD ensure that the performance is monitored before and after that Anyone (stack vendors, network administrators, etc.) turning on a
change. Relevant performance metrics include the percentages of larger initial window SHOULD ensure that the performance is monitored
packet losses or segment retransmissions as well as application-level before and after that change. A key metric to monitor is the rate of
metrics such as data transfer completion times or media quality. Note packet losses, ECN marking, or segment retransmissions during the
that it is important also to take into account hosts that do not initial burst. The sender SHOULD cache such information about
implement a larger initial window. Furthermore, non-TCP traffic (such connection setups using an initial window larger than allowed by RFC
as VoIP) should be monitored as well. If users observe any 3390, and new connections SHOULD fall back to the initial window
significant deterioration of performance, they SHOULD fall back to an allowed by RFC 3390 if there is evidence of performance issues.
initial window as allowed by RFC 3390 for safety reasons. An Further experiments are needed on the design of such a cache and
increased initial window SHOULD NOT be turned on by default on corresponding heuristics.
systems without such monitoring capabilities.
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.
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 MUST NOT be turned on by default on systems without
such monitoring capabilities.
The IETF TCPM working group is very much interested in further The IETF TCPM working group is very much interested in further
reports from experiments with this specification and encourages the reports from experiments with this specification and encourages the
publication of such measurement data. If no significant harm is publication of such measurement data. If no significant harm is
reported, a follow-up document may revisit the question on whether a reported, a follow-up document may revisit the question on whether a
larger initial window can be safely used by default in all Internet larger initial window can be safely used by default in all Internet
hosts. hosts.
13. Related Proposals 13. Related Proposals
skipping to change at page 16, line 13 skipping to change at page 17, line 13
[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
[Chu09] Chu, J., "Tuning TCP Parameters for the 21st Century", [Chu09] Chu, J., "Tuning TCP Parameters for the 21st Century",
Presented to 75th IETF TCPM working group meeting, July Presented to 75th IETF TCPM working group meeting, July
2009. URL http://www.ietf.org/proceedings/75/slides/tcpm- 2009. URL http://www.ietf.org/proceedings/75/slides/tcpm-
1.pdf. 1.pdf.
[CoDel] Nichols, K. and V. Jacobson, "Controlling Queue Delay", ACM
QUEUE, May 6, 2012.
[CW10] Chu, J. and Wang, Y., "A Testbed Study on IW10 vs IW3", [CW10] Chu, J. and Wang, Y., "A Testbed Study on IW10 vs IW3",
Presented to 79th IETF TCPM working group meeting, Nov. Presented to 79th IETF TCPM working group meeting, Nov.
2010. URL http://www.ietf.org/proceedings/79/slides/tcpm- 2010. URL http://www.ietf.org/proceedings/79/slides/tcpm-
0.pdf. 0.pdf.
[DCCM10] Dukkipati, D., Cheng, Y., Chu, J. and M. Mathis, [DCCM10] Dukkipati, D., Cheng, Y., Chu, J. and M. Mathis,
"Increasing TCP initial window", Presented to 78th IRTF "Increasing TCP initial window", Presented to 78th IRTF
ICCRG working group meeting, July 2010. URL ICCRG working group meeting, July 2010. URL
http://www.ietf.org/proceedings/78/slides/iccrg-3.pdf http://www.ietf.org/proceedings/78/slides/iccrg-3.pdf
 End of changes. 15 change blocks. 
51 lines changed or deleted 73 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/