idnits 2.17.1 draft-ietf-tcpm-ecnsyn-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (25 May 2009) is 5443 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2988 (Obsoleted by RFC 6298) -- Obsolete informational reference (is this intentional?): RFC 2309 (Obsoleted by RFC 7567) -- Obsolete informational reference (is this intentional?): RFC 2581 (Obsoleted by RFC 5681) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 4 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: Experimental Northwestern University 4 Expires: 25 November 2009 S. Floyd 5 ICSI 6 K.K. Ramakrishnan 7 AT&T 8 25 May 2009 10 Adding Explicit Congestion Notification (ECN) Capability 11 to TCP's SYN/ACK Packets 12 draft-ietf-tcpm-ecnsyn-10.txt 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 This document may contain material from IETF Documents or IETF 20 Contributions published or made publicly available before November 21 10, 2008. The person(s) controlling the copyright in some of this 22 material may not have granted the IETF Trust the right to allow 23 modifications of such material outside the IETF Standards Process. 24 Without obtaining an adequate license from the person(s) controlling 25 the copyright in such materials, this document may not be modified 26 outside the IETF Standards Process, and derivative works of it may 27 not be created outside the IETF Standards Process, except to format 28 it for publication as an RFC or to translate it into languages other 29 than English. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/ietf/1id-abstracts.txt. 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html. 47 This Internet-Draft will expire on 25 November 2009. 49 Copyright Notice 51 Copyright (c) 2009 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents in effect on the date of 56 publication of this document (http://trustee.ietf.org/license-info). 57 Please review these documents carefully, as they describe your rights 58 and restrictions with respect to this document. 60 Abstract 62 The proposal in this document is experimental. While it may be 63 deployed in the current Internet, it does not represent a consensus 64 that this is the best possible mechanism for the use of ECN in TCP 65 SYN/ACK packets. 67 This draft describes an optional, experimental modification to RFC 68 3168 to allow TCP SYN/ACK packets to be ECN-Capable. For TCP, RFC 69 3168 specifies setting an ECN-Capable codepoint on data packets, but 70 not on SYN and SYN/ACK packets. However, because of the high cost to 71 the TCP transfer of having a SYN/ACK packet dropped, with the 72 resulting retransmission timeout, this document describes the use of 73 ECN for the SYN/ACK packet itself, when sent in response to a SYN 74 packet with the two ECN flags set in the TCP header, indicating a 75 willingness to use ECN. Setting the initial TCP SYN/ACK packet as 76 ECN-Capable can be of great benefit to the TCP connection, avoiding 77 the severe penalty of a retransmission timeout for a connection that 78 has not yet started placing a load on the network. The TCP responder 79 (the sender of the SYN/ACK packet) must reply to a report of an ECN- 80 marked SYN/ACK packet by resending a SYN/ACK packet that is not ECN- 81 Capable. If the resent SYN/ACK packet is acknowledged, then the TCP 82 responder reduces its initial congestion window from two, three, or 83 four segments to one segment, thereby reducing the subsequent load 84 from that connection on the network. If instead the SYN/ACK packet 85 is dropped, or for some other reason the TCP responder does not 86 receive an acknowledgement in the specified time, the TCP responder 87 follows TCP standards for a dropped SYN/ACK packet (setting the 88 retransmission timer). 90 Table of Contents 92 1. Introduction ....................................................6 93 2. Conventions and Terminology .....................................8 94 3. Specification ...................................................9 95 3.1. SYN/ACK Packets Dropped in the Network .....................9 96 3.2. SYN/ACK Packets ECN-Marked in the Network .................10 97 3.3. Management Interface ......................................13 98 4. Discussion .....................................................14 99 4.1. Flooding Attacks ..........................................14 100 4.2. The TCP SYN Packet ........................................14 101 4.3. SYN/ACK Packets and Packet Size ...........................15 102 4.4. Response to ECN-marking of SYN/ACK Packets ................15 103 5. Related Work ...................................................17 104 6. Performance Evaluation .........................................17 105 6.1. The Costs and Benefit of Adding ECN-Capability ............17 106 6.2. An Evaluation of Different Responses to ECN-Marked SYN/ACK 107 Packets ........................................................19 108 6.3. Experiments ...............................................20 109 7. Security Considerations ........................................20 110 7.1. 'Bad' Routers or Middleboxes ..............................20 111 7.2. Congestion Collapse .......................................21 112 8. Conclusions ....................................................21 113 9. Acknowledgements ...............................................22 114 A. Report on Simulations ..........................................22 115 A.1. Simulations with RED in Packet Mode .......................23 116 A.2. Simulations with RED in Byte Mode .........................28 117 B. Issues of Incremental Deployment ...............................30 118 Normative References ..............................................33 119 Informative References ............................................33 120 IANA Considerations ...............................................34 122 NOTE TO RFC EDITOR: PLEASE DELETE THIS NOTE UPON PUBLICATION. 124 Changes from draft-ietf-tcpm-ecnsyn-09: 126 * Added back Normative References and RFC 2119. 127 (These were deleted accidentally.) 128 IESG feedback from Pasi Eronen. 130 * Added Section 6.3 on a discussion of possible experiments. 131 IESG Feedback from Tim Polk. 133 Changes from draft-ietf-tcpm-ecnsyn-08: 135 * Minor editing and bug-fixes. Feedback from Anil Agarwal and 136 Alfred Hoenes. 138 * Changed the specification so that after the first SYN/ACK packet 139 is ECN-marked, and the responder receives an ECN-Echo, the 140 responder does not set the CWR flag in the second SYN/ACK packet. 141 We also specified that on receiving the non-ECN-marked SYN/ACK 142 packet, the TCP initiator clears the ECN-Echo flag on replying 143 packets. Feedback from Anil Agarwal. 145 * Changed it so that the initiator moves from the "SYN-Sent" state 146 to the "Established" state when it receives a SYN/ACK packet 147 that is not ECN-marked. 149 Changes from draft-ietf-tcpm-ecnsyn-07: 151 * Updated boilerplates. 153 * Changed proposed status from "Proposed Standard" to "Experimental", 154 and modified text in the Introduction to match. The added text 155 in the introduction is based on similar text in the Introduction of 156 RFC 3649. 158 * Specified that with ECN+/TryOnce, the originator restarts the 159 retransmission timer when it receives an ECN-marked SYN/ACK. 160 Also reran simulations for ECN+/TryOnce, and updated 161 Tables 1-6. 163 * Specified that the originator follows the traditional rules in 164 setting the cumulative ack field for the ACK acking the SYN/ACK. 166 * Minor editing. 168 Changes from draft-ietf-tcpm-ecnsyn-06: 170 * Updated text and simulation results to specify ECN+/TryOnce 171 instead of ECN+. Added tables on CDFs. 173 * Acknowledged Adam's Linux implementation of ECN+/TryOnce. 175 Changes from draft-ietf-tcpm-ecnsyn-05: 177 * Added "Updates: 3168" to the header. Added a reference 178 to RFC 4987. Mild editing. 179 Feedback from Lars's Area Director review. 181 * Updated simulation results with new simulation scripts that 182 don't require any modifications to the ns simulator, and that 183 all use the same seed for generating traffic. The results are 184 somewhat different for the very-high-congestion scenarios 185 (with loss rates of 25% in the absence of ECN-capability 186 for SYN/ACK packets). This is reflected in the simulations with 187 a target load of 125% in Tables 1 and 2. 189 * Added the URL for the web page that has the simulation scripts. 191 Changes from draft-ietf-tcpm-ecnsyn-04: 193 * Updating the copyright date. 195 Changes from draft-ietf-tcpm-ecnsyn-03: 197 * General editing. This includes using the terms "initiator" 198 and "responder" for the two ends of the TCP connection. 199 Feedback from Alfred Hoenes. 201 * Added some text to the backwards compatibility discussion, 202 now in Appendix B, about the pros and cons of using a TCP 203 flag for the TCP initiator to signal that it understands 204 ECN-Capable SYN/ACK packets. The consensus at this time is 205 not to use such a flag. Also added a recommendation that 206 TCP implementations include a management interface to turn 207 off the use of ECN for SYN/ACK packets. From email from 208 Bob Briscoe. 210 Changes from draft-ietf-tcpm-ecnsyn-02: 212 * Added to the discussion in the Security section of whether 213 ECN-Capable TCP SYN packets have problems with firewalls, 214 over and above the known problems of TCP data packets 215 (e.g., as in the Microsoft report). From a question raised 216 at the TCPM meeting at the July 2007 IETF. 218 * Added a sentence to the discussion of routers or middleboxes that 219 *might* drop TCP SYN packets on the basis of IP header fields. 220 Feedback from Remi Denis-Courmont. 222 * General editing. Feedback from Alfred Hoenes. 224 Changes from draft-ietf-tcpm-ecnsyn-01: 226 * Changes in response to feedback from Anil Agarwal. 228 * Added a look at the costs of adding ECN-Capability to 229 SYN/ACKs in a highly-congested scenario. 230 From feedback from Mark Allman and Janardhan Iyengar. 232 * Added a comparative evaluation of two possible responses 233 to an ECN-marked SYN/ACK packet. From Mark Allman. 235 Changes from draft-ietf-tcpm-ecnsyn-00: 237 * Only updating the revision number. 239 Changes from draft-ietf-twvsg-ecnsyn-00: 241 * Changed name of draft to draft-ietf-tcpm-ecnsyn. 243 * Added a discussion in Section 3 of "Response to 244 ECN-marking of SYN/ACK packets". Based on 245 suggestions from Mark Allman. 247 * Added a discussion to the Conclusions about adding 248 ECN-capability to relevant set-up packets in other 249 protocols. From a suggestion from Wesley Eddy. 251 * Added a description of SYN exchanges with SYN cookies. 252 From a suggestion from Wesley Eddy. 254 * Added a discussion of one-way data transfers, where the 255 host sending the SYN/ACK packet sends no data packets. 257 * Minor editing, from feedback from Mark Allman and Janardhan 258 Iyengar. 260 * Future work: a look at the costs of adding 261 ECN-Capability in a worst-case scenario. 262 From feedback from Mark Allman and Janardhan Iyengar. 264 * Future work: a comparative evaluation of two 265 possible responses to an ECN-marked SYN/ACK packet. 267 Changes from draft-kuzmanovic-ecn-syn-00.txt: 269 * Changed name of draft to draft-ietf-twvsg-ecnsyn. 271 END OF NOTE TO RFC EDITOR. 273 1. Introduction 275 TCP's congestion control mechanism has primarily used packet loss as 276 the congestion indication, with packets dropped when buffers 277 overflow. With such tail-drop mechanisms, the packet delay can be 278 high, as the queue at bottleneck routers can be fairly large. 279 Dropping packets only when the queue overflows, and having TCP react 280 only to such losses, results in: 281 1) significantly higher packet delay; 282 2) unnecessarily many packet losses; and 283 3) unfairness due to synchronization effects. 285 The adoption of Active Queue Management (AQM) mechanisms allows 286 better control of bottleneck queues [RFC2309]. This use of AQM has 287 the following potential benefits: 288 1) better control of the queue, with reduced queueing delay; 289 2) fewer packet drops; and 290 3) better fairness because of fewer synchronization effects. 292 With the adoption of ECN, performance may be further improved. When 293 the router detects congestion before buffer overflow, the router can 294 provide a congestion indication either by dropping a packet, or by 295 setting the Congestion Experienced (CE) codepoint in the Explicit 296 Congestion Notification (ECN) field in the IP header [RFC3168]. The 297 IETF has standardized the use of the Congestion Experienced (CE) 298 codepoint in the IP header for routers to indicate congestion. For 299 incremental deployment and backwards compatibility, the RFC on ECN 300 [RFC3168] specifies that routers may mark ECN-capable packets that 301 would otherwise have been dropped, using the Congestion Experienced 302 codepoint in the ECN field. The use of ECN allows TCP to react to 303 congestion while avoiding unnecessary retransmission timeouts. Thus, 304 using ECN has several benefits: 306 1) For short transfers, a TCP connection's congestion window may be 307 small. For example, if the current window contains only one packet, 308 and that packet is dropped, TCP will have to wait for a 309 retransmission timeout to recover, reducing its overall throughput. 310 Similarly, if the current window contains only a few packets and one 311 of those packets is dropped, there might not be enough duplicate 312 acknowledgements for a fast retransmission, and the sender of the 313 data packet might have to wait for a delay of several round-trip 314 times using Limited Transmit [RFC3042]. With the use of ECN, short 315 flows are less likely to have packets dropped, sometimes avoiding 316 unnecessary delays or costly retransmission timeouts. 318 2) While longer flows may not see substantially improved throughput 319 with the use of ECN, they may experience lower loss. This may benefit 320 TCP applications that are latency- and loss-sensitive, because of the 321 avoidance of retransmissions. 323 RFC 3168 [RFC3168] specifies setting the ECN-Capable codepoint on TCP 324 data packets, but not on TCP SYN and SYN/ACK packets. RFC 3168 325 [RFC3168] specifies the negotiation of the use of ECN between the two 326 TCP end-points in the TCP SYN and SYN-ACK exchange, using flags in 327 the TCP header. Erring on the side of being conservative, RFC 3168 328 [RFC3168] does not specify the use of ECN for the first SYN/ACK 329 packet itself. However, because of the high cost to the TCP transfer 330 of having a SYN/ACK packet dropped, with the resulting retransmission 331 timeout, this document specifies the use of ECN for the SYN/ACK 332 packet itself. This can be of great benefit to the TCP connection, 333 avoiding the severe penalty of a retransmission timeout for a 334 connection that has not yet started placing a load on the network. 335 The sender of the SYN/ACK packet must respond to a report of an ECN- 336 marked SYN/ACK packet (a SYN/ACK packet with the CE codepoint set in 337 the ECN field in the IP header) by sending a non-ECN-Capable SYN/ACK 338 packet, and by reducing its initial congestion window from two, 339 three, or four segments to one segment, reducing the subsequent load 340 from that connection on the network. 342 The use of ECN for SYN/ACK packets has the following potential 343 benefits: 344 1) Avoidance of a retransmission timeout; 345 2) Improvement in the throughput of short connections. 347 This draft specifies a modification to RFC 3168 [RFC3168] to allow 348 TCP SYN/ACK packets to be ECN-Capable. Section 3 contains the 349 specification of the change, while Section 4 discusses some of the 350 issues, and Section 5 discusses related work. Section 6 contains an 351 evaluation of the specified change. 353 2. Conventions and Terminology 355 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 356 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 357 document are to be interpreted as described in [RFC2119]. 359 We use the following terminology from RFC 3168 [RFC3168]: 361 The ECN field in the IP header: 362 o CE: the Congestion Experienced codepoint; and 363 o ECT: either one of the two ECN-Capable Transport codepoints. 365 The ECN flags in the TCP header: 366 o CWR: the Congestion Window Reduced flag; and 367 o ECE: the ECN-Echo flag. 369 ECN-setup packets: 370 o ECN-setup SYN packet: a SYN packet with the ECE and CWR flags; 371 o ECN-setup SYN-ACK packet: a SYN-ACK packet with ECE but not CWR. 373 In this document we use the terms "initiator" and "responder" to 374 refer to the sender of the SYN packet and of the SYN-ACK packet, 375 respectively. 377 3. Specification 379 This section specifies the modification to RFC 3168 [RFC3168] to 380 allow TCP SYN/ACK packets to be ECN-Capable. 382 Section 6.1.1 of RFC 3168 [RFC3168] states that "A host MUST NOT set 383 ECT on SYN or SYN-ACK packets." In this section, we specify that a 384 TCP node may respond to an initial ECN-setup SYN packet by setting 385 ECT in the responding ECN-setup SYN/ACK packet, indicating to routers 386 that the SYN/ACK packet is ECN-Capable. This allows a congested 387 router along the path to mark the packet instead of dropping the 388 packet as an indication of congestion. 390 Assume that TCP node A transmits to TCP node B an ECN-setup SYN 391 packet, indicating willingness to use ECN for this connection. As 392 specified by RFC 3168 [RFC3168], if TCP node B is willing to use ECN, 393 node B responds with an ECN-setup SYN-ACK packet. 395 3.1. SYN/ACK Packets Dropped in the Network 397 Figure 1 shows an interchange with the SYN/ACK packet dropped by a 398 congested router. Node B waits for a retransmission timeout, and 399 then retransmits the SYN/ACK packet. 401 --------------------------------------------------------------- 402 TCP Node A Router TCP Node B 403 (initiator) (responder) 404 ---------- ------ ---------- 406 ECN-setup SYN packet ---> 407 ECN-setup SYN packet ---> 409 <--- ECN-setup SYN/ACK, possibly ECT 410 3-second timer set 411 SYN/ACK dropped . 412 . 413 . 414 3-second timer expires 415 <--- ECN-setup SYN/ACK, not ECT 416 <--- ECN-setup SYN/ACK 417 Data/ACK ---> 418 Data/ACK ---> 419 <--- Data (one to four segments) 420 --------------------------------------------------------------- 422 Figure 1: SYN exchange with the SYN/ACK packet dropped. 424 If the SYN/ACK packet is dropped in the network, the responder (node 425 B) responds by waiting three seconds for the retransmission timer to 426 expire [RFC2988]. If a SYN/ACK packet with the ECT codepoint is 427 dropped, the responder should resend the SYN/ACK packet without the 428 ECN-Capable codepoint. (Although we are not aware of any middleboxes 429 that drop SYN/ACK packets that contain an ECN-Capable codepoint in 430 the IP header, we have learned to design our protocols defensively in 431 this regard [RFC3360].) 433 We note that if syn-cookies were used by the responder (node B) in 434 the exchange in Figure 1, the responder wouldn't set a timer upon 435 transmission of the SYN/ACK packet [SYN-COOK] [RFC4987]. In this 436 case, if the SYN/ACK packet was lost, the initiator (Node A) would 437 have to timeout and retransmit the SYN packet in order to trigger 438 another SYN-ACK. 440 3.2. SYN/ACK Packets ECN-Marked in the Network 442 Figure 2 shows an interchange with the SYN/ACK packet sent as ECN- 443 Capable, and ECN-marked instead of dropped at the congested router. 444 This document specifies ECN+/TryOnce, which differs from the original 445 proposal for ECN+ in [ECN+]; with ECN+/TryOnce, if the TCP responder 446 is informed that the SYN/ACK was ECN-marked, the TCP responder 447 immediately sends a SYN/ACK packet that is not ECN-Capable. The TCP 448 responder is only allowed to send data packets after the TCP 449 initiator reports the receipt of a SYN/ACK packet that is not ECN- 450 marked. 452 --------------------------------------------------------------- 453 TCP Node A Router TCP Node B 454 (initiator) (responder) 455 ---------- ------ ---------- 457 ECN-setup SYN packet ---> 458 ECN-setup SYN packet ---> 460 <--- ECN-setup SYN/ACK, ECT 461 3-second timer set 462 <--- Sets CE on SYN/ACK 463 <--- ECN-setup SYN/ACK, CE 465 ACK, ECN-Echo ---> 466 ACK, ECN-Echo ---> 467 Window reduced to one segment. 468 <--- ECN-setup SYN/ACK, not ECT 469 <--- ECN-setup SYN/ACK 471 Data/ACK, ECT ---> 472 Data/ACK, ECT ---> 473 <--- Data, ECT (one segment only) 474 --------------------------------------------------------------- 476 Figure 2: SYN exchange with the SYN/ACK packet marked. 477 ECN+/TryOnce. 479 If the initiator (node A) receives a SYN/ACK packet that has been 480 ECN-marked by the congested router, with the CE codepoint set, the 481 initiator restarts the retransmission timer. The initiator responds 482 to the ECN-marked SYN/ACK packet by setting the ECN-Echo flag in the 483 TCP header of the responding ACK packet. The initiator uses the 484 standard rules in setting the cumulative acknowledgement field in the 485 responding ACK packet. 487 The initiator does not advance from the "SYN-Sent" to the 488 "Established" state until it receives a SYN/ACK packet that is not 489 ECN-marked. 491 When the responder (node B) receives the ECN-Echo packet reporting 492 the Congestion Experienced indication in the SYN/ACK packet, the 493 responder sets the initial congestion window to one segment, instead 494 of two segments as allowed by [RFC2581], or three or four segments 495 allowed by [RFC3390]. As illustrated in Figure 2, if the responder 496 (node B) receives an ECN-Echo packet informing it of a Congestion 497 Experienced indication on its SYN/ACK packet, the responder sends a 498 SYN/ACK packet that is not ECN-Capable, in addition to setting the 499 initial window to one segment. The responder does not advance the 500 send sequence number. The responder also sets the retransmission 501 timer. The responder follows RFC 2988 [RFC2988] in setting the RTO 502 (retransmission timeout). 504 The TCP hosts follow the standard specification for the response to 505 duplicate SYN/ACK packets (e.g., Section 3.4 of RFC 793 [RFC793]). 507 We note that the mechanism in this document differs from RFC 3168 508 [RFC3168], which specifies that "the sending TCP MUST restart the 509 retransmission timer on receiving the ECN-Echo packet when the 510 congestion window is one." RFC 3168 [RFC3168] does not allow SYN/ACK 511 packets to be ECN-Capable. RFC 3168 [RFC3168] specifies that in 512 response to an ECN-Echo packet, the TCP responder also sets the CWR 513 flag in the TCP header of the next data packet sent, to acknowledge 514 its receipt of and reaction to the ECN-Echo flag. In contrast, in 515 response to an ECN-Echo packet acknowledging the receipt of an ECN- 516 Capable SYN/ACK packet, the TCP responder doesn't set the CWR flag, 517 but simply sends a SYN/ACK packet that is not ECN-Capable. On 518 receiving the non-ECN-Capable SYN/ACK packet, the TCP initiator 519 clears the ECN-Echo flag on replying packets. 521 --------------------------------------------------------------- 522 TCP Node A Router TCP Node B 523 (initiator) (responder) 524 ---------- ------ ---------- 526 ECN-setup SYN packet ---> 527 ECN-setup SYN packet ---> 529 <--- ECN-setup SYN/ACK, ECT 530 <--- Sets CE on SYN/ACK 531 <--- ECN-setup SYN/ACK, CE 533 ACK, ECN-Echo ---> 534 ACK, ECN-Echo ---> 535 Window reduced to one segment. 537 <--- ECN-setup SYN/ACK, not ECT 538 3-second timer set 539 SYN/ACK dropped . 540 . 541 . 542 3-second timer expires 543 <--- ECN-setup SYN/ACK, not ECT 544 <--- ECN-setup SYN/ACK, not ECT 545 Data/ACK, ECT ---> 546 Data/ACK, ECT ---> 547 <--- Data, ECT (one segment only) 548 --------------------------------------------------------------- 550 Figure 3: SYN exchange with the first SYN/ACK packet marked, 551 and the second SYN/ACK packet dropped. ECN+/TryOnce. 553 In contrast to Figure 2, Figure 3 shows an interchange where the 554 first SYN/ACK packet is ECN-marked and the second SYN/ACK packet is 555 dropped in the network. As in Figure 2, the TCP responder sets a 556 timer when the second SYN/ACK packet is sent. Figure 3 shows that if 557 the timer expires before the TCP responder receives an 558 acknowledgement for the other end, the TCP responder resends the 559 SYN/ACK packet, following the TCP standards. 561 3.3. Management Interface 563 The TCP implementation using ECN-Capable SYN/ACK packets should 564 include a management interface to allow the use of ECN to be turned 565 off for SYN/ACK packets. This is to deal with possible backwards 566 compatibility problems such as those discussed in Appendix B. 568 4. Discussion 570 The rationale for the specification in this document is the 571 following. When node B receives a TCP SYN packet with ECN-Echo bit 572 set in the TCP header, this indicates that node A is ECN-capable. If 573 node B is also ECN-capable, there are no obstacles to immediately 574 setting one of the ECN-Capable codepoints in the IP header in the 575 responding TCP SYN/ACK packet. 577 There can be a great benefit in setting an ECN-capable codepoint in 578 SYN/ACK packets, as is discussed further in [ECN+], and reported 579 briefly in Section 5 below. Congestion is most likely to occur in 580 the server-to-client direction. As a result, setting an ECN-capable 581 codepoint in SYN/ACK packets can reduce the occurrence of three- 582 second retransmission timeouts resulting from the drop of SYN/ACK 583 packets. 585 4.1. Flooding Attacks 587 Setting an ECN-Capable codepoint in the responding TCP SYN/ACK 588 packets does not raise any new or additional security 589 vulnerabilities. For example, provoking servers or hosts to send 590 SYN/ACK packets to a third party in order to perform a "SYN/ACK 591 flood" attack would be highly inefficient. Third parties would 592 immediately drop such packets, since they would know that they didn't 593 generate the TCP SYN packets in the first place. Moreover, such 594 SYN/ACK attacks would have the same signatures as the existing TCP 595 SYN attacks. Provoking servers or hosts to reply with SYN/ACK packets 596 in order to congest a certain link would also be highly inefficient 597 because SYN/ACK packets are small in size. 599 However, the addition of ECN-Capability to SYN/ACK packets could 600 allow SYN/ACK packets to persist for more hops along a network path 601 before being dropped, thus adding somewhat to the ability of a 602 SYN/ACK attack to flood a network link. 604 4.2. The TCP SYN Packet 606 There are several reasons why an ECN-Capable codepoint must not be 607 set in the IP header of the initiating TCP SYN packet. First, when 608 the TCP SYN packet is sent, there are no guarantees that the other 609 TCP endpoint (node B in Figure 2) is ECN-capable, or that it would be 610 able to understand and react if the ECN CE codepoint was set by a 611 congested router. 613 Second, the ECN-Capable codepoint in TCP SYN packets could be misused 614 by malicious clients to `improve' the well-known TCP SYN attack. By 615 setting an ECN-Capable codepoint in TCP SYN packets, a malicious host 616 might be able to inject a large number of TCP SYN packets through a 617 potentially congested ECN-enabled router, congesting it even further. 619 For both these reasons, we continue the restriction that the TCP SYN 620 packet must not have the ECN-Capable codepoint in the IP header set. 622 4.3. SYN/ACK Packets and Packet Size 624 There are a number of router buffer architectures that have smaller 625 dropping rates for small (SYN) packets than for large (data) packets. 626 For example, for a Drop Tail queue in units of packets, where each 627 packet takes a single slot in the buffer regardless of packet size, 628 small and large packets are equally likely to be dropped. However, 629 for a Drop Tail queue in units of bytes, small packets are less 630 likely to be dropped than are large ones. Similarly, for RED in 631 packet mode, small and large packets are equally likely to be dropped 632 or marked, while for RED in byte mode, a packet's chance of being 633 dropped or marked is proportional to the packet size in bytes. 635 For a congested router with an AQM mechanism in byte mode, where a 636 packet's chance of being dropped or marked is proportional to the 637 packet size in bytes, the drop or marking rate for TCP SYN/ACK 638 packets should generally be low. In this case, the benefit of making 639 SYN/ACK packets ECN-Capable should be similarly moderate. However, 640 for a congested router with a Drop Tail queue in units of packets or 641 with an AQM mechanism in packet mode, and with no priority queueing 642 for smaller packets, small and large packets should have the same 643 probability of being dropped or marked. In such a case, making 644 SYN/ACK packets ECN-Capable should be of significant benefit. 646 We believe that there are a wide range of behaviors in the real world 647 in terms of the drop or mark behavior at routers as a function of 648 packet size [Tools] (Section 10). We note that all of these 649 alternatives listed above are available in the NS simulator (Drop 650 Tail queues are by default in units of packets, while the default for 651 RED queue management has been changed from packet mode to byte mode). 653 4.4. Response to ECN-marking of SYN/ACK Packets 655 One question is why TCP SYN/ACK packets should be treated differently 656 from other packets in terms of the end node's response to an ECN- 657 marked packet. Section 5 of RFC 3168 [RFC3168] specifies the 658 following: 660 "Upon the receipt by an ECN-Capable transport of a single CE packet, 661 the congestion control algorithms followed at the end-systems MUST be 662 essentially the same as the congestion control response to a *single* 663 dropped packet. For example, for ECN-Capable TCP the source TCP is 664 required to halve its congestion window for any window of data 665 containing either a packet drop or an ECN indication." 667 In particular, Section 6.1.2 of RFC 3168 [RFC3168] specifies that 668 when the TCP congestion window consists of a single packet and that 669 packet is ECN-marked in the network, then the data sender must reduce 670 the sending rate below one packet per round-trip time, by waiting for 671 one RTO before sending another packet. If the RTO was set to the 672 average round-trip time, this would result in halving the sending 673 rate; because the RTO is in fact larger than the average round-trip 674 time, the sending rate is reduced to less than half of its previous 675 value. 677 TCP's congestion control response to the *dropping* of a SYN/ACK 678 packet is to wait a default time before sending another packet. This 679 document argues that ECN gives end-systems a wider range of possible 680 responses to the *marking* of a SYN/ACK packet, and that waiting a 681 default time before sending another packet is not the desired 682 response. 684 On the conservative end, one could assume an effective congestion 685 window of one packet for the SYN/ACK packet, and respond to an ECN- 686 marked SYN/ACK packet by reducing the sending rate to one packet 687 every two round-trip times. As an approximation, the TCP end-node 688 could measure the round-trip time T between the sending of the 689 SYN/ACK packet and the receipt of the acknowledgement, and reply to 690 the acknowledgement of the ECN-marked SYN/ACK packet by waiting T 691 seconds before sending a data packet. 693 However, we note that for an ECN-marked SYN/ACK packet, halving the 694 *congestion window* is not the same as halving the *sending rate*; 695 there is no `sending rate' associated with an ECN-Capable SYN/ACK 696 packet, as such packets are only sent as the first packet in a 697 connection from that host. Further, a router's marking of a SYN/ACK 698 packet is not affected by any past history of that connection. 700 Adding ECN-Capability to SYN/ACK packets allows the response of the 701 responder setting the initial congestion window to one packet, 702 instead of its allowed default value of two, three, or four packets. 703 The responder sends a non-ECN-Capable SYN/ACK packet, and proceeds 704 with a cautious sending rate of one data packet per round-trip time 705 after that SYN/ACK packet is acknowledged. This document argues that 706 this approach is useful to users, with no dangers of congestion 707 collapse or of starvation of competing traffic. This is discussed in 708 more detail below in Section 6.2. 710 We note that if the data transfer is entirely from Node A to Node B, 711 there is still a difference in performance between the original 712 mechanism ECN+ and the mechanism ECN+/TryOnce specified in this 713 document. In particular, with ECN+/TryOnce the TCP originator does 714 not send data packets until it has received a non-ECN-marked SYN/ACK 715 packet from the other end. 717 5. Related Work 719 The addition of ECN-capability to TCP's SYN/ACK packets was initially 720 proposed in [ECN+]. The paper includes an extensive set of 721 simulation and testbed experiments to evaluate the effects of the 722 proposal, using several Active Queue Management (AQM) mechanisms, 723 including Random Early Detection (RED) [RED], Random Exponential 724 Marking (REM) [REM], and Proportional Integrator (PI) [PI]. The 725 performance measures were the end-to-end response times for each 726 request/response pair, and the aggregate throughput on the bottleneck 727 link. The end-to-end response time was computed as the time from the 728 moment when the request for the file is sent to the server, until 729 that file is successfully downloaded by the client. 731 The measurements from [ECN+] show that setting an ECN-Capable 732 codepoint in the IP packet header in TCP SYN/ACK packets 733 systematically improves performance with all evaluated AQM schemes. 734 When SYN/ACK packets at a congested router are ECN-marked instead of 735 dropped, this can avoid a long initial retransmission timeout, 736 improving the response time for the affected flow dramatically. 738 [ECN+] shows that the impact on aggregate throughput can also be 739 quite significant, because marking SYN ACK packets can prevent larger 740 flows from suffering long timeouts before being "admitted" into the 741 network. In addition, the testbed measurements from [ECN+] show that 742 web servers setting the ECN-Capable codepoint in TCP SYN/ACK packets 743 could serve more requests. 745 As a final step, [ECN+] explores the co-existence of flows that do 746 and don't set the ECN-capable codepoint in TCP SYN/ACK packets. The 747 results in [ECN+] show that both types of flows can coexist, with 748 some performance degradation for flows that don't use ECN+. Flows 749 that do use ECN+ improve their end-to-end performance. At the same 750 time, the performance degradation for flows that don't use ECN+, as a 751 result of the flows that do use ECN+, increases as a greater fraction 752 of flows use ECN+. 754 6. Performance Evaluation 756 6.1. The Costs and Benefit of Adding ECN-Capability 758 [ECN+] explores the costs and benefits of adding ECN-Capability to 759 SYN/ACK packets with both simulations and experiments. The addition 760 of ECN-capability to SYN/ACK packets could be of significant benefit 761 for those ECN connections that would have had the SYN/ACK packet 762 dropped in the network, and for which the ECN-Capability would allow 763 the SYN/ACK to be marked rather than dropped. 765 The percent of SYN/ACK packets on a link can be quite high. In 766 particular, measurements on links dominated by web traffic indicate 767 that 15-20% of the packets can be SYN/ACK packets [SCJO01]. 769 The benefit of adding ECN-capability to SYN/ACK packets depends in 770 part on the size of the data transfer. The drop of a SYN/ACK packet 771 can increase the download time of a short file by an order of 772 magnitude, by requiring a three-second retransmission timeout. For 773 longer-lived flows, the effect of a dropped SYN/ACK packet on file 774 download time is less dramatic. However, even for longer-lived 775 flows, the addition of ECN-capability to SYN/ACK packets can improve 776 the fairness among long-lived flows, as newly-arriving flows would be 777 less likely to have to wait for retransmission timeouts. 779 One question that arises is what fraction of connections would see 780 the benefit from making SYN/ACK packets ECN-capable, in a particular 781 scenario. Specifically: 783 (1) What fraction of arriving SYN/ACK packets are dropped at the 784 congested router when the SYN/ACK packets are not ECN-capable? 786 (2) Of those SYN/ACK packets that are dropped, what fraction would 787 have been ECN-marked instead of dropped if the SYN/ACK packets had 788 been ECN-capable? 790 To answer (1), it is necessary to consider not only the level of 791 congestion but also the queue architecture at the congested link. As 792 described in Section 4 above, for some queue architectures small 793 packets are less likely to be dropped than large ones. In such an 794 environment, SYN/ACK packets would have lower packet drop rates; 795 question (1) could not necessarily be inferred from the overall 796 packet drop rate, but could be answered by measuring the drop rate 797 for SYN/ACK packets directly. In such an environment, adding ECN- 798 capability to SYN/ACK packets would be of less dramatic benefit than 799 in environments where all packets are equally likely to be dropped 800 regardless of packet size. 802 As question (2) implies, even if all of the SYN/ACK packets were ECN- 803 capable, there could still be some SYN/ACK packets dropped instead of 804 marked at the congested link; the full answer to question (2) depends 805 on the details of the queue management mechanism at the router. If 806 congestion is sufficiently bad, and the queue management mechanism 807 cannot prevent the buffer from overflowing, then SYN/ACK packets will 808 be dropped rather than marked upon buffer overflow whether or not 809 they are ECN-capable. 811 For some AQM mechanisms, ECN-capable packets are marked instead of 812 dropped any time this is possible, that is, any time the buffer is 813 not yet full. For other AQM mechanisms however, such as the RED 814 mechanism as recommended in [RED], packets are dropped rather than 815 marked when the packet drop/mark rate exceeds a certain threshold, 816 e.g., 10%, even if the packets are ECN-capable. For a router with 817 such an AQM mechanism, when congestion is sufficiently severe to 818 cause a high drop/mark rate, some SYN/ACK packets would be dropped 819 instead of marked whether or not they were ECN-capable. 821 Thus, the degree of benefit of adding ECN-Capability to SYN/ACK 822 packets depends not only on the overall packet drop rate in the 823 network, but also on the queue management architecture at the 824 congested link. 826 6.2. An Evaluation of Different Responses to ECN-Marked SYN/ACK Packets 828 This document specifies that the end-node responds to the report of 829 an ECN-marked SYN/ACK packet by setting the initial congestion window 830 to one segment, instead of its possible default value of two to four 831 segments, and resending a SYN/ACK packet that is not ECN-Capable. We 832 call this ECN+/TryOnce. 834 However, Section 4 discussed two other possible responses to an ECN- 835 marked SYN/ACK packet. In ECN+, the original proposal from [ECN+], 836 the end node responds to the report of an ECN-marked SYN/ACK packet 837 by setting the initial congestion window to one segment and 838 immediately sending a data packet, if it has one to send. In 839 ECN+/Wait, the end node responds to the report of an ECN-marked 840 SYN/ACK packet by setting the initial congestion window to one 841 segment and waiting an RTT before sending a data packet. 843 Simulations comparing the performance with Standard ECN (without ECN- 844 marked SYN/ACK packets), ECN+, ECN+/Wait, and ECN/TryOnce show little 845 difference, in terms of aggregate congestion, between ECN+ and 846 ECN+/Wait. However, for some scenarios with queues that are packet- 847 based rather than byte-based, and with packet drop rates above 25% 848 without ECN+, the use of ECN+ or of ECN+/Wait can more than double 849 the packet drop rates, to greater than 50%. The details are given in 850 Tables 1 and 3 of Appendix A below. ECN+/TryOnce does not increase 851 the packet drop rate in scenarios of high congestion. Therefore, 852 ECN+/TryOnce is superior to ECN+ or to ECN+/Wait, which both 853 significantly increase the packet drop rate in scenarios of high 854 congestion. At the same time, ECN+/TryOnce gives a performance 855 improvement similar to that of ECN+ or ECN+/Wait (Tables 2 and 4 of 856 Appendix A). 858 Our conclusions are that ECN+/TryOnce is safe, and has significant 859 benefits to the user, and avoids the problems of ECN+ or ECN+/Wait 860 under extreme levels of congestion. As a consequence, this document 861 specifies the use of ECN+/TryOnce. 863 [Note: We only discovered the occasional congestion-related problems 864 of ECN+ and of ECN+/Wait when re-running the simulations with an 865 updated version of the ns-2 simulator, after the internet-draft had 866 almost completed the standardization process.] 868 6.3. Experiments 870 This section discusses experiments that would be useful before a 871 widespread deployment of ECN-Capability for TCP SYN/ACK packets. 873 Section 7.1 below discusses some of the know deployment problems of 874 ECN, in terms of routers or middleboxes that react inappropriately to 875 packets that use ECN codepoints in the IP or TCP packet headers. One 876 goal of a measurement study of ECN-Capablility for TCP SYN/ACK 877 packets would be to determine if there were any routers or 878 middleboxes that react inappropriately to TCP SYN/ACK packets 879 containing an ECN-Capable or CE codepoint in the IP header. A second 880 goal of a measurement study would be to check the deployment status 881 of older TCP implementations that are ECN-Capable, but that don't 882 respond to ECN-Capability for SYN/ACK packets. (This is discussed in 883 more detail in Appendix B below.) 885 Following the discussion in Section 6.2, an experimental study could 886 explore the use of ECN-Capability for TCP SYN/ACK packets in highly- 887 congested environments with ECN-capable routers. 889 7. Security Considerations 891 TCP packets carrying the ECT codepoint in IP headers can be marked 892 rather than dropped by ECN-capable routers. This raises several 893 security concerns that we discuss below. 895 7.1. 'Bad' Routers or Middleboxes 897 There are a number of known deployment problems from using ECN with 898 TCP traffic in the Internet. The first reported problem, dating back 899 to 2000, is of a small but decreasing number of routers or 900 middleboxes that reset a TCP connection in response to TCP SYN 901 packets using flags in the TCP header to negotiate ECN-capability 902 [Kelson00] [RFC3360] [MAF05]. Dave Thaler reported at the March 2007 903 IETF of new two problems encountered by TCP connections using ECN; 904 the first of the two problems concerns routers that crash when a TCP 905 data packet arrives with the ECN field in the IP header with the 906 codepoint ECT(0) or ECT(1), indicating that an ECN-Capable connection 907 has been established [SBT07]. 909 While there is no evidence that any routers or middleboxes drop 910 SYN/ACK packets that contain an ECN-Capable or CE codepoint in the IP 911 header, such behavior cannot be excluded. (There seems to be a 912 number of routers or middleboxes that drop TCP SYN packets that 913 contain known or unknown IP options [MAF05] (Figure 1).) Thus, as 914 specified in Section 3, if a SYN/ACK packet with the ECT or CE 915 codepoint is dropped, the TCP node should resend the SYN/ACK packet 916 without the ECN-Capable codepoint. There is also no evidence that 917 any routers or middleboxes crash when a SYN/ACK arrives with an ECN- 918 Capable or CE codepoint in the IP header (over and above the routers 919 already known to crash when a data packet arrives with either ECT(0) 920 or ECT(1)), but we have not conducted any measurement studies of this 921 [F07]. 923 7.2. Congestion Collapse 925 Because TCP SYN/ACK packets carrying an ECT codepoint could be ECN- 926 marked instead of dropped at an ECN-capable router, the concern is 927 whether this can either invoke congestion, or worsen performance in 928 highly congested scenarios. However, after learning that a SYN/ACK 929 packet was ECN-marked, the responder sends a SYN/ACK packet that is 930 not ECN-Capable; if this SYN/ACK packet is dropped, the responder 931 then waits for a retransmission timeout, as specified in the TCP 932 standards. In addition, routers are free to drop rather than mark 933 arriving packets in times of high congestion, regardless of whether 934 the packets are ECN-capable. When congestion is very high and a 935 router's buffer is full, the router has no choice but to drop rather 936 than to mark an arriving packet. 938 The simulations reported in Appendix A show that even with demanding 939 traffic mixes dominated by short flows and high levels of congestion, 940 the aggregate packet dropping rates are not significantly different 941 with Standard ECN or with ECN+/TryOnce. However, in our simulations, 942 we have one scenario where ECN+ or ECN+/Wait results in a 943 significantly higher packet drop rate than ECN or ECN+/TryOnce 944 (Tables 1 and 3 in Appendix A below). 946 8. Conclusions 948 This draft specifies a modification to RFC 3168 [RFC3168] to allow 949 TCP nodes to send SYN/ACK packets as being ECN-Capable. Making the 950 SYN/ACK packet ECN-Capable avoids the high cost to a TCP transfer 951 when a SYN/ACK packet is dropped by a congested router, by avoiding 952 the resulting retransmission timeout. This improves the throughput 953 of short connections. This document specifies the ECN+/TryOnce 954 mechanism for ECN-Capability for SYN/ACK packets, where the sender of 955 the SYN/ACK packet responds to an ECN mark by reducing its initial 956 congestion window from two, three, or four segments to one segment, 957 and sending a SYN/ACK packet that is not ECN-Capable. The addition 958 of ECN-capability to SYN/ACK packets is particularly beneficial in 959 the server-to-client direction, where congestion is more likely to 960 occur. In this case, the initial information provided by the ECN 961 marking in the SYN/ACK packet enables the server to appropriately 962 adjust the initial load it places on the network, while avoiding the 963 delay of a retransmission timeout. 965 9. Acknowledgements 967 We thank Anil Agarwal, Mark Allman, Remi Denis-Courmont, Wesley Eddy, 968 Lars Eggert, Alfred Hoenes, Janardhan Iyengar, and Pasi Sarolahti for 969 feedback on earlier versions of this draft. We thank Adam Langley 970 [L08] for contributing a patch for ECN+/TryOnce for the Linux 971 development tree. 973 A. Report on Simulations 975 This section reports on simulations showing the costs of adding ECN+ 976 in highly-congested scenarios. This section also reports on 977 simulations for a comparative evaluation between ECN, ECN+, 978 ECN+/Wait, and ECN+/TryOnce. 980 The simulations are run with a range of file-size distributions, 981 using the PackMime traffic generator in the ns-2 simulator. They all 982 use a heavy-tailed distribution of file sizes. The simulations 983 reported in the tables below use a mean file size of 3 KBypes, to 984 show the results with a traffic mix with a large number of small 985 transfers. Other simulations were run with mean file sizes of 5 986 KBytes, 7 Kbytes, 14 KBytes, and 17 Kbytes. The title of each chart 987 gives the targeted average load from the traffic generator. Because 988 the simulations use a heavy-tailed distribution of file sizes, and 989 run for only 85 seconds (including ten seconds of warm-up time), the 990 actual load is often much smaller than the targeted load. The 991 congested link is 100 Mbps. RED is run in gentle mode, and arriving 992 ECN-Capable packets are only dropped instead of marked if the buffer 993 is full (and the router has no choice). 995 We explore three possible mechanisms for a TCP node's response to a 996 report of an ECN-marked SYN/ACK packet. With ECN+, the TCP node 997 sends a data packet immediately (with an initial congestion window of 998 one segment). With ECN+/Wait, the TCP node waits a round-trip time 999 before sending a data packet; the responder already has one 1000 measurement of the round-trip time when the acknowledgement for the 1001 SYN/ACK packet is received. With ECN+/TryOnce, the mechanism 1002 standardized in this document, the TCP responder replies to a report 1003 of an ECN-marked SYN/ACK packet by sending a SYN/ACK packet that is 1004 not ECN-Capable, and reducing the initial congestion window to one 1005 segment. 1007 The simulation scripts are available on [ECN-SYN]. along with graphs 1008 showing the distribution of response times for the TCP connections. 1010 A.1. Simulations with RED in Packet Mode 1012 The simulations with RED in packet mode and with the queue in packets 1013 show that ECN+ is useful in times of moderate or of high congestion. 1014 However, for the simulations with a target load of 125%, with a 1015 packet loss rate of over 25% for ECN, ECN+ and ECN+/Wait both result 1016 in a packet loss rate of over 50%. (In contrast, the packet loss 1017 rate with ECN+/TryOnce is less than that of ECN alone.) For the 1018 distribution of response times, the simulations show that ECN+, 1019 ECN+/Wait, and ECN+/TryOnce all significantly improve the response 1020 times, compared to the response times with plain ECN. 1022 Table 1 shows the congestion levels for simulations with RED in 1023 packet mode, with a queue in packets. To explore a worst-case 1024 scenario, these simulations use a traffic mix with an unrealistically 1025 small flow size distribution, with a mean flow size of 3 Kbytes. For 1026 each table showing a particular traffic load, the four rows show the 1027 number of packets dropped, the number of packets ECN-marked, the 1028 aggregate packet drop rate, and the aggregate throughput, and the 1029 four columns show the simulations with Standard ECN, ECN+, ECN+/Wait, 1030 and ECN+/TryOnce. 1032 These simulations were run with RED set to mark instead of drop 1033 packets any time that the queue is not full. This is a worst-case 1034 scenario for ECN+ and its variants. For the default implementation 1035 of RED in the ns-2 simulator, when the average queue size exceeds a 1036 configured threshold, the router drops all arriving packets. For 1037 scenarios with this RED mechanisms, it is less likely that ECN+ or 1038 one of its variants would increase the average queue size above the 1039 configured threshold. 1041 The usefulness of ECN+: The first thing to observe is that for all of 1042 the simulations, the use of ECN+ or ECN+/Wait significantly increases 1043 the number of packets marked. In contrast, the use of ECN+/TryOnce 1044 significantly increases the number of packets marked in the 1045 simulations with moderate congestion, and gives a more moderate 1046 increase in the number of packets marked for the simulations with 1047 higher levels of congestion. However, the cumulative distribution 1048 function (CDF) in Table 2 shows that ECN+, ECN+/Wait, and 1049 ECN+/TryOnce all improve response times for all of the simulations, 1050 with moderate or with larger levels of congestion. 1052 Little increase in congestion, sometimes: The second thing to observe 1053 is that for the simulations with low or moderate levels of congestion 1054 (that is, with packet drop rates less than 10%), the use of ECN+, 1055 ECN+/Wait, and ECN+/TryOnce all decrease the aggregate packet drop 1056 rate, relative to the simulations with ECN. This makes sense, since 1057 with low or moderate levels of congestion, ECN+ allows SYN/ACK 1058 packets to be marked instead of dropped, and the use of ECN+ doesn't 1059 add to the aggregate congestion. However, for the simulations with 1060 packet drop rates of 15% or higher with ECN, the use of ECN+ or 1061 ECN+/Wait increases the aggregate packet drop rate, sometimes even 1062 doubling it. 1064 Comparing ECN+, ECN+/Wait, and ECN+/TryOnce: The aggregate packet 1065 drop rate is generally higher with ECN+/Wait than with ECN+. Thus, 1066 there is no congestion-related reason to prefer ECN+/Wait over ECN+. 1067 In contrast, the aggregate packet drop rate with ECN+/TryOnce is 1068 often significantly lower than the aggregate packet drop rate with 1069 either ECN, ECN+, ECN+/Wait. 1071 Target Load = 95%: 1072 ECN ECN+ ECN+/Wait ECN+/TryOnce 1073 ------- ------- ------- ---------- 1074 Dropped 20,516 11,226 11,735 16,755` 1075 Marked 30,586 37,741 37,425 40,764 1076 Loss rate 1.41% 0.78% 0.81% 1.02% 1077 Throughput 81% 81% 81% 81% 1079 Target Load = 110%: 1080 ECN ECN+ ECN+/Wait ECN+/TryOnce 1081 ------- ------- ------- ---------- 1082 Dropped 165,566 106,083 147,180 208,422 1083 Marked 179,735 281,306 308,473 235,483 1084 Loss rate 9.01% 6.12% 8.02% 6.89% 1085 Throughput 92% 92% 92% 94% 1087 Target Load = 125%: 1088 ECN ECN+ ECN+/Wait ECN+/TryOnce 1089 ------- ------- ------- ---------- 1090 Dropped 600,628 1,746,768 2,176,530 625,552 1091 Marked 418,433 1,166,450 1,164,932 439,847 1092 Loss rate 25.45% 51.73% 56.87% 18.31% 1093 Throughput 94% 98% 97% 95% 1095 Target Load = 150% 1096 ECN ECN+ ECN+/Wait ECN+/TryOnce 1097 ------- ------- ------- ---------- 1098 Dropped 1,449,945 1,565,0517 1,563,0801 1,351,637 1099 Marked 669,840 583,378 591,315 684,715 1100 Loss rate 46.7% 59.0% 59.0% 32.7% 1101 Throughput 88% 94% 94% 92% 1103 Table 1: Simulations with an average flow size of 3 Kbytes, a 1104 100 Mbps link, RED in packet mode, queue in packets. 1106 Target Load = 95%: 1107 TIME: 10 100 200 300 400 500 1000 2000 3000 4000 5000 1108 ------------------------------------------------------ 1109 ECN: 0.00 0.07 0.26 0.51 0.82 0.96 0.97 0.97 0.97 1.00 1.00 1110 ECN+: 0.00 0.07 0.27 0.53 0.85 0.99 1.00 1.00 1.00 1.00 1.00 1111 Wait: 0.00 0.07 0.26 0.51 0.83 0.97 1.00 1.00 1.00 1.00 1.00 1112 Once: 0.00 0.07 0.24 0.49 0.83 0.97 1.00 1.00 1.00 1.00 1.00 1114 Target Load = 110%: 1115 TIME: 10 100 200 300 400 500 1000 2000 3000 4000 5000 1116 ------------------------------------------------------ 1117 ECN: 0.00 0.05 0.19 0.41 0.67 0.79 0.80 0.80 0.80 0.96 0.96 1118 ECN+: 0.00 0.07 0.22 0.48 0.81 0.96 1.00 1.00 1.00 1.00 1.00 1119 Wait: 0.00 0.05 0.18 0.38 0.64 0.77 0.95 1.00 1.00 1.00 1.00 1120 Once: 0.00 0.06 0.19 0.42 0.70 0.86 0.95 0.96 0.96 0.99 0.99 1122 Target Load = 125%: 1123 TIME: 10 100 200 300 400 500 1000 2000 3000 4000 5000 1124 ------------------------------------------------------ 1125 ECN: 0.00 0.04 0.13 0.27 0.46 0.56 0.58 0.59 0.59 0.82 0.82 1126 ECN+: 0.00 0.06 0.18 0.33 0.58 0.76 0.97 0.99 0.99 1.00 1.00 1127 Wait: 0.00 0.01 0.06 0.13 0.21 0.27 0.68 0.98 0.99 1.00 1.00 1128 Once: 0.00 0.05 0.16 0.34 0.58 0.73 0.85 0.87 0.87 0.95 0.96 1130 Target Load = 150%: 1131 TIME: 10 100 200 300 400 500 1000 2000 3000 4000 5000 1132 ------------------------------------------------------ 1133 ECN: 0.00 0.03 0.08 0.18 0.31 0.39 0.42 0.42 0.43 0.68 0.68 1134 ECN+: 0.00 0.06 0.18 0.39 0.67 0.81 0.83 0.84 0.84 0.93 0.93 1135 Wait: 0.00 0.06 0.18 0.39 0.67 0.81 0.83 0.84 0.84 0.93 0.94 1136 Once: 0.00 0.04 0.13 0.27 0.46 0.59 0.72 0.75 0.75 0.88 0.88 1138 Table 2: The cumulative distribution function (CDF) for transfer 1139 times, for simulations with an average flow size of 3 Kbytes, a 1140 100 Mbps link, RED in packet mode, queue in packets. (The graphs are 1141 available from "http://www.icir.org/floyd/ecn-syn/".) 1142 Target Load = 95% 1143 ECN ECN+ ECN+/Wait ECN+/TryOnce 1144 ------- ------- ------- ---------- 1145 Dropped 8,448 6,362 7,740 14,107 1146 Marked 9,891 16,787 17,456 16,132 1147 Loss rate 5.5% 4.3% 5.0% 5.0% 1148 Throughput 78% 78% 78% 81% 1150 Target Load = 110% 1151 ECN ECN+ ECN+/Wait ECN+/TryOnce 1152 ------- ------- ------- ---------- 1153 Dropped 31,284 29,773 49,297 45,277 1154 Marked 28,429 54,729 60,383 34,622 1155 Loss rate 15.3% 15.2% 21.9% 13.6% 1156 Throughput 97% 96% 96% 94% 1158 Target Load = 125% 1159 ECN ECN+ ECN+/Wait ECN+/TryOnce 1160 ------- ------- ------- ---------- 1161 Dropped 61,433 176,682 214,096 75,612 1162 Marked 44,408 119,728 117,301 49,442 1163 Loss rate 25.4% 51.9% 56.0% 22.3% 1164 Throughput 97% 98% 98% 96% 1166 Target Load = 150% 1167 ECN ECN+ ECN+/Wait ECN+/TryOnce 1168 ------- ------- ------- ---------- 1169 Dropped 130,007 251,856 326,845 133,603 1170 Marked 63,066 146,757 147,239 66,444 1171 Loss rate 42.5% 61.3% 67.3% 31.7% 1172 Throughput 93% 99% 99% 94% 1174 Table 3: Simulations with an average flow size of 3 Kbytes, a 10 Mbps 1175 link, RED in packet mode, queue in packets. 1177 Target Load = 95%: 1178 TIME: 10 100 200 300 400 500 1000 2000 3000 4000 5000 1179 ------------------------------------------------------ 1180 ECN: 0.00 0.05 0.18 0.42 0.70 0.86 0.88 0.88 0.88 0.98 0.98 1181 ECN+: 0.00 0.06 0.20 0.45 0.78 0.96 1.00 1.00 1.00 1.00 1.00 1182 Wait: 0.00 0.05 0.18 0.40 0.68 0.84 0.96 1.00 1.00 1.00 1.00 1183 Once: 0.00 0.05 0.18 0.40 0.71 0.88 0.96 0.97 0.97 0.99 0.99 1185 Target Load = 110%: 1186 TIME: 10 100 200 300 400 500 1000 2000 3000 4000 5000 1187 ------------------------------------------------------ 1188 ECN: 0.00 0.03 0.13 0.29 0.52 0.66 0.69 0.69 0.69 0.91 0.91 1189 ECN+: 0.00 0.05 0.17 0.36 0.66 0.88 0.98 0.99 1.00 1.00 1.00 1190 Wait: 0.00 0.02 0.08 0.20 0.35 0.47 0.76 0.98 1.00 1.00 1.00 1191 Once: 0.00 0.05 0.15 0.32 0.58 0.75 0.88 0.90 0.90 0.97 0.97 1193 Target Load = 125%: 1194 TIME: 10 100 200 300 400 500 1000 2000 3000 4000 5000 1195 ------------------------------------------------------ 1196 ECN: 0.00 0.03 0.10 0.22 0.40 0.52 0.56 0.56 0.57 0.82 0.82 1197 ECN+: 0.00 0.03 0.14 0.27 0.49 0.70 0.96 0.99 0.99 0.99 1.00 1198 Wait: 0.00 0.00 0.03 0.07 0.12 0.18 0.50 0.94 0.99 0.99 1.00 1199 Once: 0.00 0.04 0.13 0.28 0.51 0.66 0.81 0.84 0.84 0.94 0.94 1201 Target Load = 150%: 1202 TIME: 10 100 200 300 400 500 1000 2000 3000 4000 5000 1203 ------------------------------------------------------ 1204 ECN: 0.00 0.02 0.07 0.15 0.28 0.38 0.42 0.42 0.43 0.67 0.68 1205 ECN+: 0.00 0.00 0.00 0.00 0.01 0.05 0.68 0.83 0.95 0.97 0.98 1206 Wait: 0.00 0.00 0.00 0.00 0.00 0.00 0.10 0.62 0.83 0.93 0.97 1207 Once: 0.00 0.03 0.11 0.24 0.42 0.56 0.71 0.75 0.75 0.88 0.88 1209 Table 4: The cumulative distribution function (CDF) for transfer 1210 times, for simulations with an average flow size of 3 Kbytes, a 1211 10 Mbps link, RED in packet mode, queue in packets. (The graphs are 1212 available from "http://www.icir.org/floyd/ecn-syn/".) 1214 A.2. Simulations with RED in Byte Mode 1216 Table 5 below shows simulations with RED in byte mode and the queue 1217 in bytes. There is no significant increase in aggregate congestion 1218 with the use of ECN+, ECN+/Wait, or ECN+/TryOnce. 1220 However, unlike the simulations with RED in packet mode, the 1221 simulations with RED in byte mode show little benefit from the use of 1222 ECN+ or ECN+/Wait, in that the packet marking rate with ECN+ or 1223 ECN+/Wait is not much different than the packet marking rate with 1224 Standard ECN. This is because with RED in byte mode, small packets 1225 like SYN/ACK packets are rarely dropped or marked - that is, there is 1226 no drawback from the use of ECN+ in these scenarios, but not much 1227 need for ECN+ either, in a scenario where small packets are unlikely 1228 to be dropped or marked. 1230 Target Load = 95% 1231 ECN ECN+ ECN+/Wait ECN+/TryOnce 1232 ------- ------- ------- ---------- 1233 Dropped 766 446 427 408 1234 Marked 32,683 34,289 33,412 31,892 1235 Loss rate 0.05% 0.03% 0.03% 0.03% 1236 Throughput 81% 81% 81% 81% 1238 Target Load = 110% 1239 ECN ECN+ ECN+/Wait ECN+/TryOnce 1240 ------- ------- ------- ---------- 1241 Dropped 2,496 2,110 1,733 2,020 1242 Marked 220,573 258,696 230,955 214,604 1243 Loss rate 0.15% 0.13% 0.11% 0.11% 1244 Throughput 92% 91% 92% 92% 1246 Target Load = 125% 1247 ECN ECN+ ECN+/Wait ECN+/TryOnce 1248 ------- ------- ------- ---------- 1249 Dropped 20,032 13,555 13,979 16,918 1250 Marked 725,165 726,992 726,823 615,235 1251 Loss rate 1.11% 0.76% 0.78% 0.66% 1252 Throughput 95% 95% 95% 96% 1254 Target Load = 150% 1255 ECN ECN+ ECN+/Wait ECN+/TryOnce 1256 ------- ------- ------- ---------- 1257 Dropped 484,251 483,847 507,727 600,737 1258 Marked 865,905 872,254 873,317 818,451 1259 Loss rate 19.09% 19.13% 19.71% 12.66% 1260 Throughput 99% 98% 99% 99% 1262 Table 5: Simulations with an average flow size of 3 Kbytes, a 1263 100 Mbps link, RED in byte mode, queue in bytes. 1265 Target Load = 95% 1266 ECN ECN+ ECN+/Wait ECN+/TryOnce 1267 ------- ------- ------- ---------- 1268 Dropped 142 77 103 99 1269 Marked 11,694 11,387 11,604 12,129 1270 Loss rate 0.1% 0.1% 0.1% 0.1% 1271 Throughput 78% 78% 78% 78% 1273 Target Load = 110% 1274 ECN ECN+ ECN+/Wait ECN+/TryOnce 1275 ------- ------- ------- ---------- 1276 Dropped 338 210 247 274 1277 Marked 41,676 40,412 44,173 36,265 1278 Loss rate 0.2% 0.1% 0.1% 0.1% 1279 Throughput 94% 94% 94% 96% 1281 Target Load = 125% 1282 ECN ECN+ ECN+/Wait ECN+/TryOnce 1283 ------- ------- ------- ---------- 1284 Dropped 1,559 951 978 1,723 1285 Marked 74,933 75,499 75,481 59,670 1286 Loss rate 0.8% 0.5% 0.5% 0.6% 1287 Throughput 99% 99% 99% 96% 1289 Target Load = 150% 1290 ECN ECN+ ECN+/Wait ECN+/TryOnce 1291 ------- ------- ------- ---------- 1292 Dropped 2,374 1,528 1,515 4,848 1293 Marked 85,739 86,428 86,144 81,350 1294 Loss rate 1.2% 0.8% 0.8% 1.4% 1295 Throughput 99% 98% 98% 98% 1297 Table 6: Simulations with an average flow size of 3 Kbytes, a 10 Mbps 1298 link, RED in byte mode, queue in bytes. 1300 B. Issues of Incremental Deployment 1302 In order for TCP node B to send a SYN/ACK packet as ECN-Capable, node 1303 B must have received an ECN-setup SYN packet from node A. However, 1304 it is possible that node A supports ECN, but either ignores the CE 1305 codepoint on received SYN/ACK packets, or ignores SYN/ACK packets 1306 with the ECT or CE codepoint set. If the TCP initiator ignores the 1307 CE codepoint on received SYN/ACK packets, this would mean that the 1308 TCP responder would not respond to this congestion indication. 1309 However, this seems to us an acceptable cost to pay in the 1310 incremental deployment of ECN-Capability for TCP's SYN/ACK packets. 1311 It would mean that the responder would not reduce the initial 1312 congestion window from two, three, or four segments down to one 1313 segment, as it should. and would not sent a non-ECN-Capable SYN/ACK 1314 packet to complete the SYN exchange. However, the TCP end nodes 1315 would still respond correctly to any subsequent CE indications on 1316 data packets later on in the connection. 1318 Figure 4 shows an interchange with the SYN/ACK packet ECN-marked, but 1319 with the ECN mark ignored by the TCP originator. 1321 --------------------------------------------------------------- 1322 TCP Node A Router TCP Node B 1323 (initiator) (responder) 1324 ---------- ------ ---------- 1326 ECN-setup SYN packet ---> 1327 ECN-setup SYN packet ---> 1329 <--- ECN-setup SYN/ACK, ECT 1330 <--- Sets CE on SYN/ACK 1331 <--- ECN-setup SYN/ACK, CE 1333 Data/ACK, No ECN-Echo ---> 1334 Data/ACK ---> 1335 <--- Data (up to four packets) 1336 --------------------------------------------------------------- 1338 Figure 4: SYN exchange with the SYN/ACK packet marked, 1339 but with the ECN mark ignored by the TCP initiator. 1341 Thus, to be explicit, when a TCP connection includes an initiator 1342 that supports ECN but *does not* support ECN-Capability for SYN/ACK 1343 packets, in combination with a responder that *does* support ECN- 1344 Capability for SYN/ACK packets, it is possible that the ECN-Capable 1345 SYN/ACK packets will be marked rather than dropped in the network, 1346 and that the responder will not learn about the ECN mark on the 1347 SYN/ACK packet. This would not be a problem if most packets from the 1348 responder supporting ECN for SYN/ACK packets were in long-lived TCP 1349 connections, but it would be more problematic if most of the packets 1350 were from TCP connections consisting of four data packets, and the 1351 TCP responder for these connections was ready to send its data 1352 packets immediately after the SYN/ACK exchange. Of course, with 1353 *severe* congestion, the SYN/ACK packets would likely be dropped 1354 rather than ECN-marked at the congested router, preventing the TCP 1355 responder from adding to the congestion by sending its initial window 1356 of four data packets. 1358 It is also possible that in some older TCP implementation, the 1359 initiator would ignore arriving SYN/ACK packets that had the ECT or 1360 CE codepoint set. This would result in a delay in connection set-up 1361 for that TCP connection, with the initiator re-sending the SYN packet 1362 after a retransmission timeout. We are not aware of any TCP 1363 implementations with this behavior. 1365 One possibility for coping with problems of backwards compatibility 1366 would be for TCP initiators to use a TCP flag that means "I 1367 understand ECN-Capable SYN/ACK packets". If this document were to 1368 standardize the use of such an "ECN-SYN" flag, then the TCP responder 1369 would only send a SYN/ACK packet as ECN-capable if the incoming SYN 1370 packet had the "ECN-SYN" flag set. An ECN-SYN flag would prevent the 1371 backwards compatibility problems described in the paragraphs above. 1373 One drawback to the use of an ECN-SYN flag is that it would use one 1374 of the four remaining reserved bits in the TCP header, for a 1375 transient backwards compatibility problem. This drawback is limited 1376 by the fact that the "ECN-SYN" flag would be defined only for use 1377 with ECN-setup SYN packets; that bit in the TCP header could be 1378 defined to have other uses for other kinds of TCP packets. 1380 Factors in deciding not to use an ECN-SYN flag include the following: 1382 (1) The limited installed base: At the time that this document was 1383 written, the TCP implementations in Microsoft Vista and Mac OS X 1384 included ECN, but ECN was not enabled by default [SBT07]. Thus, 1385 there was not a large deployed base of ECN-Capable TCP 1386 implementations. This limits the scope of any backwards 1387 compatibility problems. 1389 (2) Limits to the scope of the problem: The backwards compatibility 1390 problem would not be serious enough to cause congestion collapse; 1391 with severe congestion, the buffer at the congested router will 1392 overflow, and the congested router will drop rather than ECN-mark 1393 arriving SYN packets. Some active queue management mechanisms might 1394 switch from packet-marking to packet-dropping in times of high 1395 congestion before buffer overflow, as recommended in Section 19.1 of 1396 RFC 3168 [RFC3168]. This helps to prevent congestion collapse 1397 problems with the use of ECN. 1399 (3) Detection of and response to backwards-compatibility problems: A 1400 TCP responder such as a web server can't differentiate between a 1401 SYN/ACK packet that is not ECN-marked in the network, and a SYN/ACK 1402 packet that is ECN-marked, but where the ECN mark is ignored by the 1403 TCP initiator. However, a TCP responder *can* detect if a SYN/ACK 1404 packet is sent as ECN-capable and not reported as ECN-marked, but 1405 data packets are dropped or marked from the initial window of data. 1406 We will call this scenario "initial-window-congestion". If a web 1407 server frequently experienced initial-window congestion (without 1408 SYN/ACK congestion), then the web server *might* be experiencing 1409 backwards compatibility problems with ECN-Capable SYN/ACK packets, 1410 and could respond by not sending SYN/ACK packets as ECN-Capable. 1412 Normative References 1414 [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 1415 September 1981. 1417 [RFC2119] S. Bradner, Key Words For Use in RFCs to Indicate 1418 Requirement Levels, RFC 2119. 1420 [RFC2988] V. Paxson and M. Allman, Computing TCP's Retransmission 1421 Timer, RFC 2988, November 2000. 1423 [RFC3168] K.K. Ramakrishnan, S. Floyd, and D. Black, The Addition of 1424 Explicit Congestion Notification (ECN) to IP, RFC 3168, Proposed 1425 Standard, September 2001. 1427 Informative References 1429 [ECN+] A. Kuzmanovic, The Power of Explicit Congestion Notification, 1430 SIGCOMM 2005. 1432 [ECN-SYN] ECN-SYN web page with simulation scripts, URL 1433 "http://www.icir.org/floyd/ecn-syn". 1435 [F07] S. Floyd, "[BEHAVE] Response of firewalls and middleboxes to 1436 TCP SYN packets that are ECN-Capable?", August 2, 2007, email sent to 1437 the BEHAVE mailing list, URL "http://www1.ietf.org/mail- 1438 archive/web/behave/current/msg02644.html". 1440 [Kelson00] Dax Kelson, note sent to the Linux kernel mailing list, 1441 September 10, 2000. 1443 [L08] A. Landley, "Re: [tcpm] I-D Action:draft-ietf-tcpm- 1444 ecnsyn-06.txt", Email to the tcpm mailing list, August 24, 2008. 1446 [MAF05] A. Medina, M. Allman, and S. Floyd. Measuring the Evolution 1447 of Transport Protocols in the Internet, ACM CCR, April 2005. 1449 [PI] C. Hollot, V. Misra, W. Gong, and D. Towsley, On Designing 1450 Improved Controllers for AQM Routers Supporting TCP Flows, April 1451 1998. 1453 [RED] Floyd, S., and Jacobson, V. Random Early Detection gateways 1454 for Congestion Avoidance . IEEE/ACM Transactions on Networking, V.1 1455 N.4, August 1993. 1457 [REM] S. Athuraliya, V. H. Li, S. H. Low and Q. Yin, REM: Active 1458 Queue Management, IEEE Network, May 2001. 1460 [RFC2309] B. Braden et al., Recommendations on Queue Management and 1461 Congestion Avoidance in the Internet, RFC 2309, April 1998. 1463 [RFC2581] M. Allman, V. Paxson, and W. Stevens, TCP Congestion 1464 Control, RFC 2581, April 1999. 1466 [RFC3042] M. Allman, H. Balakrishnan, and S. Floyd, Enhancing TCP's 1467 Loss Recovery Using Limited Transmit, RFC 3042, Proposed Standard, 1468 January 2001. 1470 [RFC3360] S. Floyd, Inappropriate TCP Resets Considered Harmful, RFC 1471 3360, August 2002. 1473 [RFC3390] M. Allman, S. Floyd, and C. Partridge, Increasing TCP's 1474 Initial Window, RFC 3390, October 2002. 1476 [RFC4987] W. Eddy, TCP SYN Flooding Attacks and Common Mitigations, 1477 RFC 4987, August 2007. 1479 [SCJO01] F. Smith, F. Campos, K. Jeffay, and D. Ott, What TCP/IP 1480 Protocol Headers Can Tell us about the Web, SIGMETRICS, June 2001. 1482 [SYN-COOK] Dan J. Bernstein, SYN cookies, 1997, see also 1483 1485 [SBT07] M. Sridharan, D. Bansal, and D. Thaler, Implementation Report 1486 on Experiences with Various TCP RFCs, Presentation in the TSVAREA, 1487 IETF 68, March 2007. URL 1488 "http://www3.ietf.org/proceedings/07mar/slides/tsvarea-3/sld6.htm". 1490 [Tools] S. Floyd and E. Kohler, Tools for the Evaluation of 1491 Simulation and Testbed Scenarios, Internet-draft draft-irtf-tmrg- 1492 tools-05, work in progress, February 2008. 1494 IANA Considerations 1496 There are no IANA considerations regarding this document. 1498 Authors' Addresses 1499 Aleksandar Kuzmanovic 1500 Phone: +1 (847) 467-5519 1501 Northwestern University 1502 Email: akuzma at northwestern.edu 1503 URL: http://cs.northwestern.edu/~a 1505 Amit Mondal 1506 Northwestern University 1507 Email: a-mondal at northwestern.edu 1509 Sally Floyd 1510 Phone: +1 (510) 666-2989 1511 ICIR (ICSI Center for Internet Research) 1512 Email: floyd@icir.org 1513 URL: http://www.icir.org/floyd/ 1515 K. K. Ramakrishnan 1516 Phone: +1 (973) 360-8764 1517 AT&T Labs Research 1518 Email: kkrama at research.att.com 1519 URL: http://www.research.att.com/info/kkrama