idnits 2.17.1 draft-floyd-ecn-alternates-02.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 617. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 628. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 635. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 641. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 609), 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 : ---------------------------------------------------------------------------- ** 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 371: '...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 -- 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 (18 August 2005) is 6798 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 145, but not defined == Missing Reference: 'RFC 3540' is mentioned on line 480, but not defined == Unused Reference: 'RFC3168' is defined on line 581, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-babiarz-tsvwg-rtecn-04 -- 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 (~~), 6 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-02.txt 18 August 2005 4 Expires: February 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 February 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-01.txt: 54 * Changed requirement for TCP friendliness, to a requirement of 55 friendliness with IETF-conformant congestion control. From email 56 from Mark Allman. 58 * Added to discussion of robustness to route changes. From email 59 from Mark Allman. 61 * Added an explicit note that the ECN nonce is agnostic to the 62 semantics of the other codepoints, and could be used with alternate 63 ECN semantics. 65 * Minor editing, from email from Mark Allman. 67 Changes from draft-floyd-ecn-alternates-00.txt: 69 * Added requirements for compatibility between traffic using default 70 ECN semantics and routers using alternate ECN semantics, to the 71 section on "Option 3: Friendly Co-existence with Competing 72 Traffic". From email from Gorry Fairhurst. 74 * Added to the discussion of using the diffserv code point to signal 75 alternate ECN semantics. From email from Gorry Fairhurst. 77 * Minor editing for clarity, also from email from Gorry Fairhurst. 79 END OF NOTE TO RFC EDITOR. 81 Table of Contents 83 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3 84 2. An Overview of the Issues . . . . . . . . . . . . . . . . . . 3 85 3. Signalling the Use of Alternate ECN Semantics . . . . . . . . 4 86 3.1. Using the Diffserv Field for Signalling. . . . . . . . . 5 87 4. Issues of Incremental Deployment. . . . . . . . . . . . . . . 6 88 4.1. Option 1: Unsafe for Deployment in the 89 Internet. . . . . . . . . . . . . . . . . . . . . . . . . . . 8 90 4.2. Option 2: Verification that Routers Under- 91 stand the Alternate Semantics . . . . . . . . . . . . . . . . 8 92 4.3. Option 3: Friendly Co-existence with Com- 93 peting Traffic. . . . . . . . . . . . . . . . . . . . . . . . 8 94 5. Evaluation of the Alternate-ECN Semantics . . . . . . . . . . 11 95 5.1. Verification of Feedback from the Router . . . . . . . . 11 96 5.2. Co-existence with Competing Traffic. . . . . . . . . . . 11 97 5.3. A General Evaluation of the Alternate-ECN 98 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . 12 99 6. Who Wants to Use Alternate Semantics for the ECN 100 Codepoint? . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 101 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 102 8. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 12 103 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 13 104 10. Normative References . . . . . . . . . . . . . . . . . . . . 13 105 11. Informative References . . . . . . . . . . . . . . . . . . . 13 106 IANA Considerations. . . . . . . . . . . . . . . . . . . . . . . 14 107 AUTHORS' ADDRESSES . . . . . . . . . . . . . . . . . . . . . . . 14 108 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 14 109 Intellectual Property. . . . . . . . . . . . . . . . . . . . . . 14 111 1. Introduction 113 RFC 3168, a Proposed Standard document, defines the ECN field in the 114 IP header, and specifies the semantics for the codepoints for the 115 ECN field. However, end nodes could specify the use of alternate 116 semantics for the ECN field, e.g., using codepoints in the diffserv 117 field of the IP header. This document describes some of the issues 118 that arise in specifying such alternate semantics for the ECN field, 119 and gives requirements for a safe co-existence in a world using the 120 default ECN semantics (or using no ECN at all). 122 2. An Overview of the Issues 124 In this section we discuss some of the issues that arise if some of 125 the traffic in a network consists of alternate-ECN traffic (i.e., 126 traffic using alternate semantics for the ECN field). The issues 127 include the following: (1) how routers know which ECN semantics to 128 use with which packets; (2) incremental deployment in a network 129 where some routers use only the default ECN semantics, or no ECN at 130 all; (3) co-existence of alternate-ECN traffic with competing 131 traffic on the path; and (4) a general evaluation of the alternate- 132 ECN semantics. 134 (1) The first issue concerns how routers know which ECN semantics to 135 use with which packets in the network: 137 How does the connection indicate to the router that its packets are 138 using alternate-ECN semantics? Is the specification of alternate- 139 ECN semantics robust and unambiguous? If not, is this a problem? 141 As an example, in most of the proposals for alternate-ECN semantics, 142 a diffserv field is used to specify the use of alternate-ECN 143 semantics. Do all routers that understand this diffserv codepoint 144 understand that it uses alternate-ECN semantics, or not? Diffserv 145 allows routers to re-mark DiffServ Code Point [DSCP] values within 146 the network; what is the effect of this on the alternate-ECN 147 semantics? 149 This is discussed in more detail in Section 3 below. 151 (2) A second issue is that of incremental deployment in a network 152 where some routers only use the default ECN semantics, and other 153 routers might not use ECN at all. In this document we use the 154 phrase "new routers" to refer to the routers that understand the 155 alternate-ECN semantics, and "old routers" to refer to routers that 156 don't understand or aren't willing to use the alternate-ECN 157 semantics. 159 The possible existence of old routers raises the following question: 160 How does the possible presence of old routers affect the performance 161 of the alternate-ECN connections? 163 (3) The possible existence of old routers also raises the question 164 of how the presence of old routers affects the co-existence of the 165 alternate-ECN traffic with competing traffic on the path. 167 Issues (2) and (3) are discussed in Section 4 below. 169 (4) A final issue is that of the general evaluation of the 170 alternate-ECN semantics: 172 How well does the alternate-ECN traffic perform, and how well does 173 it co-exist with competing traffic on the path, in a "clean" 174 environment with new routers and with the unambiguous specification 175 of the use of alternate-ECN semantics? 177 These issues are discussed in Section 5 below. 179 3. Signalling the Use of Alternate ECN Semantics 181 This section discusses question (1) from Section 2: 183 (1) How does the connection indicate to the router that its packets 184 are using alternate-ECN semantics? Is the specification of 185 alternate-ECN semantics robust and unambiguous? If not, is this a 186 problem? 188 The assumption of this document is that when alternate semantics are 189 defined for the ECN field, a codepoint in the diffserv field is used 190 to signal the use of these alternate ECN semantics to the router. 191 That is, the end host sets the codepoint in the diffserv field to 192 indicate to routers that alternate semantics to the ECN field are 193 being used. Routers that understand this diffserv codepoint would 194 know to use the alternate semantics for interpreting and setting the 195 ECN field. Old ECN-capable routers that do not understand this 196 diffserv codepoint would use the default ECN semantics in 197 interpreting and setting the ECN field. 199 In general, the diffserv codepoints are used to signal the per-hop 200 behavior at router queues. One possibility would be to use one 201 diffserv codepoint to signal a per-hop behavior with the default ECN 202 semantics, and a separate diffserv codepoint to signal a similar 203 per-hop behavior with the alternate ECN semantics. Another 204 possibility would be to use a diffserv codepoint to signal the use 205 of best-effort per-hop queueing and scheduling behavior, but with 206 alternate ECN semantics. A detailed discussion of these issues is 207 beyond the scope of this document. 209 We note that this discussion does not exclude the possibility of 210 using other methods, including out-of-band mechanisms, for 211 signalling the use of alternate semantics for the ECN field. The 212 considerations in the rest of this document apply regardless of the 213 method used to signal the use of alternate semantics for the ECN 214 field. 216 3.1. Using the Diffserv Field for Signalling 218 We note that the default ECN semantics defined in RFC 3168 are the 219 current default semantics for the ECN field, regardless of the 220 contents of any other fields in the IP header. In particular, the 221 default ECN semantics apply for more than best-effort traffic with a 222 codepoint of '000000' for the diffserv field - the default ECN 223 semantics currently apply regardless of the contents of the diffserv 224 field. 226 There are two ways to use the diffserv field to signal the use of 227 alternate ECN semantics. One way is to use an existing diffserv 228 codepoint, and to modify the current definition of that codepoint, 229 through approved IETF processes, to specify the use of alternate ECN 230 semantics with that codepoint. A second way is to define a new 231 diffserv codepoint, and to specify the use of alternate ECN 232 semantics with that codepoint. We note that the first of these two 233 mechanisms raises the possibility that some routers along the path 234 will understand the diffserv codepoint but will use the default ECN 235 semantics with this diffserv codepoint, or won't use ECN at all, and 236 that other routers will use the alternate ECN semantics with this 237 diffserv codepoint. 239 4. Issues of Incremental Deployment 241 This section discusses questions (2) and (3) posed in Section 2: 243 (2) How does the possible presence of old routers affect the 244 performance of the alternate-ECN connections? 246 (3) How does the possible presence of old routers affect the co- 247 existence of the alternate-ECN traffic with competing traffic on the 248 path? 250 When alternate semantics are defined for the ECN field, it is 251 necessary to ensure that there are no problems caused by old routers 252 along the path that don't understand the alternate ECN semantics. 254 One possible problem is that of poor performance for the alternate- 255 ECN traffic. Is it essential to the performance of the alternate- 256 ECN traffic that all routers along the path understand the 257 alternate-ECN semantics? If not, what are the possible 258 consequences, for the alternate-ECN traffic itself, when some old 259 routers along the path don't understand the alternate-ECN semantics? 260 These issues have to be answered in the context of each specific 261 proposal for alternate ECN semantics. 263 A second specific problem is that of possible unfair competition 264 with other traffic along the path. If there is an old router along 265 the path that doesn't use ECN, that old router could drop packets 266 from the alternate-ECN traffic, and expect the alternate-ECN traffic 267 to reduce its sending rate as a result. Does the alternate-ECN 268 traffic respond to packet drops as an indication of congestion? 269 |--------| 270 Alternate-ECN traffic ----> | | ---> CE-marked packet 271 | Old | 272 Non-ECN traffic ----------> | Router | ---> dropped packet 273 | | 274 RFC-3168 ECN traffic -----> | | ---> CE-marked packet 275 |--------| 277 Figure 1: Alternate-ECN traffic, an old router using RFC-3168 ECN. 279 Similarly, what if there is an old router along the path that 280 understands only the default ECN semantics from RFC-3168, as in 281 Figure 1 above? In times of congestion, the old default-ECN router 282 could see an alternate-ECN packet with one of the ECN-Capable 283 Transport (ECT) codepoints set in the ECN field in the IP header, as 284 defined in RFC 3168, and set the Congestion Experienced (CE) 285 codepoint in the ECN field as an alternative to dropping the packet. 286 The router in this case would expect the alternate-ECN connection to 287 respond, in terms of congestion control, as it would if the packet 288 has been dropped. If the alternate-ECN traffic fails to respond 289 appropriately to the CE codepoint being set by an old router, this 290 could increase the aggregate traffic arriving at the old router, 291 resulting in an increase in the packet-marking and packet-dropping 292 rates at that router, further resulting in the alternate-ECN traffic 293 crowding out the other traffic competing for bandwidth on that link. 295 Basically, there are three possibilities for avoiding scenarios 296 where the presence of old routers along the path results in the 297 alternate-ECN traffic competing unfairly with other traffic along 298 the path: 300 Option 1: Alternate-ECN traffic is clearly understood as unsafe for 301 deployment in the global Internet; or 303 Option 2: All alternate-ECN traffic deploys some mechanism for 304 verifying that all routers on the path understand and agree to use 305 the alternate ECN semantics for this traffic; or 307 Option 3: The alternate-ECN semantics are defined in such a way as 308 to ensure the fair and peaceful co-existence of the alternate-ECN 309 traffic with best-effort and other traffic, even in environments 310 that include old routers that do not understand the alternate-ECN 311 semantics. 313 Each of these alternatives is explored in more detail below. 315 4.1. Option 1: Unsafe for Deployment in the Internet 317 The first option specified above is for the alternate-ECN traffic to 318 be clearly understood as only suitable for enclosed environments, 319 and as unsafe for deployment in the global Internet. This would 320 mean that it would be unsafe for packets using the alternate ECN 321 semantics to be unleashed in the global Internet, in order to avoid 322 the chance of the alternate-ECN traffic traversing an old router 323 that don't understand the alternate semantics. This document 324 doesn't comment on whether a mechanism would be required to ensure 325 that the alternate-ECN semantics would not be let loose on the 326 global Internet. This document also doesn't comment on the chances 327 that this scenario would be considered acceptable for 328 standardization by the IETF community. 330 4.2. Option 2: Verification that Routers Understand the Alternate 331 Semantics 333 The second option specified above is for the alternate-ECN traffic 334 to include a mechanism for ensuring that all routers along the path 335 understand and agree to the use of the alternate ECN semantics for 336 this traffic. As an example, such a mechanism could consist of a 337 field in an IP option that all routers along the path decrement if 338 they agree to use the alternate ECN semantics with this traffic. (A 339 similar mechanism is proposed for Quick-Start, for verifying that 340 all of the routers along the path understand the Quick-Start IP 341 Option [QuickStart].) Using such a mechanism, a sender could have 342 reasonable assurance that the packets that are sent specifying the 343 use of alternate ECN semantics only traverse routers that in fact 344 understand and agree to use these alternate semantics for these 345 packets. 347 Such a mechanism should be robust in the presence of paths with 348 multi-path routing, and in the presence of routing or configuration 349 changes along the path while the connection is in use. In 350 particular, if this option is used, connections could include some 351 form of monitoring for changes in path behavior, and/or periodic 352 monitoring that all routers along the path continue to understand 353 the alternate-ECN semantics. 355 4.3. Option 3: Friendly Co-existence with Competing Traffic 357 The third option specified above is for the alternate ECN semantics 358 to be defined so that traffic using the alternate semantics would 359 co-exist safely in the Internet on a path with one or more old 360 routers that use only the default ECN semantics. In this scenario, 361 a connection sending alternate-ECN traffic would have to respond 362 appropriately to a CE packet (a packet with the ECN codepoint "11") 363 received at the receiver, using a conformant congestion control 364 response. Hopefully, the connection sending alternate-ECN traffic 365 would also respond appropriately to a dropped packet, that could be 366 a congestion indication from a router that doesn't use ECN. 368 RFC 3168 defines the default ECN semantics as follows: 370 "Upon the receipt by an ECN-Capable transport of a single CE packet, 371 the congestion control algorithms followed at the end-systems MUST 372 be essentially the same as the congestion control response to a 373 *single* dropped packet. For example, for ECN-Capable TCP the 374 source TCP is required to halve its congestion window for any window 375 of data containing either a packet drop or an ECN indication." 377 The only conformant congestion control mechanisms currently 378 standardized in the IETF are TCP [RFC2581] and protocols using TCP- 379 like congestion control (e.g., SCTP [RFC2960], DCCP with CCID-2 380 [DCCP]), and TCP-Friendly Rate Control (TFRC) and protocols with 381 TFRC-like congestion control (e.g., DCCP using CCID-3 [DCCP]). TCP 382 uses Additive-Increase Multiplicative-Decrease congestion control, 383 and responds to the loss or ECN-marking of a single packet by 384 halving its congestion window. In contrast, the equation-based 385 congestion control mechanism in TFRC estimates the loss event rate 386 over some period of time, and uses a sending rate that would be 387 comparable, in packets per round-trip-time, to that of a TCP 388 connection experiencing the same loss event rate. 390 So what are the requirements in order for alternate-ECN traffic to 391 compete appropriately with other traffic on a path through an old 392 router that doesn't understand the alternate ECN semantics (and 393 therefore might be using the default ECN semantics)? The first and 394 second requirements below concern compatibility between traffic 395 using alternate ECN semantics and routers using default ECN 396 semantics. 398 The first requirement for compatibility with routers using default 399 ECN is that if a packet is marked with the ECN codepoint "11" in the 400 network, this marking is not changed on the packet's way to the 401 receiver (unless the packet is dropped before it reaches the 402 receiver). This requirement is necessary to ensure that congestion 403 indications from a default-ECN router make it to the transport 404 receiver. 406 A second requirement for compatibility with routers using default 407 ECN is that the end-nodes respond to packets that are marked with 408 the ECN codepoint "11" in a way that is friendly to flows using 409 IETF-conformant congestion control. This requirement is needed 410 because the "11"-marked packets might have come from a congested 411 router that understands only the default ECN semantics, and that 412 expects that end-nodes will respond appropriately to CE packets. 413 This requirement would ensure that the traffic using the alternate 414 semantics does not `bully' competing traffic that it might encounter 415 along the path, and does not drive up congestion on the shared link 416 inappropriately. 418 Additional requirements concern compatibility between traffic using 419 default ECN semantics and routers using alternate ECN semantics. 420 This situation could occur if a diff-serv codepoint using default 421 ECN semantics is redefined to use alternate ECN semantics, and 422 traffic from an "old" source traverses a "new" router. If the 423 router "knows" that a packet is from a sender using alternate 424 semantics (e.g., because the packet is using a certain diff-serv 425 codepoint, and all packets with that diff-serv codepoint use 426 alternate semantics for the ECN field), then the requirements below 427 are not necessary, and the rules for the alternate semantics apply. 429 A requirement for compatibility with end-nodes using default ECN is 430 that if a packet that *could* be using default semantics is marked 431 with the ECN codepoint "00", this marking must not be changed to 432 "01", "10", or "11" in the network. This prevents the packet from 433 being represented incorrectly to a default ECN router downstream as 434 ECN-Capable. Similarly, if a packet that *could* be using default 435 semantics is marked with the ECN codepoint "01", then this codepoint 436 should not be changed to "10" in the network (and a "10" codepoint 437 should not be changed to "01"). This requirement is necessary to 438 avoid interference with the transport protocol's use of the ECN 439 nonce [RFC3540]. 441 As discussed earlier, the current conformant congestion control 442 responses to a dropped or default-ECN-marked packet consist of TCP 443 and TCP-like congestion control, and of TFRC (TCP-Friendly Rate 444 Control). Another possible response considered in RFC 3714, but not 445 standardized in a standards-track document, is that of simply 446 terminating an alternate-ECN connection for a period of time if the 447 long-term sending rate is higher than would be that of a TCP 448 connection experiencing the same packet dropping or marking rates 449 [RFC3714]. We note that the use of such a congestion control 450 response to CE-marked packets would require specification of time 451 constants for measuring the loss rates and for stopping 452 transmission, and would require a consideration of issues of packet 453 size. 455 5. Evaluation of the Alternate-ECN Semantics 457 This section discusses question (4) posed in Section 2: 459 (4) How well does the alternate-ECN traffic perform, and how well 460 does it co-exist with competing traffic on the path, in a "clean" 461 environment with new routers and with the unambiguous specification 462 of the use of alternate-ECN semantics? 464 5.1. Verification of Feedback from the Router 466 One issue in evaluating the alternate-ECN semantics concerns 467 mechanisms to discourage lying from the transport receiver to the 468 transport sender. In many cases the sender is a server that has an 469 interest in using the alternate-ECN semantics correctly, while the 470 receiver has more incentives for lying about the congestion 471 experienced along the path. 473 In the default ECN semantics, two of the four ECN codepoints are 474 used for ECN-Capable(0) and ECN-Capable(1). The use of two 475 codepoints for ECN-Capable, instead of one, permits the data sender 476 to verify receiver's reports that packets were actually received 477 unmarked at the receiver. In particular, the sender can specify 478 that the receiver report to the sender whether each unmarked packet 479 was received ECN-Capable(0) or ECN-Capable(1), as discussed in RFC 480 3540 [RFC 3540]. This use of ECN-Capable(0) and ECN-Capable(1) is 481 independent of the semantics of the other ECN codepoints, and could 482 be used, if desired, with alternate semantics for the other 483 codepoints. 485 If alternate semantics for the ECN codepoint don't include the use 486 of two separate codepoints to indicate ECN-Capable, then the 487 connections using those semantics have lost the ability to verify 488 that the data receiver is accurately reporting the received ECN 489 codepoint to the data sender. In this case, it might be necessary 490 for the alternate-ECN framework to include alternate mechanisms for 491 ensuring that the data receiver is reporting feedback appropriately 492 to the sender. As one possibility, policers could be used in 493 routers to ensure that end nodes are responding appropriately to 494 marked packets. 496 5.2. Co-existence with Competing Traffic 498 A second general issue concerns the co-existence of alternate-ECN 499 traffic with competing traffic along the path, in a clean 500 environment where all routers understand and are willing to use the 501 alternate-ECN semantics for the traffic that specifies its use. 503 If the traffic using the alternate-ECN semantics is best-effort 504 traffic, then it is subject to the general requirement of fair 505 competition with TCP and other traffic along the path [RFC2914]. 507 If the traffic using the alternate-ECN semantics is diffserv 508 traffic, then the requirements are governed by the overall 509 guidelines for that class of diffserv traffic. It is beyond the 510 scope of this document to specify the requirements, if any, for the 511 co-existence of diffserv traffic with other traffic on the link; 512 this should be addressed in the specification of the diffserv 513 codepoint itself. 515 5.3. A General Evaluation of the Alternate-ECN Semantics 517 A third general issue concerns the evaluation of the general merits 518 of the proposed alternate-ECN semantics. Again, it would be beyond 519 the scope of this document to specify requirements for the general 520 evaluation of alternate-ECN semantics. 522 6. Who Wants to Use Alternate Semantics for the ECN Codepoint? 524 There have been a number of proposals in the IETF and in the 525 research community for alternate semantics for the ECN codepoint 526 [ECN]. One such proposal, [BCF05], proposes an alternate-ECN 527 semantics for real-time inelastic traffic such as voice, video 528 conferencing, and multimedia streaming in DiffServ networks. In 529 this proposal, the alternate-ECN semantics would provide information 530 about two levels of congestion experienced along the path [BCF05]. 531 Some of the other proposals for alternate ECN semantics are listed 532 on the ECN Web Page [ECN]. 534 7. Security Considerations 536 This document doesn't propose any new mechanisms for the Internet 537 protocol, and therefore doesn't introduce any new security 538 considerations. 540 8. Acknowledgements 542 This document is based in part on conversations with Jozef Babiarz, 543 Kwok Ho Chan, and Victor Firoiu on their proposal for an alternate 544 use of the ECN field in DiffServ environments. Many thanks to 545 Francois Le Faucheur for feedback recommending that the document 546 include a section at the beginning discussing the potential issues 547 that need to be addressed. Thanks also to Mark Allman, Fred Baker, 548 David Black, Gorry Fairhurst, and to members of the TSVWG working 549 group for feedback on these issues. 551 9. Conclusions 553 This document has discussed some of the issues to be considered in 554 the specification of alternate semantics for the ECN field in the IP 555 header. 557 10. Normative References 559 11. Informative References 561 [BCF05] J. Babiarz, K. Chan, and V. Firoiu, Congestion Notification 562 Process for Real-Time Traffic, internet-draft draft-babiarz-tsvwg- 563 rtecn-04, work in progress, July 2005. 565 [DCCP] DCCP Web Page, URL "http://www.icir.org/kohler/dccp/". 567 [ECN] ECN Web Page, URL "www.icir.org/floyd/ecn.html". 569 [QuickStart] Quick-Start Web Page, URL 570 "http://www.icir.org/floyd/quickstart.html". 572 [RFC2581] M. Allman, V. Paxson, and W. Stevens, TCP Congestion 573 Control, RFC 2581, Proposed Standard, April 1999. 575 [RFC2914] S. Floyd, Congestion Control Principles, RFC 2914, Best 576 Current Practice, September 2000. 578 [RFC2960] R. Stewart et al, Stream Control Transmission Protocol, 579 RFC 2960, October 2000. 581 [RFC3168] Ramakrishnan, K.K., Floyd, S., and Black, D., The Addition 582 of Explicit Congestion Notification (ECN) to IP, RFC 3168, Proposed 583 Standard, September 2001. 585 [RFC3540] N. Spring, D. Wetherall, and D. Ely, Robust Explicit 586 Congestion Notification (ECN) Signaling with Nonces, RFC 3540, 587 Experimental, June 2003. 589 [RFC3714] S. Floyd and J. Kempf, Editors, IAB Concerns Regarding 590 Congestion Control for Voice Traffic in the Internet, RFC 3714, 591 Informational, March 2004. 593 IANA Considerations 595 There are no IANA considerations in this document. 597 AUTHORS' ADDRESSES 599 Sally Floyd 600 Phone: +1 (510) 666-2989 601 ICIR (ICSI Center for Internet Research) 602 Email: floyd@icir.org 603 URL: http://www.icir.org/floyd/ 605 Full Copyright Statement 607 Copyright (C) The Internet Society 2005. This document is subject 608 to the rights, licenses and restrictions contained in BCP 78, and 609 except as set forth therein, the authors retain all their rights. 611 This document and the information contained herein are provided on 612 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 613 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 614 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 615 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 616 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 617 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 619 Intellectual Property 621 The IETF takes no position regarding the validity or scope of any 622 Intellectual Property Rights or other rights that might be claimed 623 to pertain to the implementation or use of the technology described 624 in this document or the extent to which any license under such 625 rights might or might not be available; nor does it represent that 626 it has made any independent effort to identify any such rights. 627 Information on the procedures with respect to rights in RFC 628 documents can be found in BCP 78 and BCP 79. 630 Copies of IPR disclosures made to the IETF Secretariat and any 631 assurances of licenses to be made available, or the result of an 632 attempt made to obtain a general license or permission for the use 633 of such proprietary rights by implementers or users of this 634 specification can be obtained from the IETF on-line IPR repository 635 at http://www.ietf.org/ipr. 637 The IETF invites any interested party to bring to its attention any 638 copyrights, patents or patent applications, or other proprietary 639 rights that may cover technology that may be required to implement 640 this standard. Please address the information to the IETF at ietf- 641 ipr@ietf.org.