[tcpm] initial RTO change ?
Mark Allman <mallman@icir.org> Mon, 15 March 2010 21:09 UTC
Return-Path: <mallman@icir.org>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43B5D3A6965 for <tcpm@core3.amsl.com>; Mon, 15 Mar 2010 14:09:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.151
X-Spam-Level:
X-Spam-Status: No, score=-5.151 tagged_above=-999 required=5 tests=[AWL=-1.010, BAYES_40=-0.185, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xUYFIQAw4Var for <tcpm@core3.amsl.com>; Mon, 15 Mar 2010 14:09:08 -0700 (PDT)
Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 998793A6BE8 for <tcpm@ietf.org>; Mon, 15 Mar 2010 14:09:04 -0700 (PDT)
Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id o2FKxVO1004720 for <tcpm@ietf.org>; Mon, 15 Mar 2010 13:59:31 -0700 (PDT)
Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 59ECAB20596 for <tcpm@ietf.org>; Mon, 15 Mar 2010 11:31:17 -0400 (EDT)
To: tcpm@ietf.org
From: Mark Allman <mallman@icir.org>
Organization: International Computer Science Institute (ICSI)
Song-of-the-Day: In the City
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="--------ma21189-1"; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Mon, 15 Mar 2010 11:31:17 -0400
Sender: mallman@icir.org
Message-Id: <20100315153117.59ECAB20596@lawyers.icir.org>
Subject: [tcpm] initial RTO change ?
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mallman@icir.org
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Mar 2010 21:09:09 -0000
As alluded to previously, we (== Vern Paxson, Jerry Chu and I) recently put out an I-D for a possible 2988bis that represents only a small change from RFC2988. It is draft-paxson-tcpm-rfc2988bis-00.txt. The proposed change is to reduce the initial RTO from 3 seconds to 1 second. A few notes: - If there is loss detected before an RTT sample is obtained (i.e., using the 1sec RTO) then the RTO is backed off per usual. But, in addition, the data transmission starts by using the old 3sec value to be conservative and to not let an RTO in the 3WHS impact data transfer. (An RTO in the 3WHS does force the sender to use an initial cwnd of 1 segment, so there is some potential impact for being more aggressive.) - It seems the real danger here is in strobing one or two extra SYNs into the network---not a big deal in our judgment. - The changes are quite modest. We added an appendix that explains the thinking, but the in-line changes are small and given below. We'd appreciate feedback on whether the WG thinks this is a good idea or not. Many thanks! allman @@ -92,17 +92,24 @@ Abstract (2.1) Until a round-trip time (RTT) measurement has been made for a segment sent between the sender and receiver, the sender SHOULD - set RTO <- 3 seconds (per RFC 1122 [Bra89]), though the - "backing off" on repeated retransmission discussed in (5.5) - still applies. - - Note that some implementations may use a "heartbeat" timer - that in fact yield a value between 2.5 seconds and 3 - seconds. Accordingly, a lower bound of 2.5 seconds is also - acceptable, providing that the timer will never expire - faster than 2.5 seconds. Implementations using a heartbeat - timer with a granularity of G SHOULD not set the timer below - 2.5 + G seconds. + set RTO <- 1 second, though the "backing off" on repeated + retransmission discussed in (5.5) still applies. + + Note that the previous version of this document used an + initial RTO of 3 seconds [RFC2988]. A TCP implementation MAY + still use this value (or any other value > 1 second). This + change in the lower bound on the initial RTO is discussed in + further detail in Appendix A. (2.2) When the first RTT measurement R is made, the host MUST set @@ -222,6 +229,14 @@ Abstract seconds (for the value of RTO after the doubling operation outlined in 5.5). + (5.7) If the timer expires awaiting the ACK of a SYN segment and the + TCP implementation is using an RTO less than 3 seconds, the RTO + MUST be re-initialized to 3 seconds when data transmission + begins (i.e., after the three-way handshake completes). + + This represents a change from the previous version of this + document [RFC2988] and is discussed in Appendix A. + Note that after retransmitting, once a new RTT measurement is obtained (which can only happen when new data has been sent and acknowledged), the computations outlined in section 2 are performed,
- [tcpm] initial RTO change ? Mark Allman