idnits 2.17.1 draft-ietf-tcpm-ecnsyn-05.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 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1130. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1141. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1148. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1154. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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.) -- The document date (19 February 2008) is 5909 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 2309 (Obsoleted by RFC 7567) -- Obsolete informational reference (is this intentional?): RFC 2581 (Obsoleted by RFC 5681) -- Obsolete informational reference (is this intentional?): RFC 2988 (Obsoleted by RFC 6298) == Outdated reference: A later version (-05) exists of draft-irtf-tmrg-tools-04 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 10 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 A. Mondal 3 Intended status: Proposed Standard Northwestern University 4 Expires: 19 August 2008 S. Floyd 5 ICIR 6 K.K. Ramakrishnan 7 AT&T 8 19 February 2008 10 Adding Explicit Congestion Notification (ECN) Capability 11 to TCP's SYN/ACK Packets 12 draft-ietf-tcpm-ecnsyn-05.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on August 2008. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2008). 43 Abstract 45 This draft specifies a modification to RFC 3168 to allow TCP SYN/ACK 46 packets to be ECN-Capable. For TCP, RFC 3168 only specifies setting 47 an ECN-Capable codepoint on data packets, and not on SYN and SYN/ACK 48 packets. However, because of the high cost to the TCP transfer of 49 having a SYN/ACK packet dropped, with the resulting retransmit 50 timeout, this document specifies the use of ECN for the SYN/ACK 51 packet itself, when sent in response to a SYN packet with the two ECN 52 flags set in the TCP header, indicating a willingness to use ECN. 53 Setting TCP SYN/ACK packets as ECN-Capable can be of great benefit to 54 the TCP connection, avoiding the severe penalty of a retransmit 55 timeout for a connection that has not yet started placing a load on 56 the network. The sender of the SYN/ACK packet must respond to a 57 report of an ECN-marked SYN/ACK packet by reducing its initial 58 congestion window from two, three, or four segments to one segment, 59 thereby reducing the subsequent load from that connection on the 60 network. This document is intended to update RFC 3168. 62 Table of Contents 64 1. Introduction ....................................................4 65 2. Conventions and Terminology .....................................5 66 3. Proposal ........................................................6 67 4. Discussion ......................................................9 68 5. Related Work ...................................................12 69 6. Performance Evaluation .........................................12 70 6.1. The Costs and Benefit of Adding ECN-Capability ............12 71 6.2. An Evaluation of Different Responses to ECN-Marked SYN/ACK 72 Packets ........................................................14 73 7. Security Considerations ........................................14 74 8. Conclusions ....................................................16 75 9. Acknowledgements ...............................................16 76 A. Report on Simulations ..........................................17 77 A.1. Simulations with RED in Packet Mode .......................17 78 A.2. Simulations with RED in Byte Mode .........................19 79 B. Issues of Incremental Deployment ...............................20 80 Normative References ..............................................23 81 Informative References ............................................23 82 IANA Considerations ...............................................24 83 Full Copyright Statement ..........................................25 84 Intellectual Property .............................................25 86 NOTE TO RFC EDITOR: PLEASE DELETE THIS NOTE UPON PUBLICATION. 88 Changes from draft-ietf-tcpm-ecnsyn-04: 90 * Updating the copyright date. 92 Changes from draft-ietf-tcpm-ecnsyn-03: 94 * General editing. This includes using the terms "initiator" 95 and "responder" for the two ends of the TCP connection. 96 Feedback from Alfred Hoenes. 98 * Added some text to the backwards compatibility discussion, 99 now in Appendix B, about the pros and cons of using a TCP 100 flag for the TCP initiator to signal that it understands 101 ECN-Capable SYN/ACK packets. The consensus at this time is 102 not to use such a flag. Also added a recommendation that 103 TCP implementations include a management interface to turn 104 off the use of ECN for SYN/ACK packets. From email from 105 Bob Briscoe. 107 Changes from draft-ietf-tcpm-ecnsyn-02: 109 * Added to the discussion in the Security section of whether 110 ECN-Capable TCP SYN packets have problems with firewalls, 111 over and above the known problems of TCP data packets 112 (e.g., as in the Microsoft report). From a question raised 113 at the TCPM meeting at the July 2007 IETF. 115 * Added a sentence to the discussion of routers or middleboxes that 116 *might* drop TCP SYN packets on the basis of IP header fields. 117 Feedback from Remi Denis-Courmont. 119 * General editing. Feedback from Alfred Hoenes. 121 Changes from draft-ietf-tcpm-ecnsyn-01: 123 * Changes in response to feedback from Anil Agarwal. 125 * Added a look at the costs of adding ECN-Capability to 126 SYN/ACKs in a highly-congested scenario. 127 From feedback from Mark Allman and Janardhan Iyengar. 129 * Added a comparative evaluation of two possible responses 130 to an ECN-marked SYN/ACK packet. From Mark Allman. 132 Changes from draft-ietf-tcpm-ecnsyn-00: 134 * Only updating the revision number. 136 Changes from draft-ietf-twvsg-ecnsyn-00: 138 * Changed name of draft to draft-ietf-tcpm-ecnsyn. 140 * Added a discussion in Section 3 of "Response to 141 ECN-marking of SYN/ACK packets". Based on 142 suggestions from Mark Allman. 144 * Added a discussion to the Conclusions about adding 145 ECN-capability to relevant set-up packets in other 146 protocols. From a suggestion from Wesley Eddy. 148 * Added a description of SYN exchanges with SYN cookies. 149 From a suggestion from Wesley Eddy. 151 * Added a discussion of one-way data transfers, where the 152 host sending the SYN/ACK packet sends no data packets. 154 * Minor editing, from feedback from Mark Allman and Janardhan 155 Iyengar. 157 * Future work: a look at the costs of adding 158 ECN-Capability in a worst-case scenario. 159 From feedback from Mark Allman and Janardhan Iyengar. 161 * Future work: a comparative evaluation of two 162 possible responses to an ECN-marked SYN/ACK packet. 164 Changes from draft-kuzmanovic-ecn-syn-00.txt: 166 * Changed name of draft to draft-ietf-twvsg-ecnsyn. 168 END OF NOTE TO RFC EDITOR. 170 1. Introduction 172 TCP's congestion control mechanism has primarily used packet loss as 173 the congestion indication, with packets dropped when buffers 174 overflow. With such tail-drop mechanisms, the packet delay can be 175 high, as the queue at bottleneck routers can be fairly large. 176 Dropping packets only when the queue overflows, and having TCP react 177 only to such losses, results in: 178 1) significantly higher packet delay; 179 2) unnecessarily many packet losses; and 180 3) unfairness due to synchronization effects. 182 The adoption of Active Queue Management (AQM) mechanisms allows 183 better control of bottleneck queues [RFC2309]. This use of AQM has 184 the following potential benefits: 185 1) better control of the queue, with reduced queueing delay; 186 2) fewer packet drops; and 187 3) better fairness because of fewer synchronization effects. 189 With the adoption of ECN, performance may be further improved. When 190 the router detects congestion before buffer overflow, the router can 191 provide a congestion indication either by dropping a packet, or by 192 setting the Congestion Experienced (CE) codepoint in the Explicit 193 Congestion Notification (ECN) field in the IP header [RFC3168]. The 194 IETF has standardized the use of the Congestion Experienced (CE) 195 codepoint in the IP header for routers to indicate congestion. For 196 incremental deployment and backwards compatibility, the RFC on ECN 197 [RFC3168] specifies that routers may mark ECN-capable packets that 198 would otherwise have been dropped, using the Congestion Experienced 199 codepoint in the ECN field. The use of ECN allows TCP to react to 200 congestion while avoiding unnecessary retransmissions and, in some 201 cases, unnecessary retransmit timeouts. Thus, using ECN has several 202 benefits: 204 1) For short transfers, a TCP connection's congestion window may be 205 small. For example, if the current window contains only one packet, 206 and that packet is dropped, TCP will have to wait for a retransmit 207 timeout to recover, reducing its overall throughput. Similarly, if 208 the current window contains only a few packets and one of those 209 packets is dropped, there might not be enough duplicate 210 acknowledgements for a fast retransmission, and the sender of the 211 data packet might have to wait for a delay of several round-trip 212 times using Limited Transmit [RFC3042]. With the use of ECN, short 213 flows are less likely to have packets dropped, sometimes avoiding 214 unnecessary delays or costly retransmit timeouts. 216 2) While longer flows may not see substantially improved throughput 217 with the use of ECN, they experience lower loss. This may benefit TCP 218 applications that are latency- and loss-sensitive, because of the 219 avoidance of retransmissions. 221 RFC 3168 only specifies marking the Congestion Experienced codepoint 222 on TCP's data packets, and not on SYN and SYN/ACK packets. RFC 3168 223 specifies the negotiation of the use of ECN between the two TCP end- 224 points in the TCP SYN and SYN-ACK exchange, using flags in the TCP 225 header. Erring on the side of being conservative, RFC 3168 does not 226 specify the use of ECN for the SYN/ACK packet itself. However, 227 because of the high cost to the TCP transfer of having a SYN/ACK 228 packet dropped, with the resulting retransmit timeout, this document 229 specifies the use of ECN for the SYN/ACK packet itself. This can be 230 of great benefit to the TCP connection, avoiding the severe penalty 231 of a retransmit timeout for a connection that has not yet started 232 placing a load on the network. The sender of the SYN/ACK packet must 233 respond to a report of an ECN-marked SYN/ACK packet by reducing its 234 initial congestion window from two, three, or four segments to one 235 segment, reducing the subsequent load from that connection on the 236 network. 238 The use of ECN for SYN/ACK packets has the following potential 239 benefits: 240 1) Avoidance of a retransmit timeout; 241 2) Improvement in the throughput of short connections. 243 This draft specifies ECN+, a modification to RFC 3168 to allow TCP 244 SYN/ACK packets to be ECN-Capable. Section 3 contains the 245 specification of the change, while Section 4 discusses some of the 246 issues, and Section 5 discusses related work. Section 6 contains an 247 evaluation of the proposed change. 249 2. Conventions and Terminology 251 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 252 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 253 document are to be interpreted as described in [RFC 2119]. 255 We use the following terminology from RFC 3168: 257 The ECN field in the IP header: 258 o CE: the Congestion Experienced codepoint; and 259 o ECT: either one of the two ECN-Capable Transport codepoints. 261 The ECN flags in the TCP header: 262 o CWR: the Congestion Window Reduced flag; and 263 o ECE: the ECN-Echo flag. 265 ECN-setup packets: 266 o ECN-setup SYN packet: a SYN packet with the ECE and CWR flags; 267 o ECN-setup SYN-ACK packet: a SYN-ACK packet with ECE but not CWR. 269 In this document we use the terms "initiator" and "responder" to 270 refer to the sender of the SYN packet and of the SYN-ACK packet, 271 respectively. 273 3. Proposal 275 This section specifies the modification to RFC 3168 to allow TCP 276 SYN/ACK packets to be ECN-Capable. 278 RFC 3168 in Section 6.1.1. states that "A host MUST NOT set ECT on 279 SYN or SYN-ACK packets." In this section, we specify that a TCP node 280 MAY respond to an ECN-setup SYN packet by setting ECT in the 281 responding ECN-setup SYN/ACK packet, indicating to routers that the 282 SYN/ACK packet is ECN-Capable. This allows a congested router along 283 the path to mark the packet instead of dropping the packet as an 284 indication of congestion. 286 Assume that TCP node A transmits to TCP node B an ECN-setup SYN 287 packet, indicating willingness to use ECN for this connection. As 288 specified by RFC 3168, if TCP node B is willing to use ECN, node B 289 responds with an ECN-setup SYN-ACK packet. 291 Figure 1 shows an interchange with the SYN/ACK packet dropped by a 292 congested router. Node B waits for a retransmit timeout, and then 293 retransmits the SYN/ACK packet. 295 --------------------------------------------------------------- 296 TCP Node A Router TCP Node B 297 ---------- ------ ---------- 299 ECN-setup SYN packet ---> 300 ECN-setup SYN packet ---> 302 <--- ECN-setup SYN/ACK, possibly ECT 303 3-second timer set 304 SYN/ACK dropped . 305 . 306 . 307 3-second timer expires 308 <--- ECN-setup SYN/ACK, not ECT 309 <--- ECN-setup SYN/ACK 310 Data/ACK ---> 311 Data/ACK ---> 312 <--- Data (one to four segments) 313 --------------------------------------------------------------- 315 Figure 1: SYN exchange with the SYN/ACK packet dropped. 317 If the SYN/ACK packet is dropped in the network, the responder (node 318 B) responds by waiting three seconds for the retransmit timer to 319 expire [RFC2988]. If a SYN/ACK packet with the ECT codepoint is 320 dropped, the responder SHOULD resend the SYN/ACK packet without the 321 ECN-Capable codepoint. (Although we are not aware of any middleboxes 322 that drop SYN/ACK packets that contain an ECN-Capable codepoint in 323 the IP header, we have learned to design our protocols defensively in 324 this regard [RFC3360].) 326 We note that if syn-cookies were used by the responder (node B) in 327 the exchange in Figure 1, the responder wouldn't set a timer upon 328 transmission of the SYN/ACK packet [SYN-COOK]. In this case, if the 329 SYN/ACK packet was lost, the initiator (Node A) would have to timeout 330 and retransmit the SYN packet in order to trigger another SYN-ACK. 332 Figure 2 shows an interchange with the SYN/ACK packet sent as ECN- 333 Capable, and ECN-marked instead of dropped at the congested router. 335 --------------------------------------------------------------- 336 TCP Node A Router TCP Node B 337 ---------- ------ ---------- 339 ECN-setup SYN packet ---> 340 ECN-setup SYN packet ---> 342 <--- ECN-setup SYN/ACK, ECT 343 <--- Sets CE on SYN/ACK 344 <--- ECN-setup SYN/ACK, CE 346 Data/ACK, ECN-Echo ---> 347 Data/ACK, ECN-Echo ---> 348 Window reduced to one segment. 349 <--- Data, CWR (one segment only) 350 --------------------------------------------------------------- 352 Figure 2: SYN exchange with the SYN/ACK packet marked. 354 If the initiator (node A) receives a SYN/ACK packet that has been 355 marked by the congested router, with the CE codepoint set, the 356 initiator MUST respond by setting the ECN-Echo flag in the TCP header 357 of the responding ACK packet. As specified in RFC 3168, the 358 initiator continues to set the ECN-Echo flag in packets until it 359 receives a packet with the CWR flag set. 361 When the responder (node B) receives the ECN-Echo packet reporting 362 the Congestion Experienced indication in the SYN/ACK packet, the 363 responder MUST set the initial congestion window to one segment, 364 instead of two segments as allowed by [RFC2581], or three or four 365 segments allowed by [RFC3390]. If the responder (node B) was going 366 to use an initial window of one segment, and receives an ECN-Echo 367 packet informing it of a Congestion Experienced indication on its 368 SYN/ACK packet, the responder MAY continue to send with an initial 369 window of one segment, without waiting for a retransmit timeout. We 370 note that this updates RFC 3168, which specifies that "the sending 371 TCP MUST reset the retransmit timer on receiving the ECN-Echo packet 372 when the congestion window is one." As specified by RFC 3168, the 373 responder (node B) also sets the CWR flag in the TCP header of the 374 next data packet sent, to acknowledge its receipt of and reaction to 375 the ECN-Echo flag. 377 If the data transfer in Figure 2 is entirely from Node A to Node B, 378 then data packets from Node A continue to set the ECN-Echo flag in 379 data packets, waiting for the CWR flag from Node B acknowledging a 380 response to the ECN-Echo flag. 382 The TCP implementation using ECN-Capable SYN/ACK packets SHOULD 383 include a management interface to allow the use of ECN to be turned 384 off for SYN/ACK packets. This is to deal with possible backwards 385 compatibility problems such as those discussed in Appendix B. 387 4. Discussion 389 Motivation: 390 The rationale for the proposed change is the following. When node B 391 receives a TCP SYN packet with ECN-Echo bit set in the TCP header, 392 this indicates that node A is ECN-capable. If node B is also ECN- 393 capable, there are no obstacles to immediately setting one of the 394 ECN-Capable codepoints in the IP header in the responding TCP SYN/ACK 395 packet. 397 There can be a great benefit in setting an ECN-capable codepoint in 398 SYN/ACK packets, as is discussed further in [ECN+], and reported 399 briefly in Section 5 below. Congestion is most likely to occur in 400 the server-to-client direction. As a result, setting an ECN-capable 401 codepoint in SYN/ACK packets can reduce the occurrence of three- 402 second retransmit timeouts resulting from the drop of SYN/ACK 403 packets. 405 Flooding attacks: 406 Setting an ECN-Capable codepoint in the responding TCP SYN/ACK 407 packets does not raise any novel security vulnerabilities. For 408 example, provoking servers or hosts to send SYN/ACK packets to a 409 third party in order to perform a "SYN/ACK flood" attack would be 410 highly inefficient. Third parties would immediately drop such 411 packets, since they would know that they didn't generate the TCP SYN 412 packets in the first place. Moreover, such SYN/ACK attacks would 413 have the same signatures as the existing TCP SYN attacks. Provoking 414 servers or hosts to reply with SYN/ACK packets in order to congest a 415 certain link would also be highly inefficient because SYN/ACK packets 416 are small in size. 418 However, the addition of ECN-Capability to SYN/ACK packets could 419 allow SYN/ACK packets to persist for more hops along a network path 420 before being dropped, thus adding somewhat to the ability of a 421 SYN/ACK attack to flood a network link. 423 The TCP SYN packet: 424 There are several reasons why an ECN-Capable codepoint MUST NOT be 425 set in the IP header of the initiating TCP SYN packet. First, when 426 the TCP SYN packet is sent, there are no guarantees that the other 427 TCP endpoint (node B in Figure 2) is ECN-capable, or that it would be 428 able to understand and react if the ECN CE codepoint was set by a 429 congested router. 431 Second, the ECN-Capable codepoint in TCP SYN packets could be misused 432 by malicious clients to `improve' the well-known TCP SYN attack. By 433 setting an ECN-Capable codepoint in TCP SYN packets, a malicious host 434 might be able to inject a large number of TCP SYN packets through a 435 potentially congested ECN-enabled router, congesting it even further. 437 For both these reasons, we continue the restriction that the TCP SYN 438 packet MUST NOT have the ECN-Capable codepoint in the IP header set. 440 SYN/ACK packets and packet size: 441 There are a number of router buffer architectures that have smaller 442 dropping rates for small (SYN) packets than for large (data) packets. 443 For example, for a Drop Tail queue in units of packets, where each 444 packet takes a single slot in the buffer regardless of packet size, 445 small and large packets are equally likely to be dropped. However, 446 for a Drop Tail queue in units of bytes, small packets are less 447 likely to be dropped than are large ones. Similarly, for RED in 448 packet mode, small and large packets are equally likely to be dropped 449 or marked, while for RED in byte mode, a packet's chance of being 450 dropped or marked is proportional to the packet size in bytes. 452 For a congested router with an AQM mechanism in byte mode, where a 453 packet's chance of being dropped or marked is proportional to the 454 packet size in bytes, the drop or marking rate for TCP SYN/ACK 455 packets should generally be low. In this case, the benefit of making 456 SYN/ACK packets ECN-Capable should be similarly moderate. However, 457 for a congested router with a Drop Tail queue in units of packets or 458 with an AQM mechanism in packet mode, and with no priority queueing 459 for smaller packets, small and large packets should have the same 460 probability of being dropped or marked. In such a case, making 461 SYN/ACK packets ECN-Capable should be of significant benefit. 463 We believe that there are a wide range of behaviors in the real world 464 in terms of the drop or mark behavior at routers as a function of 465 packet size [Tools] (Section 10). We note that all of these 466 alternatives listed above are available in the NS simulator (Drop 467 Tail queues are by default in units of packets, while the default for 468 RED queue management has been changed from packet mode to byte mode). 470 Response to ECN-marking of SYN/ACK packets: 471 One question is why TCP SYN/ACK packets should be treated differently 472 from other packets in terms of the end node's response to an ECN- 473 marked packet. Section 5 of RFC 3168 specifies the following: 475 "Upon the receipt by an ECN-Capable transport of a single CE packet, 476 the congestion control algorithms followed at the end-systems MUST be 477 essentially the same as the congestion control response to a *single* 478 dropped packet. For example, for ECN-Capable TCP the source TCP is 479 required to halve its congestion window for any window of data 480 containing either a packet drop or an ECN indication." 482 In particular, Section 6.1.2 of RFC 3168 specifies that when the TCP 483 congestion window consists of a single packet and that packet is ECN- 484 marked in the network, then the data sender must reduce the sending 485 rate below one packet per round-trip time, by waiting for one RTO 486 before sending another packet. If the RTO was set to the average 487 round-trip time, this would result in halving the sending rate; 488 because the RTO is in fact larger than the average round-trip time, 489 the sending rate is reduced to less than half of its previous value. 491 TCP's congestion control response to the *dropping* of a SYN/ACK 492 packet is to wait a default time before sending another packet. This 493 document argues that ECN gives end-systems a wider range of possible 494 responses to the *marking* of a SYN/ACK packet, and that waiting a 495 default time before sending a data packet is not the desired 496 response. 498 On the conservative end, one could assume an effective congestion 499 window of one packet for the SYN/ACK packet, and respond to an ECN- 500 marked SYN/ACK packet by reducing the sending rate to one packet 501 every two round-trip times. As an approximation, the TCP end-node 502 could measure the round-trip time T between the sending of the 503 SYN/ACK packet and the receipt of the acknowledgement, and reply to 504 the acknowledgement of the ECN-marked SYN/ACK packet by waiting T 505 seconds before sending a data packet. 507 However, we note that for an ECN-marked SYN/ACK packet, halving the 508 *congestion window* is not the same as halving the *sending rate*; 509 there is no `sending rate' associated with an ECN-Capable SYN/ACK 510 packet, as such packets are only sent as the first packet in a 511 connection from that host. Further, a router's marking of a SYN/ACK 512 packet is not affected by any past history of that connection. 514 Adding ECN-Capability to SYN/ACK packets allows the simple response 515 of the responder setting the initial congestion window to one packet, 516 instead of its allowed default value of two, three, or four packets, 517 with the responder proceeding with a cautious sending rate of one 518 packet per round-trip time. If that data packet is ECN-marked or 519 dropped, then the responder will wait an RTO before sending another 520 packet. This document argues that this approach is useful to users, 521 with no dangers of congestion collapse or of starvation of competing 522 traffic. This is discussed in more detail below in Section 6.2. 524 We note that if the data transfer is entirely from Node A to Node B, 525 then there is no effective difference between the two possible 526 responses to an ECN-marked SYN/ACK packet outlined above. In either 527 case, Node B sends no data packets, only sending acknowledgement 528 packets in response to received data packets. 530 5. Related Work 532 The addition of ECN-capability to TCP's SYN/ACK packets was proposed 533 in [ECN+]. The paper includes an extensive set of simulation and 534 testbed experiments to evaluate the effects of the proposal, using 535 several Active Queue Management (AQM) mechanisms, including Random 536 Early Detection (RED) [RED], Random Exponential Marking (REM) [REM], 537 and Proportional Integrator (PI) [PI]. The performance measures were 538 the end-to-end response times for each request/response pair, and the 539 aggregate throughput on the bottleneck link. The end-to-end response 540 time was computed as the time from the moment when the request for 541 the file is sent to the server, until that file is successfully 542 downloaded by the client. 544 The measurements from [ECN+] show that setting an ECN-Capable 545 codepoint in the IP packet header in TCP SYN/ACK packets 546 systematically improves performance with all evaluated AQM schemes. 547 When SYN/ACK packets at a congested router are ECN-marked instead of 548 dropped, this can avoid a long initial retransmit timeout, improving 549 the response time for the affected flow dramatically. 551 [ECN+] shows that the impact on aggregate throughput can also be 552 quite significant, because marking SYN ACK packets can prevent larger 553 flows from suffering long timeouts before being "admitted" into the 554 network. In addition, the testbed measurements from [ECN+] show that 555 web servers setting the ECN-Capable codepoint in TCP SYN/ACK packets 556 could serve more requests. 558 As a final step, [ECN+] explores the co-existence of flows that do 559 and don't set the ECN-capable codepoint in TCP SYN/ACK packets. The 560 results in [ECN+] show that both types of flows can coexist, with 561 some performance degradation for flows that don't use ECN+. Flows 562 that do use ECN+ improve their end-to-end performance. At the same 563 time, the performance degradation for flows that don't use ECN+, as a 564 result of the flows that do use ECN+, increases as a greater fraction 565 of flows use ECN+. 567 6. Performance Evaluation 569 6.1. The Costs and Benefit of Adding ECN-Capability 571 [ECN+] explores the costs and benefits of adding ECN-Capability to 572 SYN/ACK packets with both simulations and experiments. The addition 573 of ECN-capability to SYN/ACK packets could be of significant benefit 574 for those ECN connections that would have had the SYN/ACK packet 575 dropped in the network, and for which the ECN-Capability would allow 576 the SYN/ACK to be marked rather than dropped. 578 The percent of SYN/ACK packets on a link can be quite high. In 579 particular, measurements on links dominated by web traffic indicate 580 that 15-20% of the packets can be SYN/ACK packets [SCJO01]. 582 The benefit of adding ECN-capability to SYN/ACK packets depends in 583 part on the size of the data transfer. The drop of a SYN/ACK packet 584 can increase the download time of a short file by an order of 585 magnitude, by requiring a three-second retransmit timeout. For 586 longer-lived flows, the effect of a dropped SYN/ACK packet on file 587 download time is less dramatic. However, even for longer-lived 588 flows, the addition of ECN-capability to SYN/ACK packets can improve 589 the fairness among long-lived flows, as newly-arriving flows would be 590 less likely to have to wait for retransmit timeouts. 592 One question that arises is what fraction of connections would see 593 the benefit from making SYN/ACK packets ECN-capable, in a particular 594 scenario. Specifically: 596 (1) What fraction of arriving SYN/ACK packets are dropped at the 597 congested router when the SYN/ACK packets are not ECN-capable? 599 (2) Of those SYN/ACK packets that are dropped, what fraction would 600 have been ECN-marked instead of dropped if the SYN/ACK packets had 601 been ECN-capable? 603 To answer (1), it is necessary to consider not only the level of 604 congestion but also the queue architecture at the congested link. As 605 described in Section 4 above, for some queue architectures small 606 packets are less likely to be dropped than large ones. In such an 607 environment, SYN/ACK packets would have lower packet drop rates; 608 question (1) could not necessarily be inferred from the overall 609 packet drop rate, but could be answered by measuring the drop rate 610 for SYN/ACK packets directly. In such an environment, adding ECN- 611 capability to SYN/ACK packets would be of less dramatic benefit than 612 in environments where all packets are equally likely to be dropped 613 regardless of packet size. 615 As question (2) implies, even if all of the SYN/ACK packets were ECN- 616 capable, there could still be some SYN/ACK packets dropped instead of 617 marked at the congested link; the full answer to question (2) depends 618 on the details of the queue management mechanism at the router. If 619 congestion is sufficiently bad, and the queue management mechanism 620 cannot prevent the buffer from overflowing, then SYN/ACK packets will 621 be dropped rather than marked upon buffer overflow whether or not 622 they are ECN-capable. 624 For some AQM mechanisms, ECN-capable packets are marked instead of 625 dropped any time this is possible, that is, any time the buffer is 626 not yet full. For other AQM mechanisms however, such as the RED 627 mechanism as recommended in [RED], packets are dropped rather than 628 marked when the packet drop/mark rate exceeds a certain threshold, 629 e.g., 10%, even if the packets are ECN-capable. For a router with 630 such an AQM mechanism, when congestion is sufficiently severe to 631 cause a high drop/mark rate, some SYN/ACK packets would be dropped 632 instead of marked whether or not they were ECN-capable. 634 Thus, the degree of benefit of adding ECN-Capability to SYN/ACK 635 packets depends not only on the overall packet drop rate in the 636 network, but also on the queue management architecture at the 637 congested link. 639 6.2. An Evaluation of Different Responses to ECN-Marked SYN/ACK Packets 641 This document specifies that the end-node responds to the report of 642 an ECN-marked SYN/ACK packet by setting the initial congestion window 643 to one segment, instead of its possible default value of two to four 644 segments. We call this ECN+ with NoWaiting. However, Section 4 645 discussed another possible response to an ECN-marked SYN/ACK packet, 646 of the end-node waiting an RTT before sending a data packet. We call 647 this approach ECN+ with Waiting. 649 Simulations comparing the performance with Standard ECN (without ECN- 650 marked SYN/ACK packets), ECN+ with NoWaiting, and ECN+ with Waiting 651 show little difference, in terms of aggregate congestion, between 652 ECN+ with NoWaiting and ECN+ with Waiting. The details are given in 653 Appendix A below. Our conclusions are that ECN+ with NoWaiting is 654 perfectly safe, and there are no congestion-related reasons for 655 preferring ECN+ with Waiting over ECN+ with NoWaiting. That is, 656 there is no need for the TCP end-node to wait a round-trip time 657 before sending a data packet after receiving an acknowledgement of an 658 ECN-marked SYN/ACK packet. 660 7. Security Considerations 662 TCP packets carrying the ECT codepoint in IP headers can be marked 663 rather than dropped by ECN-capable routers. This raises several 664 security concerns that we discuss below. 666 "Bad" routers or middleboxes: 667 There are a number of known deployment problems from using ECN with 668 TCP traffic in the Internet. The first reported problem, dating back 669 to 2000, is of a small but decreasing number of routers or 670 middleboxes that reset a TCP connection in response to TCP SYN 671 packets using flags in the TCP header to negotiate ECN-capability 672 [Kelson00] [RFC3360] [MAF05]. Dave Thaler reported at the March 2007 673 IETF of new two problems encountered by TCP connections using ECN; 674 the first of the two problems concerns routers that crash when a TCP 675 data packet arrives with the ECN field in the IP header with the 676 codepoint ECT(0) or ECT(1), indicating that an ECN-Capable connection 677 has been established [SBT07]. 679 While there is no evidence that any routers or middleboxes drop 680 SYN/ACK packets that contain an ECN-Capable or CE codepoint in the IP 681 header, such behavior cannot be excluded. (There seems to be a 682 number of routers or middleboxes that drop TCP SYN packets that 683 contain known or unknown IP options [MAF05] (Figure 1).) Thus, as 684 specified in Section 3, if a SYN/ACK packet with the ECT or CE 685 codepoint is dropped, the TCP node SHOULD resend the SYN/ACK packet 686 without the ECN-Capable codepoint. There is also no evidence that 687 any routers or middleboxes crash when a SYN/ACK arrives with an ECN- 688 Capable or CE codepoint in the IP header (over and above the routers 689 already known to crash when a data packet arrives with either ECT(0) 690 or ECT(1)), but we have not conducted any measurement studies of this 691 [F07]. 693 Congestion collapse: 694 Because TCP SYN/ACK packets carrying an ECT codepoint could be ECN- 695 marked instead of dropped at an ECN-capable router, the concern is 696 whether this can either invoke congestion, or worsen performance in 697 highly congested scenarios. However, after learning that a SYN/ACK 698 packet was ECN-marked, the responder will only send one data packet; 699 if this data packet is ECN-marked, the responder will then wait for a 700 retransmission timeout. In addition, routers are free to drop rather 701 than mark arriving packets in times of high congestion, regardless of 702 whether the packets are ECN-capable. When congestion is very high 703 and a router's buffer is full, the router has no choice but to drop 704 rather than to mark an arriving packet. 706 The simulations reported in Appendix A show that even with demanding 707 traffic mixes dominated by short flows and high levels of congestion, 708 the aggregate packet dropping rates are not significantly different 709 with Standard ECN, ECN+ with NoWaiting, or ECN+ with Waiting. In 710 particular, the simulations show that in periods of very high 711 congestion the packet-marking rate is low with or without ECN+, and 712 the use of ECN+ does not significantly increase the number of dropped 713 or marked packets. 715 The simulations show that ECN+ is most effective in times of moderate 716 congestion. In these moderate-congested scenarios, the use of ECN+ 717 increases the number of ECN-marked packets, because ECN+ allows 718 SYN/ACK packets to be ECN-marked. At the same time, in these times 719 of moderate congestion, the use of ECN+ instead of Standard ECN does 720 not significantly affect the overall levels of congestion. 722 The simulations show that the use of ECN+ is less effective in times 723 of high congestion; the simulations show that in times of high 724 congestion more packets are dropped instead of marked, both with 725 Standard ECN and with ECN+. In times of high congestion, the buffer 726 can overflow, even with Active Queue Management and ECN; when the 727 buffer is full arriving packets are dropped rather than marked, 728 whether the packets are ECN-capable or not. Thus while ECN+ is less 729 effective in times of high congestion, it still doesn't result in a 730 significant increase in the level of congestion. More details are 731 given in the appendix. 733 8. Conclusions 735 This draft specifies a modification to RFC 3168 to allow TCP nodes to 736 send SYN/ACK packets as being ECN-Capable. Making the SYN/ACK packet 737 ECN-Capable avoids the high cost to a TCP transfer when a SYN/ACK 738 packet is dropped by a congested router, by avoiding the resulting 739 retransmit timeout. This improves the throughput of short 740 connections. The sender of the SYN/ACK packet responds to an ECN 741 mark by reducing its initial congestion window from two, three, or 742 four segments to one segment, reducing the subsequent load from that 743 connection on the network. The addition of ECN-capability to SYN/ACK 744 packets is particularly beneficial in the server-to-client direction, 745 where congestion is more likely to occur. In this case, the initial 746 information provided by the ECN marking in the SYN/ACK packet enables 747 the server to more appropriately adjust the initial load it places on 748 the network. 750 Future work will address the more general question of adding ECN- 751 Capability to relevant handshake packets in other protocols that use 752 retransmission-based reliability in their setup phase (e.g., SCTP, 753 DCCP, HIP, and the like). 755 9. Acknowledgements 757 We thank Anil Agarwal, Mark Allman, Remi Denis-Courmont, Wesley Eddy, 758 Alfred Hoenes, Janardhan Iyengar, and Pasi Sarolahti for feedback on 759 earlier versions of this draft. 761 A. Report on Simulations 763 This section reports on simulations showing the costs of adding ECN+ 764 in highly-congested scenarios. This section also reports on 765 simulations for a comparative evaluation between ECN+ with NoWaiting 766 and ECN+ with Waiting. 768 The simulations are run with a range of file-size distributions. As 769 a baseline, they use the empirical heavy-tailed distribution reported 770 in [SCJO01], with a mean file size of around 7 KBytes. This flow- 771 size distribution is manipulated by skewing the flow sizes towards 772 lower and higher values to get distributions with mean file sizes of 773 3 KBytes, 5 KBytes, 14 KBytes and 17 KBytes. The congested link is 774 100 Mbps. RED is run in gentle mode, and arriving ECN-Capable 775 packets are only dropped instead of marked if the buffer is full (and 776 the router has no choice). 778 We explore two alternatives for a TCP node's response to a report of 779 an ECN-marked SYN/ACK packet. With ECN+ with NoWaiting, the TCP node 780 sends a data packet immediately (with an initial congestion window of 781 one segment). With the alternative ECN+ with Waiting, the TCP node 782 waits a round-trip time before sending a data packet; the responder 783 already has one measurement of the round-trip time when the 784 acknowledgement for the SYN/ACK packet is received. 786 In the tables below, ECN+ refers to ECN+ with NoWaiting, where the 787 responder starts transmitting immediately, and ECN+/wait refers to 788 ECN+ with Waiting, where the responder waits a round-trip time before 789 sending a data packet into the network. 791 The simulation scripts are available on [ECN-SYN], along with graphs 792 showing the distribution of response times for the TCP connections. 794 A.1. Simulations with RED in Packet Mode 796 The simulations with RED in packet mode and with the queue in packets 797 show that ECN+ is useful in times of moderate congestion, though it 798 adds little benefit in times of high congestion. The simulations 799 show a minimal increase in levels of congestion with either ECN+ with 800 Waiting or ECN+ with NoWaiting, either in terms of packet dropping or 801 marking rates or in terms of the distribution of responses times. 803 Thus, the simulations show no problems with ECN+ in times of high 804 congestion, and no reason to use ECN+ with Waiting instead of ECN+ 805 with NoWaiting. 807 Table 1 shows the congestion levels for simulations with RED in 808 packet mode, with a queue in packets. To explore a worst-case 809 scenario, these simulations use a traffic mix with an unrealistically 810 small flow size distribution, with a mean flow size of 3 Kbytes. For 811 each table showing a particular traffic load, the three rows show the 812 number of packets dropped, the number of packets ECN-marked, and the 813 aggregate packet drop rate, and the three columns show the 814 simulations with Standard ECN, ECN+ (NoWaiting) and ECN+/wait. 816 The usefulness of ECN+: The first thing to observe is that for the 817 simulations with the somewhat moderate load of 95%, with packet drop 818 rates of 5-6%, the use of ECN+ or ECN+/wait more than doubled the 819 number of packets marked. This indicates that with ECN+ or 820 ECN+/wait, many SYN/ACK packets are marked instead of dropped. 822 No increase in congestion: The second thing to observe is that in all 823 of the simulations, the use of ECN+ or ECN+/wait does not 824 significantly increase the aggregate packet drop rate. 826 Comparing ECN+ and ECN+/wait: The third thing to observe is that 827 there is little difference between ECN+ and ECN+/wait in terms of the 828 aggregate packet drop rate. Thus, there is no congestion-related 829 reason to prefer ECN+/wait over ECN+. 831 Traffic Load = 95%: 832 ECN ECN+ ECN+/wait 833 ------- ------- ------- 834 Dropped 74,645 64,034 64,983 835 Marked 7,639 17,681 16,914 836 Loss rate 6.05% 5.26% 5.33% 838 Traffic Load = 110%: 839 ECN ECN+ ECN+/wait 840 ------- ------- ------- 841 Dropped 161,644 163,620 165,196 842 Marked 4,375 6,653 6,144 843 Loss rate 10.38% 10.45% 10.53% 845 Traffic Load = 125%: 846 ECN ECN+ ECN+/wait 847 ------- ------- ------- 848 Dropped 257,671 268,161 264,437 849 Marked 2,885 3,712 3,359 850 Loss rate 14.52% 15.00% 14.83% 852 Traffic Load = 150%: 853 ECN ECN+ ECN+/wait 854 ------- ------- ------- 855 Loss rate 24.36% 24.61% 24.46% 857 Traffic Load = 200%: 858 ECN ECN+ ECN+/wait 859 ------- ------- ------- 860 Loss rate 29.99% 30.22% 30.23% 862 Table 1: Simulations with an average flow size of 3 Kbytes, RED in 863 packet mode, queue in packets. 865 A.2. Simulations with RED in Byte Mode 867 Table 2 below shows simulations with RED in byte mode and the queue 868 in bytes. Like the simulations with RED in packet mode, there is no 869 significant increase in aggregate congestion with the use of ECN+ or 870 ECN+/wait, and no congestion-related reason to prefer ECN+/wait over 871 ECN+. 873 However, unlike the simulations with RED in packet mode, the 874 simulations with RED in byte mode show little benefit from the use of 875 ECN+ or ECN+/wait, in that the packet marking rate with ECN+ or 876 ECN+/wait is not much different than the packet marking rate with 877 Standard ECN. This is because with RED in byte mode, small packets 878 like SYN/ACK packets are rarely dropped or marked - that is, there is 879 no drawback from the use of ECN+ in these scenarios, but not much 880 need for ECN+ either, in a scenario where small packets are unlikely 881 to be dropped or marked. 883 Traffic Load = 95%: 884 ECN ECN+ ECN+/wait 885 ------- ------- ------- 886 Dropped 13,044 13,323 14,855 887 Marked 18,880 19,175 19,049 888 Loss rate 1.13% 1.16% 1.29% 890 Traffic Load = 110%: 891 ECN ECN+ ECN+/wait 892 ------- ------- ------- 893 Dropped 84,809 83,013 83,564 894 Marked 4,086 4,644 4,826 895 Loss rate 5.90% 5.78% 5.81% 897 Traffic Load = 125%: 898 ECN ECN+ ECN+/wait 899 ------- ------- ------- 900 Dropped 157,305 157,435 158,368 901 Marked 2,183 2,363 2,663 902 Loss rate 9.89% 9.87% 9.93% 904 Table 2: Simulations with an average flow size of 3 Kbytes, RED in 905 byte mode, queue in bytes. 907 B. Issues of Incremental Deployment 909 In order for TCP node B to send a SYN/ACK packet as ECN-Capable, node 910 B must have received an ECN-setup SYN packet from node A. However, 911 it is possible that node A supports ECN, but either ignores the CE 912 codepoint on received SYN/ACK packets, or ignores SYN/ACK packets 913 with the ECT or CE codepoint set. If the TCP initiator ignores the 914 CE codepoint on received SYN/ACK packets, this would mean that the 915 TCP responder would not respond to this congestion indication. 916 However, this seems to us an acceptable cost to pay in the 917 incremental deployment of ECN-Capability for TCP's SYN/ACK packets. 918 It would mean that the responder would not reduce the initial 919 congestion window from two, three, or four segments down to one 920 segment, as it should. However, the TCP end nodes would still 921 respond correctly to any subsequent CE indications on data packets 922 later on in the connection. 924 Figure 3 shows an interchange with the SYN/ACK packet ECN-marked, but 925 with the ECN mark ignored by the TCP originator. 927 --------------------------------------------------------------- 928 TCP Node A Router TCP Node B 929 ---------- ------ ---------- 931 ECN-setup SYN packet ---> 932 ECN-setup SYN packet ---> 934 <--- ECN-setup SYN/ACK, ECT 935 <--- Sets CE on SYN/ACK 936 <--- ECN-setup SYN/ACK, CE 938 Data/ACK, No ECN-Echo ---> 939 Data/ACK ---> 940 <--- Data (up to four packets) 941 --------------------------------------------------------------- 943 Figure 3: SYN exchange with the SYN/ACK packet marked, 944 but with the ECN mark ignored by the TCP initiator. 946 Thus, to be explicit, when a TCP connection includes an initiator 947 that supports ECN but *does not* support ECN-Capability for SYN/ACK 948 packets, in combination with a responder that *does* support ECN- 949 Capabililty for SYN/ACK packets, it is possible that the ECN-Capable 950 SYN/ACK packets will be marked rather than dropped in the network, 951 and that the responder will not learn about the ECN mark on the 952 SYN/ACK packet. This would not be a problem if most packets from the 953 responder supporting ECN for SYN/ACK packets were in long-lived TCP 954 connections, but it would be more problematic if most of the packets 955 were from TCP connections consisting of four data packets, and the 956 TCP responder for these connections was ready to send its data 957 packets immediately after the SYN/ACK exchange. Of course, with 958 *severe* congestion, the SYN/ACK packets would likely be dropped 959 rather than ECN-marked at the congested router, preventing the TCP 960 responder from adding to the congestion by sending its initial window 961 of four data packets. 963 It is also possible that in some older TCP implementation, the 964 initiator would ignore arriving SYN/ACK packets that had the ECT or 965 CE codepoint set. This would result in a delay in connection set-up 966 for that TCP connection, with the initiator re-sending the SYN packet 967 after a retransmit timeout. We are not aware of any TCP 968 implementations with this behavior. 970 One possibility for coping with problems of backwards compatibility 971 would be for TCP initiators to use a TCP flag that means "I 972 understand ECN-Capable SYN/ACK packets". If this document were to 973 standardize the use of such an "ECN-SYN" flag, then the TCP responder 974 would only send a SYN/ACK packet as ECN-capable if the incoming SYN 975 packet had the "ECN-SYN" flag set. An ECN-SYN flag would prevent the 976 backwards compatibility problems described in the paragraphs above. 978 One drawback to the use of an ECN-SYN flag is that it would use one 979 of the four remaining reserved bits in the TCP header, for a 980 transient backwards compatibility problem. This drawback is limited 981 by the fact that the "ECN-SYN" flag would be defined only for use 982 with ECN-setup SYN packets; that bit in the TCP header could be 983 defined to have other uses for other kinds of TCP packets. 985 Factors in deciding not to use an ECN-SYN flag include the following: 987 (1) The limited installed base: At the time that this document was 988 written, the TCP implementations in Microsoft Vista and Mac OS X 989 included ECN, but ECN was not enabled by default [SBT07]. Thus, 990 there was not a large deployed base of ECN-Capable TCP 991 implementations. This limits the scope of any backwards 992 compatibility problems. 994 (2) Limits to the scope of the problem: The backwards compatibility 995 problem would not be serious enough to cause congestion collapse; 996 with severe congestion, the buffer at the congested router will 997 overflow, and the congested router will drop rather than ECN-mark 998 arriving SYN packets. Some active queue management mechanisms might 999 switch from packet-marking to packet-dropping in times of high 1000 congestion before buffer overflow, as recommended in Section 19.1 of 1001 RFC 3168. This helps to prevent congestion collapse problems with 1002 the use of ECN. 1004 (3) Detection of and response to backwards-compatibility problems: A 1005 TCP responder such as a web server can't differentiate between a 1006 SYN/ACK packet that is not ECN-marked in the network, and a SYN/ACK 1007 packet that is ECN-marked, but where the ECN mark is ignored by the 1008 TCP initiator. However, a TCP responder *can* detect if a SYN/ACK 1009 packet is sent as ECN-capable and not reported as ECN-marked, but 1010 data packets are dropped or marked from the initial window of data. 1011 We will call this scenario "initial-window-congestion". If a web 1012 server frequently experienced initial-window congestion (without 1013 SYN/ACK congestion), then the web server *might* be experiencing 1014 backwards compatibility problems with ECN-Capable SYN/ACK packets, 1015 and could respond by not sending SYN/ACK packets as ECN-Capable. 1017 Normative References 1019 [RFC 2119] S. Bradner, Key words for use in RFCs to Indicate 1020 Requirement Levels, RFC 2119, March 1997. 1022 [RFC3168] K.K. Ramakrishnan, S. Floyd, and D. Black, The Addition of 1023 Explicit Congestion Notification (ECN) to IP, RFC 3168, Proposed 1024 Standard, September 2001. 1026 Informative References 1028 [ECN+] A. Kuzmanovic, The Power of Explicit Congestion Notification, 1029 SIGCOMM 2005. 1031 [ECN-SYN] ECN-SYN web page with simulation scripts, URL to be added. 1033 [F07] S. Floyd, "[BEHAVE] Response of firewalls and middleboxes to 1034 TCP SYN packets that are ECN-Capable?", August 2, 2007, email sent to 1035 the BEHAVE mailing list, URL "http://www1.ietf.org/mail- 1036 archive/web/behave/current/msg02644.html". 1038 [Kelson00] Dax Kelson, note sent to the Linux kernel mailing list, 1039 September 10, 2000. 1041 [MAF05] A. Medina, M. Allman, and S. Floyd. Measuring the Evolution 1042 of Transport Protocols in the Internet, ACM CCR, April 2005. 1044 [PI] C. Hollot, V. Misra, W. Gong, and D. Towsley, On Designing 1045 Improved Controllers for AQM Routers Supporting TCP Flows, April 1046 1998. 1048 [RED] Floyd, S., and Jacobson, V. Random Early Detection gateways 1049 for Congestion Avoidance . IEEE/ACM Transactions on Networking, V.1 1050 N.4, August 1993. 1052 [REM] S. Athuraliya, V. H. Li, S. H. Low and Q. Yin, REM: Active 1053 Queue Management, IEEE Network, May 2001. 1055 [RFC2309] B. Braden et al., Recommendations on Queue Management and 1056 Congestion Avoidance in the Internet, RFC 2309, April 1998. 1058 [RFC2581] M. Allman, V. Paxson, and W. Stevens, TCP Congestion 1059 Control, RFC 2581, April 1999. 1061 [RFC2988] V. Paxson and M. Allman, Computing TCP's Retransmission 1062 Timer, RFC 2988, November 2000. 1064 [RFC3042] M. Allman, H. Balakrishnan, and S. Floyd, Enhancing TCP's 1065 Loss Recovery Using Limited Transmit, RFC 3042, Proposed Standard, 1066 January 2001. 1068 [RFC3360] S. Floyd, Inappropriate TCP Resets Considered Harmful, RFC 1069 3360, August 2002. 1071 [RFC3390] M. Allman, S. Floyd, and C. Partridge, Increasing TCP's 1072 Initial Window, RFC 3390, October 2002. 1074 [SCJO01] F. Smith, F. Campos, K. Jeffay, D. Ott, What {TCP/IP} 1075 Protocol Headers Can Tell us about the Web, SIGMETRICS, June 2001. 1077 [SYN-COOK] Dan J. Bernstein, SYN cookies, 1997, see also 1078 1080 [SBT07] M. Sridharan, D. Bansal, and D. Thaler, Implementation Report 1081 on Experiences with Various TCP RFCs, Presentation in the TSVAREA, 1082 IETF 68, March 2007. URL 1083 "http://www3.ietf.org/proceedings/07mar/slides/tsvarea-3/sld6.htm". 1085 [Tools] S. Floyd and E. Kohler, Tools for the Evaluation of 1086 Simulation and Testbed Scenarios, Internet-draft draft-irtf-tmrg- 1087 tools-04, work in progress, July 2007. 1089 IANA Considerations 1091 There are no IANA considerations regarding this document. 1093 Authors' Addresses 1094 Aleksandar Kuzmanovic 1095 Phone: +1 (847) 467-5519 1096 Northwestern University 1097 Email: akuzma at northwestern.edu 1098 URL: http://cs.northwestern.edu/~a 1100 Amit Mondal 1101 Northwestern University 1102 Email: a-mondal at northwestern.edu 1104 Sally Floyd 1105 Phone: +1 (510) 666-2989 1106 ICIR (ICSI Center for Internet Research) 1107 Email: floyd@icir.org 1108 URL: http://www.icir.org/floyd/ 1110 K. K. Ramakrishnan 1111 Phone: +1 (973) 360-8764 1112 AT&T Labs Research 1113 Email: kkrama at research.att.com 1114 URL: http://www.research.att.com/info/kkrama 1116 Full Copyright Statement 1118 Copyright (C) The IETF Trust (2008). 1120 This document is subject to the rights, licenses and restrictions 1121 contained in BCP 78, and except as set forth therein, the authors 1122 retain all their rights. 1124 This document and the information contained herein are provided on an 1125 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1126 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1127 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1128 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1129 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1130 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1132 Intellectual Property 1134 The IETF takes no position regarding the validity or scope of any 1135 Intellectual Property Rights or other rights that might be claimed to 1136 pertain to the implementation or use of the technology described in 1137 this document or the extent to which any license under such rights 1138 might or might not be available; nor does it represent that it has 1139 made any independent effort to identify any such rights. Information 1140 on the procedures with respect to rights in RFC documents can be 1141 found in BCP 78 and BCP 79. 1143 Copies of IPR disclosures made to the IETF Secretariat and any 1144 assurances of licenses to be made available, or the result of an 1145 attempt made to obtain a general license or permission for the use of 1146 such proprietary rights by implementers or users of this 1147 specification can be obtained from the IETF on-line IPR repository at 1148 http://www.ietf.org/ipr. 1150 The IETF invites any interested party to bring to its attention any 1151 copyrights, patents or patent applications, or other proprietary 1152 rights that may cover technology that may be required to implement 1153 this standard. Please address the information to the IETF at ietf- 1154 ipr@ietf.org.