idnits 2.17.1 draft-ietf-tsvwg-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 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 685. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 696. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 703. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 709. ** 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 ([RFC3168]), 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 405: '...ithms followed at the end-systems MUST...' RFC 2119 keyword, line 555: '...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 (27 July 2006) is 6483 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) == 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-03 == Outdated reference: A later version (-07) exists of draft-ietf-tsvwg-quickstart-05 -- Obsolete informational reference (is this intentional?): RFC 2581 (Obsoleted by RFC 5681) -- Obsolete informational reference (is this intentional?): RFC 2960 (Obsoleted by RFC 4960) -- Obsolete informational reference (is this intentional?): RFC 3448 (Obsoleted by RFC 5348) Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 10 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-01.txt 27 July 2006 4 Expires: January 2007 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 January 2007. 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 [RFC3168]. This document discusses 42 some of the issues in defining alternate semantics for the ECN 43 field, and specifies requirements for a safe co-existence in an 44 Internet that could include routers that do not understand the 45 defined alternate semantics. This document evolved as a result of 46 discussions with the authors of one recent proposal for such 47 alternate semantics. 49 NOTE TO RFC EDITOR: PLEASE DELETE THIS NOTE UPON PUBLICATION. 51 Changes from draft-ietf-tsvwg-ecn-alternates-01.txt: 53 * Updated references, moved a paragraph to the Introduction. 54 Based on feedback from the IESG. 56 Changes from draft-ietf-tsvwg-ecn-alternates-00.txt: 58 * Added a pointer to the SIGCOMM 2005 paper on "One More Bit 59 is Enough". 61 Changes from draft-floyd-ecn-alternates-02.txt: 63 * Added a subsection on proposals for edge-to-edge ECN. 65 * Changed name to draft-ietf-tsvwg-ecn-alternates-00. 67 Changes from draft-floyd-ecn-alternates-01.txt: 69 * Changed requirement for TCP friendliness, to a requirement of 70 friendliness with IETF-conformant congestion control. From email 71 from Mark Allman. 73 * Added to discussion of robustness to route changes. From email 74 from Mark Allman. 76 * Added an explicit note that the ECN nonce is agnostic to the 77 semantics of the other codepoints, and could be used with alternate 78 ECN semantics. 80 * Minor editing, from email from Mark Allman. 82 Changes from draft-floyd-ecn-alternates-00.txt: 84 * Added requirements for compatibility between traffic using default 85 ECN semantics and routers using alternate ECN semantics, to the 86 section on "Option 3: Friendly Co-existence with Competing 87 Traffic". From email from Gorry Fairhurst. 89 * Added to the discussion of using the diffserv code point to signal 90 alternate ECN semantics. From email from Gorry Fairhurst. 92 * Minor editing for clarity, also from email from Gorry Fairhurst. 94 END OF NOTE TO RFC EDITOR. 96 Table of Contents 98 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3 99 2. An Overview of the Issues . . . . . . . . . . . . . . . . . . 4 100 3. Signalling the Use of Alternate ECN Semantics . . . . . . . . 5 101 3.1. Using the Diffserv Field for Signalling. . . . . . . . . 6 102 4. Issues of Incremental Deployment. . . . . . . . . . . . . . . 6 103 4.1. Option 1: Unsafe for Deployment in the 104 Internet. . . . . . . . . . . . . . . . . . . . . . . . . . . 8 105 4.2. Option 2: Verification that Routers Under- 106 stand the Alternate Semantics . . . . . . . . . . . . . . . . 8 107 4.3. Option 3: Friendly Co-existence with Com- 108 peting Traffic. . . . . . . . . . . . . . . . . . . . . . . . 9 109 5. Evaluation of the Alternate-ECN Semantics . . . . . . . . . . 11 110 5.1. Verification of Feedback from the Router . . . . . . . . 11 111 5.2. Co-existence with Competing Traffic. . . . . . . . . . . 12 112 5.3. Proposals for Alternate-ECN with Edge-to- 113 Edge Semantics. . . . . . . . . . . . . . . . . . . . . . . . 12 114 5.4. A General Evaluation of the Alternate-ECN 115 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . 13 116 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 117 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 13 118 8. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 13 119 9. Normative References. . . . . . . . . . . . . . . . . . . . . 14 120 10. Informative References . . . . . . . . . . . . . . . . . . . 14 121 IANA Considerations. . . . . . . . . . . . . . . . . . . . . . . 15 122 AUTHORS' ADDRESSES . . . . . . . . . . . . . . . . . . . . . . . 15 123 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 15 124 Intellectual Property. . . . . . . . . . . . . . . . . . . . . . 15 126 1. Introduction 128 RFC 3168, a Proposed Standard document, defines the ECN field in the 129 IP header, and specifies the semantics for the codepoints for the 130 ECN field. However, end nodes could specify the use of alternate 131 semantics for the ECN field, e.g., using codepoints in the diffserv 132 field of the IP header. 134 There have been a number of proposals in the IETF and in the 135 research community for alternate semantics for the ECN codepoint. 136 One such proposal, [BCF05], proposes an alternate-ECN semantics for 137 real-time inelastic traffic such as voice, video conferencing, and 138 multimedia streaming in DiffServ networks. In this proposal, the 139 alternate-ECN semantics would provide information about two levels 140 of congestion experienced along the path [BCF05]. Another research 141 proposal, [XSSK05], proposes a low-complexity protocol, Variable- 142 structure congestion Control Protocol (VCP), that uses the two bits 143 in the ECN field to indicate low-load, high-load, and overload 144 (congestion), where transport protocols can increase more rapidly 145 during the low-load regime. Some of the proposals for alternate-ECN 146 semantics are for ECN used in an edge-to-edge context between 147 gateways at the edge of a network region, e.g., for pre-congestion 148 notification for admissions control [BESFC06]. Other proposals for 149 alternate ECN semantics are listed on the ECN Web Page [ECN]. 151 This document describes some of the issues that arise in specifying 152 alternate semantics for the ECN field, and gives requirements for a 153 safe co-existence in a world using the default ECN semantics (or 154 using no ECN at all). 156 2. An Overview of the Issues 158 In this section we discuss some of the issues that arise if some of 159 the traffic in a network consists of alternate-ECN traffic (i.e., 160 traffic using alternate semantics for the ECN field). The issues 161 include the following: (1) how routers know which ECN semantics to 162 use with which packets; (2) incremental deployment in a network 163 where some routers use only the default ECN semantics, or no ECN at 164 all; (3) co-existence of alternate-ECN traffic with competing 165 traffic on the path; and (4) a general evaluation of the alternate- 166 ECN semantics. 168 (1) The first issue concerns how routers know which ECN semantics to 169 use with which packets in the network: 171 How does the connection indicate to the router that its packets are 172 using alternate-ECN semantics? Is the specification of alternate- 173 ECN semantics robust and unambiguous? If not, is this a problem? 175 As an example, in most of the proposals for alternate-ECN semantics, 176 a diffserv field is used to specify the use of alternate-ECN 177 semantics. Do all routers that understand this diffserv codepoint 178 understand that it uses alternate-ECN semantics, or not? Diffserv 179 allows routers to re-mark DiffServ Code Point (DSCP) values within 180 the network; what is the effect of this on the alternate-ECN 181 semantics? 183 This is discussed in more detail in Section 3 below. 185 (2) A second issue is that of incremental deployment in a network 186 where some routers only use the default ECN semantics, and other 187 routers might not use ECN at all. In this document we use the 188 phrase "new routers" to refer to the routers that understand the 189 alternate-ECN semantics, and "old routers" to refer to routers that 190 don't understand or aren't willing to use the alternate-ECN 191 semantics. 193 The possible existence of old routers raises the following question: 194 How does the possible presence of old routers affect the performance 195 of the alternate-ECN connections? 197 (3) The possible existence of old routers also raises the question 198 of how the presence of old routers affects the co-existence of the 199 alternate-ECN traffic with competing traffic on the path. 201 Issues (2) and (3) are discussed in Section 4 below. 203 (4) A final issue is that of the general evaluation of the 204 alternate-ECN semantics: 206 How well does the alternate-ECN traffic perform, and how well does 207 it co-exist with competing traffic on the path, in a "clean" 208 environment with new routers and with the unambiguous specification 209 of the use of alternate-ECN semantics? 211 These issues are discussed in Section 5 below. 213 3. Signalling the Use of Alternate ECN Semantics 215 This section discusses question (1) from Section 2: 217 (1) How does the connection indicate to the router that its packets 218 are using alternate-ECN semantics? Is the specification of 219 alternate-ECN semantics robust and unambiguous? If not, is this a 220 problem? 222 The assumption of this document is that when alternate semantics are 223 defined for the ECN field, a codepoint in the diffserv field is used 224 to signal the use of these alternate ECN semantics to the router. 225 That is, the end host sets the codepoint in the diffserv field to 226 indicate to routers that alternate semantics to the ECN field are 227 being used. Routers that understand this diffserv codepoint would 228 know to use the alternate semantics for interpreting and setting the 229 ECN field. Old ECN-capable routers that do not understand this 230 diffserv codepoint would use the default ECN semantics in 231 interpreting and setting the ECN field. 233 In general, the diffserv codepoints are used to signal the per-hop 234 behavior at router queues. One possibility would be to use one 235 diffserv codepoint to signal a per-hop behavior with the default ECN 236 semantics, and a separate diffserv codepoint to signal a similar 237 per-hop behavior with the alternate ECN semantics. Another 238 possibility would be to use a diffserv codepoint to signal the use 239 of best-effort per-hop queueing and scheduling behavior, but with 240 alternate ECN semantics. A detailed discussion of these issues is 241 beyond the scope of this document. 243 We note that this discussion does not exclude the possibility of 244 using other methods, including out-of-band mechanisms, for 245 signalling the use of alternate semantics for the ECN field. The 246 considerations in the rest of this document apply regardless of the 247 method used to signal the use of alternate semantics for the ECN 248 field. 250 3.1. Using the Diffserv Field for Signalling 252 We note that the default ECN semantics defined in RFC 3168 are the 253 current default semantics for the ECN field, regardless of the 254 contents of any other fields in the IP header. In particular, the 255 default ECN semantics apply for more than best-effort traffic with a 256 codepoint of '000000' for the diffserv field - the default ECN 257 semantics currently apply regardless of the contents of the diffserv 258 field. 260 There are two ways to use the diffserv field to signal the use of 261 alternate ECN semantics. One way is to use an existing diffserv 262 codepoint, and to modify the current definition of that codepoint, 263 through approved IETF processes, to specify the use of alternate ECN 264 semantics with that codepoint. A second way is to define a new 265 diffserv codepoint, and to specify the use of alternate ECN 266 semantics with that codepoint. We note that the first of these two 267 mechanisms raises the possibility that some routers along the path 268 will understand the diffserv codepoint but will use the default ECN 269 semantics with this diffserv codepoint, or won't use ECN at all, and 270 that other routers will use the alternate ECN semantics with this 271 diffserv codepoint. 273 4. Issues of Incremental Deployment 275 This section discusses questions (2) and (3) posed in Section 2: 277 (2) How does the possible presence of old routers affect the 278 performance of the alternate-ECN connections? 279 (3) How does the possible presence of old routers affect the co- 280 existence of the alternate-ECN traffic with competing traffic on the 281 path? 283 When alternate semantics are defined for the ECN field, it is 284 necessary to ensure that there are no problems caused by old routers 285 along the path that don't understand the alternate ECN semantics. 287 One possible problem is that of poor performance for the alternate- 288 ECN traffic. Is it essential to the performance of the alternate- 289 ECN traffic that all routers along the path understand the 290 alternate-ECN semantics? If not, what are the possible 291 consequences, for the alternate-ECN traffic itself, when some old 292 routers along the path don't understand the alternate-ECN semantics? 293 These issues have to be answered in the context of each specific 294 proposal for alternate ECN semantics. 296 A second specific problem is that of possible unfair competition 297 with other traffic along the path. If there is an old router along 298 the path that doesn't use ECN, that old router could drop packets 299 from the alternate-ECN traffic, and expect the alternate-ECN traffic 300 to reduce its sending rate as a result. Does the alternate-ECN 301 traffic respond to packet drops as an indication of congestion? 303 |--------| 304 Alternate-ECN traffic ----> | | ---> CE-marked packet 305 | Old | 306 Non-ECN traffic ----------> | Router | ---> dropped packet 307 | | 308 RFC-3168 ECN traffic -----> | | ---> CE-marked packet 309 |--------| 311 Figure 1: Alternate-ECN traffic, an old router using RFC-3168 ECN. 313 Similarly, what if there is an old router along the path that 314 understands only the default ECN semantics from RFC-3168, as in 315 Figure 1 above? In times of congestion, the old default-ECN router 316 could see an alternate-ECN packet with one of the ECN-Capable 317 Transport (ECT) codepoints set in the ECN field in the IP header, as 318 defined in RFC 3168, and set the Congestion Experienced (CE) 319 codepoint in the ECN field as an alternative to dropping the packet. 320 The router in this case would expect the alternate-ECN connection to 321 respond, in terms of congestion control, as it would if the packet 322 has been dropped. If the alternate-ECN traffic fails to respond 323 appropriately to the CE codepoint being set by an old router, this 324 could increase the aggregate traffic arriving at the old router, 325 resulting in an increase in the packet-marking and packet-dropping 326 rates at that router, further resulting in the alternate-ECN traffic 327 crowding out the other traffic competing for bandwidth on that link. 329 Basically, there are three possibilities for avoiding scenarios 330 where the presence of old routers along the path results in the 331 alternate-ECN traffic competing unfairly with other traffic along 332 the path: 334 Option 1: Alternate-ECN traffic is clearly understood as unsafe for 335 deployment in the global Internet; or 337 Option 2: All alternate-ECN traffic deploys some mechanism for 338 verifying that all routers on the path understand and agree to use 339 the alternate ECN semantics for this traffic; or 341 Option 3: The alternate-ECN semantics are defined in such a way as 342 to ensure the fair and peaceful co-existence of the alternate-ECN 343 traffic with best-effort and other traffic, even in environments 344 that include old routers that do not understand the alternate-ECN 345 semantics. 347 Each of these alternatives is explored in more detail below. 349 4.1. Option 1: Unsafe for Deployment in the Internet 351 The first option specified above is for the alternate-ECN traffic to 352 be clearly understood as only suitable for enclosed environments, 353 and as unsafe for deployment in the global Internet. This would 354 mean that it would be unsafe for packets using the alternate ECN 355 semantics to be unleashed in the global Internet, in order to avoid 356 the chance of the alternate-ECN traffic traversing an old router 357 that don't understand the alternate semantics. This document 358 doesn't comment on whether a mechanism would be required to ensure 359 that the alternate-ECN semantics would not be let loose on the 360 global Internet. This document also doesn't comment on the chances 361 that this scenario would be considered acceptable for 362 standardization by the IETF community. 364 4.2. Option 2: Verification that Routers Understand the Alternate 365 Semantics 367 The second option specified above is for the alternate-ECN traffic 368 to include a mechanism for ensuring that all routers along the path 369 understand and agree to the use of the alternate ECN semantics for 370 this traffic. As an example, such a mechanism could consist of a 371 field in an IP option that all routers along the path decrement if 372 they agree to use the alternate ECN semantics with this traffic. (A 373 similar mechanism is proposed for Quick-Start, for verifying that 374 all of the routers along the path understand the Quick-Start IP 375 Option [QuickStart].) Using such a mechanism, a sender could have 376 reasonable assurance that the packets that are sent specifying the 377 use of alternate ECN semantics only traverse routers that in fact 378 understand and agree to use these alternate semantics for these 379 packets. 381 Such a mechanism should be robust in the presence of paths with 382 multi-path routing, and in the presence of routing or configuration 383 changes along the path while the connection is in use. In 384 particular, if this option is used, connections could include some 385 form of monitoring for changes in path behavior, and/or periodic 386 monitoring that all routers along the path continue to understand 387 the alternate-ECN semantics. 389 4.3. Option 3: Friendly Co-existence with Competing Traffic 391 The third option specified above is for the alternate ECN semantics 392 to be defined so that traffic using the alternate semantics would 393 co-exist safely in the Internet on a path with one or more old 394 routers that use only the default ECN semantics. In this scenario, 395 a connection sending alternate-ECN traffic would have to respond 396 appropriately to a CE packet (a packet with the ECN codepoint "11") 397 received at the receiver, using a conformant congestion control 398 response. Hopefully, the connection sending alternate-ECN traffic 399 would also respond appropriately to a dropped packet, that could be 400 a congestion indication from a router that doesn't use ECN. 402 RFC 3168 defines the default ECN semantics as follows: 404 "Upon the receipt by an ECN-Capable transport of a single CE packet, 405 the congestion control algorithms followed at the end-systems MUST 406 be essentially the same as the congestion control response to a 407 *single* dropped packet. For example, for ECN-Capable TCP the 408 source TCP is required to halve its congestion window for any window 409 of data containing either a packet drop or an ECN indication." 411 The only conformant congestion control mechanisms currently 412 standardized in the IETF are TCP [RFC2581] and protocols using TCP- 413 like congestion control (e.g., SCTP [RFC2960], DCCP with CCID-2 414 ([RFC4340], [RFC4341])), and TCP-Friendly Rate Control (TFRC) 415 [RFC3448] and protocols with TFRC-like congestion control (e.g., 416 DCCP using CCID-3 [RFC4342]). TCP uses Additive-Increase 417 Multiplicative-Decrease congestion control, and responds to the loss 418 or ECN-marking of a single packet by halving its congestion window. 419 In contrast, the equation-based congestion control mechanism in TFRC 420 estimates the loss event rate over some period of time, and uses a 421 sending rate that would be comparable, in packets per round-trip- 422 time, to that of a TCP connection experiencing the same loss event 423 rate. 425 So what are the requirements in order for alternate-ECN traffic to 426 compete appropriately with other traffic on a path through an old 427 router that doesn't understand the alternate ECN semantics (and 428 therefore might be using the default ECN semantics)? The first and 429 second requirements below concern compatibility between traffic 430 using alternate ECN semantics and routers using default ECN 431 semantics. 433 The first requirement for compatibility with routers using default 434 ECN is that if a packet is marked with the ECN codepoint "11" in the 435 network, this marking is not changed on the packet's way to the 436 receiver (unless the packet is dropped before it reaches the 437 receiver). This requirement is necessary to ensure that congestion 438 indications from a default-ECN router make it to the transport 439 receiver. 441 A second requirement for compatibility with routers using default 442 ECN is that the end-nodes respond to packets that are marked with 443 the ECN codepoint "11" in a way that is friendly to flows using 444 IETF-conformant congestion control. This requirement is needed 445 because the "11"-marked packets might have come from a congested 446 router that understands only the default ECN semantics, and that 447 expects that end-nodes will respond appropriately to CE packets. 448 This requirement would ensure that the traffic using the alternate 449 semantics does not `bully' competing traffic that it might encounter 450 along the path, and does not drive up congestion on the shared link 451 inappropriately. 453 Additional requirements concern compatibility between traffic using 454 default ECN semantics and routers using alternate ECN semantics. 455 This situation could occur if a diff-serv codepoint using default 456 ECN semantics is redefined to use alternate ECN semantics, and 457 traffic from an "old" source traverses a "new" router. If the 458 router "knows" that a packet is from a sender using alternate 459 semantics (e.g., because the packet is using a certain diff-serv 460 codepoint, and all packets with that diff-serv codepoint use 461 alternate semantics for the ECN field), then the requirements below 462 are not necessary, and the rules for the alternate semantics apply. 464 A requirement for compatibility with end-nodes using default ECN is 465 that if a packet that *could* be using default semantics is marked 466 with the ECN codepoint "00", this marking must not be changed to 467 "01", "10", or "11" in the network. This prevents the packet from 468 being represented incorrectly to a default ECN router downstream as 469 ECN-Capable. Similarly, if a packet that *could* be using default 470 semantics is marked with the ECN codepoint "01", then this codepoint 471 should not be changed to "10" in the network (and a "10" codepoint 472 should not be changed to "01"). This requirement is necessary to 473 avoid interference with the transport protocol's use of the ECN 474 nonce [RFC3540]. 476 As discussed earlier, the current conformant congestion control 477 responses to a dropped or default-ECN-marked packet consist of TCP 478 and TCP-like congestion control, and of TFRC (TCP-Friendly Rate 479 Control). Another possible response considered in RFC 3714, but not 480 standardized in a standards-track document, is that of simply 481 terminating an alternate-ECN connection for a period of time if the 482 long-term sending rate is higher than would be that of a TCP 483 connection experiencing the same packet dropping or marking rates 484 [RFC3714]. We note that the use of such a congestion control 485 response to CE-marked packets would require specification of time 486 constants for measuring the loss rates and for stopping 487 transmission, and would require a consideration of issues of packet 488 size. 490 5. Evaluation of the Alternate-ECN Semantics 492 This section discusses question (4) posed in Section 2: 494 (4) How well does the alternate-ECN traffic perform, and how well 495 does it co-exist with competing traffic on the path, in a "clean" 496 environment with new routers and with the unambiguous specification 497 of the use of alternate-ECN semantics? 499 5.1. Verification of Feedback from the Router 501 One issue in evaluating the alternate-ECN semantics concerns 502 mechanisms to discourage lying from the transport receiver to the 503 transport sender. In many cases the sender is a server that has an 504 interest in using the alternate-ECN semantics correctly, while the 505 receiver has more incentives for lying about the congestion 506 experienced along the path. 508 In the default ECN semantics, two of the four ECN codepoints are 509 used for ECN-Capable(0) and ECN-Capable(1). The use of two 510 codepoints for ECN-Capable, instead of one, permits the data sender 511 to verify receiver's reports that packets were actually received 512 unmarked at the receiver. In particular, the sender can specify 513 that the receiver report to the sender whether each unmarked packet 514 was received ECN-Capable(0) or ECN-Capable(1), as discussed in RFC 515 3540 [RFC3540]. This use of ECN-Capable(0) and ECN-Capable(1) is 516 independent of the semantics of the other ECN codepoints, and could 517 be used, if desired, with alternate semantics for the other 518 codepoints. 520 If alternate semantics for the ECN codepoint don't include the use 521 of two separate codepoints to indicate ECN-Capable, then the 522 connections using those semantics have lost the ability to verify 523 that the data receiver is accurately reporting the received ECN 524 codepoint to the data sender. In this case, it might be necessary 525 for the alternate-ECN framework to include alternate mechanisms for 526 ensuring that the data receiver is reporting feedback appropriately 527 to the sender. As one possibility, policers could be used in 528 routers to ensure that end nodes are responding appropriately to 529 marked packets. 531 5.2. Co-existence with Competing Traffic 533 A second general issue concerns the co-existence of alternate-ECN 534 traffic with competing traffic along the path, in a clean 535 environment where all routers understand and are willing to use the 536 alternate-ECN semantics for the traffic that specifies its use. 538 If the traffic using the alternate-ECN semantics is best-effort 539 traffic, then it is subject to the general requirement of fair 540 competition with TCP and other traffic along the path [RFC2914]. 542 If the traffic using the alternate-ECN semantics is diffserv 543 traffic, then the requirements are governed by the overall 544 guidelines for that class of diffserv traffic. It is beyond the 545 scope of this document to specify the requirements, if any, for the 546 co-existence of diffserv traffic with other traffic on the link; 547 this should be addressed in the specification of the diffserv 548 codepoint itself. 550 5.3. Proposals for Alternate-ECN with Edge-to-Edge Semantics 552 RFC 3168 specifies the use of the default ECN semantics by an end- 553 to-end transport protocol, with the requirement that "upon the 554 receipt by an ECN-Capable transport of a single CE packet, the 555 congestion control algorithms followed at the end-systems MUST be 556 essentially the same as the congestion control response to a 557 *single* dropped packet" ([RFC3168], Section 5). In contrast, some 558 of the proposals for alternate-ECN semantics are for ECN used in an 559 edge-to-edge context between gateways at the edge of a network 560 region, e.g., [BESFC06]. 562 When alternate-ECN is defined with edge-to-edge semantics, this 563 definition needs to ensure that the edge-to-edge semantics do not 564 conflict with a connection using other ECN semantics end-to-end. 565 One way to avoid conflict would be for the edge-to-edge ECN proposal 566 to include some mechanism to ensure that the edge-to-edge ECN is not 567 used for connections that are using other ECN semantics (standard or 568 otherwise) end-to-end. Alternately, the edge-to-edge semantics 569 could be defined so that they do not conflict with a connection 570 using other ECN semantics end-to-end. 572 5.4. A General Evaluation of the Alternate-ECN Semantics 574 A third general issue concerns the evaluation of the general merits 575 of the proposed alternate-ECN semantics. Again, it would be beyond 576 the scope of this document to specify requirements for the general 577 evaluation of alternate-ECN semantics. 579 6. Security Considerations 581 This document doesn't propose any new mechanisms for the Internet 582 protocol, and therefore doesn't introduce any new security 583 considerations. 585 7. Conclusions 587 This document has discussed some of the issues to be considered in 588 the specification of alternate semantics for the ECN field in the IP 589 header. 591 8. Acknowledgements 593 This document is based in part on conversations with Jozef Babiarz, 594 Kwok Ho Chan, and Victor Firoiu on their proposal for an alternate 595 use of the ECN field in DiffServ environments. Many thanks to 596 Francois Le Faucheur for feedback recommending that the document 597 include a section at the beginning discussing the potential issues 598 that need to be addressed. Thanks also to Mark Allman, Fred Baker, 599 David Black, Gorry Fairhurst, and to members of the TSVWG working 600 group for feedback on these issues. 602 9. Normative References 604 [RFC3168] Ramakrishnan, K.K., Floyd, S., and Black, D., The Addition 605 of Explicit Congestion Notification (ECN) to IP, RFC 3168, Proposed 606 Standard, September 2001. 608 10. Informative References 610 [BCF05] J. Babiarz, K. Chan, and V. Firoiu, Congestion Notification 611 Process for Real-Time Traffic, expired internet-draft draft-babiarz- 612 tsvwg-rtecn-04, work in progress, July 2005. 614 [BESFC06] B. Briscoe, P. Eardley, D. Songhurst, F. Le Faucheur, A. 615 Charny, J. Barbiaz, K. Chan, A Framework for Admission Control over 616 DiffServ using Pre-Congestion Notification, internet-draft draft- 617 briscoe-tsvwg-cl-architecture-03.txt, work in progress, June 2006. 619 [ECN] ECN Web Page, URL "www.icir.org/floyd/ecn.html". 621 [QuickStart] S. Floyd, M. Allman, A. Jain, and P. Sarolahti, Quick- 622 Start for TCP and IP, Internet-draft draft-ietf-tsvwg- 623 quickstart-05.txt, work in progress, July 2006. 625 [RFC2581] M. Allman, V. Paxson, and W. Stevens, TCP Congestion 626 Control, RFC 2581, Proposed Standard, April 1999. 628 [RFC2914] S. Floyd, Congestion Control Principles, RFC 2914, Best 629 Current Practice, September 2000. 631 [RFC2960] R. Stewart et al, Stream Control Transmission Protocol, 632 RFC 2960, October 2000. 634 [RFC3448] Handley, M., Floyd, S., Pahdye, J., and Widmer, J. TCP 635 Friendly Rate Control (TFRC): Protocol Specification. RFC 3448, 636 Proposed Standard, January 2003. 638 [RFC3540] N. Spring, D. Wetherall, and D. Ely, Robust Explicit 639 Congestion Notification (ECN) Signaling with Nonces, RFC 3540, 640 Experimental, June 2003. 642 [RFC3714] S. Floyd and J. Kempf, Editors, IAB Concerns Regarding 643 Congestion Control for Voice Traffic in the Internet, RFC 3714, 644 Informational, March 2004. 646 [RFC4340] E. Kohler, M. Handley, and S. Floyd, Datagram Congestion 647 Control Protocol (DCCP), RFC 4340, Proposed Standard, March 2006. 649 [RFC4341] S. Floyd and E. Kohler, Profile for Datagram Congestion 650 Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion 651 Control, RFC 4341, Proposed Standard, March 2006. 653 [RFC4342] S. Floyd, E. Kohler, and J. Padhye, Profile for Datagram 654 Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP- 655 Friendly Rate Control (TFRC), RFC 4342, Proposed Standard, March 656 2006. 658 [XSSK05] Y. Xia, L. Subramanian, I. Stoica, and S. Kalyanaraman, 659 One More Bit Is Enough, SIGCOMM 2005, September 2005. 661 IANA Considerations 663 There are no IANA considerations in this document. 665 AUTHORS' ADDRESSES 667 Sally Floyd 668 Phone: +1 (510) 666-2989 669 ICIR (ICSI Center for Internet Research) 670 Email: floyd@icir.org 671 URL: http://www.icir.org/floyd/ 673 Full Copyright Statement 675 This document is subject to the rights, licenses and restrictions 676 contained in BCP 78, and except as set forth therein, the authors 677 retain all their rights. 679 This document and the information contained herein are provided on 680 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 681 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 682 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 683 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 684 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 685 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 687 Intellectual Property 689 The IETF takes no position regarding the validity or scope of any 690 Intellectual Property Rights or other rights that might be claimed 691 to pertain to the implementation or use of the technology described 692 in this document or the extent to which any license under such 693 rights might or might not be available; nor does it represent that 694 it has made any independent effort to identify any such rights. 695 Information on the procedures with respect to rights in RFC 696 documents can be found in BCP 78 and BCP 79. 698 Copies of IPR disclosures made to the IETF Secretariat and any 699 assurances of licenses to be made available, or the result of an 700 attempt made to obtain a general license or permission for the use 701 of such proprietary rights by implementers or users of this 702 specification can be obtained from the IETF on-line IPR repository 703 at http://www.ietf.org/ipr. 705 The IETF invites any interested party to bring to its attention any 706 copyrights, patents or patent applications, or other proprietary 707 rights that may cover technology that may be required to implement 708 this standard. Please address the information to the IETF at ietf- 709 ipr@ietf.org.