Re: [tcpm] Introducing draft-huang-tcpm-tcp-eack-00
Manqing Huang <Manqing.Huang@exar.com> Thu, 01 April 2010 21:36 UTC
Return-Path: <Manqing.Huang@exar.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 04F003A698D for <tcpm@core3.amsl.com>; Thu, 1 Apr 2010 14:36:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.818
X-Spam-Level:
X-Spam-Status: No, score=-0.818 tagged_above=-999 required=5 tests=[AWL=0.651, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13]
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 1Hs-H8qCkhRU for <tcpm@core3.amsl.com>; Thu, 1 Apr 2010 14:36:04 -0700 (PDT)
Received: from smtp1.exar.com (webmail.exar.com [204.154.183.83]) by core3.amsl.com (Postfix) with ESMTP id 0392F3A6888 for <tcpm@ietf.org>; Thu, 1 Apr 2010 14:36:03 -0700 (PDT)
Received: from FRE1EXCH02.hq.exar.com ([fe80::e9a7:6160:4e13:1677]) by fre1-cas ([10.127.1.162]) with mapi; Thu, 1 Apr 2010 14:36:36 -0700
From: Manqing Huang <Manqing.Huang@exar.com>
To: "mallman@icir.org" <mallman@icir.org>
Date: Thu, 01 Apr 2010 14:36:35 -0700
Thread-Topic: [tcpm] Introducing draft-huang-tcpm-tcp-eack-00
Thread-Index: AcrR2ufNsCZQLrJwQRCAnqYtlK6crAACD/Sw
Message-ID: <FCA91A92EE52B041906A0358FC28FCC38EED749D45@FRE1EXCH02.hq.exar.com>
References: <FCA91A92EE52B041906A0358FC28FCC38EED595E83@FRE1EXCH02.hq.exar.com> <20100401203543.BD0FBC9A1C1@lawyers.icir.org>
In-Reply-To: <20100401203543.BD0FBC9A1C1@lawyers.icir.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
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: Thu, 01 Apr 2010 21:36:05 -0000
Mark, Thank you for the comments. I read RFC 5690 and thought the ACK congestion control will mitigate the issue I am describing. Manqing -----Original Message----- From: mallman@icir.org [mailto:mallman@icir.org] Sent: Thursday, April 01, 2010 1:36 PM To: Manqing Huang Cc: tcpm@ietf.org Subject: Re: [tcpm] Introducing draft-huang-tcpm-tcp-eack-00 > 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. I quickly looked at the draft. Three bits ... (1) Have a look at RFC 5690 on ACK congestion control that tries to adapt the number of pure ACKs sent with the network conditions. (2) It seems to me to be a fairly bad idea to try to exchange state about some connection on an independent connection. Seems like a recipe for a big mess. (3) For this to even have a shot (as Alexander previously mentioned) the traffic pattern would have to be Just So. I.e., you'd have to be sending from A->B on one connection and receiving from B->A on another. That seems implausible to me. You say HTTP and FTP can benefit, but I doubt it. How many times are you fetching a file via FTP while you're also sending a file to the same endpoint? How much do HTTP clients really send? Sure, sometimes they upload pictures and video. But, most of the time they send a few hundred bytes of request and thats it. Not much room for piggybacking. Seems that regardless of whether we could engineer some cross- connection scheme we should have some idea that it'd be Really Useful. Luckily, that can be assessed via looking at network traffic and assessing the symmetry (i.e., the opportunities for piggybacking). That seems like it should be the first step because without that the motivation seems too far fetched to even worry about the details of the proposal. allman 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] Introducing draft-huang-tcpm-tcp-eack-00 Manqing Huang
- Re: [tcpm] Introducing draft-huang-tcpm-tcp-eack-… Alexander Zimmermann
- Re: [tcpm] Introducing draft-huang-tcpm-tcp-eack-… Manqing Huang
- Re: [tcpm] Introducing draft-huang-tcpm-tcp-eack-… Alexander Zimmermann
- Re: [tcpm] Introducing draft-huang-tcpm-tcp-eack-… Mark Allman
- Re: [tcpm] Introducing draft-huang-tcpm-tcp-eack-… Manqing Huang