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

Mark Allman <mallman@icir.org> Thu, 01 April 2010 20:35 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 8F29B3A68D4 for <tcpm@core3.amsl.com>; Thu, 1 Apr 2010 13:35:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.01
X-Spam-Level:
X-Spam-Status: No, score=-4.01 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, 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 ijZbORE0WPDH for <tcpm@core3.amsl.com>; Thu, 1 Apr 2010 13:35:12 -0700 (PDT)
Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 99F123A6847 for <tcpm@ietf.org>; Thu, 1 Apr 2010 13:35:12 -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 o31KZhWZ015786; Thu, 1 Apr 2010 13:35:44 -0700 (PDT)
Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id BD0FBC9A1C1; Thu, 1 Apr 2010 16:35:43 -0400 (EDT)
To: Manqing Huang <Manqing.Huang@exar.com>
From: Mark Allman <mallman@icir.org>
In-Reply-To: <FCA91A92EE52B041906A0358FC28FCC38EED595E83@FRE1EXCH02.hq.exar.com>
Organization: International Computer Science Institute (ICSI)
Song-of-the-Day: The Joker
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="--------ma927-1"; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Thu, 01 Apr 2010 16:35:43 -0400
Sender: mallman@icir.org
Message-Id: <20100401203543.BD0FBC9A1C1@lawyers.icir.org>
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
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: Thu, 01 Apr 2010 20:35:16 -0000

> 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