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

From: Manqing Huang <[email-masked]>
Date: Fri, 26 Mar 2010 10:48:13 -0700

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.

---

From: Alexander Zimmermann <[email-masked]>
Date: Fri, 26 Mar 2010 19:48:58 +0000

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:

> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Manqing Huang <[email-masked]>
Date: Fri, 26 Mar 2010 17:39:07 -0700

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. 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:[email-masked]]
Sent: Friday, March 26, 2010 12:49 PM
To: Manqing Huang
Cc: [email-masked]
Subject: Re: [tcpm] Introducing draft-huang-tcpm-tcp-eack-00

Hi,

Alex

Am 26.03.2010 um 10:48 schrieb Manqing Huang:

> 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.

---

From: Alexander Zimmermann <[email-masked]>
Date: Wed, 31 Mar 2010 15:10:32 +0000

Hi Manqing,

Am 27.03.2010 um 01:39 schrieb Manqing Huang:

> 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.
>