Network Working Group S. Floyd, Ed.
Request for Comments: 3714 J. Kempf, Ed.
Category: Informational March 2004
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
IAB关注互联网语音流量的拥塞控制
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.
版权所有（C）互联网协会（2004年）。版权所有。
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.
本文档讨论了IAB对互联网上尽力而为语音流量的有效端到端拥塞控制的关注。这些担忧与公平性、用户质量以及拥塞崩溃的危险有关。考虑到互联网上缺乏广泛的服务质量（QoS）部署，以及这种情况在短期内不会发生太大变化的可能性，这些担忧尤其重要。在QoS支持方面，本文档没有对VoIP的部署路径提出任何建议，也没有声称可以依靠尽力而为的服务为VoIP提供可接受的性能。我们只是注意到，语音流量偶尔会作为尽力而为的流量部署在Internet的某些链路上，我们希望这种偶尔的部署会继续下去，并且我们担心这种尽力而为的语音流量缺乏有效的端到端拥塞控制。
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
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. An Example of the Potential for Trouble. . . . . . . . . . . . 4
3. Why are Persistent, High Drop Rates a Problem? . . . . . . . . 6
3.1. Congestion Collapse. . . . . . . . . . . . . . . . . . . 6
3.2. User Quality . . . . . . . . . . . . . . . . . . . . . . 7
3.3. The Amorphous Problem of Fairness. . . . . . . . . . . . 8
4. Current efforts in the IETF. . . . . . . . . . . . . . . . . . 10
4.1. RTP. . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2. TFRC . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.3. DCCP . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.4. Adaptive Rate Audio Codecs . . . . . . . . . . . . . . . 12
4.5. Differentiated Services and Related Topics . . . . . . . 13
5. Assessing Minimum Acceptable Sending Rates . . . . . . . . . . 13
5.1. Drop Rates at 4.75 kbps Minimum Sending Rate . . . . . . 17
5.2. Drop Rates at 64 kbps Minimum Sending Rate . . . . . . . 18
5.3. Open Issues. . . . . . . . . . . . . . . . . . . . . . . 18
5.4. A Simple Heuristic . . . . . . . . . . . . . . . . . . . 19
6. Constraints on VoIP Systems . . . . . . . . . . . . . . . . . . 20
7. Conclusions and Recommendations. . . . . . . . . . . . . . . . 20
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.1. Normative References . . . . . . . . . . . . . . . . . . 21
9.2. Informative References . . . . . . . . . . . . . . . . . 22
10. Appendix - Sending Rates with Packet Drops . . . . . . . . . . 26
11. Security Considerations. . . . . . . . . . . . . . . . . . . . 29
12. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 29
13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 30
14. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 31
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
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.
虽然电话界的许多人认为互联网上的商业VoIP服务需要有效的端到端QoS，但实际上，通过尽力而为的宽带互联网连接提供的语音服务是一种目前需求不断增长的可用服务。虽然一些ISP在其主干网上部署QoS，而一些公司内部网在内部提供端到端QoS，但在当前Internet中，端到端QoS通常不可供客户使用。鉴于目前VoIP在尽力而为的媒体连接上的商业利益，研究实时流对拥塞的潜在影响似乎是谨慎的。在本文件中，我们进行了这样的分析。但是，请注意，本文档并没有就QoS支持方面的VoIP部署路径提出任何建议，也没有声称可以依靠尽力而为的服务为VoIP提供可接受的性能。本文档也不讨论VoIP的信令连接。然而，语音流量实际上偶尔会作为尽力而为的流量部署在互联网的某些链接上，我们预计这种偶尔的部署会继续下去。本文件表达了我们对这种尽力而为的语音通信缺乏有效的端到端拥塞控制的担忧。
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
假设通过尽力而为的互联网连接的VoIP继续在宽带连接的消费者中流行，那么在公共ISP中部署端到端QoS机制可能会很慢。IETF已经为互联网中的QoS机制制定了标准[DIFFSERV，RSVP]，并继续活跃在这一领域[NSIS，COPS]。然而，需要改变互联网基础设施的技术的部署受到广泛的商业影响
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.
此外，技术方面的考虑因素以及可以在不改变基础设施的情况下进行部署的技术在部署速度方面具有相当大的优势。RFC 2990概述了在Internet中部署QoS体系结构的一些技术挑战[RFC2990]。通常，为快速增长的应用程序提供支持的临时措施被采用，并且在满足普遍部署更具破坏性的技术的压力降低的需求方面足够成功。有许多基础设施部署缓慢的例子，类似于QoS机制（包括IPv6、IP多播或用于IKE和IPsec支持的全局PKI）的缓慢部署。
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.
最容易部署的临时QoS措施包括单个拥塞链路上VoIP流量的单跳或仅边缘QoS机制，例如电缆接入网络的仅边缘QoS机制。这种本地形式的QoS可以非常成功地保护部分尽力而为的VoIP流量免受拥塞。但是，端到端VoIP连接无法直接看到这些本地形式的QoS。尽力而为的VoIP连接可能会经历高的端到端数据包丢弃率，并与其他尽力而为的流量竞争，即使路径上的某些链路可能具有单跳QoS机制。
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.
除了专用IP网络的其他部署方案外，IP电话的部署可能包括到公共接入网络的尽最大努力的宽带连接，或者作为ADSL部署最后一英里上的频带分裂或有线接入网络上的QoS机制的替代方案。已经存在一种快速扩展的VoIP服务部署，旨在通过住宅宽带接入链路（例如，[FWD，Vonage]）运行。目前，许多公共接入IP网络在核心没有阻塞，链路利用率低或中等，但在最后一跳链路上不一定如此。如果IP电话呼叫完全在Internet上运行，则连接可以很容易地穿越两端拥挤的链路。由于经济因素，互联网电话的增长率可能在发展中国家最高，因为这些国家的核心链路更容易出现拥塞，这使得拥塞控制成为发展中国家特别重要的课题。
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
考虑到IP电话可能在拥挤的尽力而为网络上部署，一些人担心由于实时语音通信量的快速增长而导致拥塞崩溃的可能性，而实时语音通信量不实行端到端拥塞控制。本文件对公平性、用户质量以及尽力而为网络上尽力而为的电话流量的快速增长可能导致的拥塞崩溃的危险提出了一些担忧。我们考虑具有最小发送速率的尽力电话连接。
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.
本文档中关于公平性和拥塞崩溃危险的关注不仅适用于电话流量，也适用于视频流量和其他具有最小发送速率的尽力而为实时流量。RFC 2914已经指出，尽力而为的流量需要端到端的拥塞控制[RFC2914]。由于音频流量相对于视频和其他实时流量的发送速率如此之低，因此有时有人声称音频流量不需要端到端拥塞控制。因此，虽然本文档中的关注点是一般性的，但本文档重点关注尽力而为的音频流量这一特定问题。
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].
反馈可发送至IAB邮件列表，地址为iab@ietf.org，或向floyd@icir.org和kempf@docomolabs-美国网站。反馈也可发送至End2 End interest邮件列表[E2E]。
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.
2002年11月，IEPREP工作组在亚特兰大召开会议，在美国佐治亚州亚特兰大市和肯尼亚内罗毕市的一家酒店房间之间的共享链路上，对VoIP进行了简短演示。该链路通过典型的未阻塞的Internet主干网，并接入到任一端点和Internet主干网之间的对等点的链路。通话的语音质量非常好，特别是与内罗毕的电路交换通话的典型质量相比。伴随演示的演示文稿将接入链路（例如DSL、T1、T3、拨号和电缆调制解调器链路）描述为网络拥塞的主要来源，并将VoIP通信量描述为商业ISP通信量中数据包的很小百分比[A02]。该演示进一步指出，VoIP在丢包率为5-40%[AUT]的情况下获得了良好的质量。VoIP呼叫使用了ITU-T G.711编解码器，加上专有的FEC编码，再加上RTP/UDP/IP帧。由此产生的互联网流量负载远远超过编解码器所需的64 kbps。演示路径上的主要拥塞点是肯尼亚的一家ISP与其内罗毕的几家订户之间的128 kbps接入链路。因此，单个VoIP呼叫消耗了超过一半的接入链路容量，这些容量由多个不同的用户共享。
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
请注意，对于VoIP来说，这种网络配置不是特别好。特别是，如果有数据服务在典型数据包大小为1500字节的链路上运行TCP，则某些语音
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.
数据包可能再延迟90毫秒，这可能导致端到端延迟增加，超过ITU建议的150毫秒语音通信时间[G.114]。这将导致用户明显的延迟，随着突发TCP流量的来来往往，延迟的变化会增加，因此通话质量也会增加。对于已经具有高延迟的呼叫，例如上一段中的内罗毕呼叫，由于竞争TCP流量而增加的抖动也增加了对接收器处抖动缓冲区的要求。尽管如此，在拥挤的尽力而为的链路上，VoIP的使用率在不久的将来可能会增加，而不管VoIP在“运营商级”服务中的优异性能如何。面对40%的丢包率，最大努力的VoIP连接持续以64 Kbps的速率发送数据包，消耗128 Kbps访问链路的一半，并由此导致用户可感知的语音质量下降，其行为方式不符合VoIP用户或网络其他并发用户的利益。
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.
有两种可能的机制可以避免这种拥塞崩溃：繁忙期间的呼叫拒绝，或使用端到端拥塞控制。由于目前互联网上没有尽力而为流量的接受/拒绝机制，因此唯一的替代方案是使用端到端拥塞控制。即使端到端拥塞控制仅在通常未阻塞的接入链路或网络中出现拥塞的极少数情况下调用，这一点也很重要。偶尔会出现高需求，例如地震或其他灾难后的两个小时内，这正是避免拥堵崩溃的重要时刻。
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.
Internet上的尽力而为流量不包括接受或拒绝呼叫的机制。相反，尽力而为网络本身在资源管理方面基本上是中性的，应用程序传输会话的交互以合理公平的方式相互调节网络资源。以无中断方式将语音引入尽力而为环境的一种方法是关注编解码器，并研究能够与现有传输协议（如TCP）成功互操作的速率自适应措施，同时保持实时模拟语音信号的完整性；另一种方法是考虑具有固定发送速率的编解码器。编解码器是否具有固定的或可变的发送速率，当编解码器处于最小数据速率时，我们考虑适当的响应，并且流所经历的分组丢弃率仍然很高。这是本文件所述的关键问题。
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.
在没有路由故障或其他重大中断的情况下，持续的高数据包丢失率在今天的互联网上是很少见的。这种令人高兴的情况主要是由于核心链路利用率低，通常在低容量访问链路上出现拥塞，以及TCP中使用端到端拥塞控制。如今，互联网上的大多数流量都使用TCP，TCP会进行自我更正，以便在检测到拥塞时，连接的两端可以降低数据包发送的速率。在下面的部分中，我们将讨论由持续的高丢包率引起的一些问题。
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].
持续的高丢包率可能导致的一个问题是拥塞崩溃。拥塞崩溃最早出现在20世纪80年代中期互联网的早期发展阶段[RFC896]，修复方案由Van Jacobson提供，他开发了TCP实现中现在需要的拥塞控制机制[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
如RFC 2914中所述，当流量穿越多个拥塞链路且具有持续的高丢包率时，网络中会发生拥塞崩溃[RFC2914]。特别是，在这种情况下，注入拥塞链路的数据包浪费了稀缺的带宽，因为这些数据包只是稍后在下游拥塞链路上丢弃。如果发生拥塞崩溃，所有流量都会缓慢爬行，没有人能够获得可接受的数据包交付或可接受的性能。由于这种形式的拥塞崩溃只会发生在穿越多个拥塞链路的流中，因此拥塞崩溃是一种严重的问题
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.
VoIP网络中的潜在问题：当VoIP呼叫的两端都位于拥挤的宽带连接（如DSL）上，或者当呼叫穿过拥挤的主干或跨洋链路时。
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.
持久的、高丢包率的第二个问题涉及最终用户看到的服务质量。考虑一个网络场景，其中每个流只遍历一个拥塞链路，正如上面内罗毕演示中的情况。例如，假设N个VoIP流共享128 Kbps链路，每个流至少发送64 Kbps。为简单起见，假设128kbps链路是唯一的拥塞链路，并且除了N个VoIP呼叫之外，该链路上没有其他通信量。我们还将暂时忽略FEC和数据包头的电话流量所使用的额外带宽，或者由于静音抑制而减少的带宽（通常估计为70%）。我们还忽略了一个事实，即构成双向VoIP呼叫的两个流（每个方向一个）实际上会增加路径某些链路上的负载。根据这些简化的假设，该链路的到达率至少为N*64 Kbps。实际转发的流量最多为2*64 Kbps（链路带宽），因此必须丢弃至少（N-2）*64 Kbps的到达流量。因此，至少（N-2）/N的到达业务的一部分被丢弃，并且每个流平均接收链路带宽的一部分1/N。需要注意的一个重要点是，下降是随机发生的，因此从统计上看，没有一个流量能够比其他流量向用户提供更好的服务质量。因此，每个人的声音质量都会受到影响。
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.
从这个简单的示例中可以清楚地看出，如果每个VoIP流使用端到端拥塞控制，并且具有能够根据该流实际接收的带宽调整比特率的编解码器，则拥塞链路上尽力而为的VoIP流量的质量可以得到改善。这些措施的总体效果是降低总分组丢弃率，从而改善链路上所有VoIP用户的语音质量。今天，互联网电话的应用程序和流行的编解码器试图通过使用更多的FEC进行补偿，但直接控制数据包流量应该会减少冗余FEC信息，从而减少带宽，从而进一步提高吞吐量。文献[JS00、JS02、JS03、MTK03]详细研究了FEC存在时延迟和数据包丢失对VoIP的影响。一条经验法则是，当数据包丢失率超过20%时，VoIP的音频质量会降低到无法使用的程度，部分原因是丢失的突发性[S03]。我们不知道在实践中，当数据包丢失率超过某个限制时，VoIP用户是否会挂断电话。
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.
本节中的简单示例仅考虑语音流，但实际上，VoIP流量将与其他流竞争，最有可能是TCP。VoIP流量对拥塞的响应最好是考虑TCP的拥塞控制响应，这将在下一小节中讨论。
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.
持久的、高丢包率的第三个问题是公平性。在这篇文章中，我们考虑公平性方面的尽力而为的VoIP流量竞争与其他尽力而为的流量在互联网上。也就是说，我们没有明确地解决紧急服务或QoS支持的流量引起的问题，这些流量已知与拥塞链路上的尽力而为流量分开处理。
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.
虽然公平性有点难以量化，但我们可以通过将TCP流量添加到上一节讨论的拥塞链路来说明这种效果。在这种情况下，非拥塞控制流量和拥塞控制TCP流量[RFC2914]共享链路，拥塞控制流量的发送速率由这些流经历的分组丢弃速率确定。如前一节所述，128 Kbps链路有N个VoIP连接，每个连接发送64 Kbps，导致拥塞链路上的丢包率至少为（N-2）/N。竞争的TCP流将经历相同的丢包率。但是，经历相同丢包率的TCP流将发送远小于64 Kbps的数据。从谁获得多少带宽的角度来看，VoIP流量正在挤出TCP流量。
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.
当然，这只是看待公平的一种方式。VoIP和TCP流量之间的相对公平性可以通过几种不同的方式来观察，这取决于对数据包大小和往返时间的假设。例如，在存在固定分组丢弃率的情况下，具有较大分组的TCP流比具有较小分组的TCP流发送更多（以Bps为单位，字节/秒），并且具有较短往返时间的TCP流比具有较大往返时间的TCP流发送更多（以Bps为单位）。在具有高丢包率的环境中，TCP的发送速率也取决于设置重传计时器（RTO）的算法，具有更积极RTO设置的TCP实现比具有较少积极RTO设置的TCP实现发送更多的数据。
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].
不幸的是，没有明显的标准往返时间来判断网络中流的相对公平性。文献中一致认为，网络中大多数链路上的大多数数据包的往返时间在10到500毫秒之间[RTTWeb]。
(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.
（这不包括卫星链路）因此，如果有一个标准的往返来判断相对公平性，它必须在该范围内。在没有一个代表性往返时间的情况下，本文的假设是合理的考虑VoIP连接和TCP连接之间的公平性相同的往返时间。
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.
类似地，没有标准的数据包大小来判断TCP连接之间的相对公平性。然而，因为TCP数据包最常见的数据包大小是1460字节[测量]，所以我们假设合理地考虑VoIP连接之间的公平性，以及发送1460字节数据包的TCP连接。请注意，1460字节比VoIP数据包通常使用的字节大得多。
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.
同样，虽然RFC 2988指定了TCP设置TCP RTO的算法，但最小RTO没有标准值，并且最小RTO在高拥塞时严重影响TCP的发送速率[RFC2988]。RFC 2988规定TCP的RTO必须设置为SRTT+4*RTTVAR，SRTT为平滑往返时间，RTTVAR为最近往返时间测量的平均偏差。RFC 2988进一步规定RTO“应”具有1秒的最小值。然而，TCP实现的最小RTO低至100 ms在实践中并不少见。出于本文档的目的，在考虑相对公平性时，我们将假设最小RTO为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.
另外，在数据包丢弃率较高的环境中，使用细粒度时间戳的TCP连接可能比不使用时间戳的TCP连接具有更高的发送速率。对于具有细粒度时间戳的TCP连接，当接收器成功接收并确认重传的数据包时，可获得有效的往返时间测量值；在这种情况下，也可以取消后退的重新传输计时器。对于没有时间戳的TCP连接，只有当接收器接收并确认新数据包的传输时，才能获得有效的往返时间测量值。这限制了取消取消取消已取消的重新传输计时器的机会。在本文中，考虑到相对公平性，我们使用无时间戳的TCP连接，因为这是TCP在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,
有时从公平性角度提出的另一种说法是，尽力而为的VoIP流量本质上比其他尽力而为的流量（例如，网络冲浪、对等流量或多人游戏）更重要，因此在高拥塞情况下需要更大的带宽份额。我们在本文档中的假设是，TCP流量包括发送电子邮件，
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.
商业文件、从网页下载的紧急信息，以及上述更具娱乐性的用途。因此，我们不同意尽力而为的VoIP流量因其固有价值更高的内容而免于端到端拥塞控制。（人们同样可以从逻辑上说，由于电子邮件和即时消息在带宽使用方面比VoIP更有效，因此电子邮件和即时消息在高拥塞时对稀缺带宽的利用更为宝贵。）事实上，网络无法对流量的相对用户价值做出判断。默认假设是，所有尽力而为的流量对网络提供商和用户都具有相同的价值。
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.
我们注意到，这种对相对公平性的讨论并没有以任何方式挑战ISP在拥塞链路上以其选择的任何方式将带宽分配给流量类别的权利。（例如，管理员对网络中某些链路上的点对点流量使用的带宽进行了限制，以确保带宽也可用于其他类别的流量。）本讨论仅认为，没有理由对所有类别的尽力而为流量免除端对端拥塞控制。
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.
IETF目前正在进行四项工作，以解决实时流量的拥塞控制问题：RTP规范、TFRC、DCCP的升级，以及音频编解码器的工作。
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:
用于音频和视频控制的原始RTP配置文件RFC1890没有讨论拥塞控制[RFC1890]。关于“具有最小控制的音频和视频会议的RTP配置文件”[RFC3551]的修订文件在第2节中讨论了拥塞控制。[RFC3551]说明如下：
"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."
“如果正在使用尽力而为服务，RTP接收器应监控数据包丢失，以确保数据包丢失率在可接受的参数范围内。如果通过相同网络路径并经历相同网络条件的TCP流能够达到在合理的时间尺度上测得的平均吞吐量，则认为数据包丢失是可接受的at不小于正在实现的RTP流。可以通过实施拥塞控制机制来适应传输速率（或分层多播会话订阅的层数），或者如果丢失率高得令人无法接受，则通过安排接收器离开会话来满足此条件。”
"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."
“无法准确指定与TCP的比较，但其目的是作为时间尺度和吞吐量的“数量级”比较。测量TCP吞吐量的时间尺度是连接的往返时间。本质上，此要求表明部署应用程序是不可接受的（使用RTP或任何其他传输协议）在尽力而为的互联网上，任意消耗带宽，在一个数量级内与TCP不公平竞争。”
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.
注意，[RFC3551]说接收器“应该”监视数据包丢失。[RFC3551]没有明确指出RTP发送方和接收方“必须”检测并响应持续的高丢失率。由于拥塞崩溃可被视为“对互联网的危险”，因此“必须”的使用将适用于尽力而为互联网中的RTP流量，其中VoIP流量与其他流量共享链路，因为“对互联网的危险”是RFC 2119中给出的使用“必须”的两个标准之一[RFC2119]。对于仅为VoIP配置的专用尽力而为IP网络，可能存在不同的要求，其中VoIP流量不与更广泛的Internet交互。
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:
如RFC3267所述，基于等式的拥塞控制是VoIP的一种可能性。TCP友好速率控制（TFRC）是IETF中标准化的基于等式的拥塞控制机制。TFRC规范“TCP友好速率控制（TFRC）：协议规范”[RFC3448]说明如下：
"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."
“TFRC…在与TCP流竞争带宽时相当公平，但与TCP相比，吞吐量随时间的变化要小得多，使其更适合于相对平稳的发送速率非常重要的应用程序，如电话或流媒体…TFRC专为使用固定数据包大小的应用程序而设计，并更改其发送速率（以每秒数据包数表示），以响应拥塞。某些音频应用程序需要数据包之间的固定时间间隔，并更改其数据包大小，而不是更改其数据包速率以响应拥塞。这些应用程序无法使用本文档中的拥塞控制机制；TFRC-PS（对于TFRC PacketSize）是TFRC的一个变体，适用于具有固定发送速率但因拥塞而改变其数据包大小的应用程序。TFRC-PS将在稍后的文档中指定。”
There is no draft available for TFRC-PS yet, unfortunately, but several researchers are still working on these issues.
不幸的是，TFRC-PS还没有可用的草案，但一些研究人员仍在研究这些问题。
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）是IETF中针对不可靠流标准化的传输协议，应用程序能够指定TCP类或TFRC拥塞控制[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.
DCCP目前有两个拥塞控制标识符或CCID；它们是用于TCP类拥塞控制的CCID 2和用于TFRC拥塞控制的CCID 3。随着TFRC-PS可用并通过标准流程，我们希望DCCP创建一个新的CCID，CCID 4，用于TFRC-PS拥塞控制。
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.
任何实时应用程序设计中的一个关键组件是选择适当的编解码器，特别是在低发送速率下运行的编解码器，或随着吞吐量降低和/或数据包丢失增加而降低发送速率的编解码器。如果没有这一点，并且没有本文档中建议的拥塞响应，实时应用程序可能会显著增加Internet拥塞崩溃的风险，从而对部署的Internet的健康状况产生不利影响。如果编解码器能够降低其比特率以响应拥塞，则这将改进能够共享拥塞链路的VoIP或TCP会话的数量的缩放，同时仍然为用户提供可接受的性能。许多当前的音频编解码器能够以低比特率发送，在某些情况下，根据来自网络的拥塞指示调整其发送速率。
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].
RFC3267描述了用于自适应多速率（AMR）和自适应多速率宽带（AMR-WB）音频编解码器的RTP有效载荷格式[RFC3267]。AMR编解码器支持比特率在4.75和12.2 kbps之间的八种语音编码模式，在20 ms语音帧上执行语音编码，并且能够在静默期间降低传输速率。RFC 3267中指定的有效载荷格式包括前向纠错（FEC）和帧交织，以在一定程度上提高对分组丢失的鲁棒性。第三代合作伙伴计划（3GPP）选择AMR编解码器作为第三代（3G）蜂窝系统的强制性编解码器，RFC 3267建议使用RFC 3267中指定的RTP有效负载格式的AMR或AMR-WB应用程序使用拥塞控制，但不建议使用特定机制。RFC 3267给出了“单播应用的基于等式的拥塞控制”，作为适用于实时流的拥塞控制机制的示例[FHPW00]。
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.
“互联网低比特率编解码器”iLBC是IETF的一项工作，旨在开发一种无知识产权的编解码器，用于通过IP进行稳健的语音通信[ILBRC]。编解码器设计用于在丢失数据包的情况下降低语音质量，30毫秒帧的有效负载比特率为13.33 kbps，20毫秒帧的有效负载比特率为15.20 kbps。
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.
Ivox（交互式语音交换）[Ivox]中有几种无阻碍的低速编解码器算法，并计划添加额外的可变速率编解码器。例如，LPC2400（又称LQ2400）是一种基于2400 bps LPC的编解码器，具有允许“静音检测”的增强功能。据报道，2400 bps编解码器具有“轻微的机器人质量”[A03]（即使没有额外的丢包并发症）。[KKK79，KF82]中描述的较旧的多速率编解码器是一种LPC编解码器，它以2.4 kbps和9.6 kbps两种速率工作，并且可以选择以更高的比特率发送额外的“剩余”比特以提高质量。
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.
现成的ITU-T声码器（如G.711）通常是专门为电路交换网络设计的，即使在顶部添加了FEC，也不能很好地适应互联网的使用。
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.
2003年结束的区分服务工作组[DIFFSERV]完成了IPv4和IPv6报头[RFC2474]中区分服务字段（DS字段）的标准，包括若干每跳转发行为[RFC2597，RFC3246]。信令工作组[NSIS]的下一步是开发一个用于QoS的优化信令协议，部分基于资源预留设置协议工作组[RSVP]的早期工作。在本文档中，我们不会进一步讨论这些和相关的工作，因为本文档只关注可能作为尽力而为的流量通过Internet中的某个拥塞链路传输的VoIP流量。
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.
当前的IECF工作在DCCP和AVT工作组中没有考虑到具有最小发送速率的应用的问题，并且不能低于该发送速率。TFRC-PS草案中必须明确说明这一点。正如RTP文档中所建议的，如果丢失率相对于当前发送率持续高得令人无法接受，并且尽力而为应用程序无法降低其发送率，那么唯一可接受的答案是该流停止该链路上的发送。对于多播会话，这可以通过接收方从多播组中退出来实现。对于单播会话，这可以通过单播连接终止来实现，至少在一段时间内。
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?
我们可以用下面的方法来描述最小发送速率的问题。考虑尽最大努力的自适应音频应用程序，该应用程序能够适应应用数据的N个BPS（字节/秒）的最小发送速率，每秒发送M个分组。这是否是一个足够低的发送速率，使得尽力而为流永远不会因为拥塞而终止，或者进一步降低其发送速率（以每秒数据包为单位）？换句话说，N Bps是否是应用程序可接受的最小发送速率，在遇到拥塞时可以继续，而不终止或暂停应用程序？
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.
对于VoIP，我们假设网络的限制是以每秒字节数（Bps）为单位的带宽，而不是CPU周期或每秒数据包数（pps）。如果网络中的限制是带宽，这是Bps中的限制，而如果限制是路由器处理数据包的能力，这将是pps中的限制。我们注意到，TCP发送固定大小的数据包，并在适应网络拥塞时降低其在pps中的发送速率，从而减少Bps和pps中转发路径上的负载。相比之下，对于自适应VoIP应用程序，自适应有时是为了在pps中保持相同的发送速率，但要减小数据包大小，降低以Bps为单位的发送速率。这适合作为应用程序的音频需求，并且在限制为Bps的网络路径上是一个很好的响应。对于限制在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.
如果网络限制实际上是以Bps为单位的，那么就拥塞而言，最重要的是以Bps为单位的数据流在线路上的发送速率。如果Bps中的网络限制假设是错误的，那么即使Bps中的发送速率相当温和，pps中的发送速率也可能导致拥塞。虽然理想的传输协议能够检测路径上的瓶颈链路是否在Bps或pps中受到限制，并在限制在pps中时做出适当响应，但这样的理想很难实现。我们不想推迟对电话业务的拥塞控制部署，直到实现这样一个理想。此外，我们注意到，当前的TCP拥塞控制机制本身在pps中沿反向路径存在限制的环境中不是非常有效。虽然TCP机制确实提供了使用大数据包的激励，但TCP不包括任何有效的拥塞控制机制，用于反向路径上的小确认包流。鉴于上述论点，在考虑电话流量的最小发送速率时，我们似乎可以接受以Bps为单位而不是以pps为单位的网络限制。
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.
假设40字节的数据包头（IP、RTP和UDP或DCCP），N Bps和M pps的应用程序数据发送速率转换为B=N+40M Bps的传输速率。如果应用程序使用额外的FEC（前向纠错），则还必须添加FEC位。在我们的示例中，我们忽略了带宽调整，这些带宽调整需要考虑FEC的额外开销或静默期的降低发送速率。我们也没有考虑在拥挤的边缘链路上头部压缩的可能作用，这可以显著减少这些链路上用于头部的字节数。
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).
现在，考虑一个等效速率TCP连接与数据字节的P字节和往返时间的R秒。考虑到报头大小，这种在Bps线路上具有发送速率的TCP连接正在发送B/（P+40）pps，或者，等效地，BR/（P+40）ppr（每往返时间的分组）。
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?
根据VoIP和TCP的上述表达式重申该问题：如果尽力而为的VoIP连接正在经历持续的数据包丢失率D，并且在B Bps的线路上处于其最低发送速率，那么应用程序或传输协议应在何时终止或暂停VoIP连接？
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.
这个问题的一个答案是在ppr中查找TCP连接的发送速率，该连接在Bps中以相同的速率在线路上发送，以及使用TCP响应函数来确定一致性TCP连接是否能够以相同的持续丢弃率D保持接近该发送率的发送率。如果VoIP连接的发送率显著高于相同条件下一致性TCP连接的发送率，并且VoIP连接无法降低其在导线上的发送速率，则VoIP连接应终止或挂起。
As discussed above, there are two reasons for requiring the application to terminate:
如上所述，要求终止申请有两个原因：
1) Avoiding congestion collapse, given the possibility of multiple congested links,
1) 避免拥塞崩溃，考虑到多个拥塞链路的可能性，
2) Fairness for congestion-controlled TCP traffic sharing the link.
2) 共享链路的拥塞控制TCP流量的公平性。
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.
此外，如果应用程序需要来自网络的最低服务级别才能运行，并且始终未达到该服务级别，则应用程序应终止或暂停发送。
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.
一个相反的论点是，用户无论如何都会挂断高丢包率，所以强制执行最低可接受速率是没有意义的。用户可能会挂断电话，但他们也可能只是继续交谈，偶尔会发出噪音，等待几分钟或更长的时间，等待一小段时间的澄清。另一个反论点是，当持续丢包率超过配置的最小发送速率的允许丢包率时，没有人真正从终止或挂起VoIP连接中获益。这是不真实的，因为这些VoIP连接的终止可能会使相互竞争的TCP和VoIP流量取得一些进展。
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.
在下一节中，我们将说明上述用于VoIP流量的方法，最低发送速率分别为4.75和64 kbps，并表明在实践中，这种方法对于VoIP流量似乎不会太繁重。这种方法意味着，对于最小发送速率为4.75 kbps的VoIP流，当丢包率显著超过40%时，VoIP流量将终止或暂停。如果VoIP要在尽力而为的链路上提供“载波质量”甚至接近“载波质量”，那么在持续丢包率超过40%的情况下保持最大发送速率的能力限制部署并不意味着服务模式将在消费者中得到广泛接受，无论价格差异有多大。良好的数据包吞吐量对于提供可接受的VoIP服务至关重要。
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].
对于由于其最小发送速率对于稳态丢包速率来说过高而停止发送的VoIP流，我们没有解决VoIP流何时能够再次开始发送的问题，以查看端到端路径上的拥塞是否发生了变化。这一问题已在概率拥塞控制（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.
我们注意到，如果拥塞指示是以ECN标记的数据包（显式拥塞通知）的形式，而不是丢弃的数据包，那么关于具有最小发送速率的流何时必须停止发送的答案会有所不同。ECN允许路由器通过ECN标记明确通知终端节点拥塞，而不是丢弃数据包[RFC3168]。如果数据包被ECN标记而不是丢弃在网络中，那么就不存在拥塞崩溃或用户质量问题（对于支持ECN的流量，无论如何），剩下的是对竞争流的公平性问题。其次，在拥塞非常严重的情况下，TCP使用ECN标记的发送速率高于丢弃的数据包，部分原因是在取消后退的重新传输计时器方面存在不同的动态。
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.
考虑具有R＝0.1秒的RTT的自适应音频应用，该应用能够适应4.75 kbps应用数据的最小发送速率，每秒发送m＝20个分组。此发送速率转换为N=593 Bps的应用程序数据，即B=1393 Bps的网络发送速率。具有P=1460字节数据包和R=0.1秒往返时间的等效速率TCP连接将发送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.
附录中的表1查看了RTO设置为RTT两倍的TCP连接的丢包率，并给出了ppr中TCP连接的相应发送速率。第二列给出了标准分析方法估计的发送速率，第三、第四和第五列给出了随机丢包或标记模拟的平均发送速率。第六列给出了在4.8版本FreeBSD机器上进行的实验的发送速率。分析方法需要RTO表示为RTT的倍数，表1显示了RTO设置为2 RTT的结果。在模拟中，最小RTO设置为RTT的两倍。有关更多详细信息，请参见附录。
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%.
对于0.09 ppr的发送速率和设置为2 RTT的RTO，表1显示，分析方法给出了大约50%的相应丢包率，而第五列中的模拟和第六列中的实验给出了35%到40%之间的丢包率，以保持0.09 ppr的发送速率。（对于使用时间戳的参考TCP连接，如第四列所示，模拟给出了55%的丢包率，以保持0.09 ppr的发送率。）确定发送率和丢包率之间TCP关系的两种方法中，分析方法和模拟的使用，由于附录中讨论的原因，我们认为模拟是最现实的。这表明，对于平均发送速率为0.09 ppr的TCP连接，40%的丢包率是合理的。因此，当持续数据包丢失率显著超过40%时，需要终止或挂起RTT为0.1秒、最小发送速率为4.75 kbps的VoIP连接。
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
这些估计对TCP连接的假定往返时间很敏感。如果我们假设等效速率TCP连接的往返时间为R=0.01秒，则等效速率TCP连接将发送BR/（P+40）=0.009 ppr。然而，我们还假设TCP连接的最小RTO为0.1秒，在本例中，这意味着RTO至少为10 RTT。对于RTO的这种设置，我们将使用附录中的表2来确定特定数据包的平均TCP发送速率
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.)
下降率。表2第五列中的模拟表明，RTT为0.01秒、RTO为10 RTT的TCP连接能够以45%的丢包率发送0.009 ppr。（对于使用时间戳的相同TCP连接，如第四列所示，模拟给出了60-65%的丢包率，以保持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%.
因此，对于RTT为0.01秒且最小发送速率为4.75 kbps的VoIP连接，当持续丢包率超过45%时，VoIP连接需要终止或挂起。
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%.
将最小可接受发送速率增加到64 kbps的效果是有效地降低应用程序终止或暂停发送时的丢包率。对于这一部分，考虑编解码器的最小发送速率为64 kbps，或n＝8000个bps，以及m＝50 pps的分组发送速率。（这相当于160字节的数据包，每个数据包20毫秒。）线路上的发送速率为B=N+40M Bps，包括报头，或10000 Bps。具有该发送速率的TCP连接（数据包大小为P=1460字节，往返时间为R=0.1秒）发送BR/（P+40）=0.66 ppr。从表1的第五列可以看出，对于2RTT的RTO，这对应于20%到25%之间的丢包率。[对于使用细粒度时间戳的TCP连接，如表1第四列所示，该发送速率对应于25%到35%之间的丢包率。]，当持续数据包丢失率显著超过25%时，要求RTT为0.1秒且最小发送速率为64 kbps的VoIP连接终止或挂起。
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%.
对于往返时间为R=0.01秒且最小RTO为0.1秒（RTO为10 RTT）的等效速率TCP连接，我们使用表2的第五列，该列显示0.066 ppr的发送速率对应约30%的丢包率。[对于使用细粒度时间戳的TCP连接，如表2第四列所示，该发送速率对应于约45%的丢包率。]因此，对于RTT为0.01秒且最小发送速率为64 kbps的VoIP连接，当持续数据包丢失率超过30%时，将需要终止或挂起VoIP连接。
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
本文档不尝试指定完整的协议。例如，本文档没有指定持久数据包丢弃率的定义。假设是
"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.
“持续丢包率”是指在相当多的往返时间内（例如，至少5秒）的丢包率。另一种可能性是，测量持续下降率的时间间隔是连接寿命的函数，寿命较长的连接使用更长的时间间隔测量持续下降率。
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.
检测持续拥塞的时间段也会影响VoIP会话的潜在同步，所有会话都会因共享拥塞而同时终止或挂起。如果流在设置用于检测持续拥塞的时间间隔时使用一些随机化，或者使用作为连接生存期函数的时间间隔，这可能有助于防止所有VoIP流同时终止。
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.
本文档的建议是，具有最小发送速率的VoIP流应具有相应的配置分组丢弃速率，以便当流的持久分组丢弃速率超过配置速率时，流终止或挂起。如果持久数据包丢弃率随时间增加，则具有较高最低发送速率的流必须在具有较低最低发送速率的流之前暂停发送。如果VoIP流在持久分组丢弃率过高时终止，这可能导致具有较低最低发送速率的VoIP流基本上接收所有链路带宽，而具有较高最低发送速率的VoIP流则需要终止。然而，如果VoIP流在持久分组丢弃率过高时暂停发送一段时间，而不是完全终止，那么带宽最终可能在具有不同最小发送速率的VoIP流之间合理公平地共享。
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.
估计拥塞的一个简单启发式方法是使用RTCP报告的丢失率作为指标。例如，如果RTCP报告的丢失率大于30%，或者缺少N个背对背RTCP报告，则应用程序可能认为网络过于拥挤，并终止或暂停发送。
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.
最终，尝试在拥挤的链路上运行VoIP，即使使用自适应速率编解码器和最小数据包速率，也可能由于严重拥挤场景中实时流量的性质而遇到困难。VoIP系统显示出扩展其数据包速率的有限能力。如果包的数量减少，则每个包的音频量更大，并且接收器处的错误隐藏变得更困难。任何超过音素长度的错误（根据音素和扬声器的不同，通常为40到100毫秒）都是不可恢复的。理想情况下，应用程序需要小于30ms的数据包，这是大多数语音编解码器提供的。此外，语音媒体流在较低的数据速率下表现出更大的丢失敏感性。较低的数据速率编解码器保持更多的端到端状态，因此通常对丢失更敏感。
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.
我们注意到，在极低带宽、高噪声环境（例如，2.4kbps高频无线电）中，极低比特率编解码器被证明是有用的，尽管性能有所下降。例如，2.4kbps编解码器“产生的语音虽然可理解，但却远不是自然的声音”[W98]。[W98]的图5显示了几种形式的编解码器的语音质量如何随编解码器的比特率而变化。
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.
在短期内，VoIP服务可能会通过宽带尽力而为的连接部署（至少部分部署）。当前的实时媒体编码和传输实践忽略了拥塞考虑，如果VoIP在近中期内成为广泛部署的服务，则可能会出现问题。用户质量差、对其他VoIP和TCP用户不公平以及偶尔发生拥塞崩溃的可能性是该场景中的一些潜在问题。
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.
在使用固定速率编解码器的应用程序中，可以通过要求尽力而为的VoIP应用程序指定其最小比特吞吐量来缓解这些问题。该最小比特率可用于估计应用程序终止时的分组丢弃率。
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.
(1) 在IETF关于具有最小发送速率的尽力而为流的协议标准中，必须指定数据包丢弃率，以便当稳态数据包丢弃率显著超过指定的丢弃率时，尽力而为流终止或暂时暂停发送。
(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.
(2) 最小发送速率的指定丢弃速率应与本文件中表1和表2的使用一致。
We note that this is a recommendation to the IETF community, as a specific follow-up to RFC 2914 on Congestion Control Principles.
我们注意到，这是向IETF社区提出的建议，作为RFC 2914拥塞控制原则的具体后续行动。
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.
能够根据拥塞估计改变比特率的编解码器在高负载条件下提供高质量服务，同时保持网络效率方面更为有效。因此，自适应可变比特率编解码器更适合作为支持共享使用互联网环境上VOIP会话的一种手段。
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.
实时流量（如VoIP）可以从ECN的使用中获得显著的好处，在ECN中，路由器可以通过标记数据包而不是丢弃数据包来指示终端节点的拥塞。然而，ECN仅被标准化为与传输协议一起使用，传输协议对作为拥塞指示的标记数据包做出适当反应。遵循本文档中建议的VoIP流量可以满足使用ECN的拥塞控制要求，而当数据包丢弃和标记率过高时，没有终止或挂起机制的VoIP流量则无法满足。但是，我们重申，本文档不是一个完整的协议规范。特别是，在通过UDP运行的应用程序安全地使用ECN之前，需要额外的机制。例如，在使用ECN之前，发送应用程序必须确保接收应用程序能够从较低层UDP堆栈接收ECN相关信息，并将此ECN信息解释为拥塞指示。
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.
我们感谢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和Henning Schulzrinne对本文件的反馈。（当然，这些人并不一定同意所有的文件。）Ran Atkinson和Geoff Huston对文件的文本做出了贡献。
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.
第6.0节中的分析源自与Mark Handley在白板上的对话。我们还感谢Alberto Medina的FreeBSD实验，该实验显示TCP的发送速率是丢包率的函数。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
[RFC2988]Paxson，V.和M.Allman，“计算TCP的重传计时器”，RFC 2988，2000年11月。
[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.
[RFC3267]Sjoberg，J.，Westerlund，M.，Lakaniemi，A.和Q.Xie，“自适应多速率（AMR）和自适应多速率宽带（AMR-WB）音频编解码器的实时传输协议（RTP）有效载荷格式和文件存储格式”，RFC 3267，2002年6月。
[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".
[A02]Ran Atkinson，《ISP现实检查》，向ieprep的演示，第55届IETF会议，2002年11月。URL“http://www.ietf.cnri.reston.va.us/proceedings/ 11月2日/219.htm#幻灯片”。
[A03] Brian Adamson, private communication, June 2003.
[A03]Brian Adamson，《私人通信》，2003年6月。
[BBFS01] Deepak Bansal, Hari Balakrishnan, Sally Floyd, and Scott Shenker, Dynamic Behavior of Slowly-Responsive Congestion Control Algorithms, SIGCOMM 2001.
[BBFS01]Deepak Bansal、Hari Balakrishnan、Sally Floyd和Scott Shenker，《缓慢响应拥塞控制算法的动态行为》，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.
[COPS]达勒姆，D.，Ed.，Boyle，J.，Cohen，R.，Herzog，S.，Rajan，R.和A.Sastry，“COPS（公共开放政策服务）协议”，RFC 27482000年1月。
[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/".
[DCCP03]Eddie Kohler，Mark Handley，Sally Floyd和Jitendra Padhye，数据报拥塞控制协议（DCCP），互联网草案工作正在进行中，2003年3月。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".
[DIFFSERV]区分服务（DIFFSERV），工作组总结，URL“http://www.ietf.cnri.reston.va.us/html.charters/ 旧的/diffserv charter.html”。
[E2E] The end2end-interest mailing list, URL "http://www.postel.org/mailman/listinfo/end2end-interest".
[E2E]End2兴趣邮件列表，URL“http://www.postel.org/mailman/listinfo/end2end-interest".
[FHPW00] S. Floyd, M. Handley, J. Padhye, J. Widmer, "Equation-Based Congestion Control for Unicast Applications", ACM SIGCOMM 2000.
[FHPW00]S.Floyd，M.Handley，J.Padhye，J.Widmer，“单播应用中基于方程的拥塞控制”，ACM SIGCOMM 2000。
[FM03] S. Floyd and R. Mahajan, Router Primitives for Protection Against High-Bandwidth Flows and Aggregates, internet draft (not yet submitted).
[FM03]S.Floyd和R.Mahajan，《防止高带宽流量和聚合的路由器原语》，互联网草案（尚未提交）。
[FWD] Free World Dialup, URL "www.pulver.com/fwd/".
[FWD]免费世界拨号，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".
[IEPREP02]互联网应急准备（ieprep），会议记录，第55次IETF会议，2002年11月。URL“http://www.ietf.cnri.reston.va.us/proceedings/ 11月2日/219.htm#cmr”。
[ILBRC] S.V. Andersen, et. al., Internet Low Bit Rate Codec, Work in Progress, March 2003.
[ILBRC]S.V.Andersen等人，《互联网低比特率编解码器》，正在进行的工作，2003年3月。
[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/".
[G.114]建议G.114-单向传输时间，国际电联，2003年5月。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/".
[IVOX]交互式语音交换，URL“http://manimac.itd.nrl.navy.mil/IVOX/".
[Jacobson88] V. Jacobson, Congestion Avoidance and Control, ACM SIGCOMM '88, August 1988.
[Jacobson88]诉Jacobson，拥塞避免和控制，ACM SIGCOMM'88，1988年8月。
[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.
[AUT]VoIP流量的最大可行丢弃率取决于编解码器。这些数字是各种编解码器的范围；许多编解码器的语音质量开始下降，下降率约为10%。作者的说明。
[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".
[JS00]姜文宇和Henning Schulzrinne，分组丢失和延迟的建模及其对实时多媒体服务质量的影响，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/".
[JS02]姜文宇和Henning Schulzrinne，突发性丢失下VoIP感知质量丢包修复方法的比较与优化，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/".
[JS03]姜文宇，Kazummi Koguchi和Henning Schulzrinne，VoIP端点的QoS评估，ICC 2003。URL“http://www1.cs.columbia.edu/~wenyu/”。
[KFK79] G.S. Kang, L.J. Fransen, and E.L. Kline, "Multirate Processor (MRP) for Digital Voice Communications", NRL Report 8295, Naval Research Laboratory, Washington DC, March 1979.
[KKK79]G.S.Kang，L.J.Fransen和E.L.Kline，“数字语音通信用多速率处理器（MRP）”，美国国家无线电研究实验室报告8295，海军研究实验室，华盛顿特区，1979年3月。
[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.
[KF82]G.S.Kang和L.J.Fransen，“用于数字语音通信的多速率处理器（MRP）的第二次报告”，NRL报告8614，海军研究实验室，华盛顿特区，1982年9月。
[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.
[测量]关于“互联网端到端拥塞控制测量研究”的网页，URLhttp://www.icir.org/floyd/ccmeasure.html". “特定站点的网络测量”一节包括关于互联网中不同链路上数据包大小分布的测量数据。
[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.
[MTK03]A.P.Markopoulou，F.A.Tobagi和M.J.Karam，“评估互联网主干上的语音通信质量”，IEEE/ACM网络交易，第11卷第5期，2003年10月。
[NSIS] Next Steps in Signaling (nsis), IETF Working Group, URL "http://www.ietf.cnri.reston.va.us/html.charters/nsis-charter.html".
[NSIS]信令下一步（NSIS），IETF工作组，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".
Joerg Widmer、Martin Mauve和Jan Peter Damm。非适应性流的概率拥塞控制。曼海姆大学数学与计算机科学系技术报告3/2001。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.
[PFTK98]J.Padhye，V.Firoiu，D.Towsley，J.Kurose，TCP吞吐量建模：一个简单模型及其经验验证，技术报告TF 98-008，美国马萨诸塞州，1998年2月。
[RFC896] Nagle, J., "Congestion Control in IP/TCP", RFC 896, January 1984.
[RFC896]Nagle，J.，“IP/TCP中的拥塞控制”，RFC896，1984年1月。
[RFC1890] Schulzrinne, H., "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 1890, January 1996.
[RFC1890]Schulzrinne，H.，“具有最小控制的音频和视频会议的RTP配置文件”，RFC 1890，1996年1月。
[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.
[RFC2474]Nichols，K.，Blake，S.，Baker，F.和D.Black，“IPv4和IPv6标头中区分服务字段（DS字段）的定义”，RFC 2474，1998年12月。
[RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581]Allman，M.，Paxson，V.和W.Stevens，“TCP拥塞控制”，RFC 25811999年4月。
[RFC2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "Assured Forwarding PHB Group, RFC 2597, June 1999.
[RFC2597]Heinanen，J.，Baker，F.，Weiss，W.和J.Wroclawski，“保证货运PHB集团，RFC 25971999年6月。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
[RFC2914]Floyd，S.，“拥塞控制原则”，BCP 41，RFC 2914，2000年9月。
[RFC2990] Huston, G., "Next Steps for the IP QoS Architecture", RFC 2990, November 2000.
[RFC2990]Huston，G.，“IP QoS架构的下一步”，RFC 29902000年11月。
[RFC3042] Allman, M., Balakrishnan, H. and S., Floyd, "Enhancing TCP's Loss Recovery Using Limited Transmit", RFC 3042, January 2001.
[RFC3042]Allman，M.，Balakrishnan，H.和S.，Floyd，“使用有限传输增强TCP的丢失恢复”，RFC 3042，2001年1月。
[RFC3168] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RFC3168]Ramakrishnan，K.，Floyd，S.和D.Black，“向IP添加显式拥塞通知（ECN）”，RFC 3168，2001年9月。
[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.
[RFC3246]Davie，B.，Charny，A.，Bennet，J.C.R.，Benson，K.，Le Boudec，J.Y.，Courtney，W.，Davari，S.，Firoiu，V.和D.Stiliadis，“快速转发PHB（每跳行为）”，RFC 32462002年3月。
[RFC3448] Handley, M., Floyd, S., Pahdye, J. and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 3448, January 2003.
[RFC3448]Handley，M.，Floyd，S.，Pahdey，J.和J.Widmer，“TCP友好速率控制（TFRC）：协议规范”，RFC 3448，2003年1月。
[RSVP] Resource Reservation Setup Protocol (rsvp), Concluded Working Group, URL "http://www.ietf.cnri.reston.va.us/html.charters/ OLD/rsvp-charter.html".
[RSVP]资源预留设置协议（RSVP），工作组总结，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"
[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.
[S03]H.Schulzrinne，私人通信，2003年。
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 3551, July 2003.
[RFC3551]Schulzrinne，H.和S.Casner，“具有最小控制的音频和视频会议的RTP配置文件”，RFC 35512003年7月。
[Vonage] Vonage, URL "www.vonage.com".
[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/",
[W98] J·伍德沃德，语音编码，通信研究组，南安普敦大学，1998。URL“http://www-mobile.ecs.soton.ac.uk/speech_codecs/",
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]:
作为丢包率的函数，估计TCP的平均发送速率（以每次往返的数据包为单位）的标准方法是使用[PFTK98]中估计的TCP响应函数：
S = 1/(sqrt(2p/3) + K min(1,3 sqrt(3p/8)) p (1 + 32 p^2)) (1)
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.
对于每个数据包发送的ACK，RTO设置为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.
下面表1和表2中第二列给出了等式（1）的结果。然而，等式（1）高估了TCP在丢包率高（例如，30%或更高）的情况下的发送速率。等式（1）后面的分析假设，一旦单个数据包成功传输，TCP的重传计时器就不再后退。这可能适用于具有ECN的环境，或者适用于使用细粒度时间戳的TCP连接，但对于不支持ECN且没有时间戳的TCP连接，情况未必如此。如[RFC2988]中所述，如果TCP的重传计时器被回退，则只有当TCP在没有时间戳的情况下成功传输新数据包（与重传数据包相反）时，才应删除此回退。
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.]
例如，当分组丢弃率为50%或更高时，许多成功分组传输可以是重传分组，并且在没有时间戳的情况下，重传定时器可以在相当长的时间段内保持后退。在这种情况下，TCP的吞吐量在很大程度上取决于重传计时器的最大回退。例如，在NS模拟器中，重传计时器的最大回退是未回退值的64倍。RFC 2988规定，“如果RTO上的最大值至少为60秒，则可以将其设置为最大值。”[尽管TCP实现方式有所不同，但许多TCP实现在丢弃SYN数据包后，对于已备份的RTO，其最大值为45秒。]
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.
等式（1）的另一个限制是，它对雷诺TCP建模，因此低估了使用SACK和有限传输的现代TCP连接的发送速率。
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).
下表显示了等式（1）中RTO设置为2 RTT的TCP连接的平均发送速率S的估计值（以每个RTT的数据包为单位）。
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
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
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.
在10000秒模拟的后半部分中的平均发送速率，对于每个数据包丢弃速率，在50次模拟中给出平均值。对于具有极高丢包率的模拟，有时会重复丢包SYN数据包，并且TCP发送方从未成功传输数据包。在这种情况下，TCP发送方也永远无法获得往返时间的测量值。
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.
表1的第六列显示了使用4.8版本FreeBSD机器的实验的平均发送速率S（以每个RTT的数据包为单位）。对于0.1和0.2的低丢包率，模拟中的发送速率高于实验中的发送速率；这可能是因为模拟中的TCP实现使用有限传输[RFC3042]。在有限传输的情况下，当数据包丢失且拥塞窗口较小时，TCP发送方有时可以避免重传超时。在高分组丢弃率为0.65和0.7的情况下，模拟中的发送速率略低于实验中的发送速率。对于这些高丢包率，实验中的TCP连接通常会在连续丢包足够多后过早中止。
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.
我们注意到，如果ECN标记率超过本地配置的阈值，则建议路由器从标记切换到丢弃。因此，即使事实上部署了ECN，我们也不希望在互联网上看到高的稳态标记率。
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
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.
表1:RTO设置为2 RTT时，发送速率S作为丢包率p的函数，以及每个RTT的数据包数S。
The table below shows the average sending rate S, for TCP connections with the RTO set to 10 RTT.
下表显示了RTO设置为10 RTT的TCP连接的平均发送速率。
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
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.
表2：RTO设置为10 RTT时，发送速率作为丢包率的函数，每个RTT的数据包数为S。
This document does not itself create any new security issues for the Internet community.
本文件本身不会给互联网社区带来任何新的安全问题。
There are no IANA considerations regarding this document.
关于本文件，没有IANA考虑事项。
Internet Architecture Board EMail: iab@iab.org
互联网架构委员会电子邮件：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
Bernard Aboba Harald Alvestrand（IETF主席）Rob Austein Leslie Daigle（IAB主席）Patrik Faltstrom Sally Floyd Jun ichiro Itojun Hagino Mark Handley Geoff Huston（IAB执行董事）Charlie Kaufman James Kempf Eric Rescorla Mike St.Johns
This document was created in January 2004.
本文件创建于2004年1月。
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.
版权所有（C）互联网协会（2004年）。本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和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.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为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.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。