[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,