idnits 2.17.1 draft-floyd-ecn-alternates-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 593. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 604. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 611. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 617. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 585), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 38. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 353: '...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 283 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 (11 July 2005) is 6863 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: 'DSCP' is mentioned on line 130, but not defined == Missing Reference: 'RFC 3540' is mentioned on line 459, but not defined == Unused Reference: 'RFC3168' is defined on line 557, but no explicit reference was found in the text == Unused Reference: 'RFC3540' is defined on line 561, 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: 9 errors (**), 0 flaws (~~), 8 warnings (==), 9 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-01.txt 11 July 2005 4 Expires: January 2006 6 Specifying Alternate Semantics for the Explicit Congestion 7 Notification (ECN) Field 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of section 3 of RFC 3667. By submitting this Internet-Draft, each 13 author represents that any applicable patent or other IPR claims of 14 which he or she is aware have been or will be disclosed, and any of 15 which he or she becomes aware will be disclosed, in accordance with 16 Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). All Rights Reserved. 40 Abstract 42 There have been a number of proposals for alternate semantics for 43 the ECN field in the IP header [ECN]. This document discusses some 44 of the issues in defining alternate semantics for the ECN field, and 45 specifies requirements for a safe co-existence in an Internet that 46 could include routers that do not understand the defined alternate 47 semantics. This document evolved as a result of discussions with 48 the authors of one recent proposal for such alternate semantics. 50 NOTE TO RFC EDITOR: PLEASE DELETE THIS NOTE UPON PUBLICATION. 52 Changes from draft-floyd-ecn-alternates-00.txt: 54 * Added requirements for compatibility between traffic using default 55 ECN semantics and routers using alternate ECN semantics, to the 56 section on "Option 3: Friendly Co-existence with Competing 57 Traffic". From email from Gorry Fairhurst. 59 * Added to the discussion of using the diffserv code point to signal 60 alternate ECN semantics. From email from Gorry Fairhurst. 62 * Minor editing for clarity, also from email from Gorry Fairhurst. 64 END OF NOTE TO RFC EDITOR. 66 Table of Contents 68 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. An Overview of the Issues . . . . . . . . . . . . . . . . . . 3 70 3. Signalling the Use of Alternate ECN Semantics . . . . . . . . 4 71 3.1. Using the Diffserv Field for Signalling. . . . . . . . . 5 72 4. Issues of Incremental Deployment. . . . . . . . . . . . . . . 5 73 4.1. Option 1: Unsafe for Deployment in the 74 Internet. . . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 4.2. Option 2: Verification that Routers Under- 76 stand the Alternate Semantics . . . . . . . . . . . . . . . . 7 77 4.3. Option 3: Friendly Co-existence with Com- 78 peting Traffic. . . . . . . . . . . . . . . . . . . . . . . . 8 79 5. Evaluation of the Alternate-ECN Semantics . . . . . . . . . . 10 80 5.1. Verification of Feedback from the Router . . . . . . . . 10 81 5.2. Co-existence with Competing Traffic. . . . . . . . . . . 11 82 5.3. A General Evaluation of the Alternate-ECN 83 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 6. Who Wants to Use Alternate Semantics for the ECN 85 Codepoint? . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 87 8. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 12 88 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 12 89 10. Normative References . . . . . . . . . . . . . . . . . . . . 12 90 11. Informative References . . . . . . . . . . . . . . . . . . . 12 91 IANA Considerations. . . . . . . . . . . . . . . . . . . . . . . 13 92 AUTHORS' ADDRESSES . . . . . . . . . . . . . . . . . . . . . . . 13 93 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 13 94 Intellectual Property. . . . . . . . . . . . . . . . . . . . . . 14 96 1. Introduction 98 RFC 3168, a Proposed Standard document, defines the ECN field in the 99 IP header, and specifies the semantics for the codepoints for the 100 ECN field. However, end nodes could specify the use of alternate 101 semantics for the ECN field, e.g., using codepoints in the diffserv 102 field of the IP header. This document describes some of the issues 103 that arise in specifying such alternate semantics for the ECN field, 104 and gives requirements for a safe co-existence in a world using the 105 default ECN semantics (or using no ECN at all). 107 2. An Overview of the Issues 109 In this section we discuss some of the issues that arise if some of 110 the traffic in a network consists of alternate-ECN traffic (i.e., 111 traffic using alternate semantics for the ECN field). The issues 112 include the following: (1) how routers know which ECN semantics to 113 use with which packets; (2) incremental deployment in a network 114 where some routers use only the default ECN semantics, or no ECN at 115 all; (3) co-existence of alternate-ECN traffic with competing 116 traffic on the path; and (4) a general evaluation of the alternate- 117 ECN semantics. 119 (1) The first issue concerns how routers know which ECN semantics to 120 use with which packets in the network: 122 How does the connection indicate to the router that its packets are 123 using alternate-ECN semantics? Is the specification of alternate- 124 ECN semantics robust and unambiguous? If not, is this a problem? 126 As an example, in most of the proposals for alternate-ECN semantics, 127 a diffserv field is used to specify the use of alternate-ECN 128 semantics. Do all routers that understand this diffserv codepoint 129 understand that it uses alternate-ECN semantics, or not? Diffserv 130 allows routers to re-mark DiffServ Code Point [DSCP] values within 131 the network; what is the effect of this on the alternate-ECN 132 semantics? 134 This is discussed in more detail in Section 3 below. 136 (2) A second issue is that of incremental deployment in a network 137 where some routers only use the default ECN semantics, and other 138 routers might not use ECN at all. In this document we use the 139 phrase "new routers" to refer to the routers that understand the 140 alternate-ECN semantics, and "old routers" to refer to routers that 141 don't understand or aren't willing to use the alternate-ECN 142 semantics. 144 The possible existence of old routers raises the following question: 145 How does the possible presence of old routers affect the performance 146 of the alternate-ECN connections? 148 (3) The possible existence of old routers also raises the question 149 of how the presence of old routers affects the co-existence of the 150 alternate-ECN traffic with competing traffic on the path. 152 Issues (2) and (3) are discussed in Section 4 below. 154 (4) A final issue is that of the general evaluation of the 155 alternate-ECN semantics: 157 How well does the alternate-ECN traffic perform, and how well does 158 it co-exist with competing traffic on the path, in a "clean" 159 environment with new routers and with the unambiguous specification 160 of the use of alternate-ECN semantics? 162 These issues are discussed in Section 5 below. 164 3. Signalling the Use of Alternate ECN Semantics 166 This section discusses question (1) from Section 2: 168 (1) How does the connection indicate to the router that its packets 169 are using alternate-ECN semantics? Is the specification of 170 alternate-ECN semantics robust and unambiguous? If not, is this a 171 problem? 173 The assumption of this document is that when alternate semantics are 174 defined for the ECN field, a codepoint in the diffserv field is used 175 to signal the use of these alternate ECN semantics to the router. 176 That is, the end host sets the codepoint in the diffserv field to 177 indicate to routers that alternate semantics to the ECN field are 178 being used. Routers that understand this diffserv codepoint would 179 know to use the alternate semantics for interpreting and setting the 180 ECN field. Old ECN-capable routers that do not understand this 181 diffserv codepoint would use the default ECN semantics in 182 interpreting and setting the ECN field. 184 In general, the diffserv codepoints are used to signal the per-hop 185 behavior at router queues. One possibility would be to use one 186 diffserv codepoint to signal a per-hop behavior with the default ECN 187 semantics, and a separate diffserv codepoint to signal a similar 188 per-hop behavior with the alternate ECN semantics. Another 189 possibility would be to use a diffserv codepoint to signal the use 190 of best-effort per-hop queueing and scheduling behavior, but with 191 alternate ECN semantics. A detailed discussion of these issues is 192 beyond the scope of this document. 194 We note that this discussion does not exclude the possibility of 195 using other methods, including out-of-band mechanisms, for 196 signalling the use of alternate semantics for the ECN field. The 197 considerations in the rest of this document apply regardless of the 198 method used to signal the use of alternate semantics for the ECN 199 field. 201 3.1. Using the Diffserv Field for Signalling 203 We note that the default ECN semantics defined in RFC 3168 are the 204 current default semantics for the ECN field, regardless of the 205 contents of any other fields in the IP header. In particular, the 206 default ECN semantics apply for more than best-effort traffic with a 207 codepoint of '000000' for the diffserv field - the default ECN 208 semantics currently apply regardless of the contents of the diffserv 209 field. 211 There are two ways to use the diffserv field to signal the use of 212 alternate ECN semantics. One way is to use an existing diffserv 213 codepoint, and to modify the current definition of that codepoint, 214 through approved IETF processes, to specify the use of alternate ECN 215 semantics with that codepoint. A second way is to define a new 216 diffserv codepoint, and to specify the use of alternate ECN 217 semantics with that codepoint. We note that the first of these two 218 mechanisms raises the possibility that some routers along the path 219 will understand the diffserv codepoint but will use the default ECN 220 semantics with this diffserv codepoint, or won't use ECN at all, and 221 that other routers will use the alternate ECN semantics with this 222 diffserv codepoint. 224 4. Issues of Incremental Deployment 226 This section discusses questions (2) and (3) posed in Section 2: 228 (2) How does the possible presence of old routers affect the 229 performance of the alternate-ECN connections? 231 (3) How does the possible presence of old routers affect the co- 232 existence of the alternate-ECN traffic with competing traffic on the 233 path? 235 When alternate semantics are defined for the ECN field, it is 236 necessary to ensure that there are no problems caused by old routers 237 along the path that don't understand the alternate ECN semantics. 239 One possible problem is that of poor performance for the alternate- 240 ECN traffic. Is it essential to the performance of the alternate- 241 ECN traffic that all routers along the path understand the 242 alternate-ECN semantics? If not, what are the possible 243 consequences, for the alternate-ECN traffic itself, when some old 244 routers along the path don't understand the alternate-ECN semantics? 245 These issues have to be answered in the context of each specific 246 proposal for alternate ECN semantics. 248 A second specific problem is that of possible unfair competition 249 with other traffic along the path. If there is an old router along 250 the path that doesn't use ECN, that old router could drop packets 251 from the alternate-ECN traffic, and expect the alternate-ECN traffic 252 to reduce its sending rate as a result. Does the alternate-ECN 253 traffic respond to packet drops as an indication of congestion? 255 |--------| 256 Alternate-ECN traffic ----> | | ---> CE-marked packet 257 | Old | 258 Non-ECN traffic ----------> | Router | ---> dropped packet 259 | | 260 RFC-3168 ECN traffic -----> | | ---> CE-marked packet 261 |--------| 263 Figure 1: Alternate-ECN traffic with an old router using RFC-3168 ECN. 265 Similarly, what if there is an old router along the path that 266 understands only the default ECN semantics from RFC-3168, as in 267 Figure 1 above? In times of congestion, the old default-ECN router 268 could see an alternate-ECN packet with one of the ECN-Capable 269 Transport (ECT) codepoints set in the ECN field in the IP header, as 270 defined in RFC 3168, and set the Congestion Experienced (CE) 271 codepoint in the ECN field as an alternative to dropping the packet. 272 The router in this case would expect the alternate-ECN connection to 273 respond, in terms of congestion control, as it would if the packet 274 has been dropped. If the alternate-ECN traffic fails to respond 275 appropriately to the CE codepoint being set by an old router, this 276 could increase the aggregate traffic arriving at the old router, 277 resulting in an increase in the packet-marking and packet-dropping 278 rates at that router, further resulting in the alternate-ECN traffic 279 crowding out the other traffic competing for bandwidth on that link. 281 Basically, there are three possibilities for avoiding scenarios 282 where the presence of old routers along the path results in the 283 alternate-ECN traffic competing unfairly with other traffic along 284 the path: 286 Option 1: Alternate-ECN traffic is clearly understood as unsafe for 287 deployment in the global Internet; or 289 Option 2: All alternate-ECN traffic deploys some mechanism for 290 verifying that all routers on the path understand and agree to use 291 the alternate ECN semantics for this traffic; or 293 Option 3: The alternate-ECN semantics are defined in such a way as 294 to ensure the fair and peaceful co-existence of the alternate-ECN 295 traffic with best-effort and other traffic, even in environments 296 that include old routers that do not understand the alternate-ECN 297 semantics. 299 Each of these alternatives is explored in more detail below. 301 4.1. Option 1: Unsafe for Deployment in the Internet 303 The first option specified above is for the alternate-ECN traffic to 304 be clearly understood as only suitable for enclosed environments, 305 and as unsafe for deployment in the global Internet. This would 306 mean that it would be unsafe for packets using the alternate ECN 307 semantics to be unleashed in the global Internet, in order to avoid 308 the chance of the alternate-ECN traffic traversing an old router 309 that don't understand the alternate semantics. This document 310 doesn't comment on whether a mechanism would be required to ensure 311 that the alternate-ECN semantics would not be let loose on the 312 global Internet. This document also doesn't comment on the chances 313 that this scenario would be considered acceptable for 314 standardization by the IETF community. 316 4.2. Option 2: Verification that Routers Understand the Alternate 317 Semantics 319 The second option specified above is for the alternate-ECN traffic 320 to include a mechanism for ensuring that all routers along the path 321 understand and agree to the use of the alternate ECN semantics for 322 this traffic. As an example, such a mechanism could consist of a 323 field in an IP option that all routers along the path decrement if 324 they agree to use the alternate ECN semantics with this traffic. (A 325 similar mechanism is proposed for Quick-Start, for verifying that 326 all of the routers along the path understand the Quick-Start IP 327 Option [QuickStart].) Using such a mechanism, a sender could have 328 reasonable assurance that the packets that are sent specifying the 329 use of alternate ECN semantics only traverse routers that in fact 330 understand and agree to use these alternate semantics for these 331 packets. 333 Such a mechanism should be robust in the presence of paths with load 334 balancing, and in the presence of routing changes in the middle of a 335 connection. 337 4.3. Option 3: Friendly Co-existence with Competing Traffic 339 The third option specified above is for the alternate ECN semantics 340 to be defined so that traffic using the alternate semantics would 341 co-exist safely in the Internet on a path with one or more old 342 routers that use only the default ECN semantics. In this scenario, 343 a connection sending alternate-ECN traffic would have to respond 344 appropriately to a CE packet (a packet with the ECN codepoint "11") 345 received at the receiver, using a conformant congestion control 346 response. Hopefully, the connection sending alternate-ECN traffic 347 would also respond appropriately to a dropped packet, that could be 348 a congestion indication from a router that doesn't use ECN. 350 RFC 3168 defines the default ECN semantics as follows: 352 "Upon the receipt by an ECN-Capable transport of a single CE packet, 353 the congestion control algorithms followed at the end-systems MUST 354 be essentially the same as the congestion control response to a 355 *single* dropped packet. For example, for ECN-Capable TCP the 356 source TCP is required to halve its congestion window for any window 357 of data containing either a packet drop or an ECN indication." 359 The only conformant congestion control mechanisms currently 360 standardized in the IETF are TCP [RFC2581] and protocols using TCP- 361 like congestion control (e.g., SCTP [RFC2960], DCCP with CCID-2 362 [DCCP]), and TCP-Friendly Rate Control (TFRC) and protocols with 363 TFRC-like congestion control (e.g., DCCP using CCID-3 [DCCP]). TCP 364 uses Additive-Increase Multiplicative-Decrease congestion control, 365 and responds to the loss or ECN-marking of a single packet by 366 halving its congestion window. In contrast, the equation-based 367 congestion control mechanism in TFRC estimates the loss event rate 368 over some period of time, and uses a sending rate that would be 369 comparable, in packets per round-trip-time, to that of a TCP 370 connection experiencing the same loss event rate. 372 So what are the requirements in order for alternate-ECN traffic to 373 compete appropriately with other traffic on a path through an old 374 router that doesn't understand the alternate ECN semantics (and 375 therefore might be using the default ECN semantics)? The first and 376 second requirements below concern compatibility between traffic 377 using alternate ECN semantics and routers using default ECN 378 semantics. 380 The first requirement for compatibility with routers using default 381 ECN is that if a packet is marked with the ECN codepoint "11" in the 382 network, this marking is not changed on the packet's way to the 383 receiver (unless the packet is dropped before it reaches the 384 receiver). This requirement is necessary to ensure that congestion 385 indications from a default-ECN router make it to the transport 386 receiver. 388 A second requirement for compatibility with routers using default 389 ECN is that the end-nodes respond in a TCP-friendly manner to 390 packets received that are marked with the ECN codepoint "11" 391 (because these packets might have come from a congested router that 392 understands only the default ECN semantics). This would ensure that 393 the traffic using the alternate semantics does not `bully' competing 394 traffic that it might encounter along the path, and does not drive 395 up congestion on the shared link inappropriately. 397 Additional requirements concern compatibility between traffic using 398 default ECN semantics and routers using alternate ECN semantics. 399 This situation could occur if a diff-serv codepoint using default 400 ECN semantics is redefined to use alternate ECN semantics, and 401 traffic from an "old" source traverses a "new" router. If the 402 router "knows" that a packet is from a sender using alternate 403 semantics (e.g., because the packet is using a certain diff-serv 404 codepoint, and all packets with that diff-serv codepoint use 405 alternate semantics for the ECN field), then the requirements below 406 are not necessary, and the rules for the alternate semantics apply. 408 A requirement for compatibility with end-nodes using default ECN is 409 that if a packet that *could* be using default semantics is marked 410 with the ECN codepoint "00", this marking must not be changed to 411 "01", "10", or "11" in the network. This prevents the packet from 412 being represented incorrectly to a default ECN router downstream as 413 ECN-Capable. Similarly, if a packet that *could* be using default 414 semantics is marked with the ECN codepoint "01", then this codepoint 415 should not be changed to "10" in the network (and a "10" codepoint 416 should not be changed to "01"). This requirement is necessary to 417 avoid interference with the transport protocol's use of the ECN 418 nonce. 420 As discussed earlier, the current conformant congestion control 421 responses to a dropped or default-ECN-marked packet consist of TCP 422 and TCP-like congestion control, and of TFRC (TCP-Friendly Rate 423 Control). Another possible response considered in RFC 3714, but not 424 standardized in a standards-track document, is that of simply 425 terminating an alternate-ECN connection for a period of time if the 426 long-term sending rate is higher that would be that of a TCP 427 connection experiencing the same packet dropping or marking rates 428 [RFC3714]. We note that the use of such a congestion control 429 response to CE-marked packets would require specification of time 430 constants for measuring the loss rates and for stopping 431 transmission, and would require a consideration of issues of packet 432 size. 434 5. Evaluation of the Alternate-ECN Semantics 436 This section discusses question (4) posed in Section 2: 438 (4) How well does the alternate-ECN traffic perform, and how well 439 does it co-exist with competing traffic on the path, in a "clean" 440 environment with new routers and with the unambiguous specification 441 of the use of alternate-ECN semantics? 443 5.1. Verification of Feedback from the Router 445 One issue in evaluating the alternate-ECN semantics concerns 446 mechanisms to discourage lying from the transport receiver to the 447 transport sender. In many cases the sender is a server that has an 448 interest in using the alternate-ECN semantics correctly, while the 449 receiver has more incentives for lying about the congestion 450 experienced along the path. 452 In the default ECN semantics, two of the four ECN codepoints are 453 used for ECN-Capable(0) and ECN-Capable(1). The use of two 454 codepoints for ECN-Capable, instead of one, permits the data sender 455 to verify receiver's reports that packets were actually received 456 unmarked at the receiver. In particular, the sender can specify 457 that the receiver report to the sender whether each unmarked packet 458 was received ECN-Capable(0) or ECN-Capable(1), as discussed in RFC 459 3540 [RFC 3540]. 461 If alternate semantics for the ECN codepoint don't include the use 462 of two separate codepoints to indicate ECN-Capable, then the 463 connections using those semantics have lost the ability to verify 464 that the data receiver is accurately reporting the received ECN 465 codepoint to the data sender. In this case, it might be necessary 466 for the alternate-ECN framework to include alternate mechanisms for 467 ensuring that the data receiver is reporting feedback appropriately 468 to the sender. 470 5.2. Co-existence with Competing Traffic 472 A second general issue concerns the co-existence of alternate-ECN 473 traffic with competing traffic along the path, in a clean 474 environment where all routers understand and are willing to use the 475 alternate-ECN semantics for the traffic that specifies its use. 477 If the traffic using the alternate-ECN semantics is best-effort 478 traffic, then it is subject to the general requirement of fair 479 competition with TCP and other traffic along the path [RFC2914]. 481 If the traffic using the alternate-ECN semantics is diffserv 482 traffic, then the requirements are governed by the overall 483 guidelines for that class of diffserv traffic. It is beyond the 484 scope of this document to specify the requirements, if any, for the 485 co-existence of diffserv traffic with other traffic on the link; 486 this should be addressed in the specification of the diffserv 487 codepoint itself. 489 5.3. A General Evaluation of the Alternate-ECN Semantics 491 A third general issue concerns the evaluation of the general merits 492 of the proposed alternate-ECN semantics. Again, it would be beyond 493 the scope of this document to specify requirements for the general 494 evaluation of alternate-ECN semantics. 496 6. Who Wants to Use Alternate Semantics for the ECN Codepoint? 498 There have been a number of proposals in the IETF and in the 499 research community for alternate semantics for the ECN codepoint 500 [ECN]. One such proposal, [BCF05], proposes an alternate-ECN 501 semantics for real-time inelastic traffic such as voice, video 502 conferencing, and multimedia streaming in DiffServ networks. In 503 this proposal, the alternate-ECN semantics would provide information 504 about two levels of congestion experienced along the path, where "it 505 is left up to the application designers to define how end-systems 506 should react to ECN bit marking" [BCF05]. Some of the other 507 proposals for alternate ECN semantics are listed on the ECN Web Page 508 [ECN]. 510 7. Security Considerations 512 This document doesn't propose any new mechanisms for the Internet 513 protocol, and therefore doesn't introduce any new security 514 considerations. 516 8. Acknowledgements 518 This document is based in part on conversations with Jozef Babiarz, 519 Kwok Ho Chan, and Victor Firoiu on their proposal for an alternate 520 use of the ECN field in DiffServ environments. Many thanks to 521 Francois Le Faucheur for feedback recommending that the document 522 include a section at the beginning discussing the potential issues 523 that need to be addressed. Thanks also to Fred Baker, David Black, 524 Gorry Fairhurst, and to members of the TSVWG working group for 525 feedback on these issues. 527 9. Conclusions 529 This document has discussed some of the issues to be considered in 530 the specification of alternate semantics for the ECN field in the IP 531 header. 533 10. Normative References 535 11. Informative References 537 [BCF05] J. Babiarz, K. Chan, and V. Firoiu, Congestion Notification 538 Process for Real-Time Traffic, internet-draft draft-babiarz-tsvwg- 539 rtecn-03, work in progress, February 2005. 541 [DCCP] DCCP Web Page, URL "http://www.icir.org/kohler/dccp/". 543 [ECN] ECN Web Page, URL "www.icir.org/floyd/ecn.html". 545 [QuickStart] Quick-Start Web Page, URL 546 "http://www.icir.org/floyd/quickstart.html". 548 [RFC2581] M. Allman, V. Paxson, and W. Stevens, TCP Congestion 549 Control, RFC 2581, Proposed Standard, April 1999. 551 [RFC2914] S. Floyd, Congestion Control Principles, RFC 2914, Best 552 Current Practice, September 2000. 554 [RFC2960] R. Stewart et al, Stream Control Transmission Protocol, 555 RFC 2960, October 2000. 557 [RFC3168] Ramakrishnan, K.K., Floyd, S., and Black, D., The Addition 558 of Explicit Congestion Notification (ECN) to IP, RFC 3168, Proposed 559 Standard, September 2001. 561 [RFC3540] N. Spring, D. Wetherall, and D. Ely, Robust Explicit 562 Congestion Notification (ECN) Signaling with Nonces, RFC 3540, 563 Experimental, June 2003. 565 [RFC3714] S. Floyd and J. Kempf, Editors, IAB Concerns Regarding 566 Congestion Control for Voice Traffic in the Internet, RFC 3714, 567 Informational, March 2004. 569 IANA Considerations 571 There are no IANA considerations in this document. 573 AUTHORS' ADDRESSES 575 Sally Floyd 576 Phone: +1 (510) 666-2989 577 ICIR (ICSI Center for Internet Research) 578 Email: floyd@icir.org 579 URL: http://www.icir.org/floyd/ 581 Full Copyright Statement 583 Copyright (C) The Internet Society 2005. This document is subject 584 to the rights, licenses and restrictions contained in BCP 78, and 585 except as set forth therein, the authors retain all their rights. 587 This document and the information contained herein are provided on 588 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 589 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 590 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 591 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 592 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 593 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 595 Intellectual Property 597 The IETF takes no position regarding the validity or scope of any 598 Intellectual Property Rights or other rights that might be claimed 599 to pertain to the implementation or use of the technology described 600 in this document or the extent to which any license under such 601 rights might or might not be available; nor does it represent that 602 it has made any independent effort to identify any such rights. 603 Information on the procedures with respect to rights in RFC 604 documents can be found in BCP 78 and BCP 79. 606 Copies of IPR disclosures made to the IETF Secretariat and any 607 assurances of licenses to be made available, or the result of an 608 attempt made to obtain a general license or permission for the use 609 of such proprietary rights by implementers or users of this 610 specification can be obtained from the IETF on-line IPR repository 611 at http://www.ietf.org/ipr. 613 The IETF invites any interested party to bring to its attention any 614 copyrights, patents or patent applications, or other proprietary 615 rights that may cover technology that may be required to implement 616 this standard. Please address the information to the IETF at ietf- 617 ipr@ietf.org.