idnits 2.17.1 draft-floyd-ecn-alternates-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.5 on line 524. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 535. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 542. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 548. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([ECN]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 310: '...ithms followed at the end-systems MUST...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 244 has weird spacing: '...nfairly with ...' -- 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 (21 April 2005) is 6938 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) == Missing Reference: 'RFC 3540' is mentioned on line 390, but not defined == Unused Reference: 'RFC3168' is defined on line 488, but no explicit reference was found in the text == Unused Reference: 'RFC3540' is defined on line 492, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-babiarz-tsvwg-rtecn-03 -- Obsolete informational reference (is this intentional?): RFC 2581 (Obsoleted by RFC 5681) -- Obsolete informational reference (is this intentional?): RFC 2960 (Obsoleted by RFC 4960) Summary: 8 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force S. Floyd 2 INTERNET-DRAFT ICIR 3 draft-floyd-ecn-alternates-00.txt 21 April 2005 4 Expires: October 2005 6 Specifying Alternate Semantics for the Explicit Congestion 7 Notification (ECN) Field 9 Status of this Memo 11 By submitting this Internet-Draft, we certify that any applicable 12 patent or other IPR claims of which we are aware have been 13 disclosed, or will be disclosed, and any of which we become aware 14 will be disclosed, in accordance with RFC 3668 (BCP 79). 16 By submitting this Internet-Draft, we accept the provisions of 17 Section 3 of RFC 3667 (BCP 78). 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other documents 26 at any time. It is inappropriate to use Internet- Drafts as 27 reference material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 There have been a number of proposals for alternate semantics for 38 the ECN field in the IP header [ECN]. This document discusses some 39 of the issues in defining alternate semantics for the ECN field, and 40 specifies requirements for a safe co-existence in an Internet that 41 could include routers that do not understand the defined alternate 42 semantics. This document evolved as a result of discussions with 43 the authors of one recent proposal for such alternate semantics. 45 Table of Contents 47 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2 48 2. An Overview of the Issues . . . . . . . . . . . . . . . . . . 3 49 3. Signalling the Use of Alternate ECN Semantics . . . . . . . . 4 50 3.1. Using the Diffserv Field for Signalling. . . . . . . . . 4 51 4. Issues of Incremental Deployment. . . . . . . . . . . . . . . 5 52 4.1. Option 1: Unsafe for Deployment in the 53 Internet. . . . . . . . . . . . . . . . . . . . . . . . . . . 6 54 4.2. Option 2: Verification that Routers Under- 55 stand the Alternate Semantics . . . . . . . . . . . . . . . . 7 56 4.3. Option 3: Friendly Co-existence with Com- 57 peting Traffic. . . . . . . . . . . . . . . . . . . . . . . . 7 58 5. Evaluation of the Alternate-ECN Semantics . . . . . . . . . . 9 59 5.1. Verification of Feedback from the Router . . . . . . . . 9 60 5.2. Co-existence with Competing Traffic. . . . . . . . . . . 9 61 5.3. A General Evaluation of the Alternate-ECN 62 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . 10 63 6. Who Wants to Use Alternate Semantics for the ECN 64 Codepoint? . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 66 8. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 10 67 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 10. Normative References . . . . . . . . . . . . . . . . . . . . 11 69 11. Informative References . . . . . . . . . . . . . . . . . . . 11 70 IANA Considerations. . . . . . . . . . . . . . . . . . . . . . . 12 71 AUTHORS' ADDRESSES . . . . . . . . . . . . . . . . . . . . . . . 12 72 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 12 73 Intellectual Property. . . . . . . . . . . . . . . . . . . . . . 12 74 , 76 1. Introduction 78 RFC 3168, a Proposed Standard document, defines the ECN field in the 79 IP header, and specifies the semantics for the codepoints for the 80 ECN field. However, end nodes could specify the use of alternate 81 semantics for the ECN field, e.g., using codepoints in the diffserv 82 field of the IP header. This document describes some of the issues 83 that arise in specifying such alternate semantics for the ECN field, 84 and gives requirements for a safe co-existence in a world using the 85 default ECN semantics (or using no ECN at all). 87 2. An Overview of the Issues 89 In this section we discuss some of the issues that arise if some of 90 the traffic in a network consists of alternate-ECN traffic (i.e., 91 traffic using alternate semantics for the ECN field). 93 The first issue concerns how routers know which ECN semantics to use 94 with which packets in the network: 96 (1) How does the connection indicate to the router that its packets 97 are using alternate-ECN semantics? Is the specification of 98 alternate-ECN semantics robust and unambiguous? If not, is this a 99 problem? 101 As an example, in most of the proposals for alternate-ECN semantics, 102 a diffserv field is used to specify the use of alternate-ECN 103 semantics. Do all routers that understand this diffserv codepoint 104 understand that it uses alternate-ECN semantics, or not? Can the 105 diffserv field be re-written in the middle of the network? If so, 106 is this a problem? 108 This is discussed in more detail in Section 3 below. 110 A second issue is that of incremental deployment in a network where 111 some routers only use the default ECN semantics, and other routers 112 might not use ECN at all. In this document we use the phrase "new 113 routers" to refer to the routers that understand the alternate-ECN 114 semantics, and "old routers" to refer to routers that don't 115 understand or aren't willing to use the alternate-ECN semantics. 116 The possible existence of old routers raises several questions: 118 (2) How does the possible presence of old routers affect the 119 performance of the alternate-ECN connections? 121 (3) How does the possible presence of old routers affect the co- 122 existence of the alternate-ECN traffic with competing traffic on the 123 path? 125 These issues are discussed in Section 4 below. 127 A final issue is that of the general evaluation of the alternate-ECN 128 semantics: 130 (4) How well does the alternate-ECN traffic perform, and how well 131 does it co-exist with competing traffic on the path, in a "clean" 132 environment with new routers and with the unambiguous specification 133 of the use of alternate-ECN semantics? 134 These issues are discussed in Section 5 below. 136 3. Signalling the Use of Alternate ECN Semantics 138 This section discusses question (1) from Section 2: 140 (1) How does the connection indicate to the router that its packets 141 are using alternate-ECN semantics? Is the specification of 142 alternate-ECN semantics robust and unambiguous? If not, is this a 143 problem? 145 The assumption of this document is that when alternate semantics are 146 defined for the ECN field, a codepoint in the diffserv field is used 147 to signal the use of these alternate ECN semantics to the router. 148 That is, the end host sets the codepoint in the diffserv field to 149 indicate to routers that alternate semantics to the ECN field are 150 being used. Routers that understand this diffserv codepoint would 151 know to use the alternate semantics for interpreting and setting the 152 ECN field. Old ECN-capable routers that do not understand this 153 diffserv codepoint would use the default ECN semantics in 154 interpreting and setting the ECN field. 156 We note that this does not exclude the possibility of using other 157 methods, including out-of-band mechanisms, for signalling the use of 158 alternate semantics for the ECN field. The considerations in the 159 rest of this document apply regardless of the method used to signal 160 the use of alternate semantics for the ECN field. 162 3.1. Using the Diffserv Field for Signalling 164 We note that the default ECN semantics defined in RFC 3168 are the 165 current default semantics for the ECN field, regardless of the 166 contents of any other fields in the IP header. In particular, the 167 default ECN semantics don't just apply for best-effort traffic with 168 a codepoint of `000000' for the diffserv field - the default ECN 169 semantics currently apply regardless of the contents of the diffserv 170 field. 172 There are two ways to use the diffserv field to signal the use of 173 alternate ECN semantics. One way is to use an existing diffserv 174 codepoint, and to modify the current definition of that codepoint, 175 through approved IETF processes, to specify the use of alternate ECN 176 semantics with that codepoint. A second way is to define a new 177 diffserv codepoint, and to specify the use of alternate ECN 178 semantics with that codepoint. We note that the first of these two 179 mechanisms raises the possibility that some routers along the path 180 will understand the diffserv codepoint but will use the default ECN 181 semantics with this diffserv codepoint, or won't use ECN at all, and 182 that other routers will use the alternate ECN semantics with this 183 diffserv codepoint. 185 4. Issues of Incremental Deployment 187 This section discusses questions (2) and (3) posed in Section 2: 189 (2) How does the possible presence of old routers affect the 190 performance of the alternate-ECN connections? 192 (3) How does the possible presence of old routers affect the co- 193 existence of the alternate-ECN traffic with competing traffic on the 194 path? 196 When alternate semantics are defined for the ECN field, it is 197 necessary to ensure that there are no problems caused by old routers 198 along the path that don't understand the alternate ECN semantics. 200 One possible problem is that of poor performance for the alternate- 201 ECN traffic. Is it essential to the performance of the alternate- 202 ECN traffic that all routers along the path understand the 203 alternate-ECN semantics? If not, what are the possible 204 consequences, for the alternate-ECN traffic itself, when some old 205 routers along the path don't understand the alternate-ECN semantics? 206 These issues have to be answered in the context of each specific 207 proposal for alternate ECN semantics. 209 A second specific problem is that of possible unfair competition 210 with other traffic along the path. If there is an old router along 211 the path that doesn't use ECN, that old router could drop packets 212 from the alternate-ECN traffic, and expect the alternate-ECN traffic 213 to reduce its sending rate as a result. Does the alternate-ECN 214 traffic respond to packet drops as an indication of congestion? 216 |--------| 217 Alternate-ECN traffic ----> | | ---> CE-marked packet 218 | Old | 219 Non-ECN traffic ----------> | Router | ---> dropped packet 220 | | 221 RFC-3168 ECN traffic -----> | | ---> CE-marked packet 222 |--------| 224 Figure 1: Alternate-ECN traffic with an old router using RFC-3168 ECN. 226 Similarly, what if there is an old router along the path that 227 understands only the default ECN semantics from RFC-3168, as in 228 Figure 1 above? In times of congestion, the old default-ECN router 229 could see an alternate-ECN packet with one of the ECN-Capable 230 Transport (ECT) codepoints set in the ECN field in the IP header, as 231 defined in RFC 3168, and set the Congestion Experienced (CE) 232 codepoint in the ECN field as an alternative to dropping the packet. 233 The router in this case would expect the alternate-ECN connection to 234 respond, in terms of congestion control, as it would if the packet 235 has been dropped. If the alternate-ECN traffic fails to respond 236 appropriately to the CE codepoint being set by an old router, this 237 could increase the aggregate traffic arriving at the old router, 238 resulting in an increase in the packet-marking and packet-dropping 239 rates at that router, further resulting in the alternate-ECN traffic 240 crowding out the other traffic competing for bandwidth on that link. 242 Basically, there are three possibilities for avoiding scenarios 243 where the presence of old routers along the path results in the 244 alternate-ECN traffic competing unfairly with other traffic along 245 the path: 247 Option 1: Alternate-ECN traffic is clearly understood as unsafe for 248 deployment in the global Internet; or 250 Option 2: All alternate-ECN traffic deploys some mechanism for 251 verifying that all routers on the path understand and agree to use 252 the alternate ECN semantics for this traffic; or 254 Option 3: The alternate-ECN semantics are defined in such a way as 255 to ensure the fair and peaceful co-existence of the alternate-ECN 256 traffic with best-effort and other traffic, even in environments 257 that include old routers that do not understand the alternate-ECN 258 semantics. 260 Each of these alternatives is explored in more detail below. 262 4.1. Option 1: Unsafe for Deployment in the Internet 264 The first option specified above is for the alternate-ECN traffic to 265 be clearly understood as only suitable for enclosed environments, 266 and as unsafe for deployment in the global Internet. This would 267 mean that it would be unsafe for packets using the alternate ECN 268 semantics to be unleashed in the global Internet, in order to avoid 269 the chance of the alternate-ECN traffic traversing an old router 270 that don't understand the alternate semantics. This document 271 doesn't comment on whether a mechanism would be required to ensure 272 that the alternate-ECN semantics would not be let loose on the 273 global Internet. This document also doesn't comment on the chances 274 that this scenario would be considered acceptable for 275 standardization by the IETF community. 277 4.2. Option 2: Verification that Routers Understand the Alternate 278 Semantics 280 The second option specified above is for the alternate-ECN traffic 281 to include a mechanism for ensuring that all routers along the path 282 understand and agree to the use of the alternate ECN semantics for 283 this traffic. As an example, such a mechanism could consist of a 284 field in an IP option that all routers along the path decrement if 285 they agree to use the alternate ECN semantics with this traffic. (A 286 similar mechanism is proposed for Quick-Start, for verifying that 287 all of the routers along the path understand the Quick-Start IP 288 Option [QuickStart].) Using such a mechanism, a sender could have 289 reasonable assurance that the packets that are sent specifying the 290 use of alternate ECN semantics only traverse routers that in fact 291 understand and agree to use these alternate semantics for these 292 packets. 294 4.3. Option 3: Friendly Co-existence with Competing Traffic 296 The third option specified above is for the alternate ECN semantics 297 to be defined so that traffic using the alternate semantics would 298 co-exist safely in the Internet on a path with one or more old 299 routers that use only the default ECN semantics. In this scenario, 300 a connection sending alternate-ECN traffic would have to respond 301 appropriately to a CE packet (a packet with the ECN codepoint "11") 302 received at the receiver, using a conformant congestion control 303 response. Hopefully, the connection sending alternate-ECN traffic 304 would also respond appropriately to a dropped packet, that could be 305 a congestion indication from a router that doesn't use ECN at all. 307 RFC 3168 defines the default ECN semantics as follows: 309 "Upon the receipt by an ECN-Capable transport of a single CE packet, 310 the congestion control algorithms followed at the end-systems MUST 311 be essentially the same as the congestion control response to a 312 *single* dropped packet. For example, for ECN-Capable TCP the 313 source TCP is required to halve its congestion window for any window 314 of data containing either a packet drop or an ECN indication." 316 The only conformant congestion control mechanisms currently 317 standardized in the IETF are TCP [RFC2581] and protocols using TCP- 318 like congestion control (e.g., SCTP [RFC2960], DCCP with CCID-2 320 [DCCP]), and TCP-Friendly Rate Control (TFRC) and protocols with 321 TFRC-like congestion control (e.g., DCCP using CCID-3 [DCCP]). TCP 322 uses Additive-Increase Multiplicative-Decrease congestion control, 323 and responds to the loss or ECN-marking of a single packet by 324 halving its congestion window. In contrast, the equation-based 325 congestion control mechanism in TFRC estimates the loss event rate 326 over some period of time, and uses a sending rate that would be 327 comparable, in packets per round-trip-time, to that of a TCP 328 connection experiencing the same loss event rate. 330 So what are the requirements in order for alternate-ECN traffic to 331 compete appropriately with other traffic on a path through an old 332 router that doesn't understand the alternate ECN semantics (and 333 therefore might be using the default ECN semantics)? 335 The first requirement is that if a packet is marked with the ECN 336 codepoint "11" in the network, this marking is not changed on the 337 packet's way to the receiver (unless the packet is dropped before it 338 reaches the receiver). This requirement is necessary to ensure that 339 congestion indications from a default-ECN router make it to the 340 transport receiver. 342 The second requirement is that the end-nodes respond in a TCP- 343 friendly manner to packets received that are marked with the ECN 344 codepoint "11" (because these packets might have come from a 345 congested router that understands only the default ECN semantics). 346 This would ensure that the traffic using the alternate semantics 347 does not `bully' competing traffic that it might encounter along the 348 path, and does not drive up congestion on the shared link 349 inappropriately. 351 As discussed earlier, the current conformant congestion control 352 responses to a dropped or default-ECN-marked packet consist of TCP 353 and TCP-like congestion control, and of TFRC (TCP-Friendly Rate 354 Control). Another possible response considered in RFC 3714, but not 355 standardized in a standards-track document, is that of simply 356 terminating an alternate-ECN connection for a period of time if the 357 long-term sending rate is higher that would be that of a TCP 358 connection experiencing the same packet dropping or marking rates 359 [RFC3714]. We note that the use of such a congestion control 360 response to CE-marked packets would require specification of time 361 constants for measuring the loss rates and for stopping 362 transmission, and would require a consideration of issues of packet 363 size. 365 5. Evaluation of the Alternate-ECN Semantics 367 This section discusses question (4) posed in Section 2: 369 (4) How well does the alternate-ECN traffic perform, and how well 370 does it co-exist with competing traffic on the path, in a "clean" 371 environment with new routers and with the unambiguous specification 372 of the use of alternate-ECN semantics? 374 5.1. Verification of Feedback from the Router 376 One issue in evaluating the alternate-ECN semantics concerns 377 mechanisms to discourage lying from the transport receiver to the 378 transport sender. In many cases the sender is a server that has an 379 interest in using the alternate-ECN semantics correctly, while the 380 receiver has more incentives for lying about the congestion 381 experienced along the path. 383 In the default ECN semantics, two of the four ECN codepoints are 384 used for ECN-Capable(0) and ECN-Capable(1). The use of two 385 codepoints for ECN-Capable, instead of one, permits the data sender 386 to verify receiver's reports that packets were actually received 387 unmarked at the receiver. In particular, the sender can specify 388 that the receiver report to the sender whether each unmarked packet 389 was received ECN-Capable(0) or ECN-Capable(1), as discussed in RFC 390 3540 [RFC 3540]. 392 If alternate semantics for the ECN codepoint don't include the use 393 of two separate codepoints to indicate ECN-Capable, then the 394 connections using those semantics have lost the ability to verify 395 that the data receiver is accurately reporting the received ECN 396 codepoint to the data sender. In this case, it might be necessary 397 for the alternate-ECN framework to include alternate mechanisms for 398 ensuring that the data receiver is reporting feedback appropriately 399 to the sender. 401 5.2. Co-existence with Competing Traffic 403 A second general issue concerns the co-existence of alternate-ECN 404 traffic with competing traffic along the path, in a clean 405 environment where all routers understand and are willing to use the 406 alternate-ECN semantics for the traffic that specifies its use. 408 If the traffic using the alternate-ECN semantics is best-effort 409 traffic, then it is subject to the general requirement of fair 410 competition with TCP and other traffic along the path [RFC2914]. 412 If the traffic using the alternate-ECN semantics is diffserv 413 traffic, then the requirements are governed by the overall 414 guidelines for that class of diffserv traffic. It is beyond the 415 scope of this document to specify the requirements, if any, for the 416 co-existence of diffserv traffic with other traffic on the link; 417 this should be addressed in the specification of the diffserv 418 codepoint itself. 420 5.3. A General Evaluation of the Alternate-ECN Semantics 422 A third general issue concerns the evaluation of the general merits 423 of the proposed alternate-ECN semantics. Again, it would be beyond 424 the scope of this document to specify requirements for the general 425 evaluation of alternate-ECN semantics. 427 6. Who Wants to Use Alternate Semantics for the ECN Codepoint? 429 There have been a number of proposals in the IETF and in the 430 research community for alternate semantics for the ECN codepoint 431 [ECN]. One such proposal, [BCF05], proposes an alternate-ECN 432 semantics for real-time inelastic traffic such as voice, video 433 conferencing, and multimedia streaming in DiffServ networks. In 434 this proposal, the alternate-ECN semantics would provide information 435 about two levels of congestion experienced along the path, where "it 436 is left up to the application designers to define how end-systems 437 should react to ECN bit marking" [BCF05]. Some of the other 438 proposals for alternate ECN semantics are listed on the ECN Web Page 439 [ECN]. 441 7. Security Considerations 443 This document doesn't propose any new mechanisms for the Internet 444 protocol, and therefore doesn't introduce any new security 445 considerations. 447 8. Acknowledgements 449 This document is based in part on conversations with Jozef Babiarz, 450 Kwok Ho Chan, and Victor Firoiu on their proposal for an alternate 451 use of the ECN field in DiffServ environments. Many thanks to 452 Francois Le Faucheur for feedback recommending that the document 453 include a section at the beginning discussing the potential issues 454 that need to be addressed. Thanks also to Fred Baker, David Black, 455 and to members of the TSVWG working group for feedback on these 456 issues. 458 9. Conclusions 460 This document has discussed some of the issues to be considered in 461 the specification of alternate semantics for the ECN field in the IP 462 header. 464 10. Normative References 466 11. Informative References 468 [BCF05] J. Babiarz, K. Chan, and V. Firoiu, Congestion Notification 469 Process for Real-Time Traffic, internet-draft draft-babiarz-tsvwg- 470 rtecn-03, work in progress, February 2005. 472 [DCCP] DCCP Web Page, URL "http://www.icir.org/kohler/dccp/". 474 [ECN] ECN Web Page, URL "www.icir.org/floyd/ecn.html". 476 [QuickStart] Quick-Start Web Page, URL 477 "http://www.icir.org/floyd/quickstart.html". 479 [RFC2581] M. Allman, V. Paxson, and W. Stevens, TCP Congestion 480 Control, RFC 2581, Proposed Standard, April 1999. 482 [RFC2914] S. Floyd, Congestion Control Principles, RFC 2914, Best 483 Current Practice, September 2000. 485 [RFC2960] R. Stewart et al, Stream Control Transmission Protocol, 486 RFC 2960, October 2000. 488 [RFC3168] Ramakrishnan, K.K., Floyd, S., and Black, D., The Addition 489 of Explicit Congestion Notification (ECN) to IP, RFC 3168, Proposed 490 Standard, September 2001. 492 [RFC3540] N. Spring, D. Wetherall, and D. Ely, Robust Explicit 493 Congestion Notification (ECN) Signaling with Nonces, RFC 3540, 494 Experimental, June 2003. 496 [RFC3714] S. Floyd and J. Kempf, Editors, IAB Concerns Regarding 497 Congestion Control for Voice Traffic in the Internet, RFC 3714, 498 Informational, March 2004. 500 IANA Considerations 502 There are no IANA considerations in this document. 504 AUTHORS' ADDRESSES 506 Sally Floyd 507 Phone: +1 (510) 666-2989 508 ICIR (ICSI Center for Internet Research) 509 Email: floyd@icir.org 510 URL: http://www.icir.org/floyd/ 512 Full Copyright Statement 514 Copyright (C) The Internet Society 2004. This document is subject 515 to the rights, licenses and restrictions contained in BCP 78, and 516 except as set forth therein, the authors retain all their rights. 518 This document and the information contained herein are provided on 519 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 520 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 521 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 522 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 523 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 524 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 526 Intellectual Property 528 The IETF takes no position regarding the validity or scope of any 529 Intellectual Property Rights or other rights that might be claimed 530 to pertain to the implementation or use of the technology described 531 in this document or the extent to which any license under such 532 rights might or might not be available; nor does it represent that 533 it has made any independent effort to identify any such rights. 534 Information on the procedures with respect to rights in RFC 535 documents can be found in BCP 78 and BCP 79. 537 Copies of IPR disclosures made to the IETF Secretariat and any 538 assurances of licenses to be made available, or the result of an 539 attempt made to obtain a general license or permission for the use 540 of such proprietary rights by implementers or users of this 541 specification can be obtained from the IETF on-line IPR repository 542 at http://www.ietf.org/ipr. 544 The IETF invites any interested party to bring to its attention any 545 copyrights, patents or patent applications, or other proprietary 546 rights that may cover technology that may be required to implement 547 this standard. Please address the information to the IETF at ietf- 548 ipr@ietf.org.