Re: [tcpm] TCP tuning

Mark Allman <mallman@icir.org> Mon, 15 March 2010 21:16 UTC

Return-Path: <mallman@icir.org>
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 F3CB13A6824 for <tcpm@core3.amsl.com>; Mon, 15 Mar 2010 14:16:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.28
X-Spam-Level:
X-Spam-Status: No, score=-6.28 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_MED=-4]
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 6s-QIRlLBJVV for <tcpm@core3.amsl.com>; Mon, 15 Mar 2010 14:16:43 -0700 (PDT)
Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 2DDD43A6407 for <tcpm@ietf.org>; Mon, 15 Mar 2010 14:16:43 -0700 (PDT)
Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id o2FKxVQ3004712; Mon, 15 Mar 2010 13:59:31 -0700 (PDT)
Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 33B98B204BA; Mon, 15 Mar 2010 11:22:44 -0400 (EDT)
To: John Heffner <johnwheffner@gmail.com>
From: Mark Allman <mallman@icir.org>
In-Reply-To: <1e41a3231002031251v53f03f78x2ba6a12c4f12a22@mail.gmail.com>
Organization: International Computer Science Institute (ICSI)
Song-of-the-Day: In the City
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="--------ma20675-1"; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Mon, 15 Mar 2010 11:22:44 -0400
Sender: mallman@icir.org
Message-Id: <20100315152244.33B98B204BA@lawyers.icir.org>
Cc: "tcpm@ietf.org WG" <tcpm@ietf.org>
Subject: Re: [tcpm] TCP tuning
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mallman@icir.org
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: Mon, 15 Mar 2010 21:16:44 -0000

[These are re-sends from long ago... they never made it to the list.
 But, that seems to have been worked out, now.  --allman]

> I think you need a negotiation for
> opt-in rather than opt-out.

If you want to negotiate an initial window then define a riff on
Quick-Start that doesn't require help from the routers.

But, that feels like too much here ...

  - If the receiver is the problem then even overwhelming it with a
    larger initial burst doesn't hurt the shared network much.

  - On the order of 10 packets it seems hard to believe that we're
    really going to overwhelm any even moderately recent end system.

  - If it isn't the end system we're worried about then the receiver is
    acting as a proxy for something in the middle.  And, so ...

      + How good will the receiver be able to achieve this?

      + If it is really a problem then you probably want something like
        Quick-Start to actually engage the path in the decision.

I helped write Quick-Start so don't get me wrong here.... perhaps there
is a need to get into all this mechanism if you want to send Really
Fast.  But, it seems that we should be able to have some initial value
that can be used without consent that will not cause issues high quite
high probability.  And, 'network inflation' would likely mean that
number should increase over time.

allman