idnits 2.17.1 draft-iab-congestion-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 29 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 30 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([E2E]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 2004) is 7369 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 3267' is mentioned on line 601, but not defined ** Obsolete undefined reference: RFC 3267 (Obsoleted by RFC 4867) == Unused Reference: 'RFC3267' is defined on line 1030, but no explicit reference was found in the text == Unused Reference: 'BBFS01' is defined on line 1043, but no explicit reference was found in the text == Unused Reference: 'FM03' is defined on line 1066, but no explicit reference was found in the text == Unused Reference: 'IEPREP02' is defined on line 1072, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2988 (Obsoleted by RFC 6298) ** Obsolete normative reference: RFC 3267 (Obsoleted by RFC 4867) == Outdated reference: A later version (-13) exists of draft-ietf-dccp-spec-01 == Outdated reference: A later version (-05) exists of draft-ietf-avt-ilbc-codec-01 -- Obsolete informational reference (is this intentional?): RFC 896 (Obsoleted by RFC 7805) -- Obsolete informational reference (is this intentional?): RFC 1890 (Obsoleted by RFC 3551) -- Obsolete informational reference (is this intentional?): RFC 2581 (Obsoleted by RFC 5681) -- Obsolete informational reference (is this intentional?): RFC 3448 (Obsoleted by RFC 5348) Summary: 8 errors (**), 0 flaws (~~), 11 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Sally Floyd, Editor 3 INTERNET DRAFT James Kempf, Editor 4 draft-iab-congestion-02.txt January 2004 6 IAB Concerns Regarding Congestion Control for Voice Traffic in the Internet 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet- Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 This document discusses IAB concerns about effective end-to-end 32 congestion control for best-effort voice traffic in the Internet. 33 These concerns have to do with fairness, user quality, and with the 34 dangers of congestion collapse. The concerns are particularly 35 relevant in light of the absence of a widespread QoS deployment in 36 the Internet, and the likelihood that this situation will not change 37 much in the near term. This document is not making any 38 recommendations about deployment paths for VoIP in terms of QoS 39 support, and is not claiming that best-effort service can be relied 40 upon to give acceptable performance for VoIP. We are merely 41 observing that voice traffic is occasionally deployed as best-effort 42 traffic over some links in the Internet, that we expect this 43 occasional deployment to continue, and that we have concerns about 44 the lack of effective end-to-end congestion control for this best- 45 effort voice traffic. 47 Feedback can be sent to the IAB mailing list at iab@ietf.org, or to 48 the editors at floyd@icir.org and kempf@docomolabs-usa.com. Feedback 49 can also be sent to the end2end-interest mailing list [E2E]. 51 TO BE DELETED BY THE RFC EDITOR UPON PUBLICATION: 53 Changes from draft-iab-congestion-01.txt: 55 * Rephrasing a few sentences in Section 2 about over-provisioning. 56 Feedback from Ran Atkinson. 58 * Rephrased the discussion of ITU codecs, and acknowledged that the 59 RTP profile also might be used in private networks. Feedback from 60 Colin Perkins. 62 * Added a sentence that the concerns of this document could apply to 63 traffic other than just audio traffic. Feedback from Jeremy George. 65 * Updated citations. 67 * Added a Table of Contents. 69 * Added some references to QoS in cable access networks. Feedback 70 from Jean-Francois Mule. 72 * Added results of experiments to Table 1. 74 Changes from draft-iab-congestion-00.txt: 76 * Added a discussion of QoS efforts in the IETF, and made it clear 77 that we are not recommending any particular roll-out path for VoIP 78 traffic in the Internet. In particular, we are not claiming that 79 best-effort VoIP is a recommended deployment strategy. 81 * Included simulations for TCP with timestamps. 83 * Replace "terminate" with "terminate or suspend". 85 * Changed the phrase "overprovisioned links" to "uncongested links", 86 or "links with low levels of link utilization", to avoid entering the 87 debate about appropriate levels of provisioning. 89 * Added a section on Open Issues. 91 Table of Contents 93 1. Introduction 94 2. An Example of the Potential for Trouble 95 3. Why are Persistent, High Drop Rates a Problem? 96 3.1. Congestion Collapse. 97 3.2. User Quality. 98 3.3. The Amorphous Problem of Fairness. 99 4. Current efforts in the IETF 100 4.1. RTP 101 4.2. TFRC 102 4.3. DCCP 103 4.4. Adaptive Rate Audio Codecs 104 4.5. Differentiated Services and Related Topics 105 5.0. Assessing Minimum Acceptable Sending Rates 106 5.1. Drop Rates at 4.75 kbps Minimum Sending Rate 107 5.2. Drop Rates at 64 kbps Minimum Sending Rate 108 5.3. Open Issues 109 5.4. A Simple Heuristic 110 6. Constraints on VoIP Systems 111 7. Conclusions and Recommendations. 112 8. Acknowledgements 113 9. References 114 10. Appendix - Sending Rates with Packet Drops 115 11. Security Considerations 116 12. IANA Considerations 117 13. AUTHORS' ADDRESSES 119 1. Introduction 121 While many in the telephony community assume that commercial VoIP 122 service in the Internet awaits effective end-to-end QoS, in reality 123 voice service over best-effort broadband Internet connections is an 124 available service now with growing demand. While some ISPs deploy 125 QoS on their backbones, and some corporate intranets offer end-to-end 126 QoS internally, end-to-end QoS is not generally available to 127 customers in the current Internet. Given the current commercial 128 interest in VoIP on best-effort media connections, it seems prudent 129 to examine the potential effect of real time flows on congestion. In 130 this document, we perform such an analysis. Note, however, that this 131 document is not making any recommendations about deployment paths for 132 VoIP in terms of QoS support, and is not claiming that best-effort 133 service can be relied upon to give acceptable performance for VoIP. 134 This document is also not discussing signalling connections for VoIP. 135 However, voice traffic is in fact occasionally deployed as best 136 effort traffic over some links in the Internet today, and we expect 137 this occasional deployment to continue. This document expresses our 138 concern over the lack of effective end-to-end congestion control for 139 this best-effort voice traffic. 141 Assuming that VoIP over best-effort Internet connections continues to 142 gain popularity among consumers with broadband connections, the 143 deployment of end-to-end QoS mechanisms in public ISPs may be slow. 144 The IETF has developed standards for QoS mechanisms in the Internet 145 [DIFFSERV, RSVP] and continues to be active in this area [NSIS,COPS]. 146 However, the deployment of technologies requiring change to the 147 Internet infrastructure is subject to a wide range of commercial as 148 well as technical considerations, and technologies that can be 149 deployed without changes to the infrastructure enjoy considerable 150 advantages in the speed of deployment. RFC 2990 outlines some of the 151 technical challenges to the deployment of QoS architectures in the 152 Internet [RFC2990]. Often, interim measures that provide support for 153 fast-growing applications are adopted, and are successful enough at 154 meeting the need that the pressure for a ubiquitous deployment of the 155 more disruptive technologies is reduced. There are many examples of 156 the slow deployment of infrastructure that are similar to the slow 157 deployment of QoS mechanisms, including IPv6, IP multicast, or of a 158 global PKI for IKE and IPsec support. 160 Interim QoS measures that can be deployed most easily include single- 161 hop or edge-only QoS mechanisms for VoIP traffic on individual 162 congested links, such as edge-only QoS mechanisms for cable access 163 networks. Such local forms of QoS could be quite successful in 164 protecting some fraction of best-effort VoIP traffic from congestion. 165 However, these local forms of QoS are not directly visible to the 166 end-to-end VoIP connection. A best-effort VoIP connection could 167 experience high end-to-end packet drop rates, and be competing with 168 other best-effort traffic, even if some of the links along the path 169 might have single-hop QoS mechanisms. 171 The deployment of IP telephony is likely to include best-effort 172 broadband connections to public-access networks, in addition to other 173 deployment scenarios of dedicated IP networks, or as an alternative 174 to band splitting on the last mile of ADSL deployments or QoS 175 mechanisms on cable access networks. There already exists a rapidly- 176 expanding deployment of VoIP services intended to operate over 177 residential broadband access links (e.g., [FWD, Vonage]). At the 178 moment, many public-access IP networks are uncongested in the core, 179 with low or moderate levels of link utilization, but this is not 180 necessarily the case on last hop links. If an IP telephony call runs 181 completely over the Internet, the connection could easily traverse 182 congested links on both ends. Because of economic factors, the 183 growth rate of Internet telephony is likely to be greatest in 184 developing countries, where core links are more likely to be 185 congested, making congestion control an especially important topic 186 for developing countries. 188 Given the possible deployment of IP telephony over congested best- 189 effort networks, some concerns arise about the possibilities of 190 congestion collapse due to a rapid growth in real-time voice traffic 191 that does not practice end-to-end congestion control. This document 192 raises some concerns about fairness, user quality, and the danger of 193 congestion collapse that would arise from a rapid growth in best- 194 effort telephony traffic on best-effort networks. We consider best- 195 effort telephony connections that have a minimum sending rate and 196 that compete directly with other best-effort traffic on a path with 197 at least one congested link, and address the specific question of 198 whether such traffic should be required to terminate, or to suspend 199 sending temporarily, in the face of a persistent, high packet drop 200 rate, when reducing the sending rate is not a viable alternative. 202 The concerns in this document about fairness and the danger of 203 congestion collapse apply not only to telephony traffic, but also to 204 video traffic and other best-effort real-time traffic with a minimum 205 sending rate. RFC 2914 already makes the point that best-effort 206 traffic requires end-to-end congestion control [RFC2914]. Because 207 audio traffic sends at such a low rate, relative to video and other 208 real-time traffic, it is sometimes claimed that audio traffic doesn't 209 require end-to-end congestion control. Thus, while the concerns in 210 this document are general, the document focuses on the particular 211 issue of best-effort audio traffic. 213 2. An Example of the Potential for Trouble 215 At the November, 2002, IEPREP Working Group meeting in Atlanta, a 216 brief demonstration was made of VoIP over a shared link between a 217 hotel room in Atlanta, Georgia, USA, and Nairobi, Kenya. The link ran 218 over the typical uncongested Internet backbone and access links to 219 peering points between either endpoint and the Internet backbone. 220 The voice quality on the call was very good, especially in comparison 221 to the typical quality obtained by a circuit-switched call with 222 Nairobi. A presentation that accompanied the demonstration described 223 the access links (e.g., DSL, T1, T3, dialup, and cable modem links) 224 as the primary source of network congestion, and described VoIP 225 traffic as being a very small percentage of the packets in commercial 226 ISP traffic [A02]. The presentation further stated that VoIP 227 received good quality in the presence of packet drop rates of 5-40% 228 [AUT]. The VoIP call used an ITU-T G.711 codec, plus proprietary FEC 229 encoding, plus RTP/UDP/IP framing. The resulting traffic load over 230 the Internet was substantially more than the 64 Kbps required by the 231 codec. The primary congestion point along the path of the 232 demonstration was a 128 Kbps access link between an ISP in Kenya and 233 several of its subscribers in Nairobi. So the single VoIP call 234 consumed more than half of the access link capacity, capacity that is 235 shared across several different users. 237 Note that this network configuration is not a particularly good one 238 for VoIP. In particular, if there are data services running TCP on 239 the link with a typical packet size of 1500 bytes, then voice packets 240 could be delayed up to 90 ms, which might cause an increase in the 241 end to end delay above the ITU-recommended time of 150 ms [G.114] for 242 speech traffic. This would result in a delay noticeable to users, 243 with an increased variation in delay, and therefore in call quality, 244 as the bursty TCP traffic comes and goes. Nevertheless, VoIP usage 245 over congested best-effort links is likely to increase in the near 246 future, regardless of VoIP's superior performance with "carrier 247 class" service. A best-effort VoIP connection that persists in 248 sending packets at 64 Kbps, consuming half of a 128 Kbps access link, 249 in the face of a drop rate of 40%, with the resulting user- 250 perceptible degradation in voice quality, is not behaving in a way 251 that serves the interests of either the VoIP users or the other 252 concurrent users of the network. 254 As the Nairobi connection demonstrates, prescribing universal 255 overprovisioning (or more precisely, provisioning sufficient to avoid 256 persistent congestion) as the solution to the problem is not an 257 acceptable generic solution. For example, in regions of the world 258 where circuit-switched telephone service is poor and expensive, and 259 Internet access is possible and lower cost, provisioning all Internet 260 links to avoid congestion is likely to be impractical or impossible. 262 In particular, an over-provisioned core is not by itself sufficient 263 to avoid congestion collapse all the way along the path, because an 264 over-provisioned core can not address the common problem of 265 congestion on the access links. Many access links routinely suffer 266 from congestion. It is important to avoid congestion collapse along 267 the entire end-to-end path, including along the access links (where 268 congestion collapse would consist of congested access links wasting 269 scarce bandwidth carrying packets that will only be dropped 270 downstream). So an over-provisioned core does not by itself 271 eliminate or reduce the need for end-to-end congestion avoidance and 272 control. 274 There are two possible mechanisms for avoiding this congestion 275 collapse: call rejection during busy periods, or the use of end-to- 276 end congestion control. Because there are currently no 277 acceptance/rejection mechanisms for best-effort traffic in the 278 Internet, the only alternative is the use of end-to-end congestion 279 control. This is important even if end-to-end congestion control is 280 invoked only in those very rare scenarios with congestion in 281 generally-uncongested access links or networks. There will always be 282 occasional periods of high demand, e.g., in the two hours after an 283 earthquake or other disaster, and this is exactly when it is 284 important to avoid congestion collapse. 286 Best-effort traffic in the Internet does not include mechanisms for 287 call acceptance or rejection. Instead, a best-effort network itself 288 is largely neutral in terms of resource management, and the 289 interaction of the applications' transport sessions mutually 290 regulates network resources in a reasonably fair fashion. One way to 291 bring voice into the best-effort environment in a non-disruptive 292 manner is to focus on the codec and look at rate adaptation measures 293 that can successfully interoperate with existing transport protocols 294 (e.g., TCP), while at the same time preserving the integrity of a 295 real-time, analog voice signal; another way is to consider codecs 296 with fixed sending rates. Whether the codec has a fixed or variable 297 sending rate, we consider the appropriate response when the codec is 298 at its minimum data rate, and the packet drop rate experienced by the 299 flow remains high. This is the key issue addressed in this document. 301 3. Why are Persistent, High Drop Rates a Problem? 303 Persistent, high packet drop rates are rarely seen in the Internet 304 today, in the absence of routing failures or other major disruptions. 305 This happy situation is due primarily to low levels of link 306 utilization in the core, with congestion typically found on lower- 307 capacity access links, and to the use of end-to-end congestion 308 control in TCP. Most of the traffic on the Internet today uses TCP, 309 and TCP self-corrects so that the two ends of a connection reduce the 310 rate of packet sending if congestion is detected. In the sections 311 below, we discuss some of the problems caused by persistent, high 312 packet drop rates. 314 3.1. Congestion Collapse. 316 One possible problem caused by persistent, high packet drop rates is 317 that of congestion collapse. Congestion collapse was first observed 318 during the early growth phase of the Internet of the mid 1980s 319 [RFC896], and the fix was provided by Van Jacobson, who developed the 320 congestion control mechanisms that are now required in TCP 321 implementations [Jacobson88, RFC2581]. 323 As described in RFC 2914, congestion collapse occurs in networks with 324 flows that traverse multiple congested links having persistent, high 325 packet drop rates [RFC2914]. In particular, in this scenario packets 326 that are injected onto congested links squander scarce bandwidth 327 since these packets are only dropped later, on a downstream congested 328 link. If congestion collapse occurs, all traffic slows to a crawl and 329 nobody gets acceptable packet delivery or acceptable performance. 330 Because congestion collapse of this form can occur only for flows 331 that traverse multiple congested links, congestion collapse is a 332 potential problem in VoIP networks when both ends of the VoIP call 333 are on an congested broadband connection such as DSL, or when the 334 call traverses an congested backbone or transoceanic link. 336 3.2. User Quality. 338 A second problem with persistent, high packet drop rates concerns 339 service quality seen by end users. Consider a network scenario where 340 each flow traverses only one congested link, as could have been the 341 case in the Nairobi demonstration above. For example, imagine N VoIP 342 flows sharing a 128 Kbps link, with each flow sending at least 64 343 Kbps. For simplicity, suppose the 128 Kbps link is the only 344 congested link, and there is no traffic on that link other than the N 345 VoIP calls. We will also ignore for now the extra bandwidth used by 346 the telephony traffic for FEC and packet headers, or the reduced 347 bandwidth (often estimated as 70%) due to silence suppression. We 348 also ignore the fact that the two streams composing a bidirectional 349 VoIP call, one for each direction, can in practice add to the load on 350 some links of the path. Given these simplified assumptions, the 351 arrival rate to that link is at least N*64 Kbps. The traffic actually 352 forwarded is at most 2*64 Kbps (the link bandwidth), so at least 353 (N-2)*64 Kbps of the arriving traffic must be dropped. Thus, a 354 fraction of at least (N-2)/N of the arriving traffic is dropped, and 355 each flow receives on average a fraction 1/N of the link bandwidth. 356 An important point to note is that the drops occur randomly, so that 357 no one flow can be expected statistically to present better quality 358 service to users than any other. Everybody's voice quality therefore 359 suffers. 361 It seems clear from this simple example that the quality of best- 362 effort VoIP traffic over congested links can be improved if each VoIP 363 flow uses end-to-end congestion control, and has a codec that can 364 adapt the bit rate to the bandwidth actually received by that flow. 365 The overall effect of these measures is to reduce the aggregate 366 packet drop rate, thus improving voice quality for all VoIP users on 367 the link. Today, applications and popular codecs for Internet 368 telephony attempt to compensate by using more FEC, but controlling 369 the packet flow rate directly should result in less redundant FEC 370 information, and thus less bandwidth, thereby improving throughput 371 even further. The effect of delay and packet loss on VoIP in the 372 presence of FEC has been investigated in detail in the literature 373 [JS00, JS02, JS03, MTK03]. One rule of thumb is that when the packet 374 loss rate exceeds 20%, the audio quality of VoIP is degraded beyond 375 usefulness, in part due to the bursty nature of the losses [S03]. We 376 are not aware of measurement studies of whether VoIP users in 377 practice tend to hang up when packet loss rates exceed some limit. 379 The simple example in this section considered only voice flows, but 380 in reality, VoIP traffic will compete with other flows, most likely 381 TCP. The response of VoIP traffic to congestion works best by taking 382 into account the congestion control response of TCP, as is discussed 383 in the next subsection. 385 3.3. The Amorphous Problem of Fairness. 387 A third problem with persistent, high packet drop rates is fairness. 388 In this document we consider fairness with regard to best-effort VoIP 389 traffic competing with other best-effort traffic in the Internet. 390 That is, we are explicitly not addressing the issues raised by 391 emergency services, or by QoS-enabled traffic that is known to be 392 treated separately from best-effort traffic at a congested link. 394 While fairness is a bit difficult to quantify, we can illustrate the 395 effect by adding TCP traffic to the congested link discussed in the 396 previous section. In this case, the non-congestion-controlled traffic 397 and congestion-controlled TCP traffic [RFC2914] share the link, with 398 the congestion-controlled traffic's sending rate determined by the 399 packet drop rate experienced by those flows. As in the previous 400 section, the 128 Kbps link has N VoIP connections each sending 64 401 Kbps, resulting in packet drop rate of at least (N-2)/N on the 402 congested link. Competing TCP flows will experience the same packet 403 drop rates. However, a TCP flow experiencing the same packet drop 404 rates will be sending considerably less than 64 Kbps. From the point 405 of view of who gets what amount of bandwidth, the VoIP traffic is 406 crowding out the TCP traffic. 408 Of course, this is only one way to look at fairness. The relative 409 fairness between VoIP and TCP traffic can be viewed several different 410 ways, depending on the assumptions that one makes on packet sizes and 411 round-trip times. In the presence of a fixed packet drop rate, for 412 example, a TCP flow with larger packets sends more (in Bps, bytes per 413 second) than a TCP flow with smaller packets, and a TCP flow with a 414 shorter round-trip time sends more (in Bps) than a TCP flow with a 415 larger round-trip time. In environments with high packet drop rates, 416 TCP's sending rate depends on the algorithm for setting the 417 retransmit timer (RTO) as well, with a TCP implementation having a 418 more aggressive RTO setting sending more than a TCP implementation 419 having a less aggressive RTO setting. 421 Unfortunately, there is no obvious canonical round-trip time for 422 judging relative fairness of flows in the network. Agreement in the 423 literature is that the majority of packets on most links in the 424 network experience round-trip times between 10 and 500 ms [RTTWeb]. 426 (This does not include satellite links.) As a result, if there was a 427 canonical round-trip for judging relative fairness, it would have to 428 be within that range. In the absence of a single representative 429 round-trip time, the assumption of this paper is that it is 430 reasonable to consider fairness between a a VoIP connection and a TCP 431 connection with the same round-trip time. 433 Similarly, there is no canonical packet size for judging relative 434 fairness between TCP connections. However, because the most common 435 packet size for TCP data packets is 1460 bytes [Measurement], we 436 assume that it is reasonable to consider fairness between a a VoIP 437 connection, and a TCP connection sending 1460-byte data packets. 438 Note that 1460 bytes is considerably larger than is typically used 439 for VoIP packets. 441 In the same way, while RFC 2988 specifies TCP's algorithm for setting 442 TCP's RTO, there is no canonical value for the minimum RTO, and the 443 minimum RTO heavily affects TCP's sending rate in times of high 444 congestion [RFC2988]. RFC 2988 specifies that TCP's RTO must be set 445 to SRTT + 4*RTTVAR, for SRTT the smoothed round-trip time, and for 446 RTTVAR the mean deviation of recent round-trip time measurements. 447 RFC 2988 further states that the RTO "SHOULD" have a minimum value of 448 1 second. However, it is not uncommon in practice for TCP 449 implementations to have a minimum RTO as low as 100 ms. For the 450 purposes of this document, in considering relative fairness, we will 451 assume a minimum RTO of 100 ms. 453 As an additional complication, TCP connections that use fine-grained 454 timestamps can have considerably higher sending rates than TCP 455 connections that do not use timestamps, in environments with high 456 packet drop rates. For TCP connections with fine-grained timestamps, 457 a valid round-trip time measurement is obtained when a retransmitted 458 packet is successfully received and acknowledged by the receiver; in 459 this case a backed-off retransmit timer can be un-backed-off as well. 460 For TCP connections without timestamps, a valid round-trip time 461 measurement is only obtained when the transmission of a new packet is 462 received and acknowledged by the receiver. This limits the 463 opportunities for the un-backing-off of a backed-off retransmit 464 timer. In this document, in considering relative fairness, we use a 465 TCP connection without timestamps, since this is the dominant use of 466 TCP in the Internet. 468 A separate claim that has sometimes been raised in terms of fairness 469 is that best-effort VoIP traffic is inherently more important that 470 other best-effort traffic (e.g., web surfing, peer-to-peer traffic, 471 or multi-player games), and therefore merits a larger share of the 472 bandwidth in times of high congestion. Our assumption in this 473 document is that TCP traffic includes pressing email messages, 474 business documents, and emergency information downloaded from web 475 pages, as well as the more recreational uses cited above. Thus, we 476 do not agree that best-effort VoIP traffic should be exempt from end- 477 to-end congestion control due to any claims of inherently more 478 valuable content. (One could equally logically argue that because 479 email and instant messaging are more efficient forms of communication 480 than VoIP in terms of bandwidth usage, as a result email and instant 481 messaging are more valuable uses of scarce bandwidth in times of high 482 congestion.) In fact, the network is incapable of making a judgement 483 about the relative user value of traffic. The default assumption is 484 that all best-effort traffic has equal value to the network provider 485 and to the user. 487 We note that this discussion of relative fairness does not in any way 488 challenge the right of ISPs to allocate bandwidth on congested links 489 to classes of traffic in any way that they choose. (E.g. 490 administrators rate-limit the bandwidth used by peer-to-peer traffic 491 on some links in the network, to ensure that bandwidth is also 492 available for other classes of traffic.) This discussion merely 493 argues that there is no reason for entire classes of best-effort 494 traffic to be exempt from end-to-end congestion control, 496 4. Current efforts in the IETF 498 There are four efforts currently underway in IETF to address issues 499 of congestion control for real time traffic: an upgrade of the RTP 500 specification, TFRC, DCCP, and work on audio codecs. 502 4.1. RTP 504 RFC 1890, the original RTP Profile for Audio and Video Control, does 505 not discuss congestion control [RFC1890]. The revised document on 506 "RTP Profile for Audio and Video Conferences with Minimal Control" 507 [RFC3551] discusses congestion control in Section 2. [RFC3551] says 508 the following: 510 "If best-effort service is being used, RTP receivers SHOULD monitor 511 packet loss to ensure that the packet loss rate is within 512 acceptable parameters. Packet loss is considered acceptable if a 513 TCP flow across the same network path and experiencing the same 514 network conditions would achieve an average throughput, measured on 515 a reasonable timescale, that is not less than the RTP flow is 516 achieving. This condition can be satisfied by implementing 517 congestion control mechanisms to adapt the transmission rate (or 518 the number of layers subscribed for a layered multicast session), 519 or by arranging for a receiver to leave the session if the loss 520 rate is unacceptably high." 521 "The comparison to TCP cannot be specified exactly, but is intended 522 as an "order-of-magnitude" comparison in timescale and throughput. 523 The timescale on which TCP throughput is measured is the round- 524 trip time of the connection. In essence, this requirement states 525 that it is not acceptable to deploy an application (using RTP or 526 any other transport protocol) on the best-effort Internet which 527 consumes bandwidth arbitrarily and does not compete fairly with TCP 528 within an order of magnitude." 530 Note that [RFC3551] says that receivers "SHOULD" monitor packet loss. 531 [RFC3551] does not explicitly say that the RTP senders and receivers 532 "MUST" detect and respond to a persistent high loss rate. Since 533 congestion collapse can be considered a "danger to the Internet" the 534 use of "MUST" would be appropriate for RTP traffic in the best-effort 535 Internet, where the VoIP traffic shares a link with other traffic, 536 since "danger to the Internet" is one of two criteria given in RFC 537 2119 for the use of "MUST" [RFC2119]. Different requirements may 538 hold for a private best-effort IP network provisioned solely for 539 VoIP, where the VoIP traffic does not interact with the wider 540 Internet. 542 4.2. TFRC 544 As mentioned in RFC 3267, equation-based congestion control is one of 545 the possibilities for VoIP. TCP Friendly Rate Control (TFRC) is the 546 equation-based congestion control mechanism that has been 547 standardized in the IETF. The TFRC specification, "TCP Friendly Rate 548 Control (TFRC): Protocol Specification" [RFC3448], says the 549 following: 551 "TFRC ... is reasonably fair when competing for bandwidth with TCP 552 flows, but has a much lower variation of throughput over time 553 compared with TCP, making it more suitable for applications such as 554 telephony or streaming media where a relatively smooth sending rate 555 is of importance. ... TFRC is designed for applications that use 556 a fixed packet size, and vary their sending rate in packets per 557 second in response to congestion. Some audio applications require 558 a fixed interval of time between packets and vary their packet size 559 instead of their packet rate in response to congestion. The 560 congestion control mechanism in this document cannot be used by 561 those applications; TFRC-PS (for TFRC-PacketSize) is a variant of 562 TFRC for applications that have a fixed sending rate but vary their 563 packet size in response to congestion. TFRC-PS will be specified 564 in a later document." 566 There is no draft available for TFRC-PS yet, unfortunately, but 567 several researchers are still working on these issues. 569 4.3. DCCP 571 The Datagram Congestion Control Protocol (DCCP) is a transport 572 protocol being standardized in the IETF for unreliable flows, with 573 the application being able to specify either TCP-like or TFRC 574 congestion control [DCCP03]. 576 DCCP currently has two Congestion Control IDentifiers or CCIDs; these 577 are CCID 2 for TCP-like congestion control and CCID 3 for TFRC 578 congestion control. As TFRC-PS becomes available and goes through 579 the standards process, we would expect DCCP to create a new CCID, 580 CCID 4, for use with TFRC-PS congestion control. 582 4.4. Adaptive Rate Audio Codecs 584 A critical component in the design of any real-time application is 585 the selection of appropriate codecs, specifically codecs that operate 586 at a low sending rate, or that will reduce the sending rate as 587 throughput decreases and/or packet loss increases. Absent this, and 588 in the absence of the response to congestion recommended in this 589 document, the real-time application is likely to significantly 590 increase the risk of Internet congestion collapse, thereby adversely 591 impacting the health of the deployed Internet. If the codec is 592 capable of reducing its bit rate in response to congestion, this 593 improves the scaling of the number of VoIP or TCP sessions capable of 594 sharing a congested link while still providing acceptable performance 595 to users. Many current audio codecs are capable of sending at a low 596 bit rate, in some cases adapting their sending rate in response to 597 congestion indications from the network. 599 RFC 3267 describes RTP payload formats for use with the Adaptive 600 Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) audio 601 codecs [RFC 3267]. The AMR codec supports eight speech encoding 602 modes having bit rates between 4.75 and 12.2 kbps, with the speech 603 encoding performed on 20 ms speech frames, and is able to reduce the 604 transmission rate during silence periods. The payload format 605 specified in RFC 3267 includes forward error correction (FEC) and 606 frame interleaving to increase robustness against packet loss 607 somewhat. The AMR codec was chosen by the Third Generation 608 Partnership Project (3GPP) as the mandatory codec for third 609 generation (3G) cellular systems, and RFC 2367 recommends that AMR or 610 AMR-WB applications using the RTP payload format specified in RFC 611 3267 use congestion control, though no specific mechanism is 612 recommended. RFC 3267 gives "Equation-Based Congestion Control for 613 Unicast Applications" as an example of a congestion control mechanism 614 suitable for real-time flows [FHPW00]. 616 The "Internet Low Bit Rate Codec", iLBC, is an IETF effort to develop 617 an IPR-free codec for robust voice communication over IP [ILBRC]. 618 The codec is designed for graceful speech quality degradation in the 619 case of lost packets, and has a payload bit rate of 13.33 Kbps for 30 620 ms frames or 15.20 Kbps for 20 ms frames. 622 There are several unencumbered low-rate codec algorithms in Ivox (the 623 Interactive VOice eXchange) [IVOX], with plans to add additional 624 variable rate codecs. For example, LPC2400 (a.k.a. LQ2400) is a 2400 625 bps LPC based codec with an enhancement to permit "silence 626 detection". The 2400 bps codec is reported to have a "slight robotic 627 quality" [A03] (even without the additional complications of packet 628 loss). The older multirate codec described in [KFK79, KF82] is an 629 LPC codec that works at two rates, 2.4 Kbps and 9.6 Kbps, and can 630 optionally send additional "residual" bits for enhanced quality at a 631 higher bit rate. 633 Off-the-shelf ITU-T vocoders such as G.711 were generally designed 634 explicitly for circuit-switched networks and are not as well-adapted 635 for Internet use, even with the addition of FEC on top. 637 4.5. Differentiated Services and Related Topics 639 The Differentiated Services Working Group [DIFFSERV], which concluded 640 in 2003, completed standards for the Differentiated Services Field 641 (DS Field) in the IPv4 and IPv6 Headers [RFC2474], including several 642 per-hop forwarding behaviors [RFC2597, RFC3246]. The Next Steps in 643 Signaling Working Group [NSIS] is developing an optimized signalling 644 protocol for QoS, based in part on earlier work of the Resource 645 Reservation Setup Protocol Working Group [RSVP]. We do not discuss 646 these and related efforts further in this document, since this 647 document concerns only that VoIP traffic that might be carried as 648 best-effort traffic over some congested link in the Internet. 650 5.0. Assessing Minimum Acceptable Sending Rates 652 Current IETF work in the DCCP and AVT working groups does not 653 consider the problem of applications that have a minimum sending rate 654 and are not able to go below that sending rate. This clearly must be 655 addressed in the TFRC-PS draft. As suggested in the RTP document, if 656 the loss rate is persistently unacceptably high relative to the 657 current sending rate, and the best-effort application is unable to 658 lower its sending rate, then the only acceptable answer is for that 659 flow to discontinue sending on that link. For a multicast session, 660 this could be accomplished by the receiver withdrawing from the 661 multicast group. For a unicast session, this could be accomplished 662 by the unicast connection terminating, at least for a period of time. 664 We can formulate a problem statement for the minimum sending rate in 665 the following way. Consider a best-effort, adaptive audio 666 application that is able to adapt down to a minimum sending rate of N 667 Bps (bytes per second) of application data, sending M packets per 668 second. Is this a sufficiently low sending rate that the best-effort 669 flow is never required to terminate due to congestion, or to reduce 670 its sending rate in packets per second still further? In other words, 671 is N Bps an acceptable minimum sending rate for the application, 672 which can be continued in the face of congestion without terminating 673 or suspending the application? 675 We assume, generously for VoIP, that the limitation of the network is 676 in bandwidth in bytes per second (Bps), and not in CPU cycles or in 677 packets per second (pps). If the limitation in the network is in 678 bandwidth, this is a limitation in Bps, while if the limitation is in 679 router processing capacity in packets, this would be a limitation in 680 pps. We note that TCP sends fixed-size data packets, and reduces its 681 sending rate in pps when it adapts to network congestion, thus 682 reducing the load on the forward path both in Bps and in pps. In 683 contrast, for adaptive VoIP applications, the adaption is sometimes 684 to keep the same sending rate in pps, but to reduce the packet size, 685 reducing the sending rate in Bps. This fits the needs of audio as an 686 application, and is a good response on a network path where the 687 limitation is in Bps. Such behavior would be a less appropriate 688 response for a network path where the limitation is in pps. 690 If the network limitation in fact is in Bps, then all that matters in 691 terms of congestion is a flow's sending rate on the wire in Bps. If 692 this assumption of a network limitation in Bps is false, then the 693 sending rate in pps could contribute to congestion even when the 694 sending rate in Bps is quite moderate. While the ideal would be to 695 have a transport protocol that is able to detect whether the 696 bottleneck links along the path are limited in Bps or in pps, and to 697 respond appropriately when the limitation is in pps, such an ideal is 698 hard to achieve, and we would not want to delay the deployment of 699 congestion control for telephony traffic until such an ideal could be 700 accomplished. In addition, we note that the current TCP congestion 701 control mechanisms are themselves not very effective in an 702 environment where there is a limitation along the reserve path in 703 pps. While the TCP mechanisms do provide an incentive to use large 704 data packets, TCP does not include any effective congestion control 705 mechanisms for the stream of small acknowledgement packets on the 706 reverse path. Given the arguments above, it seems acceptable to us 707 to assume a network limitation in Bps rather than in pps in 708 considering the minimum sending rate of telephony traffic. 710 Assuming 40-byte packet headers (IP, RTP, and UDP or DCCP), the 711 application data sending rate of N Bps and M pps translates to a 712 sending rate on the wire of B = N+40M Bps. If the application uses 713 additional FEC (Forward Error Correction), the FEC bits must be added 714 in as well. In our example, we ignore bandwidth adjustments that are 715 needed to take into account the additional overhead for FEC or the 716 reduced sending rate for silence periods. We also are not taking 717 into account the possible role of header compression on congested 718 edge links, which can reduce significantly the number of bytes used 719 for headers on those links. 721 Now, consider an equivalent-rate TCP connection with data packets of 722 P bytes and a round-trip time of R seconds. Taking into account 723 header size, such a TCP connection with a sending rate on the wire of 724 B Bps is sending B/(P+40) pps, or, equivalently, BR/(P+40) ppr 725 (packets per round-trip time). 727 Restating the question in terms of the above expressions for VoIP and 728 TCP: if the best-effort VoIP connection is experiencing a persistent 729 packet drop rate of D, and is at its minimum sending rate on the wire 730 of B Bps, when should the application or transport protocol terminate 731 or suspend the VoIP connection? 733 One answer to this question is to find the sending rate in ppr for a 734 TCP connection sending at the same rate on the wire in Bps, and to 735 use the TCP response function to determine whether a conformant TCP 736 connection would be able to maintain a sending rate close to that 737 sending rate with the same persistent drop rate D. If the sending 738 rate of the VoIP connection is significantly higher that the sending 739 rate of a conformant TCP connection under the same conditions, and 740 the VoIP connection is unable to reduce its sending rate on the wire, 741 then the VoIP connection should terminate or suspend. 743 As discussed above, there are two reasons for requiring the 744 application to terminate: 746 1) Avoiding congestion collapse, given the possibility of multiple 747 congested links, 749 2) Fairness for congestion-controlled TCP traffic sharing the link. 751 In addition, if an application requires a minimum service level from 752 the network in order to operate, and that service level is 753 consistently not achieved, then the application should terminate or 754 suspend sending. 756 One counter-argument is that users will just hang up anyway with a 757 high packet drop rate so there is no point in enforcing a minimum 758 acceptable rate. Users might hang up, but they might also just keep 759 on talking, with the occasional noise getting though, for minutes or 760 longer waiting for a short period of clarity. Another counter- 761 argument is that nobody really benefits from VoIP connections being 762 terminated or suspended when persistent packet drop rates exceed the 763 allowable packet drop rate for the configured minimum sending rate. 764 This is untrue, since the termination of these VoIP connections could 765 allow competing TCP and VoIP traffic to make some progress. 767 In the next section, we illustrate the approach outlined above for 768 VoIP flows with minimum sending rates of 4.75 and 64 kbps 769 respectively, and show that in practice such an approach would not 770 seem too burdensome for VoIP traffic. This approach implies that the 771 VoIP traffic would terminate or suspend when the packet drop rate 772 significantly exceeds 40% for a VoIP flow with a minimum sending rate 773 of 4.75 kbps. If VoIP is to deliver "carrier quality" or even near 774 "carrier quality" on best-effort links, conditioning deployment on 775 the ability to maintain maximum sending rates during periods of 776 persistent packet drops rates exceeding 40% does not suggest a 777 service model that will see widespread acceptance among consumers, no 778 matter what the price differential. Good packet throughput is vital 779 for the delivery of acceptable VoIP service. 781 For a VoIP flow that stops sending because its minimum sending rate 782 is too high for the steady-state packet drop rate, we have not 783 addressed the question of when a VoIP flow might be able to start 784 sending again, to see if the congestion on the end-to-end path has 785 changed. This issue has been addressed in a proposal for 786 Probabilistic Congestion Control [PCC]. 788 We note that if the congestion indications are in the form of ECN- 789 marked packets (Explicit Congestion Notification), as opposed to 790 dropped packets, then the answers about when a flow with a minimum 791 sending rate would have to stop sending are somewhat different. ECN 792 allows routers to explicitly notify end-nodes of congestion by ECN- 793 marking instead of dropping packets [RFC3168]. If packets are ECN- 794 marked instead of dropped in the network, then there are no concerns 795 of congestion collapse or of user quality (for the ECN-capable 796 traffic, at any rate), and what remains are concerns of fairness with 797 competing flows. Second, in regimes with very high congestion, TCP 798 has a higher sending rate with ECN-marked than with dropped packets, 799 in part because of different dynamics in terms of un-backing-off a 800 backed-off retransmit timer. 802 5.1. Drop Rates at 4.75 kbps Minimum Sending Rate 804 Consider an adaptive audio application with an RTT of R=0.1 seconds 805 that is able to adapt down to a minimum sending rate of 4.75 kbps 806 application data, sending M=20 packets per second. This sending rate 807 translates to N=593 Bps of application data, for a sending rate on 808 the wire of B=1393 Bps. An equivalent-rate TCP connection with data 809 packets of P=1460 bytes and a round-trip time of R=0.1 seconds would 810 be sending BR/(P+40) = 0.09 ppr. 812 Table 1 in the Appendix looks at the packet drop rate experienced by 813 a TCP connection with the RTO set to twice the RTT, and gives the 814 corresponding sending rate of the TCP connection in ppr. The second 815 column gives the sending rate estimated by the standard analytical 816 approach, and the third, fourth, and fifth columns give the average 817 sending rate from simulations with random packet drops or marks. The 818 sixth column gives the sending rates from experiments on a 819 4.8-RELEASE FreeBSD machine. The analytical approaches require an 820 RTO expressed as a multiple of the RTT, and Table 1 shows the results 821 for the RTO set to 2 RTT. In the simulations, the minimum RTO is set 822 to twice the RTT. See the Appendix for more details. 824 For a sending rate of 0.09 ppr and an RTO set to 2 RTT, Table 1 shows 825 that the analytical approach gives a corresponding packet drop rate 826 of roughly 50%, while the simulations in the fifth column and the 827 experiments in the sixth column give a packet drop rate of between 828 35% and 40% to maintain a sending rate of 0.09 ppr. (For a reference 829 TCP connection using timestamps, shown in the fourth column, the 830 simulations give a packet drop rate of 55% to maintain a sending rate 831 of 0.09 ppr.) Of the two approaches for determining TCP's 832 relationship between the sending rate and the packet drop rate, the 833 analytic approach and the use of simulations, we consider the 834 simulations to be the most realistic, for reasons discussed in the 835 Appendix. This suggests a packet drop rate of 40% would be 836 reasonable for a TCP connection with an average sending rate of 0.09 837 ppr. As a result, a VoIP connection with an RTT of 0.1 sec and a 838 minimum sending rate of 4.75 kbps would be required to terminate or 839 suspend when the persistent packet drop rate significantly exceeds 840 40%. 842 These estimates are sensitive to the assumed round-trip time of the 843 TCP connection. If we assumed instead that the equivalent-rate TCP 844 connection had a round-trip time of R=0.01 seconds, the equivalent- 845 rate TCP connection would be sending BR/(P+40) = 0.009 ppr. However, 846 we have also assumed a minimum RTO for TCP connections of 0.1 847 seconds, which in this case would mean an RTO of at least 10 RTT. 848 For this setting of the RTO, we would use Table 2 from the appendix 849 to determine the average TCP sending rate for a particular packet 850 drop rate. The simulations in the fifth column of Table 2 suggest 851 that a TCP connection with an RTT of 0.01 sec and an RTO of 10 RTT 852 would be able to send 0.009 ppr with a packet drop rate of 45%. (For 853 the same TCP connection using timestamps, shown in the fourth column, 854 the simulations give a packet drop rate of 60-65% to maintain a 855 sending rate of 0.009 ppr.) 857 Thus, for a VoIP connection with an RTT of 0.01 sec and a minimum 858 sending rate of 4.75 kbps, the VoIP connection would be required to 859 terminate or suspend when the persistent packet drop rate exceeded 860 45%. 862 5.2. Drop Rates at 64 kbps Minimum Sending Rate 864 The effect of increasing the minimum acceptable sending rate to 64 865 kbps is effectively to decrease the packet drop rate at which the 866 application should terminate or suspend sending. For this section, 867 consider a codec with a minimum sending rate of 64 kbps, or N=8000 868 Bps, and a packet sending rate of M=50 pps. (This would be 869 equivalent to 160-byte data packets, with 20 ms. per packet.) The 870 sending rate on the wire is B = N+40M Bps, including headers, or 871 10000 Bps. A TCP connection having that sending rate, with packets of 872 size P=1460 bytes and a round-trip time of R=0.1 seconds, sends 873 BR/(P+40) = 0.66 ppr. From the fifth column of Table 1, for an RTO 874 of 2 RTT, this corresponds to a packet drop rate between 20 and 25%. 875 [For a TCP connection using fine-grained timestamps, as shown in the 876 fourth column of Table 1, this sending rate corresponds to a packet 877 drop rate between 25% and 35%.] As a result, a VoIP connection with 878 an RTT of 0.1 sec and a minimum sending rate of 64 kbps would be 879 required to terminate or suspend when the persistent packet drop rate 880 significantly exceeds 25%. 882 For an equivalent-rate TCP connection with a round-trip time of 883 R=0.01 seconds and a minimum RTO of 0.1 seconds (giving an RTO of 10 884 RTT), we use the fifth column of Table 2, which shows that a sending 885 rate of 0.066 ppr corresponds to a packet drop rate of roughly 30%. 886 [For a TCP connection using fine-grained timestamps, as shown in the 887 fourth column of Table 2, this sending rate corresponds to a packet 888 drop rate of roughly 45%.] Thus, for a VoIP connection with an RTT 889 of 0.01 sec and a minimum sending rate of 64 kbps, the VoIP 890 connection would be required to terminate or suspend when the 891 persistent packet drop rate exceeded 30%. 893 5.3. Open Issues 895 This document does not attempt to specify a complete protocol. For 896 example, this document does not specify the definition of a 897 persistent packet drop rate. The assumption would be that a 898 "persistent packet drop rate" would refer to the packet drop rate 899 over a significant number of round-trip times, e.g., at least five 900 seconds. Another possibility would be that the time interval for 901 measuring the persistent drop rate is a function of the lifetime of 902 the connection, with longer-lived connections using longer time 903 intervals for measuring the persistent drop rate. 905 The time period for detecting persistent congestion also affects the 906 potential synchronization of VoIP sessions all terminating or 907 suspending at the same time in response to shared congestion. If 908 flows use some randomization in setting the time interval for 909 detecting persistent congestion, or use a time interval that is a 910 function of the connection lifetime, this could help to prevent all 911 VoIP flows from terminating at the same time. 913 Another design issue for a complete protocol concerns whether a flow 914 terminates when the packet drop rate is too high, or only suspends 915 temporarily. For a flow that suspends temporarily, there is an issue 916 of how long it should wait before resuming transmission. At the very 917 least, the sender should wait long enough so that the the flow's 918 overall sending rate doesn't exceed the allowed sending rate for that 919 packet drop rate. 921 The recommendation of this document is that VoIP flows with minimum 922 sending rates should have corresponding configured packet drop rates, 923 such that the flow terminates or suspends when the persistent packet 924 drop rate of the flow exceeds the configured rate. If the persistent 925 packet drop rate increases over time, flows with higher minimum 926 sending rates would have to suspend sending before flows with lower 927 minimum sending rates. If VoIP flows terminate when the persistent 928 packet drop rate is too high, this could lead to scenarios where VoIP 929 flows with lower minimum sending rates essentially receive all of the 930 link bandwidth, while the VoIP flows with higher minimum sending 931 rates are required to terminate. However, if VoIP flows suspend 932 sending for a time when the persistent packet drop rate is too high, 933 instead of terminating entirely, then the bandwidth could end up 934 being shared reasonably fairly between VoIP flows with different 935 minimum sending rates. 937 5.4. A Simple Heuristic 939 One simple heuristic for estimating congestion would be to use the 940 RTCP reported loss rate as an indicator. For example, if the RTCP- 941 reported lost rate is greater than 30%, or N back-to-back RTCP 942 reports are missing, the application could assume that the network is 943 too congested, and terminate or suspend sending. 945 6. Constraints on VoIP Systems 947 Ultimately, attempting to run VoIP on congested links, even with 948 adaptive rate codecs and minimum packet rates, is likely to run into 949 hard constraints due to the nature of real time traffic in heavily 950 congested scenarios. VoIP systems exhibit a limited ability to scale 951 their packet rate. If the number of packets decreases, the amount of 952 audio per packet is greater and error concealment at the receiver 953 becomes harder. Any error longer than phoneme length, which is 954 typically 40 to 100 ms depending on the phoneme and speaker, is 955 unrecoverable. Ideally, applications want sub 30ms packets and this 956 is what most voice codecs provide. In addition, voice media streams 957 exhibit greater loss sensitivity at lower data rates. Lower-data 958 rate codecs maintain more end-to-end state and as a result are 959 generally more sensitive to loss. 961 We note that very-low-bit-rate codecs have proved useful, although 962 with some performance degradation, in very low bandwidth, high noise 963 environments (e.g. 2.4 Kbps HF radio). For example, 2.4 Kbps codecs 964 "produce speech which although intelligible is far from natural 965 sounding" [W98]. Figure 5 of [W98] shows how the speech quality with 966 several forms of codecs varies with the bit rate of the codec. 968 7. Conclusions and Recommendations. 970 In the near term, VoIP services are likely to be deployed, at least 971 in part, over broadband best-effort connections. Current real time 972 media encoding and transmission practice ignores congestion 973 considerations, resulting in the potential for trouble should VoIP 974 become a broadly deployed service in the near to intermediate term. 975 Poor user quality, unfairness to other VoIP and TCP users, and the 976 possibility of sporadic episodes of congestion collapse are some of 977 the potential problems in this scenario. 979 These problems can be mitigated in applications that use fixed-rate 980 codecs by requiring the best-effort VoIP application to specify its 981 minimum bit throughput rate. This minimum bit rate can be used to 982 estimate a packet drop rate at which the application would terminate. 984 This document specifically recommends the following: 986 (1) In IETF standards for protocols regarding best-effort flows with 987 a minimum sending rate, a packet drop rate must be specified, such 988 that the best-effort flow terminates, or suspends sending 989 temporarily, when the steady-state packet drop rate significantly 990 exceeds the specified drop rate. 992 (2) The specified drop rate for the minimum sending rate should be 993 consistent with the use of Tables 1 and 2 as illustrated in this 994 document. 996 We note that this is a recommendation to the IETF community, as a 997 specific follow-up to RFC 2914 on Congestion Control Principles. 999 This is not a specific or complete protocol specification. 1001 Codecs that are able to vary their bit rate depending on estimates of 1002 congestion can be even more effective in providing good quality 1003 service while maintaining network efficiency under high load 1004 conditions. Adaptive variable-bit-rate codecs are therefore 1005 preferable as a means of supporting VOIP sessions on shared use 1006 Internet environments. 1008 8. Acknowledgements 1010 We thank Brian Adamson, Ran Atkinson, Fred Baker, Jon Crowcroft, 1011 Christophe Diot, Alan Duric, Jeremy George, Mark Handley, Orion 1012 Hodson, Geoff Huston, Eddie Kohler, David Meyer, Jean-Francois Mule, 1013 Colin Perkins, Jon Peterson, Cyrus Shaoul, and Henning Schulzrinne 1014 for feedback on this document. (Of course, these people do not 1015 necessarily agree with all of the document.) Ran Atkinson and Geoff 1016 Huston contributed to the text of the document. 1018 The analysis in Section 6.0 resulted from a session at the whiteboard 1019 with Mark Handley. We also thank Alberto Medina for the FreeBSD 1020 experiments showing TCP's sending rate as a function of the packet 1021 drop rate. 1023 9. References 1025 Normative References 1027 [RFC2988] V. Paxson and M. Allman, Computing TCP's Retransmission 1028 Timer, RFC 2988, November 2000. 1030 [RFC3267] J. Sjoberg, M. Westerlund, A. Lakaniemi, and Q. Xie, Real- 1031 Time Transport Protocol (RTP) Payload Format and File Storage Format 1032 for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband 1033 (AMR-WB) Audio Codecs, RFC 3267, June 2002 1035 Informative References 1037 [A02] Ran Atkinson, An ISP Reality Check, Presentation to ieprep, 1038 55th IETF Meeting, November 2002. URL 1039 "http://www.ietf.cnri.reston.va.us/proceedings/02nov/219.htm#slides". 1041 [A03] Brian Adamson, private communication, June 2003. 1043 [BBFS01] Deepak Bansal, Hari Balakrishnan, Sally Floyd, and Scott 1044 Shenker, Dynamic Behavior of Slowly-Responsive Congestion Control 1045 Algorithms, SIGCOMM 2001. 1047 [COPS] D. Durham et al., The COPS (Common Open Policy Service) 1048 Protocol, RFC 2748, January 2000. 1050 [DCCP03] Eddie Kohler, Mark Handley, Sally Floyd, and Jitendra 1051 Padhye, Datagram Congestion Control Protocol (DCCP), internet-draft 1052 draft-ietf-dccp-spec-01.txt, work in progress, March 2003. URL 1053 "http://www.icir.org/kohler/dcp/". 1055 [DIFFSERV] Differentiated Services (diffserv), Concluded Working 1056 Group, URL 1057 "http://www.ietf.cnri.reston.va.us/html.charters/OLD/diffserv- 1058 charter.html". 1060 [E2E] The end2end-interest mailing list, URL 1061 "http://www.postel.org/mailman/listinfo/end2end-interest". 1063 [FHPW00] S. Floyd, M. Handley, J. Padhye, J. Widmer, "Equation-Based 1064 Congestion Control for Unicast Applications", ACM SIGCOMM 2000. 1066 [FM03] S. Floyd and R. Mahajan, Router Primitives for Protection 1067 Against High-Bandwidth Flows and Aggregates, internet draft (not yet 1068 submitted). 1070 [FWD] Free World Dialup, URL "www.pulver.com/fwd/". 1072 [IEPREP02] Internet Emergency Preparedness (ieprep), Minutes, 55th 1073 IETF Meeting, November 2002. URL 1074 "http://www.ietf.cnri.reston.va.us/proceedings/02nov/219.htm#cmr". 1076 [ILBRC] S.V. Andersen, et. al., Internet Low Bit Rate Codec, draft- 1077 ietf-avt-ilbc-codec-01.txt, internet draft, work in progress, March 1078 2003. 1080 [G.114] Recommendation G.114 - One-way Transmission Time, ITU, May 1081 2003. URL "http://www.itu.int/itudoc/itu- 1082 t/aap/sg12aap/recaap/g.114/". 1084 [IVOX] The Interactive VOice eXchange, URL 1085 "http://manimac.itd.nrl.navy.mil/IVOX/". 1087 [Jacobson88] V. Jacobson, Congestion Avoidance and Control, ACM 1088 SIGCOMM '88, August 1988. 1090 [AUT] The maximum feasible drop rate for VoIP traffic depends on the 1091 codec. These numbers are a range for a variety of codecs; voice 1092 quality begins to deteriorate for many codecs around a 10% drop rate. 1093 Note from authors. 1095 [JS00] Wenyu Jiang and Henning Schulzrinne, Modeling of Packet Loss 1096 and Delay and Their Effect on Real-Time Multimedia Service Quality, 1097 NOSSDAV, 2000. URL 1098 "http://citeseer.nj.nec.com/jiang00modeling.html". 1100 [JS02] Wenyu Jiang and Henning Schulzrinne, Comparison and 1101 Optimization of Packet Loss Repair Methods on VoIP Perceived Quality 1102 under Bursty Loss, NOSSDAV, 2002. URL 1103 "http://www1.cs.columbia.edu/~wenyu/". 1105 [JS03] Wenyu Jiang, Kazummi Koguchi, and Henning Schulzrinne, QoS 1106 Evaluation of VoIP End-points, ICC 2003. URL 1107 "http://www1.cs.columbia.edu/~wenyu/". 1109 [KFK79] G.S. Kang, L.J. Fransen, and E.L. Kline, "Multirate Processor 1110 (MRP) for Digital Voice Communications", NRL Report 8295, Naval 1111 Research Laboratory, Washington DC, March 1979. 1113 [KF82] G.S. Kang and L.J. Fransen, "Second Report of the Multirate 1114 Processor (MRP) for Digital Voice Communciations", NRL Report 8614, 1115 Naval Research Laboratory, Washington DC, September 1982. 1117 [Measurement] Web page on "Measurement Studies of End-to-End 1118 Congestion Control in the Internet", URL 1119 "http://www.icir.org/floyd/ccmeasure.html". The section on "Network 1120 Measurements at Specific Sites" includes measurement data about the 1121 distribution of packet sizes on various links in the Internet. 1123 [MTK03] A. P. Markopoulou, F. A. Tobagi, and M. J. Karam, "Assessing 1124 the Quality of Voice Communications Over Internet Backbones", 1125 IEEE/ACM Transactions on Networking, V. 11 N. 5, October 2003. 1127 [NSIS] Next Steps in Signaling (nsis), IETF Working Group, URL 1128 "http://www.ietf.cnri.reston.va.us/html.charters/nsis-charter.html". 1130 [PCC] Joerg Widmer, Martin Mauve, and Jan Peter Damm. Probabilistic 1131 Congestion Control for Non-Adaptable Flows. Technical Report 3/2001, 1132 Department of Mathematics and Computer Science, University of 1133 Mannheim. URL "http://www.informatik.uni- 1134 mannheim.de/informatik/pi4/projects/CongCtrl/pcc/index.html". 1136 [PFTK98] J. Padhye, V. Firoiu, D. Towsley, J. Kurose, Modeling TCP 1137 Throughput: A Simple Model and its Empirical Validation, Tech Report 1138 TF 98-008, U. Mass, February 1998. 1140 [RFC896] Nagle, J., "Congestion Control in IP/TCP", RFC 896, January 1141 1984. 1143 [RFC1890] H. Schulzrinne, RTP Profile for Audio and Video Conferences 1144 with Minimal Control, RFC 1890, January 1996. 1146 [RFC2119] S. Bradner, Key words for use in RFCs to Indicate 1147 Requirement Levels, RFC 2119, 1997. 1149 [RFC2474] K. Nichols, S. Blake, F. Baker, and D. Black, Definition of 1150 the Differentiated Services Field (DS Field) in the IPv4 and IPv6 1151 Headers, RFC 2474, December 1998. 1153 [RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion 1154 Control", RFC 2581, April 1999. 1156 [RFC2597] J. Heinanen et al, Assured Forwarding PHB Group, RFC 2597, 1157 June 1999. 1159 [RFC2914] S. Floyd, Congestion Control Principles, RFC 2914, 1160 September 2000. 1162 [RFC2990] G. Huston, Next Steps for the IP QoS Architecture, November 1163 2000. 1165 [RFC3042] Allman, M., Balakrishnan, H., and Floyd, S., Enhancing 1166 TCP's Loss Recovery Using Limited Transmit, RFC 3042, January 2001. 1168 [RFC3168] K. Ramakrishnan, S. Floyd, and D. Black, The Addition of 1169 Explicit Congestion Notification (ECN) to IP, RFC 3168, September 1170 2001. 1172 [RFC3246] B. Davie et al, An Expedited Forwarding PHB (Per-Hop 1173 Behavior), RFC 3246, March 2002. 1175 [RFC3448] Handley, M., Floyd, S., Pahdye, J., and Widmer, J., TCP 1176 Friendly Rate Control (TFRC): Protocol Specification, RFC 3448, 1177 Proposed Standard, January 2003. 1179 [RSVP] Resource Reservation Setup Protocol (rsvp), Concluded Working 1180 Group, URL "http://www.ietf.cnri.reston.va.us/html.charters/OLD/rsvp- 1181 charter.html". 1183 [RTTWeb] Web Page on Round-Trip Times in the Internet, URL 1184 "http://www.icir.org/floyd/rtt-questions.html" 1186 [S03] H. Schulzrinne, private communication, 2003. 1188 [RFC3551] H. Schulzrinne and S. Casner, RTP Profile for Audio and 1189 Video Conferences with Minimal Control, RFC 3551, July 2003. URL 1190 "ftp://ftp.isi.edu/in-notes/rfc3551.txt". 1192 [Vonage] Vonage, URL "www.vonage.com". 1194 [W98] J. Woodward, Speech Coding, Communications Research Group, 1195 University of Southampton, 1998. URL "http://www- 1196 mobile.ecs.soton.ac.uk/speech_codecs/", 1198 10. Appendix - Sending Rates with Packet Drops 1200 The standard way to estimate TCP's average sending rate S in packets 1201 per round-trip as a function of the packet drop rate would be to use 1202 the TCP response function estimated in [PFTK98]: 1204 S = 1/(sqrt(2p/3) + K min(1,3 sqrt(3p/8)) p (1 + 32 p^2)) (1) 1206 for acks sent for every data packet, and the RTO set to K*RTT. 1208 The results from Equation (1) are given in the second column in 1209 Tables 1 and 2 below. However, Equation (1) overestimates TCP's 1210 sending rate in the regime with heavy packet drop rates (e.g., of 30% 1211 or more). The analysis behind Equation (1) assumes that once a 1212 single packet is successfully transmitted, TCP's retransmit timer is 1213 no longer backed-off. This might be appropriate for an environment 1214 with ECN, or for a TCP connection using fine-grained timestamps, but 1215 this is not necessarily the case for a non-ECN-capable TCP connection 1216 without timestamps. As specified in [RFC2988], if TCP's retransmit 1217 timer is backed-off, this back-off should only be removed when TCP 1218 successfully transmits a new packet (as opposed to a retransmitted 1219 packet), in the absence of timestamps. 1221 When the packet drop rate is 50% or higher, for example, many of the 1222 successful packet transmissions can be of retransmitted packets, and 1223 the retransmit timer can remain backed-off for significant periods of 1224 time, in the absence of timestamps. In this case, TCP's throughput 1225 is determined largely by the maximum backoff of the retransmit timer. 1226 For example, in the NS simulator the maximum backoff of the 1227 retransmit timer is 64 times the un-backed-off value. RFC 2988 1228 specifies that "a maximum value MAY be placed on RTO provided it is 1229 at least 60 seconds." [Although TCP implementations vary, many TCP 1230 implementations have a maximum of 45 seconds for the backed-off RTO 1231 after dropped SYN packets.] 1233 Another limitation of Equation (1) is that it models Reno TCP, and 1234 therefore underestimates the sending rate of a modern TCP connection 1235 that used SACK and Limited Transmit. 1237 The table below shows estimates of the average sending rate S in 1238 packets per RTT, for TCP connections with the RTO set to 2 RTT for 1239 Equation (1). 1241 These estimates are compared with simulations in the third, fourth, 1242 and fifth columns, with ECN, packet drops for TCP with fine-grained 1243 timestamps, and packet drops for TCP without timestamps respectively. 1244 (The simulation scripts are available from 1245 http://www.icir.org/floyd/VoIP/sims.) Each simulation computes the 1246 average sending rate over the second half of a 10,000-second 1247 simulation, and for each packet drop rate, the average is given over 1248 50 simulations. For the simulations with very high packet drop 1249 rates, it is sometimes the case that the SYN packet is repeatedly 1250 dropped, and the TCP sender never successfully transmits a packet. 1251 In this case, the TCP sender also never gets a measurement of the 1252 round-trip time. 1254 The sixth column of Table 1 shows the average sending rate S in 1255 packets per RTT for an experiment using a 4.8-RELEASE FreeBSD 1256 machine. For the low packet drop rates of 0.1 and 0.2, the sending 1257 rate in the simulations is higher than the sending rate in the 1258 experiments; this is probably because the TCP implementation in the 1259 simulations uses Limited Transmit [RFC3042]. With Limited Transmit, 1260 the TCP sender can sometimes avoid a retransmit timeout when a packet 1261 is dropped and the congestion window is small. With high packet drop 1262 rates of 0.65 and 0.7, the sending rate in the simulations is 1263 somewhat lower than the sending rate in the experiments. For these 1264 high packet drop rates, the TCP connections in the experiments would 1265 often abort prematurely, after a sufficient number of successive 1266 packet drops. 1268 We note that if the ECN marking rate exceeds a locally-configured 1269 threshold, then a router is advised to switch from marking to 1270 dropping. As a result, we do not expect to see high steady-state 1271 marking rates in the Internet, even if ECN is in fact deployed. 1273 Drop 1274 Rate p Eq(1) Sims:ECN Sims:TimeStamp Sims:Drops Experiments 1275 ------ ----- -------- -------------- ---------- ----------- 1276 0.1 2.42 2.92 2.38 2.32 0.72 1277 0.2 .89 1.82 1.26 0.82 0.29 1278 0.25 .55 1.52 .94 .44 0.22 1279 0.35 .23 .99 .51 .11 0.10 1280 0.4 .16 .75 .36 .054 0.068 1281 0.45 .11 .55 .24 .029 0.050 1282 0.5 .10 .37 .16 .018 0.036 1283 0.55 .060 .25 .10 .011 0.024 1284 0.6 .045 .15 .057 .0068 0.006 1285 0.65 .051 . .033 .0034 0.008 1286 0.7 .041 .06 .018 .0022 0.007 1287 0.75 .034 .04 .0099 .0011 1288 0.8 .028 .027 .0052 .00072 1289 0.85 .023 .015 .0021 .00034 1290 0.9 .020 .011 .0011 .00010 1291 0.95 .017 .0079 .00021 .000037 1293 Table 1: Sending Rate S as a Function of the Packet Drop Rate p, 1294 for RTO set to 2 RTT, and S in packets per RTT. 1296 The table below shows the average sending rate S, for TCP connections 1297 with the RTO set to 10 RTT. 1299 Drop 1300 Rate p Eq(1) Sims:ECN Sims:TimeStamp Sims:Drops 1301 ------ ----- -------- -------------- ---------- 1302 0.1 0.97 2.92 1.67 1.64 1303 0.2 0.23 1.82 .56 .31 1304 0.25 0.13 .88 .36 .13 1305 0.3 0.08 .61 .23 .059 1306 0.35 0.056 .41 .15 .029 1307 0.4 0.040 .28 .094 .014 1308 0.45 0.029 .18 .061 .0080 1309 0.5 0.021 .11 .038 .0053 1310 0.55 0.016 .077 .022 .0030 1311 0.6 0.013 .045 .013 .0018 1312 0.65 0.010 . .0082 .0013 1313 0.7 0.0085 .018 .0042 1314 0.75 0.0069 .012 .0025 .00071 1315 0.8 0.0057 .0082 .0014 .00030 1316 0.85 0.0046 .0047 .00057 .00014 1317 0.9 0.0041 .0034 .00026 .000025 1318 0.95 0.0035 .0024 .000074 .000013 1320 Table 2: Sending Rate as a Function of the Packet Drop Rate, 1321 for RTO set to 10 RTT, and S in packets per RTT. 1323 11. Security Considerations 1325 This document does not itself create any new security issues for the 1326 Internet community. 1328 12. IANA Considerations 1330 There are no IANA considerations regarding this document. 1332 13. AUTHORS' ADDRESSES 1334 Internet Architecture Board 1335 EMail: iab@iab.org 1337 Internet Architecture Board Members 1338 at the time this document was published were: 1340 Bernard Aboba 1341 Harald Alvestrand (IETF chair) 1342 Rob Austein 1343 Leslie Daigle (IAB chair) 1344 Patrik Faltstrom 1345 Sally Floyd 1346 Jun-ichiro Itojun Hagino 1347 Mark Handley 1348 Geoff Huston (IAB Executive Director) 1349 Charlie Kaufman 1350 James Kempf 1351 Eric Rescorla 1352 Mike St. Johns 1354 This document was created in January 2004.