idnits 2.17.1 draft-kuzmanovic-ecn-syn-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 579. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 590. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 602. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 602. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 571), 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 64, but not defined == Missing Reference: 'RFC 3168' is mentioned on line 92, but not defined == Missing Reference: 'Section 10' is mentioned on line 336, 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-kuzmanovic-ecn-syn-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 1. Conventions 61 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 62 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 63 document are to be interpreted as described in [RFC 2119]. 65 1. Introduction 67 TCP's congestion control mechanism has primarily used packet loss as 68 the congestion indication, with packets dropped when buffers 69 overflow. With such tail-drop mechanisms, the packet delay can be 70 high, as the queue at bottleneck routers can be fairly large. 71 Dropping packets only when the queue overflows, and having TCP react 72 only to such losses, results in: 73 1) significantly higher packet delay; 74 2) unnecessarily many packet losses; and 75 3) unfairness due to synchronization effects. 77 The adoption of Active Queue Management (AQM) mechanisms allows 78 better control of bottleneck queues. This use of AQM has the 79 following potential benefits: 80 1) better control of the queue, with reduced queueing delay; 81 2) fewer packet drops; and 82 3) better fairness because of fewer synchronization effects. 84 With the adoption of ECN, performance may be further improved. When 85 the router detects congestion before buffer overflow, the router can 86 provide a congestion indication either by dropping a packet, or by 87 setting the Congestion Experienced (CE) codepoint in the Explicit 88 Congestion Notification (ECN) field in the IP header [RFC3168]. The 89 IETF has standardized the use of the Congestion Experienced (CE) 90 codepoint in the IP header for routers to indicate congestion. For 91 incremental deployment and backwards compatibility, the RFC on ECN 92 [RFC 3168] specifies that routers may mark ECN-capable packets that 93 would otherwise have been dropped, using the Congestion Experienced 94 codepoint in the ECN field. The use of ECN allows TCP to react to 95 congestion while avoiding unnecessary retransmissions and, in some 96 cases, unnecessary retransmit timeouts. Thus, using ECN has several 97 benefits: 99 1) For short transfers, a TCP connection's congestion window may be 100 small. For example, if the current window contains only one packet, 101 and that packet is dropped, TCP will have to wait for a retransmit 102 timeout to recover, reducing its overall throughput. Similarly, if 103 the current window contains only a few packets and one of those 104 packets is dropped, there might not be enough duplicate 105 acknowledgements for a fast retransmission, and the sender might have 106 to wait for a delay of several round-trip times using Limited 107 Transmit [RFC3042]. With the use of ECN, short flows are less likely 108 to have packets dropped, sometimes avoiding unnecessary delays or 109 costly retransmit timeouts. 111 2) While longer flows may not see substantially improved throughput 112 with the use of ECN, they experience lower loss. This may benefit TCP 113 applications that are latency- and loss-sensitive, because of the 114 avoidance of retransmissions. 116 RFC 3168 only specified marking the Congestion Experienced codepoint 117 on TCP's data packets, and not on SYN and SYN/ACK packets. RFC 3168 118 specified the negotiation of the use of ECN between the two TCP end- 119 points in the TCP SYN and SYN-ACK exchange, using flags in the TCP 120 header. Erring on the side of being conservative, RFC 3168 did not 121 specify the use of ECN for the SYN/ACK packet itself. However, 122 because of the high cost to the TCP transfer of having a SYN/ACK 123 packet dropped, with the resulting retransmit timeout, this document 124 is specifying the use of ECN for the SYN/ACK packet itself. This can 125 be of great benefit to the TCP connection, avoiding the severe 126 penalty of a retransmit timeout for a connection that has not yet 127 started placing a load on the network. The sender of the SYN/ACK 128 packet must respond to an ECN mark by reducing its initial congestion 129 window from two, three, or four segments to one segment, reducing the 130 subsequent load from that connection on the network. 132 The use of ECN for SYN/ACK packets has the following potential 133 benefits: 134 1) Avoidance of a retransmit timeout; 135 2) Improvement in the throughput of short connections. 137 This draft specifies a modification to RFC 3168 to allow TCP SYN/ACK 138 packets to be ECN-Capable. Section 2 contains the specification of 139 the change, while Section 3 discusses some of the issues, and Section 140 4 discusses related work. Section 5 contains an evaluation of the 141 proposed change. 143 2. Proposal 145 This section specifies the modification to RFC 3168 to allow TCP 146 SYN/ACK packets to be ECN-Capable. We use the following terminology 147 from RFC 3168: 149 The ECN field in the IP header: 150 o CE: the Congestion Experienced codepoint; and 151 o ECT: either one of the two ECN-Capable Transport codepoints. 153 The ECN flags in the TCP header: 154 o CWR: the Congestion Window Reduced flag; and 155 o ECE: the ECN-Echo flag. 157 ECN-setup packets: 158 o ECN-setup SYN packet: a SYN packet with the ECE and CWR flags; 159 o ECN-setup SYN-ACK packet: a SYN-ACK packet with ECE but not CWR. 161 RFC 3168 in Section 6.1.1. states that "A host MUST NOT set ECT on 162 SYN or SYN-ACK packets." In this section, we specify that a TCP node 163 MAY respond to an ECN-setup SYN packet by setting ECT in the 164 responding ECN-setup SYN/ACK packet, indicating to routers that the 165 SYN/ACK packet is ECN-Capable. This allows a congested router along 166 the path to mark the packet instead of dropping the packet as an 167 indication of congestion. 169 Assume that TCP node A transmits to TCP node B an ECN-setup SYN 170 packet, indicating willingness to use ECN for this connection. As 171 specified by RFC 3168, if TCP node B is willing to use ECN, node B 172 responds with an ECN-setup SYN-ACK packet. 174 Table 1 shows an interchange with the SYN/ACK packet dropped by a 175 congested router. Node B waits for a retransmit timeout, and then 176 retransmits the SYN/ACK packet. 178 --------------------------------------------------------------- 179 TCP Node A Router TCP Node B 180 ---------- ------ ---------- 182 ECN-setup SYN packet ---> 183 ECN-setup SYN packet ---> 185 <--- ECN-setup SYN/ACK, possibly ECT 186 3-second timer set 187 SYN/ACK dropped . 188 . 189 . 190 3-second timer expires 191 <--- ECN-setup SYN/ACK, not ECT 192 <--- ECN-setup SYN/ACK 193 Data/ACK ---> 194 Data/ACK ---> 195 <--- Data (one to four segments) 196 --------------------------------------------------------------- 198 Table 1: SYN exchange with the SYN/ACK packet dropped. 200 If the SYN/ACK packet is dropped in the network, the TCP host (node 201 B) responds by waiting three seconds for the retransmit timer to 202 expire [RFC2988]. If a SYN/ACK packet with the ECT codepoint is 203 dropped, the TCP node SHOULD resend the SYN/ACK packet without the 204 ECN-Capable codepoint. (Although we are not aware of any middleboxes 205 that drop SYN/ACK packets that contain an ECN-Capable codepoint in 206 the IP header, we have learned to design our protocols defensively in 207 this regard [RFC3360].) 209 Table 2 shows an interchange with the SYN/ACK packet sent as ECN- 210 Capable, and ECN-marked instead of dropped at the congested router. 212 --------------------------------------------------------------- 213 TCP Node A Router TCP Node B 214 ---------- ------ ---------- 216 ECN-setup SYN packet ---> 217 ECN-setup SYN packet ---> 219 <--- ECN-setup SYN/ACK, ECT 220 <--- Sets CE on SYN/ACK 221 <--- ECN-setup SYN/ACK, CE 223 Data/ACK, ECN-Echo ---> 224 Data/ACK, ECN-Echo ---> 225 Window reduced to one segment. 226 <--- Data, CWR (one segment only) 227 --------------------------------------------------------------- 229 Table 2: SYN exchange with the SYN/ACK packet marked. 231 If the receiving node (node A) receives a SYN/ACK packet that has 232 been marked by the congested router, with the CE codepoint set, the 233 receiving node MUST respond by setting the ECN-Echo flag in the TCP 234 header of the responding ACK packet. As specified in RFC 3168, the 235 receiving node continues to set the ECN-Echo flag in packets until it 236 receives a packet with the CWR flag set. 238 When the sending node (node B) receives the ECN-Echo packet reporting 239 the Congestion Experienced indication in the SYN/ACK packet, the node 240 MUST set the initial congestion window to one segment, instead of two 241 segments as allowed by [RFC2414], or three or four segments allowed 242 by [RFC3390]. If the sending node (node B) was going to use an 243 initial window of one segment, and receives an ECN-Echo packet 244 informing it of a Congestion Experienced indication on its SYN/ACK 245 packet, the sending node MAY continue to send with an initial window 246 of one segment, without waiting for a retransmit timeout. We note 247 that this updates RFC 3168, which specifies that "the sending TCP 248 MUST reset the retransmit timer on receiving the ECN-Echo packet when 249 the congestion window is one." As specified by RFC 3168, the sending 250 node (node B) also sets the CWR flag in the TCP header of the next 251 packet sent, to acknowledge its receipt of and reaction to the ECN- 252 Echo flag. 254 3. Discussion 256 Motivation: 257 The rationale for the proposed change is the following. When node B 258 receives a TCP SYN packet with ECN-Echo bit set in the TCP header, 259 this indicates that node A is ECN-capable. If node B is also ECN- 260 capable, there are no obstacles to immediately setting one of the 261 ECN-Capable codepoints in the IP header in the responding TCP SYN/ACK 262 packet. 264 There can be a great benefit in setting an ECN-capable codepoint in 265 SYN/ACK packets, as is discussed further in Section 4. Congestion is 266 most likely to occur in the server-to-client direction. As a result, 267 setting an ECN-capable codepoint in SYN/ACK packets can reduce the 268 occurence of three-second retransmit timeouts resulting from the drop 269 of SYN/ACK packets. 271 Flooding attacks: 272 Setting an ECN-Capable codepoint in the responding TCP SYN/ACK 273 packets does not raise any novel security vulnerabilities. For 274 example, provoking servers or hosts to send SYN/ACK packets to a 275 third party in order to perform a "SYN/ACK flood" attack would be 276 greatly inefficient. Third parties would immediately drop such 277 packets, since they would know that they didn't generate the TCP SYN 278 packets in the first place. Moreover, such SYN/ACK attacks would 279 have the same signatures as the existing TCP SYN attacks. Provoking 280 servers or hosts to reply with SYN/ACK packets in order to congest a 281 certain link would also be highly inefficient because SYN ACK packets 282 are small in size. 284 The TCP SYN packet: 285 There are several reasons why an ECN-Capable codepoint MUST NOT be 286 set in the IP header of the initiating TCP SYN packet. First, when 287 the TCP SYN packet is sent, there are no guarantees that the other 288 TCP endpoint (node B in Table 2) is ECN-capable, or that it would be 289 able to understand and react if the ECN CE codepoint was set by a 290 congested router. 292 Second, the ECN-Capable codepoint in TCP SYN packets could be misused 293 by malicious clients to `improve' the well-known TCP SYN attack. By 294 setting an ECN-Capable codepoint in TCP SYN packets, a malicious host 295 might be able to inject a large number of TCP SYN packets through a 296 potentially congested ECN-enabled router, congesting it even further. 298 For both these reasons, we continue the restriction that the TCP SYN 299 packet MUST NOT have the ECN-Capable codepoint in the IP header set. 301 Backwards compatibility: 302 If there are some older TCP implementations that don't respond to the 303 Congestion Experienced codepoint in a SYN/ACK packet, that would not 304 be an insurmountable problem. It would mean that the sender of the 305 SYN/ACK packet would not reduce the initial congestion window from 306 two, three, or four segments down to one segment, as it should. 308 However, the TCP sender would still respond correctly to any 309 subsequent CE indications on data packets later on in the connection. 311 SYN/ACK packets and packet size: 312 There are a number of router buffer architectures that have smaller 313 dropping rates for small (SYN) packets than for large (data) packets. 314 For example, for a Drop Tail queue in units of packets, where each 315 packet takes a single slot in the buffer regardless of packet size, 316 small and large packets are equally likely to be dropped. However, 317 for a Drop Tail queue in units of bytes, small packets are less 318 likely to be dropped than are large ones. Similarly, for RED in 319 packet mode, small and large packets are equally likely to be dropped 320 or marked, while for RED in byte mode, a packet's chance of being 321 dropped or marked is proportional to the packet size in bytes. 323 For a congested router with an AQM mechanism in byte mode, where a 324 packet's chance of being dropped or marked is proportional to the 325 packet size in bytes, the drop or marking rate for TCP SYN/ACK 326 packets should generally be low. In this case, the benefit of making 327 SYN/ACK packets ECN-Capable should be similarly moderate. However, 328 for a congested router with a Drop Tail queue in units of packets or 329 with an AQM mechanism in packet mode, and with no priority queueing 330 for smaller packets, small and large packets should have the same 331 probability of being dropped or marked. In such a case, making 332 SYN/ACK packets ECN-Capable should be of significant benefit. 334 We believe that there are a wide range of behaviors in the real world 335 in terms of the drop or mark behavior at routers as a function of 336 packet size [Tools, Section 10]. We note that all of these 337 alternatives listed above are available in the NS simulator (Drop 338 Tail queues are by default in units of packets, while the default for 339 RED queue management has been changed from packet mode to byte mode). 341 4. Related Work 343 The addition of ECN-capability to TCP's SYN/ACK packets was proposed 344 in [ECN+]. The paper includes an extensive set of simulation and 345 testbed experiments to evaluate the effects of the proposal, using 346 several Active Queue Management (AQM) mechanisms, including Random 347 Early Detection (RED) [RED], Random Exponential Marking (REM) [REM], 348 and Proportional Integrator (PI) [PI]. The performance measures were 349 the end-to-end response times for each request/response pair, and the 350 aggregate throughput on the bottleneck link. The end-to-end response 351 time was computed as the time from the moment when the request for 352 the file is sent to the server, until that file is successfully 353 downloaded by the client. 355 The measurements from [ECN+] showed that setting an ECN-Capable 356 codepoint in the IP packet header in TCP SYN/ACK packets 357 systematically improves performance with all evaluated AQM schemes. 358 When SYN/ACK packets at a congested router are ECN-marked instead of 359 dropped, this can avoid a long initial retransmit timeout, improving 360 the response time for the affected flow dramatically. 362 [ECN+] showed that the impact on aggregate throughput can also be 363 quite significant, because marking SYN ACK packets can prevent larger 364 flows from suffering long timeouts before being "admitted" into the 365 network. In addition, the testbed measurements from [ECN+] showed 366 that Web servers setting the ECN-Capable codepoint in TCP SYN/ACK 367 packets could serve more requests. 369 As a final step, [ECN+] explored the co-existence of flows that do 370 and don't set the ECN-capable codepoint in TCP SYN/ACK packets. The 371 results in [ECN+] confirmed that both types of flows can coexist; 372 flows that apply the change improve their end-to-end performance, 373 while the performance degradation for flows that don't apply the 374 change, as a result of the flows that do apply the change, is 375 marginal. 377 5. Evaluation 379 The addition of ECN-capability to SYN/ACK packets could be of 380 significant benefit for those ECN connections that would have had the 381 SYN/ACK packet dropped in the network, and for which the ECN- 382 Capability would allow the SYN/ACK to be marked rather than dropped. 384 The percent of SYN/ACK packets on a link can be quite high. In 385 particular, measurements on links dominated by Web traffic indicate 386 that 15-20% of the packets can be SYN/ACK packets [SCJO01]. 388 The benefit of adding ECN-capability to SYN/ACK packets depends in 389 part on the size of the data transfer. The drop of a SYN/ACK packet 390 can increase the download time of a short file by an order of 391 magnitude, by requiring a three-second retransmit timeout. For 392 longer-lived flows, the effect of a dropped SYN/ACK packet on file 393 download time is less dramatic. However, even for longer-lived 394 flows, the addition of ECN-capability to SYN/ACK packets can improve 395 the fairness among long-lived flows, as newly-arriving flows would be 396 less likely to have to wait for retransmit timeouts. 398 The question that arises of course is what fraction of connections 399 would see the benefit from making SYN/ACK packets ECN-capable, in a 400 particular scenario? Specifically: 402 (1) What fraction of arriving SYN/ACK packets are dropped at the 403 congested router when the SYN/ACK packets are not ECN-capable? 404 (2) Of those SYN/ACK packets that are dropped, what fraction of those 405 drops would have been ECN-marks instead of drops if the SYN/ACK 406 packets had been ECN-capable? 408 To answer (1), it is necessary to consider not only the level of 409 congestion but also the queue architecture at the congested link. As 410 described in Section 3 above, for some queue architectures small 411 packets are less likely to be dropped than large ones. In such an 412 environment, SYN/ACK packets would have lower packet drop rates; 413 question (1) could not necessarily be inferred from the overall 414 packet drop rate, but could be answered by measuring the drop rate 415 for SYN/ACK packets directly. In such an environment, adding ECN- 416 capability to SYN/ACK packets would be of less dramatic benefit than 417 in environments where all packets are equally likely to be dropped 418 regardless of packet size. 420 As question (2) implies, even if all of the SYN/ACK packets were ECN- 421 capable, there could still be some SYN/ACK packets dropped instead of 422 marked at the congested link; the full answer to question (2) depends 423 on the details of the queue management mechanism at the router. If 424 congestion is sufficiently bad, and the queue management mechanism 425 cannot prevent the buffer from overflowing, then SYN/ACK packets will 426 be dropped rather than marked upon buffer overflow whether or not 427 they are ECN-capable. 429 For some AQM mechanisms, ECN-capable packets are marked instead of 430 dropped any time this is possible, that is, any time the buffer is 431 not yet full. For other AQM mechanisms however, such as the RED 432 mechanism as recommended in [RED], packets are dropped rather than 433 marked when the packet drop/mark rate exceeds a certain threshold, 434 e.g., 10%, even if the packets are ECN-capable. For a router with 435 such an AQM mechanism, when congestion is sufficiently severe to 436 cause a high drop/mark rate, some SYN/ACK packets would be dropped 437 instead of marked whether or not they were ECN-capable. 439 Thus, the degree of benefit of adding ECN-Capability to SYN/ACK 440 packets depends not only on the overall packet drop rate in the 441 network, but also on the queue management architecture at the 442 congested link. 444 6. Security Considerations 446 TCP packets carrying the ECT codepoint in IP headers can be marked 447 rather than dropped by ECN-capable routers. This raises several 448 security concerns that we discuss below. 450 TCP SYN flooding attacks: 451 By setting an ECN-Capable codepoint in TCP SYN packets, a malicious 452 host might be able to inject a large number of TCP SYN packets 453 through a potentially congested ECN-enabled router, congesting it 454 even further. This is one of the reasons why an ECN-Capable codepoint 455 MUST NOT be set in the IP header of the initiating TCP SYN packet. 456 On the other hand, as discussed in Section 3 above, setting an ECN- 457 Capable codepoint in the responding TCP SYN/ACK packet does not raise 458 any novel security vulnerabilities. 460 "Bad" middleboxes: 461 While there is no evidence that any middleboxes drop SYN/ACK packets 462 that contain an ECN-Capable codepoint in the IP header, such behavior 463 cannot be excluded [RFC3360]. Thus, if a SYN/ACK packet with the ECT 464 codepoint is dropped, the TCP node SHOULD resend the SYN/ACK packet 465 without the ECN-Capable codepoint. 467 Congestion collapse: 468 Because TCP SYN/ACK packets carrying an ECT codepoint could be ECN- 469 marked instead of dropped at an ECN-capable router, the concern is 470 whether this can either invoke congestion, or worsen performance in 471 highly congested scenarios. This is not a problem because after 472 learning that the SYN/ACK packet was ECN-marked, the sender of that 473 packet will only send one data packet; in the case that this data 474 packet is ECN-marked, the sender will wait for a retransmission 475 timeout. In addition, routers are free to drop rather than mark 476 arriving packets in times of high congestion, regardless of whether 477 the packets are ECN-capable. 479 7. Conclusions 481 This draft specifies a modification to RFC 3168 to allow TCP nodes to 482 send SYN/ACK packets as being ECN-Capable. Making the SYN/ACK packet 483 ECN-Capable avoids the high cost to a TCP transfer when a SYN/ACK 484 packet is dropped by a congested router, by avoiding the resulting 485 retransmit timeout. This improves the throughput of short 486 connections. The sender of the SYN/ACK packet responds to an ECN 487 mark by reducing its initial congestion window from two, three, or 488 four segments to one segment, reducing the subsequent load from that 489 connection on the network. The addition of ECN-capability to SYN/ACK 490 packets is particularly beneficial in the server-to-client direction, 491 where congestion is more likely to occur. In this case, the initial 492 information provided by the ECN marking in the SYN/ACK packet enables 493 the server to more appropriately adjust the initial load it places on 494 the network. 496 8. Acknowledgements 498 9. Normative References 500 [RFC2414] M. Allman, S. Floyd, and C. Partridge, Increasing TCP's 501 Initial Window, RFC 2414, September 1998. 503 [RFC3168] K.K. Ramakrishnan, S. Floyd, and D. Black, The Addition of 504 Explicit Congestion Notification (ECN) to IP, RFC 3168, Proposed 505 Standard, September 2001. 507 [RFC3390] M. Allman, S. Floyd, and C. Partridge, Increasing TCP's 508 Initial Window, RFC 3390, October 2002. 510 10. Informative References 512 [ECN+] A. Kuzmanovic, The Power of Explicit Congestion Notification, 513 SIGCOMM 2005. 515 [PI] C. Hollot, V. Misra, W. Gong, and D. Towsley, On Designing 516 Improved Controllers for AQM Routers Supporting TCP Flows, INFOCOM, 517 June 2001. 519 [RED] S. Floyd and V. Jacobson, Random Early Detection Gateways for 520 Congestion Avoidance, IEEE/ACM Transactions on Networking, V.1, N.4, 521 1993. 523 [REM] S. Athuraliya, V. Li, S. Low, and Q Yin, REM: Active Queue 524 Management, IEEE Network, V.15, N. 3, May 2001. 526 [RFC2988] V. Paxson and M. Allman, Computing TCP's Retransmission 527 Timer, RFC 2988, November 2000. 529 [RFC3042] M. Allman, H. Balakrishnan, and S. Floyd, Enhancing TCP's 530 Loss Recovery Using Limited Transmit, RFC 3042, Proposed Standard, 531 January 2001. 533 [RFC3360] S. Floyd, Inappropriate TCP Resets Considered Harmful, RFC 534 3360, August 2002. 536 [SCJO01] F. Smith, F. Campos, K. Jeffay, D. Ott, What {TCP/IP} 537 Protocol Headers Can Tell us about the Web, SIGMETRICS, June 2001. 539 [Tools] S. Floyd and E. Kohler, Tools for the Evaluation of 540 Simulation and Testbed Scenarios, Internet-draft draft-irtf-tmrg- 541 tools-00, work in progress, September 2005. 543 11. IANA Considerations 545 There are no IANA considerations regarding this document. 547 AUTHORS' ADDRESSES 549 Aleksandar Kuzmanovic 550 Phone: +1 (847) 467-5519 551 Northwestern University 552 Email: akuzma@northwestern.edu 553 URL: http://cs.northwestern.edu/~akuzma/ 555 Sally Floyd 556 Phone: +1 (510) 666-2989 557 ICIR (ICSI Center for Internet Research) 558 Email: floyd@icir.org 559 URL: http://www.icir.org/floyd/ 561 K. K. Ramakrishnan 562 Phone: +1 (973) 360-8764 563 AT&T Labs Research 564 Email: kkrama@research.att.com 565 URL: http://www.research.att.com/info/kkrama 567 Full Copyright Statement 569 Copyright (C) The Internet Society 2005. This document is subject 570 to the rights, licenses and restrictions contained in BCP 78, and 571 except as set forth therein, the authors retain all their rights. 573 This document and the information contained herein are provided on 574 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 575 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 576 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 577 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 578 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 579 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 581 Intellectual Property 583 The IETF takes no position regarding the validity or scope of any 584 Intellectual Property Rights or other rights that might be claimed 585 to pertain to the implementation or use of the technology described 586 in this document or the extent to which any license under such 587 rights might or might not be available; nor does it represent that 588 it has made any independent effort to identify any such rights. 589 Information on the procedures with respect to rights in RFC 590 documents can be found in BCP 78 and BCP 79. 592 Copies of IPR disclosures made to the IETF Secretariat and any 593 assurances of licenses to be made available, or the result of an 594 attempt made to obtain a general license or permission for the use 595 of such proprietary rights by implementers or users of this 596 specification can be obtained from the IETF on-line IPR repository 597 at http://www.ietf.org/ipr. 598 The IETF invites any interested party to bring to its attention any 599 copyrights, patents or patent applications, or other proprietary 600 rights that may cover technology that may be required to implement 601 this standard. Please address the information to the IETF at ietf- 602 ipr@ietf.org.