RFC 5783
Congestion Control in the RFC Series
Internet Research Task Force (IRTF) 🦋
RFC 5783, Congestion Control in the RFC Series, is an Informational document, not Standards Track. Its authors are M. Welzl (University of Oslo) and W. Eddy (MTI Systems). It was published in February 2010 and carries ISSN 2070-1721. It doesn't obsolete or update any other document, and it doesn't change the status of any RFC it discusses 💅
Abstract ✨
okay so this doc is an informational snapshot the IRTF's Internet Congestion Control Research Group (ICCRG) took in October 2008 🌸 It's basically a survey of congestion control topics covered by RFCs. It doesn't modify or update the specs or status of any of the RFCs it talks about, so nothing gets rewritten, just explained. Researchers can use it as a reference or a launchpad for the group's future work, especially for spotting gaps or open issues in current IETF standards 🔍
Status of This Memo 📋
this one's not an Internet Standards Track spec, it's published just for information ngl 🫶
It's a product of the Internet Research Task Force (IRTF), which publishes results of Internet-related research and development. Those results might not be suitable for deployment, so don't go shipping them yet 😭 This RFC represents the consensus of the Internet Congestion Control Research Group of the IRTF. Documents the IRSG approves for publication aren't candidates for any level of Internet Standard, see Section 2 of RFC 5741 for the details 🎀
For the current status of this document, any errata, and how to give feedback, check http://www.rfc-editor.org/info/rfc5783 🔗
Copyright Notice 🌈
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved 💜
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication. Please read those carefully, because they spell out your rights and restrictions for this document 📜
Table of Contents 🧚
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Architectural Documents . . . . . . . . . . . . . . . . . . . 5
3. TCP Congestion Control . . . . . . . . . . . . . . . . . . . . 9
4. Challenging Link and Path Characteristics . . . . . . . . . . 10
5. End-Host and Router Cooperative Signaling . . . . . . . . . . 12
5.1. Explicit Congestion Notification . . . . . . . . . . . . . 13
5.2. Quick-Start . . . . . . . . . . . . . . . . . . . . . . . 15
6. Non-TCP Unicast Congestion Control . . . . . . . . . . . . . . 15
7. Multicast Congestion Control . . . . . . . . . . . . . . . . . 18
8. Guidance for Developing and Analyzing Congestion Control
Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9. Historic Interest . . . . . . . . . . . . . . . . . . . . . . 21
10. Security Considerations . . . . . . . . . . . . . . . . . . . 22
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
12. Informative References . . . . . . . . . . . . . . . . . . . . 221. Introduction 💖
okay bestie, the big picture: in this doc, congestion control means the feedback-based adjustment of the rate at which data gets sent into the network 🚦 It's an absolutely essential set of principles and mechanisms for keeping the Internet stable 👑 Congestion control has been tightly linked to TCP since 1988 [Jac88], but there's also a ton of congestion control work outside TCP, like for real-time multimedia, multicast, and router-based mechanisms ✨ The IETF has published several of these proposals as RFCs, along with RFCs giving architectural guidance (for example, pointing out why some form of congestion control matters at all). Several of these mechanisms are actually in use across the Internet 🌍
So when you're designing a new Internet transport protocol, it's not enough to understand TCP's congestion control. You need the broader picture too 🧠 Some RFCs give guidance, some describe mechanisms that could directly influence your new protocol, and some are just "related work" worth knowing about 📚 This document's whole purpose is to help you go find that knowledge by giving an overview of the congestion control RFCs published so far 🔎 It's a product of the IRTF's Internet Congestion Control Research Group (ICCRG) and was made because a strong grasp of the existing literature should help future ICCRG work 💅 The ICCRG built consensus on the content over a two-year development period, based on review comments and ICCRG mailing list discussions. The main review contributors are listed in the Acknowledgements section of this document 🫶
The authors' opinions are their own, even though the ICCRG agreed to produce the document. Since this isn't an IETF publication, it doesn't update or modify the status of any published RFCs 🙈 It's laid out like an annotated bibliography. Host and router requirements for congestion control come up in the discussion, but this is only an informational document, so it doesn't carry any formal standards weight of its own ✨
Congestion control is a huge, active topic, so this document's scope is limited to published RFCs and a small number of current working group drafts 🎯 That keeps it focused on the principles and mechanisms that are most well-supported, well-accepted, or widely used. There are also significant contributions in the academic literature and in Internet-Drafts, but this study leaves those out 📝 Often, the RFC describing a mechanism cites academic papers in journals or conference proceedings that presented the research and validation. For instance, RFC 2581 cites Jacobson's 1988 SIGCOMM paper, which is less standards-oriented but more illustrative, explaining some of the mechanisms in RFC 2581 in more depth 🦋
Most of the documents discussed here are about end-host-based congestion control 💻 Plenty of network-based mechanisms, like many queue management algorithms, don't need any protocol exchanges between elements. They just run inside a single host or router 🤖 Because of that, network-based congestion control mechanisms often haven't been described in any RFC, since they generally count as implementation details that don't affect interoperability 🌸
There are lots of RFCs about Quality of Service (QoS), especially in the Integrated Services and Differentiated Services frameworks [RFC1633] [RFC2475] [RFC2998] 🎀 Those QoS RFCs deserve their own bibliography, just like this one does for congestion control. This document deliberately leaves out the huge amount of QoS work, because QoS is a full field in its own right and mostly deals with issues orthogonal to end-host congestion control and router queue management 🙅♀️ QoS and congestion control can definitely interact. For example, scheduling mechanisms used to implement QoS (per flow or in aggregate) can operate independently of the end-host congestion control and queue management functions also in use. The same goes for traffic shaping, admission control, and other QoS functions that are only side notes for congestion control 💜
A similar argument applies to excluding the media access control (MAC) layer protocols used by the links along a path 🔗 MAC protocols resolve contention for shared links, and sometimes offer QoS services, but they're also distinct from end-to-end congestion control. MAC protocols usually aren't discussed in the RFC series. They're defined in outside documents, such as IEEE standards, because the IETF doesn't generally work on link layers themselves. Few, if any, of the RFCs describing how IP maps onto various link layers directly discuss congestion control 🫠
To organize the material, this document sorts its content into several broad categories 🗂️ First up, Section 2 lists documents about Internet architecture and general architectural concepts. Next, Section 3 covers the congestion control algorithms used in TCP. Section 4 covers interactions between link properties and mechanisms, and the kinds of algorithms and heuristics used in end-to-end congestion control. One method the IETF has developed, and deployed to some extent, lets network-based and host-based congestion control interact without dropping packets, and that's the subject of Section 5.1 ⚡ Section 6 describes the congestion control algorithms used by unicast transport protocols other than TCP. Section 7 lists work on congestion control for multicast transports and applications. Section 8 discusses RFCs that guide developers of new algorithms. Finally, Section 9 covers documents with historic significance but perhaps not current direct technical application 🕰️ Heads up: the word "historic" here has nothing to do with the IETF's formal classification of documents as having "Historic" status 🙈
2. Architectural Documents ✨
okay so this section is the big-picture crew 🧚 Some of these docs are architecture guidance and concerns, and others specify congestion control mechanisms that are broadly useful and affect more than one kind of congestion control technique. A few of them are direct products of the Internet Architecture Board (IAB), who gave their takes on specific parts of congestion control on the Internet. iconic behavior 👑
RFC 1122: "Requirements for Internet Hosts -- Communication Layers" (October 1989)
[RFC1122] formally mandates that hosts perform congestion control 🎀 For TCP, a bunch of congestion control features get described and listed as required elements of conforming implementations. For UDP, RFC 1122 leaves congestion control up to higher-layered protocols 🤷♀️ Sending and reacting to ICMP Source Quench packets is no longer recommended [RFC1812] [Gont10] 💀 but the rest of the congestion control guidance in this RFC is still the basis for several current practices in TCP implementations. it's giving foundational 🫶
RFC 1812: "Requirements for IP Version 4 Routers" (June 1995)
Tons of issues related to router behavior get discussed in [RFC1812], and it lays out requirements for routers to support ✨ The congestion control parts that matter most are: routers SHOULD NOT originate ICMP Source Quench messages, a discussion of precedence in queueing, and Section 5.3.6 titled "Congestion Control". That section recommends sizing buffers as a function of the product of the bandwidth of the link times the path delay of the flows using the link, and it gives advice on implementing active queue management techniques. main character energy 🌸
RFC 1958: "Architectural Principles of the Internet" (June 1996)
[RFC1958] sketches several guidelines for network systems design that have proven useful in the evolution of the Internet 🦋 Congestion control isn't specifically mentioned or hinted at, but the general principles still apply to it. For example, doing end-to-end functions at end nodes, having no centralized control, heterogeneity, scalability, simplicity, avoiding options and parameters, etc. are all valid concerns when designing and assessing congestion control schemes for the Internet 💜
RFC 2140: "TCP Control Block Interdependence" (April 1997)
[RFC2140] suggests that TCP connections between the same endpoints might share some information, including their congestion control state 👯♀️ A few current operating systems kind of do this in practice. Linux, for example, has a destination cache with this information 🐧 But this behavior hasn't been formally standardized or recognized as a best practice by the IETF yet 🙈
RFC 2309: "Recommendations on Queue Management and Congestion Avoidance in the Internet" (April 1998)
[RFC2309] briefly talks through the history of congestion and where congestion control in the Internet came from ⏳ It's mostly focused on network- or router-based queue management algorithms. This RFC recommends testing, standardizing, and deploying Active Queue Management (AQM) in routers. It gives an overview of one such mechanism, Random Early Detection (RED), and explains how and why AQM mechanisms can improve Internet performance 📈 Last but not least, it explains the danger of a possible "congestion collapse" caused by unresponsive flows, and it makes a strong recommendation to develop and eventually deploy router mechanisms that protect the Internet from that kind of traffic 🚨
Today, the advice in this document has been followed to some extent, and honestly the vendors were receptive 🥰 AQM techniques are widely available in lots of popular dedicated commercial router products, and even in more general operating systems that sometimes get used as routers. However, AQM techniques may not be enabled in default configurations of these systems, so it's often left up to users and network engineers to turn on and configure AQM mechanisms when they want them 🧐 In some cases, enabling QoS mechanisms on a device also enables AQM mechanisms by default. How many production routers actually have these AQM features turned on? still an open question 🤷♀️✨
RFC 2914 (BCP 41): "Congestion Control Principles" (September 2000)
[RFC2914] explains the principles of congestion control, and it's the IETF's Best Current Practice for congestion control design 📚 It points out that there's an increasing number of applications that don't use TCP, and it goes into why congestion control matters for that traffic, so we don't end up with congestion collapse 🚧 The TCP Reno congestion control mechanisms get described as an example of end-to-end congestion control within transport protocols 🦄
SCTP is one example of a non-TCP transport protocol that implements congestion control based on these principles 🫧 The developments of TFRC [RFC3448] and DCCP [RFC4340] are attempts to give apps with needs similar to streaming media useful tools that implement those principles, since TCP's reactions are too fast for them 🎥 It would be beneficial for users and for the Internet itself if these carefully designed tools became widely deployed in place of other ad hoc schemes that might not be well grounded in the congestion control principles. This replacement process is ongoing and not yet complete 🍑 Appropriate and usable congestion control schemes for non-TCP flows are still an open research area 🔬
RFC 3124: "The Congestion Manager" (June 2001)
[RFC3124] specifies the Congestion Manager, an end-system service that does congestion control on a per-host-pair basis instead of per-connection, which may be a more appropriate way to handle it 🧠 With the Congestion Manager, multiple streams between two hosts (which may include TCP flows) can adapt to network congestion in a unified way 🤝
This proposal is related to RFC 2140, which we just covered, but it has a wider scope than TCP ✨ Some pieces of its supporting architecture haven't been specified yet, so the Congestion Manager's techniques aren't commonly used today and haven't been widely implemented or deployed beyond experimental stacks 🧪 Sharing congestion and path information between individual connections is still an open research area, with branches in detecting shared bottlenecks when using multiple paths, caching old state for faster startup, and sharing current state and feedback 🌈
RFC 3426: "General Architectural and Policy Considerations" (November 2002)
[RFC3426] lists a bunch of questions you can ask about a particular technical solution to figure out its architectural impact and whether it's desirable 📝 These totally apply to congestion control mechanisms, and end-point congestion management shows up as an example case study several times in RFC 3426 💅 Two salient questions that RFC 3426 says to ask about proposed mechanisms are why they're needed in addition to existing protocols, and why they're needed at a certain layer instead of other layers 🪜 This matters a lot for congestion control, since several mechanisms already exist and they can span the network, transport, and application layers 🫠
RFC 3439: "Some Internet Architectural Guidelines and Philosophy" (December 2002)
[RFC3439] supplements RFC 1958 🧩 Simplicity gets a lot of emphasis here, because the unpredictable results of complexity (due to amplification and coupling) are described. It also covers congestion control issues that come from layering interactions between transport and lower protocols, plus other congestion control items, including asymmetry and the "myth of over-provisioning" 🙄
RFC 3714: "IAB Concerns Regarding Congestion Control for Voice Traffic in the Internet" (March 2004)
okay this one is a follow-up to the concerns discussed in RFC 2914 📞 [RFC3714] expresses the IAB's worry about the lack of effective end-to-end congestion control for best-effort voice traffic, which is a current service with growing demand 📈 The example is a VoIP connection between Atlanta, Georgia, USA, and Nairobi, Kenya, where a single VoIP call used more than half of the access link capacity (which is normally shared across several different users) 😳 That example is the basis for the rest of the discussion, and it makes it super clear that using some form of congestion control for VoIP traffic is highly recommended 🚨💜
3. TCP Congestion Control ✨
okay so bestie, RFC 793 and its predecessors didn't say anything about using or managing a congestion window 😭 Outside of a simple retransmission timeout and flow control through the advertised receive window, TCP implementations that only followed RFC 793 had zero congestion control. Then a bunch of congestion collapse events hit the Internet and everyone was like, oh no, we actually need this 💀 The host requirements in RFC 1122 say conforming TCP implementations MUST implement Jacobson's slow start and congestion avoidance algorithms (later specified in RFC 2001 and then RFC 2581). RFC 1122 also recommends a few other behaviors that affect congestion control, like the Nagle algorithm, delayed acknowledgements, Jacobson's retransmission timeout (RTO) estimation algorithm, and exponential backoff of the retransmission timer 🌸
Basic TCP congestion control is defined in RFC 2581, and there are a bunch of other RFCs with ancillary modifications and enhancements 🦋 RFC 2581 obsoletes RFC 2001, which was the first proposed standard for TCP congestion control. Both of them wrote down mechanisms that TCP implementations had already been using for years, so it's like the paperwork finally caught up 💅 If you want the full tour, the TCP Roadmap [RFC4614] has the RFCs that specifically describe TCP congestion control. This doc doesn't copy all of that, so go check it out 🧚
Lately there's been a ton of effort on experimental TCP congestion control modifications that aim for high throughput with reduced startup and recovery times 🔥 Some of these have RFCs, including HighSpeed TCP [RFC3649] and Limited Slow-Start [RFC3742]. But high-rate congestion control is still considered an open issue in congestion control research, so it's not totally figured out yet 🙈 Other schemes have shown up as Internet-Drafts or got a little discussion at the IETF, but most of this work hasn't been adopted within the IETF yet. That means most of it lives outside the RFC series and might get discussed in other products of the ICCRG ✨
When this was written, the IETF's TCP Maintenance and Minor Extensions (TCPM) Working Group was working on an update to RFC 2581 🎀 The goal was to fold in small changes from other documents and move TCP congestion control mechanisms forward on the IETF Standards Track. The update also clarifies and revises some points, like the definition of a duplicate ACK, initial congestion window and slow start threshold values, behavior in response to retransmission timeouts, the use of the limited transmit mechanism, and security with regards to misbehaving receivers that practice ACK division. Main character glow-up energy 👑
4. Challenging Link and Path Characteristics 🌈
Links with large and/or variable bandwidth-delay products have traditionally been a problem for congestion control schemes, because they can distort the properties of the feedback loop 😵 Links that either expose a high rate of packet losses to the upper layers, or use highly-persistent retransmission mechanisms to prevent losses, also cause problems with some of the standard congestion control mechanisms. The documents in this section talk about these challenging link characteristics, and a lot of them were written by the Performance Implications of Link Characteristics (PILC) Working Group 🫶
While these documents often point to specific problems with TCP, the link characteristics they describe can be expected to affect other congestion control mechanisms too. Interactions between link properties and TCP congestion control will also show up for other protocols that use similar congestion control behavior, such as SCTP [RFC4960] and DCCP with CCID 2 [RFC4341] (see Section 6). Designers of congestion control mechanisms that use the same kind of feedback as TCP should take these into consideration too 💜
Some RFCs only make recommendations about implementing and configuring TCP based on the characteristics of special links. Since those RFCs are so closely tied to the specification of TCP itself, they're not included in this document, but they're listed in the TCP Roadmap [RFC4614] 🍓
Here's the lineup of RFCs that cover challenging links and paths. Iconic list, no cap 💅
- RFC 2488 (BCP 28): "Enhancing TCP Over Satellite Channels using Standard Mechanisms" (January 1999)
The summary of recommendations in [RFC2488] came from the TCP over Satellite (TCPSAT) Working Group. Their goal was to figure out the performance problems TCP may have over satellite links and suggest mitigations 🛰️ The document explains several ways existing standards can be applied to improve the performance of basic TCP congestion control over paths with characteristics similar to satellite links ✨
- RFC 3135: "Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations" (June 2001)
[RFC3135] is a survey of Performance Enhancing Proxies (PEPs) that are often used to improve degraded TCP performance caused by the characteristics of specific link environments, like satellite, wireless WAN, and wireless LAN environments 📡 It describes different types of PEPs and the mechanisms they use to improve performance. Even though it focuses on TCP, PEPs can operate on any protocol, and the performance enhancements they achieve are often closely related to congestion control 🦋
PEPs have architectural implications, because they sometimes violate end-to-end assumptions and can add complexity to the inner portions of a network 😬 Certain types of PEPs are commonly used today in satellite or long-distance networking, since it's easier to insert a small number of PEPs near problematic links than to upgrade the TCP implementations on all the end hosts that might use those links. One down-side is that deploying them raises some issues when you introduce new or updated congestion control (CC) methods into these networks. PEPs may be operating with undocumented algorithms, making assumptions about the end-host CC behavior, and/or altering packet fields that affect the end-host CC behavior 🙃
- RFC 3150 (BCP 48): "End-to-end Performance Implications of Slow Links" (July 2001)
[RFC3150] makes performance-related recommendations for users of network paths that go through "very low bit-rate" links 🐢 It includes a discussion of how those links interact with TCP congestion control.
- RFC 3155 (BCP 50): "End-to-end Performance Implications of Links with Errors" (August 2001)
Under the premise that several types of PEP have undesirable implications, [RFC3155] recommends end-to-end alternatives for improving TCP performance over paths with error-prone links 🧩
- RFC 3366 (BCP 62): "Advice to link designers on link Automatic Repeat reQuest (ARQ)" (August 2002)
Link-layer ARQ techniques are a popular way to make particular links more robust to transmission errors, using retransmission and acknowledgement mechanisms 🔁 As [RFC3366] explains, ARQ can interact poorly with TCP's end-to-end congestion control if it leads to additional delay variation or reordering. This RFC gives some advice on limiting how far these problematic interactions go. The proper balance between end-to-end and link-layer reliability mechanisms is still an open research issue, and lots of academic papers outside the IETF have explored it 📚
- RFC 3449 (BCP 69): "TCP Performance Implications of Network Path Asymmetry" (December 2002)
[RFC3449] describes performance limitations of TCP when the capacity of the ACK path is limited 🌊 It recommends several techniques to help TCP in these situations as Best Current Practices. ACK congestion control and sender pacing are especially relevant to other, non-TCP congestion control schemes, which are outside the scope of this document. For example, when designing the Reliable Multicast Transport (RMT) protocols for multicast, preventing ACK-implosion at multicast sources can be seen as a form of ACK congestion control 🤯
- RFC 3481: "TCP over Second (2.5G) and Third (3G) Generation Wireless Networks" (February 2003)
Among other issues, some mobile data systems have delay spikes, handovers, and bandwidth oscillation 📶 [RFC3481] describes the problems these conditions cause for TCP congestion control, and how some TCP extensions can be used to mitigate them.
- RFC 3819 (BCP 89): "Advice for Internet Subnetwork Designers" (July 2004)
Several issues in link design and optimization for carrying IP traffic are discussed in [RFC3819], which recommends Best Current Practices 🧱 Many of these principles are motivated by properties of TCP, but most of them also apply to other transport-layer congestion control techniques too.
5. End-Host and Router Cooperative Signaling 📣
Some RFCs define mechanisms that let routers add signaling information to packets, so the network's congestion state is less of a mystery to end-host congestion controllers 🕵️♀️ Routers that support these can signal information about the current congestion state to flows in-band. That's faster and more fine-grained than inference-based methods, which is giving "we're sending a lot of guessing" vibes 😂 Two examples are discussed in this section. The first one tells sources to slow down in order to avoid losses, and the other helps figure out an appropriate starting rate for new flows 🚀
5.1. Explicit Congestion Notification ✨
Okay so, traditionally when a router gets congested it just keeps stuffing packets into its queue until the queue is full, and then it starts dropping them 💀. TCP and other IETF transport protocols notice the drops by watching their stream of acknowledgements and going "oh no, loss, slow down." This section is about a glow-up: a way to tell senders about congestion before anything has to get dropped 🦋
There are two Explicit Congestion Notification (ECN) bits in the IP header that enable an AQM mechanism (see [RFC2309] or Section 2) to convey congestion information to endpoints without dropping packets 🎀. This can significantly reduce the losses experienced by transport endpoints if they are responsive to ECN. ECN is most frequently discussed in the context of TCP (and is therefore included in the TCP Roadmap [RFC4614]), but its applicability is broader 🌈. ECN use has also been specified for protocols such as DCCP and SCTP 💜.
RFC 2481: "A Proposal to add Explicit Congestion Notification (ECN) to IP" (January 1999) - Obsoleted by RFC 3168
[RFC2481] introduced ECN into the RFC series 👑. It describes when the Congestion Experienced (CE) bit in the IP header should be set in routers, and what modifications are needed to TCP to make it ECN-capable. It includes a discussion of issues related to nodes and routers that are non-compliant, IPsec tunnels, and dropped or corrupted packets, as well as a summary of related work 🧚. Many of these issues will also be faced by operators trying to deploy other network-based congestion control methods. RFC 2481 has been obsoleted by RFC 3168 🥀.
RFC 2884: "Performance Evaluation of Explicit Congestion Notification (ECN) in IP Networks" (July 2000)
[RFC2884] presents a performance study of ECN as specified in [RFC2481], using an implementation on the Linux operating system 🐧. The experiments focused on ECN for both bulk and transactional transfers. They showed that there is an improvement in throughput over TCP without ECN in the case of bulk transfers, and a substantial improvement for transactional transfers 📈. Studies like this help to build the community's confidence that extensions like ECN are both safe and valuable 🫶. Similar RFCs helped the community accept larger initial windows for TCP [RFC2414] [RFC2415] [RFC2416] 🍓.
RFC 3168: "The Addition of Explicit Congestion Notification (ECN) to IP" (September 2001)
[RFC3168], which obsoletes [RFC2481], specifies the incorporation of ECN into TCP and IP ✨. One notable change in this significantly extended specification is the definition of a bit combination that was not defined in [RFC2481]. That combination can be used to realize a nonce that would prevent a receiver from falsely claiming that there was no congestion 🙈. Potential issues related to ECN are discussed at length, including those already included in [RFC2481], and backwards compatibility with implementations that would follow the specification in the obsoleted document 📚.
ECN, as specified in RFC 3168, is implemented in several popular router and end-host platforms, and it is in active use, to at least some extent 🔥. Problems with ECN "blackholes" (Internet routers misconfigured to discard packets with ECN-capable bits set) were discovered when ECN was enabled by default in some end-host operating systems 😭. Fears about the persisting presence of these blackholes may currently be keeping ECN from being used by default in many end-host operating systems, even though it is implemented as an option within them 🥺. Some measurements on ECN support and usability are available [PF01] [MAF04] [MAF05] 📊.
RFC 3540: "Robust Explicit Congestion Notification (ECN) Signaling with Nonces" (June 2003)
[RFC3540] specifies a nonce mechanism that uses an ECN bit combination which is not used in [RFC2481], but which is specified in [RFC3168] to allow a one-bit ECN nonce 🦄. This nonce mechanism includes a Nonce Sum (NS) field in the TCP header, so that senders can ensure that ACKs that do not indicate congestion are credible 🕵️♀️. The mechanism improves the robustness of congestion control by preventing receivers from exploiting ECN to gain an unfair share of network bandwidth 💅.
This nonce technique is not understood to have been widely implemented or deployed 🤷♀️. There has also been some discussion as to whether the mechanism is really effective, or is the best use of these bits (see emails to the IETF Transport Area Working Group (TSVWG) mailing list, in the thread "ECN nonce snag in TCP ESTATS MIB" from December 2006 - January 2007, or [MBJ07]) 💬.
5.2. Quick-Start 🚀
RFC 4782: "Quick-Start for TCP and IP" (January 2007)
Quick-Start provides a way for hosts to ask routers to help them select an initial sending rate, and to use this rate rather than the traditional small initial congestion window and slow-start algorithm 🏃♀️. [RFC4782] describes the Quick-Start mechanism and its use with TCP. In addition to discussing the benefits of Quick-Start, the document also discusses several limitations of the technique with respect to some types of tunnels in use over the Internet today, and other potential costs of Quick-Start, including those related to router design 🚧. Analysis of the effects of misbehaving entities, and appendices containing design rationale and related work, are also notably present in this RFC 🧐.
Many of the issues discussed in RFC 4782, including router architecture, network design / tunnels, and misbehaving agents, are all challenges relevant to other proposals that try to add router assistance into the network 🌸. The consideration of these issues can be illustrative for other protocol designers, even if they are not interested in Quick-Start itself 💖.
6. Non-TCP Unicast Congestion Control 🦋
In the past, TCP dominated Internet traffic, since it was used for many of the popular applications (email, web browsing, file transfer, remote login, etc.) 📬. The majority of early congestion control work focused on TCP, and the introduction of congestion control into TCP alone is often credited with saving the Internet from additional congestion collapse events 🙌. Today, TCP has been joined by other transport protocols (e.g., custom UDP-based protocols, SCTP, DCCP, RTP over UDP [RFC3550], etc.). So having properly functioning congestion control within these other protocols is important for the Internet's health (as explained in RFC 3714, for instance, or see the discussion of the "congestion control arms race" scenario in RFC 2914) 🏁. Documents that describe unicast congestion control methods for non-TCP transport protocols have been grouped into this section 🗂️.
RFC 4960: "Stream Control Transmission Protocol" (September 2007)
SCTP congestion control is very similar to TCP with Selective Acknowledgements, but there are some differences, as described in Section 7.1 of [RFC4960] 🧩. The major difference lies in the fact that SCTP supports multihoming, whereas TCP does not. Thus, SCTP keeps a different set of congestion control parameters for each destination address within an association, whereas TCP only keeps a single set of congestion control parameters per connection 🏠.
RFC 5348: "TCP Friendly Rate Control (TFRC): Protocol Specification" (September 2008)
[RFC5348], which obsoletes [RFC3448], specifies TCP-Friendly Rate Control (TFRC), a rate-based congestion control mechanism for unicast flows operating in a best-effort Internet environment where flows are competing with standard TCP traffic 🏎️. TFRC ensures conformance with TCP by continuously calculating the rate that a TCP sender would obtain under similar circumstances, using a slightly simplified version of the TCP Reno throughput equation in [PFTK98]. Its sending rate is smoother than the rate of TCP, which makes it suitable for multimedia applications 🎶. TFRC is not a wire protocol, but rather a mechanism that could, for instance, be used within a UDP-based application, in a transport protocol such as RTP, or in the context of endpoint congestion management [RFC3124] 🎀.
RFC 3550: "RTP: A Transport Protocol for Real-Time Applications" (July 2003)
[RFC3550] specifies the real-time transport protocol RTP along with its control protocol RTCP 📞. RTP/RTCP does not prescribe a specific congestion control behavior, but it is recommended that such a behavior be specified in each RTP profile. That is because the potential for reducing the sending rate is often content dependent in the case of real-time streams 🎥. Specifically, [RFC3550] states: "For some profiles, it may be sufficient to include an applicability statement restricting the use of that profile to environments where congestion is avoided by engineering. For other profiles, specific methods such as data rate adaptation based on RTCP feedback may be required". [RFC4585], which discusses RTCP feedback and adaptation mechanisms, points out that RTCP feedback may operate on much slower timescales than transport layer feedback mechanisms, and that additional mechanisms are therefore required to perform proper congestion control ⏳. One way to make use of such additional mechanisms is to run RTP over DCCP 💫.
RFC 4336: "Problem Statement for the Datagram Congestion Control Protocol (DCCP)" (March 2006)
[RFC4336] provides the motivation leading to the design of DCCP 🧠. In doing so, other possibilities of implementing similar functionality are discussed, including unreliable extensions of SCTP, RTP-based congestion control, and providing congestion control above or below UDP 🔍.
RFC 4340: "Datagram Congestion Control Protocol" (March 2006)
[RFC4340] specifies DCCP, the Datagram Congestion Control Protocol 🪄. This protocol provides bidirectional unicast connections of congestion-controlled unreliable datagrams. It is suitable for applications that can benefit from control over the tradeoff between timeliness and reliability ⚡. The core DCCP specification does not include a specific congestion control behavior. Rather, it functions as a framework for such mechanisms, which can be selected via the Congestion Control Identifier (CCID) 🔑.
RFC 4341: "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion Control" (March 2006)
[RFC4341] is the specification of TCP-like congestion control within DCCP 🌊. This should be used by senders who would like to take advantage of the available bandwidth in an environment with rapidly changing conditions, and who are able to adapt to the abrupt changes in the congestion window typical of TCP's Additive Increase Multiplicative Decrease (AIMD) congestion control 🎢. ECN is also supported within RFC 4341 ✅.
RFC 4342: "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)" (March 2006)
[RFC4342] is the specification of TFRC congestion control, as described in [RFC3448], for DCCP 🫧. This should be used by senders who want a TCP-friendly sending rate, possibly with Explicit Congestion Notification (ECN), while minimizing abrupt rate changes 🌷.
7. Multicast Congestion Control ✨
okay so multicast (that's one-to-many communication 📡) congestion control has mostly been tackled by the Reliable Multicast Transport (RMT) Working Group 💜 Apart from [RFC2357] and [RFC3208], every document in this section came out of that group. And here's the tea: a "one size fits all" protocol just can't cover every app in this space 😭 so they went modular instead, with "protocol cores" and "building blocks" 🧩 There are multiple congestion control building blocks, giving you both sender-driven and receiver-driven methods that differ a LOT in their assumptions and behavior 🔥
RFC 2357: "IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols" (June 1998)
Some early multicast content dissemination proposals skipped proper congestion control, and [RFC2357] calls that a severe mistake 💀 Large-scale multicast apps can cause vast congestion-related damage, so this doc makes the case that congestion control really needs to be built into multicast content dissemination protocols meant for the Internet 🫶
RFC 2887: "The Reliable Multicast Design Space for Bulk Data Transfer" (August 2000)
[RFC2887] briefly sketches several classes of possible congestion control schemes for single-sender multicast protocols 🦋 but it doesn't develop or select any specific protocol 🤷♀️
RFC 3048: "Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer" (January 2001)
[RFC3048] talks about the building block approach to RMT protocols and notes that several different congestion control building blocks may be needed to handle different situations 🌸 It also mentions some possible interactions between congestion control building blocks and those for Forward Error Correction (FEC), acknowledgement, and group management 🧚
RFC 3208: "PGM Reliable Transport Protocol Specification" (December 2001)
Pragmatic General Multicast (PGM) is a reliable multicast transport protocol for apps that need ordered or unordered, duplicate-free, multicast data delivery from multiple sources to multiple receivers 🍓 As [RFC3208]'s Appendix B explains, a PGM source can request congestion control feedback from both network elements (routers) and receivers (end hosts) 💖 That feedback can report the load on the worst link in a particular path, or the load on the worst path 👑 What to actually do with the feedback isn't part of RFC 3208, but using multicast routers to help with congestion control is a big deal 🔥
RFC 3450: "Asynchronous Layered Coding (ALC) Protocol Instantiation" (December 2002)
[RFC3450] specifies ALC, a rough header format built on the RMT building blocks, which multicast content dissemination protocols can use 🎀 ALC is meant to use a multi-rate congestion control building block, where the sender doesn't need any feedback 🙈 Instead, multiple multicast groups with different transmission rates are available within an ALC session, and receivers control their own rates by joining or leaving groups 🦋
RFC 3738: "Wave and Equation Based Rate Control (WEBRC) Building Block" (April 2004)
The WEBRC mechanism in [RFC3738] is receiver-driven congestion control, where each receiver in a multicast group can work out the individual rate at which packets get delivered to it 💅 WEBRC senders set up a base channel for control information and several multicast channels for data, each sending packets at a varying rate in the form of a wave 🌊 Receivers dynamically join and leave channels at chosen points within the wave of sending rates, to get the overall receive rate they want 🫧 That's based on an equation using the estimated loss probability and round-trip time within an epoch ⭐ And yes, WEBRC is compatible with use inside ALC ✨
RFC 4654: "TCP-Friendly Multicast Congestion Control (TFMCC): Protocol Specification" (August 2006)
[RFC4654] describes TFMCC, a sender-driven congestion control mechanism where the received rate for the whole multicast group is set by the worst-connected receiver 😭 TFMCC builds on TFRC, but scales down the feedback to prevent ACK-implosion effects, by having receivers suppress their feedback unless they think it's the worst in the reception group 🫶
8. Guidance for Developing and Analyzing Congestion Control Techniques 💅
Some recently published RFCs talk about which congestion control properties are "safe" for Internet deployment, plus how to measure those properties for congestion control mechanisms and transport protocols 🔍 These docs matter a lot to the ICCRG, since some of its work is reviewing congestion control proposals that have been brought to the IETF for publication (see http://www.ietf.org/iesg/statement/congestion-control.html) 🧠
RFC 5033 (BCP 133): "Specifying New Congestion Control Algorithms" (August 2007)
Multiple TCP modifications for high-rate use were being developed at the same time, and they were getting deployed on the Internet, which is why [RFC5033] was written 🚀 RFC 5033 comes from the Transport Area Working Group (TSVWG) and gives guidance on the classes of Experimental RFC that can be published to document algorithms: those encouraged for investigation on the Internet, and those only encouraged for experimentation in less-critical environments 🧪 It's been described as a checklist of things to think about when you're creating new congestion control techniques you plan to deploy widely 📋
RFC 5166: "Metrics for the Evaluation of Congestion Control Mechanisms" (March 2008)
The IRTF Transport Modeling Research Group (TMRG) produced [RFC5166] to describe the set of metrics, and the tradeoffs between them, that you can use to compare, contrast, and evaluate congestion control techniques 📊 It gives an overview of lots of these metrics and points you to their detailed descriptions 🗺️
9. Historic Interest 🕰️
Early in the RFC series there are lots of docs that are just an author's thoughts on a subject, or quick summaries of measurements and experiments, rather than the result of a long formal IETF process 📜 Some RFCs in this section are like that 💕
RFC 889: "Internet Delay Experiments" (December 1983)
Based on reported measurement experiments, [RFC0889] suggests changes to the TCP retransmission timeout (RTO) calculation 🌷 It notes that the original TCP RTO calculation causes congestion when a delay spike happens, because the RTO takes too long to adapt, which leads to superfluous retransmissions 😩
RFC 896: "Congestion Control in IP/TCP Internetworks" (January 1984)
[RFC0896] is the first document the authors know of that uses the term "congestion collapse" 🤯 Here it describes the stable state observed when a sudden load on the net made the round-trip time rise faster than sending hosts could update their measured round-trip time 📈 Two problems get discussed: the "small-packet problem" (now commonly called "silly window syndrome") and the "source-quench problem", which is about inappropriately deciding when to send and how to react to ICMP Source Quench messages 🙃 Solutions for both are presented 🎀
RFC 970: "On Packet Switches with Infinite Storage" (December 1985)
Using a thought experiment about a router with infinite buffering capacity, [RFC0970] develops a different kind of congestion collapse scenario, where few useful packet transmissions happen because the queue is longer than the time-to-live of the packets in it 🫠 As RFC 970 describes, the author also demonstrated this scenario with real equipment 🛠️
The doc also discusses game-theoretic analysis of congestion control, and getting fairness between behaving and non-behaving flows by focusing on the order of scheduling packets within the buffer, rather than on how buffer space is actually allocated between flows 🎲
RFC 1016: "Something a Host Could Do with Source Quench: The Source Quench Introduced Delay (SQuID)" (July 1987)
[RFC1016] outlines a rate-based congestion control mechanism where end hosts use Source Quench packets from routers to adjust their sending rates 🐢 RFC 1016 also suggests sending congestion notifications before queues are actually full, at a rate that goes up with the current queue occupancy 📶 This strategy has been used in several other AQM mechanisms, notably RED [FJ93] 🌈
RFC 1254: "Gateway Congestion Control Survey" (August 1991)
[RFC1254] is a survey of congestion control approaches in routers 🗂️ It first covers general congestion control performance goals (such as fairness), then digs into Source Quench messages (now discouraged, because they've been found ineffective) 🙅♀️ Random Drop (which would now be called "Active Queue Management") 🎲 Congestion Indication (DEC Bit, an early form of ECN) 🔔 "Selective Feedback Congestion Indication" (one particular method for applying ECN) 🎯 and Fair Queuing ⚖️ Finally it discusses end-system congestion control policies, including Jacobson's well-known algorithms [Jac88] and their predecessor, "CUTE" [Jain86] 👑
10. Security Considerations 🔐
This document introduces no new security considerations 🙌 Each RFC listed in this document discusses the security considerations of the specification it contains 💜
11. Acknowledgements 🫶
Several participants in the ICCRG contributed useful comments to this document, including Rex Buddenberg, Mitchell Erblichs, Lachlan Andrew, Sally Floyd, Stephen Farrell, Gorry Fairhurst, Lars Eggert, Mark Allman, and Juergen Schoenwaelder 🌸 thank u all, you're literally the best 💖
Okay bestie, last stop! 🦋 Here are all the receipts this doc is built on, so you can go check any of them yourself 💅
12. Informative References 📚✨
[FJ93] Floyd, S. and V. Jacobson, "Random Early Detection
Gateways for Congestion Avoidance", IEEE/ACM Transactions
on Networking, volume 1, number 4, August 1993.
[Gont10] Gont, F., "ICMP attacks against TCP", Work in Progress,
January 2010.
[Jac88] Jacobson, V., "Congestion Avoidance and Control",
Proceedings of ACM SIGCOMM 1988, in ACM Computer
Communication Review, 18 (4), pp. 314-329.
[Jain86] Jain, R., "A Timeout-Based Congestion Control Scheme for
Window Flow-Controlled Networks", IEEE Journal on Selected
Areas in Communications, volume 4, number 7, October 1986.
[MAF04] Medina, A., Allman, M., and S. Floyd, "Measuring
Interactions Between Transport Protocols and Middleboxes",
Proceedings of the Internet Measurement Conference 2004,
August 2004.
[MAF05] Medina, A., Allman, M., and S. Floyd, "Measuring the
Evolution of Transport Protocols in the Internet", ACM
Computer Communications Review, volume 35, issue 2,
April 2005.
[MBJ07] Moncaster, T., Briscoe, B., and A. Jacquet, "A TCP Test to
Allow Senders to Identify Receiver Non-Compliance", Work
in Progress, November 2007.
[PF01] Padhye, J. and S. Floyd, "On Inferring TCP Behavior",
Proceedings of ACM SIGCOMM 2001, August 2001.
[PFTK98] Padhye, J., Firoiu, V., Towsley, D., and J. Kurose,
"Modeling TCP Throughput: A Simple Model and its Empirical
Validation", Proceedings of ACM SIGCOMM 1998.
[RFC0889] Mills, D., "Internet delay experiments", RFC 889,
December 1983.
[RFC0896] Nagle, J., "Congestion control in IP/TCP internetworks",
RFC 896, January 1984.
[RFC0970] Nagle, J., "On packet switches with infinite storage",
RFC 970, December 1985.
[RFC1016] Prue, W. and J. Postel, "Something a host could do with
source quench: The Source Quench Introduced Delay
(SQuID)", RFC 1016, July 1987.
[RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1254] Mankin, A. and K. Ramakrishnan, "Gateway Congestion
Control Survey", RFC 1254, August 1991.
[RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated
Services in the Internet Architecture: an Overview",
RFC 1633, June 1994.
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers",
RFC 1812, June 1995.
[RFC1958] Carpenter, B., "Architectural Principles of the Internet",
RFC 1958, June 1996.
[RFC2001] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast
Retransmit, and Fast Recovery Algorithms", RFC 2001,
January 1997.
[RFC2140] Touch, J., "TCP Control Block Interdependence", RFC 2140,
April 1997.
[RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering,
S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G.,
Partridge, C., Peterson, L., Ramakrishnan, K., Shenker,
S., Wroclawski, J., and L. Zhang, "Recommendations on
Queue Management and Congestion Avoidance in the
Internet", RFC 2309, April 1998.
[RFC2357] Mankin, A., Romanov, A., Bradner, S., and V. Paxson, "IETF
Criteria for Evaluating Reliable Multicast Transport and
Application Protocols", RFC 2357, June 1998.
[RFC2414] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's
Initial Window", RFC 2414, September 1998.
[RFC2415] Poduri, K., "Simulation Studies of Increased Initial TCP
Window Size", RFC 2415, September 1998.
[RFC2416] Shepard, T. and C. Partridge, "When TCP Starts Up With
Four Packets Into Only Three Buffers", RFC 2416,
September 1998.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[RFC2481] Ramakrishnan, K. and S. Floyd, "A Proposal to add Explicit
Congestion Notification (ECN) to IP", RFC 2481,
January 1999.
[RFC2488] Allman, M., Glover, D., and L. Sanchez, "Enhancing TCP
Over Satellite Channels using Standard Mechanisms",
BCP 28, RFC 2488, January 1999.
[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion
Control", RFC 2581, April 1999.
[RFC2884] Hadi Salim, J. and U. Ahmed, "Performance Evaluation of
Explicit Congestion Notification (ECN) in IP Networks",
RFC 2884, July 2000.
[RFC2887] Handley, M., Floyd, S., Whetten, B., Kermode, R.,
Vicisano, L., and M. Luby, "The Reliable Multicast Design
Space for Bulk Data Transfer", RFC 2887, August 2000.
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41,
RFC 2914, September 2000.
[RFC2998] Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L.,
Speer, M., Braden, R., Davie, B., Wroclawski, J., and E.
Felstaine, "A Framework for Integrated Services Operation
over Diffserv Networks", RFC 2998, November 2000.
[RFC3048] Whetten, B., Vicisano, L., Kermode, R., Handley, M.,
Floyd, S., and M. Luby, "Reliable Multicast Transport
Building Blocks for One-to-Many Bulk-Data Transfer",
RFC 3048, January 2001.
[RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager",
RFC 3124, June 2001.
[RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z.
Shelby, "Performance Enhancing Proxies Intended to
Mitigate Link-Related Degradations", RFC 3135, June 2001.
[RFC3150] Dawkins, S., Montenegro, G., Kojo, M., and V. Magret,
"End-to-end Performance Implications of Slow Links",
BCP 48, RFC 3150, July 2001.
[RFC3155] Dawkins, S., Montenegro, G., Kojo, M., Magret, V., and N.
Vaidya, "End-to-end Performance Implications of Links with
Errors", BCP 50, RFC 3155, August 2001.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, September 2001.
[RFC3208] Speakman, T., Crowcroft, J., Gemmell, J., Farinacci, D.,
Lin, S., Leshchiner, D., Luby, M., Montgomery, T., Rizzo,
L., Tweedly, A., Bhaskar, N., Edmonstone, R.,
Sumanasekera, R., and L. Vicisano, "PGM Reliable Transport
Protocol Specification", RFC 3208, December 2001.
[RFC3366] Fairhurst, G. and L. Wood, "Advice to link designers on
link Automatic Repeat reQuest (ARQ)", BCP 62, RFC 3366,
August 2002.
[RFC3426] Floyd, S., "General Architectural and Policy
Considerations", RFC 3426, November 2002.
[RFC3439] Bush, R. and D. Meyer, "Some Internet Architectural
Guidelines and Philosophy", RFC 3439, December 2002.
[RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP
Friendly Rate Control (TFRC): Protocol Specification",
RFC 3448, January 2003.
[RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M.
Sooriyabandara, "TCP Performance Implications of Network
Path Asymmetry", BCP 69, RFC 3449, December 2002.
[RFC3450] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., and J.
Crowcroft, "Asynchronous Layered Coding (ALC) Protocol
Instantiation", RFC 3450, December 2002.
[RFC3481] Inamura, H., Montenegro, G., Ludwig, R., Gurtov, A., and
F. Khafizov, "TCP over Second (2.5G) and Third (3G)
Generation Wireless Networks", BCP 71, RFC 3481,
February 2003.
[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit
Congestion Notification (ECN) Signaling with Nonces",
RFC 3540, June 2003.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3649] Floyd, S., "HighSpeed TCP for Large Congestion Windows",
RFC 3649, December 2003.
[RFC3714] Floyd, S. and J. Kempf, "IAB Concerns Regarding Congestion
Control for Voice Traffic in the Internet", RFC 3714,
March 2004.
[RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate
Control (WEBRC) Building Block", RFC 3738, April 2004.
[RFC3742] Floyd, S., "Limited Slow-Start for TCP with Large
Congestion Windows", RFC 3742, March 2004.
[RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D.,
Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L.
Wood, "Advice for Internet Subnetwork Designers", BCP 89,
RFC 3819, July 2004.
[RFC4336] Floyd, S., Handley, M., and E. Kohler, "Problem Statement
for the Datagram Congestion Control Protocol (DCCP)",
RFC 4336, March 2006.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion
Control Protocol (DCCP) Congestion Control ID 2: TCP-like
Congestion Control", RFC 4341, March 2006.
[RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for
Datagram Congestion Control Protocol (DCCP) Congestion
Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342,
March 2006.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
July 2006.
[RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap
for Transmission Control Protocol (TCP) Specification
Documents", RFC 4614, September 2006.
[RFC4654] Widmer, J. and M. Handley, "TCP-Friendly Multicast
Congestion Control (TFMCC): Protocol Specification",
RFC 4654, August 2006.
[RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick-
Start for TCP and IP", RFC 4782, January 2007.
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
RFC 4960, September 2007.
[RFC5033] Floyd, S. and M. Allman, "Specifying New Congestion
Control Algorithms", BCP 133, RFC 5033, August 2007.
[RFC5166] Floyd, S., "Metrics for the Evaluation of Congestion
Control Mechanisms", RFC 5166, March 2008.
[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP
Friendly Rate Control (TFRC): Protocol Specification",
RFC 5348, September 2008.Authors' Addresses 🎀
Here's how to reach the authors, if you ever want to ask them something 🫶
Michael Welzl
University of Oslo
Department of Informatics
PO Box 1080 Blindern
N-0316 Oslo, Norway
Phone: +47 22 85 24 20
EMail: michawe@ifi.uio.no
Wesley M. Eddy
MTI Systems
NASA Glenn Research Center
21000 Brookpark Rd, MS 500-ASRC
Cleveland, OH 44135
Phone: (216) 433-6682
EMail: wes@mti-systems.com📦 where this page comes from
- ietf: rfc5783 2010-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms