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.