summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6928.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6928.txt')
-rw-r--r--doc/rfc/rfc6928.txt1347
1 files changed, 1347 insertions, 0 deletions
diff --git a/doc/rfc/rfc6928.txt b/doc/rfc/rfc6928.txt
new file mode 100644
index 0000000..189dd47
--- /dev/null
+++ b/doc/rfc/rfc6928.txt
@@ -0,0 +1,1347 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) J. Chu
+Request for Comments: 6928 N. Dukkipati
+Category: Experimental Y. Cheng
+ISSN: 2070-1721 M. Mathis
+ Google, Inc.
+ April 2013
+
+
+ Increasing TCP's Initial Window
+
+Abstract
+
+ This document proposes an experiment to increase the permitted TCP
+ initial window (IW) from between 2 and 4 segments, as specified in
+ RFC 3390, to 10 segments with a fallback to the existing
+ recommendation when performance issues are detected. It discusses
+ the motivation behind the increase, the advantages and disadvantages
+ of the higher initial window, and presents results from several
+ large-scale experiments showing that the higher initial window
+ improves the overall performance of many web services without
+ resulting in a congestion collapse. The document closes with a
+ discussion of usage and deployment for further experimental purposes
+ recommended by the IETF TCP Maintenance and Minor Extensions (TCPM)
+ working group.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for examination, experimental implementation, and
+ evaluation.
+
+ This document defines an Experimental Protocol for the Internet
+ community. This document is a product of the Internet Engineering
+ Task Force (IETF). It represents the consensus of the IETF
+ community. It has received public review and has been approved for
+ publication by the Internet Engineering Steering Group (IESG). Not
+ all documents approved by the IESG are a candidate for any level of
+ Internet Standard; see Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6928.
+
+
+
+
+
+
+
+
+
+Chu, et al. Experimental [Page 1]
+
+RFC 6928 Increasing TCP's Initial Window April 2013
+
+
+Copyright Notice
+
+ Copyright (c) 2013 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 1.1. Terminology ................................................4
+ 2. TCP Modification ................................................4
+ 3. Implementation Issues ...........................................5
+ 4. Background ......................................................6
+ 5. Advantages of Larger Initial Windows ............................7
+ 5.1. Reducing Latency ...........................................7
+ 5.2. Keeping Up with the Growth of Web Object Size ..............8
+ 5.3. Recovering Faster from Loss on Under-Utilized or
+ Wireless Links .............................................8
+ 6. Disadvantages of Larger Initial Windows for the Individual ......9
+ 7. Disadvantages of Larger Initial Windows for the Network ........10
+ 8. Mitigation of Negative Impact ..................................11
+ 9. Interactions with the Retransmission Timer .....................11
+ 10. Experimental Results From Large-Scale Cluster Tests ...........11
+ 10.1. The Benefits .............................................11
+ 10.2. The Cost .................................................12
+ 11. Other Studies .................................................13
+ 12. Usage and Deployment Recommendations ..........................14
+ 13. Related Proposals .............................................15
+ 14. Security Considerations .......................................16
+ 15. Conclusion ....................................................16
+ 16. Acknowledgments ...............................................16
+ 17. References ....................................................16
+ 17.1. Normative References .....................................16
+ 17.2. Informative References ...................................17
+ Appendix A. List of Concerns and Corresponding Test Results .......21
+
+
+
+
+
+
+
+Chu, et al. Experimental [Page 2]
+
+RFC 6928 Increasing TCP's Initial Window April 2013
+
+
+1. Introduction
+
+ This document proposes to raise the upper bound on TCP's initial
+ window (IW) to 10 segments (maximum 14600 B). It is patterned after
+ and borrows heavily from RFC 3390 [RFC3390] and earlier work in this
+ area. Due to lingering concerns about possible side effects to other
+ flows sharing the same network bottleneck, some of the
+ recommendations are conditional on additional monitoring and
+ evaluation.
+
+ The primary argument in favor of raising IW follows from the evolving
+ scale of the Internet. Ten segments are likely to fit into queue
+ space available at any broadband access link, even when there are a
+ reasonable number of concurrent connections.
+
+ Lower speed links can be treated with environment-specific
+ configurations, such that they can be protected from being
+ overwhelmed by large initial window bursts without imposing a
+ suboptimal initial window on the rest of the Internet.
+
+ This document reviews the advantages and disadvantages of using a
+ larger initial window and includes summaries of several large-scale
+ experiments showing that an initial window of 10 segments (IW10)
+ provides benefits across the board for a variety of bandwidth (BW),
+ round-trip time (RTT), and bandwidth-delay product (BDP) classes.
+ These results show significant benefits for increasing IW for users
+ at much smaller data rates than had been previously anticipated.
+ However, at initial windows larger than 10, the results are mixed.
+ We believe that these mixed results are not intrinsic but are the
+ consequence of various implementation artifacts, including overly
+ aggressive applications employing many simultaneous connections.
+
+ We recommend that all TCP implementations have a settable TCP IW
+ parameter, as long as there is a reasonable effort to monitor for
+ possible interactions with other Internet applications and services
+ as described in Section 12. Furthermore, Section 10 details why 10
+ segments may be an appropriate value, and while that value may
+ continue to rise in the future, this document does not include any
+ supporting evidence for values of IW larger than 10.
+
+ In addition, we introduce a minor revision to RFC 3390 and RFC 5681
+ [RFC5681] to eliminate resetting the initial window when the SYN or
+ SYN/ACK is lost.
+
+ The document closes with a discussion of the consensus from the TCPM
+ working group on the near-term usage and deployment of IW10 in the
+ Internet.
+
+
+
+
+Chu, et al. Experimental [Page 3]
+
+RFC 6928 Increasing TCP's Initial Window April 2013
+
+
+ A complementary set of slides for this proposal can be found at
+ [CD10].
+
+1.1. Terminology
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [RFC2119].
+
+2. TCP Modification
+
+ This document proposes an increase in the permitted upper bound for
+ TCP's initial window (IW) to 10 segments, depending on the maximum
+ segment size (MSS). This increase is optional: a TCP MAY start with
+ an initial window that is smaller than 10 segments.
+
+ 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
+ RFC 3390 [RFC3390], which specified that the congestion window be
+ initialized between 2 and 4 segments, depending on the MSS.
+
+ This change applies to the initial window of the connection in the
+ first round-trip time (RTT) of data transmission during or following
+ the TCP three-way handshake. Neither the SYN/ACK nor its ACK in the
+ three-way handshake should increase the initial window size.
+
+ 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 states (and RFC 5681 [RFC5681] has similar
+ text):
+
+ If the SYN or SYN/ACK is lost, the initial window used by a sender
+ after a correctly transmitted SYN MUST be one segment consisting
+ of MSS bytes.
+
+ The proposed change to reduce the default retransmission timeout
+ (RTO) to 1 second [RFC6298] increases the chance for spurious SYN or
+ SYN/ACK retransmission, thus unnecessarily penalizing connections
+ with RTT > 1 second if their initial window is reduced to 1 segment.
+ For this reason, it is RECOMMENDED that implementations refrain from
+ resetting the initial window to 1 segment, unless there have been
+ more than one SYN or SYN/ACK retransmissions or true loss detection
+ has been made.
+
+
+
+Chu, et al. Experimental [Page 4]
+
+RFC 6928 Increasing TCP's Initial Window April 2013
+
+
+ TCP implementations use slow start in as many as three different
+ ways: (1) to start a new connection (the initial window); (2) to
+ restart transmission after a long idle period (the restart window);
+ and (3) to restart transmission after a retransmit timeout (the loss
+ window). The change specified in this document affects the value of
+ the initial window. Optionally, a TCP MAY set the restart window to
+ the minimum of the value used for the initial window and the current
+ value of cwnd (in other words, using a larger value for the restart
+ window should never increase the size of cwnd). These changes do NOT
+ change the loss window, which must remain 1 segment of MSS bytes (to
+ permit the lowest possible window size in the case of severe
+ congestion).
+
+ Furthermore, to limit any negative effect that a larger initial
+ window may have on links with limited bandwidth or buffer space,
+ implementations SHOULD fall back to RFC 3390 for the restart window
+ (RW) if any packet loss is detected during either the initial window
+ or a restart window, and more than 4 KB of data is sent.
+ Implementations must also follow RFC 6298 [RFC6298] in order to avoid
+ spurious RTO as described in Section 9.
+
+3. Implementation Issues
+
+ The HTTP 1.1 specification allows only two simultaneous connections
+ per domain, while web browsers open more simultaneous TCP connections
+ [Ste08], partly to circumvent the small initial window in order to
+ speed up the loading of web pages as described above.
+
+ When web browsers open simultaneous TCP connections to the same
+ destination, they are working against TCP's congestion control
+ mechanisms [FF99]. Combining this behavior with larger initial
+ windows further increases the burstiness and unfairness to other
+ traffic in the network. If a larger initial window causes harm to
+ any other flows, then local application tuning will reveal that
+ having fewer concurrent connections yields better performance for
+ some users. Any content provider deploying IW10 in conjunction with
+ content distributed across multiple domains is explicitly encouraged
+ to perform measurement experiments to detect such problems, and to
+ consider reducing the number of concurrent connections used to
+ retrieve their content.
+
+ Some implementations advertise a small initial receive window (Table
+ 2 in [Duk10]), effectively limiting how much window a remote host may
+ use. In order to realize the full benefit of the large initial
+ window, implementations are encouraged to advertise an initial
+ receive window of at least 10 segments, except for the circumstances
+ where a larger initial window is deemed harmful. (See Section 8
+ below.)
+
+
+
+Chu, et al. Experimental [Page 5]
+
+RFC 6928 Increasing TCP's Initial Window April 2013
+
+
+ The TCP Selective Acknowledgment (SACK) option [RFC2018] was thought
+ to be required in order for the larger initial window to perform
+ well. But measurements from both a testbed and live tests showed that
+ IW=10 without the SACK option outperforms IW=3 with the SACK option
+ [CW10].
+
+4. Background
+
+ The TCP congestion window was introduced as part of the congestion
+ control algorithm by Van Jacobson in 1988 [Jac88]. The initial value
+ of one segment was used as the starting point for newly established
+ connections to probe the available bandwidth on the network.
+
+ Today's Internet is dominated by web traffic running on top of short-
+ lived TCP connections [IOR2009]. The relatively small initial window
+ has become a limiting factor for the performance of many web
+ applications.
+
+ The global Internet has continued to grow, both in speed and
+ penetration. According to the latest report from Akamai [AKAM10],
+ the global broadband (> 2 Mbps) adoption has surpassed 50%,
+ propelling the average connection speed to reach 1.7 Mbps, while the
+ narrowband (< 256 Kbps) usage has dropped to 5%. In contrast, TCP's
+ initial window has remained 4 KB for a decade [RFC2414],
+ corresponding to a bandwidth utilization of less than 200 Kbps per
+ connection, assuming an RTT of 200 ms.
+
+ A large proportion of flows on the Internet are short web
+ transactions over TCP and complete before exiting TCP slow start.
+ Speeding up the TCP flow startup phase, including circumventing the
+ initial window limit, has been an area of active research (see
+ [Sch08] and Section 3.4 of [RFC6077]). Numerous proposals exist
+ [LAJW07] [RFC4782] [PRAKS02] [PK98]. Some require router support
+ [RFC4782] [PK98], hence are not practical for the public Internet.
+ Others suggested bold, but often radical ideas, likely requiring more
+ years of research before standardization and deployment.
+
+ In the mean time, applications have responded to TCP's "slow" start.
+ Web sites use multiple subdomains [Bel10] to circumvent HTTP 1.1
+ regulation on two connections per physical host [RFC2616]. As of
+ today, major web browsers open multiple connections to the same site
+ (up to six connections per domain [Ste08] and the number is growing).
+ This trend is to remedy HTTP serialized download to achieve
+ parallelism and higher performance. But it also implies that today
+ most access links are severely under-utilized, hence having multiple
+ TCP connections improves performance most of the time. While raising
+ the initial congestion window may cause congestion for certain users
+ of these browsers, we argue that the browsers and other application
+
+
+
+Chu, et al. Experimental [Page 6]
+
+RFC 6928 Increasing TCP's Initial Window April 2013
+
+
+ need to respect HTTP 1.1 regulation and stop increasing the number of
+ simultaneous TCP connections. We believe a modest increase of the
+ initial window will help to stop this trend and provide the best
+ interim solution to improve overall user performance and reduce the
+ server, client, and network load.
+
+ Note that persistent connections and pipelining are designed to
+ address some of the above issues with HTTP [RFC2616]. Their presence
+ does not diminish the need for a larger initial window, e.g., data
+ from the Chrome browser shows that 35% of HTTP requests are made on
+ new TCP connections. Our test data also shows significant latency
+ reduction with the large initial window even in conjunction with
+ these two HTTP features [Duk10].
+
+ Also note that packet pacing has been suggested as a possible
+ mechanism to avoid large bursts and their associated harm [VH97].
+ Pacing is not required in this proposal due to a strong preference
+ for a simple solution. We suspect for packet bursts of a moderate
+ size, packet pacing will not be necessary. This seems to be
+ confirmed by our test results.
+
+ More discussion of the increase in initial window, including the
+ choice of 10 segments, can be found in [Duk10] and [CD10].
+
+5. Advantages of Larger Initial Windows
+
+5.1 Reducing Latency
+
+ An increase of the initial window from 3 segments to 10 segments
+ reduces the total transfer time for data sets greater than 4 KB by up
+ to 4 round trips.
+
+ The table below compares the number of round trips between IW=3 and
+ IW=10 for different transfer sizes, assuming infinite bandwidth, no
+ packet loss, and the standard delayed ACKs with large delayed-ACK
+ timer.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chu, et al. Experimental [Page 7]
+
+RFC 6928 Increasing TCP's Initial Window April 2013
+
+
+ ---------------------------------------
+ | total segments | IW=3 | IW=10 |
+ ---------------------------------------
+ | 3 | 1 | 1 |
+ | 6 | 2 | 1 |
+ | 10 | 3 | 1 |
+ | 12 | 3 | 2 |
+ | 21 | 4 | 2 |
+ | 25 | 5 | 2 |
+ | 33 | 5 | 3 |
+ | 46 | 6 | 3 |
+ | 51 | 6 | 4 |
+ | 78 | 7 | 4 |
+ | 79 | 8 | 4 |
+ | 120 | 8 | 5 |
+ | 127 | 9 | 5 |
+ ---------------------------------------
+
+ For example, with the larger initial window, a transfer of 32
+ segments of data will require only 2 rather than 5 round trips to
+ complete.
+
+5.2. Keeping Up with the Growth of Web Object Size
+
+ RFC 3390 stated that the main motivation for increasing the initial
+ window to 4 KB was to speed up connections that only transmit a small
+ amount of data, e.g., email and web. The majority of transfers back
+ then were less than 4 KB and could be completed in a single RTT
+ [All00].
+
+ Since RFC 3390 was published, web objects have gotten significantly
+ larger [Chu09] [RJ10]. Today only a small percentage of web objects
+ (e.g., 10% of Google's search responses) can fit in the 4 KB initial
+ window. The average HTTP response size of gmail.com, a highly
+ scripted web site, is 8 KB (Figure 1 in [Duk10]). The average web
+ page, including all static and dynamic scripted web objects on the
+ page, has seen even greater growth in size [RJ10]. HTTP pipelining
+ [RFC2616] and new web transport protocols such as SPDY [SPDY] allow
+ multiple web objects to be sent in a single transaction, potentially
+ benefiting from an even larger initial window in order to transfer an
+ entire web page in a small number of round trips.
+
+5.3. Recovering Faster from Loss on Under-Utilized or Wireless Links
+
+ A greater-than-3-segment initial window increases the chance to
+ recover packet loss through Fast Retransmit rather than the lengthy
+ initial RTO [RFC5681]. This is because the fast retransmit algorithm
+ requires three duplicate ACKs as an indication that a segment has
+
+
+
+Chu, et al. Experimental [Page 8]
+
+RFC 6928 Increasing TCP's Initial Window April 2013
+
+
+ been lost rather than reordered. While newer loss recovery
+ techniques such as Limited Transmit [RFC3042] and Early Retransmit
+ [RFC5827] have been proposed to help speeding up loss recovery from a
+ smaller window, both algorithms can still benefit from the larger
+ initial window because of a better chance to receive more ACKs.
+
+6. Disadvantages of Larger Initial Windows for the Individual
+ Connection
+
+ The larger bursts from an increase in the initial window may cause
+ buffer overrun and packet drop in routers with small buffers, or
+ routers experiencing congestion. This could result in unnecessary
+ retransmit timeouts. For a large-window connection that is able to
+ recover without a retransmit timeout, this could result in an
+ unnecessarily early transition from the slow-start to the congestion-
+ avoidance phase of the window increase algorithm.
+
+ Premature segment drops are unlikely to occur in uncongested networks
+ with sufficient buffering, or in moderately congested networks where
+ the congested router uses active queue management (such as Random
+ Early Detection [FJ93] [RFC2309] [RFC3150]).
+
+ Insufficient buffering is more likely to exist in the access routers
+ connecting slower links. A recent study of access router buffer size
+ [DGHS07] reveals the majority of access routers provision enough
+ buffer for 130 ms or longer, sufficient to cover a burst of more than
+ 10 packets at 1 Mbps speed, but possibly not sufficient for browsers
+ opening simultaneous connections.
+
+ A testbed study [CW10] on the effect of the larger initial window
+ with five simultaneously opened connections revealed that, even with
+ limited buffer size on slow links, IW=10 still reduced the total
+ latency of web transactions, although at the cost of higher packet
+ drop rates as compared to IW=3.
+
+ Some TCP connections will receive better performance with the larger
+ initial window, even if the burstiness of the initial window results
+ in premature segment drops. This will be true if (1) the TCP
+ connection recovers from the segment drop without a retransmit
+ timeout, and (2) the TCP connection is ultimately limited to a small
+ congestion window by either network congestion or by the receiver's
+ advertised window.
+
+
+
+
+
+
+
+
+
+Chu, et al. Experimental [Page 9]
+
+RFC 6928 Increasing TCP's Initial Window April 2013
+
+
+7. Disadvantages of Larger Initial Windows for the Network
+
+ An increase in the initial window may increase congestion in a
+ network. However, since the increase is one time only (at the
+ beginning of a connection), and the rest of TCP's congestion backoff
+ mechanism remains in place, it's unlikely the increase by itself will
+ render a network in a persistent state of congestion, or even
+ congestion collapse. This seems to have been confirmed by the large-
+ scale web experiments described later.
+
+ It should be noted that the above may not hold if applications open a
+ large number of simultaneous connections.
+
+ Until this proposal is widely deployed, a fairness issue may exist
+ between flows adopting a larger initial window vs. flows that are
+ compliant with RFC 3390. Although no severe unfairness has been
+ detected on all the known tests so far, further study on this topic
+ may be warranted.
+
+ Some of the discussions from RFC 3390 are still valid for IW=10.
+
+ Moreover, it is worth noting that although TCP NewReno increases the
+ chance of duplicate segments when trying to recover multiple packet
+ losses from a large window, the wide support of the TCP Selective
+ Acknowledgment (SACK) option [RFC2018] in all major OSes today should
+ keep the volume of duplicate segments in check.
+
+ Recent measurements [Get11] provide evidence of extremely large
+ queues (in the order of one second or more) at access networks of the
+ Internet. While a significant part of the buffer bloat is
+ contributed by large downloads/uploads such as video files, emails
+ with large attachments, backups and download of movies to disk, some
+ of the problem is also caused by web browsing of image-heavy sites
+ [Get11]. This queuing delay is generally considered harmful for
+ responsiveness of latency-sensitive traffic such as DNS queries,
+ Address Resolution Protocol (ARP), DHCP, Voice over IP (VoIP), and
+ gaming. IW=10 can exacerbate this problem when doing short
+ downloads, such as web browsing [Get11-1]. The mitigations proposed
+ for the broader problem of buffer bloating are also applicable in
+ this case, such as the use of Explicit Congestion Notification (ECN),
+ Active Queue Management (AQM) schemes [CoDel], and traffic
+ classification (QoS).
+
+
+
+
+
+
+
+
+
+Chu, et al. Experimental [Page 10]
+
+RFC 6928 Increasing TCP's Initial Window April 2013
+
+
+8. Mitigation of Negative Impact
+
+ Much of the negative impact from an increase in the initial window is
+ likely to be felt by users behind slow links with limited buffers.
+ The negative impact can be mitigated by hosts directly connected to a
+ low-speed link advertising an initial receive window smaller than 10
+ segments. This can be achieved either through manual configuration
+ by the users or through the host stack auto-detecting the low-
+ bandwidth links.
+
+ Additional suggestions to improve the end-to-end performance of slow
+ links can be found in RFC 3150 [RFC3150].
+
+9. Interactions with the Retransmission Timer
+
+ A large initial window increases the chance of spurious RTO on a low-
+ bandwidth path, because the packet transmission time will dominate
+ the round-trip time. To minimize spurious retransmissions,
+ implementations MUST follow RFC 6298 [RFC6298] to restart the
+ retransmission timer with the current value of RTO for each ACK
+ received that acknowledges new data.
+
+ For a more detailed discussion, see RFC 3390, Section 6.
+
+10. Experimental Results From Large-Scale Cluster Tests
+
+ In this section, we summarize our findings from large-scale Internet
+ experiments with an initial window of 10 segments conducted via
+ Google's front-end infrastructure serving a diverse set of
+ applications. We present results from two data centers, each chosen
+ because of the specific characteristics of subnets served: AvgDC has
+ connection bandwidths closer to the worldwide average reported in
+ [AKAM10], with a median connection speed of about 1.7 Mbps; SlowDC
+ has a larger proportion of traffic from slow-bandwidth subnets with
+ nearly 20% of traffic from connections below 100 Kbps; and a third
+ was below 256 Kbps.
+
+ Guided by measurements data, we answer two key questions: what is the
+ latency benefit when TCP connections start with a higher initial
+ window, and on the flip side, what is the cost?
+
+10.1. The Benefits
+
+ The average web search latency improvement over all responses in
+ AvgDC is 11.7% (68 ms) and 8.7% (72 ms) in SlowDC. We further
+ analyzed the data based on traffic characteristics and subnet
+ properties such as bandwidth (BW), round-trip time (RTT), and
+ bandwidth-delay product (BDP). The average response latency improved
+
+
+
+Chu, et al. Experimental [Page 11]
+
+RFC 6928 Increasing TCP's Initial Window April 2013
+
+
+ across the board for a variety of subnets with the largest benefits
+ of over 20% from high RTT and high BDP networks, wherein most
+ responses can fit within the pipe. Correspondingly, responses from
+ low RTT paths experienced the smallest improvements -- about 5%.
+
+ Contrary to what we expected, responses from low-bandwidth subnets
+ experienced the best latency improvements (between 10-20%) in the
+ 0-56 Kbps and 56-256 Kbps buckets. We speculate low-BW networks
+ observe improved latency for two plausible reasons: 1) fewer slow-
+ start rounds: unlike many large-BW networks, low-BW subnets with
+ dial-up modems have inherently large RTTs; and 2) faster loss
+ recovery: an initial window larger than 3 segments increases the
+ chances of a lost packet to be recovered through Fast Retransmit as
+ opposed to a lengthy RTO.
+
+ Responses of different sizes benefited to varying degrees; those
+ larger than 3 segments naturally demonstrated larger improvements,
+ because they finished in fewer rounds in slow start as compared to
+ the baseline. In our experiments, response sizes less than or equal
+ to 3 segments also demonstrated small latency benefits.
+
+ To find out how individual subnets performed, we analyzed average
+ latency at a /24 subnet level (an approximation to a user base that
+ is offered similar set of services by a common ISP). We find that,
+ even at the subnet granularity, latency improved at all quantiles
+ ranging from 5-11%.
+
+10.2. The Cost
+
+ To quantify the cost of raising the initial window, we analyzed the
+ data specifically for subnets with low bandwidth and BDP,
+ retransmission rates for different kinds of applications, as well as
+ latency for applications operating with multiple concurrent TCP
+ connections. From our measurements, we found no evidence of negative
+ latency impacts that correlate to BW or BDP alone, but in fact both
+ kinds of subnets demonstrated latency improvements across averages
+ and quantiles.
+
+ As expected, the retransmission rate increased modestly when
+ operating with larger initial congestion window. The overall
+ increase in AvgDC is 0.3% (from 1.98% to 2.29%) and in SlowDC is 0.7%
+ (from 3.54% to 4.21%). In our investigation, with the exception of
+ one application, the larger window resulted in a retransmission
+ increase of less than 0.5% for services in the AvgDC. The exception
+ is the Maps application that operates with multiple concurrent TCP
+ connections, which increased its retransmission rate by 0.9% in AvgDC
+ and 1.85% in SlowDC (from 3.94% to 5.79%).
+
+
+
+
+Chu, et al. Experimental [Page 12]
+
+RFC 6928 Increasing TCP's Initial Window April 2013
+
+
+ In our experiments, the percentage of traffic experiencing
+ retransmissions did not increase significantly, e.g., 90% of web
+ search and maps experienced zero retransmission in SlowDC
+ (percentages are higher for AvgDC); a break up of retransmissions by
+ percentiles indicate that most increases come from the portion of
+ traffic already experiencing retransmissions in the baseline with
+ initial window of 3 segments.
+
+ One of the worst-case scenarios where latency can be adversely
+ impacted due to bottleneck buffer overflow is represented by traffic
+ patterns from applications using multiple concurrent TCP connections,
+ all operating with a large initial window. Our investigation shows
+ that such a traffic pattern has not been a problem in AvgDC where all
+ these applications, specifically maps and image thumbnails,
+ demonstrated improved latencies varying from 2-20%. In the case of
+ SlowDC, while these applications continued showing a latency
+ improvement in the mean, their latencies in higher quantiles (96 and
+ above for maps) indicated instances where latency with larger window
+ is worse than the baseline, e.g., the 99% latency for maps has
+ increased by 2.3% (80 ms) when compared to the baseline. There is no
+ evidence from our measurements that such a cost on latency is a
+ result of subnet bandwidth alone. Although we have no way of knowing
+ from our data, we conjecture that the amount of buffering at
+ bottleneck links plays a key role in the performance of these
+ applications.
+
+ Further details on our experiments and analysis can be found in
+ [Duk10] and [DCCM10].
+
+11. Other Studies
+
+ Besides the large-scale Internet experiments described above, a
+ number of other studies have been conducted on the effects of IW10 in
+ various environments. These tests were summarized below, with more
+ discussion in Appendix A.
+
+ A complete list of tests conducted, with their results and related
+ studies, can be found at the [IW10] link.
+
+ 1. [Sch08] described an earlier evaluation of various Fast Startup
+ approaches, including the "Initial-Start" of 10 MSS.
+
+ 2. [DCCM10] presented the result from Google's large-scale IW10
+ experiments, with a focus on areas with highly multiplexed links
+ or limited broadband deployment such as Africa and South America.
+
+
+
+
+
+
+Chu, et al. Experimental [Page 13]
+
+RFC 6928 Increasing TCP's Initial Window April 2013
+
+
+ 3. [CW10] contained a testbed study on IW10 performance over slow
+ links. It also studied how short flows with a larger initial
+ window might affect the throughput performance of other
+ coexisting, long-lived, bulk data transfers.
+
+ 4. [Sch11] compared IW10 against a number of other fast startup
+ schemes, and concluded that IW10 works rather well and is also
+ quite fair.
+
+ 5. [JNDK10] and later [JNDK10-1] studied the effect of IW10 over
+ cellular networks.
+
+ 6. [AERG11] studied the effect of larger sizes of initial congestion
+ windows, among other things, on end users' page load time from
+ Yahoo!'s Content Delivery Network.
+
+12. Usage and Deployment Recommendations
+
+ 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.
+
+ Therefore, special care is needed when using this experimental TCP
+ extension, in particular on large-scale systems originating a
+ significant amount of Internet traffic or on large numbers of
+ individual consumer-level systems that have similar aggregate impact.
+ Anyone (stack vendors, network administrators, etc.) turning on a
+ larger initial window SHOULD ensure that the performance is monitored
+ before and after that change. Key metrics to monitor are the rate of
+ packet losses, ECN marking, and segment retransmissions during the
+ initial burst. The sender SHOULD cache such information about
+ connection setups using an initial window larger than allowed by RFC
+ 3390, and new connections SHOULD fall back to the initial window
+ allowed by RFC 3390 if there is evidence of performance issues.
+ Further experiments are needed on the design of such a cache and
+ corresponding heuristics.
+
+ 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, any deployment of IW10 should
+ be aware that there are potential side effects to real-time traffic
+
+
+
+Chu, et al. Experimental [Page 14]
+
+RFC 6928 Increasing TCP's Initial Window April 2013
+
+
+ (such as VoIP). If users observe any significant deterioration of
+ performance, they SHOULD fall back to an initial window as allowed by
+ RFC 3390 for safety reasons. An increased initial window MUST NOT be
+ turned on by default on systems without such monitoring capabilities.
+
+ The IETF TCPM working group is very much interested in further
+ reports from experiments with this specification and encourages the
+ publication of such measurement data. By now, there are no adequate
+ studies available that either prove or do not prove the impact of
+ IW10 to real-time traffic. Further experimentation in this direction
+ is encouraged.
+
+ If no significant harm is reported, a follow-up document may revisit
+ the question on whether a larger initial window can be safely used by
+ default in all Internet hosts. Resolution of these experiments and
+ tighter specifications of the suggestions here might be grounds for a
+ future Standards Track document on the same topic.
+
+ It is recognized that if IW10 is causing harm to other traffic, that
+ this may not be readily apparent to the software on the hosts using
+ IW10. In some cases, a local system or network administrator may be
+ able to detect this and to selectively disable IW10. In the general
+ case, however, since the harm may occur on a remote network to other
+ cross-traffic, there may be no good way at all for this to be
+ detected or corrected. Current experience and analysis does not
+ indicate whether this is a real issue, beyond a hypothetical one. As
+ use of IW10 becomes more prevalent, monitoring and analysis of flows
+ throughout the network will be needed to assess the impact across the
+ spectrum of scenarios found on the real Internet.
+
+13. Related Proposals
+
+ Two other proposals [All10] [Tou12] have been published to raise
+ TCP's initial window size over a large timescale. Both aim at
+ reducing the uncertain impact of a larger initial window at an
+ Internet-wide scale. Moreover, [Tou12] seeks an algorithm to
+ automate the adjustment of IW safely over a long period.
+
+ Although a modest, static increase of IW to 10 may address the near-
+ term need for better web performance, much work is needed from the
+ TCP research community to find a long-term solution to the TCP flow
+ startup problem.
+
+
+
+
+
+
+
+
+
+Chu, et al. Experimental [Page 15]
+
+RFC 6928 Increasing TCP's Initial Window April 2013
+
+
+14. Security Considerations
+
+ This document discusses the initial congestion window permitted for
+ TCP connections. Although changing this value may cause more packet
+ loss, it is highly unlikely to lead to a persistent state of network
+ congestion or even a congestion collapse. Hence, it does not raise
+ any known new security issues with TCP.
+
+15. Conclusion
+
+ This document suggests a simple change to TCP that will reduce the
+ application latency over short-lived TCP connections or links with
+ long RTTs (saving several RTTs during the initial slow-start phase)
+ with little or no negative impact over other flows. Extensive tests
+ have been conducted through both testbeds and large data centers with
+ most results showing improved latency with only a small increase in
+ the packet retransmission rate. Based on these results, we believe a
+ modest increase of IW to 10 is the best solution for the near-term
+ deployment, while scaling IW over the long run remains a challenge
+ for the TCP research community.
+
+16. Acknowledgments
+
+ Many people at Google have helped to make the set of large-scale
+ tests possible. We would especially like to acknowledge Amit
+ Agarwal, Tom Herbert, Arvind Jain, and Tiziana Refice for their major
+ contributions.
+
+17. References
+
+17.1. Normative References
+
+ [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
+ Selective Acknowledgment Options", RFC 2018, October 1996.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
+ Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
+ Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
+
+ [RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's
+ Initial Window", RFC 3390, October 2002.
+
+ [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
+ Control", RFC 5681, September 2009.
+
+
+
+
+Chu, et al. Experimental [Page 16]
+
+RFC 6928 Increasing TCP's Initial Window April 2013
+
+
+ [RFC5827] Allman, M., Avrachenkov, K., Ayesta, U., Blanton, J., and
+ P. Hurtig, "Early Retransmit for TCP and Stream Control
+ Transmission Protocol (SCTP)", RFC 5827, May 2010.
+
+ [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent,
+ "Computing TCP's Retransmission Timer", RFC 6298, June
+ 2011.
+
+17.2. Informative References
+
+ [AKAM10] Akamai Technologies, Inc., "The State of the Internet, 3rd
+ Quarter 2009", January 2010, <http://www.akamai.com/html/
+ about/press/releases/2010/press_011310_1.html>.
+
+ [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",
+ ACM Computer Communication Review, 30(5), October 2000.
+
+ [All10] Allman, M., "Initial Congestion Window Specification",
+ Work in Progress, November 2010.
+
+ [Bel10] Belshe, M., "A Client-Side Argument For Changing TCP Slow
+ Start", January 2010,
+ <http://sites.google.com/a/chromium.org/dev/spdy/
+ An_Argument_For_Changing_TCP_Slow_Start.pdf>.
+
+ [CD10] Chu, J. and N. Dukkipati, "Increasing TCP's Initial
+ Window", presented to the IRTF ICCRG and IETF TCPM working
+ group meetings, IETF 77, March 2010, <http://www.ietf.org/
+ proceedings/77/slides/tcpm-4.pdf>.
+
+ [Chu09] Chu, J., "Tuning TCP Parameters for the 21st Century",
+ presented to TCPM working group meeting, IETF 75, July
+ 2009. <http://www.ietf.org/proceedings/75/slides/tcpm-1>.
+
+ [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",
+ presented to the TCPM working group meeting, IETF 79,
+ November 2010,
+ <http://www.ietf.org/proceedings/79/slides/tcpm-0>.
+
+
+
+
+
+
+Chu, et al. Experimental [Page 17]
+
+RFC 6928 Increasing TCP's Initial Window April 2013
+
+
+ [DCCM10] Dukkipati, D., Cheng, Y., Chu, J., and M. Mathis,
+ "Increasing TCP initial window", presented to the IRTF
+ ICCRG meeting, IETF 78, July 2010,
+ <http://www.ietf.org/proceedings/78/slides/iccrg-3.pdf>.
+
+ [DGHS07] Dischinger, M., Gummadi, K., Haeberlen, A., and S. Saroiu,
+ "Characterizing Residential Broadband Networks", Internet
+ Measurement Conference, October 24-26, 2007.
+
+ [Duk10] Dukkipati, N., Refice, T., Cheng, Y., Chu, J., Sutin, N.,
+ Agarwal, A., Herbert, T., and J. Arvind, "An Argument for
+ Increasing TCP's Initial Congestion Window", ACM SIGCOMM
+ Computer Communications Review, vol. 40 (2010), pp. 27-33.
+ July 2010.
+
+ [FF99] Floyd, S., and K. Fall, "Promoting the Use of End-to-End
+ Congestion Control in the Internet", IEEE/ACM Transactions
+ on Networking, August 1999.
+
+ [FJ93] Floyd, S. and V. Jacobson, "Random Early Detection
+ gateways for Congestion Avoidance", IEEE/ACM Transactions
+ on Networking, V.1 N.4, August 1993, p. 397-413.
+
+ [Get11] Gettys, J., "Bufferbloat: Dark buffers in the Internet",
+ presented to the TSV Area meeting, IETF 80, March 2011,
+ <http://www.ietf.org/proceedings/80/slides/tsvarea-1.pdf>.
+
+ [Get11-1] Gettys, J., "IW10 Considered Harmful", Work in Progress,
+ August 2011.
+
+ [IOR2009] Labovitz, C., Iekel-Johnson, S., McPherson, D., Oberheide,
+ J. Jahanian, F., and M. Karir, "Atlas Internet Observatory
+ 2009 Annual Report", 47th NANOG Conference, October 2009.
+
+ [IW10] "TCP IW10 links", January 2012,
+ <http://code.google.com/speed/protocols/tcpm-IW10.html>.
+
+ [Jac88] Jacobson, V., "Congestion Avoidance and Control", Computer
+ Communication Review, vol. 18, no. 4, pp. 314-329, Aug.
+ 1988.
+
+ [JNDK10] Jarvinen, I., Nyrhinen. A., Ding, A., and M. Kojo, "A
+ Simulation Study on Increasing TCP's IW", presented to the
+ IRTF ICCRG meeting, IETF 78, July 2010,
+ <http://www.ietf.org/proceedings/78/slides/iccrg-7.pdf>.
+
+
+
+
+
+
+Chu, et al. Experimental [Page 18]
+
+RFC 6928 Increasing TCP's Initial Window April 2013
+
+
+ [JNDK10-1] Jarvinen, I., Nyrhinen. A., Ding, A., and M. Kojo, "Effect
+ of IW and Initial RTO changes", presented to the TCPM
+ working group meeting, IETF 79, November 2010,
+ <http://www.ietf.org/proceedings/79/slides/tcpm-1.pdf>.
+
+ [LAJW07] Liu, D., Allman, M., Jin, S., and L. Wang, "Congestion
+ Control Without a Startup Phase", Protocols for Fast, Long
+ Distance Networks (PFLDnet) Workshop, February 2007,
+ <http://www.icir.org/mallman/papers/
+ jumpstart-pfldnet07.pdf>.
+
+ [PK98] Padmanabhan V.N. and R. Katz, "TCP Fast Start: A technique
+ for speeding up web transfers", in Proceedings of IEEE
+ Globecom '98 Internet Mini-Conference, 1998.
+
+ [PRAKS02] Partridge, C., Rockwell, D., Allman, M., Krishnan, R., and
+ J. Sterbenz, "A Swifter Start for TCP", Technical Report
+ No. 8339, BBN Technologies, March 2002.
+
+ [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering,
+ S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G.,
+ Partridge, C., Peterson, L., Ramakrishnan, K., Shenker,
+ S., Wroclawski, J., and L. Zhang, "Recommendations on
+ Queue Management and Congestion Avoidance in the
+ Internet", RFC 2309, April 1998.
+
+ [RFC2414] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's
+ Initial Window", RFC 2414, September 1998.
+
+ [RFC3042] Allman, M., Balakrishnan, H., and S. Floyd, "Enhancing
+ TCP's Loss Recovery Using Limited Transmit", RFC 3042,
+ January 2001.
+
+ [RFC3150] Dawkins, S., Montenegro, G., Kojo, M., and V. Magret,
+ "End-to-end Performance Implications of Slow Links", BCP
+ 48, RFC 3150, July 2001.
+
+ [RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick-
+ Start for TCP and IP", RFC 4782, January 2007.
+
+ [RFC6077] Papadimitriou, D., Ed., Welzl, M., Scharf, M., and B.
+ Briscoe, "Open Research Issues in Internet Congestion
+ Control", RFC 6077, February 2011.
+
+ [RJ10] Ramachandran, S. and A. Jain, "Aggregate Statistics of
+ Size Related Metrics of Web Pages metrics", May 2010,
+ <http://code.google.com/speed/articles/web-metrics.html>.
+
+
+
+
+Chu, et al. Experimental [Page 19]
+
+RFC 6928 Increasing TCP's Initial Window April 2013
+
+
+ [Sch08] Scharf, M., "Quick-Start, Jump-Start, and Other Fast
+ Startup Approaches", presented to the IRTF ICCRG meeting,
+ IETF 73, November 2008,
+ <http://www.ietf.org/proceedings/73/slides/iccrg-2.pdf>.
+
+ [Sch11] Scharf, M., "Performance and Fairness Evaluation of IW10
+ and Other Fast Startup Schemes", presented to the IRTF
+ ICCRG meeting, IETF 80, March 2011,
+ <http://www.ietf.org/proceedings/80/slides/iccrg-1.pdf>.
+
+ [Sch11-1] Scharf, M., "Comparison of end-to-end and network-
+ supported fast startup congestion control schemes",
+ Computer Networks, Feb. 2011,
+ <http://dx.doi.org/10.1016/j.comnet.2011.02.002>.
+
+ [SPDY] "SPDY: An experimental protocol for a faster web",
+ <http://dev.chromium.org/spdy>.
+
+ [Ste08] Sounders S., "Roundup on Parallel Connections", High
+ Performance Web Sites blog, March 2008,
+ <http://www.stevesouders.com/blog/2008/03/20/
+ roundup-on-parallel-connections>.
+
+ [Tou12] Touch, J., "Automating the Initial Window in TCP", Work in
+ Progress, July 2012.
+
+ [VH97] Visweswaraiah, V. and J. Heidemann, "Improving Restart of
+ Idle TCP Connections", Technical Report 97-661, University
+ of Southern California, November 1997.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chu, et al. Experimental [Page 20]
+
+RFC 6928 Increasing TCP's Initial Window April 2013
+
+
+Appendix A. List of Concerns and Corresponding Test Results
+
+ Concerns have been raised since the initial draft of this document
+ was posted, based on a set of large-scale experiments. To better
+ understand the impact of a larger initial window and in order to
+ confirm or dismiss these concerns, additional tests have been
+ conducted using either large-scale clusters, simulations, or real
+ testbeds. The following attempts to compile the list of concerns and
+ summarize findings from relevant tests.
+
+ o How complete are various tests in covering many different traffic
+ patterns?
+
+ The large-scale Internet experiments conducted at Google's front-
+ end infrastructure covered a large portfolio of services beyond
+ web search. It included Gmail, Google Maps, Photos, News, Sites,
+ Images, etc., and covered a wide variety of traffic sizes and
+ patterns. One notable exception is YouTube, because we don't
+ think the large initial window will have much material impact,
+ either positive or negative, on bulk data services.
+
+ [CW10] contains some results from a testbed study on how short
+ flows with a larger initial window might affect the throughput
+ performance of other coexisting, long-lived, bulk data transfers.
+
+ 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 a modest increase of packet drops.
+ The only exception is from the testbed study [CW10] under
+ extremely high load and/or simultaneous opens. But under those
+ conditions, both IW=3 and IW=10 suffered very high packet loss
+ rates.
+
+ 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 a small increase in the retransmission rate. It seems
+ that the round-trip savings from a larger initial window more than
+ make up the time spent on recovering more lost packets.
+
+ Similar phenomena have also been observed from the testbed study
+ [CW10].
+
+
+
+Chu, et al. Experimental [Page 21]
+
+RFC 6928 Increasing TCP's Initial Window April 2013
+
+
+ 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 continues to
+ grow. But a scheme to "right size" the initial window
+ automatically over long timescales has yet to be developed.
+
+ o More thorough analysis of the impact on slow links is needed.
+
+ Although [Duk10] showed the large initial window reduced the
+ average latency even for the dialup link class of only 56 Kbps in
+ bandwidth, more studies were needed in order to understand the
+ effect of IW10 on slow links at the microscopic level. [CW10] was
+ conducted for this purpose.
+
+ Testbeds in [CW10] emulated a 300 ms RTT, bottleneck link
+ bandwidth as low as 64 Kbps, and route queue size as low as 40
+ packets. A large combination of test parameters were used.
+ Almost all tests showed varying degrees of latency improvement
+ from IW=10, with only a modest increase in the packet drop rate
+ until a very high load was injected. The testbed result was
+ consistent with both the large-scale data center experiments
+ [CD10] [DCCM10] and a separate study using the Network Simulation
+ Cradle (NSC) framework [Sch11] [Sch11-1].
+
+ o How will the larger initial window affect flows with initial
+ windows of 4 KB or less?
+
+ Flows with the larger initial window will likely grab more
+ bandwidth from a bottleneck link when competing against flows with
+ smaller initial windows, at least initially. How long will this
+ "unfairness" last? Will there be any "capture effect" where flows
+ with larger initial window possess a disproportional share of
+ bandwidth beyond just a few round trips?
+
+ If there is any "unfairness" issue from flows with different
+ initial windows, it did not show up in the large-scale
+ experiments, as the average latency for the bucket of all
+ responses less than 4 KB did not seem to be affected by the
+ presence of many other larger responses employing large initial
+ window. As a matter of fact, they seemed to benefit from the
+ large initial window too, as shown in Figure 7 of [Duk10].
+
+
+
+
+
+Chu, et al. Experimental [Page 22]
+
+RFC 6928 Increasing TCP's Initial Window April 2013
+
+
+ The same phenomenon seems to exist in the testbed experiments
+ [CW10]. Flows with IW=3 only suffered slightly when competing
+ against flows with IW=10 in light to medium loads. Under high
+ load, both flows' latency improved when mixed together. Also
+ long-lived, background bulk-data flows seemed to enjoy higher
+ throughput when running against many foreground short flows of
+ IW=10 than against short flows of IW=3. One plausible explanation
+ was that IW=10 enabled short flows to complete sooner, leaving
+ more room for the long-lived, background flows.
+
+ A study using an NSC simulator has also concluded that IW=10 works
+ rather well and is quite fair against IW=3 [Sch11] [Sch11-1].
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chu, et al. Experimental [Page 23]
+
+RFC 6928 Increasing TCP's Initial Window April 2013
+
+
+Authors' Addresses
+
+ Jerry Chu
+ Google, Inc.
+ 1600 Amphitheatre Parkway
+ Mountain View, CA 94043
+ USA
+
+ EMail: hkchu@google.com
+
+
+ Nandita Dukkipati
+ Google, Inc.
+ 1600 Amphitheatre Parkway
+ Mountain View, CA 94043
+ USA
+
+ EMail: nanditad@google.com
+
+
+ Yuchung Cheng
+ Google, Inc.
+ 1600 Amphitheatre Parkway
+ Mountain View, CA 94043
+ USA
+
+ EMail: ycheng@google.com
+
+
+ Matt Mathis
+ Google, Inc.
+ 1600 Amphitheatre Parkway
+ Mountain View, CA 94043
+ USA
+
+ EMail: mattmathis@google.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chu, et al. Experimental [Page 24]
+