Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets
draft-ietf-tsvwg-ecnsyn-00
| Document | Type | Replaced Internet-Draft (tsvwg WG) | |
|---|---|---|---|
| Last updated | 2015-10-14 (latest revision 2005-11-21) | ||
| Replaces | draft-kuzmanovic-ecn-syn | ||
| Replaced by | draft-ietf-tcpm-ecnsyn | ||
| Stream | IETF | ||
| Intended RFC status | (None) | ||
| Formats |
Expired & archived
plain text
pdf
html
bibtex
|
||
| Stream | WG state | WG Document | |
| Document shepherd | No shepherd assigned | ||
| IESG | IESG state | Replaced by draft-ietf-tcpm-ecnsyn | |
| Consensus Boilerplate | Unknown | ||
| Telechat date | |||
| Responsible AD | Allison Mankin | ||
| Send notices to | (None) | ||
https://www.ietf.org/archive/id/draft-ietf-tsvwg-ecnsyn-00.txt
Abstract
This draft specifies a modification to RFC 3168 to allow TCP SYN/ACK packets to be ECN-Capable. For TCP, RFC 3168 only specified setting an ECN-Capable codepoint on data packets, and not on SYN and SYN/ACK packets. However, because of the high cost to the TCP transfer of having a SYN/ACK packet dropped, with the resulting retransmit timeout, this document is specifying the use of ECN for the SYN/ACK packet itself, when sent in response to a SYN packet with the two ECN flags set in the TCP header, indicating a willingness to use ECN. Setting TCP SYN/ACK packets as ECN-Capable can be of great benefit to the TCP connection, avoiding the severe penalty of a retransmit timeout for a connection that has not yet started placing a load on the network. The sender of the SYN/ACK packet must respond to an ECN mark by reducing its initial congestion window from two, three, or four segments to one segment, reducing the subsequent load from that connection on the network.
Authors
Aleksandar Kuzmanovic (akuzma@northwestern.edu)
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)