Search RFCs

RFC Editor

File formats:

Status:

EXPERIMENTAL

Authors:

A. Kuzmanovic
A. Mondal
S. Floyd
K. Ramakrishnan

Stream:

IETF

Source:

tcpm (wit)

Cite this RFC:TXT  | XML  |  BibTeX

DOI:  https://doi.org/10.17487/RFC5562

Discuss this RFC: Send questions or comments to the mailing listtcpm@ietf.org

Other actions:Submit Errata  | Find IPR Disclosures from the IETF  | View History of RFC 5562

Abstract

The proposal in this document is Experimental. While it may bedeployed in the current Internet, it does not represent a consensusthat this is the best possible mechanism for the use of ExplicitCongestion Notification (ECN) in TCP SYN/ACK packets.

This document describes an optional, experimental modification to RFC3168 to allow TCP SYN/ACK packets to be ECN-Capable. For TCP, RFC3168 specifies setting an ECN-Capable codepoint on data packets, butnot on SYN and SYN/ACK packets. However, because of the high cost tothe TCP transfer of having a SYN/ACK packet dropped, with theresulting retransmission timeout, this document describes the use ofECN for the SYN/ACK packet itself, when sent in response to a SYNpacket with the two ECN flags set in the TCP header, indicating awillingness to use ECN. Setting the initial TCP SYN/ACK packet asECN-Capable can be of great benefit to the TCP connection, avoidingthe severe penalty of a retransmission timeout for a connection thathas not yet started placing a load on the network. The TCP responder(the sender of the SYN/ACK packet) must reply to a report of anECN-marked SYN/ACK packet by resending a SYN/ACK packet that is notECN-Capable. If the resent SYN/ACK packet is acknowledged, then theTCP responder reduces its initial congestion window from two, three,or four segments to one segment, thereby reducing the subsequent loadfrom that connection on the network. If instead the SYN/ACK packet isdropped, or for some other reason the TCP responder does not receivean acknowledgement in the specified time, the TCP responder followsTCP standards for a dropped SYN/ACK packet (setting the retransmissiontimer). This memo defines an Experimental Protocol for the Internet community.

For the definition ofStatus,seeRFC 2026.

For the definition ofStream, seeRFC 8729.