draft-ietf-tcpm-initcwnd-04.txt   draft-ietf-tcpm-initcwnd-05.txt 
Internet Draft J. Chu Internet Draft J. Chu
draft-ietf-tcpm-initcwnd-04.txt N. Dukkipati draft-ietf-tcpm-initcwnd-05.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: December 2012 Google, Inc. Expiration date: April 2013 Google, Inc.
June 28, 2012 October 20, 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 December, 2012. This Internet-Draft will expire on April, 2013.
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
skipping to change at page 3, line 10 skipping to change at page 3, line 10
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 . . 21 Appendix A - List of Concerns and Corresponding Test Results . . 21
Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . . 24 Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . . 24
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 or roughly 15KB. It is patterned after and window (IW) to 10 segments (maximum 14600B). It is patterned after
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.
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.
skipping to change at page 4, line 46 skipping to change at page 4, line 46
"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
initial window is reduced to 1 segment. For this reason, it is initial window is reduced to 1 segment. For this reason, it is
RECOMMENDED that implementations refrain from resetting the initial RECOMMENDED that implementations refrain from resetting the initial
window to 1 segment, unless either there have been multiple SYN or window to 1 segment, unless either there have been more than one SYN
SYN/ACK retransmissions, or true loss detection has been made. or SYN/ACK retransmissions, or true loss detection has been made.
TCP implementations use slow start in as many as three different TCP implementations use slow start in as many as three different
ways: (1) to start a new connection (the initial window); (2) to ways: (1) to start a new connection (the initial window); (2) to
restart transmission after a long idle period (the restart window); restart transmission after a long idle period (the restart window);
and (3) to restart transmission after a retransmit timeout (the loss and (3) to restart transmission after a retransmit timeout (the loss
window). The change specified in this document affects the value of window). The change specified in this document affects the value of
the initial window. Optionally, a TCP MAY set the restart window to the initial window. Optionally, a TCP MAY set the restart window to
the minimum of the value used for the initial window and the current 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 window, (RW) if any packet loss is detected during either the initial window,
or a restart window, and more than 4KB of data is sent. or a restart window, and more than 4KB of data is sent.
Implementations must also follow RFC6298 [RFC6298] in order to avoid
spurious RTO as described in section 9 later.
3. Implementation Issues 3. Implementation Issues
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
skipping to change at page 10, line 38 skipping to change at page 10, line 39
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 6298 [RFC6298] 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.
For a more detailed discussion see RFC3390, section 6.
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
[AKAM10], with a median connection speed of about 1.7Mbps; SlowDC has [AKAM10], with a median connection speed of about 1.7Mbps; SlowDC has
a larger proportion of traffic from slow bandwidth subnets with a larger proportion of traffic from slow bandwidth subnets with
 End of changes. 7 change blocks. 
8 lines changed or deleted 12 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/