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