diff options
Diffstat (limited to 'doc/rfc/rfc3714.txt')
| -rw-r--r-- | doc/rfc/rfc3714.txt | 1795 |
1 files changed, 1795 insertions, 0 deletions
diff --git a/doc/rfc/rfc3714.txt b/doc/rfc/rfc3714.txt new file mode 100644 index 0000000..32f11c2 --- /dev/null +++ b/doc/rfc/rfc3714.txt @@ -0,0 +1,1795 @@ + + + + + + +Network Working Group S. Floyd, Ed. +Request for Comments: 3714 J. Kempf, Ed. +Category: Informational March 2004 + + + IAB Concerns Regarding Congestion Control for + Voice Traffic in the Internet + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2004). All Rights Reserved. + +Abstract + + This document discusses IAB concerns about effective end-to-end + congestion control for best-effort voice traffic in the Internet. + These concerns have to do with fairness, user quality, and with the + dangers of congestion collapse. The concerns are particularly + relevant in light of the absence of a widespread Quality of Service + (QoS) deployment in the Internet, and the likelihood that this + situation will not change much in the near term. This document is + not making any recommendations about deployment paths for Voice over + Internet Protocol (VoIP) in terms of QoS support, and is not claiming + that best-effort service can be relied upon to give acceptable + performance for VoIP. We are merely observing that voice traffic is + occasionally deployed as best-effort traffic over some links in the + Internet, that we expect this occasional deployment to continue, and + that we have concerns about the lack of effective end-to-end + congestion control for this best-effort voice traffic. + +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 + + + +Floyd & Kempf Informational [Page 1] + +RFC 3714 IAB Concerns Regarding Congestion Control March 2004 + + + 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 + + While many in the telephony community assume that commercial VoIP + service in the Internet awaits effective end-to-end QoS, in reality + voice service over best-effort broadband Internet connections is an + available service now with growing demand. While some ISPs deploy + QoS on their backbones, and some corporate intranets offer end-to-end + QoS internally, end-to-end QoS is not generally available to + customers in the current Internet. Given the current commercial + interest in VoIP on best-effort media connections, it seems prudent + to examine the potential effect of real time flows on congestion. In + this document, we perform such an analysis. Note, however, that this + document is not making any recommendations about deployment paths for + VoIP in terms of QoS support, and is not claiming that best-effort + service can be relied upon to give acceptable performance for VoIP. + This document is also not discussing signalling connections for VoIP. + However, voice traffic is in fact occasionally deployed as best + effort traffic over some links in the Internet today, and we expect + this occasional deployment to continue. This document expresses our + concern over the lack of effective end-to-end congestion control for + this best-effort voice traffic. + + Assuming that VoIP over best-effort Internet connections continues to + gain popularity among consumers with broadband connections, the + deployment of end-to-end QoS mechanisms in public ISPs may be slow. + The IETF has developed standards for QoS mechanisms in the Internet + [DIFFSERV, RSVP] and continues to be active in this area [NSIS,COPS]. + However, the deployment of technologies requiring change to the + Internet infrastructure is subject to a wide range of commercial as + + + +Floyd & Kempf Informational [Page 2] + +RFC 3714 IAB Concerns Regarding Congestion Control March 2004 + + + well as technical considerations, and technologies that can be + deployed without changes to the infrastructure enjoy considerable + advantages in the speed of deployment. RFC 2990 outlines some of the + technical challenges to the deployment of QoS architectures in the + Internet [RFC2990]. Often, interim measures that provide support for + fast-growing applications are adopted, and are successful enough at + meeting the need that the pressure for a ubiquitous deployment of the + more disruptive technologies is reduced. There are many examples of + the slow deployment of infrastructure that are similar to the slow + deployment of QoS mechanisms, including IPv6, IP multicast, or of a + global PKI for IKE and IPsec support. + + Interim QoS measures that can be deployed most easily include + single-hop or edge-only QoS mechanisms for VoIP traffic on individual + congested links, such as edge-only QoS mechanisms for cable access + networks. Such local forms of QoS could be quite successful in + protecting some fraction of best-effort VoIP traffic from congestion. + However, these local forms of QoS are not directly visible to the + end-to-end VoIP connection. A best-effort VoIP connection could + experience high end-to-end packet drop rates, and be competing with + other best-effort traffic, even if some of the links along the path + might have single-hop QoS mechanisms. + + The deployment of IP telephony is likely to include best-effort + broadband connections to public-access networks, in addition to other + deployment scenarios of dedicated IP networks, or as an alternative + to band splitting on the last mile of ADSL deployments or QoS + mechanisms on cable access networks. There already exists a + rapidly-expanding deployment of VoIP services intended to operate + over residential broadband access links (e.g., [FWD, Vonage]). At + the moment, many public-access IP networks are uncongested in the + core, with low or moderate levels of link utilization, but this is + not necessarily the case on last hop links. If an IP telephony call + runs completely over the Internet, the connection could easily + traverse congested links on both ends. Because of economic factors, + the growth rate of Internet telephony is likely to be greatest in + developing countries, where core links are more likely to be + congested, making congestion control an especially important topic + for developing countries. + + Given the possible deployment of IP telephony over congested best- + effort networks, some concerns arise about the possibilities of + congestion collapse due to a rapid growth in real-time voice traffic + that does not practice end-to-end congestion control. This document + raises some concerns about fairness, user quality, and the danger of + congestion collapse that would arise from a rapid growth in best- + effort telephony traffic on best-effort networks. We consider best- + effort telephony connections that have a minimum sending rate and + + + +Floyd & Kempf Informational [Page 3] + +RFC 3714 IAB Concerns Regarding Congestion Control March 2004 + + + that compete directly with other best-effort traffic on a path with + at least one congested link, and address the specific question of + whether such traffic should be required to terminate, or to suspend + sending temporarily, in the face of a persistent, high packet drop + rate, when reducing the sending rate is not a viable alternative. + + The concerns in this document about fairness and the danger of + congestion collapse apply not only to telephony traffic, but also to + video traffic and other best-effort real-time traffic with a minimum + sending rate. RFC 2914 already makes the point that best-effort + traffic requires end-to-end congestion control [RFC2914]. Because + audio traffic sends at such a low rate, relative to video and other + real-time traffic, it is sometimes claimed that audio traffic doesn't + require end-to-end congestion control. Thus, while the concerns in + this document are general, the document focuses on the particular + issue of best-effort audio traffic. + + Feedback can be sent to the IAB mailing list at iab@ietf.org, or to + the editors at floyd@icir.org and kempf@docomolabs-usa.com. Feedback + can also be sent to the end2end-interest mailing list [E2E]. + +2. An Example of the Potential for Trouble + + At the November, 2002, IEPREP Working Group meeting in Atlanta, a + brief demonstration was made of VoIP over a shared link between a + hotel room in Atlanta, Georgia, USA, and Nairobi, Kenya. The link + ran over the typical uncongested Internet backbone and access links + to peering points between either endpoint and the Internet backbone. + The voice quality on the call was very good, especially in comparison + to the typical quality obtained by a circuit-switched call with + Nairobi. A presentation that accompanied the demonstration described + the access links (e.g., DSL, T1, T3, dialup, and cable modem links) + as the primary source of network congestion, and described VoIP + traffic as being a very small percentage of the packets in commercial + ISP traffic [A02]. The presentation further stated that VoIP + received good quality in the presence of packet drop rates of 5-40% + [AUT]. 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 required by the + codec. The primary congestion point along the path of the + demonstration was a 128 kbps access link between an ISP in Kenya and + several of its subscribers in Nairobi. So the single VoIP call + consumed more than half of the access link capacity, capacity that is + shared across several different users. + + Note that this network configuration is not a particularly good one + for VoIP. In particular, if there are data services running TCP on + the link with a typical packet size of 1500 bytes, then some voice + + + +Floyd & Kempf Informational [Page 4] + +RFC 3714 IAB Concerns Regarding Congestion Control March 2004 + + + packets could be delayed an additional 90 ms, which might cause an + increase in the end to end delay above the ITU-recommended time of + 150 ms [G.114] for speech traffic. This would result in a delay + noticeable to users, with an increased variation in delay, and + therefore in call quality, as the bursty TCP traffic comes and goes. + For a call that already had high delay, such as the Nairobi call from + the previous paragraph, the increased jitter due to competing TCP + traffic also increases the requirements 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 persists in sending packets at 64 Kbps, + consuming half of a 128 Kbps access link, in the face of a drop rate + of 40%, with the resulting user-perceptible degradation in voice + quality, is not behaving in a way that serves the interests of either + the VoIP users or the other concurrent users of the network. + + 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 this is exactly when it is + important to avoid congestion collapse. + + + +Floyd & Kempf Informational [Page 5] + +RFC 3714 IAB Concerns Regarding Congestion Control March 2004 + + + 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 in 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 + + + + + +Floyd & Kempf Informational [Page 6] + +RFC 3714 IAB Concerns Regarding Congestion Control March 2004 + + + potential problem in VoIP networks when both ends of the VoIP call + are on an 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 + 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. + + + + + +Floyd & Kempf Informational [Page 7] + +RFC 3714 IAB Concerns Regarding Congestion Control March 2004 + + + 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 + + A third problem with persistent, high packet drop rates is fairness. + In this document we consider fairness with regard to best-effort VoIP + traffic competing with other best-effort traffic in the Internet. + That is, we are explicitly not addressing the issues raised by + emergency services, or by QoS-enabled traffic that is known to be + treated separately from best-effort traffic at a congested link. + + While fairness is a bit difficult to quantify, we can illustrate the + effect by adding TCP traffic to the congested link discussed in the + previous section. In this case, the non-congestion-controlled + traffic and congestion-controlled TCP traffic [RFC2914] share the + link, with the congestion-controlled traffic's sending rate + determined by the packet drop rate experienced by those flows. As in + the previous section, the 128 Kbps link has N VoIP connections each + sending 64 Kbps, resulting in packet drop rate of at least (N-2)/N on + the congested link. Competing TCP flows will experience the same + packet drop rates. However, a TCP flow experiencing the same packet + drop rates will be sending considerably less than 64 Kbps. From the + point of view of who gets what amount of bandwidth, the VoIP traffic + is crowding out the TCP traffic. + + Of course, this is only one way to look at fairness. The relative + fairness between VoIP and TCP traffic can be viewed several different + ways, depending on the assumptions that one makes on packet sizes and + round-trip times. In the presence of a fixed packet drop rate, for + example, a TCP flow with larger packets sends more (in Bps, bytes per + second) than a TCP flow with smaller packets, and a TCP flow with a + shorter round-trip time sends more (in Bps) than a TCP flow with a + larger round-trip time. In environments with high packet drop rates, + TCP's sending rate depends on the algorithm for setting the + retransmit timer (RTO) as well, with a TCP implementation having a + more aggressive RTO setting sending more than a TCP implementation + having a less aggressive RTO setting. + + Unfortunately, there is no obvious canonical round-trip time for + judging relative fairness of flows in the network. Agreement in the + literature is that the majority of packets on most links in the + network experience round-trip times between 10 and 500 ms [RTTWeb]. + + + + + +Floyd & Kempf Informational [Page 8] + +RFC 3714 IAB Concerns Regarding Congestion Control March 2004 + + + (This does not include satellite links.) As a result, if there was a + canonical round-trip for judging relative fairness, it would have to + be within that range. In the absence of a single representative + round-trip time, the assumption of this paper is that it is + reasonable to consider fairness between a VoIP connection and a TCP + connection with the same round-trip time. + + Similarly, there is no canonical packet size for judging relative + fairness between TCP connections. However, because the most common + packet size for TCP data packets is 1460 bytes [Measurement], we + assume that it is reasonable to consider fairness between a VoIP + connection, and a TCP connection sending 1460-byte data packets. + Note that 1460 bytes is considerably larger than is typically used + for VoIP packets. + + In the same way, while RFC 2988 specifies TCP's algorithm for setting + TCP's RTO, there is no canonical value for the minimum RTO, and the + minimum RTO heavily affects TCP's sending rate in times of high + congestion [RFC2988]. RFC 2988 specifies that TCP's RTO must be set + to SRTT + 4*RTTVAR, for SRTT the smoothed round-trip time, and for + RTTVAR the mean deviation of recent round-trip time measurements. + RFC 2988 further states that the RTO "SHOULD" have a minimum value of + 1 second. However, it is not uncommon in practice for TCP + implementations to have a minimum RTO as low as 100 ms. For the + purposes of this document, in considering relative fairness, we will + assume a minimum RTO of 100 ms. + + As an additional complication, TCP connections that use fine-grained + timestamps can have considerably higher sending rates than TCP + connections that do not use timestamps, in environments with high + packet drop rates. For TCP connections with fine-grained timestamps, + a valid round-trip time measurement is obtained when a retransmitted + packet is successfully received and acknowledged by the receiver; in + this case a backed-off retransmit timer can be un-backed-off as well. + For TCP connections without timestamps, a valid round-trip time + measurement is only obtained when the transmission of a new packet is + received and acknowledged by the receiver. This limits the + opportunities for the un-backing-off of a backed-off retransmit + timer. In this document, in considering relative fairness, we use a + TCP connection without timestamps, since this is the dominant use of + TCP in the Internet. + + A separate claim that has sometimes been raised in terms of fairness + is that best-effort VoIP traffic is inherently more important that + other best-effort traffic (e.g., web surfing, peer-to-peer traffic, + or multi-player games), and therefore merits a larger share of the + bandwidth in times of high congestion. Our assumption in this + document is that TCP traffic includes pressing email messages, + + + +Floyd & Kempf Informational [Page 9] + +RFC 3714 IAB Concerns Regarding Congestion Control March 2004 + + + business documents, and emergency information downloaded from web + pages, as well as the more recreational uses cited above. Thus, we + do not agree that best-effort VoIP traffic should be exempt from + end-to-end congestion control due to any claims of inherently more + valuable content. (One could equally logically argue that because + email and instant messaging are more efficient forms of communication + than VoIP in terms of bandwidth usage, as a result email and instant + messaging are more valuable uses of scarce bandwidth in times of high + congestion.) In fact, the network is incapable of making a judgment + about the relative user value of traffic. The default assumption is + that all best-effort traffic has equal value to the network provider + and to the user. + + We note that this discussion of relative fairness does not in any way + challenge the right of ISPs to allocate bandwidth on congested links + to classes of traffic in any way that they choose. (For example, + administrators rate-limit the bandwidth used by peer-to-peer traffic + on some links in the network, to ensure that bandwidth is also + available for other classes of traffic.) This discussion merely + argues that there is no reason for entire classes of best-effort + traffic to be exempt from end-to-end congestion control. + +4. Current efforts in the IETF + + There are four efforts currently underway in IETF to address issues + of 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, does + not discuss congestion control [RFC1890]. The revised document on + "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." + + + + +Floyd & Kempf Informational [Page 10] + +RFC 3714 IAB Concerns Regarding Congestion Control March 2004 + + + "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." + + Note that [RFC3551] says that receivers "SHOULD" monitor packet loss. + [RFC3551] does not explicitly say that the RTP senders and receivers + "MUST" detect and respond to a persistent high loss rate. Since + congestion collapse can be considered a "danger to the Internet" the + use of "MUST" would be appropriate for RTP traffic in the best-effort + Internet, where the VoIP traffic shares a link with other traffic, + since "danger to the Internet" is one of two criteria given in RFC + 2119 for the use of "MUST" [RFC2119]. Different requirements may + hold for a private best-effort IP network provisioned solely for + VoIP, where the VoIP traffic does not 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 has 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 is no draft available for TFRC-PS yet, unfortunately, but + several researchers are still working on these issues. + + + + +Floyd & Kempf Informational [Page 11] + +RFC 3714 IAB Concerns Regarding Congestion Control March 2004 + + +4.3. DCCP + + The Datagram Congestion Control Protocol (DCCP) is a transport + protocol being standardized in the IETF for unreliable flows, with + the application being able to specify either TCP-like or TFRC + congestion control [DCCP03]. + + DCCP currently has two Congestion Control IDentifiers or CCIDs; these + 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 would expect DCCP to create a new CCID, + CCID 4, for use with TFRC-PS congestion control. + +4.4. Adaptive Rate Audio Codecs + + A critical component in the design of any real-time application is + the selection of appropriate codecs, specifically codecs that operate + at a low sending rate, or that will reduce the sending rate as + throughput decreases and/or packet loss increases. Absent this, and + in the absence of the response to congestion recommended in this + document, the real-time application is likely to significantly + increase the risk of Internet congestion collapse, thereby adversely + impacting the health of the deployed Internet. If the codec is + capable of reducing its bit rate in response to congestion, this + improves the scaling of the number of VoIP or TCP sessions capable of + sharing a congested link while still providing acceptable performance + to users. Many current audio codecs are capable of sending at a low + bit rate, in some cases adapting their sending rate in response to + congestion indications from the network. + + RFC 3267 describes RTP payload formats for use with the Adaptive + Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) audio + codecs [RFC 3267]. The AMR codec supports eight speech encoding + modes having bit rates between 4.75 and 12.2 kbps, with the speech + encoding performed on 20 ms speech frames, and is able to reduce the + transmission rate during silence periods. The payload format + specified in RFC 3267 includes forward error correction (FEC) and + frame interleaving to increase robustness against packet loss + somewhat. The AMR codec was chosen 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 the RTP payload format specified in RFC + 3267 use congestion control, though no specific mechanism is + recommended. RFC 3267 gives "Equation-Based Congestion Control for + Unicast Applications" as an example of a congestion control mechanism + suitable for real-time flows [FHPW00]. + + + + + +Floyd & Kempf Informational [Page 12] + +RFC 3714 IAB Concerns Regarding Congestion Control March 2004 + + + The "Internet Low Bit Rate Codec", iLBC, is an IETF effort to develop + an IPR-free codec for robust voice communication over IP [ILBRC]. + The codec is designed for graceful speech quality degradation in the + case of lost packets, and 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], with plans to add additional + variable rate codecs. For example, LPC2400 (a.k.a. LQ2400) is a 2400 + bps LPC based codec with an enhancement to permit "silence + detection". The 2400 bps codec is reported to have a "slight robotic + quality" [A03] (even without the additional complications of packet + loss). 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 can + optionally send additional "residual" bits for enhanced quality at a + higher bit rate. + + Off-the-shelf ITU-T vocoders such as G.711 were generally designed + explicitly for circuit-switched networks and are not as well-adapted + for Internet use, even with the addition of FEC on top. + +4.5. Differentiated Services and Related Topics + + The Differentiated Services Working Group [DIFFSERV], which concluded + in 2003, completed standards for the Differentiated Services Field + (DS Field) in the IPv4 and IPv6 Headers [RFC2474], including several + per-hop forwarding behaviors [RFC2597, RFC3246]. The Next Steps in + Signaling Working Group [NSIS] is developing an optimized signalling + protocol for QoS, based in part on earlier work of the Resource + Reservation Setup Protocol Working Group [RSVP]. We do not discuss + these and related efforts further in this document, since this + document concerns only that VoIP traffic that might be carried as + best-effort traffic over some congested link in the Internet. + +5. Assessing Minimum Acceptable Sending Rates + + Current IETF work in the DCCP and AVT working groups does not + consider the problem of applications that have a minimum sending rate + and are not able to go below that sending rate. This clearly must be + addressed in the TFRC-PS draft. As suggested in the RTP document, if + the loss rate is persistently unacceptably high relative to the + current sending rate, and the best-effort application is unable to + lower its sending rate, then the only acceptable answer is for that + flow to discontinue sending on that link. For a multicast session, + this could be accomplished by the receiver withdrawing from the + multicast group. For a unicast session, this could be accomplished + by the unicast connection terminating, at least for a period of time. + + + + +Floyd & Kempf Informational [Page 13] + +RFC 3714 IAB Concerns Regarding Congestion Control March 2004 + + + We can formulate a problem statement for the minimum sending rate in + the following way. Consider a best-effort, adaptive audio + application that is able to adapt down to a minimum sending rate of N + Bps (bytes per second) of application data, sending M packets per + second. Is this a sufficiently low sending rate that the best-effort + flow is never required to terminate due to congestion, or to reduce + its sending rate in packets per second still further? In other words, + is N Bps an acceptable minimum sending rate for the application, + which can be continued in the face of congestion without terminating + or suspending the application? + + We assume, generously for VoIP, that the limitation of the network is + in bandwidth in bytes per second (Bps), and not in CPU cycles or in + packets per second (pps). If the limitation in the network is in + bandwidth, this is a limitation in Bps, while if the limitation is in + router processing capacity in packets, this would be a limitation in + pps. We note that TCP sends fixed-size data packets, and reduces its + sending rate in pps when it adapts to network congestion, thus + reducing the load on the forward path both in Bps and in pps. In + contrast, for adaptive VoIP applications, the adaption is sometimes + to keep the same sending rate in pps, but to reduce the packet size, + reducing the sending rate in Bps. This fits the needs of audio as an + application, and is a good response on a network path where the + limitation is in Bps. Such behavior would be a less appropriate + response for a network path where the limitation is in pps. + + If the network limitation in fact is in Bps, then all that matters in + terms of congestion is a flow's sending rate on the wire in Bps. If + this assumption of a network limitation in Bps is false, then the + sending rate in pps could contribute to congestion even when the + sending rate in Bps is quite moderate. While the ideal would be to + have a transport protocol that is able to detect whether the + bottleneck links along the path are limited in Bps or in pps, and to + respond appropriately when the limitation is in pps, such an ideal is + hard to achieve. We would not want to delay the deployment of + congestion control for telephony traffic until such an ideal could be + accomplished. In addition, we note that the current TCP congestion + control mechanisms are themselves not very effective in an + environment where there is a limitation along the reverse path in + pps. While the TCP mechanisms do provide an incentive to use large + data packets, TCP does not include any effective congestion control + mechanisms for the stream of small acknowledgement packets on the + reverse path. Given the arguments above, it seems acceptable to us + to assume a network limitation in Bps rather than in pps in + considering the minimum sending rate of telephony traffic. + + + + + + +Floyd & Kempf Informational [Page 14] + +RFC 3714 IAB Concerns Regarding Congestion Control March 2004 + + + Assuming 40-byte packet headers (IP, RTP, and UDP or DCCP), the + application data sending rate of N Bps and M pps translates to a + sending rate on the wire of B = N+40M Bps. If the application uses + additional FEC (Forward Error Correction), the FEC bits must be added + in as well. In our example, we ignore bandwidth adjustments that are + needed to take into account the additional overhead for FEC or the + reduced sending rate for silence periods. We also are not taking + into account the possible role of header compression on congested + edge links, which can reduce significantly the number of bytes used + for headers on those links. + + Now, consider an equivalent-rate TCP connection with data packets of + P bytes and a round-trip time of R seconds. Taking into account + header size, such a TCP connection with a sending rate on the wire of + B Bps is sending B/(P+40) pps, or, equivalently, BR/(P+40) ppr + (packets per round-trip time). + + Restating the question in terms of the above expressions for VoIP and + TCP: if the best-effort VoIP connection is experiencing a persistent + packet drop rate of D, and is at its minimum sending rate on the wire + of B Bps, when should the application or transport protocol terminate + or suspend the VoIP connection? + + One answer to this question is to find the sending rate in ppr for a + TCP connection sending at the same rate on the wire in Bps, and to + use the TCP response function to determine whether a conformant TCP + connection would be able to maintain a sending rate close to that + sending rate with the same persistent drop rate D. If the sending + rate of the VoIP connection is significantly higher than the sending + rate of a conformant TCP connection under the same conditions, and + the VoIP connection is unable to reduce its sending rate on the wire, + then the VoIP connection should terminate or suspend. + + As discussed above, there are two reasons for requiring the + application to terminate: + + 1) Avoiding congestion collapse, given the possibility of multiple + congested links, + + 2) Fairness for congestion-controlled TCP traffic sharing the + link. + + In addition, if an application requires a minimum service level from + the network in order to operate, and that service level is + consistently not achieved, then the application should terminate or + suspend sending. + + + + + +Floyd & Kempf Informational [Page 15] + +RFC 3714 IAB Concerns Regarding Congestion Control March 2004 + + + One counter-argument is that users will just hang up anyway with a + high packet drop rate so there is no point in enforcing a minimum + acceptable rate. Users might hang up, but they might also just keep + on talking, with the occasional noise getting though, for minutes or + longer waiting for a short period of clarity. Another counter- + argument is that nobody really benefits from VoIP connections being + terminated or suspended when persistent packet drop rates exceed the + allowable packet drop rate for the configured minimum sending rate. + This is untrue, since the termination of these VoIP connections could + allow competing TCP and VoIP traffic to make some progress. + + In the next section, we illustrate the approach outlined above for + VoIP flows with minimum sending rates of 4.75 and 64 kbps + respectively, and show that in practice such an approach would not + seem too burdensome for VoIP traffic. This approach implies that the + VoIP traffic would terminate or suspend when the packet drop rate + significantly exceeds 40% for a VoIP flow with a minimum sending rate + of 4.75 kbps. If VoIP is to deliver "carrier quality" or even near + "carrier quality" on best-effort links, conditioning deployment on + the ability to maintain maximum sending rates during periods of + persistent packet drops rates exceeding 40% does not suggest a + service model that will see widespread acceptance among consumers, no + matter what the price differential. Good packet throughput is vital + for the delivery of 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 have not + addressed the question of when a VoIP flow might be able to start + sending again, to see if the congestion on the end-to-end path has + changed. This issue has been addressed in a proposal for + Probabilistic Congestion Control [PCC]. + + We note that if the congestion indications are in the form of ECN- + marked packets (Explicit Congestion Notification), as opposed to + dropped packets, then the answers about when a flow with a minimum + sending rate would have to stop sending are somewhat different. ECN + allows routers to explicitly notify end-nodes of congestion by ECN- + marking instead of dropping packets [RFC3168]. If packets are ECN- + marked instead of dropped in the network, then there are no concerns + of congestion collapse or of user quality (for the ECN-capable + traffic, at any rate), and what remains are concerns of fairness with + competing flows. Second, in regimes with very high congestion, TCP + has a higher sending rate with ECN-marked than with dropped packets, + in part because of different dynamics in terms of un-backing-off a + backed-off retransmit timer. + + + + + + +Floyd & Kempf Informational [Page 16] + +RFC 3714 IAB Concerns Regarding Congestion Control March 2004 + + +5.1. Drop Rates at 4.75 kbps Minimum Sending Rate + + Consider an adaptive audio application with an RTT of R=0.1 seconds + that is able to adapt down to a minimum sending rate of 4.75 kbps + application data, sending M=20 packets per second. This sending rate + translates to N=593 Bps of application data, for 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 experienced by + a TCP connection with the RTO set to twice the RTT, and gives the + corresponding sending rate of the TCP connection in ppr. The second + column gives the sending rate estimated by the standard analytical + approach, and the third, fourth, and fifth columns give the average + sending rate from simulations with random packet drops or marks. The + sixth column gives the sending rates from experiments on a 4.8- + RELEASE FreeBSD machine. The analytical approaches require an RTO + expressed as a multiple of the RTT, and 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. + + For a sending rate of 0.09 ppr and an RTO set to 2 RTT, Table 1 shows + that the analytical approach gives a corresponding packet drop rate + of roughly 50%, while the simulations in the fifth column and the + experiments in the sixth column give a packet drop rate of between + 35% and 40% to maintain 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 approaches for determining TCP's + relationship between the sending rate and the packet drop rate, the + analytic approach and the use of simulations, we consider the + simulations to be 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. If we assumed instead that the equivalent-rate TCP + connection had a round-trip time of R=0.01 seconds, the equivalent- + rate TCP connection would be sending BR/(P+40) = 0.009 ppr. However, + we have 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 would use Table 2 from the appendix + to determine the average TCP sending rate for a particular packet + + + +Floyd & Kempf Informational [Page 17] + +RFC 3714 IAB Concerns Regarding Congestion Control March 2004 + + + 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.) + + Thus, 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 + + The effect of increasing the minimum acceptable sending rate to 64 + kbps is effectively to decrease the packet drop rate at which the + application should terminate or suspend sending. For this section, + consider a codec with a minimum sending rate of 64 kbps, or N=8000 + Bps, and a packet sending rate of M=50 pps. (This would be + equivalent to 160-byte data packets, with 20 ms. per packet.) The + sending rate on the wire is B = N+40M Bps, including headers, or + 10000 Bps. A TCP connection having 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%.] As a result, 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, which 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 + + This document does not attempt to specify a complete protocol. For + example, this document does not specify the definition of a + persistent packet drop rate. The assumption would be that a + + + +Floyd & Kempf Informational [Page 18] + +RFC 3714 IAB Concerns Regarding Congestion Control March 2004 + + + "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 would be 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 all terminating or + suspending at the same time in response to shared congestion. If + flows use some randomization in setting the time interval for + detecting persistent congestion, or use a time interval that is a + function of the connection lifetime, this could help to prevent all + VoIP flows from terminating at the same time. + + Another design issue for a complete protocol concerns whether a flow + terminates when the packet drop rate is too high, or only suspends + temporarily. For a flow that suspends temporarily, there is an issue + of how long it should wait before resuming transmission. At the very + least, the sender should wait long enough so 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, + such that 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 essentially receive all of the + link bandwidth, while the VoIP flows with higher minimum sending + rates are required 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 + + One simple heuristic for estimating congestion would be to 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. + + + + + +Floyd & Kempf Informational [Page 19] + +RFC 3714 IAB Concerns Regarding Congestion Control March 2004 + + +6. Constraints on VoIP Systems + + Ultimately, attempting to run VoIP on congested links, even with + adaptive rate codecs and minimum packet rates, is likely to run into + hard constraints due to the nature of real time traffic in heavily + congested scenarios. VoIP systems exhibit a limited ability to scale + their packet rate. If the number of packets decreases, the amount of + audio per packet is greater and error concealment at the receiver + becomes 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 this + is what most voice codecs provide. In addition, voice media streams + exhibit greater loss sensitivity at lower data rates. Lower-data + rate codecs maintain more end-to-end state and as a result 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 with + several forms of codecs varies with the bit rate of the codec. + +7. Conclusions and Recommendations + + In the near term, VoIP services are likely to be deployed, at least + in part, over broadband best-effort connections. Current real time + media encoding and transmission practice ignores congestion + considerations, resulting in the potential for trouble should VoIP + become a broadly deployed service in the near to intermediate term. + Poor user quality, unfairness to other VoIP and TCP users, and the + possibility of sporadic episodes of congestion collapse are some of + the potential problems in this scenario. + + These problems can be mitigated in applications that use fixed-rate + codecs by requiring the best-effort VoIP application to specify its + minimum bit throughput rate. This minimum bit rate can be used to + estimate a packet drop rate at which the application 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. + + + + + +Floyd & Kempf Informational [Page 20] + +RFC 3714 IAB Concerns Regarding Congestion Control March 2004 + + + (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. + + This is not a specific or complete protocol specification. + + Codecs that are able to vary their bit rate depending on estimates of + congestion can be even more effective in providing good quality + service while maintaining network efficiency under high load + conditions. Adaptive variable-bit-rate codecs are therefore + preferable as a means of supporting VOIP sessions on shared use + Internet environments. + + Real-time traffic such as VoIP could derive significant benefits from + the use of ECN, where routers may indicate congestion to end-nodes by + marking packets instead of dropping them. However, ECN is only + standardized to be used with transport protocols that react + appropriately to marked packets as indications of congestion. 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. However, we + repeat that this document is not a complete protocol specification. + In particular, 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 ensure that + the receiving application was capable of receiving ECN-related + information from the lower-layer UDP stack, and of interpreting this + ECN information as a congestion indication. + +8. Acknowledgements + + We thank 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.) Ran Atkinson and Geoff Huston contributed to the text of + the document. + + The analysis in Section 6.0 resulted from a session at the whiteboard + 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. + + + +Floyd & Kempf Informational [Page 21] + +RFC 3714 IAB Concerns Regarding Congestion Control March 2004 + + +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 + + [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". + + + + + +Floyd & Kempf Informational [Page 22] + +RFC 3714 IAB Concerns Regarding Congestion Control March 2004 + + + [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/". + + + + + +Floyd & Kempf Informational [Page 23] + +RFC 3714 IAB Concerns Regarding Congestion Control March 2004 + + + [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. + + + + + + +Floyd & Kempf Informational [Page 24] + +RFC 3714 IAB Concerns Regarding Congestion Control March 2004 + + + [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. + + + + +Floyd & Kempf Informational [Page 25] + +RFC 3714 IAB Concerns Regarding Congestion Control March 2004 + + + [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/", + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Floyd & Kempf Informational [Page 26] + +RFC 3714 IAB Concerns Regarding Congestion Control March 2004 + + +10. Appendix - Sending Rates with Packet Drops + + The standard way to estimate TCP's average sending rate S in packets + per round-trip as a function of the packet drop rate would be to use + the TCP response function estimated in [PFTK98]: + + S = 1/(sqrt(2p/3) + K min(1,3 sqrt(3p/8)) p (1 + 32 p^2)) (1) + + for acks sent for every data packet, and the RTO set to K*RTT. + + The results from Equation (1) are given in the second column in + Tables 1 and 2 below. However, Equation (1) overestimates TCP's + sending rate in the regime with heavy packet drop rates (e.g., of 30% + or more). The analysis behind Equation (1) assumes that once a + single packet is successfully transmitted, TCP's retransmit timer is + no longer backed-off. This might be appropriate for an environment + with ECN, or for a TCP connection using fine-grained timestamps, but + this is not necessarily the case for a non-ECN-capable TCP connection + without timestamps. As specified in [RFC2988], if TCP's retransmit + timer is backed-off, this 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 packet transmissions can be of retransmitted packets, and + the retransmit timer can remain backed-off for significant periods of + time, in the absence of timestamps. In this case, TCP's throughput + is determined largely by the maximum backoff of the retransmit timer. + For example, in the NS simulator the maximum backoff of the + retransmit timer is 64 times the un-backed-off value. RFC 2988 + specifies that "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, and + therefore 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, with ECN, packet drops for TCP with fine-grained + timestamps, and packet drops for TCP without timestamps respectively. + (The simulation scripts are available from + http://www.icir.org/floyd/VoIP/sims.) Each simulation computes the + + + +Floyd & Kempf Informational [Page 27] + +RFC 3714 IAB Concerns Regarding Congestion Control March 2004 + + + average sending rate over the second half of a 10,000-second + simulation, and for each packet drop rate, the average is given over + 50 simulations. For the simulations with very high packet drop + rates, it is sometimes the case that the SYN packet is repeatedly + dropped, and the TCP sender never successfully transmits a packet. + In this case, the TCP sender also never gets a measurement of the + round-trip time. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Floyd & Kempf Informational [Page 28] + +RFC 3714 IAB Concerns Regarding Congestion Control March 2004 + + + 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 the sending rate 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 the sending rate in the experiments. For these + high packet 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. + + + + + + + + + + +Floyd & Kempf Informational [Page 29] + +RFC 3714 IAB Concerns Regarding Congestion Control March 2004 + + + 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. + + + + + + + + + + + + + + + + +Floyd & Kempf Informational [Page 30] + +RFC 3714 IAB Concerns Regarding Congestion Control March 2004 + + +13. Authors' Addresses + + Internet Architecture Board + EMail: iab@iab.org + + 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Floyd & Kempf Informational [Page 31] + +RFC 3714 IAB Concerns Regarding Congestion Control March 2004 + + +14. Full Copyright Statement + + 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. + + + + + + + + + +Floyd & Kempf Informational [Page 32] + |