Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets
draft-ietf-tcpm-ecnsyn-10

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    tcpm mailing list <tcpm@ietf.org>, 
    tcpm chair <tcpm-chairs@tools.ietf.org>
Subject: Document Action: 'Adding Explicit Congestion 
         Notification (ECN) Capability to TCP's SYN/ACK Packets' to 
         Experimental RFC 

The IESG has approved the following document:

- 'Adding Explicit Congestion Notification (ECN) Capability to TCP's 
   SYN/ACK Packets '
   <draft-ietf-tcpm-ecnsyn-10.txt> as an Experimental RFC

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

The IESG contact persons are Lars Eggert and Magnus Westerlund.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tcpm-ecnsyn-10.txt

Ballot Text

Technical Summary

  This draft specifies a modification to RFC 3168 to allow TCP SYN/ACK
  packets to be ECN-Capable.  For TCP, RFC 3168 only specifies 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 specifies 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
  retransmit 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 retransmit timer).  This document
  updates RFC 3168

Working Group Summary

  The WG process on this document was fairly smooth.  The most
  interesting bump in the road was that after successfully completing
  the first WG last call, the authors obtained additional simulation
  results that warranted changes in the document and a 2nd WG last call.

Document Quality

  There are existing implementations.  There is (at least) a Linux
  implementation in addition to the simulation code.  No vendors
  have formally indicated plans to the WG to implement the
  modifications in the document, but it is a backwards compatible
  end-host modification, not a full new protocol or one requiring
  additional infrastructure support.

Personnel

  Wesley Eddy (weddy@grc.nasa.gov) was the document shepherd.
  Lars Eggert (lars.eggert@nokia.com) reviewed the document for the IESG.

RFC Editor Note