Re: [tcpm] Introducing draft-huang-tcpm-tcp-eack-00

Alexander Zimmermann <Alexander.Zimmermann@nets.rwth-aachen.de> Wed, 31 March 2010 15:10 UTC

Return-Path: <Alexander.Zimmermann@nets.rwth-aachen.de>
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 0AFB53A6833 for <tcpm@core3.amsl.com>; Wed, 31 Mar 2010 08:10:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.136
X-Spam-Level:
X-Spam-Status: No, score=-3.136 tagged_above=-999 required=5 tests=[AWL=0.535, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 sRshvpg6EcMD for <tcpm@core3.amsl.com>; Wed, 31 Mar 2010 08:10:06 -0700 (PDT)
Received: from mail-i4.informatik.rwth-aachen.de (mail-i4.informatik.RWTH-Aachen.DE [137.226.12.21]) by core3.amsl.com (Postfix) with ESMTP id 4F4EB3A6919 for <tcpm@ietf.org>; Wed, 31 Mar 2010 08:10:05 -0700 (PDT)
Received: from messenger.nets.rwth-aachen.de (messenger.nets.rwth-aachen.de [137.226.13.40]) by mail-i4.informatik.rwth-aachen.de (Postfix) with ESMTP id 4820057AC2; Wed, 31 Mar 2010 17:10:35 +0200 (CEST)
Received: from MESSENGER.nets.rwth-aachen.de ([fe80::d0de:4cb1:8b0f:bd28]) by MESSENGER.nets.rwth-aachen.de ([fe80::d0de:4cb1:8b0f:bd28%14]) with mapi; Wed, 31 Mar 2010 17:10:17 +0200
From: Alexander Zimmermann <Alexander.Zimmermann@nets.rwth-aachen.de>
To: Manqing Huang <Manqing.Huang@exar.com>
Thread-Topic: [tcpm] Introducing draft-huang-tcpm-tcp-eack-00
Thread-Index: AQHKzR1YCN1w7l2xYUyMH1O2EBvhR5IEsoDggAdaWwA=
Date: Wed, 31 Mar 2010 15:10:32 +0000
Message-ID: <EED9E3B8-128C-4CB9-B0E3-5615EF632667@nets.rwth-aachen.de>
References: <FCA91A92EE52B041906A0358FC28FCC38EED595E83@FRE1EXCH02.hq.exar.com> <F312C222-31EA-4FE1-8755-71C9CAC9FFF1@nets.rwth-aachen.de> <FCA91A92EE52B041906A0358FC28FCC38EED5F9B96@FRE1EXCH02.hq.exar.com>
In-Reply-To: <FCA91A92EE52B041906A0358FC28FCC38EED5F9B96@FRE1EXCH02.hq.exar.com>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="us-ascii"
Content-ID: <6ece53d5-6be1-4181-9fb5-043ed1e86ea0>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "tcpm@ietf.org" <tcpm@ietf.org>
Subject: Re: [tcpm] Introducing draft-huang-tcpm-tcp-eack-00
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, 31 Mar 2010 15:10:08 -0000

Hi Manqing,

Am 27.03.2010 um 01:39 schrieb Manqing Huang:

> Alex,
> 
> Thank you for your comments.
> 
> The congestion issue is easier to be observed in a data center. It was reported by one of our customers who is a storage server vendor. The vendor ran two FTP clients to test the bi-directional traffic between two servers which are connected by a switch.
> 
> To debug this issue, we tried different open source TCP performance test tools. We found the majority of these tools transmit one-way traffic over each TCP connection when testing bi-directional performance.

Yeah, stupid clients. Either you can use a more sophisticated tool like "flowgrind"
(sorry for the advertisement ;-)) or patch those clients. IMO TCP is not responsible
for the daftness of those performance measurement tools or even ftp clients


> This fact suggests that existing applications may not utilize the duplex feature of a TCP connection when they send two-way traffic between two end points. In the real world, FTP and HTTP without pipelining do either GET or PUT/POST but not both at the same time.
> 
> Surely I will try to improve the application scenarios in the draft when more investigation results become available.
> 
> Regards,
> 
> Manqing
> 
> -----Original Message-----
> From: Alexander Zimmermann [mailto:Alexander.Zimmermann@nets.rwth-aachen.de]
> Sent: Friday, March 26, 2010 12:49 PM
> To: Manqing Huang
> Cc: tcpm@ietf.org
> Subject: Re: [tcpm] Introducing draft-huang-tcpm-tcp-eack-00
> 
> Hi,
> 
> I take a quick look at your draft. I really have problems with your application scenarios.
> Do you really think that iperf generates congestion in the internet?
> Also the ftp example is seems quite artificial...
> 
> Alex
> 
> 
> Am 26.03.2010 um 10:48 schrieb Manqing Huang:
> 
>> Hello,
>> 
>> I would like to introduce draft-huang-tcpm-tcp-eack-00 to this group. The purpose of the TCP option proposed in this draft is to improve TCP performance by reducing the amount of separate ACK packets when there are multiple TCP connections and each of the connections carries one way traffic. Applications that can benefit from this option include HTTP and FTP.
>> 
>> Comments are appreciated.
>> 
>> Thank you.
>> 
>> Manqing Huang
>> 
>> 
>> The information and any attached documents contained in this message
>> may be confidential and/or legally privileged. The message is intended
>> solely for the addressee(s). If you are not the intended recipient,
>> you are hereby notified that any use, dissemination, or reproduction
>> is strictly prohibited and may be unlawful. If you are not the
>> intended recipient, please contact the sender immediately by return
>> e-mail and destroy all copies of the original message.
>> _______________________________________________
>> tcpm mailing list
>> tcpm@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpm
> 
> 
> The information and any attached documents contained in this message
> may be confidential and/or legally privileged.  The message is
> intended solely for the addressee(s).  If you are not the intended
> recipient, you are hereby notified that any use, dissemination, or
> reproduction is strictly prohibited and may be unlawful.  If you are
> not the intended recipient, please contact the sender immediately by
> return e-mail and destroy all copies of the original message.