--- 1/draft-ietf-tcpm-ecnsyn-00.txt 2006-10-24 01:13:17.000000000 +0200 +++ 2/draft-ietf-tcpm-ecnsyn-01.txt 2006-10-24 01:13:17.000000000 +0200 @@ -1,17 +1,17 @@ Internet Engineering Task Force A. Kuzmanovic INTERNET DRAFT Northwestern University -draft-ietf-tcpm-ecnsyn-00.txt S. Floyd +draft-ietf-tcpm-ecnsyn-01.txt S. Floyd ICIR K.K. Ramakrishnan AT&T - January, 2006 + October, 2006 Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. @@ -47,21 +47,25 @@ Setting TCP SYN/ACK packets 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 sender of the SYN/ACK packet must respond to an ECN mark by reducing its initial congestion window from two, three, or four segments to one segment, reducing the subsequent load from that connection on the network. NOTE TO RFC EDITOR: PLEASE DELETE THIS NOTE UPON PUBLICATION. - Changes from draft-ietf-twvsg-ecnsyn: + Changes from draft-ietf-tcpm-ecnsyn-00: + + * Only updating the revision number. + + Changes from draft-ietf-twvsg-ecnsyn-00: * Changed name of draft to draft-ietf-tcpm-ecnsyn. * Added a discussion in Section 3 of "Response to ECN-marking of SYN/ACK packets". Based on suggestions from Mark Allman. * Added a discussion to the Conclusions about adding ECN-capability to relevant set-up packets in other protocols. From a suggestion from Wesley Eddy. @@ -373,21 +377,21 @@ packets should generally be low. In this case, the benefit of making SYN/ACK packets ECN-Capable should be similarly moderate. However, for a congested router with a Drop Tail queue in units of packets or with an AQM mechanism in packet mode, and with no priority queueing for smaller packets, small and large packets should have the same probability of being dropped or marked. In such a case, making SYN/ACK packets ECN-Capable should be of significant benefit. We believe that there are a wide range of behaviors in the real world in terms of the drop or mark behavior at routers as a function of - packet size [Tools, Section 10]. We note that all of these + packet size [Tools] (Section 10). We note that all of these alternatives listed above are available in the NS simulator (Drop Tail queues are by default in units of packets, while the default for RED queue management has been changed from packet mode to byte mode). Response to ECN-marking of SYN/ACK packets: One question is why TCP SYN/ACK packets should be treated differently from other packets in terms of the packet sender's response to an ECN-marked packet. Section 5 of RFC 3168 specifies the following: "Upon the receipt by an ECN-Capable transport of a single CE packet, @@ -564,21 +568,21 @@ 6. Security Considerations TCP packets carrying the ECT codepoint in IP headers can be marked rather than dropped by ECN-capable routers. This raises several security concerns that we discuss below. "Bad" middleboxes: There is a small but decreasing number of middleboxes that drop or reset SYN and SYN/ACK packets based on the ECN-related flags in the - TCP header [MAF05,RFC3360]. While there is no evidence that any + TCP header [MAF05], [RFC3360]. While there is no evidence that any middleboxes drop SYN/ACK packets that contain an ECN-Capable codepoint in the *IP header*, such behavior cannot be excluded. Thus, as specified in Section 2, if a SYN/ACK packet with the ECT codepoint is dropped, the TCP node SHOULD resend the SYN/ACK packet without the ECN-Capable codepoint. Congestion collapse: Because TCP SYN/ACK packets carrying an ECT codepoint could be ECN- marked instead of dropped at an ECN-capable router, the concern is whether this can either invoke congestion, or worsen performance in @@ -612,20 +616,23 @@ retransmission-based reliability in their setup phase (e.g., SCTP, DCCP, HIP, and the like). 8. Acknowledgements We thank Mark Allman, Wesley Eddy, Janardhan Iyengar, and Pasi Sarolahti for feedback on earlier versions of this draft. 9. Normative References + [RFC 2119] S. Bradner, Key words for use in RFCs to Indicate + Requirement Levels, RFC 2119, March 1997. + [RFC3168] K.K. Ramakrishnan, S. Floyd, and D. Black, The Addition of Explicit Congestion Notification (ECN) to IP, RFC 3168, Proposed Standard, September 2001. [RFC3390] M. Allman, S. Floyd, and C. Partridge, Increasing TCP's Initial Window, RFC 3390, October 2002. 10. Informative References [ECN+] A. Kuzmanovic, The Power of Explicit Congestion Notification, @@ -662,21 +669,21 @@ 3360, August 2002. [SCJO01] F. Smith, F. Campos, K. Jeffay, D. Ott, What {TCP/IP} Protocol Headers Can Tell us about the Web, SIGMETRICS, June 2001. [SYN-COOK] Dan J. Bernstein, SYN cookies, 1997, see also [Tools] S. Floyd and E. Kohler, Tools for the Evaluation of Simulation and Testbed Scenarios, Internet-draft draft-irtf-tmrg- - tools-00, work in progress, September 2005. + tools-02, work in progress, June 2006. 11. IANA Considerations There are no IANA considerations regarding this document. AUTHORS' ADDRESSES Aleksandar Kuzmanovic Phone: +1 (847) 467-5519 Northwestern University