Re: [tcpm] Tuning TCP parameters for the 21st century

Jerry Chu <hkchu@google.com> Wed, 15 July 2009 22:27 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 B163C3A6F75 for <tcpm@core3.amsl.com>; Wed, 15 Jul 2009 15:27:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.977
X-Spam-Level:
X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 Ye9FriBLuKBq for <tcpm@core3.amsl.com>; Wed, 15 Jul 2009 15:27:09 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 175843A6BDD for <tcpm@ietf.org>; Wed, 15 Jul 2009 15:27:08 -0700 (PDT)
Received: from zps35.corp.google.com (zps35.corp.google.com [172.25.146.35]) by smtp-out.google.com with ESMTP id n6FLKJxT001970 for <tcpm@ietf.org>; Wed, 15 Jul 2009 22:20:19 +0100
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1247692820; bh=o2SC50saBC+Ma3OHDFozIMYL1cM=; h=DomainKey-Signature:MIME-Version:In-Reply-To:References:Date: Message-ID:Subject:From:To:Cc:Content-Type: Content-Transfer-Encoding:X-System-Of-Record; b=kifwu5IJyDQvGS6DCX cr9V47Q3IBgh8vSw9LCByNr6YvmRqibdtn/iA6PQwPc/B8unPSUwMi0/TFmMDXsGWxq Q==
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=Bxk/vD1ynk2w8/BdrRvUXGK6TswPTC5Ytw/qSbxru5vx/6bFN1rpAi/dX264FZlwg 9iEw0cp1n3d2lUAOtw2ng==
Received: from an-out-0708.google.com (andd14.prod.google.com [10.100.30.14]) by zps35.corp.google.com with ESMTP id n6FLKFda019257 for <tcpm@ietf.org>; Wed, 15 Jul 2009 14:20:16 -0700
Received: by an-out-0708.google.com with SMTP id d14so1950341and.13 for <tcpm@ietf.org>; Wed, 15 Jul 2009 14:20:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.152.12 with SMTP id z12mr10719223and.96.1247692815404; Wed, 15 Jul 2009 14:20:15 -0700 (PDT)
In-Reply-To: <4A5DE6BC.3090904@isi.edu>
References: <d1c2719f0907131619t1a80997ep4080a3a721ef3627@mail.gmail.com> <4A5C540E.9070104@sun.com> <4A5C9309.8030704@isi.edu> <d1c2719f0907141241p73e605adqc1d2e6f0db4eb3aa@mail.gmail.com> <4A5CE3D0.5000904@isi.edu> <d1c2719f0907141532i31d2b740hfa32209a8ccb156@mail.gmail.com> <4A5D0E8F.1040402@isi.edu> <d1c2719f0907141743n4952c9far54e3be36668577ed@mail.gmail.com> <4A5DE6BC.3090904@isi.edu>
Date: Wed, 15 Jul 2009 14:20:15 -0700
Message-ID: <d1c2719f0907151420p3f3d248dg7aa14042406ffc4f@mail.gmail.com>
From: Jerry Chu <hkchu@google.com>
To: Joe Touch <touch@isi.edu>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-System-Of-Record: true
Cc: "tcpm@ietf.org" <tcpm@ietf.org>
Subject: Re: [tcpm] Tuning TCP parameters for the 21st century
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, 15 Jul 2009 22:27:10 -0000

On Wed, Jul 15, 2009 at 7:25 AM, Joe Touch<touch@isi.edu> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> Jerry Chu wrote:
> ...
>>> We're taking one more look at T/TCP as well (probably need to start a different
>>> mail thread on T/TCP too).
>
> T/TCP is deprecated due to a fairly large security issue that has not
> been solved, AFAIK. It'd be useful to have a solution to that issue
> before proceeding with it as an approach.

Understood. On the high level it seems to me a nonce/cookie exchanged
over one reqular TCP connection (w/ 3WHS) upfront will always be required
but should be sufficient to cover later T/TCP sessions and address the security
concern? (Oh perhaps the cookie can be passed around by attackers to mount
a DDOS attack?)

> ...
>>> The SYN/SYN-ACK retransmission rate we measured turned out to be >> 1%
>>> in many cases (a bit surprising to us) hence the benefit.
>
> That points to some other problem going on. As a packet loss rate,
> that's quite high and causes problems elsewhere in TCP. It would be
> useful to understand where the drops are and why. Retransmitting SYNs to
> a busy endpoint whose queue is overflowing doesn't help things, e.g.

One set of our data show our TCP pkt rexmit rate ranges from 0.8% - 2.4%
globally. Even at 1% drop rate 3secs is a noticeable bump for the average
latency.

Jerry

>
> Joe
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkpd5rwACgkQE5f5cImnZrslfgCfVmHxe6fxfD7nCq/S5mn8S0Bt
> mwMAnRZPyVGbsvU9x6G1M+hbbR0AnCGn
> =Kghy
> -----END PGP SIGNATURE-----
>