idnits 2.17.1 draft-irtf-iccrg-cc-rfcs-07.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1247. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1258. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1265. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1271. 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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 209: '... SHOULD NOT originate ICMP Source...' 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 (October 30, 2008) is 5658 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC0889' is defined on line 994, but no explicit reference was found in the text == Unused Reference: 'RFC0896' is defined on line 997, but no explicit reference was found in the text == Unused Reference: 'RFC0970' is defined on line 1000, but no explicit reference was found in the text == Unused Reference: 'RFC1016' is defined on line 1003, but no explicit reference was found in the text == Unused Reference: 'RFC1122' is defined on line 1007, but no explicit reference was found in the text == Unused Reference: 'RFC1254' is defined on line 1010, but no explicit reference was found in the text == Unused Reference: 'RFC1958' is defined on line 1020, but no explicit reference was found in the text == Unused Reference: 'RFC2001' is defined on line 1023, but no explicit reference was found in the text == Unused Reference: 'RFC2488' is defined on line 1056, but no explicit reference was found in the text == Unused Reference: 'RFC2581' is defined on line 1060, but no explicit reference was found in the text == Unused Reference: 'RFC2884' is defined on line 1063, but no explicit reference was found in the text == Unused Reference: 'RFC2887' is defined on line 1067, but no explicit reference was found in the text == Unused Reference: 'RFC2914' is defined on line 1071, but no explicit reference was found in the text == Unused Reference: 'RFC3048' is defined on line 1084, but no explicit reference was found in the text == Unused Reference: 'RFC3135' is defined on line 1092, but no explicit reference was found in the text == Unused Reference: 'RFC3150' is defined on line 1096, but no explicit reference was found in the text == Unused Reference: 'RFC3155' is defined on line 1100, but no explicit reference was found in the text == Unused Reference: 'RFC3366' is defined on line 1114, but no explicit reference was found in the text == Unused Reference: 'RFC3426' is defined on line 1118, but no explicit reference was found in the text == Unused Reference: 'RFC3439' is defined on line 1121, but no explicit reference was found in the text == Unused Reference: 'RFC3449' is defined on line 1128, but no explicit reference was found in the text == Unused Reference: 'RFC3450' is defined on line 1132, but no explicit reference was found in the text == Unused Reference: 'RFC3540' is defined on line 1136, but no explicit reference was found in the text == Unused Reference: 'RFC3714' is defined on line 1147, but no explicit reference was found in the text == Unused Reference: 'RFC3738' is defined on line 1151, but no explicit reference was found in the text == Unused Reference: 'RFC3819' is defined on line 1157, but no explicit reference was found in the text == Unused Reference: 'RFC3926' is defined on line 1162, but no explicit reference was found in the text == Unused Reference: 'RFC3940' is defined on line 1166, but no explicit reference was found in the text == Unused Reference: 'RFC3941' is defined on line 1170, but no explicit reference was found in the text == Unused Reference: 'RFC4336' is defined on line 1175, but no explicit reference was found in the text == Unused Reference: 'RFC4342' is defined on line 1186, but no explicit reference was found in the text == Unused Reference: 'RFC4654' is defined on line 1200, but no explicit reference was found in the text == Unused Reference: 'RFC5033' is defined on line 1204, but no explicit reference was found in the text == Unused Reference: 'RFC5166' is defined on line 1207, but no explicit reference was found in the text == Unused Reference: 'Riz00' is defined on line 1210, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-tcpm-icmp-attacks-03 == Outdated reference: A later version (-03) exists of draft-moncaster-tcpm-rcv-cheat-01 -- Obsolete informational reference (is this intentional?): RFC 896 (Obsoleted by RFC 7805) -- Obsolete informational reference (is this intentional?): RFC 2001 (Obsoleted by RFC 2581) -- Obsolete informational reference (is this intentional?): RFC 2309 (Obsoleted by RFC 7567) -- Obsolete informational reference (is this intentional?): RFC 2414 (Obsoleted by RFC 3390) -- Obsolete informational reference (is this intentional?): RFC 2481 (Obsoleted by RFC 3168) -- Obsolete informational reference (is this intentional?): RFC 2581 (Obsoleted by RFC 5681) -- Obsolete informational reference (is this intentional?): RFC 2960 (Obsoleted by RFC 4960) -- Obsolete informational reference (is this intentional?): RFC 3448 (Obsoleted by RFC 5348) -- Obsolete informational reference (is this intentional?): RFC 3450 (Obsoleted by RFC 5775) -- Obsolete informational reference (is this intentional?): RFC 3926 (Obsoleted by RFC 6726) -- Obsolete informational reference (is this intentional?): RFC 3940 (Obsoleted by RFC 5740) -- Obsolete informational reference (is this intentional?): RFC 3941 (Obsoleted by RFC 5401) -- Obsolete informational reference (is this intentional?): RFC 4614 (Obsoleted by RFC 7414) Summary: 2 errors (**), 0 flaws (~~), 38 warnings (==), 20 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Welzl 3 Internet-Draft University of Innsbruck 4 Intended status: Informational W. Eddy 5 Expires: May 3, 2009 Verizon 6 October 30, 2008 8 Congestion Control in the RFC Series 9 draft-irtf-iccrg-cc-rfcs-07 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 3, 2009. 36 Abstract 38 This document is an informational snapshot produced by the IRTF's 39 Internet Congestion Control Research Group (ICCRG). It provides a 40 survey of congestion control topics described by documents in the RFC 41 series. This does not modify or update the specifications or status 42 of the RFC documents that are discussed. It may be used as a 43 reference or starting point for the future work of the research 44 group, especially in noting gaps or open issues in the current IETF 45 standards. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Architectural Documents . . . . . . . . . . . . . . . . . . . 6 51 3. TCP Congestion Control . . . . . . . . . . . . . . . . . . . . 10 52 4. Challenging Link and Path Characteristics . . . . . . . . . . 11 53 5. End-Host and Router Cooperative Signalling . . . . . . . . . . 14 54 5.1. Explicit Congestion Notification . . . . . . . . . . . . . 14 55 5.2. Quick-Start . . . . . . . . . . . . . . . . . . . . . . . 16 56 6. Non-TCP Unicast Congestion Control . . . . . . . . . . . . . . 17 57 7. Multicast Congestion Control . . . . . . . . . . . . . . . . . 20 58 8. Guidance for Developing and Analyzing Congestion Control 59 Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . 23 60 9. Historic Interest . . . . . . . . . . . . . . . . . . . . . . 24 61 10. Security Considerations . . . . . . . . . . . . . . . . . . . 26 62 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 63 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 64 13. Informative References . . . . . . . . . . . . . . . . . . . . 29 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 66 Intellectual Property and Copyright Statements . . . . . . . . . . 36 68 1. Introduction 70 In this document, we define congestion control as the feedback-based 71 adjustment of the rate at which data is sent into the network. 72 Congestion control is an indispensible set of principles and 73 mechanisms for maintaining the stability of the Internet. Congestion 74 control has been closely associated with TCP since 1988 [Jac88], but 75 there has also been a great deal of congestion control work outside 76 of TCP (e.g. for real-time multimedia applications, multicast, and 77 router-based mechanisms). Several such proposals have been produced 78 within the IETF and published as RFCs, along with RFCs that give 79 architectural guidance (e.g. by pointing out the importance of 80 performing some form of congestion control). Several of these 81 mechanisms are in use within the Internet. 83 When designing a new Internet transport protocol, it is therefore 84 important to not only understand how congestion control works in TCP 85 but also have a broader understanding of the other congestion control 86 RFCs -- some give guidance, some of them describe mechanisms which 87 may have a direct influence on a newly designed protocol, and some of 88 them may only be "related work" worth knowing about. The purpose of 89 this document is to facilitate and encourage this search for 90 knowledge by providing an overview of RFCs related to congestion 91 control that have been published thus far. This document is a 92 product of the IRTF's Internet Congestion Control Research Group 93 (ICCRG). It was developed because a strong grasp of the existing 94 literature should benefit further ICCRG work. The ICCRG developed 95 consensus on the content of this document during a two-year 96 development period based on review comments and ICCRG mailing list 97 discussions. A list of the main review contributors is contained in 98 the Acknowledgements section of this document. 100 While the ICCRG agreed to the document's production, any opinions 101 expressed are the authors' own, and as this document is not an IETF 102 publication, it does not update or modify the status of any published 103 RFCs. The format of this document is similar to an annotated 104 bibliography. Although host and router requirements for congestion 105 control functions are discussed, this is only an informational 106 document and does not contain any formal standards bearing of its 107 own. 109 Congestion control is a large and active topic, and so the scope of 110 this document is limited to published RFCs and a small number of 111 current working group drafts. This allows the document to focus on 112 congestion control principles and mechanisms that are among the most 113 well-supported, well-accepted, or widely-used. Significant 114 contributions to this subject also exist in both the academic 115 literature and in the form of individual submission Internet-drafts, 116 however we exclude these from this study. In many cases the RFC 117 describing some mechanism will contain references to relevant 118 academic publications in journals or conference proceedings that 119 presented the research and validation of the mechanism. For 120 instance, RFC 2581 cites Jacobson's 1988 SIGCOMM paper that has a 121 less standards-oriented but more illustrative treatment and 122 explanation of some of the mechanisms in RFC 2581. 124 The majority of the documents discussed here pertain to end-host 125 based congestion control. Many network-based mechanisms, such as a 126 number of queue management algorithms, do not require any protocol 127 exchanges between elements, but merely operate within a single host 128 or router. Thus, network-based congestion control mechanisms have 129 often not been described in any RFC, as they generally fall under the 130 domain of implementation details that do not influence 131 interoperability. 133 There are many RFCs related to Quality of Service (QoS), especially 134 within the Integrated Services and Differentiated Services frameworks 135 [RFC1633] [RFC2475] [RFC2998]. These QoS RFCs themselves deserve a 136 similar bibliography as this document provides for congestion 137 control. We specifically do not include the vast amount of QoS work 138 into the scope of this document, as it is a full field in its own 139 right, and deals with issues that are mostly orthogonal to end-host 140 congestion control and router queue management. Although there can 141 certainly be interactions between QoS and congestion control 142 mechanisms, scheduling mechanisms used to implement QoS (on either 143 per-flow or an aggregate basis), for instance, can be used 144 independently of the end-host congestion control and queue management 145 functions also in use. Similar arguments can be made for traffic- 146 shaping, admission control, and other functions that are intended for 147 QoS, and only side-notes for congestion control. 149 A similar argument can be made for excluding consideration of the 150 media access control (MAC) layer protocols used by the links 151 throughout a path. Although the MAC protocols implement various 152 forms of resolving contention for shared links (and sometimes offer 153 QoS services), these are also distinct from end-to-end congestion 154 control. Furthermore, MAC protocols are not typically discussed in 155 the RFC series, but are defined in outside documents (e.g. IEEE 156 standards), since the IETF does not generally work on link layers 157 themselves. Few, if any, of the RFCs that describe mappings of IP 158 onto various link layers directly discuss congestion control. 160 To organize the subject matter in this document, the content is 161 classified into several broad categories. First, we list documents 162 relating to Internet architecture and general architectural concepts 163 in Section 2. Next, the congestion control algorithms used in the 164 TCP transport protocol are discussed in Section 3. Interactions 165 between link properties and mechanisms with the kinds of algorithms 166 and heuristics used within end-to-end congestion control are covered 167 in Section 4. One method that has been developed by the IETF (and 168 deployed to some extent) for allowing network-based and host-based 169 congestion control to interact without dropping packets is the 170 subject of Section 5.1. The congestion control algorithms used by 171 unicast transport protocols other than TCP are described in 172 Section 6. Work on congestion control for multicast transports and 173 applications is listed in Section 7. RFCs that give guidance to 174 developers of new algorithms are discussed in Section 8. Finally, 175 documents that have historic significance, but perhaps not current 176 direct technical application have been classified into Section 9. 177 Note that the use of the term "historic" here has nothing to do with 178 the IETF's formal classification of documents as having "Historic" 179 status. 181 2. Architectural Documents 183 Some documents in this section contain architectural guidance and 184 concerns, while others specify congestion control related mechanisms 185 which are broadly applicability and have impacts on more than a 186 single class of congestion control techniques. Some of these 187 documents are direct products of the Internet Architecture Board 188 (IAB), giving their guidance on specific aspects of congestion 189 control in the Internet. 191 RFC 1122: "Requirements for Internet Hosts -- Communication Layers" 192 (October 1989) 194 RFC 1122 formally mandates that hosts perform congestion control. 195 For TCP, several congestion control features are described and 196 listed as required elements of conforming implementations, and for 197 UDP, RFC 1122 leaves congestion control as an issue for higher- 198 layered protocols. Although sending and reacting to ICMP Source 199 Quench packets is no longer recommended [RFC1812] [Gont08], the 200 rest of the congestion control guidance in this RFC is still a 201 basis for several current practices in TCP implementations. 203 RFC 1812: "Requirements for IP Version 4 Routers" (June 1995) 205 Numerous issues relevant to router behavior are discussed in RFC 206 1812, and requirements for routers to support are prescribed 207 within the document. Portions of RFC 1812 that are particularly 208 relevant to congestion control include the directive that routers 209 SHOULD NOT originate ICMP Source Quench messages, discussion of 210 precedence in queueing, and section 5.3.6 titled "Congestion 211 Control" that recommends sizing buffers as a function of the 212 product of the bandwidth of the link times the path delay of the 213 flows using the link, and advises on the implementation of active 214 queue management techniques. 216 RFC 1958: "Architectural Principles of the Internet" (June 1996) 218 Several guidelines for network systems design that have proven 219 useful in the evolution of the Internet are sketched in this 220 document. Congestion control is not specifically mentioned or 221 alluded to, but the general principles apply to congestion 222 control. For instance, performing end-to-end functions at end 223 nodes, lack of centralized control, heterogeneity, scalability, 224 simplicity, avoiding options and parameters, etc. are all valid 225 concerns in the design and assessment of congestion control 226 schemes for the Internet. 228 RFC 2140: "TCP Control Block Interdependence" (April 1997) 230 RFC2140 suggests that TCP connections between the same endpoints 231 might share some information, including their congestion control 232 state. To some degree, this is done in practice by a few current 233 operating systems; for example, Linux currently has a destination 234 cache with this information, but this behavior is not yet formally 235 standardized or recognized as a best practice by the IETF. 237 RFC 2309: "Recommendations on Queue Management and Congestion 238 Avoidance in the Internet" (April 1998) 240 This document briefly discusses the history of congestion and the 241 origin of congestion control in the Internet. The focus is mainly 242 on network- or router-based queue management algorithms. This RFC 243 recommends to test, standardize and deploy Active Queue Management 244 (AQM) in routers; it provides an overview of one such mechanism, 245 Random Early Detection (RED) and explains how and why AQM 246 mechanisms can improve the performance of the Internet. Finally, 247 this document explains the danger of a possible "congestion 248 collapse" from unresponsive flows and makes a strong 249 recommendation to develop and eventually deploy router mechanisms 250 to protect the Internet from such traffic. 252 Today, the advice in this document has been followed to some 253 extent. Hardware and software vendors have been receptive, and 254 AQM techniques are widely available in many popular dedicated 255 commercial router products and even in more general operating 256 systems that are sometimes used as routers. However, AQM 257 techniques may not be enabled in default configurations of these 258 systems, and it is often left to users and network engineers to 259 enable and configure AQM mechanisms when desired. In some cases, 260 enabling QoS mechanisms on a device also enables AQM mechanisms by 261 default. The number of production routers that actually have 262 these AQM features enabled is an open question. 264 RFC 2914: "Congestion Control Principles" (September 2000) 266 This document is an explanation of the principles of congestion 267 control, and the IETF's Best Current Practices for congestion 268 control design. It points out that there are an increasing number 269 of applications which do not use TCP, and elaborates on the 270 importance of performing congestion control for such traffic in 271 order to prevent congestion collapse. The TCP Reno congestion 272 control mechanisms are described as an example of end-to-end 273 congestion control within transport protocols. 275 SCTP is one example of a non-TCP transport protocol that 276 implements congestion control based on these principles. The 277 developments of TFRC [RFC3448] and DCCP [RFC4340] are attempts to 278 provide useful tools implementing those principles for 279 applications with needs similar to streaming media, where TCP's 280 reactions are too fast. It would be beneficial for users and the 281 Internet itself if these carefully designed tools become widely 282 deployed in place of other ad-hoc schemes that may not be well- 283 grounded in the congestion control principles. This replacement 284 process is ongoing and not yet complete. Appropriate and usable 285 congestion control schemes for non-TCP flows continue to be an 286 open research area. 288 RFC 3124: "The Congestion Manager" (June 2001) 290 This document specifies the Congestion Manager, an end-system 291 service that realizes congestion control on a per-host-pair rather 292 than a per-connection basis, which may be a more appropriate way 293 to carry out congestion control. Using the Congestion Manager, 294 multiple streams between two hosts (which may include TCP flows) 295 can adapt to network congestion in a unified fashion. 297 This proposal is related to RFC 2140, discussed above, but with a 298 wider scope than TCP. Because some pieces of its supporting 299 architecture have not yet been specified, the Congestion Manager's 300 techniques are not commonly used today and have not been widely 301 implemented and deployed yet beyond experimental stacks. Sharing 302 of congestion and path information between individual connections 303 continues to be an open research area with branches in detecting 304 shared bottlenecks when using multiple paths, caching of old state 305 for faster startup, and sharing of current state and feedback. 307 RFC 3426: "General Architectural and Policy Considerations" (November 308 2002) 310 RFC 3426 lists a number of questions that can be answered for a 311 particular technical solution to determine its architectural 312 impact and desirability. These are valid for congestion control 313 mechanisms, and end-point congestion management is used as an 314 example case-study several times in RFC 3426. Two salient 315 questions that RFC 3426 advises asking about proposed mechanisms 316 is why they are needed in addition to existing protocols, and why 317 they are needed at a certain layer rather than at other layers. 318 These are particularly relevant for congestion control mechanisms 319 since several already exist and since they can span network, 320 transport, and application layers. 322 RFC 3439: "Some Internet Architectural Guidelines and Philosophy" 323 (December 2002) 325 This document supplements RFC 1958. Simplicity is stressed, as 326 the unpredictable results of complexity (due to amplification and 327 coupling) are described. Congestion control issues stemming from 328 layering interactions between transport and lower protocols are 329 presented, as well as other items relevant to congestion control, 330 including asymmetry and the "myth of over-provisioning". 332 RFC 3714: "IAB Concerns Regarding Congestion Control for Voice 333 Traffic in the Internet" (March 2004) 335 This document can be seen as a follow-up to the concerns that were 336 discussed in RFC 2914. It expresses the IAB's concern over the 337 lack of effective end-to-end congestion control for best-effort 338 voice traffic, which is noted as being a current service with 339 growing demand. An example of a VoIP connection between Atlanta, 340 Georgia, USA, and Nairobi, Kenya, is given, where a single VoIP 341 call consumed more than half of the access link capacity (which is 342 normally shared across several different users). This example is 343 used as the basis for further discussion, making it clear that 344 using some form of congestion control for VoIP traffic is highly 345 recommended. 347 3. TCP Congestion Control 349 The TCP specifications found in RFC 793 and its predecessors did not 350 contain any discussion of using or managing a congestion window. 351 Other than a simple retransmission timeout and flow control through 352 the advertised receive window, TCP implementations based only on RFC 353 793 do not contain congestion control. As several congestion 354 collapse events occurred on the Internet, it was later realized that 355 congestion control was needed. The host requirements in RFC 1122 356 require conforming TCP implementations to implement Jacobson's slow 357 start and congestion avoidance algorithms (later specified in RFC 358 2001 and then 2581). RFC 1122 also recommends several other 359 behaviors that influence congestion control like the Nagle algorithm, 360 delayed acknowledgements, Jacobson's RTO estimation algorithm, and 361 exponential backoff of the retransmission timer. 363 Basic TCP congestion control is defined in RFC 2581, with many other 364 RFCs that specify ancillary modifications and enhancements. RFC 2581 365 obsoletes the first proposed standard for TCP congestion control in 366 RFC 2001. These two RFCs document the mechanisms that had already 367 been in common use by TCP implementations for many years. The reader 368 may refer to the TCP Roadmap [RFC4614] for more information on the 369 RFCs that specifically describe TCP congestion control, as this 370 material is not replicated here. 372 Recently, significant effort has been put into experimental TCP 373 congestion control modifications for obtaining high throughput with 374 reduced startup and recovery times. RFCs have been published on some 375 of these modifications, including HighSpeed TCP [RFC3649], and 376 Limited Slow-Start [RFC3742], but high rate congestion control 377 mechanisms are still considered an open issue in congestion control 378 research. Other schemes have been published as Internet-Drafts or 379 been discussed a little by the IETF, but much of the work in this 380 area has not been adopted within the IETF yet, so the majority of 381 this work is outside the RFC series and may be discussed in other 382 products of the ICCRG. 384 At the time of writing, the IETF's TCP Maintenance and Minor 385 Extensions Working Group (TCPM) was developing an update to RFC 2581 386 to incorporate small changes from other documents and advance TCP 387 congestion control mechanisms on the IETF standards track. The 388 update also clarifies and revises some points. These include the 389 definition of a duplicate ACK, initial congestion window and slow 390 start threshold values, behavior in response to retransmission 391 timeouts, the use of the limited transmit mechanism, and security 392 with regards to misbehaving receivers that practice ACK division. 394 4. Challenging Link and Path Characteristics 396 Links with large and/or variable bandwidth-delay products have 397 traditionally been problematic for congestion control schemes because 398 they can distort the properties of the feedback loop. Links that 399 either expose a high rate of packet losses to the upper layers, or 400 use highly-persistent retransmission mechanisms to prevent losses 401 also cause problems with some of the standard congestion control 402 mechanisms. The documents in this section discuss challenging link 403 characteristics; many of them were written by the "Performance 404 Implications of Link Characteristics" (PILC) Working Group. 406 While these documents often refer to specific problems with TCP, the 407 link characteristics that they describe can be expected to affect 408 other congestion control mechanisms too. In particular, interactions 409 between link properties and TCP congestion control will be shared by 410 other protocols that use the similar congestion control behavior, 411 such as SCTP [RFC2960] and DCCP with CCID 2 [RFC4341] (see 412 Section 6), and should be taken into consideration by designers of 413 congestion control mechanisms which utilize the same kind of feedback 414 as TCP. 416 Some RFCs only make recommendations regarding the implementation and 417 configuration of TCP based upon characteristics of special links. As 418 these RFCs are so closely connected to the specification of TCP 419 itself, they are not included in this document, but are listed in the 420 TCP Roadmap [RFC4614]. 422 RFC 2488: "Enhancing TCP Over Satellite Channels using Standard 423 Mechanisms" (January 1999) 425 The summary of recommendations in this document came from the 426 TCPSAT working group, whose goal was to identify the performance 427 problems that TCP may have over satellite links and suggest 428 mitigations. The document explains several ways that existing 429 standards can be applied to improve the performance of basic TCP 430 congestion control over paths with characteristics similar to 431 those involving satellite links. 433 RFC 3135: "Performance Enhancing Proxies Intended to Mitigate Link- 434 Related Degradations" (June 2001) 436 This document is a survey of Performance Enhancing Proxies (PEPs) 437 often employed to improve degraded TCP performance caused by 438 characteristics of specific link environments, for example, in 439 satellite, wireless WAN, and wireless LAN environments. Different 440 types of Performance Enhancing Proxies are described as well as 441 the mechanisms used to improve performance. While there is a 442 specific focus on TCP in this document, PEPs can operate on any 443 protocol, and the performance enhancements that PEPs achieve are 444 often closely related to congestion control. 446 The use of PEPs has architectural implications as they sometimes 447 violate end-to-end assumptions and can add complexity to the inner 448 portions of a network. Certain types of PEPs are commonly used 449 today in satellite or long-distance networking because it is 450 easier to insert a small number of PEPs near problematic links 451 than to upgrade the TCP implementations on all the end hosts that 452 might use those links. One down-side is that their deployment 453 raises some issues when introducing new or updated CC methods into 454 these deployed networks, since the PEPs may be operating with 455 undocumented algorithms, making assumptions about the end-host CC 456 behavior, and/or altering packet fields that will affect the end- 457 host CC behavior. 459 RFC 3150: "End-to-end Performance Implications of Slow Links" (July 460 2001) 462 This document makes performance-related recommendations for users 463 of network paths that traverse "very low bit-rate" links. It 464 includes a discussion of interactions between such links and TCP 465 congestion control. 467 RFC 3155: "End-to-end Performance Implications of Links with Errors" 468 (August 2001) 470 Under the premise that several types of PEP have undesirable 471 implications, RFC 3155 recommends end-to-end alternatives for 472 improving TCP performance over paths with error-prone links. 474 RFC 3366: "Advice to link designers on link Automatic Repeat reQuest 475 (ARQ)" (August 2002) 477 Link-layer ARQ techniques are a popular means to increase the 478 robustness of a particular links to transmission errors via 479 retransmission and acknowledgement mechanisms. As this RFC 480 explains, ARQ techniques on a link can interact poorly with TCP's 481 end-to-end congestion control if they lead to additional delay 482 variation or reordering. This RFC gives some advice on limiting 483 the extent of these types of problematic interactions. The proper 484 balance between end-to-end and link-layer reliability mechanisms 485 is still an open research issue that has been explored in many 486 academic papers outside the IETF. 488 RFC 3449: "TCP Performance Implications of Network Path Asymmetry" 489 (December 2002) 491 This document describes performance limitations of TCP when the 492 capacity of the ACK path is limited. Several techniques to aid 493 TCP in these circumstances are recommended as Best Current 494 Practices, particularly ACK congestion control and sender pacing 495 are relevant to other non-TCP congestion control schemes, outside 496 the scope of this document. For instance, in the design of the 497 RMT protocols for multicast, preventing ACK-implosion at multicast 498 sources can be seen as a form of ACK congestion control. 500 RFC 3481: "TCP over Second (2.5G) and Third (3G) Generation Wireless 501 Networks" (February 2003) 503 Among other issues, some mobile data systems exhibit delay spikes, 504 handovers, and bandwidth oscillation. RFC 3481 describes the 505 problems that these conditions cause for TCP congestion control 506 and how some TCP extensions can be used to mitigate them. 508 RFC 3819: "Advice for Internet Subnetwork Designers" (July 2004) 510 Several issues in link design and optimization for carrying IP 511 traffic are discussed in this document, which recommends Best 512 Current Practices. Many of these principles are motivated by 513 properties of TCP, but most of them also apply to other transport- 514 layer congestion control techniques as well. 516 5. End-Host and Router Cooperative Signalling 518 Some RFCs define mechanisms that allow routers to add signalling 519 information to packets that makes the network's congestion state less 520 of a mystery to end-host congestion controllers. Routers supporting 521 these can signal information about the current congestion state to 522 flows in-band, providing faster and finer-grained information than 523 inference-based methods. Two examples of this are discussed in this 524 section; the first directs sources to slow down in order to avoid 525 losses, and the other assists in determining an appropriate starting 526 rate for new flows. 528 5.1. Explicit Congestion Notification 530 Traditionally, under congestion, IP routers enque packets until some 531 limit is reached, at which point packets are dropped. TCP, and other 532 IETF transport protocols, use a stream of acknowledgements to infer 533 these losses and take congestion control action. This section 534 describes a more advanced way to signal congestion to sources before 535 packet-dropping is required. 537 There are two Explicit Congestion Notification (ECN) bits in the IP 538 header that enable an AQM mechanism (see [RFC2309] or Section 2) to 539 convey congestion information to endpoints without dropping packets. 540 This can significantly reduce the losses experienced by transport 541 endpoints if they are responsive to ECN. While ECN is most 542 frequently discussed in the context of TCP (and therefore included in 543 the TCP Roadmap [RFC4614]), its applicability is broader, and ECN use 544 has also been specified for protocols such as DCCP and SCTP. 546 RFC 2481: "A Proposal to add Explicit Congestion Notification (ECN) 547 to IP" (January 1999) - Obsoleted by RFC 3168 549 This historic document introduced ECN into the RFC series, 550 describing when the Congestion Experienced (CE) bit in the IP 551 header should be set in routers, and what modifications are needed 552 to TCP to make it ECN-capable. It includes a discussion of issues 553 related to nodes and routers that are non-compliant, IPSec 554 tunnels, and dropped or corrupted packets as well as a summary of 555 related work. Many of these issues will also be faced by 556 operators trying to deploy other network-based congestion control 557 methods. RFC 2481 has been obsoleted by RFC 3168. 559 RFC 2884: "Performance Evaluation of Explicit Congestion Notification 560 (ECN) in IP Networks" (July 2000) 562 This document presents a performance study of ECN as specified in 564 [RFC2481] using an implementation on the Linux Operating System. 565 The experiments focused on ECN for both bulk and transactional 566 transfers, showing that there is improvement in throughput over 567 TCP without ECN in the case of bulk transfers and substantial 568 improvement for transactional transfers. Studies like this help 569 to build the community's confidence that extensions like ECN are 570 both safe and valuable. Similar RFCs helped the community accept 571 larger initial windows for TCP [RFC2414][RFC2415][RFC2416]. 573 RFC 3168: "The Addition of Explicit Congestion Notification (ECN) to 574 IP" (September 2001) 576 This document, which obsoletes [RFC2481], specifies the 577 incorporation of ECN into TCP and IP. One notable change in this 578 significantly extended specification is the definition of a bit 579 combination that was not defined in [RFC2481], which can be used 580 to realize a nonce that would prevent a receiver from falsely 581 claiming that there was no congestion. Potential issues related 582 to ECN are discussed at length, including those already included 583 in [RFC2481] and backwards compatibility with implementations that 584 would follow the specification in the obsoleted document. 586 ECN, as specified in RFC 3168, is implemented in several popular 587 router and end host platforms. It is in active use, to at least 588 some extent. Problems with ECN "blackholes" (Internet routers 589 misconfigured to discard packets with ECN-capable bits set) were 590 discovered when ECN was enabled by default in some end host 591 operating systems. Fears about the persisting presence of these 592 blackholes may currently be keeping ECN from being used by default 593 in many end host operating systems even though it is implemented 594 as an option within them. Some measurements on ECN support and 595 usability are available [PF01][MAF04][MAF05]. 597 RFC 3540: "Robust Explicit Congestion Notification (ECN) Signaling 598 with Nonces" (June 2003) 600 This document specifies a nonce mechanism that uses an ECN bit 601 combination that is not used in [RFC2481], but that is specified 602 in [RFC3168] to allow a one-bit ECN nonce. This nonce mechanism 603 includes a Nonce Sum (NS) field in the TCP header so that senders 604 can ensure that ACKs that do not indicate congestion are credible. 605 The mechanism improves the robustness of congestion control by 606 preventing receivers from exploiting ECN to gain an unfair share 607 of network bandwidth. 609 This nonce technique is not understood to have been widely 610 implemented or deployed, and there has been some discussion as to 611 whether the mechanism is really effective or is the best use of 612 these bits (see emails to the IETF TSVWG mailing list, in the 613 thread "ECN nonce snag in TCP ESTATS MIB" from December 2006 - 614 January 2007, or [MBJ07]). 616 5.2. Quick-Start 618 RFC 4782: "Quick-Start for TCP and IP" (January 2007) 620 Quick-Start provides a way for hosts to ask routers to help them 621 select an initial sending rate, and use this rate rather than the 622 traditional small initial congestion window and slow-start 623 algorithm. RFC 4782 describes the Quick-Start mechanism and its 624 use with TCP. In addition to discussing the benefits of Quick- 625 Start, the document also discusses several limitations of the 626 Quick-Start technique with respect to some types of tunnels in use 627 over the Internet today and other potential costs of Quick-Start 628 including those related to router design. Analysis of the effects 629 of misbehaving entities and appendices containing design rationale 630 and related work are also notably present in this RFC. 632 Many of the issues discussed in RFC 4782, including router 633 architecture, network design / tunnels, and misbehaving agents are 634 all challenges relevant to other proposals that try to add router 635 assistance into the network. The consideration of these issues 636 present in the document can be illustrative for other protocol 637 designers, even if they are not interested in Quick-Start itself. 639 6. Non-TCP Unicast Congestion Control 641 In the past, TCP dominated Internet traffic, as it was used for many 642 of the popular applications (email, web browsing, file transfer, 643 remote login, etc.). The majority of early congestion control work 644 focused on TCP, and the introduction of congestion control into TCP 645 alone is often credited with saving the Internet from additional 646 congestion collapse events. Today, TCP has been joined by other 647 transport protocols (e.g. custom UDP-based protocols, SCTP, DCCP, RTP 648 over UDP [RFC3550], etc.), and so having properly functioning 649 congestion control within these other protocols is important for the 650 Internet's health (as explained in RFC 3714, for instance, or see the 651 discussion of the "congestion control arms race" scenario in RFC 652 2914). Documents that describe unicast congestion control methods 653 for non-TCP transport protocols have been grouped into this section. 655 RFC2960: "Stream Control Transmission Protocol" (October 2000) SCTP 656 congestion control is very similar to TCP with Selective 657 Acknowledgements, but there are some differences, as described in 658 Section 7.1 of RFC 2960. The major difference lies in the fact 659 that SCTP supports multihoming, whereas TCP does not. Thus, SCTP 660 keeps a different set of congestion control parameters for each 661 destination address within an association, whereas TCP only keeps 662 a single set of congestion control parameters per connection. 664 RFC 3448: "TCP Friendly Rate Control (TFRC): Protocol Specification" 665 (January 2003) 667 This document specifies TCP-Friendly Rate Control (TFRC), a rate- 668 based congestion control mechanism for unicast flows operating in 669 a best-effort Internet environment where flows are competing with 670 standard TCP traffic. TFRC ensures conformance with TCP by 671 continuously calculating the rate that a TCP sender would obtain 672 under similar circumstances using a slightly simplified version of 673 the TCP Reno throughput equation in [PFTK98]. Its sending rate is 674 smoother than the rate of TCP, making it suitable for multimedia 675 applications. TFRC is not a wire protocol but rather a mechanism 676 which could, for instance, be used within a UDP based application, 677 in a transport protocol such as RTP, or in the context of endpoint 678 congestion management [RFC3124]. 680 RFC 3550: "RTP: A Transport Protocol for Real-Time Applications" 681 (July 2003) 683 This document specifies the real-time transport protocol RTP along 684 with its control protocol RTCP. RTP/RTCP does not prescribe a 685 specific congestion control behavior, but it is recommended that 686 such a behavior be specified in each RTP profile (which is due to 687 the fact that the potential for reducing the sending rate is often 688 content dependent in the case of real-time streams). 689 Specifically, [RFC3550] states: "For some profiles, it may be 690 sufficient to include an applicability statement restricting the 691 use of that profile to environments where congestion is avoided by 692 engineering. For other profiles, specific methods such as data 693 rate adaptation based on RTCP feedback may be required." 694 [RFC4585], which discusses RTCP feedback and adaptation 695 mechanisms, points out that RTCP feedback may operate on much 696 slower timescales than transport layer feedback mechanisms, and 697 that additional mechanisms are therefore required to perform 698 proper congestion control. One way to make use of such additional 699 mechanisms is to run RTP over DCCP. 701 RFC 4336: "Problem Statement for the Datagram Congestion Control 702 Protocol (DCCP)" (March 2006) 704 This document provides the motivation leading to the design of 705 DCCP. In doing so, other possibilities of implementing similar 706 functionality are discussed, including unreliable extensions of 707 SCTP, RTP based congestion control, and providing congestion 708 control above or below UDP. 710 RFC 4340: "Datagram Congestion Control Protocol" (March 2006) 712 This document specifies DCCP, the Datagram Congestion Control 713 Protocol. This protocol provides bidirectional unicast 714 connections of congestion-controlled unreliable datagrams. It is 715 suitable for applications that can benefit from control over the 716 tradeoff between timeliness and reliability. The core DCCP 717 specification does not include a specific congestion control 718 behavior; rather, it functions as a framework for such mechanisms, 719 which can be selected via the Congestion Control Identifier 720 (CCID). 722 RFC 4341: "Profile for Datagram Congestion Control Protocol (DCCP) 723 Congestion Control ID 2: TCP-like Congestion Control" (March 2006) 725 This is the specification of TCP-like congestion control within 726 DCCP. This should be used by senders who would like to take 727 advantage of the available bandwidth in an environment with 728 rapidly changing conditions, and who are able to adapt to the 729 abrupt changes in the congestion window typical of TCP's Additive 730 Increase Multiplicative Decrease (AIMD) congestion control. ECN 731 is also supported within RFC 4341. 733 RFC 4342: "Profile for Datagram Congestion Control Protocol (DCCP) 734 Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)" (March 735 2006) 737 This is the specification of TFRC congestion control as described 738 in [RFC3448] for DCCP. This should be used by senders who want a 739 TCP-friendly sending rate, possibly with Explicit Congestion 740 Notification (ECN), while minimizing abrupt rate changes. 742 7. Multicast Congestion Control 744 In the IETF, congestion control for multicast (one-to-many) 745 communication has primarily been tackled in the "Reliable Multicast 746 Transport" (RMT) Working Group. Except for [RFC2357] and [RFC3208], 747 all the documents in this section were written by this group. Since 748 a "one size fits all" protocol cannot meet the requirements of all 749 possible applications in this space, the approach taken is a modular 750 one, consisting of "protocol cores" and "building blocks". Multiple 751 congestion control building blocks have been defined, providing both 752 sender-driven and receiver-driven congestion control methods that 753 differ widely in their assumptions and behavior. 755 RFC 2357: "IETF Criteria for Evaluating Reliable Multicast Transport 756 and Application Protocols" (June 1998) 758 Some early multicast content dissemination proposals did not 759 incorporate proper congestion control; this is pointed out as 760 being a severe mistake in RFC 2357, as large-scale multicast 761 applications have the potential to do vast congestion related 762 damage. This document clearly makes the case that congestion 763 control mechanisms should be developed and incorporated into 764 multicast content dissemination protocols intended for use over 765 the Internet. 767 RFC 2887: "The Reliable Multicast Design Space for Bulk Data 768 Transfer" (August 2000) 770 Several classes of potential congestion control schemes for 771 single-sender multicast protocols are briefly sketched as 772 possibilities, but no specific protocols are developed or selected 773 in this document. 775 RFC 3048: "Reliable Multicast Transport Building Blocks for One-to- 776 Many Bulk-Data Transfer" (January 2001) 778 RFC 3048 discusses the building block approach to RMT protocols 779 and mentions that several different congestion control building 780 blocks may be required in order to deal with different situations. 781 Some of the possible interactions between building blocks for 782 congestion control and those for FEC, acknowledgement, and group 783 management are also mentioned. 785 RFC 3208: "PGM Reliable Transport Protocol Specification" (December 786 2001) 788 Pragmatic General Multicast (PGM) is a reliable multicast 789 transport protocol for applications that require ordered or 790 unordered, duplicate-free, multicast data delivery from multiple 791 sources to multiple receivers. As discussed in RFC 3208's 792 Appendix B, a PGM protocol source can request congestion control 793 feedback from both network elements (routers) and receivers (end 794 hosts). These reports can indicate the load on the worst link in 795 a particular path, or the load on the worst path. The actual 796 procedure used in response to this feedback is not part of RFC 797 3208, but the notion of using multicast routers to assist in 798 congestion control is significant. 800 RFC 3450: "Asynchronous Layered Coding (ALC) Protocol Instantiation" 801 (December 2002) 803 This document specifies ALC, a rough header format using the RMT 804 building blocks, that can be used by multicast content 805 dissemination protocols. ALC is intended to use a multi-rate 806 congestion control building block, where the sender does not 807 require any feedback, but where multiple multicast groups with 808 different transmission rates are available within and ALC session, 809 and receivers control their rates by joining or leaving groups. 811 RFC 3738: "Wave and Equation Based Rate Control (WEBRC) Building 812 Block" (April 2004) 814 The WEBRC mechanism defined in RFC 3738 is a receiver-driven form 815 of congestion control, where each receiver in a multicast group 816 can determine the individual rate at which packets are delivered 817 to it. WEBRC senders create a base channel for control 818 information and several multicast channels for data transmission 819 that each send packets at a varying rate in the form of a wave. 820 The receivers dynamically join and leave channels at chosen points 821 within the wave of sending rates to obtain the desired overall 822 receive rate based on an equation using the estimated loss 823 probability and round-trip time within an epoch. WEBRC is 824 compatible for use within ALC. 826 RFC 4654: "TCP-Friendly Multicast Congestion Control (TFMCC): 827 Protocol Specification" (August 2006) 829 TFMCC, as described in RFC 4654, is a sender-driven congestion 830 control mechanism, where the received rate for the entire 831 multicast group is determined by the worst-connected receiver. 832 TFMCC builds upon TFRC, but scales down the feedback to prevent 833 ACK-implosion effects by having receivers suppress their feedback 834 unless they perceive it to be the worst among the reception group. 836 8. Guidance for Developing and Analyzing Congestion Control Techniques 838 Some recently published RFCs discuss the properties of congestion 839 control protocols that are "safe" for Internet deployment, as well as 840 how to measure the properties of congestion control mechanisms and 841 transport protocols. These documents are particularly relevant to 842 the ICCRG as some of the group's activities involve reviewing 843 congestion control proposals that have been brought to the IETF for 844 publication (see 845 http://www.ietf.org/IESG/content/ions/ion-tsv-alt-cc.txt). 847 RFC 5033: "Specifying New Congestion Control Algorithms" (August 848 2007) 850 The concurrent development of multiple TCP modifications for high- 851 rate use and the deployments of these modifications on the 852 Internet prompted RFC 5033 to be written. RFC 5033 comes from the 853 Transport Area Working Group (TSVWG), and gives guidance on the 854 classes of Experimental RFC that can be published to document 855 algorithms that are either encouraged for investigation on the 856 Internet, and those that are only encouraged for experimentation 857 in less-critical environments. It has been described as a list of 858 things for people to think about when creating new congestion 859 control techniques that they are planning to widely deploy. 861 RFC 5166: "Metrics for the Evaluation of Congestion Control 862 Mechanisms" (March 2008) 864 The IRTF Transport Modeling Research Group (TMRG) produced RFC 865 5166 to describe the set of metrics and related tradeoffs between 866 metrics that can be used to compare, contrast, and evaluate 867 congestion control techniques. This RFC gives an overview of many 868 such metrics, and gives references to their detailed descriptions. 870 9. Historic Interest 872 Early in the RFC series, there are many documents that represent an 873 author's thoughts on a subject or brief summaries from measurement 874 and experimentation, rather than the result of a long formal IETF 875 process. Some of the RFCs listed in this section have this 876 distinction. 878 RFC 889: "Internet Delay Experiments" (December 1983) 880 Based on reported measurement experiments, changes to the TCP 881 retransmission timeout (RTO) calculation are suggested in this 882 document. It is noted that the original TCP RTO calculation leads 883 to congestion when a delay spike occurs because it takes too long 884 for the RTO to adapt, leading to superfluous retransmissions. 886 RFC 896: "Congestion Control in IP/TCP Internetworks" (January 1984) 888 This is the first document known to the authors where the term 889 "congestion collapse" was used. Here, it refers to the stable 890 state which was observed when a sudden load on the net caused the 891 round-trip time to rise faster than the sending hosts measured 892 round-trip time could be updated. Two problems are discussed: the 893 "small-packet problem" (now commonly known by the name "silly 894 window syndrome") and the "source-quench problem", which is about 895 inappropriately deciding when to send and how to react to ICMP 896 source-quench messages. Solutions for these problems are 897 presented. 899 RFC 970: "On Packet Switches with Infinite Storage" (December 1985) 901 Using a thought experiment based on a router with infinite 902 buffering capacity, RFC 970 develops a different kind of 903 congestion collapse scenario, where few useful packet 904 transmissions occur due to the queue being longer than the time- 905 to-live of the packets within it. As described in RFC 970, this 906 scenario was also demonstrated using real equipment by the author. 908 The document also includes discussion of game-theoretic analysis 909 of congestion control and obtaining fairness between behaving and 910 non-behaving flows, by focusing on the order of scheduling packets 911 within the buffer rather than the actual allocation of buffer 912 space between flows. 914 RFC 1016: "Something a Host Could Do with Source Quench: The Source 915 Quench Introduced Delay (SQuID)" (July 1987) 917 RFC 1016 outlines a rate-based congestion control mechanism where 918 end-hosts use Source Quench packets from routers to adjust their 919 sending rates. RFC 1016 also suggests sending congestion 920 notifications before queues are actually full, at a rate that 921 increases with the current queue occupancy. This strategy has 922 been used in several other AQM mechanisms, notably RED [FJ93]. 924 RFC 1254: "Gateway Congestion Control Survey" (August 1991) 926 This survey of congestion control approaches in routers first 927 discusses general congestion control performance goals (such as 928 fairness), and then elaborates on the use of Source Quench 929 messages (which are now discouraged, as they have been found 930 ineffective), Random Drop (which would now be called "Active Queue 931 Management"), Congestion Indication (DEC Bit) (an early form of 932 ECN), "Selective Feedback Congestion Indication" (one particular 933 method for applying ECN), and Fair Queuing. Finally, end system 934 congestion control policies are discussed, including Jacobson's 935 well-known algorithms [Jac88] and their predecessor "CUTE" 936 [Jain86]. 938 10. Security Considerations 940 This document introduces no new security considerations. Each RFC 941 listed in this document discusses the security considerations of the 942 specification it contains. 944 11. IANA Considerations 946 This document contains no IANA considerations. 948 12. Acknowledgments 950 Several participants in the ICCRG contributed useful comments in the 951 development of this document, including Rex Buddenberg, Mitchell 952 Erblichs, Lachlan Andrew, Sally Floyd, Stephen Farrell, Gorry 953 Fairhurst, Lars Eggert, Mark Allman, and Juergen Schoenwaelder. 955 13. Informative References 957 [FJ93] Floyd, S. and V. Jacobson, "Random Early Detection 958 Gateways for Congestion Avoidance", IEEE/ACM Transactions 959 on Networking volume 1, number 4, August 1993. 961 [Gont08] Gont, F., "ICMP Attacks Against TCP", Internet-Draft (work 962 in progress) draft-ietf-tcpm-icmp-attacks-03, March 2008. 964 [Jac88] Jacobson, V., "Congestion Avoidance and Control, ACM 965 SIGCOMM 1988 Proceedings, in ACM Computer Communication 966 Review, 18 (4), pp. 314-329", 1988. 968 [Jain86] Jain, R., "A Timeout-Based Congestion Control Scheme for 969 Window Flow-Controlled Networks", IEEE Journal on Selected 970 Areas in Communications volume 4, number 7, October 1986. 972 [MAF04] Medina, A., Allman, M., and S. Floyd, "Measuring 973 Interactions Between Transport Protocols and Middleboxes", 974 Proceedings of the Internet Measurement Conference 2004, 975 August 2004. 977 [MAF05] Medina, A., Allman, M., and S. Floyd, "Measuring the 978 Evolution of Transport Protocols in the Internet", ACM 979 Computer Communications Review volume 35, issue 2, 980 April 2005. 982 [MBJ07] Moncaster, T., Briscoe, B., and A. Jacquet, "A TCP Test to 983 Allow Senders to Identify Receiver Non-Compliance", 984 Internet-Draft (work in 985 progress) draft-moncaster-tcpm-rcv-cheat-01, June 2007. 987 [PF01] Padhye, J. and S. Floyd, "On Inferring TCP Behavior", 988 Proceedings of ACM SIGCOMM 2001, August 2001. 990 [PFTK98] Padhye, J., Firoiu, V., Towsley, D., and J. Kurose, 991 "Modeling TCP Throughput: A Simple Model and its Empirical 992 Validation, Proc. ACM SIGCOMM 1998.". 994 [RFC0889] Mills, D., "Internet delay experiments", RFC 889, 995 December 1983. 997 [RFC0896] Nagle, J., "Congestion control in IP/TCP internetworks", 998 RFC 896, January 1984. 1000 [RFC0970] Nagle, J., "On packet switches with infinite storage", 1001 RFC 970, December 1985. 1003 [RFC1016] Prue, W. and J. Postel, "Something a host could do with 1004 source quench: The Source Quench Introduced Delay 1005 (SQuID)", RFC 1016, July 1987. 1007 [RFC1122] Braden, R., "Requirements for Internet Hosts - 1008 Communication Layers", STD 3, RFC 1122, October 1989. 1010 [RFC1254] Mankin, A. and K. Ramakrishnan, "Gateway Congestion 1011 Control Survey", RFC 1254, August 1991. 1013 [RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated 1014 Services in the Internet Architecture: an Overview", 1015 RFC 1633, June 1994. 1017 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 1018 RFC 1812, June 1995. 1020 [RFC1958] Carpenter, B., "Architectural Principles of the Internet", 1021 RFC 1958, June 1996. 1023 [RFC2001] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast 1024 Retransmit, and Fast Recovery Algorithms", RFC 2001, 1025 January 1997. 1027 [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, 1028 S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., 1029 Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, 1030 S., Wroclawski, J., and L. Zhang, "Recommendations on 1031 Queue Management and Congestion Avoidance in the 1032 Internet", RFC 2309, April 1998. 1034 [RFC2357] Mankin, A., Romanov, A., Bradner, S., and V. Paxson, "IETF 1035 Criteria for Evaluating Reliable Multicast Transport and 1036 Application Protocols", RFC 2357, June 1998. 1038 [RFC2414] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's 1039 Initial Window", RFC 2414, September 1998. 1041 [RFC2415] Poduri, K., "Simulation Studies of Increased Initial TCP 1042 Window Size", RFC 2415, September 1998. 1044 [RFC2416] Shepard, T. and C. Partridge, "When TCP Starts Up With 1045 Four Packets Into Only Three Buffers", RFC 2416, 1046 September 1998. 1048 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 1049 and W. Weiss, "An Architecture for Differentiated 1050 Services", RFC 2475, December 1998. 1052 [RFC2481] Ramakrishnan, K. and S. Floyd, "A Proposal to add Explicit 1053 Congestion Notification (ECN) to IP", RFC 2481, 1054 January 1999. 1056 [RFC2488] Allman, M., Glover, D., and L. Sanchez, "Enhancing TCP 1057 Over Satellite Channels using Standard Mechanisms", 1058 BCP 28, RFC 2488, January 1999. 1060 [RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion 1061 Control", RFC 2581, April 1999. 1063 [RFC2884] Hadi Salim, J. and U. Ahmed, "Performance Evaluation of 1064 Explicit Congestion Notification (ECN) in IP Networks", 1065 RFC 2884, July 2000. 1067 [RFC2887] Handley, M., Floyd, S., Whetten, B., Kermode, R., 1068 Vicisano, L., and M. Luby, "The Reliable Multicast Design 1069 Space for Bulk Data Transfer", RFC 2887, August 2000. 1071 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, 1072 RFC 2914, September 2000. 1074 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 1075 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., 1076 Zhang, L., and V. Paxson, "Stream Control Transmission 1077 Protocol", RFC 2960, October 2000. 1079 [RFC2998] Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L., 1080 Speer, M., Braden, R., Davie, B., Wroclawski, J., and E. 1081 Felstaine, "A Framework for Integrated Services Operation 1082 over Diffserv Networks", RFC 2998, November 2000. 1084 [RFC3048] Whetten, B., Vicisano, L., Kermode, R., Handley, M., 1085 Floyd, S., and M. Luby, "Reliable Multicast Transport 1086 Building Blocks for One-to-Many Bulk-Data Transfer", 1087 RFC 3048, January 2001. 1089 [RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager", 1090 RFC 3124, June 2001. 1092 [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. 1093 Shelby, "Performance Enhancing Proxies Intended to 1094 Mitigate Link-Related Degradations", RFC 3135, June 2001. 1096 [RFC3150] Dawkins, S., Montenegro, G., Kojo, M., and V. Magret, 1097 "End-to-end Performance Implications of Slow Links", 1098 BCP 48, RFC 3150, July 2001. 1100 [RFC3155] Dawkins, S., Montenegro, G., Kojo, M., Magret, V., and N. 1101 Vaidya, "End-to-end Performance Implications of Links with 1102 Errors", BCP 50, RFC 3155, August 2001. 1104 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 1105 of Explicit Congestion Notification (ECN) to IP", 1106 RFC 3168, September 2001. 1108 [RFC3208] Speakman, T., Crowcroft, J., Gemmell, J., Farinacci, D., 1109 Lin, S., Leshchiner, D., Luby, M., Montgomery, T., Rizzo, 1110 L., Tweedly, A., Bhaskar, N., Edmonstone, R., 1111 Sumanasekera, R., and L. Vicisano, "PGM Reliable Transport 1112 Protocol Specification", RFC 3208, December 2001. 1114 [RFC3366] Fairhurst, G. and L. Wood, "Advice to link designers on 1115 link Automatic Repeat reQuest (ARQ)", BCP 62, RFC 3366, 1116 August 2002. 1118 [RFC3426] Floyd, S., "General Architectural and Policy 1119 Considerations", RFC 3426, November 2002. 1121 [RFC3439] Bush, R. and D. Meyer, "Some Internet Architectural 1122 Guidelines and Philosophy", RFC 3439, December 2002. 1124 [RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP 1125 Friendly Rate Control (TFRC): Protocol Specification", 1126 RFC 3448, January 2003. 1128 [RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M. 1129 Sooriyabandara, "TCP Performance Implications of Network 1130 Path Asymmetry", BCP 69, RFC 3449, December 2002. 1132 [RFC3450] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., and J. 1133 Crowcroft, "Asynchronous Layered Coding (ALC) Protocol 1134 Instantiation", RFC 3450, December 2002. 1136 [RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit 1137 Congestion Notification (ECN) Signaling with Nonces", 1138 RFC 3540, June 2003. 1140 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1141 Jacobson, "RTP: A Transport Protocol for Real-Time 1142 Applications", STD 64, RFC 3550, July 2003. 1144 [RFC3649] Floyd, S., "HighSpeed TCP for Large Congestion Windows", 1145 RFC 3649, December 2003. 1147 [RFC3714] Floyd, S. and J. Kempf, "IAB Concerns Regarding Congestion 1148 Control for Voice Traffic in the Internet", RFC 3714, 1149 March 2004. 1151 [RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate 1152 Control (WEBRC) Building Block", RFC 3738, April 2004. 1154 [RFC3742] Floyd, S., "Limited Slow-Start for TCP with Large 1155 Congestion Windows", RFC 3742, March 2004. 1157 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 1158 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 1159 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 1160 RFC 3819, July 2004. 1162 [RFC3926] Paila, T., Luby, M., Lehtonen, R., Roca, V., and R. Walsh, 1163 "FLUTE - File Delivery over Unidirectional Transport", 1164 RFC 3926, October 2004. 1166 [RFC3940] Adamson, B., Bormann, C., Handley, M., and J. Macker, 1167 "Negative-acknowledgment (NACK)-Oriented Reliable 1168 Multicast (NORM) Protocol", RFC 3940, November 2004. 1170 [RFC3941] Adamson, B., Bormann, C., Handley, M., and J. Macker, 1171 "Negative-Acknowledgment (NACK)-Oriented Reliable 1172 Multicast (NORM) Building Blocks", RFC 3941, 1173 November 2004. 1175 [RFC4336] Floyd, S., Handley, M., and E. Kohler, "Problem Statement 1176 for the Datagram Congestion Control Protocol (DCCP)", 1177 RFC 4336, March 2006. 1179 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1180 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 1182 [RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion 1183 Control Protocol (DCCP) Congestion Control ID 2: TCP-like 1184 Congestion Control", RFC 4341, March 2006. 1186 [RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for 1187 Datagram Congestion Control Protocol (DCCP) Congestion 1188 Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, 1189 March 2006. 1191 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 1192 "Extended RTP Profile for Real-time Transport Control 1193 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 1194 July 2006. 1196 [RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap 1197 for Transmission Control Protocol (TCP) Specification 1198 Documents", RFC 4614, September 2006. 1200 [RFC4654] Widmer, J. and M. Handley, "TCP-Friendly Multicast 1201 Congestion Control (TFMCC): Protocol Specification", 1202 RFC 4654, August 2006. 1204 [RFC5033] Floyd, S. and M. Allman, "Specifying New Congestion 1205 Control Algorithms", BCP 133, RFC 5033, August 2007. 1207 [RFC5166] Floyd, S., "Metrics for the Evaluation of Congestion 1208 Control Mechanisms", RFC 5166, March 2008. 1210 [Riz00] Rizzo, L., "pgmcc: A TCP-Friendly Single-Rate Multicast 1211 Congestion Control Scheme", Proceedings of ACM 1212 SIGCOMM 2000, August 2000. 1214 Authors' Addresses 1216 Michael Welzl 1217 University of Innsbruck 1218 Technikerstr 21a 1219 A-6020 Innsbruck, Austria 1221 Phone: +43 (512) 507-6110 1222 Email: michael.welzl@uibk.ac.at 1224 Wesley M. Eddy 1225 Verizon Federal Network Systems 1226 NASA Glenn Research Center 1227 21000 Brookpark Rd, MS 54-5 1228 Cleveland, OH 44135 1230 Phone: (216) 433-6682 1231 Email: weddy@grc.nasa.gov 1233 Full Copyright Statement 1235 Copyright (C) The IETF Trust (2008). 1237 This document is subject to the rights, licenses and restrictions 1238 contained in BCP 78, and except as set forth therein, the authors 1239 retain all their rights. 1241 This document and the information contained herein are provided on an 1242 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1243 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1244 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1245 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1246 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1247 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1249 Intellectual Property 1251 The IETF takes no position regarding the validity or scope of any 1252 Intellectual Property Rights or other rights that might be claimed to 1253 pertain to the implementation or use of the technology described in 1254 this document or the extent to which any license under such rights 1255 might or might not be available; nor does it represent that it has 1256 made any independent effort to identify any such rights. Information 1257 on the procedures with respect to rights in RFC documents can be 1258 found in BCP 78 and BCP 79. 1260 Copies of IPR disclosures made to the IETF Secretariat and any 1261 assurances of licenses to be made available, or the result of an 1262 attempt made to obtain a general license or permission for the use of 1263 such proprietary rights by implementers or users of this 1264 specification can be obtained from the IETF on-line IPR repository at 1265 http://www.ietf.org/ipr. 1267 The IETF invites any interested party to bring to its attention any 1268 copyrights, patents or patent applications, or other proprietary 1269 rights that may cover technology that may be required to implement 1270 this standard. Please address the information to the IETF at 1271 ietf-ipr@ietf.org.