draft-ietf-tcpm-ecnsyn-09.txt   draft-ietf-tcpm-ecnsyn-10.txt 
Internet Engineering Task Force A. Kuzmanovic Internet Engineering Task Force A. Kuzmanovic
INTERNET-DRAFT A. Mondal INTERNET-DRAFT A. Mondal
Intended status: Experimental Northwestern University Intended status: Experimental Northwestern University
Expires: 13 November 2009 S. Floyd Expires: 25 November 2009 S. Floyd
ICSI ICSI
K.K. Ramakrishnan K.K. Ramakrishnan
AT&T AT&T
Adding Explicit Congestion Notification (ECN) Capability Adding Explicit Congestion Notification (ECN) Capability
to TCP's SYN/ACK Packets to TCP's SYN/ACK Packets
draft-ietf-tcpm-ecnsyn-09.txt draft-ietf-tcpm-ecnsyn-10.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
skipping to change at page 2, line 8 skipping to change at page 2, line 8
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on 13 November 2009. This Internet-Draft will expire on 25 November 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 9 skipping to change at page 3, line 9
from that connection on the network. If instead the SYN/ACK packet from that connection on the network. If instead the SYN/ACK packet
is dropped, or for some other reason the TCP responder does not is dropped, or for some other reason the TCP responder does not
receive an acknowledgement in the specified time, the TCP responder receive an acknowledgement in the specified time, the TCP responder
follows TCP standards for a dropped SYN/ACK packet (setting the follows TCP standards for a dropped SYN/ACK packet (setting the
retransmission timer). retransmission timer).
Table of Contents Table of Contents
1. Introduction ....................................................6 1. Introduction ....................................................6
2. Conventions and Terminology .....................................8 2. Conventions and Terminology .....................................8
3. Specification ...................................................8 3. Specification ...................................................9
3.1. SYN/ACK Packets Dropped in the Network .....................9 3.1. SYN/ACK Packets Dropped in the Network .....................9
3.2. SYN/ACK Packets ECN-Marked in the Network .................10 3.2. SYN/ACK Packets ECN-Marked in the Network .................10
3.3. Management Interface ......................................12 3.3. Management Interface ......................................13
4. Discussion .....................................................13 4. Discussion .....................................................14
4.1. Flooding Attacks ..........................................13 4.1. Flooding Attacks ..........................................14
4.2. The TCP SYN Packet ........................................13 4.2. The TCP SYN Packet ........................................14
4.3. SYN/ACK Packets and Packet Size ...........................14 4.3. SYN/ACK Packets and Packet Size ...........................15
4.4. Response to ECN-marking of SYN/ACK Packets ................14 4.4. Response to ECN-marking of SYN/ACK Packets ................15
5. Related Work ...................................................16 5. Related Work ...................................................17
6. Performance Evaluation .........................................17 6. Performance Evaluation .........................................17
6.1. The Costs and Benefit of Adding ECN-Capability ............17 6.1. The Costs and Benefit of Adding ECN-Capability ............17
6.2. An Evaluation of Different Responses to ECN-Marked SYN/ACK 6.2. An Evaluation of Different Responses to ECN-Marked SYN/ACK
Packets ........................................................18 Packets ........................................................19
7. Security Considerations ........................................19 6.3. Experiments ...............................................20
7.1. 'Bad' Routers or Middleboxes ..............................19 7. Security Considerations ........................................20
7.2. Congestion Collapse .......................................20 7.1. 'Bad' Routers or Middleboxes ..............................20
8. Conclusions ....................................................20 7.2. Congestion Collapse .......................................21
9. Acknowledgements ...............................................21 8. Conclusions ....................................................21
A. Report on Simulations ..........................................21 9. Acknowledgements ...............................................22
A.1. Simulations with RED in Packet Mode .......................22 A. Report on Simulations ..........................................22
A.2. Simulations with RED in Byte Mode .........................26 A.1. Simulations with RED in Packet Mode .......................23
B. Issues of Incremental Deployment ...............................28 A.2. Simulations with RED in Byte Mode .........................28
Informative References ............................................31 B. Issues of Incremental Deployment ...............................30
IANA Considerations ...............................................32 Normative References ..............................................33
Informative References ............................................33
IANA Considerations ...............................................34
NOTE TO RFC EDITOR: PLEASE DELETE THIS NOTE UPON PUBLICATION. NOTE TO RFC EDITOR: PLEASE DELETE THIS NOTE UPON PUBLICATION.
Changes from draft-ietf-tcpm-ecnsyn-09:
* Added back Normative References and RFC 2119.
(These were deleted accidentally.)
IESG feedback from Pasi Eronen.
* Added Section 6.3 on a discussion of possible experiments.
IESG Feedback from Tim Polk.
Changes from draft-ietf-tcpm-ecnsyn-08: Changes from draft-ietf-tcpm-ecnsyn-08:
* Minor editing and bug-fixes. Feedback from Anil Agarwal and * Minor editing and bug-fixes. Feedback from Anil Agarwal and
Alfred Hoenes. Alfred Hoenes.
* Changed the specification so that after the first SYN/ACK packet * Changed the specification so that after the first SYN/ACK packet
is ECN-marked, and the responder receives an ECN-Echo, the is ECN-marked, and the responder receives an ECN-Echo, the
responder does not set the CWR flag in the second SYN/ACK packet. responder does not set the CWR flag in the second SYN/ACK packet.
We also specified that on receiving the non-ECN-marked SYN/ACK We also specified that on receiving the non-ECN-marked SYN/ACK
packet, the TCP initiator clears the ECN-Echo flag on replying packet, the TCP initiator clears the ECN-Echo flag on replying
skipping to change at page 8, line 18 skipping to change at page 8, line 28
2) Improvement in the throughput of short connections. 2) Improvement in the throughput of short connections.
This draft specifies a modification to RFC 3168 [RFC3168] to allow This draft specifies a modification to RFC 3168 [RFC3168] to allow
TCP SYN/ACK packets to be ECN-Capable. Section 3 contains the TCP SYN/ACK packets to be ECN-Capable. Section 3 contains the
specification of the change, while Section 4 discusses some of the specification of the change, while Section 4 discusses some of the
issues, and Section 5 discusses related work. Section 6 contains an issues, and Section 5 discusses related work. Section 6 contains an
evaluation of the specified change. evaluation of the specified change.
2. Conventions and Terminology 2. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
We use the following terminology from RFC 3168 [RFC3168]: We use the following terminology from RFC 3168 [RFC3168]:
The ECN field in the IP header: The ECN field in the IP header:
o CE: the Congestion Experienced codepoint; and o CE: the Congestion Experienced codepoint; and
o ECT: either one of the two ECN-Capable Transport codepoints. o ECT: either one of the two ECN-Capable Transport codepoints.
The ECN flags in the TCP header: The ECN flags in the TCP header:
o CWR: the Congestion Window Reduced flag; and o CWR: the Congestion Window Reduced flag; and
o ECE: the ECN-Echo flag. o ECE: the ECN-Echo flag.
skipping to change at page 19, line 23 skipping to change at page 20, line 16
Our conclusions are that ECN+/TryOnce is safe, and has significant Our conclusions are that ECN+/TryOnce is safe, and has significant
benefits to the user, and avoids the problems of ECN+ or ECN+/Wait benefits to the user, and avoids the problems of ECN+ or ECN+/Wait
under extreme levels of congestion. As a consequence, this document under extreme levels of congestion. As a consequence, this document
specifies the use of ECN+/TryOnce. specifies the use of ECN+/TryOnce.
[Note: We only discovered the occasional congestion-related problems [Note: We only discovered the occasional congestion-related problems
of ECN+ and of ECN+/Wait when re-running the simulations with an of ECN+ and of ECN+/Wait when re-running the simulations with an
updated version of the ns-2 simulator, after the internet-draft had updated version of the ns-2 simulator, after the internet-draft had
almost completed the standardization process.] almost completed the standardization process.]
6.3. Experiments
This section discusses experiments that would be useful before a
widespread deployment of ECN-Capability for TCP SYN/ACK packets.
Section 7.1 below discusses some of the know deployment problems of
ECN, in terms of routers or middleboxes that react inappropriately to
packets that use ECN codepoints in the IP or TCP packet headers. One
goal of a measurement study of ECN-Capablility for TCP SYN/ACK
packets would be to determine if there were any routers or
middleboxes that react inappropriately to TCP SYN/ACK packets
containing an ECN-Capable or CE codepoint in the IP header. A second
goal of a measurement study would be to check the deployment status
of older TCP implementations that are ECN-Capable, but that don't
respond to ECN-Capability for SYN/ACK packets. (This is discussed in
more detail in Appendix B below.)
Following the discussion in Section 6.2, an experimental study could
explore the use of ECN-Capability for TCP SYN/ACK packets in highly-
congested environments with ECN-capable routers.
7. Security Considerations 7. Security Considerations
TCP packets carrying the ECT codepoint in IP headers can be marked TCP packets carrying the ECT codepoint in IP headers can be marked
rather than dropped by ECN-capable routers. This raises several rather than dropped by ECN-capable routers. This raises several
security concerns that we discuss below. security concerns that we discuss below.
7.1. 'Bad' Routers or Middleboxes 7.1. 'Bad' Routers or Middleboxes
There are a number of known deployment problems from using ECN with There are a number of known deployment problems from using ECN with
TCP traffic in the Internet. The first reported problem, dating back TCP traffic in the Internet. The first reported problem, dating back
skipping to change at page 31, line 8 skipping to change at page 33, line 8
packet that is ECN-marked, but where the ECN mark is ignored by the packet that is ECN-marked, but where the ECN mark is ignored by the
TCP initiator. However, a TCP responder *can* detect if a SYN/ACK TCP initiator. However, a TCP responder *can* detect if a SYN/ACK
packet is sent as ECN-capable and not reported as ECN-marked, but packet is sent as ECN-capable and not reported as ECN-marked, but
data packets are dropped or marked from the initial window of data. data packets are dropped or marked from the initial window of data.
We will call this scenario "initial-window-congestion". If a web We will call this scenario "initial-window-congestion". If a web
server frequently experienced initial-window congestion (without server frequently experienced initial-window congestion (without
SYN/ACK congestion), then the web server *might* be experiencing SYN/ACK congestion), then the web server *might* be experiencing
backwards compatibility problems with ECN-Capable SYN/ACK packets, backwards compatibility problems with ECN-Capable SYN/ACK packets,
and could respond by not sending SYN/ACK packets as ECN-Capable. and could respond by not sending SYN/ACK packets as ECN-Capable.
Normative References
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981.
[RFC2119] S. Bradner, Key Words For Use in RFCs to Indicate
Requirement Levels, RFC 2119.
[RFC2988] V. Paxson and M. Allman, Computing TCP's Retransmission
Timer, RFC 2988, November 2000.
[RFC3168] K.K. Ramakrishnan, S. Floyd, and D. Black, The Addition of
Explicit Congestion Notification (ECN) to IP, RFC 3168, Proposed
Standard, September 2001.
Informative References Informative References
[ECN+] A. Kuzmanovic, The Power of Explicit Congestion Notification, [ECN+] A. Kuzmanovic, The Power of Explicit Congestion Notification,
SIGCOMM 2005. SIGCOMM 2005.
[ECN-SYN] ECN-SYN web page with simulation scripts, URL [ECN-SYN] ECN-SYN web page with simulation scripts, URL
"http://www.icir.org/floyd/ecn-syn". "http://www.icir.org/floyd/ecn-syn".
[F07] S. Floyd, "[BEHAVE] Response of firewalls and middleboxes to [F07] S. Floyd, "[BEHAVE] Response of firewalls and middleboxes to
TCP SYN packets that are ECN-Capable?", August 2, 2007, email sent to TCP SYN packets that are ECN-Capable?", August 2, 2007, email sent to
skipping to change at page 31, line 41 skipping to change at page 34, line 9
Improved Controllers for AQM Routers Supporting TCP Flows, April Improved Controllers for AQM Routers Supporting TCP Flows, April
1998. 1998.
[RED] Floyd, S., and Jacobson, V. Random Early Detection gateways [RED] Floyd, S., and Jacobson, V. Random Early Detection gateways
for Congestion Avoidance . IEEE/ACM Transactions on Networking, V.1 for Congestion Avoidance . IEEE/ACM Transactions on Networking, V.1
N.4, August 1993. N.4, August 1993.
[REM] S. Athuraliya, V. H. Li, S. H. Low and Q. Yin, REM: Active [REM] S. Athuraliya, V. H. Li, S. H. Low and Q. Yin, REM: Active
Queue Management, IEEE Network, May 2001. Queue Management, IEEE Network, May 2001.
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981.
[RFC2309] B. Braden et al., Recommendations on Queue Management and [RFC2309] B. Braden et al., Recommendations on Queue Management and
Congestion Avoidance in the Internet, RFC 2309, April 1998. Congestion Avoidance in the Internet, RFC 2309, April 1998.
[RFC2581] M. Allman, V. Paxson, and W. Stevens, TCP Congestion [RFC2581] M. Allman, V. Paxson, and W. Stevens, TCP Congestion
Control, RFC 2581, April 1999. Control, RFC 2581, April 1999.
[RFC2988] V. Paxson and M. Allman, Computing TCP's Retransmission
Timer, RFC 2988, November 2000.
[RFC3042] M. Allman, H. Balakrishnan, and S. Floyd, Enhancing TCP's [RFC3042] M. Allman, H. Balakrishnan, and S. Floyd, Enhancing TCP's
Loss Recovery Using Limited Transmit, RFC 3042, Proposed Standard, Loss Recovery Using Limited Transmit, RFC 3042, Proposed Standard,
January 2001. January 2001.
[RFC3168] K.K. Ramakrishnan, S. Floyd, and D. Black, The Addition of
Explicit Congestion Notification (ECN) to IP, RFC 3168, Proposed
Standard, September 2001.
[RFC3360] S. Floyd, Inappropriate TCP Resets Considered Harmful, RFC [RFC3360] S. Floyd, Inappropriate TCP Resets Considered Harmful, RFC
3360, August 2002. 3360, August 2002.
[RFC3390] M. Allman, S. Floyd, and C. Partridge, Increasing TCP's [RFC3390] M. Allman, S. Floyd, and C. Partridge, Increasing TCP's
Initial Window, RFC 3390, October 2002. Initial Window, RFC 3390, October 2002.
[RFC4987] W. Eddy, TCP SYN Flooding Attacks and Common Mitigations, [RFC4987] W. Eddy, TCP SYN Flooding Attacks and Common Mitigations,
RFC 4987, August 2007. RFC 4987, August 2007.
[SCJO01] F. Smith, F. Campos, K. Jeffay, and D. Ott, What TCP/IP [SCJO01] F. Smith, F. Campos, K. Jeffay, and D. Ott, What TCP/IP
 End of changes. 13 change blocks. 
33 lines changed or deleted 74 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/