Internet Draft Y. Cheng draft-ycheng-tcpm-rtosynrtt-00.txt Google. Inc Intended status: Standard Updates: 3390, 2988 Creation date: June 30, 2010 Expiration date: January 2011 Seeding RTO with RTT sampled during three-way handshake Status of this Memo Distribution of this memo is unlimited. This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on January, 2011. Copyright Notice Copyright (c) 2010 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. Chu, et. al. Expires August 2010 [Page 1] Internet Draft Increasing TCP's Initial Window February 2010 Abstract This document proposes seeding the retransmission timer by the RTT measured during the TCP connection establishment and updates the recommended approach in [RFC3390]. It discusses the motivation, the TCP modification, and the experimental result. 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]. 1. Motivation [RFC3390] section 6. "Interaction with the Retransmission Timer" recommends not to sample the RTT during the three-way handshake when using a larger initial window. The concern is that the transmission time on narrowband links is a large portion of the RTT. Therefore seeding the RTO based on RTT of small SYN or SYNACK packets likely underestimates the RTT of larger data packets may cause spurious retransmission. While the example of 9.6kbps link used in the [RFC3390] remains valid, modern Internet is dominated by web applications over much faster links like DSL or cable broadband networks [AKAM10]. As a result, the recommended approach could cause noticeable latency impact on these networks. The Chrome browser data [BELSHE10] shows the web page by average is 320KB which consists of 45 resources downloaded from various domains. If the packet loss occurs during the initial HTTP request or response of the TCP connections and TCP fails to trigger TCP fast-retransmit due to insufficient DUPACKs, the senders will time out and retransmit after 3 second. 3 second is a long delay for today's Internet users: up to 40% of the users abandon the web page after 3 second [GOMEZ10]. Moreover, browsers or users often "reload" the web page by sending the same request over another (possibly newly created) TCP connection. In fact, some browsers try to bypass this hurdle by actively opening multiple TCP connections in quick succession and schedule HTTP request on the earliest established connection. Thus in addition to the latency impact, such unexpected long delays often result in aggressive network usage which waste more network and end systems resources. The situation calls for a TCP change to improve the latency problem. Chu, et. al. Expires August 2010 [Page 2] Internet Draft Increasing TCP's Initial Window February 2010 2. TCP Modification The document proposes to update [RFC3390] section 6. The RECOMMENDED approach is to sample the RTT during the three-way handshake and seed the retransmission timer (RTO), regardless of the size of the TCP initial congestion window. The document also updates [RFC2988] to add in section 2 "The Basic Algorithm" step 2.2: (2.2) When the first RTT measurement R is made, the host MUST set SRTT <- R RTTVAR <- R/2 RTO <- SRTT + max(G, K*RTTVAR) where K = 4 If the R is made from SYN or SYNACK RTT measurement and less than 1 second, the host MAY further increase the RTO by additional D seconds. The RECOMMENDED value of D is 2*MSS*8/56000 to accommodate transmission delay of 2 MSS size packets over a typical 56Kbps dial-up links or 1 MSS size packets plus the delayed ACK time. In a network path over 56Kbps modem of SYN RTT measured 400ms and MSS 1460 bytes, D = 417ms. The seeded RTO after TCP handshake is about 1.6 second. 4. Experimental Results The proposed TCP changes have shown 8% to 20% improvements on first HTTP download latency on a popular CDN among connections experiencing losses [CHENG10]. As expected, the change is most effective for small HTTP responses that have little chance to trigger TCP fast- retransmit. But even on larger downloads such as blogger photos achieve 12% reduction on TCP latency. On the other hand, the experiments has also shown only a slight 0.1% increase in the TCP retransmission rate. Based on the experiment results, we believe the seeding TCP RTO with RTT measured in handshake improves latency well with minimal impact to the network congestion. 5. Security Considerations This document discusses seeding the retransmission timer with the RTT measured during TCP handshake. This change does not raise any known new security issues with TCP. Chu, et. al. Expires August 2010 [Page 3] Internet Draft Increasing TCP's Initial Window February 2010 13. Conclusion This document recommends seeding TCP retransmission timer with the RTT measured in TCP handshake to improve the latency. It discusses the motivation, the proposed changes, and the results of a large- scale Internet experiment. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000. [RFC3390] Allman, M., Floyd, S. and C. Partridge, "Increasing TCP's Initial Window", RFC 3390, October 2002. Informative References [AKAM10] "The State of the Internet, 3rd Quarter 2009", Akamai Technologies, Inc., June 2010. [BELSHE10] Google Chrome, O'reilly Velocity Conference, June 2010. URL http://www.belshe.com/test/velocity2010/#slide9.0 [CHENG10] Y. Cheng, "Latency impact of seeding RTO with SYN RTT", June, 2010. URL http://code.google.com/speed/protocols/rtoseedsynrtt.ppt [GOMEZ10] Why Web Performance Matters White Paper. Gomez Inc. URL http://www.gomez.com/google-adwords/why-website- performance-matters-short/ Chu, et. al. Expires August 2010 [Page 4] Internet Draft Increasing TCP's Initial Window February 2010 Author's Addresses Yuchung Cheng Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 USA EMail: ycheng@google.com Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Chu, et. al. Expires August 2010 [Page 5]