idnits 2.17.1 draft-floyd-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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 365. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 342. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 349. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 355. ** 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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 24 instances of too long lines in the document, the longest one being 1 character in excess of 72. 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 (December 2006) is 6335 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) -- Obsolete informational reference (is this intentional?): RFC 2581 (Obsoleted by RFC 5681) == Outdated reference: A later version (-11) exists of draft-irtf-tmrg-metrics-04 Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Floyd 3 Internet-Draft M. Allman 4 Expires: June 2006 ICIR / ICSI 5 December 2006 7 Specifying New Congestion Control Algorithms 8 draft-floyd-tsvwg-cc-alt-00.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as 25 reference material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Copyright Notice 35 Copyright (C) The Internet Society (2006). 37 Abstract 39 The IETF's standard congestion control schemes have been widely 40 shown to be inadequate for various environments (e.g., high-speed or 41 wireless networks). Recent research has yielded many alternate 42 congestion control schemes. Using these new congestion control 43 schemes in the global Internet has possible ramifications to both 44 the network and to traffic using the currently standardized 45 congestion control. Therefore, the IETF must proceed with caution 46 when dealing with alternate congestion control proposals. The goal 47 of this document is to provide guidance for considering alternate 48 congestion control algorithms within the IETF. 50 TO BE DELETED BY THE RFC EDITOR UPON PUBLICATION: 52 Changes from draft-floyd-cc-alt-00.txt: 54 * Changed the name to draft-floyd-tsvwg-cc-alt-00.txt. 56 * Added a bullet about incremental deployment. Feedback from 57 Colin Perkins 59 * Clarified the fairness section; this section is not saying 60 that strict TCP-friendliness is a requirement. 62 * Clarified that as an alternative to Full Backoff, a flow 63 could stop sending when the packet drop rate is above a 64 certain threshold. 66 * Clarified that the Full Backoff bullet does not require 67 that different flows with different round-trip times 68 use the same criteria about when they should back off 69 to one packet per round-trip time or less. 71 * Added a paragraph about Informational RFCs. 73 * Added a bullet about response to transient events, including 74 routing events or moving from a private to a shared network. 76 END OF NOTES TO BE DELETED. 78 1. Introduction 80 This document provides guidelines for the IETF to use when 81 evaluating suggested congestion control algorithms that 82 significantly differ from the general congestion control principles 83 outlined in [RFC2914]. The guidance is intended to be useful to 84 authors proposing alternate congestion control and for the IETF 85 community when evaluating whether a proposal is appropriate for 86 publication in the RFC series. 88 This document does not give hard-and-fast rules for what makes for 89 an appropriate congestion control scheme. Rather, the document 90 provides a set of criteria that should be considered and weighed by 91 the IETF in the context of each proposal. The high-order criteria 92 for any new proposal is that a serious scientific study of the pros 93 and cons of the proposal needs to have been done such that the IETF 94 has a well rounded set of information to consider. 96 After initial studies, we encourage authors to write a specification 97 of their proposals for publication in the RFC series to allow others 98 to concretely understand and investigate the wealth of proposals in 99 this space. 101 2. Status 103 Following the lead of HighSpeed TCP, alternate congestion control 104 algorithms are expected to be published as "Experimental" RFCs until 105 such time that the community better understands the solution space. 106 Traditionally, the meaning of "Experimental" status has varied in 107 its use and interpretation. As part of this document we define two 108 classes of congestion control proposals that can be published with 109 the "Experimental" status. The first class is algorithms that are 110 judged to be safe to deploy in the global Internet and further 111 investigated in that environment. The second class is algorithms 112 that, while promising, are not deemed safe enough for deployment on 113 the Internet, but are being specified to facilitate investigations 114 via simulation and testbeds. 116 Each alternate congestion control algorithm published is required to 117 include a statement in the abstract indicating whether or not the 118 proposal is considered safe for use on the Internet. Each alternate 119 congestion control algorithm published is also required to include a 120 statement in the abstract describing environments where the protocol 121 is not recommended for deployment even though it may not be unsafe 122 for use. 124 As examples of such statements, [RFC3649] specifying HighSpeed TCP 125 includes a statement in the abstract stating that the proposal is 126 Experimental, but may be deployed in the current Internet. In 127 contrast, the Quick-Start document [QuickStart] includes a paragraph 128 in the abstract stating the the mechanism is only being proposed for 129 controlled environments. The abstract specifies environments where 130 the Quick-Start request would give false positives (and therefore 131 would be unsafe to deploy). The abstract also specifies 132 environments where packets containing the Quick-Start request could 133 be dropped in the network; in such an environment, Quick-Start would 134 not be unsafe to deploy, but deployment would still not be 135 recommended because it could cause unnecessary delays for the 136 connections attempting to use Quick-Start. 138 For researchers who are not ready to bring their congestion control 139 mechanisms to the IETF for standardization (either as Experimental 140 or as Proposed Standard), one possibility would be to submit an 141 internet-draft that documents the alternate congestion control 142 mechanism for the benefit of the IETF and IRTF communities. This 143 is particularly encouraged in order to get algorithm specifications 144 widely disseminated to facilitate further research. Such an 145 internet-draft could be submitted to be considered as Informational, 146 as a first step in the process towards standardization. Such a 147 document would also be expected to carry an explicit warning against 148 using the scheme in the global Internet. 150 3. Guidelines 152 As noted above, authors are expected to do a well-rounded 153 evaluations of the pros and cons of proposals brought to the IETF. 154 The following are guidelines to help authors and the IETF community. 155 Concerns that fall outside the scope of these guidelines are 156 certainly possible and these guidelines should not be used as a 157 check-list. 159 (1) Fairness to Standard TCP, SCTP, and DCCP. 161 In environments where standard congestion control is able to 162 make reasonable use of the available bandwidth the proposed 163 change should not significantly change this state. 165 For instance, in a situation where each of N flows uses 1/N of 166 the network capacity, a new congestion control scheme should not 167 significantly deviate from this state. For instance, a flow 168 using an alternate congestion controller that took half the 169 capacity and left each of the remaining N flows with 1/2N of the 170 capacity would be suspect. 172 We note that this bullet is not a requirement for strict 173 TCP-friendliness as a prerequisite for an alternate congestion 174 control mechanism to advance to Experimental. As an example, 175 HighSpeed TCP is a congestion control mechanism that is 176 Experimental, but that is not TCP-friendly in all environments. 178 (2) Using Spare Capacity. 180 Similar to point (1), alternate congestion control algorithms 181 may take up spare capacity in the network, but may not steal 182 significant amounts of capacity from flows using currently 183 standardized congestion control. 185 For instance, consider the case where N flows cannot naturally 186 use all the capacity and equally share one-third of the capacity 187 (with each flow using 1/3N of the capacity). A single flow 188 using an alternate congestion control scheme could use the 189 unused two-thirds of capacity. However, the flow using 190 alternate congestion control should not steal significant 191 amounts of additional capacity from the N standard flows. 193 (3) Difficult Environments. 195 An assessment of proposed algorithms in difficult environments 196 such as paths containing wireless links and paths with 197 reverse-path congestion. In addition, proposed algorithms 198 should be evaluated in situations where the bottleneck has high 199 and low levels of statistical multiplexing. 201 (4) Investigating a Range of Environments. 203 Similar to the last criteria, proposed alternate congestion 204 controllers should be assessed in a range of environments. For 205 instance, proposals should be investigated across a range of 206 bandwidths and round-trip times. A particularly important 207 aspect of evaluating a proposal for standardization is in 208 understanding where the algorithm breaks down. Therefore, 209 particular attention should be paid to extending the 210 investigation into areas where the proposal does not perform 211 well. 213 (5) Protection Against Congestion Collapse. 215 The alternate congestion control mechanism should either 216 stop sending when the packet drop rate exceeds some threshold 218 [RFC3714], or should include some notion of "full backoff". 219 For "full backoff", at some point the algorithm would 220 reduce the sending rate to one packet per round-trip time 221 and then exponentially backoff the time between single 222 packet transmissions if congestion persists. Exactly when 223 either "full backoff" or a pause in sending comes into play 224 will be algorithm-specific. However, this requirement is 225 crucial to protect the network in times of extreme congestion. 227 If "full backoff" is used, this bullet does not require 228 that the full backoff mechanism must be identical to that 229 of TCP. As an example, this bullet does not preclude 230 full backoff mechanisms that would give flows with 231 different round-trip times comparable bandwidth during 232 backoff. 234 (6) Fairness within the Alternate Congestion Control Algorithm. 236 In environments with multiple competing flows using the 237 alternate congestion control algorithm, the proposal should 238 explore how bandwidth is shared among the competing flows. 240 (7) Performance with Misbehaving Nodes and Outside Attackers. 242 The proposal should explore how the alternate congestion control 243 mechanism performs with misbehaving senders, receivers, or 244 routers. In addition, the proposal should explore how the 245 alternate congestion control mechanism performs with outside 246 attackers. This can be particularly important for congestion 247 control mechanisms that involve explicit feedback from routers 248 along the path. 250 (8) Responses to Sudden or Transient Events 252 The proposal should consider how the alternate congestion 253 control mechanism would perform in the presence of transient 254 events such as sudden congestion, a routing change, or a 255 mobility event. 257 (9) Incremental Deployment. 259 The proposal should discuss whether the alternate congestion 260 control mechanism allows for incremental deployment in the 261 targeted environment. If the alternate congestion control 262 mechanism is intended only for specific environments, the 263 proposal should consider how this intention is to be 264 carried out. 266 4. Conclusions 268 This document is intended as a guideline for researchers 269 in bringing congestion control mechanisms to the IETF to 270 be considered for Experimental status, and also as a 271 guideline to the IETF in evaluating such proposals. 273 5. Security Considerations 275 This document does not represent a change to any aspect of the 276 TCP/IP protocol suite and therefore does not directly impact 277 Internet security. The implementation of various facets of the 278 Internet's current congestion control algorithms do have security 279 implications (e.g., as outlined in [RFC2581]). Alternate congestion 280 control schemes should be mindful of such pitfalls, as well. 282 6. IANA Considerations 284 This document does not require any IANA action. 286 Acknowledgments 288 Discussions with Lars Eggert and Aaron Falk seeded this document. 289 Thanks to Colin Perkins for feedback. This document also draws 290 from [Metrics]. Thanks to Colin Perkins for feedback. 292 Normative References 294 Informative References 296 [RFC2581] M. Allman, V. Paxson, and W. Stevens, TCP Congestion 297 Control, RFC 2581, Proposed Standard, April 1999. 299 [RFC2914] S. Floyd, Congestion Control Principles, RFC 2914, Best 300 Current Practice, September 2000. 302 [RFC3649] S. Floyd, HighSpeed TCP for Large Congestion Windows, 303 RFC 3649, September 2003. 305 [RFC3714] S. Floyd and J. Kempf, IAB Concerns Regarding Congestion 306 Control for Voice Traffic in the Internet, RFC 3714, March 2004. 308 [Metrics] S. Floyd, Metrics for the Evaluation of Congestion 309 Control Mechanisms. Internet-draft draft-irtf-tmrg-metrics-04, 310 work in progress, August 2006. 312 [QuickStart] S. Floyd, M. Allman, A. Jain, and P. Sarolahti, 313 Quick-Start for TCP and IP. Internet-draft 314 draft-ietf-tsvwg-quickstart-07.txt, work in progress, October 315 2006. Approved for Experimental. 317 Authors' Addresses 319 Sally Floyd 320 Phone: +1 (510) 666-2989 321 ICIR (ICSI Center for Internet Research) 322 Email: floyd@icir.org 323 URL: http://www.icir.org/floyd/ 325 Mark Allman 326 ICSI Center for Internet Research 327 1947 Center Street, Suite 600 328 Berkeley, CA 94704-1198 329 Phone: (440) 235-1792 330 Email: mallman@icir.org 331 URL: http://www.icir.org/mallman/ 333 Intellectual Property Statement 335 The IETF takes no position regarding the validity or scope of any 336 Intellectual Property Rights or other rights that might be claimed 337 to pertain to the implementation or use of the technology described 338 in this document or the extent to which any license under such 339 rights might or might not be available; nor does it represent that 340 it has made any independent effort to identify any such rights. 341 Information on the procedures with respect to rights in RFC 342 documents can be found in BCP 78 and BCP 79. 344 Copies of IPR disclosures made to the IETF Secretariat and any 345 assurances of licenses to be made available, or the result of an 346 attempt made to obtain a general license or permission for the use 347 of such proprietary rights by implementers or users of this 348 specification can be obtained from the IETF on-line IPR repository 349 at http://www.ietf.org/ipr. 351 The IETF invites any interested party to bring to its attention any 352 copyrights, patents or patent applications, or other proprietary 353 rights that may cover technology that may be required to implement 354 this standard. Please address the information to the IETF at 355 ietf-ipr@ietf.org. 357 Disclaimer of Validity 359 This document and the information contained herein are provided on 360 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 361 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 362 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 363 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 364 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 365 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 367 Copyright Statement 369 Copyright (C) The Internet Society (2006). This document is subject 370 to the rights, licenses and restrictions contained in BCP 78, and 371 except as set forth therein, the authors retain all their rights. 373 Acknowledgment 375 Funding for the RFC Editor function is currently provided by the 376 Internet Society.