TCP Extended Acknowledgment Options
draft-huang-tsvwg-tcp-eack-00
Document | Type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
---|---|---|---|
Author | Manqing Huang | ||
Last updated | 2010-02-26 | ||
RFC stream | (None) | ||
Intended RFC status | (None) | ||
Formats | |||
Stream | Stream state | (No stream defined) | |
Consensus boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | Expired | |
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
TCP may experience asymmetric bi-directional performance and poor over all performance when acknowledgments (ACKs) are sent by separate packets instead of being piggybacked by data packets. Between two TCP end points, when two-way traffic flows do not share the same TCP connection, the increase of traffic volume in one direction consumes more bandwidth in the reverse direction by generating more separate ACK packets, potentially causing more congestions in the reverse direction. An Extended Acknowledgment (EACK) mechanism can help overcome these limitations. The receiving TCP sends back EACK packets to the sender informing the sender of data, including data of the current TCP connection and data of other eligible connections, that have been received. EACK thus reduces the need for separate ACK packets and improves the bi-directional symmetry and over all throughput. This memo proposes an implementation of EACK and discusses its related issues.
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)