idnits 2.17.1 draft-ietf-tsvwg-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 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 741. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 752. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 759. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 765. ** 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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** 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 446: '...ithms followed at the end-systems MUST...' RFC 2119 keyword, line 596: '...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 September 2006) is 6434 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: 6 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-02.txt 12 September 2006 4 Expires: March 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 March 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 * Modified the caption to Figure 1, to clarify that this 57 is a congested router. Feedback from the Gen-ART 58 review. 60 * Added a paragraph to the conclusions about the role 61 of this document. From IESG review. 63 * Added a new Section 5.4 on Encapsulated Packets. 64 From IESG review. 66 * Added text to the introduction about the difficulties of 67 modifying routers. From IESG review. 69 * Added text to Section 4.2 on the difficulties of 70 IP Options. From IESG review. 72 Changes from draft-ietf-tsvwg-ecn-alternates-00.txt: 74 * Added a pointer to the SIGCOMM 2005 paper on "One More Bit 75 is Enough". 77 Changes from draft-floyd-ecn-alternates-02.txt: 79 * Added a subsection on proposals for edge-to-edge ECN. 81 * Changed name to draft-ietf-tsvwg-ecn-alternates-00. 83 Changes from draft-floyd-ecn-alternates-01.txt: 85 * Changed requirement for TCP friendliness, to a requirement of 86 friendliness with IETF-conformant congestion control. From email 87 from Mark Allman. 89 * Added to discussion of robustness to route changes. From email 90 from Mark Allman. 92 * Added an explicit note that the ECN nonce is agnostic to the 93 semantics of the other codepoints, and could be used with alternate 94 ECN semantics. 96 * Minor editing, from email from Mark Allman. 98 Changes from draft-floyd-ecn-alternates-00.txt: 100 * Added requirements for compatibility between traffic using default 101 ECN semantics and routers using alternate ECN semantics, to the 102 section on "Option 3: Friendly Co-existence with Competing 103 Traffic". From email from Gorry Fairhurst. 105 * Added to the discussion of using the diffserv code point to signal 106 alternate ECN semantics. From email from Gorry Fairhurst. 108 * Minor editing for clarity, also from email from Gorry Fairhurst. 110 END OF NOTE TO RFC EDITOR. 112 Table of Contents 114 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 4 115 2. An Overview of the Issues . . . . . . . . . . . . . . . . . . 5 116 3. Signalling the Use of Alternate ECN Semantics . . . . . . . . 6 117 3.1. Using the Diffserv Field for Signalling. . . . . . . . . 7 118 4. Issues of Incremental Deployment. . . . . . . . . . . . . . . 7 119 4.1. Option 1: Unsafe for Deployment in the 120 Internet. . . . . . . . . . . . . . . . . . . . . . . . . . . 9 121 4.2. Option 2: Verification that Routers Under- 122 stand the Alternate Semantics . . . . . . . . . . . . . . . . 9 123 4.3. Option 3: Friendly Co-existence with Com- 124 peting Traffic. . . . . . . . . . . . . . . . . . . . . . . . 10 125 5. Evaluation of the Alternate-ECN Semantics . . . . . . . . . . 12 126 5.1. Verification of Feedback from the Router . . . . . . . . 12 127 5.2. Co-existence with Competing Traffic. . . . . . . . . . . 13 128 5.3. Proposals for Alternate-ECN with Edge-to- 129 Edge Semantics. . . . . . . . . . . . . . . . . . . . . . . . 13 130 5.4. Encapsulated Packets . . . . . . . . . . . . . . . . . . 14 131 5.5. A General Evaluation of the Alternate-ECN 132 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . 14 133 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 134 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 14 135 8. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 14 136 9. Normative References. . . . . . . . . . . . . . . . . . . . . 15 137 10. Informative References . . . . . . . . . . . . . . . . . . . 15 138 IANA Considerations. . . . . . . . . . . . . . . . . . . . . . . 16 139 AUTHORS' ADDRESSES . . . . . . . . . . . . . . . . . . . . . . . 16 140 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 16 141 Intellectual Property. . . . . . . . . . . . . . . . . . . . . . 17 143 1. Introduction 145 RFC 3168, a Proposed Standard document, defines the ECN field in the 146 IP header, and specifies the semantics for the codepoints for the 147 ECN field. However, end nodes could specify the use of alternate 148 semantics for the ECN field, e.g., using codepoints in the diffserv 149 field of the IP header. 151 There have been a number of proposals in the IETF and in the 152 research community for alternate semantics for the ECN codepoint. 153 One such proposal, [BCF05], proposes an alternate-ECN semantics for 154 real-time inelastic traffic such as voice, video conferencing, and 155 multimedia streaming in DiffServ networks. In this proposal, the 156 alternate-ECN semantics would provide information about two levels 157 of congestion experienced along the path [BCF05]. Another research 158 proposal, [XSSK05], proposes a low-complexity protocol, Variable- 159 structure congestion Control Protocol (VCP), that uses the two bits 160 in the ECN field to indicate low-load, high-load, and overload 161 (congestion), where transport protocols can increase more rapidly 162 during the low-load regime. Some of the proposals for alternate-ECN 163 semantics are for ECN used in an edge-to-edge context between 164 gateways at the edge of a network region, e.g., for pre-congestion 165 notification for admissions control [BESFC06]. Other proposals for 166 alternate ECN semantics are listed on the ECN Web Page [ECN]. 168 The definition of multiple semantics for the ECN field could have 169 significant implications on both host and router implementations. 170 There is a huge base of installed hosts and routers in the Internet, 171 and in other IP networks, and updating these is an enormous and 172 potentially expensive undertaking. Some existing devices might be 173 able to support the new ECN semantics with only a software upgrade 174 and without significant degradation in performance. Some other 175 equipment might be able to support the new semantics, but with a 176 degradation in performance -- which could range from trivial to 177 catastrophic. Some other deployed equipment might be able to support 178 the new ECN semantics only with a hardware upgrade, which in some 179 cases could be prohibitively expensive to deploy on a very wide 180 scale. For these reasons it would be difficult and take a 181 significant amount of time to universally deploy any new ECN 182 semantics. In particular, routers can be difficult to upgrade, 183 since small routers sometimes are not updated frequently, and large 184 routers commonly have specialized forwarding paths to facilitate 185 high performance. 187 This document describes some of the technical issues that arise in 188 specifying alternate semantics for the ECN field, and gives 189 requirements for a safe co-existence in a world using the default 190 ECN semantics (or using no ECN at all). 192 2. An Overview of the Issues 194 In this section we discuss some of the issues that arise if some of 195 the traffic in a network consists of alternate-ECN traffic (i.e., 196 traffic using alternate semantics for the ECN field). The issues 197 include the following: (1) how routers know which ECN semantics to 198 use with which packets; (2) incremental deployment in a network 199 where some routers use only the default ECN semantics, or no ECN at 200 all; (3) co-existence of alternate-ECN traffic with competing 201 traffic on the path; and (4) a general evaluation of the alternate- 202 ECN semantics. 204 (1) The first issue concerns how routers know which ECN semantics to 205 use with which packets in the network: 207 How does the connection indicate to the router that its packets are 208 using alternate-ECN semantics? Is the specification of alternate- 209 ECN semantics robust and unambiguous? If not, is this a problem? 211 As an example, in most of the proposals for alternate-ECN semantics, 212 a diffserv field is used to specify the use of alternate-ECN 213 semantics. Do all routers that understand this diffserv codepoint 214 understand that it uses alternate-ECN semantics, or not? Diffserv 215 allows routers to re-mark DiffServ Code Point (DSCP) values within 216 the network; what is the effect of this on the alternate-ECN 217 semantics? 219 This is discussed in more detail in Section 3 below. 221 (2) A second issue is that of incremental deployment in a network 222 where some routers only use the default ECN semantics, and other 223 routers might not use ECN at all. In this document we use the 224 phrase "new routers" to refer to the routers that understand the 225 alternate-ECN semantics, and "old routers" to refer to routers that 226 don't understand or aren't willing to use the alternate-ECN 227 semantics. 229 The possible existence of old routers raises the following question: 230 How does the possible presence of old routers affect the performance 231 of the alternate-ECN connections? 233 (3) The possible existence of old routers also raises the question 234 of how the presence of old routers affects the co-existence of the 235 alternate-ECN traffic with competing traffic on the path. 237 Issues (2) and (3) are discussed in Section 4 below. 239 (4) A final issue is that of the general evaluation of the 240 alternate-ECN semantics: 242 How well does the alternate-ECN traffic perform, and how well does 243 it co-exist with competing traffic on the path, in a "clean" 244 environment with new routers and with the unambiguous specification 245 of the use of alternate-ECN semantics? 247 These issues are discussed in Section 5 below. 249 3. Signalling the Use of Alternate ECN Semantics 251 This section discusses question (1) from Section 2: 253 (1) How does the connection indicate to the router that its packets 254 are using alternate-ECN semantics? Is the specification of 255 alternate-ECN semantics robust and unambiguous? If not, is this a 256 problem? 258 The assumption of this document is that when alternate semantics are 259 defined for the ECN field, a codepoint in the diffserv field is used 260 to signal the use of these alternate ECN semantics to the router. 261 That is, the end host sets the codepoint in the diffserv field to 262 indicate to routers that alternate semantics to the ECN field are 263 being used. Routers that understand this diffserv codepoint would 264 know to use the alternate semantics for interpreting and setting the 265 ECN field. Old ECN-capable routers that do not understand this 266 diffserv codepoint would use the default ECN semantics in 267 interpreting and setting the ECN field. 269 In general, the diffserv codepoints are used to signal the per-hop 270 behavior at router queues. One possibility would be to use one 271 diffserv codepoint to signal a per-hop behavior with the default ECN 272 semantics, and a separate diffserv codepoint to signal a similar 273 per-hop behavior with the alternate ECN semantics. Another 274 possibility would be to use a diffserv codepoint to signal the use 275 of best-effort per-hop queueing and scheduling behavior, but with 276 alternate ECN semantics. A detailed discussion of these issues is 277 beyond the scope of this document. 279 We note that this discussion does not exclude the possibility of 280 using other methods, including out-of-band mechanisms, for 281 signalling the use of alternate semantics for the ECN field. The 282 considerations in the rest of this document apply regardless of the 283 method used to signal the use of alternate semantics for the ECN 284 field. 286 3.1. Using the Diffserv Field for Signalling 288 We note that the default ECN semantics defined in RFC 3168 are the 289 current default semantics for the ECN field, regardless of the 290 contents of any other fields in the IP header. In particular, the 291 default ECN semantics apply for more than best-effort traffic with a 292 codepoint of '000000' for the diffserv field - the default ECN 293 semantics currently apply regardless of the contents of the diffserv 294 field. 296 There are two ways to use the diffserv field to signal the use of 297 alternate ECN semantics. One way is to use an existing diffserv 298 codepoint, and to modify the current definition of that codepoint, 299 through approved IETF processes, to specify the use of alternate ECN 300 semantics with that codepoint. A second way is to define a new 301 diffserv codepoint, and to specify the use of alternate ECN 302 semantics with that codepoint. We note that the first of these two 303 mechanisms raises the possibility that some routers along the path 304 will understand the diffserv codepoint but will use the default ECN 305 semantics with this diffserv codepoint, or won't use ECN at all, and 306 that other routers will use the alternate ECN semantics with this 307 diffserv codepoint. 309 4. Issues of Incremental Deployment 311 This section discusses questions (2) and (3) posed in Section 2: 313 (2) How does the possible presence of old routers affect the 314 performance of the alternate-ECN connections? 316 (3) How does the possible presence of old routers affect the co- 317 existence of the alternate-ECN traffic with competing traffic on the 318 path? 320 When alternate semantics are defined for the ECN field, it is 321 necessary to ensure that there are no problems caused by old routers 322 along the path that don't understand the alternate ECN semantics. 324 One possible problem is that of poor performance for the alternate- 325 ECN traffic. Is it essential to the performance of the alternate- 326 ECN traffic that all routers along the path understand the 327 alternate-ECN semantics? If not, what are the possible 328 consequences, for the alternate-ECN traffic itself, when some old 329 routers along the path don't understand the alternate-ECN semantics? 330 These issues have to be answered in the context of each specific 331 proposal for alternate ECN semantics. 333 A second specific problem is that of possible unfair competition 334 with other traffic along the path. If there is an old router along 335 the path that doesn't use ECN, that old router could drop packets 336 from the alternate-ECN traffic, and expect the alternate-ECN traffic 337 to reduce its sending rate as a result. Does the alternate-ECN 338 traffic respond to packet drops as an indication of congestion? 340 |--------| 341 Alternate-ECN traffic ----> | | ---> CE-marked packet 342 | Old | 343 Non-ECN traffic ----------> | Router | ---> dropped packet 344 | | 345 RFC-3168 ECN traffic -----> | | ---> CE-marked packet 346 |--------| 348 Figure 1: Alternate-ECN traffic, an old router, using RFC-3168 ECN, 349 that is congested and ready to drop or mark the arriving packet. 351 Similarly, what if there is an old router along the path that 352 understands only the default ECN semantics from RFC-3168, as in 353 Figure 1 above? In times of congestion, the old default-ECN router 354 could see an alternate-ECN packet with one of the ECN-Capable 355 Transport (ECT) codepoints set in the ECN field in the IP header, as 356 defined in RFC 3168, and set the Congestion Experienced (CE) 357 codepoint in the ECN field as an alternative to dropping the packet. 358 The router in this case would expect the alternate-ECN connection to 359 respond, in terms of congestion control, as it would if the packet 360 has been dropped. If the alternate-ECN traffic fails to respond 361 appropriately to the CE codepoint being set by an old router, this 362 could increase the aggregate traffic arriving at the old router, 363 resulting in an increase in the packet-marking and packet-dropping 364 rates at that router, further resulting in the alternate-ECN traffic 365 crowding out the other traffic competing for bandwidth on that link. 367 Basically, there are three possibilities for avoiding scenarios 368 where the presence of old routers along the path results in the 369 alternate-ECN traffic competing unfairly with other traffic along 370 the path: 372 Option 1: Alternate-ECN traffic is clearly understood as unsafe for 373 deployment in the global Internet; or 374 Option 2: All alternate-ECN traffic deploys some mechanism for 375 verifying that all routers on the path understand and agree to use 376 the alternate ECN semantics for this traffic; or 378 Option 3: The alternate-ECN semantics are defined in such a way as 379 to ensure the fair and peaceful co-existence of the alternate-ECN 380 traffic with best-effort and other traffic, even in environments 381 that include old routers that do not understand the alternate-ECN 382 semantics. 384 Each of these alternatives is explored in more detail below. 386 4.1. Option 1: Unsafe for Deployment in the Internet 388 The first option specified above is for the alternate-ECN traffic to 389 be clearly understood as only suitable for enclosed environments, 390 and as unsafe for deployment in the global Internet. This would 391 mean that it would be unsafe for packets using the alternate ECN 392 semantics to be unleashed in the global Internet, in order to avoid 393 the chance of the alternate-ECN traffic traversing an old router 394 that doesn't understand the alternate semantics. This document 395 doesn't comment on whether a mechanism would be required to ensure 396 that the alternate-ECN semantics would not be let loose on the 397 global Internet. This document also doesn't comment on the chances 398 that this scenario would be considered acceptable for 399 standardization by the IETF community. 401 4.2. Option 2: Verification that Routers Understand the Alternate 402 Semantics 404 The second option specified above is for the alternate-ECN traffic 405 to include a mechanism for ensuring that all routers along the path 406 understand and agree to the use of the alternate ECN semantics for 407 this traffic. As an example, such a mechanism could consist of a 408 field in an IP option that all routers along the path decrement if 409 they agree to use the alternate ECN semantics with this traffic. (A 410 similar mechanism is proposed for Quick-Start, for verifying that 411 all of the routers along the path understand the Quick-Start IP 412 Option [QuickStart].) Using such a mechanism, a sender could have 413 reasonable assurance that the packets that are sent specifying the 414 use of alternate ECN semantics only traverse routers that in fact 415 understand and agree to use these alternate semantics for these 416 packets. Note however that most existing routers are optimized for 417 IP packets with no options, or with only some very well-known and 418 simple IP options. Thus the definition and use of any new IP option 419 may have a serious detrimental effect on the performance of many 420 existing IP routers. 422 Such a mechanism should be robust in the presence of paths with 423 multi-path routing, and in the presence of routing or configuration 424 changes along the path while the connection is in use. In 425 particular, if this option is used, connections could include some 426 form of monitoring for changes in path behavior, and/or periodic 427 monitoring that all routers along the path continue to understand 428 the alternate-ECN semantics. 430 4.3. Option 3: Friendly Co-existence with Competing Traffic 432 The third option specified above is for the alternate ECN semantics 433 to be defined so that traffic using the alternate semantics would 434 co-exist safely in the Internet on a path with one or more old 435 routers that use only the default ECN semantics. In this scenario, 436 a connection sending alternate-ECN traffic would have to respond 437 appropriately to a CE packet (a packet with the ECN codepoint "11") 438 received at the receiver, using a conformant congestion control 439 response. Hopefully, the connection sending alternate-ECN traffic 440 would also respond appropriately to a dropped packet, that could be 441 a congestion indication from a router that doesn't use ECN. 443 RFC 3168 defines the default ECN semantics as follows: 445 "Upon the receipt by an ECN-Capable transport of a single CE packet, 446 the congestion control algorithms followed at the end-systems MUST 447 be essentially the same as the congestion control response to a 448 *single* dropped packet. For example, for ECN-Capable TCP the 449 source TCP is required to halve its congestion window for any window 450 of data containing either a packet drop or an ECN indication." 452 The only conformant congestion control mechanisms currently 453 standardized in the IETF are TCP [RFC2581] and protocols using TCP- 454 like congestion control (e.g., SCTP [RFC2960], DCCP with CCID-2 455 ([RFC4340], [RFC4341])), and TCP-Friendly Rate Control (TFRC) 456 [RFC3448] and protocols with TFRC-like congestion control (e.g., 457 DCCP using CCID-3 [RFC4342]). TCP uses Additive-Increase 458 Multiplicative-Decrease congestion control, and responds to the loss 459 or ECN-marking of a single packet by halving its congestion window. 460 In contrast, the equation-based congestion control mechanism in TFRC 461 estimates the loss event rate over some period of time, and uses a 462 sending rate that would be comparable, in packets per round-trip- 463 time, to that of a TCP connection experiencing the same loss event 464 rate. 466 So what are the requirements in order for alternate-ECN traffic to 467 compete appropriately with other traffic on a path through an old 468 router that doesn't understand the alternate ECN semantics (and 469 therefore might be using the default ECN semantics)? The first and 470 second requirements below concern compatibility between traffic 471 using alternate ECN semantics and routers using default ECN 472 semantics. 474 The first requirement for compatibility with routers using default 475 ECN is that if a packet is marked with the ECN codepoint "11" in the 476 network, this marking is not changed on the packet's way to the 477 receiver (unless the packet is dropped before it reaches the 478 receiver). This requirement is necessary to ensure that congestion 479 indications from a default-ECN router make it to the transport 480 receiver. 482 A second requirement for compatibility with routers using default 483 ECN is that the end-nodes respond to packets that are marked with 484 the ECN codepoint "11" in a way that is friendly to flows using 485 IETF-conformant congestion control. This requirement is needed 486 because the "11"-marked packets might have come from a congested 487 router that understands only the default ECN semantics, and that 488 expects that end-nodes will respond appropriately to CE packets. 489 This requirement would ensure that the traffic using the alternate 490 semantics does not `bully' competing traffic that it might encounter 491 along the path, and does not drive up congestion on the shared link 492 inappropriately. 494 Additional requirements concern compatibility between traffic using 495 default ECN semantics and routers using alternate ECN semantics. 496 This situation could occur if a diff-serv codepoint using default 497 ECN semantics is redefined to use alternate ECN semantics, and 498 traffic from an "old" source traverses a "new" router. If the 499 router "knows" that a packet is from a sender using alternate 500 semantics (e.g., because the packet is using a certain diff-serv 501 codepoint, and all packets with that diff-serv codepoint use 502 alternate semantics for the ECN field), then the requirements below 503 are not necessary, and the rules for the alternate semantics apply. 505 A requirement for compatibility with end-nodes using default ECN is 506 that if a packet that *could* be using default semantics is marked 507 with the ECN codepoint "00", this marking must not be changed to 508 "01", "10", or "11" in the network. This prevents the packet from 509 being represented incorrectly to a default ECN router downstream as 510 ECN-Capable. Similarly, if a packet that *could* be using default 511 semantics is marked with the ECN codepoint "01", then this codepoint 512 should not be changed to "10" in the network (and a "10" codepoint 513 should not be changed to "01"). This requirement is necessary to 514 avoid interference with the transport protocol's use of the ECN 515 nonce [RFC3540]. 517 As discussed earlier, the current conformant congestion control 518 responses to a dropped or default-ECN-marked packet consist of TCP 519 and TCP-like congestion control, and of TFRC (TCP-Friendly Rate 520 Control). Another possible response considered in RFC 3714, but not 521 standardized in a standards-track document, is that of simply 522 terminating an alternate-ECN connection for a period of time if the 523 long-term sending rate is higher than would be that of a TCP 524 connection experiencing the same packet dropping or marking rates 525 [RFC3714]. We note that the use of such a congestion control 526 response to CE-marked packets would require specification of time 527 constants for measuring the loss rates and for stopping 528 transmission, and would require a consideration of issues of packet 529 size. 531 5. Evaluation of the Alternate-ECN Semantics 533 This section discusses question (4) posed in Section 2: 535 (4) How well does the alternate-ECN traffic perform, and how well 536 does it co-exist with competing traffic on the path, in a "clean" 537 environment with new routers and with the unambiguous specification 538 of the use of alternate-ECN semantics? 540 5.1. Verification of Feedback from the Router 542 One issue in evaluating the alternate-ECN semantics concerns 543 mechanisms to discourage lying from the transport receiver to the 544 transport sender. In many cases the sender is a server that has an 545 interest in using the alternate-ECN semantics correctly, while the 546 receiver has more incentives for lying about the congestion 547 experienced along the path. 549 In the default ECN semantics, two of the four ECN codepoints are 550 used for ECN-Capable(0) and ECN-Capable(1). The use of two 551 codepoints for ECN-Capable, instead of one, permits the data sender 552 to verify receiver's reports that packets were actually received 553 unmarked at the receiver. In particular, the sender can specify 554 that the receiver report to the sender whether each unmarked packet 555 was received ECN-Capable(0) or ECN-Capable(1), as discussed in RFC 556 3540 [RFC3540]. This use of ECN-Capable(0) and ECN-Capable(1) is 557 independent of the semantics of the other ECN codepoints, and could 558 be used, if desired, with alternate semantics for the other 559 codepoints. 561 If alternate semantics for the ECN codepoint don't include the use 562 of two separate codepoints to indicate ECN-Capable, then the 563 connections using those semantics have lost the ability to verify 564 that the data receiver is accurately reporting the received ECN 565 codepoint to the data sender. In this case, it might be necessary 566 for the alternate-ECN framework to include alternate mechanisms for 567 ensuring that the data receiver is reporting feedback appropriately 568 to the sender. As one possibility, policers could be used in 569 routers to ensure that end nodes are responding appropriately to 570 marked packets. 572 5.2. Co-existence with Competing Traffic 574 A second general issue concerns the co-existence of alternate-ECN 575 traffic with competing traffic along the path, in a clean 576 environment where all routers understand and are willing to use the 577 alternate-ECN semantics for the traffic that specifies its use. 579 If the traffic using the alternate-ECN semantics is best-effort 580 traffic, then it is subject to the general requirement of fair 581 competition with TCP and other traffic along the path [RFC2914]. 583 If the traffic using the alternate-ECN semantics is diffserv 584 traffic, then the requirements are governed by the overall 585 guidelines for that class of diffserv traffic. It is beyond the 586 scope of this document to specify the requirements, if any, for the 587 co-existence of diffserv traffic with other traffic on the link; 588 this should be addressed in the specification of the diffserv 589 codepoint itself. 591 5.3. Proposals for Alternate-ECN with Edge-to-Edge Semantics 593 RFC 3168 specifies the use of the default ECN semantics by an end- 594 to-end transport protocol, with the requirement that "upon the 595 receipt by an ECN-Capable transport of a single CE packet, the 596 congestion control algorithms followed at the end-systems MUST be 597 essentially the same as the congestion control response to a 598 *single* dropped packet" ([RFC3168], Section 5). In contrast, some 599 of the proposals for alternate-ECN semantics are for ECN used in an 600 edge-to-edge context between gateways at the edge of a network 601 region, e.g., [BESFC06]. 603 When alternate-ECN is defined with edge-to-edge semantics, this 604 definition needs to ensure that the edge-to-edge semantics do not 605 conflict with a connection using other ECN semantics end-to-end. 606 One way to avoid conflict would be for the edge-to-edge ECN proposal 607 to include some mechanism to ensure that the edge-to-edge ECN is not 608 used for connections that are using other ECN semantics (standard or 609 otherwise) end-to-end. Alternately, the edge-to-edge semantics 610 could be defined so that they do not conflict with a connection 611 using other ECN semantics end-to-end. 613 5.4. Encapsulated Packets 615 RFC 3168 has an extensive discussion of the interactions between ECN 616 and IP tunnels, including IPsec and IP in IP. Proposals for 617 alternate-ECN semantics might interact with IP tunnels differently 618 than default ECN. As a result, proposals for alternate-ECN 619 semantics must explicitly consider the issue of interactions with IP 620 tunnels. 622 5.5. A General Evaluation of the Alternate-ECN Semantics 624 A third general issue concerns the evaluation of the general merits 625 of the proposed alternate-ECN semantics. Again, it would be beyond 626 the scope of this document to specify requirements for the general 627 evaluation of alternate-ECN semantics. 629 6. Security Considerations 631 This document doesn't propose any new mechanisms for the Internet 632 protocol, and therefore doesn't introduce any new security 633 considerations. 635 7. Conclusions 637 This document has discussed some of the issues to be considered in 638 the specification of alternate semantics for the ECN field in the IP 639 header. 641 Specifications of alternate ECN semantics must clearly state how 642 they address the issues raised in this document, particularly the 643 issues discussed in Section 2. In addition, specifications for 644 alternate ECN semantics must meet the requirements in Section 5.2 645 for co-existence with competing traffic. 647 8. Acknowledgements 649 This document is based in part on conversations with Jozef Babiarz, 650 Kwok Ho Chan, and Victor Firoiu on their proposal for an alternate 651 use of the ECN field in DiffServ environments. Many thanks to 652 Francois Le Faucheur for feedback recommending that the document 653 include a section at the beginning discussing the potential issues 654 that need to be addressed. Thanks also to Mark Allman, Fred Baker, 655 David Black, Gorry Fairhurst, and to members of the TSVWG working 656 group for feedback on these issues. 658 9. Normative References 660 [RFC3168] Ramakrishnan, K.K., Floyd, S., and Black, D., The Addition 661 of Explicit Congestion Notification (ECN) to IP, RFC 3168, Proposed 662 Standard, September 2001. 664 10. Informative References 666 [BCF05] J. Babiarz, K. Chan, and V. Firoiu, Congestion Notification 667 Process for Real-Time Traffic, expired internet-draft draft-babiarz- 668 tsvwg-rtecn-04, work in progress, July 2005. 670 [BESFC06] B. Briscoe, P. Eardley, D. Songhurst, F. Le Faucheur, A. 671 Charny, J. Barbiaz, K. Chan, A Framework for Admission Control over 672 DiffServ using Pre-Congestion Notification, internet-draft draft- 673 briscoe-tsvwg-cl-architecture-03.txt, work in progress, June 2006. 675 [ECN] ECN Web Page, URL "www.icir.org/floyd/ecn.html". 677 [QuickStart] S. Floyd, M. Allman, A. Jain, and P. Sarolahti, Quick- 678 Start for TCP and IP, Internet-draft draft-ietf-tsvwg- 679 quickstart-05.txt, work in progress, July 2006. 681 [RFC2581] M. Allman, V. Paxson, and W. Stevens, TCP Congestion 682 Control, RFC 2581, Proposed Standard, April 1999. 684 [RFC2914] S. Floyd, Congestion Control Principles, RFC 2914, Best 685 Current Practice, September 2000. 687 [RFC2960] R. Stewart et al, Stream Control Transmission Protocol, 688 RFC 2960, October 2000. 690 [RFC3448] Handley, M., Floyd, S., Pahdye, J., and Widmer, J. TCP 691 Friendly Rate Control (TFRC): Protocol Specification. RFC 3448, 692 Proposed Standard, January 2003. 694 [RFC3540] N. Spring, D. Wetherall, and D. Ely, Robust Explicit 695 Congestion Notification (ECN) Signaling with Nonces, RFC 3540, 696 Experimental, June 2003. 698 [RFC3714] S. Floyd and J. Kempf, Editors, IAB Concerns Regarding 699 Congestion Control for Voice Traffic in the Internet, RFC 3714, 700 Informational, March 2004. 702 [RFC4340] E. Kohler, M. Handley, and S. Floyd, Datagram Congestion 703 Control Protocol (DCCP), RFC 4340, Proposed Standard, March 2006. 705 [RFC4341] S. Floyd and E. Kohler, Profile for Datagram Congestion 706 Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion 707 Control, RFC 4341, Proposed Standard, March 2006. 709 [RFC4342] S. Floyd, E. Kohler, and J. Padhye, Profile for Datagram 710 Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP- 711 Friendly Rate Control (TFRC), RFC 4342, Proposed Standard, March 712 2006. 714 [XSSK05] Y. Xia, L. Subramanian, I. Stoica, and S. Kalyanaraman, 715 One More Bit Is Enough, SIGCOMM 2005, September 2005. 717 IANA Considerations 719 There are no IANA considerations in this document. 721 AUTHORS' ADDRESSES 723 Sally Floyd 724 Phone: +1 (510) 666-2989 725 ICIR (ICSI Center for Internet Research) 726 Email: floyd@icir.org 727 URL: http://www.icir.org/floyd/ 729 Full Copyright Statement 731 This document is subject to the rights, licenses and restrictions 732 contained in BCP 78, and except as set forth therein, the authors 733 retain all their rights. 735 This document and the information contained herein are provided on 736 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 737 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 738 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 739 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 740 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 741 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 743 Intellectual Property 745 The IETF takes no position regarding the validity or scope of any 746 Intellectual Property Rights or other rights that might be claimed 747 to pertain to the implementation or use of the technology described 748 in this document or the extent to which any license under such 749 rights might or might not be available; nor does it represent that 750 it has made any independent effort to identify any such rights. 751 Information on the procedures with respect to rights in RFC 752 documents can be found in BCP 78 and BCP 79. 754 Copies of IPR disclosures made to the IETF Secretariat and any 755 assurances of licenses to be made available, or the result of an 756 attempt made to obtain a general license or permission for the use 757 of such proprietary rights by implementers or users of this 758 specification can be obtained from the IETF on-line IPR repository 759 at http://www.ietf.org/ipr. 761 The IETF invites any interested party to bring to its attention any 762 copyrights, patents or patent applications, or other proprietary 763 rights that may cover technology that may be required to implement 764 this standard. Please address the information to the IETF at ietf- 765 ipr@ietf.org.