From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-13-iad.dyndns.com (mxout-025-iad.mailhop.org [216.146.32.25]) by lists.bufferbloat.net (Postfix) with ESMTP id 870872E015C for ; Thu, 17 Mar 2011 15:20:40 -0700 (PDT) Received: from scan-11-iad.mailhop.org (scan-11-iad.local [10.150.0.208]) by mail-13-iad.dyndns.com (Postfix) with ESMTP id D091ABDC5FD for ; Thu, 17 Mar 2011 22:20:39 +0000 (UTC) X-Spam-Score: -4.0 (----) X-Mail-Handler: MailHop by DynDNS X-Originating-IP: 15.201.24.17 Received: from g4t0014.houston.hp.com (g4t0014.houston.hp.com [15.201.24.17]) by mail-13-iad.dyndns.com (Postfix) with ESMTP id 752F6BDC563 for ; Thu, 17 Mar 2011 22:20:39 +0000 (UTC) Received: from g4t0018.houston.hp.com (g4t0018.houston.hp.com [16.234.32.27]) by g4t0014.houston.hp.com (Postfix) with ESMTP id 15656248E8; Thu, 17 Mar 2011 22:20:39 +0000 (UTC) Received: from [16.89.244.213] (tardy.cup.hp.com [16.89.244.213]) by g4t0018.houston.hp.com (Postfix) with ESMTP id 8D0B4101F6; Thu, 17 Mar 2011 22:20:38 +0000 (UTC) From: Rick Jones To: Jonathan Morton In-Reply-To: <44F5E713-4AB2-4D34-9DD5-97FBE92E401F@gmail.com> References: <4D7F4121.40307@freedesktop.org> <20110315175942.GA10064@goldfish> <1300212877.2087.2155.camel@tardy> <20110315183111.GB2542@tuxdriver.com> <29B06777-CC5F-4802-8727-B04F58CDA9E3@gmail.com> <20110315205146.GF2542@tuxdriver.com> <219C7840-ED79-49EA-929D-96C5A6200401@gmail.com> <20110316004722.GD28663@tuxdriver.com> <66469263-763A-4D5A-B689-026D0603C170@gmail.com> <1300386132.2087.2345.camel@tardy> <44F5E713-4AB2-4D34-9DD5-97FBE92E401F@gmail.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 17 Mar 2011 15:20:36 -0700 Message-ID: <1300400436.2087.2401.camel@tardy> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: bloat@lists.bufferbloat.net Subject: Re: [Bloat] Random idea in reaction to all the discussion of TCP flavours - timestamps? X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list Reply-To: rick.jones2@hp.com List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 22:20:40 -0000 On Thu, 2011-03-17 at 23:50 +0200, Jonathan Morton wrote: > On 17 Mar, 2011, at 8:22 pm, Rick Jones wrote: > > So initialRTO is specced currently to be 3 seconds, with a small but > > non-trivial effort under way to reduce that, but once established > > connections have a minimum RTO of less than or equal to a second don't > > they? > > If the RTT they measure is low enough, then yes. If the queues > lengthen, the measured RTT goes up and so does the RTO, once the > connection is established. Right. I should have been more explicit about "You know it won't retransmit any sooner than N." (for some, changing value of N :) > But the *initial* RTO is the important one for unmanaged queue sizing, > because that determines whether a new connection can be started > without retransmissions, all else functioning correctly of course. > There is no way to auto-tune that. > > Note also that with AQM that can re-order packets, the length of the > bulk queue starts to matter much less, because the SYN/ACK packets can > bypass most of the traffic. In that case the RTT measured by the > existing bulk flows will be higher than the latency seen by new and > interactive flows. I would think that unless the rest of the segments of the connection will also bypass most of the traffic, the SYN or SYN|ACK should not bypass - to do so will give the TCP connection a low, unrealistic initial estimate of the RTT. Given the recent change in Linux upstream to go to cwnd_init of 10 segments, and the prospect of other stacks following that lead in implementing the draft RFC, if there is a big slow queue of traffic that the data segments will not bypass, it would seem better to have the SYN or SYN|ACK get delayed and retransmitted to get the cwnd down. SYN and SYN|ACK segments should not receive special treatment beyond what data segments for the same connection would get. rick