RFC 3714

IAB Concerns Regarding Congestion Control for Voice Traffic in the Internet

📅 published March 2004, from ietf

RFC 3714 - Title Block Tea ☕🎀

Okay bestie, let's get into it. This is RFC 3714, and it's called IAB Concerns Regarding Congestion Control for Voice Traffic in the Internet 🦋. It's an Informational doc from the Network Working Group, dated March 2004. The editors are S. Floyd, Ed. and J. Kempf, Ed. 💅 The header doesn't list anything it obsoletes or updates, so it's standing on its own. 🌸

Status of This Memo ✨

Quick vibe check first: this memo is here to inform the Internet community 💖. It is not a standard, not even a little bit 🙈. Distribution is totally unlimited, so share it with whoever 🫶

The legal bit, kept exactly:

Copyright (C) The Internet Society (2004).  All Rights Reserved.

Abstract 🌈

So the big idea is this 🧚 The IAB is worried about whether best-effort voice traffic on the Internet can get proper end-to-end congestion control. The concerns are about fairness, user quality, and the risk of congestion collapse 😭

Why now? Because end-to-end QoS (Quality of Service) isn't widely deployed, and that probably won't change anytime soon 💀 The doc is not telling anyone how to deploy VoIP with QoS, and it's not saying best-effort is good enough for VoIP either. It's just noticing that voice sometimes runs best-effort on some links, that this will likely keep happening, and that the lack of end-to-end congestion control for it is a real concern 👑

Table of Contents 🎀

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
2.  An Example of the Potential for Trouble. . . . . . . . . . . .  4
3.  Why are Persistent, High Drop Rates a Problem? . . . . . . . .  6
    3.1.  Congestion Collapse. . . . . . . . . . . . . . . . . . .  6
    3.2.  User Quality . . . . . . . . . . . . . . . . . . . . . .  7
    3.3.  The Amorphous Problem of Fairness. . . . . . . . . . . .  8
4.  Current efforts in the IETF. . . . . . . . . . . . . . . . . . 10
    4.1.  RTP. . . . . . . . . . . . . . . . . . . . . . . . . . . 10
    4.2.  TFRC . . . . . . . . . . . . . . . . . . . . . . . . . . 11
    4.3.  DCCP . . . . . . . . . . . . . . . . . . . . . . . . . . 12
    4.4.  Adaptive Rate Audio Codecs . . . . . . . . . . . . . . . 12
    4.5.  Differentiated Services and Related Topics . . . . . . . 13
5.  Assessing Minimum Acceptable Sending Rates . . . . . . . . . . 13
    5.1.  Drop Rates at 4.75 kbps Minimum Sending Rate . . . . . . 17
    5.2.  Drop Rates at 64 kbps Minimum Sending Rate . . . . . . . 18
    5.3.  Open Issues. . . . . . . . . . . . . . . . . . . . . . . 18
    5.4.  A Simple Heuristic . . . . . . . . . . . . . . . . . . . 19
6.  Constraints on VoIP Systems . . . . . . . . . . . . . . . . . . 20
7.  Conclusions and Recommendations. . . . . . . . . . . . . . . . 20
8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
    9.1.  Normative References . . . . . . . . . . . . . . . . . . 21
    9.2.  Informative References . . . . . . . . . . . . . . . . . 22
10. Appendix - Sending Rates with Packet Drops . . . . . . . . . . 26
11. Security Considerations. . . . . . . . . . . . . . . . . . . . 29
12. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 29
13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 30
14. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 31

1. Introduction 💖

Okay so a lot of people in the telephony world assume commercial VoIP is waiting on end-to-end QoS 🙄 But honestly? Voice over best-effort broadband is already a thing, and the demand is growing 📈 Some ISPs run QoS on their backbones, and some corporate intranets have end-to-end QoS internally, but end-to-end QoS is generally not available to customers on today's Internet 😭

Since everyone's obsessed with VoIP on best-effort connections right now, it feels smart to look at how real-time flows might affect congestion 🧐 That's exactly what this doc does. Again, though, it's not recommending any deployment paths for VoIP in terms of QoS support, and it's not claiming best-effort can be trusted for acceptable VoIP performance 🙈 It's also not talking about signalling connections for VoIP. Still, voice really does get deployed as best-effort traffic over some Internet links today, and we expect that to continue. This doc is basically voicing our concern about the lack of effective end-to-end congestion control for that best-effort voice traffic 🫶

Here's the thing: as VoIP over best-effort connections keeps getting popular with broadband consumers, end-to-end QoS in public ISPs might be slow to show up 🐢 The IETF has made QoS standards for the Internet [DIFFSERV, RSVP] and is still active in this space [NSIS,COPS]. But deploying anything that needs changes to Internet infrastructure runs into a bunch of commercial and technical stuff, and tech that works without infrastructure changes gets a big speed advantage 🚀 [RFC2990] lays out some of the technical challenges of deploying QoS architectures on the Internet, so go read that if you're curious 🤓 Often, interim fixes get adopted for fast-growing apps, and they work well enough that the pressure to deploy the bigger, more disruptive stuff drops off 📉 Tons of infrastructure has been slow to roll out too, like IPv6, IP multicast, or a global PKI for IKE and IPsec support, so QoS mechanisms are in good company 😂

The interim QoS measures that are easiest to deploy are single-hop or edge-only QoS mechanisms for VoIP traffic on individual congested links, like edge-only QoS for cable access networks 🧁 These local forms of QoS could be really successful at protecting some chunk of best-effort VoIP traffic from congestion 💅 BUT, and this is a big but, they aren't directly visible to the end-to-end VoIP connection 👀 So a best-effort VoIP connection could still hit high end-to-end packet drop rates and be competing with other best-effort traffic, even if some links on the path have single-hop QoS. Not ideal, bestie 💀

IP telephony will probably run over best-effort broadband connections to public-access networks, along with dedicated IP networks, or as an alternative to band splitting on the last mile of ADSL or QoS on cable access networks 🌐 Residential VoIP services that run over broadband access links are already growing fast (e.g., [FWD, Vonage]) ✨ Right now a lot of public-access IP networks are uncongested in the core, with low or moderate link utilization, but that's not necessarily true on last hop links 🤔 If an IP telephony call goes all the way over the Internet, it could easily cross congested links at both ends 😬 Economics also matter here: Internet telephony will probably grow fastest in developing countries, where core links are more likely to be congested, so congestion control is an especially big deal for those places 🌍💜

So with IP telephony possibly running over congested best-effort networks, there are concerns about congestion collapse caused by fast growth in real-time voice that doesn't do end-to-end congestion control 😱 This doc raises concerns about fairness, user quality, and the danger of congestion collapse from rapid growth in best-effort telephony traffic on best-effort networks 📚 We're looking at best-effort telephony connections that have a minimum sending rate and that compete directly with other best-effort traffic on a path with at least one congested link. The specific question is whether that traffic should be required to terminate, or to suspend sending temporarily, when it faces a persistent, high packet drop rate, in cases where reducing the sending rate isn't a viable alternative 🥺

The concerns about fairness and congestion collapse don't just apply to telephony. They apply to video and other best-effort real-time traffic with a minimum sending rate too 🎬 [RFC2914] already makes the point that best-effort traffic needs end-to-end congestion control 💯 People sometimes say audio doesn't need it because audio sends at such a low rate compared to video and other real-time traffic 🙃 So while the concerns here are general, this doc zooms in on the particular issue of best-effort audio traffic 🎧

Want to give feedback? You can send it to the IAB mailing list at iab@ietf.org, or to the editors at floyd@icir.org and kempf@docomolabs-usa.com 💌 You can also post to the end2end-interest mailing list [E2E] 🦋

2. An Example of the Potential for Trouble ✨

Okay bestie, let's talk about a demo that's giving chaos but in a cute way 🎀. At the November, 2002, IEPREP Working Group meeting in Atlanta, people showed off VoIP running over a shared link between a hotel room in Atlanta, Georgia, USA, and Nairobi, Kenya 🌍. The link went over the typical uncongested Internet backbone and access links, out to peering points between each endpoint and the Internet backbone. The voice quality was honestly so good 😭, especially compared to the typical quality you get from a circuit-switched call to Nairobi 💅.

A presentation that came with the demo [A02] called the access links (e.g., DSL, T1, T3, dialup, and cable modem links) the main source of network congestion 🙈. It also said VoIP traffic is only a very small percentage of the packets in commercial ISP traffic. And it said VoIP still got good quality with packet drop rates of 5-40% [AUT]. Iconic, right? 👑

The VoIP call used an ITU-T G.711 codec, plus proprietary FEC encoding, plus RTP/UDP/IP framing 🧚. The resulting traffic load over the Internet was substantially more than the 64 kbps the codec needed. The main congestion point on the path was a 128 kbps access link between an ISP in Kenya and several of its subscribers in Nairobi. So one VoIP call ate more than half of that access link, and that capacity is shared across lots of different users 💀.

Note that this network setup is not a particularly good one for VoIP 🙈. If there are data services running TCP on the link with a typical packet size of 1500 bytes, some voice packets could be delayed an extra 90 ms. That could push the end-to-end delay above the ITU-recommended 150 ms [G.114] for speech traffic. The delay would be noticeable to users, with more variation in delay, and therefore worse call quality, as the bursty TCP traffic comes and goes 😩. For a call that already had high delay, like the Nairobi call from the previous paragraph, the extra jitter from competing TCP traffic also raises the demands on the jitter buffer at the receiver. Nevertheless, VoIP usage over congested best-effort links is likely to increase in the near future, regardless of VoIP's superior performance with "carrier class" service ✨.

A best-effort VoIP connection that keeps sending packets at 64 Kbps, eating half of a 128 Kbps access link, even with a drop rate of 40%, and with the user-perceptible degradation in voice quality that comes with it, is not behaving in a way that serves the interests of either the VoIP users or the other concurrent users of the network 😤. Not it.

As the Nairobi connection demonstrates, prescribing universal overprovisioning (or more precisely, provisioning sufficient to avoid persistent congestion) as the solution to the problem is not an acceptable generic solution 🙅. For example, in regions of the world where circuit-switched telephone service is poor and expensive, and Internet access is possible and lower cost, provisioning all Internet links to avoid congestion is likely to be impractical or impossible 🌸.

In particular, an over-provisioned core is not by itself sufficient to avoid congestion collapse all the way along the path, because an over-provisioned core can not address the common problem of congestion on the access links 🧱. Many access links routinely suffer from congestion. It is important to avoid congestion collapse along the entire end-to-end path, including along the access links (where congestion collapse would consist of congested access links wasting scarce bandwidth carrying packets that will only be dropped downstream) 🗑️. So an over-provisioned core does not by itself eliminate or reduce the need for end-to-end congestion avoidance and control 🫶.

There are two possible mechanisms for avoiding this congestion collapse: call rejection during busy periods, or the use of end-to-end congestion control 🚦. Because there are currently no acceptance/rejection mechanisms for best-effort traffic in the Internet, the only alternative is the use of end-to-end congestion control. This is important even if end-to-end congestion control is invoked only in those very rare scenarios with congestion in generally-uncongested access links or networks 🌈. There will always be occasional periods of high demand, e.g., in the two hours after an earthquake or other disaster, and that is exactly when it is important to avoid congestion collapse 🚨.

Best-effort traffic in the Internet does not include mechanisms for call acceptance or rejection 📵. Instead, a best-effort network itself is largely neutral in terms of resource management, and the interaction of the applications' transport sessions mutually regulates network resources in a reasonably fair fashion 🤝. One way to bring voice into the best-effort environment in a non-disruptive manner is to focus on the codec and look at rate adaptation measures that can successfully interoperate with existing transport protocols (e.g., TCP), while at the same time preserving the integrity of a real-time, analog voice signal 🎶. Another way is to consider codecs with fixed sending rates. Whether the codec has a fixed or variable sending rate, we consider the appropriate response when the codec is at its minimum data rate, and the packet drop rate experienced by the flow remains high 🧐. This is the key issue addressed in this document 🔑.

3. Why are Persistent, High Drop Rates a Problem? 🤔

Persistent, high packet drop rates are rarely seen on the Internet today, in the absence of routing failures or other major disruptions 🙌. This happy situation is due primarily to low levels of link utilization in the core, with congestion typically found on lower-capacity access links, and to the use of end-to-end congestion control in TCP 🎀. Most of the traffic on the Internet today uses TCP, and TCP self-corrects so that the two ends of a connection reduce the rate of packet sending if congestion is detected 🪄. In the sections below, we discuss some of the problems caused by persistent, high packet drop rates 👇.

3.1. Congestion Collapse 💥

One possible problem caused by persistent, high packet drop rates is that of congestion collapse. Congestion collapse was first observed during the early growth phase of the Internet of the mid 1980s [RFC896], and the fix was provided by Van Jacobson, who developed the congestion control mechanisms that are now required in TCP implementations [Jacobson88, RFC2581] 👑.

As described in RFC 2914, congestion collapse occurs in networks with flows that traverse multiple congested links having persistent, high packet drop rates [RFC2914]. In particular, in this scenario packets that are injected onto congested links squander scarce bandwidth, since these packets are only dropped later, on a downstream congested link 😭. If congestion collapse occurs, all traffic slows to a crawl and nobody gets acceptable packet delivery or acceptable performance 🐌. Because congestion collapse of this form can occur only for flows that traverse multiple congested links, congestion collapse is a potential problem in VoIP networks when both ends of the VoIP call are on a congested broadband connection such as DSL, or when the call traverses a congested backbone or transoceanic link 🌊.

3.2. User Quality 🎧

A second problem with persistent, high packet drop rates concerns the service quality seen by end users 🫧. Consider a network scenario where each flow traverses only one congested link, as could have been the case in the Nairobi demonstration above 📞. For example, imagine N VoIP flows sharing a 128 Kbps link, with each flow sending at least 64 Kbps 🧮. For simplicity, suppose the 128 Kbps link is the only congested link, and there is no traffic on that link other than the N VoIP calls. We will also ignore for now the extra bandwidth used by the telephony traffic for FEC and packet headers, or the reduced bandwidth (often estimated as 70%) due to silence suppression. We also ignore the fact that the two streams composing a bidirectional VoIP call, one for each direction, can in practice add to the load on some links of the path 🙃.

Given these simplified assumptions, the arrival rate to that link is at least N*64 Kbps. The traffic actually forwarded is at most 2*64 Kbps (the link bandwidth), so at least (N-2)*64 Kbps of the arriving traffic must be dropped. Thus, a fraction of at least (N-2)/N of the arriving traffic is dropped, and each flow receives on average a fraction 1/N of the link bandwidth. An important point to note is that the drops occur randomly, so that no one flow can be expected statistically to present better quality service to users than any other. Everybody's voice quality therefore suffers 😢.

It seems clear from this simple example that the quality of best-effort VoIP traffic over congested links can be improved if each VoIP flow uses end-to-end congestion control, and has a codec that can adapt the bit rate to the bandwidth actually received by that flow 💡. The overall effect of these measures is to reduce the aggregate packet drop rate, thus improving voice quality for all VoIP users on the link ✨. Today, applications and popular codecs for Internet telephony attempt to compensate by using more FEC, but controlling the packet flow rate directly should result in less redundant FEC information, and thus less bandwidth, thereby improving throughput even further 📈.

The effect of delay and packet loss on VoIP in the presence of FEC has been investigated in detail in the literature [JS00, JS02, JS03, MTK03]. One rule of thumb is that when the packet loss rate exceeds 20%, the audio quality of VoIP is degraded beyond usefulness, in part due to the bursty nature of the losses [S03]. We are not aware of measurement studies of whether VoIP users in practice tend to hang up when packet loss rates exceed some limit 📴.

The simple example in this section considered only voice flows, but in reality, VoIP traffic will compete with other flows, most likely TCP. The response of VoIP traffic to congestion works best by taking into account the congestion control response of TCP, as is discussed in the next subsection 🫶.

3.3. The Amorphous Problem of Fairness ⚖️

okay so the third problem with those persistent, high packet drop rates is fairness 💅. We're only looking at best-effort VoIP fighting with other best-effort traffic on the Internet. We're not covering emergency services or QoS-enabled traffic that gets treated separately on a congested link, so no drama there 🙅‍♀️.

Fairness is kinda hard to pin down 🥺, so we'll show the vibe by adding TCP traffic to the congested link from the last section. Now the non-congestion-controlled traffic and the congestion-controlled TCP traffic [RFC2914] are sharing the link, and the TCP sending rate is set by the packet drop rate those flows see. Same as before, the 128 Kbps link has N VoIP connections each sending 64 Kbps, which gives a packet drop rate of at least (N-2)/N on the congested link 📉. TCP flows get hit with those same drop rates, but a TCP flow in that situation sends way less than 64 Kbps 😭. So from the "who gets how much bandwidth" angle, the VoIP traffic is literally crowding out the TCP traffic. Not cute 💀.

BUT (and this is important) that's just one way to look at it 🧐. How fair VoIP and TCP look to each other depends on what you assume about packet sizes and round-trip times. With a fixed packet drop rate, for example, a TCP flow with bigger packets sends more (in Bps, bytes per second) than one with smaller packets 📦. A TCP flow with a shorter round-trip time also sends more (in Bps) than one with a longer round-trip time ⚡. In environments with high packet drop rates, TCP's sending rate also depends on how the retransmit timer (RTO) gets set 🕰️. A TCP implementation with a more aggressive RTO setting sends more than one with a less aggressive RTO setting 🏃‍♀️.

The annoying part is that there's no obvious canonical round-trip time for judging relative fairness on the network 🙃. The literature agrees that most packets on most links see round-trip times somewhere between 10 and 500 ms [RTTWeb] 🌍.

(This doesn't include satellite links 🛰️.) So if there were a canonical round-trip for judging fairness, it would have to live in that range. Without a single representative round-trip time, this paper assumes it's reasonable to compare a VoIP connection with a TCP connection that has the same round-trip time 🤝.

Packet size is the same deal. There's no canonical packet size for judging fairness between TCP connections 🫠. But the most common packet size for TCP data packets is 1460 bytes [Measurement], so we assume it's reasonable to compare a VoIP connection with a TCP connection sending 1460-byte data packets 📏. And yeah, 1460 bytes is way bigger than what VoIP packets usually are 😤.

Now the RTO. RFC 2988 specifies TCP's algorithm for setting TCP's RTO 🧮, but there's no canonical value for the minimum RTO, and the minimum RTO really affects TCP's sending rate when things are super congested [RFC2988] 🔥. RFC 2988 says TCP's RTO must be set to SRTT + 4*RTTVAR, where SRTT is the smoothed round-trip time and RTTVAR is the mean deviation of recent round-trip time measurements 📐. RFC 2988 also states that the RTO "SHOULD" have a minimum value of 1 second ⏱️. Still, it's not unusual in practice for TCP implementations to have a minimum RTO as low as 100 ms 👀. For this document, when we're thinking about relative fairness, we'll assume a minimum RTO of 100 ms 💜.

Here's one more twist 🌀. TCP connections that use fine-grained timestamps can send way more than TCP connections without timestamps, in environments with high packet drop rates 🚀. For TCP connections with fine-grained timestamps, a valid round-trip time measurement happens when a retransmitted packet gets successfully received and acknowledged by the receiver. In that case, a backed-off retransmit timer can be un-backed-off too 🔄. For TCP connections without timestamps, a valid round-trip time measurement only happens when a new packet's transmission gets received and acknowledged by the receiver 🙈. That means way fewer chances to un-back-off the retransmit timer 🥲. In this document, when we're thinking about relative fairness, we use a TCP connection without timestamps, since that's the dominant way TCP gets used on the Internet 🌐.

There's also a separate claim that sometimes gets raised in fairness debates: that best-effort VoIP traffic is inherently more important that other best-effort traffic (like web surfing, peer-to-peer traffic, or multi-player games), so it should get a bigger slice of the bandwidth when things are really congested 🎮. Our assumption here is that TCP traffic includes pressing email messages, business documents, and emergency information downloaded from web pages, plus all the more recreational stuff listed above 📧💼🚨. So we don't agree that best-effort VoIP should be exempt from end-to-end congestion control just because of some claim that its content is inherently more valuable 🙅‍♀️. (And honestly, you could just as logically argue that email and instant messaging are more efficient ways to communicate than VoIP in terms of bandwidth usage, so they're the more valuable uses of scarce bandwidth in times of high congestion 🤷‍♀️.) The real point is that the network is incapable of judging how valuable traffic is to users 🧠. The default assumption is that all best-effort traffic has equal value to the network provider and to the user 🫶.

Quick clarification: this fairness talk does not in any way challenge the right of ISPs to allocate bandwidth on congested links to classes of traffic however they choose 🏢. (For example, administrators rate-limit the bandwidth used by peer-to-peer traffic on some links, so bandwidth is also available for other classes of traffic 🍰.) This discussion just argues that there's no reason entire classes of best-effort traffic should be exempt from end-to-end congestion control 🌸.

4. Current efforts in the IETF 🧑‍💻

There are four efforts currently underway in the IETF to address congestion control for real time traffic 🎀: an upgrade of the RTP specification, TFRC, DCCP, and work on audio codecs 🎧.

4.1. RTP 📡

RFC 1890, the original RTP Profile for Audio and Video Control, doesn't discuss congestion control [RFC1890] 🙊. The revised document, "RTP Profile for Audio and Video Conferences with Minimal Control" [RFC3551], discusses congestion control in Section 2 👀. [RFC3551] says the following:

"If best-effort service is being used, RTP receivers SHOULD monitor packet loss to ensure that the packet loss rate is within acceptable parameters. Packet loss is considered acceptable if a TCP flow across the same network path and experiencing the same network conditions would achieve an average throughput, measured on a reasonable timescale, that is not less than the RTP flow is achieving. This condition can be satisfied by implementing congestion control mechanisms to adapt the transmission rate (or the number of layers subscribed for a layered multicast session), or by arranging for a receiver to leave the session if the loss rate is unacceptably high."
"The comparison to TCP cannot be specified exactly, but is intended as an "order-of-magnitude" comparison in timescale and throughput. The timescale on which TCP throughput is measured is the round-trip time of the connection. In essence, this requirement states that it is not acceptable to deploy an application (using RTP or any other transport protocol) on the best-effort Internet which consumes bandwidth arbitrarily and does not compete fairly with TCP within an order of magnitude."

Notice that [RFC3551] says receivers "SHOULD" monitor packet loss 🔍. It does not explicitly say that RTP senders and receivers "MUST" detect and respond to a persistent high loss rate 🤔. Now, congestion collapse can be considered a "danger to the Internet" 🚨, so using "MUST" would be appropriate for RTP traffic on the best-effort Internet, where VoIP traffic shares a link with other traffic 🫣. That's because "danger to the Internet" is one of the two criteria RFC 2119 gives for using "MUST" [RFC2119] 📜. Different requirements may apply to a private best-effort IP network provisioned solely for VoIP, where the VoIP traffic doesn't interact with the wider Internet 🏡.

4.2. TFRC 📊

As mentioned in RFC 3267, equation-based congestion control is one of the possibilities for VoIP 🧪. TCP Friendly Rate Control (TFRC) is the equation-based congestion control mechanism that's been standardized in the IETF ✅. The TFRC specification, "TCP Friendly Rate Control (TFRC): Protocol Specification" [RFC3448], says the following:

"TFRC ... is reasonably fair when competing for bandwidth with TCP flows, but has a much lower variation of throughput over time compared with TCP, making it more suitable for applications such as telephony or streaming media where a relatively smooth sending rate is of importance. ... TFRC is designed for applications that use a fixed packet size, and vary their sending rate in packets per second in response to congestion. Some audio applications require a fixed interval of time between packets and vary their packet size instead of their packet rate in response to congestion. The congestion control mechanism in this document cannot be used by those applications; TFRC-PS (for TFRC- PacketSize) is a variant of TFRC for applications that have a fixed sending rate but vary their packet size in response to congestion. TFRC-PS will be specified in a later document."

There's no draft for TFRC-PS yet, sadly 😢, but several researchers are still working on these issues 🧑‍🔬✨.

4.3. DCCP 🌊

The Datagram Congestion Control Protocol (DCCP) is a transport protocol being standardized in the IETF for unreliable flows 🎈. The application can specify either TCP-like or TFRC congestion control [DCCP03] 🎛️.

DCCP currently has two Congestion Control IDentifiers, or CCIDs 🆔. They are CCID 2 for TCP-like congestion control and CCID 3 for TFRC congestion control 🪪. As TFRC-PS becomes available and goes through the standards process, we'd expect DCCP to create a new CCID, CCID 4, for use with TFRC-PS congestion control 🔮💖.

4.4. Adaptive Rate Audio Codecs 🎀

okay so bestie, picking the right codec is literally a make-or-break decision for any real-time app 💅 You want codecs that run at a low sending rate, or that dial the rate down when throughput drops and/or packet loss goes up. If you don't have that, and the app also ignores the congestion response recommended in this document, the app is lowkey going to raise the risk of Internet congestion collapse 💀 and that messes with the health of the deployed Internet 😭 If a codec can lower its bit rate when there's congestion, then way more VoIP or TCP sessions can share a congested link while users still get acceptable performance ✨ That's the main character energy we want 👑 Plenty of current audio codecs can send at a low bit rate, and some even adapt their sending rate based on congestion signals from the network 🦋

RFC 3267 describes RTP payload formats for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) audio codecs [RFC 3267] 🌸 The AMR codec has eight speech encoding modes with bit rates between 4.75 and 12.2 kbps, it encodes speech in 20 ms frames, and it can reduce the transmission rate during silence periods 🤍 The payload format in RFC 3267 also includes forward error correction (FEC) and frame interleaving, which helps a bit with robustness against packet loss 🛡️ AMR was picked by the Third Generation Partnership Project (3GPP) as the mandatory codec for third generation (3G) cellular systems, and RFC 3267 recommends that AMR or AMR-WB applications using its RTP payload format use congestion control, though it doesn't recommend one specific mechanism 🧚 RFC 3267 names "Equation-Based Congestion Control for Unicast Applications" as an example of a congestion control mechanism that suits real-time flows [FHPW00] 💜

The "Internet Low Bit Rate Codec", iLBC, is an IETF effort to build an IPR-free codec for robust voice communication over IP [ILBRC] 🌈 It's designed so speech quality degrades gracefully when packets get lost, and it has a payload bit rate of 13.33 kbps for 30 ms frames or 15.20 kbps for 20 ms frames 🎶

There are several unencumbered low-rate codec algorithms in Ivox (the Interactive VOice eXchange) [IVOX], and more variable rate codecs are planned 🍓 For example, LPC2400 (a.k.a. LQ2400) is a 2400 bps LPC based codec with an enhancement that permits "silence detection" 🙈 The 2400 bps codec is reported to have a "slight robotic quality" [A03] (and that's even before we add packet loss into the mix 😭) The older multirate codec described in [KFK79, KF82] is an LPC codec that works at two rates, 2.4 kbps and 9.6 kbps, and it can optionally send extra "residual" bits for better quality at the higher rate ✨

Off-the-shelf ITU-T vocoders like G.711 were mostly designed for circuit-switched networks, so they aren't as well adapted for Internet use, even with FEC added on top 🙅‍♀️

The Differentiated Services Working Group [DIFFSERV] wrapped up in 2003, and it finished the standards for the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers [RFC2474], along with several per-hop forwarding behaviors [RFC2597, RFC3246] 🎀 The Next Steps in Signaling Working Group [NSIS] is working on an optimized signalling protocol for QoS, based partly on earlier work from the Resource Reservation Setup Protocol Working Group [RSVP] 🔥 We won't dig into these and related efforts any further in this document, because this document is only about that VoIP traffic that might ride as best-effort traffic over some congested link in the Internet 🫶

5. Assessing Minimum Acceptable Sending Rates ✨

okay so the DCCP and AVT working groups aren't really looking at apps that have a minimum sending rate and can't go any lower 😭 that's a gap, and the TFRC-PS draft has to deal with it. As the RTP document suggests, if the loss rate stays unacceptably high compared to the current sending rate, and a best-effort app can't lower its rate, then the only real answer is for that flow to stop sending on that link 🛑. For a multicast session, that could mean the receiver leaves the multicast group. For a unicast session, the connection could end, at least for a while 🎀

Let's set up the problem properly 🧠 Picture a best-effort, adaptive audio app that can drop down to a minimum sending rate of N Bps (bytes per second) of application data, sending M packets per second. Is that low enough that the flow never has to be killed because of congestion, or never has to cut its packets-per-second rate even further? Put another way, is N Bps an acceptable minimum for the app, one that can keep going through congestion without being terminated or suspended? 👀

We're going to assume, generously for VoIP 💖, that the network's bottleneck is limited by bandwidth in bytes per second (Bps), and not by CPU cycles or packets per second (pps). If the limit is bandwidth, it's a Bps limit. If the limit is router processing in packets, it's a pps limit. Now, TCP sends fixed-size data packets and cuts its rate in pps when it adapts to congestion, which lowers the load on the forward path in both Bps and pps 💅 Adaptive VoIP is different. Sometimes it keeps the same pps rate but shrinks the packet size, which lowers the rate in Bps. That's a great fit for audio, and a good response on a path where the limit is in Bps. It's a less appropriate response on a path where the limit is in pps 🤔

If the network limit really is in Bps, then the only thing that matters for congestion is a flow's sending rate on the wire in Bps. If that assumption is wrong, the sending rate in pps could add to congestion even when the Bps rate is pretty moderate 😬 The dream would be a transport protocol that can tell whether the bottleneck links on a path are limited in Bps or pps, and respond correctly when it's pps. But that ideal is hard to reach, and we don't want to hold back congestion control for telephony traffic until we get there 🙅‍♀️ Also, current TCP congestion control isn't very effective when the reverse path is limited in pps. TCP does give an incentive to use big data packets, but it has no real congestion control for the stream of small acknowledgement packets on the reverse path 🥲 So, given all that, it seems fine to assume a Bps limit rather than a pps limit when we think about the minimum sending rate for telephony traffic ✨

Assuming 40-byte packet headers (IP, RTP, and UDP or DCCP), an application data rate of N Bps and M pps works out to a sending rate on the wire of B = N+40M Bps 🧮 If the app uses FEC (Forward Error Correction), the FEC bits have to be added too. In this example, we skip the bandwidth tweaks needed for FEC overhead or for the lower rate during silence periods. We also aren't counting header compression on congested edge links, which can really cut the number of header bytes on those links 🌸

Now let's look at an equivalent-rate TCP connection with data packets of P bytes and a round-trip time of R seconds. Counting header size, a TCP connection sending B Bps on the wire is sending B/(P+40) pps, or equivalently BR/(P+40) ppr (packets per round-trip time) 📐

So here's the question restated with those formulas for VoIP and TCP 💜 If the best-effort VoIP connection is seeing a persistent packet drop rate of D, and it's already at its minimum sending rate on the wire of B Bps, when should the app or transport protocol terminate or suspend the VoIP connection? 😭

One answer is to work out the ppr sending rate for a TCP connection sending at the same Bps rate on the wire, then use the TCP response function to figure out whether a conformant TCP connection could keep a rate close to that under the same persistent drop rate D. If the VoIP sending rate is way higher than what a conformant TCP connection would get under the same conditions, and the VoIP connection can't cut its on-the-wire rate, then the VoIP connection should terminate or suspend 🎀

As we talked about above, there are two reasons to make the app terminate:

  1. Avoiding congestion collapse, since there might be several congested links.
  2. Fairness for congestion-controlled TCP traffic sharing the link.

Plus, if an app needs a minimum service level from the network to work, and that level is consistently not being met, then the app should terminate or suspend sending 🫶

Someone might say users will just hang up anyway when drops are high, so there's no point enforcing a minimum acceptable rate. But users might not hang up. They might keep talking, with the occasional bit of noise getting through, for minutes or longer, waiting for a short window of clarity 👂 Another counter-argument is that nobody really gains when VoIP connections end or suspend once persistent drop rates go past the allowable drop rate for the configured minimum sending rate. That isn't true! Ending those VoIP connections could let competing TCP and VoIP traffic make some progress 🌈

In the next section, we walk through this approach for VoIP flows with minimum sending rates of 4.75 and 64 kbps, and show that in practice it wouldn't be too burdensome for VoIP traffic 🦋 Here's the headline: this approach means VoIP traffic would terminate or suspend once the packet drop rate significantly exceeds 40% for a VoIP flow with a minimum sending rate of 4.75 kbps 😳 If VoIP is going to deliver "carrier quality," or even close to it, on best-effort links, then requiring it to keep its maximum sending rate through persistent packet drop rates above 40% is not going to win over consumers, no matter how big the price difference is. Good packet throughput is vital for acceptable VoIP service 💅

For a VoIP flow that stops sending because its minimum sending rate is too high for the steady-state packet drop rate, we haven't yet addressed when that flow could start sending again to check whether the end-to-end path congestion has changed. That question is covered in a proposal for Probabilistic Congestion Control [PCC] 🔮

One more thing 👀 If congestion shows up as ECN-marked packets (Explicit Congestion Notification) instead of dropped packets, then the answers about when a flow with a minimum sending rate would have to stop are a bit different. ECN lets routers tell end-nodes about congestion by ECN-marking packets instead of dropping them [RFC3168]. If packets get ECN-marked instead of dropped, there aren't any concerns about congestion collapse or user quality (at least for the ECN-capable traffic), and what's left is fairness with competing flows 🙌 Also, when congestion is really high, TCP gets a higher sending rate with ECN-marked packets than with dropped ones, partly because of different dynamics around un-backing-off a backed-off retransmit timer ⭐

5.1. Drop Rates at 4.75 kbps Minimum Sending Rate

Okay so picture an adaptive audio app with an RTT of R=0.1 seconds 🎀 that can chill out down to a minimum sending rate of 4.75 kbps application data, sending M=20 packets per second. That works out to N=593 Bps of application data, which means a sending rate on the wire of B=1393 Bps. An equivalent-rate TCP connection with data packets of P=1460 bytes and a round-trip time of R=0.1 seconds would be sending BR/(P+40) = 0.09 ppr 🦋

Table 1 in the Appendix looks at the packet drop rate a TCP connection experiences with the RTO set to twice the RTT, and it gives the matching sending rate of that TCP connection in ppr 💅 The second column is the sending rate from the standard analytical approach. The third, fourth, and fifth columns are the average sending rates from simulations with random packet drops or marks. The sixth column has the sending rates from experiments on a 4.8-RELEASE FreeBSD machine. The analytical approaches need an RTO expressed as a multiple of the RTT, so Table 1 shows the results for the RTO set to 2 RTT. In the simulations, the minimum RTO is set to twice the RTT. See the Appendix for more details ✨

So for a sending rate of 0.09 ppr with an RTO set to 2 RTT, Table 1 says the analytical approach gives a packet drop rate of roughly 50%. Meanwhile the simulations in the fifth column and the experiments in the sixth column give a packet drop rate of between 35% and 40% to keep a sending rate of 0.09 ppr 👀 (For a reference TCP connection using timestamps, shown in the fourth column, the simulations give a packet drop rate of 55% to maintain a sending rate of 0.09 ppr.) Of the two ways of figuring out how TCP's sending rate relates to the packet drop rate, the analytic approach and the simulations, we think the simulations are the most realistic, for reasons discussed in the Appendix 🧠 This suggests a packet drop rate of 40% would be reasonable for a TCP connection with an average sending rate of 0.09 ppr. As a result, a VoIP connection with an RTT of 0.1 sec and a minimum sending rate of 4.75 kbps would be required to terminate or suspend when the persistent packet drop rate significantly exceeds 40% 😭

These estimates are sensitive to the assumed round-trip time of the TCP connection, so keep that in mind 🫶 If we instead assumed that the equivalent-rate TCP connection had a round-trip time of R=0.01 seconds, it would be sending BR/(P+40) = 0.009 ppr. But we've also assumed a minimum RTO for TCP connections of 0.1 seconds, which in this case would mean an RTO of at least 10 RTT. For this setting of the RTO, we'd use Table 2 from the appendix to find the average TCP sending rate for a particular packet drop rate. The simulations in the fifth column of Table 2 suggest that a TCP connection with an RTT of 0.01 sec and an RTO of 10 RTT would be able to send 0.009 ppr with a packet drop rate of 45% 🌸 (For the same TCP connection using timestamps, shown in the fourth column, the simulations give a packet drop rate of 60-65% to maintain a sending rate of 0.009 ppr.)

So, for a VoIP connection with an RTT of 0.01 sec and a minimum sending rate of 4.75 kbps, the VoIP connection would be required to terminate or suspend when the persistent packet drop rate exceeded 45% 💜

5.2. Drop Rates at 64 kbps Minimum Sending Rate

Bumping the minimum acceptable sending rate up to 64 kbps basically means the packet drop rate where the app should terminate or suspend sending goes down 🍓 For this section, let's consider a codec with a minimum sending rate of 64 kbps, or N=8000 Bps, and a packet sending rate of M=50 pps. (That's the same as 160-byte data packets, with 20 ms. per packet.) The sending rate on the wire is B = N+40M Bps, including headers, which comes out to 10000 Bps. A TCP connection with that sending rate, with packets of size P=1460 bytes and a round-trip time of R=0.1 seconds, sends BR/(P+40) = 0.66 ppr. From the fifth column of Table 1, for an RTO of 2 RTT, this corresponds to a packet drop rate between 20 and 25%. [For a TCP connection using fine-grained timestamps, as shown in the fourth column of Table 1, this sending rate corresponds to a packet drop rate between 25% and 35%.] So a VoIP connection with an RTT of 0.1 sec and a minimum sending rate of 64 kbps would be required to terminate or suspend when the persistent packet drop rate significantly exceeds 25% 🔥

For an equivalent-rate TCP connection with a round-trip time of R=0.01 seconds and a minimum RTO of 0.1 seconds (giving an RTO of 10 RTT), we use the fifth column of Table 2. It shows that a sending rate of 0.066 ppr corresponds to a packet drop rate of roughly 30% ✨ [For a TCP connection using fine-grained timestamps, as shown in the fourth column of Table 2, this sending rate corresponds to a packet drop rate of roughly 45%.] Thus, for a VoIP connection with an RTT of 0.01 sec and a minimum sending rate of 64 kbps, the VoIP connection would be required to terminate or suspend when the persistent packet drop rate exceeded 30% 💖

5.3. Open Issues

Okay, real talk: this document doesn't try to specify a complete protocol 🙈 For example, it doesn't define what a persistent packet drop rate actually is. The assumption is that a "persistent packet drop rate" would refer to the packet drop rate over a significant number of round-trip times, e.g., at least five seconds. Another possibility is that the time interval for measuring the persistent drop rate is a function of the lifetime of the connection, with longer-lived connections using longer time intervals for measuring the persistent drop rate 🦋

The time period for detecting persistent congestion also affects the potential synchronization of VoIP sessions, where they all terminate or suspend at the same time in response to shared congestion 😱 If flows use some randomization when setting the time interval for detecting persistent congestion, or use a time interval that's a function of the connection lifetime, this could help stop all the VoIP flows from terminating at the same time 🧚

Another design issue for a complete protocol is whether a flow terminates when the packet drop rate is too high, or only suspends temporarily. For a flow that suspends temporarily, there's the question of how long it should wait before resuming transmission. At the very least, the sender should wait long enough that the flow's overall sending rate doesn't exceed the allowed sending rate for that packet drop rate 💅

The recommendation of this document is that VoIP flows with minimum sending rates should have corresponding configured packet drop rates, so the flow terminates or suspends when the persistent packet drop rate of the flow exceeds the configured rate. If the persistent packet drop rate increases over time, flows with higher minimum sending rates would have to suspend sending before flows with lower minimum sending rates. If VoIP flows terminate when the persistent packet drop rate is too high, this could lead to scenarios where VoIP flows with lower minimum sending rates basically get all of the link bandwidth, while the VoIP flows with higher minimum sending rates are forced to terminate 💀 However, if VoIP flows suspend sending for a time when the persistent packet drop rate is too high, instead of terminating entirely, then the bandwidth could end up being shared reasonably fairly between VoIP flows with different minimum sending rates 🌈

5.4. A Simple Heuristic

Here's a simple heuristic for estimating congestion: use the RTCP reported loss rate as an indicator 👑 For example, if the RTCP-reported lost rate is greater than 30%, or N back-to-back RTCP reports are missing, the application could assume that the network is too congested and terminate or suspend sending 🎀

6. Constraints on VoIP Systems ✨

Ultimately, trying to run VoIP on congested links, even with adaptive rate codecs and minimum packet rates, is likely to run into hard constraints because of the nature of real time traffic in heavily congested scenarios 😭 VoIP systems have a limited ability to scale their packet rate. If the number of packets decreases, the amount of audio per packet goes up, and error concealment at the receiver gets harder 🙈 Any error longer than phoneme length, which is typically 40 to 100 ms depending on the phoneme and speaker, is unrecoverable 💀 Ideally, applications want sub 30ms packets, and that's what most voice codecs provide 💖 On top of that, voice media streams are more sensitive to loss at lower data rates. Lower-data rate codecs maintain more end-to-end state, and as a result they are generally more sensitive to loss 🧠

We note that very-low-bit-rate codecs have proved useful, although with some performance degradation, in very low bandwidth, high noise environments (e.g., 2.4 kbps HF radio) 📻 For example, 2.4 kbps codecs "produce speech which although intelligible is far from natural sounding" [W98]. Figure 5 of [W98] shows how the speech quality of several forms of codecs varies with the bit rate of the codec 🫶

7. Conclusions and Recommendations ✨

okay bestie, let's wrap this up 💅 in the near term, VoIP is probably gonna run at least partly over broadband best-effort connections 🌸. The problem is that current real-time media encoding and transmission practice basically ignores congestion 💀. If VoIP blows up in the near to intermediate term, that could get messy: poor user quality, unfairness to other VoIP and TCP users, and maybe sporadic episodes of congestion collapse 😭

The good news is these problems can be mitigated for apps that use fixed-rate codecs 🎀. You make the best-effort VoIP app specify its minimum bit throughput rate, and that minimum bit rate can be used to estimate a packet drop rate at which the app would terminate 🦋

This document specifically recommends the following 👑:

  1. In IETF standards for protocols regarding best-effort flows with a minimum sending rate, a packet drop rate MUST be specified, such that the best-effort flow terminates, or suspends sending temporarily, when the steady-state packet drop rate significantly exceeds the specified drop rate.
  2. The specified drop rate for the minimum sending rate SHOULD be consistent with the use of Tables 1 and 2 as illustrated in this document.

We note that this is a recommendation to the IETF community, as a specific follow-up to RFC 2914 on Congestion Control Principles 🧚. And to be super clear, this is not a specific or complete protocol specification 🙈

Codecs that can vary their bit rate based on congestion estimates are giving even more effective quality while keeping the network efficient under high load 😤 So adaptive variable-bit-rate codecs are preferable for supporting VOIP sessions in shared-use Internet environments. Iconic behavior, honestly 👑

Real-time traffic like VoIP could get significant benefits from ECN 🌈, where routers can tell end-nodes about congestion by marking packets instead of dropping them. BUT ECN is only standardized for use with transport protocols that react appropriately to marked packets as congestion indications. So VoIP traffic that follows the recommendations in this document could satisfy the congestion-control requirements for using ECN, while VoIP traffic with no mechanism for terminating or suspending when the packet dropping and marking rate was too high would not 💀 Again, this document is not a complete protocol specification. Additional mechanisms would be required before it was safe for applications running over UDP to use ECN 🫶 For example, before using ECN, the sending application would have to make sure that the receiving application can actually receive ECN-related information from the lower-layer UDP stack, and can interpret that ECN information as a congestion indication. Not me making sure everything is checked 💅

8. Acknowledgements 🫶

Huge thank-you energy to Brian Adamson, Ran Atkinson, Fred Baker, Jon Crowcroft, Christophe Diot, Alan Duric, Jeremy George, Mark Handley, Orion Hodson, Geoff Huston, Eddie Kohler, Simon Leinen, David Meyer, Jean-Francois Mule, Colin Perkins, Jon Peterson, Mike Pierce, Cyrus Shaoul, and Henning Schulzrinne for feedback on this document 💖 (Of course, these people do not necessarily agree with all of the document, lol 🙈) Ran Atkinson and Geoff Huston contributed to the text of the document 👑

The analysis in Section 6.0 came out of a whiteboard session with Mark Handley 🦋 We also thank Alberto Medina for the FreeBSD experiments showing TCP's sending rate as a function of the packet drop rate 🌸

9. References 📚

9.1. Normative References

[RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2988]     Paxson, V. and M. Allman, "Computing TCP's
              Retransmission Timer", RFC 2988, November 2000.

[RFC3267]     Sjoberg, J., Westerlund, M., Lakaniemi, A. and Q. Xie,
              "Real-Time Transport Protocol (RTP) Payload Format and
              File Storage Format for the Adaptive Multi-Rate (AMR)
              and Adaptive Multi-Rate Wideband (AMR-WB) Audio
              Codecs", RFC 3267, June 2002.

9.2. Informative References 📚✨

okay bestie, these are the "extra reading" sources. nothing here is required to implement the spec, but they're the receipts 🧾💅

  • [A02] Ran Atkinson, An ISP Reality Check, Presentation to ieprep, 55th IETF Meeting, November 2002. URL http://www.ietf.cnri.reston.va.us/proceedings/02nov/219.htm#slides.
  • [A03] Brian Adamson, private communication, June 2003.
  • [BBFS01] Deepak Bansal, Hari Balakrishnan, Sally Floyd, and Scott Shenker, Dynamic Behavior of Slowly-Responsive Congestion Control Algorithms, SIGCOMM 2001.
  • [COPS] Durham, D., Ed., Boyle, J., Cohen, R., Herzog, S., Rajan, R. and A. Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000.
  • [DCCP03] Eddie Kohler, Mark Handley, Sally Floyd, and Jitendra Padhye, Datagram Congestion Control Protocol (DCCP), internet-draft Work in Progress, March 2003. URL http://www.icir.org/kohler/dcp/.
  • [DIFFSERV] Differentiated Services (diffserv), Concluded Working Group, URL http://www.ietf.cnri.reston.va.us/html.charters/OLD/diffserv-charter.html.
  • [E2E] The end2end-interest mailing list, URL http://www.postel.org/mailman/listinfo/end2end-interest.
  • [FHPW00] S. Floyd, M. Handley, J. Padhye, J. Widmer, "Equation-Based Congestion Control for Unicast Applications", ACM SIGCOMM 2000.
  • [FM03] S. Floyd and R. Mahajan, Router Primitives for Protection Against High-Bandwidth Flows and Aggregates, internet draft (not yet submitted).
  • [FWD] Free World Dialup, URL www.pulver.com/fwd/.
  • [IEPREP02] Internet Emergency Preparedness (ieprep), Minutes, 55th IETF Meeting, November 2002. URL http://www.ietf.cnri.reston.va.us/proceedings/02nov/219.htm#cmr.
  • [ILBRC] S.V. Andersen, et. al., Internet Low Bit Rate Codec, Work in Progress, March 2003.
  • [G.114] Recommendation G.114 - One-way Transmission Time, ITU, May 2003. URL http://www.itu.int/itudoc/itu-t/aap/sg12aap/recaap/g.114/.
  • [IVOX] The Interactive VOice eXchange, URL http://manimac.itd.nrl.navy.mil/IVOX/.
  • [Jacobson88] V. Jacobson, Congestion Avoidance and Control, ACM SIGCOMM '88, August 1988.
  • [AUT] The maximum feasible drop rate for VoIP traffic depends on the codec. These numbers are a range for a variety of codecs; voice quality begins to deteriorate for many codecs around a 10% drop rate. Note from authors.
  • [JS00] Wenyu Jiang and Henning Schulzrinne, Modeling of Packet Loss and Delay and Their Effect on Real-Time Multimedia Service Quality, NOSSDAV, 2000. URL http://citeseer.nj.nec.com/jiang00modeling.html.
  • [JS02] Wenyu Jiang and Henning Schulzrinne, Comparison and Optimization of Packet Loss Repair Methods on VoIP Perceived Quality under Bursty Loss, NOSSDAV, 2002. URL http://www1.cs.columbia.edu/~wenyu/.
  • [JS03] Wenyu Jiang, Kazummi Koguchi, and Henning Schulzrinne, QoS Evaluation of VoIP End-points, ICC 2003. URL http://www1.cs.columbia.edu/~wenyu/.
  • [KFK79] G.S. Kang, L.J. Fransen, and E.L. Kline, "Multirate Processor (MRP) for Digital Voice Communications", NRL Report 8295, Naval Research Laboratory, Washington DC, March 1979.
  • [KF82] G.S. Kang and L.J. Fransen, "Second Report of the Multirate Processor (MRP) for Digital Voice Communications", NRL Report 8614, Naval Research Laboratory, Washington DC, September 1982.
  • [Measurement] Web page on "Measurement Studies of End-to-End Congestion Control in the Internet", URL http://www.icir.org/floyd/ccmeasure.html. The section on "Network Measurements at Specific Sites" includes measurement data about the distribution of packet sizes on various links in the Internet.
  • [MTK03] A. P. Markopoulou, F. A. Tobagi, and M. J. Karam, "Assessing the Quality of Voice Communications Over Internet Backbones", IEEE/ACM Transactions on Networking, V. 11 N. 5, October 2003.
  • [NSIS] Next Steps in Signaling (nsis), IETF Working Group, URL http://www.ietf.cnri.reston.va.us/html.charters/nsis-charter.html.
  • [PCC] Joerg Widmer, Martin Mauve, and Jan Peter Damm. Probabilistic Congestion Control for Non-Adaptable Flows. Technical Report 3/2001, Department of Mathematics and Computer Science, University of Mannheim. URL http://www.informatik.uni-mannheim.de/informatik/pi4/projects/CongCtrl/pcc/index.html.
  • [PFTK98] J. Padhye, V. Firoiu, D. Towsley, J. Kurose, Modeling TCP Throughput: A Simple Model and its Empirical Validation, Tech Report TF 98-008, U. Mass, February 1998.
  • [RFC896] Nagle, J., "Congestion Control in IP/TCP", RFC 896, January 1984.
  • [RFC1890] Schulzrinne, H., "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 1890, January 1996.
  • [RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
  • [RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
  • [RFC2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "Assured Forwarding PHB Group, RFC 2597, June 1999.
  • [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
  • [RFC2990] Huston, G., "Next Steps for the IP QoS Architecture", RFC 2990, November 2000.
  • [RFC3042] Allman, M., Balakrishnan, H. and S., Floyd, "Enhancing TCP's Loss Recovery Using Limited Transmit", RFC 3042, January 2001.
  • [RFC3168] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
  • [RFC3246] Davie, B., Charny, A., Bennet, J.C.R., Benson, K., Le Boudec, J.Y., Courtney, W., Davari, S., Firoiu, V. and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.
  • [RFC3448] Handley, M., Floyd, S., Pahdye, J. and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 3448, January 2003.
  • [RSVP] Resource Reservation Setup Protocol (rsvp), Concluded Working Group, URL http://www.ietf.cnri.reston.va.us/html.charters/OLD/rsvp-charter.html.
  • [RTTWeb] Web Page on Round-Trip Times in the Internet, URL http://www.icir.org/floyd/rtt-questions.html
  • [S03] H. Schulzrinne, private communication, 2003.
  • [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 3551, July 2003.
  • [Vonage] Vonage, URL www.vonage.com.
  • [W98] J. Woodward, Speech Coding, Communications Research Group, University of Southampton, 1998. URL http://www-mobile.ecs.soton.ac.uk/speech_codecs/,

10. Appendix - Sending Rates with Packet Drops ✨

okay so, the standard way to estimate TCP's average sending rate S (in packets per round-trip) as a function of the packet drop rate is the TCP response function from [PFTK98] 🧮

S = 1/(sqrt(2p/3) + K min(1,3 sqrt(3p/8)) p (1 + 32 p^2))   (1)

this is for acks sent for every data packet, with the RTO set to K*RTT 💅

The results from Equation (1) are in the second column of Tables 1 and 2 below. BUT ngl, Equation (1) overestimates TCP's sending rate when there are heavy packet drop rates (like 30% or more) 😭 The analysis behind it assumes that once a single packet gets through, TCP's retransmit timer is no longer backed-off. That might be fine in an environment with ECN, or for a TCP connection using fine-grained timestamps. But it's not necessarily the case for a non-ECN-capable TCP connection without timestamps. As [RFC2988] specifies, if TCP's retransmit timer is backed-off, that back-off should only be removed when TCP successfully transmits a new packet (as opposed to a retransmitted packet), in the absence of timestamps 🎀

When the packet drop rate is 50% or higher, for example, many of the successful transmissions can be retransmitted packets, and the retransmit timer can stay backed-off for significant periods of time (no timestamps, remember) 🥺 In that case, TCP's throughput is basically decided by the maximum backoff of the retransmit timer. In the NS simulator, for example, the maximum backoff of the retransmit timer is 64 times the un-backed-off value. [RFC2988] says "a maximum value MAY be placed on RTO provided it is at least 60 seconds." [Although TCP implementations vary, many TCP implementations have a maximum of 45 seconds for the backed-off RTO after dropped SYN packets.] 🫠

Another limitation of Equation (1) is that it models Reno TCP. So it underestimates the sending rate of a modern TCP connection that used SACK and Limited Transmit 📉

The table below shows estimates of the average sending rate S (in packets per RTT) for TCP connections with the RTO set to 2 RTT for Equation (1) 🌸

These estimates are compared with simulations in the third, fourth, and fifth columns. Those are with ECN, packet drops for TCP with fine-grained timestamps, and packet drops for TCP without timestamps, in that order. (The simulation scripts are at http://www.icir.org/floyd/VoIP/sims.) Each simulation computes the average sending rate over the second half of a 10,000-second simulation. For each packet drop rate, the average is taken over 50 simulations. For the simulations with very high packet drop rates, it sometimes happens that the SYN packet is repeatedly dropped, and the TCP sender never successfully transmits a packet. In that case the TCP sender also never gets a measurement of the round-trip time 💀

The sixth column of Table 1 shows the average sending rate S (in packets per RTT) for an experiment using a 4.8-RELEASE FreeBSD machine 🍓 For the low packet drop rates of 0.1 and 0.2, the sending rate in the simulations is higher than in the experiments. This is probably because the TCP implementation in the simulations uses Limited Transmit [RFC3042]. With Limited Transmit, the TCP sender can sometimes avoid a retransmit timeout when a packet is dropped and the congestion window is small 🧚 With high packet drop rates of 0.65 and 0.7, the sending rate in the simulations is somewhat lower than in the experiments. For these high drop rates, the TCP connections in the experiments would often abort prematurely, after a sufficient number of successive packet drops 🫠

We note that if the ECN marking rate exceeds a locally-configured threshold, then a router is advised to switch from marking to dropping. As a result, we do not expect to see high steady-state marking rates in the Internet, even if ECN is in fact deployed. 🦋
 Drop
Rate p  Eq(1)  Sims:ECN  Sims:TimeStamp  Sims:Drops  Experiments
------  -----  --------  --------------  ----------  -----------
  0.1   2.42    2.92      2.38            2.32       0.72
  0.2    .89    1.82      1.26            0.82       0.29
  0.25   .55    1.52       .94             .44       0.22
  0.35   .23    .99        .51             .11       0.10
  0.4    .16    .75        .36             .054      0.068
  0.45   .11    .55        .24             .029      0.050
  0.5    .10    .37        .16             .018      0.036
  0.55   .060   .25        .10             .011      0.024
  0.6    .045   .15        .057            .0068     0.006
  0.65   .051   .          .033            .0034     0.008
  0.7    .041   .06        .018            .0022     0.007
  0.75   .034   .04        .0099           .0011
0p.8    .028   .027       .0052           .00072
  0.85   .023   .015       .0021           .00034
  0.9    .020   .011       .0011           .00010
  0.95   .017   .0079      .00021          .000037

Table 1: Sending Rate S as a Function of the Packet Drop Rate p, for RTO set to 2 RTT, and S in packets per RTT. 📊

The table below shows the average sending rate S, for TCP connections with the RTO set to 10 RTT. 🌈

 Drop
Rate p  Eq(1)  Sims:ECN  Sims:TimeStamp  Sims:Drops
------  -----  --------  --------------  ----------
 0.1    0.97    2.92       1.67          1.64
 0.2    0.23    1.82        .56           .31
 0.25   0.13     .88        .36           .13
 0.3    0.08     .61        .23           .059
 0.35   0.056    .41        .15           .029
 0.4    0.040    .28        .094          .014
 0.45   0.029    .18        .061          .0080
 0.5    0.021    .11        .038          .0053
 0.55   0.016    .077       .022          .0030
 0.6    0.013    .045       .013          .0018
 0.65   0.010    .          .0082         .0013
 0.7    0.0085   .018       .0042
 0.75   0.0069   .012       .0025         .00071
 0.8    0.0057   .0082      .0014         .00030
 0.85   0.0046   .0047      .00057        .00014
 0.9    0.0041   .0034      .00026        .000025
 0.95   0.0035   .0024      .000074       .000013

Table 2: Sending Rate as a Function of the Packet Drop Rate, for RTO set to 10 RTT, and S in packets per RTT. 🎀

11. Security Considerations 🔐

This document does not itself create any new security issues for the Internet community.

12. IANA Considerations 📋

There are no IANA considerations regarding this document.

13. Authors' Addresses 💌

The author is the Internet Architecture Board, reachable at iab@iab.org.

The Internet Architecture Board Members at the time this document was published were:

Bernard Aboba
Harald Alvestrand (IETF chair)
Rob Austein
Leslie Daigle (IAB chair)
Patrik Faltstrom
Sally Floyd
Jun-ichiro Itojun Hagino
Mark Handley
Geoff Huston (IAB Executive Director)
Charlie Kaufman
James Kempf
Eric Rescorla
Mike St. Johns

This document was created in January 2004. 🗓️

Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or the extent to which any license under such rights might or might not be available. Nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification, can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 💖

Acknowledgement

Funding for the RFC Editor function is currently provided by the Internet Society. 🫶

📦 where this page comes from