Network Working Group A. Kuzmanovic
Request for Comments: 5562 A. Mondal
Category: Experimental Northwestern University
S. Floyd
ICSI
K. Ramakrishnan
AT&T Labs Research
June 2009
Adding Explicit Congestion Notification (ECN) Capability
to TCP's SYN/ACK Packets
Status of This Memo
This memo defines an Experimental Protocol for the Internet
community. It does not specify an Internet standard of any kind.
Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Kuzmanovic, et al. Experimental [Page 1]RFC 5562 ECN and SYN/ACK Packets June 2009Abstract
The proposal in this document is Experimental. While it may be
deployed in the current Internet, it does not represent a consensus
that this is the best possible mechanism for the use of Explicit
Congestion Notification (ECN) in TCP SYN/ACK packets.
This document describes an optional, experimental modification to RFC
3168 to allow TCP SYN/ACK packets to be ECN-Capable. For TCP, RFC
3168 specifies setting an ECN-Capable codepoint on data packets, but
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 retransmission timeout, this document describes 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 the initial TCP SYN/ACK packet as
ECN-Capable can be of great benefit to the TCP connection, avoiding
the severe penalty of a retransmission timeout for a connection that
has 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 an ECN-
marked SYN/ACK packet by resending a SYN/ACK packet that is not ECN-
Capable. If the resent SYN/ACK packet is acknowledged, then the TCP
responder reduces its initial congestion window from two, three, or
four segments to one segment, thereby reducing the subsequent load
from that connection on the network. If instead the SYN/ACK packet
is dropped, or for some other reason the TCP responder does not
receive an acknowledgement in the specified time, the TCP responder
follows TCP standards for a dropped SYN/ACK packet (setting the
retransmission timer).
Kuzmanovic, et al. Experimental [Page 2]RFC 5562 ECN and SYN/ACK Packets June 2009Table of Contents
1. Introduction ....................................................3
2. Conventions and Terminology .....................................5
3. Specification ...................................................6
3.1. SYN/ACK Packets Dropped in the Network ....................7
3.2. SYN/ACK Packets ECN-Marked in the Network .................8
3.3. Management Interface .....................................10
4. Discussion .....................................................11
4.1. Flooding Attacks .........................................11
datatracker.ietf.org