idnits 2.17.1 draft-ietf-tsvwg-cc-alt-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, updated by RFC 4748 on line 513. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 489. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 496. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 502. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 70 instances of lines with control characters in the document. ** The abstract seems to contain references ([HTCP], [RFC3649], [FAST], [BIC], [CompoundTCP], [XCP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (March 2007) is 6249 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-11) exists of draft-irtf-tmrg-metrics-07 -- Obsolete informational reference (is this intentional?): RFC 2581 (Obsoleted by RFC 5681) -- Obsolete informational reference (is this intentional?): RFC 2960 (Obsoleted by RFC 4960) == Outdated reference: A later version (-05) exists of draft-irtf-tmrg-tools-03 Summary: 4 errors (**), 0 flaws (~~), 3 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 M. Allman 3 Intended status: Best Current Practice ICIR / ICSI 4 Expires: September 2007 March 2007 6 Specifying New Congestion Control Algorithms 7 draft-ietf-tsvwg-cc-alt-00.txt 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 19 Internet-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 Copyright Notice 34 Copyright (C) The IETF Trust (2007). 36 Abstract 38 The IETF's standard congestion control schemes have been widely 39 shown to be inadequate for various environments (e.g., high-speed 40 networks). Recent research has yielded many alternate congestion 41 control schemes ([RFC3649], [HTCP], [FAST], [BIC], [CompoundTCP], 42 [XCP], and many more). Using these new congestion control 43 schemes in the global Internet has possible ramifications to 44 both the traffic using the new congestion control and to traffic 45 using the currently standardized congestion control. Therefore, 46 the IETF must proceed with caution when dealing with alternate 47 congestion control proposals. The goal of this document is to 48 provide guidance for considering alternate congestion control 49 algorithms within the IETF. 51 TO BE DELETED BY THE RFC EDITOR UPON PUBLICATION: 53 Changes from draft-floyd-tsvwg-cc-alt-00.txt: 55 * Changed the name to draft-ietf-tsvwg-cc-alt-00.txt. 57 * Added a sentence about robustness with various 58 queueing algorithms in the routers, especially both RED 59 and DropTail. Suggestion from Jitendra Padhye. 61 * Added a sentence about robustness with the routers, 62 middleboxes, and such deployed in the current Internet. 63 Concern taken from a talk by Henry Sanders. 65 * Add a section about minimum requirements necessary for 66 approval for deployment in the global Internet. 67 Suggestion by Jitendra Padhye. 69 * Added more examples to guideline 3 about difficult environments, 70 and added that TCP performance in difficult environments is 71 still an active research topic. Suggestion from Doug Leith. 73 * Added citations to examples of discussions of these issues 74 in Experimental RFCs 3649 and 4782. 76 * Added examples of high speed TCP proposals. Suggestion 77 from Bob Braden. 79 * Changed the fairness bullets to better reflect that new congestion 80 controllers are expected to assess the impact to standard 81 congestion controlled flows---without commenting on how that 82 assessment should be done. From discussions with bob Briscoe. 84 * Made numerous editing changes suggested by Gorry Fairhurst. 86 Changes from draft-floyd-cc-alt-00.txt: 88 * Changed the name to draft-floyd-tsvwg-cc-alt-00.txt. 90 * Added a bullet about incremental deployment. Feedback from 91 Colin Perkins 93 * Clarified the fairness section; this section is not saying 94 that strict TCP-friendliness is a requirement. 96 * Clarified that as an alternative to Full Backoff, a flow 97 could stop sending when the packet drop rate is above a 98 certain threshold. 100 * Clarified that the Full Backoff bullet does not require 101 that different flows with different round-trip times 102 use the same criteria about when they should back off 103 to one packet per round-trip time or less. 105 * Added a paragraph about Informational RFCs. 107 * Added a bullet about response to transient events, including 108 routing events or moving from a private to a shared network. 110 END OF NOTES TO BE DELETED. 112 1. Introduction 114 This document provides guidelines for the IETF to use when 115 evaluating suggested congestion control algorithms that 116 significantly differ from the general congestion control principles 117 outlined in [RFC2914]. The guidance is intended to be useful to 118 authors proposing alternate congestion control and for the IETF 119 community when evaluating whether a proposal is appropriate for 120 publication in the RFC series. 122 This document does not give hard-and-fast rules for what makes for 123 an appropriate congestion control scheme. Rather, the document 124 provides a set of criteria that should be considered and weighed by 125 the IETF in the context of each proposal. The high-order criteria 126 for any new proposal is that a serious scientific study of the pros 127 and cons of the proposal needs to have been done such that the IETF 128 has a well rounded set of information to consider. 130 After initial studies, we encourage authors to write a specification 131 of their proposals for publication in the RFC series to allow others 132 to concretely understand and investigate the wealth of proposals in 133 this space. 135 2. Status 137 Following the lead of HighSpeed TCP, alternate congestion control 138 algorithms are expected to be published as "Experimental" RFCs until 139 such time that the community better understands the solution space. 140 Traditionally, the meaning of "Experimental" status has varied in 141 its use and interpretation. As part of this document we define two 142 classes of congestion control proposals that can be published 143 with the "Experimental" status. The first class includes 144 algorithms that are judged to be safe to deploy for best-effort 145 traffic in the global Internet and further investigated in that 146 environment. The second class includes algorithms that, while 147 promising, are not deemed safe enough for widespread deployment 148 as best-effort traffic on the Internet, but are being specified 149 to facilitate investigations in simulation, testbeds, or 150 controlled environments. The second class can also include 151 algorithms where the IETF does not yet have sufficient understanding 152 to decide if the algorithm is or is not safe for deployment on 153 the Internet. 155 Each alternate congestion control algorithm published is required to 156 include a statement in the abstract indicating whether or not the 157 proposal is considered safe for use on the Internet. Each alternate 158 congestion control algorithm published is also required to include a 159 statement in the abstract describing environments where the protocol 160 is not recommended for deployment. There may be environments where 161 the protocol is deemed *safe* for use, but still is not *recommended* 162 for use because it does not perform well for the user. 164 As examples of such statements, [RFC3649] specifying HighSpeed TCP 165 includes a statement in the abstract stating that the proposal is 166 Experimental, but may be deployed in the current Internet. In 167 contrast, the Quick-Start document [RFC4782] includes a paragraph 168 in the abstract stating the the mechanism is only being proposed for 169 controlled environments. The abstract specifies environments where 170 the Quick-Start request could give false positives (and therefore 171 would be unsafe to deploy). The abstract also specifies 172 environments where packets containing the Quick-Start request could 173 be dropped in the network; in such an environment, Quick-Start would 174 not be unsafe to deploy, but deployment would still not be 175 recommended because it could cause unnecessary delays for the 176 connections attempting to use Quick-Start. 178 For researchers who are not ready to bring their congestion control 179 mechanisms to the IETF for standardization (either as Experimental 180 or as Proposed Standard), one possibility would be to submit an 181 internet-draft that documents the alternate congestion control 182 mechanism for the benefit of the IETF and IRTF communities. This is 183 particularly encouraged in order to get algorithm specifications 184 widely disseminated to facilitate further research. Such an 185 internet-draft could be submitted to be considered as an 186 Informational RFC, as a first step in the process towards 187 standardization. Such a document would also be expected to carry an 188 explicit warning against using the scheme in the global Internet. 190 3. Guidelines 192 As noted above, authors are expected to do a well-rounded 193 evaluation of the pros and cons of proposals brought to the IETF. 194 The following are guidelines to help authors and the IETF community. 195 Concerns that fall outside the scope of these guidelines are 196 certainly possible; these guidelines should not be considered 197 as an all-encompassing check-list. 199 (1) Impact on Standard TCP, SCTP [RFC2960], and DCCP [RFC4340]. 201 Proposed congestion control mechanisms should be evaluated when 202 competing with standard IETF congestion control. Alternate 203 congestion controllers that have a significantly negative impact 204 on traffic using standard congestion control may be suspect and 205 this aspect should be part of the community's decision making 206 with regards to the suitability of the alternate congestion 207 control mechanism. 209 We note that this bullet is not a requirement for strict 210 TCP-friendliness as a prerequisite for an alternate congestion 211 control mechanism to advance to Experimental. As an example, 212 HighSpeed TCP is a congestion control mechanism that is 213 Experimental, but that is not TCP-friendly in all environments. 214 We also note that this guideline does not constrain the 215 fairness offered for non-best-effort traffic. 217 As an example from an Experimental RFC, fairness with standard 218 TCP is discussed in Sections 4 and 6 of RFC 3649 (High-Speed 219 TCP) and using spare capacity is discussed in Sections 6, 11.1, 220 and 12 of RFC 3649 (High-Speed TCP). 222 (2) Difficult Environments. 224 The proposed algorithms should be assessed in difficult 225 environments such as paths containing wireless links. 226 Characteristics of wireless environments are discussed in 227 [RFC3819] and in Section 16 of [Tools]. Other difficult 228 environments can include those with multipath routing within 229 a connection. We note that there is still much to be desired 230 in terms of the performance of TCP in some of these difficult 231 environments. For congestion control mechanisms with 232 explicit feedback from routers, difficult environments can 233 include paths with non-IP queues at layer-two, IP tunnels, 234 and the like. A minimum goal for experimental mechanisms 235 proposed for widespread deployment in the Internet should 236 be that they do not perform significantly worse than TCP 237 in these environments. 239 As an example from an Experimental RFC, performance in difficult 240 environments is discussed in Sections 6, 9.2, and 10.2 of 241 RFC 4782 (Quick-Start). 243 (3) Investigating a Range of Environments. 245 Similar to the last criteria, proposed alternate congestion 246 controllers should be assessed in a range of environments. 247 For instance, proposals should be investigated across a 248 range of bandwidths, round-trip times, levels of traffic 249 on the reverse path, and levels of statistical multiplexing 250 at the congested link. Similarly, proposals should be 251 investigated for robust performance with different queueing 252 mechanisms in the routers, especially Random Early Detection 253 (RED) [FJ03] and Drop-Tail. This evaluation is often not 254 included in the internet-draft itself, but in related papers 255 cited in the draft. 257 A particularly important aspect of evaluating a proposal 258 for standardization is in understanding where the algorithm 259 breaks down. Therefore, particular attention should be 260 paid to characterizing the areas where the proposed mechanism 261 does not perform well. 263 As an example from an Experimental RFC, performance in a range 264 of environments is discussed in Section 12 of RFC 3649 265 (High-Speed TCP) and Section 9.7 of RFC 4782 (Quick-Start). 267 (4) Protection Against Congestion Collapse. 269 The alternate congestion control mechanism should either 270 stop sending when the packet drop rate exceeds some threshold 271 [RFC3714], or should include some notion of "full backoff". 272 For "full backoff", at some point the algorithm would 273 reduce the sending rate to one packet per round-trip time 274 and then exponentially backoff the time between single 275 packet transmissions if congestion persists. Exactly when 276 either "full backoff" or a pause in sending comes into play 277 will be algorithm-specific. However, as discussed in 278 [RFC2914], this requirement is crucial to protect the network 279 in times of extreme congestion. 281 If "full backoff" is used, this bullet does not require 282 that the full backoff mechanism must be identical to that 283 of TCP. As an example, this bullet does not preclude 284 full backoff mechanisms that would give flows with 285 different round-trip times comparable bandwidth during 286 backoff. 288 (5) Fairness within the Alternate Congestion Control Algorithm. 290 In environments with multiple competing flows all using the 291 same alternate congestion control algorithm, the proposal 292 should explore how bandwidth is shared among the competing 293 flows. 295 (6) Performance with Misbehaving Nodes and Outside Attackers. 297 The proposal should explore how the alternate congestion control 298 mechanism performs with misbehaving senders, receivers, or 299 routers. In addition, the proposal should explore how the 300 alternate congestion control mechanism performs with outside 301 attackers. This can be particularly important for congestion 302 control mechanisms that involve explicit feedback from routers 303 along the path. 305 As an example from an Experimental RFC, performance with 306 misbehaving nodes and outside attackers is discussed in 307 Sections 9.4, 9.5, and 9.6 of RFC 4782 (Quick-Start). This 308 includes discussion of misbehaving senders and receivers; 309 collusion between misbehaving routers; misbehaving middleboxes; 310 and the potential use of Quick-Start to attack routers or 311 to tie up available Quick-Start bandwidth. 313 (7) Responses to Sudden or Transient Events. 315 The proposal should consider how the alternate congestion 316 control mechanism would perform in the presence of transient 317 events such as sudden congestion, a routing change, or a 318 mobility event. Routing changes, link disconnections, 319 intermittent link connectivity, and mobility are discussed in 320 more detail in Section 17 of [Tools]. 322 As an example from an Experimental RFC, response to transient 323 events is discussed in Section 9.2 of RFC 4782 (Quick-Start). 325 (8) Incremental Deployment. 327 The proposal should discuss whether the alternate congestion 328 control mechanism allows for incremental deployment in the 329 targeted environment. For a mechanism targeted for deployment 330 in the current Internet, it would be helpful for the proposal 331 to discuss what is known (if anything) about the correct 332 operation of the mechanism with some of the equipment 333 installed in the current Internet, e.g., routers, 334 transparent proxies, WAN optimizers, intrusion detection 335 systems, home routers, and the like. 337 As a similar concern, if the alternate congestion control 338 mechanism is intended only for specific environments, the 339 proposal should consider how this intention is to be carried 340 out. For example, if a proposed congestion control scheme is 341 deemed suitable for deployment in controlled environments but 342 unsafe for widespread deployment in the Internet, is it 343 sufficient just to have a sentence in the Abstract of the 344 document stating this, or are some additional mechanisms needed 345 as well? 347 As an example from an Experimental RFC, deployment issues are 348 discussed in Sections 10.3 and 10.4 of RFC 4782 (Quick-Start). 350 4. Minimum Requirements 352 This section suggests minimum requirements for a document to 353 be approved as Experimental with approval for widespread 354 deployment in the global Internet. We note that this is not 355 a binding document with fixed and unchanging requirements, 356 but simply a document targeted for approval as Best Current 357 Practice. 359 Minimum requirements for approval for widespread deploy include 360 guideline (1) on assessing the impact on standard congestion 361 control. Minimum requirements also include guideline (3) on 362 investigation of the proposed mechanism in a range of environments, 363 and guideline (4) on protection against congestion collapse. In 364 order to be approved for widespread deployment, the proposed 365 mechanism will also have to meet guideline (8), discussing whether 366 the mechanism allows for incremental deployment. 368 For other guidelines, i.e., (2), (5), (6), and (7), evidence 369 that the proposed mechanism has significantly more problems 370 than those of TCP should be a cause for concern in approval for 371 widespread deployment in the Internet. 373 5. Conclusions 375 This document is intended as a guideline for researchers 376 in bringing congestion control mechanisms to the IETF to 377 be considered for Experimental status, and also as a 378 guideline to the IETF in evaluating such proposals. 380 6. Security Considerations 382 This document does not represent a change to any aspect of the 383 TCP/IP protocol suite and therefore does not directly impact 384 Internet security. The implementation of various facets of the 385 Internet's current congestion control algorithms do have security 386 implications (e.g., as outlined in [RFC2581]). Alternate congestion 387 control schemes should be mindful of such pitfalls, as well, and 388 should examine any potential security issues that may arise. 390 7. IANA Considerations 392 This document does not require any IANA action. 394 Acknowledgments 396 Discussions with Lars Eggert and Aaron Falk seeded this document. 397 Thanks to Bob Briscoe, Gorry Fairhurst, Doug Leith, Jitendra 398 Padhye, Colin Perkins, members of TSVWG, and participants at 399 the TCP Workshop at Microsoft Research for feedback and 400 contributions. This document also draws from [Metrics]. 402 Normative References 404 Informative References 406 [BIC] L. Xu, K. Harfoush, and I. Rhee, Binary Increase Congestion 407 Control for Fast Long-Distance Networks, Infocom 2004. 409 [CompoundTCP] K. Tan, J. Song, Q. Zhang, and M. Sridharan, A 410 Compound TCP Approach for High-speed and Long Distance Networks, 411 Infocom 2006. 413 [FAST] C. Jin, D. Wei and S. Low, FAST TCP: Motivation, 414 Architecture, Algorithms, Performance, Infocom 2004. 416 [FJ03] Floyd, S., and Jacobson, V., Random Early Detection 417 Gateways for Congestion Avoidance, IEEE/ACM Transactions on 418 Networking, V.1 N.4, August 1993. 420 [HTCP] Shorten, R.N. and Leith, D.J., H-TCP: TCP for High-speed 421 and Long-distance Networks. PFLDnet, 2004. 423 [Metrics] S. Floyd, Metrics for the Evaluation of Congestion 424 Control Mechanisms. Internet-draft draft-irtf-tmrg-metrics-07, 425 work in progress, February 2007. 427 [RFC2581] M. Allman, V. Paxson, and W. Stevens, TCP Congestion 428 Control, RFC 2581, Proposed Standard, April 1999. 430 [RFC2914] S. Floyd, Congestion Control Principles, RFC 2914, Best 431 Current Practice, September 2000. 433 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 434 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., 435 and V. Paxson, Stream Control Transmission Protocol, RFC 2960, 436 October 2000. 438 [RFC3649] S. Floyd, HighSpeed TCP for Large Congestion Windows, 439 RFC 3649, September 2003. 441 [RFC3714] S. Floyd and J. Kempf, IAB Concerns Regarding Congestion 442 Control for Voice Traffic in the Internet, RFC 3714, March 2004. 444 [RFC3819] P. Karn, C. Bormann, G. Fairhurst, D. Grossman, R. Ludwig, 445 J. Mahdavi, G. Montenegro, J. Touch, and L. Wood, Advice for Internet 446 Subnetwork Designers, RFC 3819, July 2004 448 [RFC4340] Kohler, E., Handley, M., and S. Floyd, Datagram 449 Congestion Control Protocol (DCCP), RFC 4340, March 2006. 451 [RFC4782] S. Floyd, M. Allman, A. Jain, and P. Sarolahti, 452 Quick-Start for TCP and IP. RFC 4782, Experimental, January 453 2007. 455 [Tools] S. Floyd and E. Kohler, Tools for the Evaluation of 456 Simulation and Testbed Scenarios, Internet-draft 457 draft-irtf-tmrg-tools-03.txt, work in progress, December 2006. 459 [XCP] D. Katabi, M. Handley, and C. Rohrs, Congestion Control 460 for High Bandwidth-Delay Product Networks, Sigcomm 2002. 462 Authors' Addresses 464 Sally Floyd 465 ICIR (ICSI Center for Internet Research) 466 1947 Center Street, Suite 600 467 Berkeley, CA 94704-1198 468 Phone: +1 (510) 666-2989 469 Email: floyd at icir.org 470 URL: http://www.icir.org/floyd/ 472 Mark Allman 473 ICSI Center for Internet Research 474 1947 Center Street, Suite 600 475 Berkeley, CA 94704-1198 476 Phone: (440) 235-1792 477 Email: mallman at icir.org 478 URL: http://www.icir.org/mallman/ 480 Intellectual Property Statement 482 The IETF takes no position regarding the validity or scope of any 483 Intellectual Property Rights or other rights that might be claimed 484 to pertain to the implementation or use of the technology described 485 in this document or the extent to which any license under such 486 rights might or might not be available; nor does it represent that 487 it has made any independent effort to identify any such rights. 488 Information on the procedures with respect to rights in RFC 489 documents can be found in BCP 78 and BCP 79. 491 Copies of IPR disclosures made to the IETF Secretariat and any 492 assurances of licenses to be made available, or the result of an 493 attempt made to obtain a general license or permission for the use 494 of such proprietary rights by implementers or users of this 495 specification can be obtained from the IETF on-line IPR repository 496 at http://www.ietf.org/ipr. 498 The IETF invites any interested party to bring to its attention any 499 copyrights, patents or patent applications, or other proprietary 500 rights that may cover technology that may be required to implement 501 this standard. Please address the information to the IETF at 502 ietf-ipr@ietf.org. 504 Disclaimer of Validity 506 This document and the information contained herein are provided on 507 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 508 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 509 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 510 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 511 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 512 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 513 FOR A PARTICULAR PURPOSE. 515 Copyright Statement 517 Copyright (C) The IETF Trust (2007). This document is subject 518 to the rights, licenses and restrictions contained in BCP 78, and 519 except as set forth therein, the authors retain all their rights. 521 Acknowledgment 523 Funding for the RFC Editor function is currently provided by the 524 Internet Society.