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