idnits 2.17.1 draft-ietf-tsvwg-ecnsyn-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 587. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 598. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 610. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 610. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 579), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 39. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 2119' is mentioned on line 72, but not defined == Missing Reference: 'RFC 3168' is mentioned on line 100, but not defined == Missing Reference: 'Section 10' is mentioned on line 344, but not defined ** Obsolete normative reference: RFC 2414 (Obsoleted by RFC 3390) -- Obsolete informational reference (is this intentional?): RFC 2988 (Obsoleted by RFC 6298) == Outdated reference: A later version (-05) exists of draft-irtf-tmrg-tools-00 Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force A. Kuzmanovic 2 INTERNET DRAFT Northwestern University 3 draft-ietf-tsvwg-ecnsyn-00.txt S. Floyd 4 ICIR 5 K.K. Ramakrishnan 6 AT&T 7 October, 2005 9 Adding Explicit Congestion Notification (ECN) Capability to TCP's 10 SYN/ACK Packets 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on April 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). All Rights Reserved. 41 Abstract 43 This draft specifies a modification to RFC 3168 to allow TCP SYN/ACK 44 packets to be ECN-Capable. For TCP, RFC 3168 only specified setting 45 an ECN-Capable codepoint on data packets, and not on SYN and SYN/ACK 46 packets. However, because of the high cost to the TCP transfer of 47 having a SYN/ACK packet dropped, with the resulting retransmit 48 timeout, this document is specifying the use of ECN for the SYN/ACK 49 packet itself, when sent in response to a SYN packet with the two ECN 50 flags set in the TCP header, indicating a willingness to use ECN. 51 Setting TCP SYN/ACK packets as ECN-Capable can be of great benefit to 52 the TCP connection, avoiding the severe penalty of a retransmit 53 timeout for a connection that has not yet started placing a load on 54 the network. The sender of the SYN/ACK packet must respond to an ECN 55 mark by reducing its initial congestion window from two, three, or 56 four segments to one segment, reducing the subsequent load from that 57 connection on the network. 59 NOTE TO RFC EDITOR: PLEASE DELETE THIS NOTE UPON PUBLICATION. 61 Changes from draft-kuzmanovic-ecn-syn-00.txt: 63 * Changed name of draft to draft-ietf-twvsg-ecnsyn. 65 END OF NOTE TO RFC EDITOR. 67 1. Conventions 69 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 70 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 71 document are to be interpreted as described in [RFC 2119]. 73 1. Introduction 75 TCP's congestion control mechanism has primarily used packet loss as 76 the congestion indication, with packets dropped when buffers 77 overflow. With such tail-drop mechanisms, the packet delay can be 78 high, as the queue at bottleneck routers can be fairly large. 79 Dropping packets only when the queue overflows, and having TCP react 80 only to such losses, results in: 81 1) significantly higher packet delay; 82 2) unnecessarily many packet losses; and 83 3) unfairness due to synchronization effects. 85 The adoption of Active Queue Management (AQM) mechanisms allows 86 better control of bottleneck queues. This use of AQM has the 87 following potential benefits: 88 1) better control of the queue, with reduced queueing delay; 89 2) fewer packet drops; and 90 3) better fairness because of fewer synchronization effects. 92 With the adoption of ECN, performance may be further improved. When 93 the router detects congestion before buffer overflow, the router can 94 provide a congestion indication either by dropping a packet, or by 95 setting the Congestion Experienced (CE) codepoint in the Explicit 96 Congestion Notification (ECN) field in the IP header [RFC3168]. The 97 IETF has standardized the use of the Congestion Experienced (CE) 98 codepoint in the IP header for routers to indicate congestion. For 99 incremental deployment and backwards compatibility, the RFC on ECN 100 [RFC 3168] specifies that routers may mark ECN-capable packets that 101 would otherwise have been dropped, using the Congestion Experienced 102 codepoint in the ECN field. The use of ECN allows TCP to react to 103 congestion while avoiding unnecessary retransmissions and, in some 104 cases, unnecessary retransmit timeouts. Thus, using ECN has several 105 benefits: 107 1) For short transfers, a TCP connection's congestion window may be 108 small. For example, if the current window contains only one packet, 109 and that packet is dropped, TCP will have to wait for a retransmit 110 timeout to recover, reducing its overall throughput. Similarly, if 111 the current window contains only a few packets and one of those 112 packets is dropped, there might not be enough duplicate 113 acknowledgements for a fast retransmission, and the sender might have 114 to wait for a delay of several round-trip times using Limited 115 Transmit [RFC3042]. With the use of ECN, short flows are less likely 116 to have packets dropped, sometimes avoiding unnecessary delays or 117 costly retransmit timeouts. 119 2) While longer flows may not see substantially improved throughput 120 with the use of ECN, they experience lower loss. This may benefit TCP 121 applications that are latency- and loss-sensitive, because of the 122 avoidance of retransmissions. 124 RFC 3168 only specified marking the Congestion Experienced codepoint 125 on TCP's data packets, and not on SYN and SYN/ACK packets. RFC 3168 126 specified the negotiation of the use of ECN between the two TCP end- 127 points in the TCP SYN and SYN-ACK exchange, using flags in the TCP 128 header. Erring on the side of being conservative, RFC 3168 did not 129 specify the use of ECN for the SYN/ACK packet itself. However, 130 because of the high cost to the TCP transfer of having a SYN/ACK 131 packet dropped, with the resulting retransmit timeout, this document 132 is specifying the use of ECN for the SYN/ACK packet itself. This can 133 be of great benefit to the TCP connection, avoiding the severe 134 penalty of a retransmit timeout for a connection that has not yet 135 started placing a load on the network. The sender of the SYN/ACK 136 packet must respond to an ECN mark by reducing its initial congestion 137 window from two, three, or four segments to one segment, reducing the 138 subsequent load from that connection on the network. 140 The use of ECN for SYN/ACK packets has the following potential 141 benefits: 142 1) Avoidance of a retransmit timeout; 143 2) Improvement in the throughput of short connections. 145 This draft specifies a modification to RFC 3168 to allow TCP SYN/ACK 146 packets to be ECN-Capable. Section 2 contains the specification of 147 the change, while Section 3 discusses some of the issues, and Section 148 4 discusses related work. Section 5 contains an evaluation of the 149 proposed change. 151 2. Proposal 153 This section specifies the modification to RFC 3168 to allow TCP 154 SYN/ACK packets to be ECN-Capable. We use the following terminology 155 from RFC 3168: 157 The ECN field in the IP header: 158 o CE: the Congestion Experienced codepoint; and 159 o ECT: either one of the two ECN-Capable Transport codepoints. 161 The ECN flags in the TCP header: 162 o CWR: the Congestion Window Reduced flag; and 163 o ECE: the ECN-Echo flag. 165 ECN-setup packets: 166 o ECN-setup SYN packet: a SYN packet with the ECE and CWR flags; 167 o ECN-setup SYN-ACK packet: a SYN-ACK packet with ECE but not CWR. 169 RFC 3168 in Section 6.1.1. states that "A host MUST NOT set ECT on 170 SYN or SYN-ACK packets." In this section, we specify that a TCP node 171 MAY respond to an ECN-setup SYN packet by setting ECT in the 172 responding ECN-setup SYN/ACK packet, indicating to routers that the 173 SYN/ACK packet is ECN-Capable. This allows a congested router along 174 the path to mark the packet instead of dropping the packet as an 175 indication of congestion. 177 Assume that TCP node A transmits to TCP node B an ECN-setup SYN 178 packet, indicating willingness to use ECN for this connection. As 179 specified by RFC 3168, if TCP node B is willing to use ECN, node B 180 responds with an ECN-setup SYN-ACK packet. 182 Table 1 shows an interchange with the SYN/ACK packet dropped by a 183 congested router. Node B waits for a retransmit timeout, and then 184 retransmits the SYN/ACK packet. 186 --------------------------------------------------------------- 187 TCP Node A Router TCP Node B 188 ---------- ------ ---------- 190 ECN-setup SYN packet ---> 191 ECN-setup SYN packet ---> 193 <--- ECN-setup SYN/ACK, possibly ECT 194 3-second timer set 195 SYN/ACK dropped . 196 . 197 . 198 3-second timer expires 199 <--- ECN-setup SYN/ACK, not ECT 200 <--- ECN-setup SYN/ACK 201 Data/ACK ---> 202 Data/ACK ---> 203 <--- Data (one to four segments) 204 --------------------------------------------------------------- 206 Table 1: SYN exchange with the SYN/ACK packet dropped. 208 If the SYN/ACK packet is dropped in the network, the TCP host (node 209 B) responds by waiting three seconds for the retransmit timer to 210 expire [RFC2988]. If a SYN/ACK packet with the ECT codepoint is 211 dropped, the TCP node SHOULD resend the SYN/ACK packet without the 212 ECN-Capable codepoint. (Although we are not aware of any middleboxes 213 that drop SYN/ACK packets that contain an ECN-Capable codepoint in 214 the IP header, we have learned to design our protocols defensively in 215 this regard [RFC3360].) 217 Table 2 shows an interchange with the SYN/ACK packet sent as ECN- 218 Capable, and ECN-marked instead of dropped at the congested router. 220 --------------------------------------------------------------- 221 TCP Node A Router TCP Node B 222 ---------- ------ ---------- 224 ECN-setup SYN packet ---> 225 ECN-setup SYN packet ---> 227 <--- ECN-setup SYN/ACK, ECT 228 <--- Sets CE on SYN/ACK 229 <--- ECN-setup SYN/ACK, CE 231 Data/ACK, ECN-Echo ---> 232 Data/ACK, ECN-Echo ---> 233 Window reduced to one segment. 234 <--- Data, CWR (one segment only) 235 --------------------------------------------------------------- 237 Table 2: SYN exchange with the SYN/ACK packet marked. 239 If the receiving node (node A) receives a SYN/ACK packet that has 240 been marked by the congested router, with the CE codepoint set, the 241 receiving node MUST respond by setting the ECN-Echo flag in the TCP 242 header of the responding ACK packet. As specified in RFC 3168, the 243 receiving node continues to set the ECN-Echo flag in packets until it 244 receives a packet with the CWR flag set. 246 When the sending node (node B) receives the ECN-Echo packet reporting 247 the Congestion Experienced indication in the SYN/ACK packet, the node 248 MUST set the initial congestion window to one segment, instead of two 249 segments as allowed by [RFC2414], or three or four segments allowed 250 by [RFC3390]. If the sending node (node B) was going to use an 251 initial window of one segment, and receives an ECN-Echo packet 252 informing it of a Congestion Experienced indication on its SYN/ACK 253 packet, the sending node MAY continue to send with an initial window 254 of one segment, without waiting for a retransmit timeout. We note 255 that this updates RFC 3168, which specifies that "the sending TCP 256 MUST reset the retransmit timer on receiving the ECN-Echo packet when 257 the congestion window is one." As specified by RFC 3168, the sending 258 node (node B) also sets the CWR flag in the TCP header of the next 259 packet sent, to acknowledge its receipt of and reaction to the ECN- 260 Echo flag. 262 3. Discussion 264 Motivation: 265 The rationale for the proposed change is the following. When node B 266 receives a TCP SYN packet with ECN-Echo bit set in the TCP header, 267 this indicates that node A is ECN-capable. If node B is also ECN- 268 capable, there are no obstacles to immediately setting one of the 269 ECN-Capable codepoints in the IP header in the responding TCP SYN/ACK 270 packet. 272 There can be a great benefit in setting an ECN-capable codepoint in 273 SYN/ACK packets, as is discussed further in Section 4. Congestion is 274 most likely to occur in the server-to-client direction. As a result, 275 setting an ECN-capable codepoint in SYN/ACK packets can reduce the 276 occurence of three-second retransmit timeouts resulting from the drop 277 of SYN/ACK packets. 279 Flooding attacks: 280 Setting an ECN-Capable codepoint in the responding TCP SYN/ACK 281 packets does not raise any novel security vulnerabilities. For 282 example, provoking servers or hosts to send SYN/ACK packets to a 283 third party in order to perform a "SYN/ACK flood" attack would be 284 greatly inefficient. Third parties would immediately drop such 285 packets, since they would know that they didn't generate the TCP SYN 286 packets in the first place. Moreover, such SYN/ACK attacks would 287 have the same signatures as the existing TCP SYN attacks. Provoking 288 servers or hosts to reply with SYN/ACK packets in order to congest a 289 certain link would also be highly inefficient because SYN ACK packets 290 are small in size. 292 The TCP SYN packet: 293 There are several reasons why an ECN-Capable codepoint MUST NOT be 294 set in the IP header of the initiating TCP SYN packet. First, when 295 the TCP SYN packet is sent, there are no guarantees that the other 296 TCP endpoint (node B in Table 2) is ECN-capable, or that it would be 297 able to understand and react if the ECN CE codepoint was set by a 298 congested router. 300 Second, the ECN-Capable codepoint in TCP SYN packets could be misused 301 by malicious clients to `improve' the well-known TCP SYN attack. By 302 setting an ECN-Capable codepoint in TCP SYN packets, a malicious host 303 might be able to inject a large number of TCP SYN packets through a 304 potentially congested ECN-enabled router, congesting it even further. 306 For both these reasons, we continue the restriction that the TCP SYN 307 packet MUST NOT have the ECN-Capable codepoint in the IP header set. 309 Backwards compatibility: 310 If there are some older TCP implementations that don't respond to the 311 Congestion Experienced codepoint in a SYN/ACK packet, that would not 312 be an insurmountable problem. It would mean that the sender of the 313 SYN/ACK packet would not reduce the initial congestion window from 314 two, three, or four segments down to one segment, as it should. 316 However, the TCP sender would still respond correctly to any 317 subsequent CE indications on data packets later on in the connection. 319 SYN/ACK packets and packet size: 320 There are a number of router buffer architectures that have smaller 321 dropping rates for small (SYN) packets than for large (data) packets. 322 For example, for a Drop Tail queue in units of packets, where each 323 packet takes a single slot in the buffer regardless of packet size, 324 small and large packets are equally likely to be dropped. However, 325 for a Drop Tail queue in units of bytes, small packets are less 326 likely to be dropped than are large ones. Similarly, for RED in 327 packet mode, small and large packets are equally likely to be dropped 328 or marked, while for RED in byte mode, a packet's chance of being 329 dropped or marked is proportional to the packet size in bytes. 331 For a congested router with an AQM mechanism in byte mode, where a 332 packet's chance of being dropped or marked is proportional to the 333 packet size in bytes, the drop or marking rate for TCP SYN/ACK 334 packets should generally be low. In this case, the benefit of making 335 SYN/ACK packets ECN-Capable should be similarly moderate. However, 336 for a congested router with a Drop Tail queue in units of packets or 337 with an AQM mechanism in packet mode, and with no priority queueing 338 for smaller packets, small and large packets should have the same 339 probability of being dropped or marked. In such a case, making 340 SYN/ACK packets ECN-Capable should be of significant benefit. 342 We believe that there are a wide range of behaviors in the real world 343 in terms of the drop or mark behavior at routers as a function of 344 packet size [Tools, Section 10]. We note that all of these 345 alternatives listed above are available in the NS simulator (Drop 346 Tail queues are by default in units of packets, while the default for 347 RED queue management has been changed from packet mode to byte mode). 349 4. Related Work 351 The addition of ECN-capability to TCP's SYN/ACK packets was proposed 352 in [ECN+]. The paper includes an extensive set of simulation and 353 testbed experiments to evaluate the effects of the proposal, using 354 several Active Queue Management (AQM) mechanisms, including Random 355 Early Detection (RED) [RED], Random Exponential Marking (REM) [REM], 356 and Proportional Integrator (PI) [PI]. The performance measures were 357 the end-to-end response times for each request/response pair, and the 358 aggregate throughput on the bottleneck link. The end-to-end response 359 time was computed as the time from the moment when the request for 360 the file is sent to the server, until that file is successfully 361 downloaded by the client. 363 The measurements from [ECN+] showed that setting an ECN-Capable 364 codepoint in the IP packet header in TCP SYN/ACK packets 365 systematically improves performance with all evaluated AQM schemes. 366 When SYN/ACK packets at a congested router are ECN-marked instead of 367 dropped, this can avoid a long initial retransmit timeout, improving 368 the response time for the affected flow dramatically. 370 [ECN+] showed that the impact on aggregate throughput can also be 371 quite significant, because marking SYN ACK packets can prevent larger 372 flows from suffering long timeouts before being "admitted" into the 373 network. In addition, the testbed measurements from [ECN+] showed 374 that Web servers setting the ECN-Capable codepoint in TCP SYN/ACK 375 packets could serve more requests. 377 As a final step, [ECN+] explored the co-existence of flows that do 378 and don't set the ECN-capable codepoint in TCP SYN/ACK packets. The 379 results in [ECN+] confirmed that both types of flows can coexist; 380 flows that apply the change improve their end-to-end performance, 381 while the performance degradation for flows that don't apply the 382 change, as a result of the flows that do apply the change, is 383 marginal. 385 5. Evaluation 387 The addition of ECN-capability to SYN/ACK packets could be of 388 significant benefit for those ECN connections that would have had the 389 SYN/ACK packet dropped in the network, and for which the ECN- 390 Capability would allow the SYN/ACK to be marked rather than dropped. 392 The percent of SYN/ACK packets on a link can be quite high. In 393 particular, measurements on links dominated by Web traffic indicate 394 that 15-20% of the packets can be SYN/ACK packets [SCJO01]. 396 The benefit of adding ECN-capability to SYN/ACK packets depends in 397 part on the size of the data transfer. The drop of a SYN/ACK packet 398 can increase the download time of a short file by an order of 399 magnitude, by requiring a three-second retransmit timeout. For 400 longer-lived flows, the effect of a dropped SYN/ACK packet on file 401 download time is less dramatic. However, even for longer-lived 402 flows, the addition of ECN-capability to SYN/ACK packets can improve 403 the fairness among long-lived flows, as newly-arriving flows would be 404 less likely to have to wait for retransmit timeouts. 406 The question that arises of course is what fraction of connections 407 would see the benefit from making SYN/ACK packets ECN-capable, in a 408 particular scenario? Specifically: 410 (1) What fraction of arriving SYN/ACK packets are dropped at the 411 congested router when the SYN/ACK packets are not ECN-capable? 412 (2) Of those SYN/ACK packets that are dropped, what fraction of those 413 drops would have been ECN-marks instead of drops if the SYN/ACK 414 packets had been ECN-capable? 416 To answer (1), it is necessary to consider not only the level of 417 congestion but also the queue architecture at the congested link. As 418 described in Section 3 above, for some queue architectures small 419 packets are less likely to be dropped than large ones. In such an 420 environment, SYN/ACK packets would have lower packet drop rates; 421 question (1) could not necessarily be inferred from the overall 422 packet drop rate, but could be answered by measuring the drop rate 423 for SYN/ACK packets directly. In such an environment, adding ECN- 424 capability to SYN/ACK packets would be of less dramatic benefit than 425 in environments where all packets are equally likely to be dropped 426 regardless of packet size. 428 As question (2) implies, even if all of the SYN/ACK packets were ECN- 429 capable, there could still be some SYN/ACK packets dropped instead of 430 marked at the congested link; the full answer to question (2) depends 431 on the details of the queue management mechanism at the router. If 432 congestion is sufficiently bad, and the queue management mechanism 433 cannot prevent the buffer from overflowing, then SYN/ACK packets will 434 be dropped rather than marked upon buffer overflow whether or not 435 they are ECN-capable. 437 For some AQM mechanisms, ECN-capable packets are marked instead of 438 dropped any time this is possible, that is, any time the buffer is 439 not yet full. For other AQM mechanisms however, such as the RED 440 mechanism as recommended in [RED], packets are dropped rather than 441 marked when the packet drop/mark rate exceeds a certain threshold, 442 e.g., 10%, even if the packets are ECN-capable. For a router with 443 such an AQM mechanism, when congestion is sufficiently severe to 444 cause a high drop/mark rate, some SYN/ACK packets would be dropped 445 instead of marked whether or not they were ECN-capable. 447 Thus, the degree of benefit of adding ECN-Capability to SYN/ACK 448 packets depends not only on the overall packet drop rate in the 449 network, but also on the queue management architecture at the 450 congested link. 452 6. Security Considerations 454 TCP packets carrying the ECT codepoint in IP headers can be marked 455 rather than dropped by ECN-capable routers. This raises several 456 security concerns that we discuss below. 458 TCP SYN flooding attacks: 459 By setting an ECN-Capable codepoint in TCP SYN packets, a malicious 460 host might be able to inject a large number of TCP SYN packets 461 through a potentially congested ECN-enabled router, congesting it 462 even further. This is one of the reasons why an ECN-Capable codepoint 463 MUST NOT be set in the IP header of the initiating TCP SYN packet. 464 On the other hand, as discussed in Section 3 above, setting an ECN- 465 Capable codepoint in the responding TCP SYN/ACK packet does not raise 466 any novel security vulnerabilities. 468 "Bad" middleboxes: 469 While there is no evidence that any middleboxes drop SYN/ACK packets 470 that contain an ECN-Capable codepoint in the IP header, such behavior 471 cannot be excluded [RFC3360]. Thus, if a SYN/ACK packet with the ECT 472 codepoint is dropped, the TCP node SHOULD resend the SYN/ACK packet 473 without the ECN-Capable codepoint. 475 Congestion collapse: 476 Because TCP SYN/ACK packets carrying an ECT codepoint could be ECN- 477 marked instead of dropped at an ECN-capable router, the concern is 478 whether this can either invoke congestion, or worsen performance in 479 highly congested scenarios. This is not a problem because after 480 learning that the SYN/ACK packet was ECN-marked, the sender of that 481 packet will only send one data packet; in the case that this data 482 packet is ECN-marked, the sender will wait for a retransmission 483 timeout. In addition, routers are free to drop rather than mark 484 arriving packets in times of high congestion, regardless of whether 485 the packets are ECN-capable. 487 7. Conclusions 489 This draft specifies a modification to RFC 3168 to allow TCP nodes to 490 send SYN/ACK packets as being ECN-Capable. Making the SYN/ACK packet 491 ECN-Capable avoids the high cost to a TCP transfer when a SYN/ACK 492 packet is dropped by a congested router, by avoiding the resulting 493 retransmit timeout. This improves the throughput of short 494 connections. The sender of the SYN/ACK packet responds to an ECN 495 mark by reducing its initial congestion window from two, three, or 496 four segments to one segment, reducing the subsequent load from that 497 connection on the network. The addition of ECN-capability to SYN/ACK 498 packets is particularly beneficial in the server-to-client direction, 499 where congestion is more likely to occur. In this case, the initial 500 information provided by the ECN marking in the SYN/ACK packet enables 501 the server to more appropriately adjust the initial load it places on 502 the network. 504 8. Acknowledgements 506 9. Normative References 508 [RFC2414] M. Allman, S. Floyd, and C. Partridge, Increasing TCP's 509 Initial Window, RFC 2414, September 1998. 511 [RFC3168] K.K. Ramakrishnan, S. Floyd, and D. Black, The Addition of 512 Explicit Congestion Notification (ECN) to IP, RFC 3168, Proposed 513 Standard, September 2001. 515 [RFC3390] M. Allman, S. Floyd, and C. Partridge, Increasing TCP's 516 Initial Window, RFC 3390, October 2002. 518 10. Informative References 520 [ECN+] A. Kuzmanovic, The Power of Explicit Congestion Notification, 521 SIGCOMM 2005. 523 [PI] C. Hollot, V. Misra, W. Gong, and D. Towsley, On Designing 524 Improved Controllers for AQM Routers Supporting TCP Flows, INFOCOM, 525 June 2001. 527 [RED] S. Floyd and V. Jacobson, Random Early Detection Gateways for 528 Congestion Avoidance, IEEE/ACM Transactions on Networking, V.1, N.4, 529 1993. 531 [REM] S. Athuraliya, V. Li, S. Low, and Q Yin, REM: Active Queue 532 Management, IEEE Network, V.15, N. 3, May 2001. 534 [RFC2988] V. Paxson and M. Allman, Computing TCP's Retransmission 535 Timer, RFC 2988, November 2000. 537 [RFC3042] M. Allman, H. Balakrishnan, and S. Floyd, Enhancing TCP's 538 Loss Recovery Using Limited Transmit, RFC 3042, Proposed Standard, 539 January 2001. 541 [RFC3360] S. Floyd, Inappropriate TCP Resets Considered Harmful, RFC 542 3360, August 2002. 544 [SCJO01] F. Smith, F. Campos, K. Jeffay, D. Ott, What {TCP/IP} 545 Protocol Headers Can Tell us about the Web, SIGMETRICS, June 2001. 547 [Tools] S. Floyd and E. Kohler, Tools for the Evaluation of 548 Simulation and Testbed Scenarios, Internet-draft draft-irtf-tmrg- 549 tools-00, work in progress, September 2005. 551 11. IANA Considerations 553 There are no IANA considerations regarding this document. 555 AUTHORS' ADDRESSES 557 Aleksandar Kuzmanovic 558 Phone: +1 (847) 467-5519 559 Northwestern University 560 Email: akuzma@northwestern.edu 561 URL: http://cs.northwestern.edu/~a 563 Sally Floyd 564 Phone: +1 (510) 666-2989 565 ICIR (ICSI Center for Internet Research) 566 Email: floyd@icir.org 567 URL: http://www.icir.org/floyd/ 569 K. K. Ramakrishnan 570 Phone: +1 (973) 360-8764 571 AT&T Labs Research 572 Email: kkrama@research.att.com 573 URL: http://www.research.att.com/info/kkrama 575 Full Copyright Statement 577 Copyright (C) The Internet Society 2005. This document is subject 578 to the rights, licenses and restrictions contained in BCP 78, and 579 except as set forth therein, the authors retain all their rights. 581 This document and the information contained herein are provided on 582 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 583 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 584 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 585 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 586 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 587 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 589 Intellectual Property 591 The IETF takes no position regarding the validity or scope of any 592 Intellectual Property Rights or other rights that might be claimed 593 to pertain to the implementation or use of the technology described 594 in this document or the extent to which any license under such 595 rights might or might not be available; nor does it represent that 596 it has made any independent effort to identify any such rights. 597 Information on the procedures with respect to rights in RFC 598 documents can be found in BCP 78 and BCP 79. 600 Copies of IPR disclosures made to the IETF Secretariat and any 601 assurances of licenses to be made available, or the result of an 602 attempt made to obtain a general license or permission for the use 603 of such proprietary rights by implementers or users of this 604 specification can be obtained from the IETF on-line IPR repository 605 at http://www.ietf.org/ipr. 606 The IETF invites any interested party to bring to its attention any 607 copyrights, patents or patent applications, or other proprietary 608 rights that may cover technology that may be required to implement 609 this standard. Please address the information to the IETF at ietf- 610 ipr@ietf.org.