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

[Mark Allman <[e-mail]>]

> 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