From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-22-ewr.dyndns.com (mxout-069-ewr.mailhop.org [216.146.33.69]) by lists.bufferbloat.net (Postfix) with ESMTP id 506042E00B9 for ; Thu, 17 Mar 2011 15:56:21 -0700 (PDT) Received: from scan-22-ewr.mailhop.org (scan-22-ewr.local [10.0.141.244]) by mail-22-ewr.dyndns.com (Postfix) with ESMTP id AE71A2E2DD for ; Thu, 17 Mar 2011 22:56:18 +0000 (UTC) X-Spam-Score: -1.0 (-) X-Mail-Handler: MailHop by DynDNS X-Originating-IP: 74.125.82.171 Received: from mail-wy0-f171.google.com (mail-wy0-f171.google.com [74.125.82.171]) by mail-22-ewr.dyndns.com (Postfix) with ESMTP id 049DE2F698 for ; Thu, 17 Mar 2011 22:56:12 +0000 (UTC) Received: by wyb32 with SMTP id 32so3963374wyb.16 for ; Thu, 17 Mar 2011 15:56:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=vWkh4QOJYzTok82MoNm6vUvtACfnU6cOMBTKalB28GI=; b=Z00yXQF+3URaNdgsB3BOotxtB8ZWWy9gNOb2Wavjsy6NNzNj1uNY6JRX8HE5yQTLBX 5JgwfcPrfAlP442FRjX369zHD7G0mMAaqhDPqdZdJiv9lhJDbOc6BQ0Eqne2b3ZbicPb mx5cDcHz4aZAuIhUVy1mMYd1vYexQVVMIPXlw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=X8vln7MTm3MjZUW3Xx/vec0QccX8trhA6Lfe7n4it5dL94PmAYefKFhqYx2Q/wVVIU QpWHmXtSOkme8nvq4BUZkhkXrjgUFbXhnJWkpqiej8YYGzeyQEH8PtU0MaSC/qdPjrVa 2Pdo2ipEVA6XdLvkjxWNwmHSz7ttRA5YLLBw4= Received: by 10.216.172.15 with SMTP id s15mr1436860wel.70.1300402572395; Thu, 17 Mar 2011 15:56:12 -0700 (PDT) Received: from [192.168.239.42] (xdsl-83-150-84-172.nebulazone.fi [83.150.84.172]) by mx.google.com with ESMTPS id r80sm1323394wei.15.2011.03.17.15.56.11 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 17 Mar 2011 15:56:12 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Jonathan Morton In-Reply-To: <1300400436.2087.2401.camel@tardy> Date: Fri, 18 Mar 2011 00:56:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <845EB260-932A-42F4-800C-005196B32D48@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> <1300400436.2087.2401.camel@tardy> To: rick.jones2@hp.com X-Mailer: Apple Mail (2.1082) 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 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:56:21 -0000 On 18 Mar, 2011, at 12:20 am, 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? >>=20 >> 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. >=20 > Right. I should have been more explicit about "You know it won't > retransmit any sooner than N." (for some, changing value of N :) I think there is a minimum value, on the order of 100ms - I don't know = precisely. >> 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.=20 >> There is no way to auto-tune that. >>=20 >> 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. >=20 > 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. > SYN and SYN|ACK segments should not receive special treatment beyond > what data segments for the same connection would get. I was thinking of SFQ, which doesn't discriminate based on TCP flags, = only on addresses and ports. With that said, while a low initial estimate of RTT is bad for = calculating RTO, it is not so bad for the rest of the congestion control = system. Remember that a major problem with Vegas is that it can grossly = overestimate the optimal RTT if, because the queues are already full, it = never sees the real propagation time. - Jonathan