[rfc-dist] RFC 5562 on Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets

A new Request for Comments is now available in online RFC libraries.

        RFC 5562

        Title:      Adding Explicit Congestion Notification (ECN) 
                    Capability to TCP's SYN/ACK Packets 
        Author:     A. Kuzmanovic, A. Mondal,
                    S. Floyd, K. Ramakrishnan
        Status:     Experimental
        Date:       June 2009
        Mailbox:    akuzma at northwestern.edu, 
                    a-mondal at northwestern.edu, 
                    floyd at icir.org, kkrama at research.att.com
        Pages:      33
        Characters: 77110
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-tcpm-ecnsyn-10.txt

        URL:        http://www.rfc-editor.org/rfc/rfc5562.txt

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).  This memo defines an Experimental Protocol for the Internet community.

This document is a product of the TCP Maintenance and Minor Extensions Working Group of the IETF.

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

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor at rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

The RFC Editor Team
USC/Information Sciences Institute