IETF Logo Mail Archive

Re: [tcpm] TCP tuning

Joe Touch <touch@ISI.EDU> Thu, 04 February 2010 18:40 UTC

Return-Path: <touch@ISI.EDU>
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 A90583A6DEF for <tcpm@core3.amsl.com>; Thu, 4 Feb 2010 10:40:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 G-H-G+zEHKH5 for <tcpm@core3.amsl.com>; Thu, 4 Feb 2010 10:40:36 -0800 (PST)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 120443A6D5B for <tcpm@ietf.org>; Thu, 4 Feb 2010 10:40:36 -0800 (PST)
Received: from [75.214.242.122] (122.sub-75-214-242.myvzw.com [75.214.242.122]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o14Ic9GP000221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 4 Feb 2010 10:38:11 -0800 (PST)
Message-ID: <4B6B1410.9010604@isi.edu>
Date: Thu, 04 Feb 2010 10:38:08 -0800
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: rick jones <perfgeek@mac.com>
References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <133D9897FB9C5E4E9DF2779DC91E947C025F1861@SLFSNX.rcs.alcatel-research.de> <d1c2719f1002031110v3b76ca9eu14c9a110847548e7@mail.gmail.com> <4B69CDD7.6060802@isi.edu> <E086E248-DEFA-4AA4-B25D-F7FBB0FB9E7D@mac.com> <4B6A43D1.2010706@isi.edu> <9E43CA53-5BFD-4377-93D1-1AED32C09B0E@mac.com> <443C71B6-1D1A-49CA-B5E4-FB81FDCB7FD1@mac.com> <4B6A6848.80904@isi.edu> <6C3B471F-6ACB-467E-9D11-EE68388B3F5B@mac.com> <4B6AF84A.9080509@isi.edu> <5995012B-4768-4073-A153-1AB8012A84D4@mac.com>
In-Reply-To: <5995012B-4768-4073-A153-1AB8012A84D4@mac.com>
X-Enigmail-Version: 0.96.0
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="------------enigB09A0D0D38A542B5AA4C9427"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: tcpm@ietf.org, "SCHARF, Michael" <Michael.Scharf@alcatel-lucent.com>
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: Thu, 04 Feb 2010 18:40:36 -0000


rick jones wrote:
...
> My experience thusfar with netperf benchmarking has been that the
> single-transaction at a time TCP_RR test has never run into
> Nagle-induced delays on any stack that wasn't broken, and I cannot
> recall the last time I encountered such a broken stack. 

What you have seen is consistency in implementations. Such behavior is
not required by the specs, so it should not be considered "broken", nor
should tests rely on it.

Thanks for removing it as an issue, though. There are many other things
that could be happening, and as I noted the behavior was never really
well spec'd AFAIR.

Joe

v2.23.0 | Report a Bug | By Email