idnits 2.17.1 draft-ietf-tsvwg-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.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 652. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 663. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 670. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 676. ** 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: ---------------------------------------------------------------------------- == 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 377: '...ithms followed at the end-systems MUST...' RFC 2119 keyword, line 526: '...ms followed at the end-systems MUST be...' 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 (12 January 2006) is 6677 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 151, but not defined == Missing Reference: 'RFC 3540' is mentioned on line 486, but not defined == Missing Reference: 'Section 5' is mentioned on line 528, but not defined == Outdated reference: A later version (-05) exists of draft-babiarz-tsvwg-rtecn-04 == Outdated reference: A later version (-04) exists of draft-briscoe-tsvwg-cl-architecture-01 -- 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: 5 errors (**), 0 flaws (~~), 7 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-ietf-tsvwg-ecn-alternates-00.txt 12 January 2006 4 Expires: July 2006 6 Specifying Alternate Semantics for the Explicit Congestion 7 Notification (ECN) Field 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as 24 reference material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on July 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 There have been a number of proposals for alternate semantics for 41 the ECN field in the IP header [ECN]. This document discusses some 42 of the issues in defining alternate semantics for the ECN field, and 43 specifies requirements for a safe co-existence in an Internet that 44 could include routers that do not understand the defined alternate 45 semantics. This document evolved as a result of discussions with 46 the authors of one recent proposal for such alternate semantics. 48 NOTE TO RFC EDITOR: PLEASE DELETE THIS NOTE UPON PUBLICATION. 50 Changes from draft-floyd-ecn-alternates-02.txt: 52 * Added a subsection on proposals for edge-to-edge ECN. 54 * Changed name to draft-ietf-tsvwg-ecn-alternates-00. 56 Changes from draft-floyd-ecn-alternates-01.txt: 58 * Changed requirement for TCP friendliness, to a requirement of 59 friendliness with IETF-conformant congestion control. From email 60 from Mark Allman. 62 * Added to discussion of robustness to route changes. From email 63 from Mark Allman. 65 * Added an explicit note that the ECN nonce is agnostic to the 66 semantics of the other codepoints, and could be used with alternate 67 ECN semantics. 69 * Minor editing, from email from Mark Allman. 71 Changes from draft-floyd-ecn-alternates-00.txt: 73 * Added requirements for compatibility between traffic using default 74 ECN semantics and routers using alternate ECN semantics, to the 75 section on "Option 3: Friendly Co-existence with Competing 76 Traffic". From email from Gorry Fairhurst. 78 * Added to the discussion of using the diffserv code point to signal 79 alternate ECN semantics. From email from Gorry Fairhurst. 81 * Minor editing for clarity, also from email from Gorry Fairhurst. 83 END OF NOTE TO RFC EDITOR. 85 Table of Contents 87 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3 88 2. An Overview of the Issues . . . . . . . . . . . . . . . . . . 3 89 3. Signalling the Use of Alternate ECN Semantics . . . . . . . . 5 90 3.1. Using the Diffserv Field for Signalling. . . . . . . . . 5 91 4. Issues of Incremental Deployment. . . . . . . . . . . . . . . 6 92 4.1. Option 1: Unsafe for Deployment in the 93 Internet. . . . . . . . . . . . . . . . . . . . . . . . . . . 8 94 4.2. Option 2: Verification that Routers Under- 95 stand the Alternate Semantics . . . . . . . . . . . . . . . . 8 96 4.3. Option 3: Friendly Co-existence with Com- 97 peting Traffic. . . . . . . . . . . . . . . . . . . . . . . . 8 98 5. Evaluation of the Alternate-ECN Semantics . . . . . . . . . . 11 99 5.1. Verification of Feedback from the Router . . . . . . . . 11 100 5.2. Co-existence with Competing Traffic. . . . . . . . . . . 11 101 5.3. Proposals for Alternate-ECN with Edge-to- 102 Edge Semantics. . . . . . . . . . . . . . . . . . . . . . . . 12 103 5.4. A General Evaluation of the Alternate-ECN 104 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . 12 105 6. Who Wants to Use Alternate Semantics for the ECN 106 Codepoint? . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 107 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 108 8. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 13 109 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 13 110 10. Normative References . . . . . . . . . . . . . . . . . . . . 13 111 11. Informative References . . . . . . . . . . . . . . . . . . . 13 112 IANA Considerations. . . . . . . . . . . . . . . . . . . . . . . 14 113 AUTHORS' ADDRESSES . . . . . . . . . . . . . . . . . . . . . . . 14 114 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 15 115 Intellectual Property. . . . . . . . . . . . . . . . . . . . . . 15 117 1. Introduction 119 RFC 3168, a Proposed Standard document, defines the ECN field in the 120 IP header, and specifies the semantics for the codepoints for the 121 ECN field. However, end nodes could specify the use of alternate 122 semantics for the ECN field, e.g., using codepoints in the diffserv 123 field of the IP header. This document describes some of the issues 124 that arise in specifying such alternate semantics for the ECN field, 125 and gives requirements for a safe co-existence in a world using the 126 default ECN semantics (or using no ECN at all). 128 2. An Overview of the Issues 130 In this section we discuss some of the issues that arise if some of 131 the traffic in a network consists of alternate-ECN traffic (i.e., 132 traffic using alternate semantics for the ECN field). The issues 133 include the following: (1) how routers know which ECN semantics to 134 use with which packets; (2) incremental deployment in a network 135 where some routers use only the default ECN semantics, or no ECN at 136 all; (3) co-existence of alternate-ECN traffic with competing 137 traffic on the path; and (4) a general evaluation of the alternate- 138 ECN semantics. 140 (1) The first issue concerns how routers know which ECN semantics to 141 use with which packets in the network: 143 How does the connection indicate to the router that its packets are 144 using alternate-ECN semantics? Is the specification of alternate- 145 ECN semantics robust and unambiguous? If not, is this a problem? 147 As an example, in most of the proposals for alternate-ECN semantics, 148 a diffserv field is used to specify the use of alternate-ECN 149 semantics. Do all routers that understand this diffserv codepoint 150 understand that it uses alternate-ECN semantics, or not? Diffserv 151 allows routers to re-mark DiffServ Code Point [DSCP] values within 152 the network; what is the effect of this on the alternate-ECN 153 semantics? 155 This is discussed in more detail in Section 3 below. 157 (2) A second issue is that of incremental deployment in a network 158 where some routers only use the default ECN semantics, and other 159 routers might not use ECN at all. In this document we use the 160 phrase "new routers" to refer to the routers that understand the 161 alternate-ECN semantics, and "old routers" to refer to routers that 162 don't understand or aren't willing to use the alternate-ECN 163 semantics. 165 The possible existence of old routers raises the following question: 166 How does the possible presence of old routers affect the performance 167 of the alternate-ECN connections? 169 (3) The possible existence of old routers also raises the question 170 of how the presence of old routers affects the co-existence of the 171 alternate-ECN traffic with competing traffic on the path. 173 Issues (2) and (3) are discussed in Section 4 below. 175 (4) A final issue is that of the general evaluation of the 176 alternate-ECN semantics: 178 How well does the alternate-ECN traffic perform, and how well does 179 it co-exist with competing traffic on the path, in a "clean" 180 environment with new routers and with the unambiguous specification 181 of the use of alternate-ECN semantics? 183 These issues are discussed in Section 5 below. 185 3. Signalling the Use of Alternate ECN Semantics 187 This section discusses question (1) from Section 2: 189 (1) How does the connection indicate to the router that its packets 190 are using alternate-ECN semantics? Is the specification of 191 alternate-ECN semantics robust and unambiguous? If not, is this a 192 problem? 194 The assumption of this document is that when alternate semantics are 195 defined for the ECN field, a codepoint in the diffserv field is used 196 to signal the use of these alternate ECN semantics to the router. 197 That is, the end host sets the codepoint in the diffserv field to 198 indicate to routers that alternate semantics to the ECN field are 199 being used. Routers that understand this diffserv codepoint would 200 know to use the alternate semantics for interpreting and setting the 201 ECN field. Old ECN-capable routers that do not understand this 202 diffserv codepoint would use the default ECN semantics in 203 interpreting and setting the ECN field. 205 In general, the diffserv codepoints are used to signal the per-hop 206 behavior at router queues. One possibility would be to use one 207 diffserv codepoint to signal a per-hop behavior with the default ECN 208 semantics, and a separate diffserv codepoint to signal a similar 209 per-hop behavior with the alternate ECN semantics. Another 210 possibility would be to use a diffserv codepoint to signal the use 211 of best-effort per-hop queueing and scheduling behavior, but with 212 alternate ECN semantics. A detailed discussion of these issues is 213 beyond the scope of this document. 215 We note that this discussion does not exclude the possibility of 216 using other methods, including out-of-band mechanisms, for 217 signalling the use of alternate semantics for the ECN field. The 218 considerations in the rest of this document apply regardless of the 219 method used to signal the use of alternate semantics for the ECN 220 field. 222 3.1. Using the Diffserv Field for Signalling 224 We note that the default ECN semantics defined in RFC 3168 are the 225 current default semantics for the ECN field, regardless of the 226 contents of any other fields in the IP header. In particular, the 227 default ECN semantics apply for more than best-effort traffic with a 228 codepoint of '000000' for the diffserv field - the default ECN 229 semantics currently apply regardless of the contents of the diffserv 230 field. 232 There are two ways to use the diffserv field to signal the use of 233 alternate ECN semantics. One way is to use an existing diffserv 234 codepoint, and to modify the current definition of that codepoint, 235 through approved IETF processes, to specify the use of alternate ECN 236 semantics with that codepoint. A second way is to define a new 237 diffserv codepoint, and to specify the use of alternate ECN 238 semantics with that codepoint. We note that the first of these two 239 mechanisms raises the possibility that some routers along the path 240 will understand the diffserv codepoint but will use the default ECN 241 semantics with this diffserv codepoint, or won't use ECN at all, and 242 that other routers will use the alternate ECN semantics with this 243 diffserv codepoint. 245 4. Issues of Incremental Deployment 247 This section discusses questions (2) and (3) posed in Section 2: 249 (2) How does the possible presence of old routers affect the 250 performance of the alternate-ECN connections? 252 (3) How does the possible presence of old routers affect the co- 253 existence of the alternate-ECN traffic with competing traffic on the 254 path? 256 When alternate semantics are defined for the ECN field, it is 257 necessary to ensure that there are no problems caused by old routers 258 along the path that don't understand the alternate ECN semantics. 260 One possible problem is that of poor performance for the alternate- 261 ECN traffic. Is it essential to the performance of the alternate- 262 ECN traffic that all routers along the path understand the 263 alternate-ECN semantics? If not, what are the possible 264 consequences, for the alternate-ECN traffic itself, when some old 265 routers along the path don't understand the alternate-ECN semantics? 266 These issues have to be answered in the context of each specific 267 proposal for alternate ECN semantics. 269 A second specific problem is that of possible unfair competition 270 with other traffic along the path. If there is an old router along 271 the path that doesn't use ECN, that old router could drop packets 272 from the alternate-ECN traffic, and expect the alternate-ECN traffic 273 to reduce its sending rate as a result. Does the alternate-ECN 274 traffic respond to packet drops as an indication of congestion? 275 |--------| 276 Alternate-ECN traffic ----> | | ---> CE-marked packet 277 | Old | 278 Non-ECN traffic ----------> | Router | ---> dropped packet 279 | | 280 RFC-3168 ECN traffic -----> | | ---> CE-marked packet 281 |--------| 283 Figure 1: Alternate-ECN traffic, an old router using RFC-3168 ECN. 285 Similarly, what if there is an old router along the path that 286 understands only the default ECN semantics from RFC-3168, as in 287 Figure 1 above? In times of congestion, the old default-ECN router 288 could see an alternate-ECN packet with one of the ECN-Capable 289 Transport (ECT) codepoints set in the ECN field in the IP header, as 290 defined in RFC 3168, and set the Congestion Experienced (CE) 291 codepoint in the ECN field as an alternative to dropping the packet. 292 The router in this case would expect the alternate-ECN connection to 293 respond, in terms of congestion control, as it would if the packet 294 has been dropped. If the alternate-ECN traffic fails to respond 295 appropriately to the CE codepoint being set by an old router, this 296 could increase the aggregate traffic arriving at the old router, 297 resulting in an increase in the packet-marking and packet-dropping 298 rates at that router, further resulting in the alternate-ECN traffic 299 crowding out the other traffic competing for bandwidth on that link. 301 Basically, there are three possibilities for avoiding scenarios 302 where the presence of old routers along the path results in the 303 alternate-ECN traffic competing unfairly with other traffic along 304 the path: 306 Option 1: Alternate-ECN traffic is clearly understood as unsafe for 307 deployment in the global Internet; or 309 Option 2: All alternate-ECN traffic deploys some mechanism for 310 verifying that all routers on the path understand and agree to use 311 the alternate ECN semantics for this traffic; or 313 Option 3: The alternate-ECN semantics are defined in such a way as 314 to ensure the fair and peaceful co-existence of the alternate-ECN 315 traffic with best-effort and other traffic, even in environments 316 that include old routers that do not understand the alternate-ECN 317 semantics. 319 Each of these alternatives is explored in more detail below. 321 4.1. Option 1: Unsafe for Deployment in the Internet 323 The first option specified above is for the alternate-ECN traffic to 324 be clearly understood as only suitable for enclosed environments, 325 and as unsafe for deployment in the global Internet. This would 326 mean that it would be unsafe for packets using the alternate ECN 327 semantics to be unleashed in the global Internet, in order to avoid 328 the chance of the alternate-ECN traffic traversing an old router 329 that don't understand the alternate semantics. This document 330 doesn't comment on whether a mechanism would be required to ensure 331 that the alternate-ECN semantics would not be let loose on the 332 global Internet. This document also doesn't comment on the chances 333 that this scenario would be considered acceptable for 334 standardization by the IETF community. 336 4.2. Option 2: Verification that Routers Understand the Alternate 337 Semantics 339 The second option specified above is for the alternate-ECN traffic 340 to include a mechanism for ensuring that all routers along the path 341 understand and agree to the use of the alternate ECN semantics for 342 this traffic. As an example, such a mechanism could consist of a 343 field in an IP option that all routers along the path decrement if 344 they agree to use the alternate ECN semantics with this traffic. (A 345 similar mechanism is proposed for Quick-Start, for verifying that 346 all of the routers along the path understand the Quick-Start IP 347 Option [QuickStart].) Using such a mechanism, a sender could have 348 reasonable assurance that the packets that are sent specifying the 349 use of alternate ECN semantics only traverse routers that in fact 350 understand and agree to use these alternate semantics for these 351 packets. 353 Such a mechanism should be robust in the presence of paths with 354 multi-path routing, and in the presence of routing or configuration 355 changes along the path while the connection is in use. In 356 particular, if this option is used, connections could include some 357 form of monitoring for changes in path behavior, and/or periodic 358 monitoring that all routers along the path continue to understand 359 the alternate-ECN semantics. 361 4.3. Option 3: Friendly Co-existence with Competing Traffic 363 The third option specified above is for the alternate ECN semantics 364 to be defined so that traffic using the alternate semantics would 365 co-exist safely in the Internet on a path with one or more old 366 routers that use only the default ECN semantics. In this scenario, 367 a connection sending alternate-ECN traffic would have to respond 368 appropriately to a CE packet (a packet with the ECN codepoint "11") 369 received at the receiver, using a conformant congestion control 370 response. Hopefully, the connection sending alternate-ECN traffic 371 would also respond appropriately to a dropped packet, that could be 372 a congestion indication from a router that doesn't use ECN. 374 RFC 3168 defines the default ECN semantics as follows: 376 "Upon the receipt by an ECN-Capable transport of a single CE packet, 377 the congestion control algorithms followed at the end-systems MUST 378 be essentially the same as the congestion control response to a 379 *single* dropped packet. For example, for ECN-Capable TCP the 380 source TCP is required to halve its congestion window for any window 381 of data containing either a packet drop or an ECN indication." 383 The only conformant congestion control mechanisms currently 384 standardized in the IETF are TCP [RFC2581] and protocols using TCP- 385 like congestion control (e.g., SCTP [RFC2960], DCCP with CCID-2 386 [DCCP]), and TCP-Friendly Rate Control (TFRC) and protocols with 387 TFRC-like congestion control (e.g., DCCP using CCID-3 [DCCP]). TCP 388 uses Additive-Increase Multiplicative-Decrease congestion control, 389 and responds to the loss or ECN-marking of a single packet by 390 halving its congestion window. In contrast, the equation-based 391 congestion control mechanism in TFRC estimates the loss event rate 392 over some period of time, and uses a sending rate that would be 393 comparable, in packets per round-trip-time, to that of a TCP 394 connection experiencing the same loss event rate. 396 So what are the requirements in order for alternate-ECN traffic to 397 compete appropriately with other traffic on a path through an old 398 router that doesn't understand the alternate ECN semantics (and 399 therefore might be using the default ECN semantics)? The first and 400 second requirements below concern compatibility between traffic 401 using alternate ECN semantics and routers using default ECN 402 semantics. 404 The first requirement for compatibility with routers using default 405 ECN is that if a packet is marked with the ECN codepoint "11" in the 406 network, this marking is not changed on the packet's way to the 407 receiver (unless the packet is dropped before it reaches the 408 receiver). This requirement is necessary to ensure that congestion 409 indications from a default-ECN router make it to the transport 410 receiver. 412 A second requirement for compatibility with routers using default 413 ECN is that the end-nodes respond to packets that are marked with 414 the ECN codepoint "11" in a way that is friendly to flows using 415 IETF-conformant congestion control. This requirement is needed 416 because the "11"-marked packets might have come from a congested 417 router that understands only the default ECN semantics, and that 418 expects that end-nodes will respond appropriately to CE packets. 419 This requirement would ensure that the traffic using the alternate 420 semantics does not `bully' competing traffic that it might encounter 421 along the path, and does not drive up congestion on the shared link 422 inappropriately. 424 Additional requirements concern compatibility between traffic using 425 default ECN semantics and routers using alternate ECN semantics. 426 This situation could occur if a diff-serv codepoint using default 427 ECN semantics is redefined to use alternate ECN semantics, and 428 traffic from an "old" source traverses a "new" router. If the 429 router "knows" that a packet is from a sender using alternate 430 semantics (e.g., because the packet is using a certain diff-serv 431 codepoint, and all packets with that diff-serv codepoint use 432 alternate semantics for the ECN field), then the requirements below 433 are not necessary, and the rules for the alternate semantics apply. 435 A requirement for compatibility with end-nodes using default ECN is 436 that if a packet that *could* be using default semantics is marked 437 with the ECN codepoint "00", this marking must not be changed to 438 "01", "10", or "11" in the network. This prevents the packet from 439 being represented incorrectly to a default ECN router downstream as 440 ECN-Capable. Similarly, if a packet that *could* be using default 441 semantics is marked with the ECN codepoint "01", then this codepoint 442 should not be changed to "10" in the network (and a "10" codepoint 443 should not be changed to "01"). This requirement is necessary to 444 avoid interference with the transport protocol's use of the ECN 445 nonce [RFC3540]. 447 As discussed earlier, the current conformant congestion control 448 responses to a dropped or default-ECN-marked packet consist of TCP 449 and TCP-like congestion control, and of TFRC (TCP-Friendly Rate 450 Control). Another possible response considered in RFC 3714, but not 451 standardized in a standards-track document, is that of simply 452 terminating an alternate-ECN connection for a period of time if the 453 long-term sending rate is higher than would be that of a TCP 454 connection experiencing the same packet dropping or marking rates 455 [RFC3714]. We note that the use of such a congestion control 456 response to CE-marked packets would require specification of time 457 constants for measuring the loss rates and for stopping 458 transmission, and would require a consideration of issues of packet 459 size. 461 5. Evaluation of the Alternate-ECN Semantics 463 This section discusses question (4) posed in Section 2: 465 (4) How well does the alternate-ECN traffic perform, and how well 466 does it co-exist with competing traffic on the path, in a "clean" 467 environment with new routers and with the unambiguous specification 468 of the use of alternate-ECN semantics? 470 5.1. Verification of Feedback from the Router 472 One issue in evaluating the alternate-ECN semantics concerns 473 mechanisms to discourage lying from the transport receiver to the 474 transport sender. In many cases the sender is a server that has an 475 interest in using the alternate-ECN semantics correctly, while the 476 receiver has more incentives for lying about the congestion 477 experienced along the path. 479 In the default ECN semantics, two of the four ECN codepoints are 480 used for ECN-Capable(0) and ECN-Capable(1). The use of two 481 codepoints for ECN-Capable, instead of one, permits the data sender 482 to verify receiver's reports that packets were actually received 483 unmarked at the receiver. In particular, the sender can specify 484 that the receiver report to the sender whether each unmarked packet 485 was received ECN-Capable(0) or ECN-Capable(1), as discussed in RFC 486 3540 [RFC 3540]. This use of ECN-Capable(0) and ECN-Capable(1) is 487 independent of the semantics of the other ECN codepoints, and could 488 be used, if desired, with alternate semantics for the other 489 codepoints. 491 If alternate semantics for the ECN codepoint don't include the use 492 of two separate codepoints to indicate ECN-Capable, then the 493 connections using those semantics have lost the ability to verify 494 that the data receiver is accurately reporting the received ECN 495 codepoint to the data sender. In this case, it might be necessary 496 for the alternate-ECN framework to include alternate mechanisms for 497 ensuring that the data receiver is reporting feedback appropriately 498 to the sender. As one possibility, policers could be used in 499 routers to ensure that end nodes are responding appropriately to 500 marked packets. 502 5.2. Co-existence with Competing Traffic 504 A second general issue concerns the co-existence of alternate-ECN 505 traffic with competing traffic along the path, in a clean 506 environment where all routers understand and are willing to use the 507 alternate-ECN semantics for the traffic that specifies its use. 509 If the traffic using the alternate-ECN semantics is best-effort 510 traffic, then it is subject to the general requirement of fair 511 competition with TCP and other traffic along the path [RFC2914]. 513 If the traffic using the alternate-ECN semantics is diffserv 514 traffic, then the requirements are governed by the overall 515 guidelines for that class of diffserv traffic. It is beyond the 516 scope of this document to specify the requirements, if any, for the 517 co-existence of diffserv traffic with other traffic on the link; 518 this should be addressed in the specification of the diffserv 519 codepoint itself. 521 5.3. Proposals for Alternate-ECN with Edge-to-Edge Semantics 523 RFC 3168 specifies the use of the default ECN semantics by an end- 524 to-end transport protocol, with the requirement that "upon the 525 receipt by an ECN-Capable transport of a single CE packet, the 526 congestion control algorithms followed at the end-systems MUST be 527 essentially the same as the congestion control response to a 528 *single* dropped packet" [RFC3168, Section 5]. In contrast, some of 529 the proposals for alternate-ECN semantics are for ECN used in an 530 edge-to-edge context between gateways at the edge of a network 531 region, e.g., for pre-congestion notification for admissions control 532 [BESFC05]. 534 When alternate-ECN is defined with edge-to-edge semantics, this 535 definition needs to ensure that the edge-to-edge semantics do not 536 conflict with a connection using other ECN semantics end-to-end. 537 One way to avoid conflict would be for the edge-to-edge ECN proposal 538 to include some mechanism to ensure that the edge-to-edge ECN is not 539 used for connections that are using other ECN semantics (standard or 540 otherwise) end-to-end. Alternately, the edge-to-edge semantics 541 could be defined so that they do not conflict with a connection 542 using other ECN semantics end-to-end. 544 5.4. A General Evaluation of the Alternate-ECN Semantics 546 A third general issue concerns the evaluation of the general merits 547 of the proposed alternate-ECN semantics. Again, it would be beyond 548 the scope of this document to specify requirements for the general 549 evaluation of alternate-ECN semantics. 551 6. Who Wants to Use Alternate Semantics for the ECN Codepoint? 553 There have been a number of proposals in the IETF and in the 554 research community for alternate semantics for the ECN codepoint 555 [ECN]. One such proposal, [BCF05], proposes an alternate-ECN 556 semantics for real-time inelastic traffic such as voice, video 557 conferencing, and multimedia streaming in DiffServ networks. In 558 this proposal, the alternate-ECN semantics would provide information 559 about two levels of congestion experienced along the path [BCF05]. 560 Some of the other proposals for alternate ECN semantics are listed 561 on the ECN Web Page [ECN]. 563 7. Security Considerations 565 This document doesn't propose any new mechanisms for the Internet 566 protocol, and therefore doesn't introduce any new security 567 considerations. 569 8. Acknowledgements 571 This document is based in part on conversations with Jozef Babiarz, 572 Kwok Ho Chan, and Victor Firoiu on their proposal for an alternate 573 use of the ECN field in DiffServ environments. Many thanks to 574 Francois Le Faucheur for feedback recommending that the document 575 include a section at the beginning discussing the potential issues 576 that need to be addressed. Thanks also to Mark Allman, Fred Baker, 577 David Black, Gorry Fairhurst, and to members of the TSVWG working 578 group for feedback on these issues. 580 9. Conclusions 582 This document has discussed some of the issues to be considered in 583 the specification of alternate semantics for the ECN field in the IP 584 header. 586 10. Normative References 588 11. Informative References 590 [BCF05] J. Babiarz, K. Chan, and V. Firoiu, Congestion Notification 591 Process for Real-Time Traffic, internet-draft draft-babiarz-tsvwg- 592 rtecn-04, work in progress, July 2005. 594 [BESFC05] B. Briscoe, P. Eardley, D. Songhurst, F. Le Faucheur, A. 595 Charny, J. Barbiaz, K. Chan, A Framework for Admission Control over 596 DiffServ using Pre-Congestion Notification, internet-draft draft- 597 briscoe-tsvwg-cl-architecture-01.txt, work in progress, October 598 2005. 600 [DCCP] DCCP Web Page, URL "http://www.icir.org/kohler/dccp/". 602 [ECN] ECN Web Page, URL "www.icir.org/floyd/ecn.html". 604 [QuickStart] Quick-Start Web Page, URL 605 "http://www.icir.org/floyd/quickstart.html". 607 [RFC2581] M. Allman, V. Paxson, and W. Stevens, TCP Congestion 608 Control, RFC 2581, Proposed Standard, April 1999. 610 [RFC2914] S. Floyd, Congestion Control Principles, RFC 2914, Best 611 Current Practice, September 2000. 613 [RFC2960] R. Stewart et al, Stream Control Transmission Protocol, 614 RFC 2960, October 2000. 616 [RFC3168] Ramakrishnan, K.K., Floyd, S., and Black, D., The Addition 617 of Explicit Congestion Notification (ECN) to IP, RFC 3168, Proposed 618 Standard, September 2001. 620 [RFC3540] N. Spring, D. Wetherall, and D. Ely, Robust Explicit 621 Congestion Notification (ECN) Signaling with Nonces, RFC 3540, 622 Experimental, June 2003. 624 [RFC3714] S. Floyd and J. Kempf, Editors, IAB Concerns Regarding 625 Congestion Control for Voice Traffic in the Internet, RFC 3714, 626 Informational, March 2004. 628 IANA Considerations 630 There are no IANA considerations in this document. 632 AUTHORS' ADDRESSES 634 Sally Floyd 635 Phone: +1 (510) 666-2989 636 ICIR (ICSI Center for Internet Research) 637 Email: floyd@icir.org 638 URL: http://www.icir.org/floyd/ 640 Full Copyright Statement 642 This document is subject to the rights, licenses and restrictions 643 contained in BCP 78, and except as set forth therein, the authors 644 retain all their rights. 646 This document and the information contained herein are provided on 647 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 648 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 649 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 650 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 651 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 652 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 654 Intellectual Property 656 The IETF takes no position regarding the validity or scope of any 657 Intellectual Property Rights or other rights that might be claimed 658 to pertain to the implementation or use of the technology described 659 in this document or the extent to which any license under such 660 rights might or might not be available; nor does it represent that 661 it has made any independent effort to identify any such rights. 662 Information on the procedures with respect to rights in RFC 663 documents can be found in BCP 78 and BCP 79. 665 Copies of IPR disclosures made to the IETF Secretariat and any 666 assurances of licenses to be made available, or the result of an 667 attempt made to obtain a general license or permission for the use 668 of such proprietary rights by implementers or users of this 669 specification can be obtained from the IETF on-line IPR repository 670 at http://www.ietf.org/ipr. 672 The IETF invites any interested party to bring to its attention any 673 copyrights, patents or patent applications, or other proprietary 674 rights that may cover technology that may be required to implement 675 this standard. Please address the information to the IETF at ietf- 676 ipr@ietf.org.