IETF Logo Mail Archive

Re: [tcpm] TCP tuning

Jerry Chu <hkchu@google.com> Wed, 03 February 2010 20:47 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 86CE328C0FC for <tcpm@core3.amsl.com>; Wed, 3 Feb 2010 12:47:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.644
X-Spam-Level:
X-Spam-Status: No, score=-102.644 tagged_above=-999 required=5 tests=[AWL=-0.667, 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 TdeUFb9UAEIq for <tcpm@core3.amsl.com>; Wed, 3 Feb 2010 12:47:35 -0800 (PST)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 3CE6728C121 for <tcpm@ietf.org>; Wed, 3 Feb 2010 12:47:35 -0800 (PST)
Received: from kpbe19.cbf.corp.google.com (kpbe19.cbf.corp.google.com [172.25.105.83]) by smtp-out.google.com with ESMTP id o13KmI1n030618 for <tcpm@ietf.org>; Wed, 3 Feb 2010 12:48:18 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1265230098; bh=ScXiDZvhyQTDISSRsEC1961+TvM=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=yWP14AarvATfQISzU7rCwN5hDSPKziGtnomvoeH59JFQW2n07Gv1WCIylviTueU1v 66rClJUI0DoTIZvY0kj8Q==
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=InfA3rexyRZJCjwq2X31WECMq4Uf3u0M6tcGh2VIXQAoX3X77AzQxlgf4IIbSYF+c 83t/5kEiK6WTPD4Zgxm0w==
Received: from pxi26 (pxi26.prod.google.com [10.243.27.26]) by kpbe19.cbf.corp.google.com with ESMTP id o13KlIRF026393 for <tcpm@ietf.org>; Wed, 3 Feb 2010 12:48:17 -0800
Received: by pxi26 with SMTP id 26so2114197pxi.17 for <tcpm@ietf.org>; Wed, 03 Feb 2010 12:48:15 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.56.2 with SMTP id e2mr102875rva.37.1265230095387; Wed, 03 Feb 2010 12:48:15 -0800 (PST)
In-Reply-To: <4B69C35F.9080903@isi.edu>
References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <4B69A53E.2050508@isi.edu> <4B69ACD9.1030105@sun.com> <4B69AE64.8070608@isi.edu> <10EDB15A-0DF6-45EE-897C-E38AA611134C@ifi.uio.no> <4B69B030.3000508@isi.edu> <D70C30EF-91E3-4DB6-B0C7-0A6328C77E6A@ifi.uio.no> <4B69B5AC.1090209@isi.edu> <8FCC1879-FBA4-4A5F-8ADF-932A6731B7EA@ifi.uio.no> <4B69C35F.9080903@isi.edu>
Date: Wed, 03 Feb 2010 12:48:15 -0800
Message-ID: <d1c2719f1002031248q2eb05845ycd32a63f7d05dae@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: quoted-printable
X-System-Of-Record: true
Cc: tcpm@ietf.org, Kacheong Poon <kacheong.poon@sun.com>, 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:47:36 -0000

On Wed, Feb 3, 2010 at 10:41 AM, Joe Touch <touch@isi.edu> wrote:
>
>
> Michael Welzl wrote:
>>>> In other words, why not harness this knowledge somehow,
>>>> and develop a customized transport protocol, or ways of
>>>> customizing what we now have?
>>>
>>> That's been tried in various ways in various IETF efforts. Some try to
>>> find the properties of the immediate link, which are expected for some
>>> link types to dominate the path. Some try to detect path properties.
>>> Some reuse information from past connections.
>>
>> Really? I'd be curious about a few pointers, what exactly
>> do you have in mind? About reusing information etc., the
>> congestion manager and your TCB sharing stuff comes to
>> mind, but for the rest I'm curious
>
> Spencer Dawkins probably recalls better than I; I think there were
> numerous BOFs centered around "link indications", including:
>        TRIGTRAN BOF
>        "LinkUp"
>        draft-dawkins-linkup-nevermind
>        LCI BOF (Link Characteristic Information for Mobility)
>        MPTCP WG
>        LEDBAT WG
>        RFC-4709

The following is quoted from RFC3150 (a BCP):

   "Implementors should consider the possibility that a host will be
   directly connected to a low-speed link when choosing default TCP
   receive window sizes."

Jerry

>
> Joe
>
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>
>

v2.23.0 | Report a Bug | By Email