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