Re: [tcpm] TCP tuning
Jerry Chu <hkchu@google.com> Wed, 03 February 2010 20:34 UTC
Return-Path: <hkchu@google.com>
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 8CFAF28C1B8 for <tcpm@core3.amsl.com>; Wed, 3 Feb 2010 12:34:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.477
X-Spam-Level:
X-Spam-Status: No, score=-104.477 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 sAQgHzQsDISa for <tcpm@core3.amsl.com>; Wed, 3 Feb 2010 12:34:30 -0800 (PST)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 2546828C1B7 for <tcpm@ietf.org>; Wed, 3 Feb 2010 12:34:29 -0800 (PST)
Received: from kpbe12.cbf.corp.google.com (kpbe12.cbf.corp.google.com [172.25.105.76]) by smtp-out.google.com with ESMTP id o13KZB8G031807 for <tcpm@ietf.org>; Wed, 3 Feb 2010 20:35:11 GMT
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1265229312; bh=eiD3AFPvGllRXANX9OMapHkdsI8=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=MUYgXPJCW3WG9KMettnP04kV29/8nFiedjQXNO1Jc6UltBmatC0Dqo0bUYSZeEZEg 8meeVRHHpANisRTpx+EDA==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=QVlkKUilsaEl6aCD5+c79ReQQfOtvd/b6/mE6sGWKnZJE3sOCX7n2Hj2zv8JdIMVI ArG98Vq5HlY6EuKP5qtcw==
Received: from pzk9 (pzk9.prod.google.com [10.243.19.137]) by kpbe12.cbf.corp.google.com with ESMTP id o13KYx5m002933 for <tcpm@ietf.org>; Wed, 3 Feb 2010 12:35:10 -0800
Received: by pzk9 with SMTP id 9so2011899pzk.31 for <tcpm@ietf.org>; Wed, 03 Feb 2010 12:35:10 -0800 (PST)
MIME-Version: 1.0
Received: by 10.141.12.3 with SMTP id p3mr66451rvi.194.1265229309054; Wed, 03 Feb 2010 12:35:09 -0800 (PST)
In-Reply-To: <A3D02FB7C6883741952C425A59E261A509732117@SACMVEXC2-PRD.hq.netapp.com>
References: <d1c2719f1002031020u114d0f27r5b1685eef4f2177b@mail.gmail.com> <A3D02FB7C6883741952C425A59E261A509732117@SACMVEXC2-PRD.hq.netapp.com>
Date: Wed, 03 Feb 2010 12:35:09 -0800
Message-ID: <d1c2719f1002031235p3fb042ddg6d919ad32a4865c4@mail.gmail.com>
From: Jerry Chu <hkchu@google.com>
To: "Biswas, Anumita" <Anumita.Biswas@netapp.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
Cc: tcpm@ietf.org, Michael Welzl <michawe@ifi.uio.no>
Subject: Re: [tcpm] TCP tuning
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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: Wed, 03 Feb 2010 20:34:31 -0000
On Wed, Feb 3, 2010 at 10:39 AM, Biswas, Anumita <Anumita.Biswas@netapp.com> wrote: > > >> -----Original Message----- >> From: Jerry Chu [mailto:hkchu@google.com] >> Sent: Wednesday, February 03, 2010 10:21 AM >> To: Michael Welzl >> Cc: tcpm@ietf.org WG >> Subject: Re: [tcpm] TCP tuning >> >> >> Michael, >> >> On Wed, Feb 3, 2010 at 6:42 AM, Michael Welzl >> <michawe@ifi.uio.no> wrote: >> > Hi all, >> > >> > (sorry if this is a bit off topic, as the mentioned presentation is >> > mainly about using a larger initial window) >> > >> > In the context of the discussion that Jerry brought up on parameter >> > tuning, one question that was raised was the initial RTO during the >> > SYN - SYN/ACK exchange. I understand that we can't >> recommend to resend >> > SYN's more aggressively because this might cause a server to be >> > overloaded with SYN's, but why do we have to wait extremely >> long until >> > we resend SYN/ACKs? >> > >> > Back then, when I asked, I got no answer. Both Jerry and I >> pointed to >> > our measurement results which show that the effect is nonneglible. >> >> Actually Mark Allman, Vern Paxon and I have been working on >> revising RFC2988 to reduce the initial RTO from 3secs to >> 1sec. Will submit the proposal soon! >> > This implies that this proposal brings the intial RTO value to be equal to the minimum RTO value of 1 second. Is this true? Correct. > > I am going by RFC 2988, section 2, 2.4. It explicitly states this: > > " (2.4) Whenever RTO is computed, if it is less than 1 second then the > RTO SHOULD be rounded up to 1 second. > > Traditionally, TCP implementations use coarse grain clocks to > measure the RTT and trigger the RTO, which imposes a large > minimum value on the RTO. Research suggests that a large > minimum RTO is needed to keep TCP conservative and avoid > spurious retransmissions [AP99]. Therefore, this > specification requires a large minimum RTO as a conservative > approach, while at the same time acknowledging that at some > future point, research may show that a smaller minimum RTO is > acceptable or superior." > > Is it time to reconsider a smaller minimum RTO as well? Yes this is the 3rd item on my todo list (see http://www.ietf.org/proceedings/75/slides/tcpm-1.pdf) but is not nearly as important as the first two IMO. Jerry > > > > > > >> Best, >> >> Jerry >> >> > >> > So I'll use this chance to ask again :-) >> > >> > Cheers, >> > Michael >> > >> > >> > On Feb 3, 2010, at 3:28 PM, Lars Eggert wrote: >> > >> >> Hi, >> >> >> >> Jerry Chu has recently started the discussion on whether >> we need to >> >> think about tweaking TCP for the "modern Internet." Just >> came across >> >> another presentation from (AFAICT) another corner of Google that >> >> makes similar arguments. >> >> >> >> FYI: >> >> >> http://sites.google.com/a/chromium.org/dev/spdy/An_Argument_For_Chang >> >> ing_TCP_Slow_Start.pdf >> >> >> >> This topic seems to be gaining momentum, and the WG should >> take some >> >> time considering if there is work here for it. >> >> >> >> Lars_______________________________________________ >> >> tcpm mailing list >> >> tcpm@ietf.org >> >> https://www.ietf.org/mailman/listinfo/tcpm >> > >> > _______________________________________________ >> > tcpm mailing list >> > tcpm@ietf.org >> > https://www.ietf.org/mailman/listinfo/tcpm >> > >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> >
- [tcpm] TCP tuning Lars Eggert
- Re: [tcpm] TCP tuning Adam Langley
- Re: [tcpm] TCP tuning Michael Welzl
- Re: [tcpm] TCP tuning SCHARF, Michael
- Re: [tcpm] TCP tuning Stefanos Harhalakis
- Re: [tcpm] TCP tuning Kacheong Poon
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Kacheong Poon
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Michael Welzl
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Michael Welzl
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Adam Langley
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Jerry Chu
- Re: [tcpm] TCP tuning Michael Welzl
- Re: [tcpm] TCP tuning Michael Welzl
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Jerry Chu
- Re: [tcpm] TCP tuning Jerry Chu
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Jerry Chu
- Re: [tcpm] TCP tuning John Heffner
- Re: [tcpm] TCP tuning Jerry Chu
- Re: [tcpm] TCP tuning Jerry Chu
- Re: [tcpm] TCP tuning Biswas, Anumita
- Re: [tcpm] TCP tuning Jerry Chu
- Re: [tcpm] TCP tuning John Heffner
- Re: [tcpm] TCP tuning Jerry Chu
- Re: [tcpm] TCP tuning Biswas, Anumita
- Re: [tcpm] TCP tuning Michael Welzl
- Re: [tcpm] TCP tuning Jerry Chu
- Re: [tcpm] TCP tuning Murali Bashyam
- Re: [tcpm] TCP tuning Michael Welzl
- Re: [tcpm] TCP tuning John Heffner
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Jerry Chu
- Re: [tcpm] TCP tuning Marco Mellia
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Jerry Chu
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Jerry Chu
- Re: [tcpm] TCP tuning rick jones
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Mike Belshe
- Re: [tcpm] TCP tuning rick jones
- Re: [tcpm] TCP tuning rick jones
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Alexander Zimmermann
- Re: [tcpm] TCP tuning Kacheong Poon
- Re: [tcpm] TCP tuning Kacheong Poon
- Re: [tcpm] TCP tuning SCHARF, Michael
- Re: [tcpm] TCP tuning SCHARF, Michael
- Re: [tcpm] TCP tuning Andrew Yourtchenko
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Jerry Chu
- Re: [tcpm] TCP tuning rick jones
- Re: [tcpm] TCP tuning Kacheong Poon
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning SCHARF, Michael
- Re: [tcpm] TCP tuning rick jones
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Jerry Chu
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Mike Belshe
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Mark Allman
- Re: [tcpm] TCP tuning Mark Allman
- Re: [tcpm] TCP tuning Mark Allman
- Re: [tcpm] TCP tuning Mark Allman
- Re: [tcpm] TCP tuning Mark Allman
- Re: [tcpm] TCP tuning Joe Touch