draft-ietf-tcpm-initcwnd-06.txt   draft-ietf-tcpm-initcwnd-07.txt 
Internet Draft J. Chu Internet Draft J. Chu
draft-ietf-tcpm-initcwnd-06.txt N. Dukkipati draft-ietf-tcpm-initcwnd-07.txt N. Dukkipati
Intended status: Experimental Y. Cheng Intended status: Experimental Y. Cheng
Updates: 3390, 5681 M. Mathis M. Mathis
Expiration date: May 2013 Google, Inc. Expiration date: July 2013 Google, Inc.
November 16, 2012 January 28, 2013
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 2, line 27 skipping to change at page 2, line 27
IETF TCP Maintenance and Minor Extensions (TCPM) working group. 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 6
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 . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . . . . . . 14 13. Related Proposals . . . . . . . . . . . . . . . . . . . . . . 14
14. Security Considerations . . . . . . . . . . . . . . . . . . . 14 14. Security Considerations . . . . . . . . . . . . . . . . . . . 14
15. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 14 15. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 15
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
Normative References . . . . . . . . . . . . . . . . . . . . . . 16 Normative References . . . . . . . . . . . . . . . . . . . . . . . 16
Informative References . . . . . . . . . . . . . . . . . . . . . 16 Informative References . . . . . . . . . . . . . . . . . . . . . . 16
Appendix A - List of Concerns and Corresponding Test Results . . 20 Appendix A - List of Concerns and Corresponding Test Results . . . 20
Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . . 23 Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
This document proposes to raise the upper bound on TCP's initial This document proposes to raise the upper bound on TCP's initial
window (IW) to 10 segments (maximum 14600B). It is patterned after window (IW) to 10 segments (maximum 14600B). It is patterned after
and borrows heavily from RFC 3390 [RFC3390] and earlier work in this and borrows heavily from RFC 3390 [RFC3390] and earlier work in this
area. Due to lingering concerns about possible side effects to other area. Due to lingering concerns about possible side effects to other
flows sharing the same network bottleneck, some of the flows sharing the same network bottleneck, some of the
recommendations are conditional on additional monitoring and recommendations are conditional on additional monitoring and
evaluation. evaluation.
skipping to change at page 5, line 33 skipping to change at page 5, line 33
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. If a larger initial window causes harm to any
applications to use fewer concurrent TCP connections. other flows then local application tuning will reveal that fewer
concurrent connections yields better performance for some users. Any
content provider deploying IW10 in conjunction with content
distributed across multiple domains is explicitly encouraged to
perform measurement experiments to detect such problems, and to
consider reducing the number of concurrent connections used to
retrieve their content.
Some implementations advertise small initial receive window (Table 2 Some implementations advertise small initial receive window (Table 2
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
skipping to change at page 14, line 24 skipping to change at page 14, line 29
deterioration of performance, they SHOULD fall back to an initial deterioration of performance, they SHOULD fall back to an initial
window as allowed by RFC 3390 for safety reasons. An increased window as allowed by RFC 3390 for safety reasons. An increased
initial window MUST NOT be turned on by default on systems without initial window MUST NOT be turned on by default on systems without
such monitoring capabilities. 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. Resolution of these experiments and tighter specifications of
the suggestions here might be grounds for a future standards track
document on the same topic.
13. Related Proposals 13. Related Proposals
Two other proposals [All10, Tou12] have been published to raise TCP's Two other proposals [All10, Tou12] have been published to raise TCP's
initial window size over a large timescale. Both aim at reducing the initial window size over a large timescale. Both aim at reducing the
uncertain impact of a larger initial window at an Internet wide uncertain impact of a larger initial window at an Internet wide
scale. Moreover, [Tou12] seeks an algorithm to automate the scale. Moreover, [Tou12] seeks an algorithm to automate the
adjustment of IW safely over long haul period. adjustment of IW safely over long haul period.
Although a modest, static increase of IW to 10 may address the near- Although a modest, static increase of IW to 10 may address the near-
 End of changes. 5 change blocks. 
34 lines changed or deleted 42 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/