Internet Architecture Board (IAB) H. Tschofenig
Request for Comments: 7295 L. Eggert
Category: Informational Z. Sarker
ISSN: 2070-1721 July 2014
Internet Architecture Board (IAB) H. Tschofenig
Request for Comments: 7295 L. Eggert
Category: Informational Z. Sarker
ISSN: 2070-1721 July 2014
Report from the IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication
IAB/IRTF互动实时通信拥塞控制研讨会报告
Abstract
摘要
This document provides a summary of the IAB/IRTF Workshop on 'Congestion Control for Interactive Real-Time Communication', which took place in Vancouver, Canada, on July 28, 2012. The main goal of the workshop was to foster a discussion on congestion control mechanisms for interactive real-time communication. This report summarizes the discussions and lists recommendations to the Internet Engineering Task Force (IETF) community.
本文件概述了IAB/IRTF于2012年7月28日在加拿大温哥华举办的“交互式实时通信拥塞控制”研讨会。研讨会的主要目标是促进讨论交互式实时通信的拥塞控制机制。本报告总结了讨论情况，并向互联网工程任务组（IETF）社区提出了建议。
The views and positions in this report are those of the workshop participants and do not necessarily reflect the views and positions of the authors, the Internet Architecture Board (IAB), or the Internet Research Task Force (IRTF).
本报告中的观点和立场是研讨会参与者的观点和立场，并不一定反映作者、互联网架构委员会（IAB）或互联网研究工作组（IRTF）的观点和立场。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Architecture Board (IAB) and represents information that the IAB has deemed valuable to provide for permanent record. It represents the consensus of the Internet Architecture Board (IAB). Documents approved for publication by the IAB are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网体系结构委员会（IAB）的产品，代表IAB认为有价值提供永久记录的信息。它代表了互联网体系结构委员会（IAB）的共识。IAB批准发布的文件不适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7295.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7295.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Workshop Structure . . . . . . . . . . . . . . . . . . . . . 5
2.1. History and Current Challenges . . . . . . . . . . . . . 5
2.2. Simulations and Measurements . . . . . . . . . . . . . . 8
2.3. Design Aspects of Problems and Solutions . . . . . . . . 9
3. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 13
3.1. Changes to Network Infrastructure . . . . . . . . . . . . 14
3.2. Avoiding Self-Inflicted Queuing . . . . . . . . . . . . . 15
4. Security Considerations . . . . . . . . . . . . . . . . . . . 17
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
6. Informative References . . . . . . . . . . . . . . . . . . . 17
Appendix A. Program Committee . . . . . . . . . . . . . . . . . 22
Appendix B. Workshop Material . . . . . . . . . . . . . . . . . 22
Appendix C. Accepted Position Papers . . . . . . . . . . . . . . 22
Appendix D. Workshop Participants . . . . . . . . . . . . . . . 24
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Workshop Structure . . . . . . . . . . . . . . . . . . . . . 5
2.1. History and Current Challenges . . . . . . . . . . . . . 5
2.2. Simulations and Measurements . . . . . . . . . . . . . . 8
2.3. Design Aspects of Problems and Solutions . . . . . . . . 9
3. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 13
3.1. Changes to Network Infrastructure . . . . . . . . . . . . 14
3.2. Avoiding Self-Inflicted Queuing . . . . . . . . . . . . . 15
4. Security Considerations . . . . . . . . . . . . . . . . . . . 17
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
6. Informative References . . . . . . . . . . . . . . . . . . . 17
Appendix A. Program Committee . . . . . . . . . . . . . . . . . 22
Appendix B. Workshop Material . . . . . . . . . . . . . . . . . 22
Appendix C. Accepted Position Papers . . . . . . . . . . . . . . 22
Appendix D. Workshop Participants . . . . . . . . . . . . . . . 24
The Internet Architecture Board (IAB) holds occasional workshops designed to consider long-term issues and strategies for the Internet, and to suggest future directions for the Internet architecture. This long-term planning function of the IAB is complementary to the ongoing engineering efforts performed by working groups of the Internet Engineering Task Force (IETF), under the leadership of the Internet Engineering Steering Group (IESG) and area directorates.
互联网体系结构委员会（IAB）举办临时研讨会，旨在考虑互联网的长期问题和策略，并提出未来的互联网架构方向。IAB的这一长期规划职能是对互联网工程任务组（IETF）工作组在互联网工程指导小组（IESG）和地区理事会领导下进行的工程工作的补充。
Any application that sends significant amounts of data over the Internet is expected to implement reasonable congestion control behavior. The goals for congestion control are well understood and documented in RFC 2914 [2] and RFC 5405 [1]:
任何通过互联网发送大量数据的应用程序都需要实现合理的拥塞控制行为。RFC 2914[2]和RFC 5405[1]充分理解并记录了拥塞控制的目标：
1. Preventing congestion collapse.
1. 防止堵塞崩溃。
2. Allowing multiple flows to share the network fairly.
2. 允许多个流公平地共享网络。
The Internet has been used for interactive real-time communication for decades, most of which is being transmitted using the Real-Time Transport Protocol (RTP) over UDP, often over provisioned capacity and/or using only rudimentary congestion control mechanisms. In 2004, the IAB raised concerns regarding possibilities of a congestion collapse due to a rapid growth in real-time voice traffic that does not practice end-to-end congestion control [17]. That congestion collapse did not happen, but concerns raised about both congestion collapse and fairness are still valid and have gained more relevance when applied to more bandwidth-hungry video applications. The development and upcoming widespread deployment of web-based real-time media communication -- where RTP is used to and from web browsers to transmit audio, video, and data -- will likely result in substantial new Internet traffic. Due to the projected volume of this traffic, as well as the fact that it is more likely to use unprovisioned capacity, it is essential that it is transmitted with robust and effective congestion control mechanisms.
几十年来，互联网一直用于交互式实时通信，其中大部分是通过UDP使用实时传输协议（RTP）传输的，通常是过度配置的容量和/或仅使用基本的拥塞控制机制。2004年，IAB提出了关于由于实时语音流量的快速增长而导致拥塞崩溃的可能性的担忧，而实时语音流量并未实施端到端拥塞控制[17]。这种拥塞崩溃并没有发生，但人们对拥塞崩溃和公平性的担忧仍然有效，并且在应用于带宽需求更大的视频应用时，这种担忧变得更加重要。基于web的实时媒体通信的发展和即将广泛部署——RTP用于在web浏览器之间传输音频、视频和数据——可能会带来大量新的互联网流量。由于该流量的预计容量，以及它更可能使用未预见容量的事实，因此，必须使用稳健有效的拥塞控制机制传输该流量。
Designing congestion control mechanisms that perform well under a wide variety of traffic mixes and over network paths with widely varying characteristics is not easy. Prevention of congestion collapse can be achieved through a "circuit breaker" mechanism (see, for example, [3]), but for media flows that are supposed to coexist with a user's other ongoing communication sessions, a congestion control mechanism that shares capacity fairly in the presence of a mix of TCP, UDP, and other protocol flows is needed.
设计在各种流量混合和具有各种特性的网络路径上表现良好的拥塞控制机制并不容易。可以通过“断路器”机制（例如，参见[3]）来防止拥塞崩溃，但是对于假定与用户的其他正在进行的通信会话共存的媒体流，需要在TCP、UDP和其他协议流混合存在的情况下公平共享容量的拥塞控制机制。
Many additional complications arise. Here are some examples:
出现了许多额外的并发症。以下是一些例子：
1. Real-time interactive media sessions require low latencies, whereas streaming media can use large play-out buffers.
1. 实时交互媒体会话需要低延迟，而流媒体可以使用大的播放缓冲区。
2. In an RTP session, feedback exchanged via the RTP Control Protocol (RTCP) typically arrives much less frequently than, for example, TCP ACKs for a given TCP connection. Theoretically, the RTP/RTCP control loop can lead to a longer reaction time.
2. 在RTP会话中，通过RTP控制协议（RTCP）交换的反馈通常比（例如）给定TCP连接的TCP确认到达的频率要低得多。理论上，RTP/RTCP控制回路可以导致更长的反应时间。
3. Media codecs can usually only adjust their output rates in a much more coarse-grained fashion than, for example, TCP, and user experience suffers if encoding rates are switched too frequently. Codecs typically have a minimum sending rate as well.
3. 媒体编解码器通常只能以比TCP更粗粒度的方式调整其输出速率，如果编码速率切换过于频繁，用户体验就会受到影响。编解码器通常也具有最低发送速率。
4. Some bits of an encoded media stream are more important than others. For example, losing or dropping an I-frame of a video stream is more problematic than dropping a P-frame [40].
4. 编码媒体流的某些位比其他位更重要。例如，丢失或丢弃视频流的I帧比丢弃P帧问题更大[40]。
5. Ramping up the transmission rate can be problematic. Simply increasing the output rate of the codec without knowing whether the network path can sustain transmission at the increased rate runs the danger of incurring a significant amount of packet loss that can cause playback artifacts.
5. 提高传输速率可能会有问题。简单地增加编解码器的输出速率，而不知道网络路径是否能够以增加的速率维持传输，就有可能导致大量数据包丢失，从而导致播放伪影。
6. A congestion control scheme for interactive media needs to handle bundles of interrelated flows (audio, video, and data) in a way that accommodates the preferences of the application in the event of congestion.
6. 交互式媒体的拥塞控制方案需要以一种在发生拥塞时适应应用程序偏好的方式处理相互关联的流（音频、视频和数据）束。
7. The desire to provide a congestion control mechanism that can be efficiently implemented inside an application imposes additional restrictions. For example, a web browser is not able to take the protocol interactions of a software download happening in another application into account.
7. 为了提供能够在应用程序内部高效实现的拥塞控制机制，需要施加额外的限制。例如，web浏览器无法考虑在另一个应用程序中发生的软件下载的协议交互。
8. There are explicit congestion signals (such as Explicit Congestion Notification (ECN) [19]), and there are implicit indications of congestion (e.g., packet delay and loss). Care must be taken to account for each of these signals, particularly if various applications react on the same set of signals.
8. 存在显式拥塞信号（例如显式拥塞通知（ECN）[19]），并且存在拥塞的隐式指示（例如，数据包延迟和丢失）。必须注意这些信号中的每一个，特别是如果不同的应用对同一组信号作出反应。
9. Large buffers are often used in network elements and end device operating systems to better support TCP-based applications. These buffers introduce additional communication delay, which harms the small delay budget available for interactive real-time applications.
9. 大型缓冲区通常用于网元和终端设备操作系统，以更好地支持基于TCP的应用程序。这些缓冲区引入了额外的通信延迟，这损害了交互式实时应用程序可用的小延迟预算。
The IETF has a long history of work on congestion control mechanisms. With ongoing standardization work on real-time interactive media communication on the web, new challenges have emerged that have refocused engineering attention on congestion control issues. To take a deeper look at congestion control in light of the growth of real-time traffic, workshop participants were invited to submit position papers that were then used to organize the workshop agenda into three principal components: a keynote talk given by Mark Handley describing the history of the work on congestion control for real-time media followed and his views of current problems; a presentation of simulations and data demonstrating current problems and solutions; and a discussion of desirable solution properties and challenges in deploying solutions.
IETF在拥塞控制机制方面有着悠久的工作历史。随着web上实时交互式媒体通信的标准化工作的不断进行，出现了新的挑战，使工程界的注意力重新集中在拥塞控制问题上。为了更深入地了解实时交通量增长带来的拥堵控制，研讨会参与者被邀请提交立场文件，然后用于将研讨会议程分为三个主要部分：马克·汉德利（Mark Handley）的主旨演讲，描述了实时媒体拥塞控制工作的历史以及他对当前问题的看法；演示当前问题和解决方案的模拟和数据；以及讨论理想的解决方案属性和部署解决方案时面临的挑战。
Mark Handley argued that since 1988, the Internet has remained functional despite exponential growth, routers that are sometimes buggy or misconfigured, rapidly changing applications and usage patterns, and flash crowds. This is largely because most applications use TCP, and TCP implements end-to-end congestion control.
马克·汉德利（Mark Handley）认为，自1988年以来，尽管互联网呈指数级增长，路由器有时存在缺陷或配置错误，应用程序和使用模式迅速变化，以及flash用户群不断增加，但互联网仍能正常运行。这主要是因为大多数应用程序使用TCP，TCP实现端到端的拥塞控制。
TCP's congestion control adapts the window to fit the capacity available in the network and accomplishes approximate fairness between two competing flows over a period of time. Mark indicated that the provided level of fairness is not necessarily what we want: The 1/round-trip-time relationship in TCP is not ideal since it means that network operators can decide to lower packet loss by adding bigger buffers (which unfortunately leads to bufferbloat problems; see [31] and [39]). The 1/sqrt(packet drop rate) relationship is also not necessarily desirable since TCP initially did not work particularly well for high-speed flows (which had been the subject of much TCP research).
TCP的拥塞控制调整窗口以适应网络中的可用容量，并在一段时间内实现两个竞争流之间的近似公平性。Mark指出，提供的公平性水平并不一定是我们想要的：TCP中的1/往返时间关系并不理想，因为这意味着网络运营商可以决定通过添加更大的缓冲区来降低数据包丢失（不幸的是，这会导致缓冲区膨胀问题；参见[31]和[39]）。1/sqrt（数据包丢弃率）关系也不一定是理想的，因为TCP最初在高速流（这一直是TCP研究的主题）中工作得不是特别好。
TCP controls the congestion window in bytes. For bulk transfer, usually this results in controlling the number of 1500-byte packets sent per second. Real-time media is different since it has its own time constraints. For audio, one wants to send one packet per 20 ms and for video, the ideal value would be 25 to 30 frames per second. One, therefore, wants to avoid additional sending delay.
TCP以字节为单位控制拥塞窗口。对于批量传输，这通常会导致控制每秒发送的1500字节数据包的数量。实时媒体是不同的，因为它有自己的时间限制。对于音频，人们希望每20毫秒发送一个数据包，而对于视频，理想值为每秒25到30帧。因此，其中一个希望避免额外的发送延迟。
As an example, in case of video, to relieve congestion one has to reduce the number of packets-per-second transmission rate rather than transmit smaller packets, since at higher bitrates on WiFi the time it takes to send a packet is almost negligible compared to the time
例如，在视频的情况下，为了缓解拥塞，必须降低每秒传输速率中的数据包数量，而不是传输较小的数据包，因为在WiFi上的较高比特率下，发送数据包所需的时间几乎可以忽略不计
that is spent with Media Access Control (MAC) layer operations. Reducing the packet size makes little difference to the available capacity. For a serial line, it does not matter how big the packets are.
这与媒体访问控制（MAC）层操作有关。减小数据包大小对可用容量影响不大。对于串行线路，数据包有多大无关紧要。
From a network point of view, the goals of congestion control therefore are:
因此，从网络的角度来看，拥塞控制的目标是：
1. Avoid congestion collapse
1. 避免拥堵崩溃
2. Avoid starvation of TCP flows
2. 避免TCP流饥饿
3. Avoid starvation of real-time flows, specifically in the case where TCP and real-time flows share the same FIFO queue.
3. 避免实时流匮乏，特别是在TCP和实时流共享同一FIFO队列的情况下。
From an application point of view, the goals of congestion control are different, namely:
从应用的角度来看，拥塞控制的目标是不同的，即：
1. Robust behavior. One wants to have a good throughput when the network is working well and passable performance when the network is working poorly.
1. 健壮的行为。人们希望在网络运行良好时具有良好的吞吐量，在网络运行不良时具有可通过的性能。
2. Predictable behavior. This matters from a usability point of view since variable media creates a bad user experience.
2. 可预测的行为。从可用性的角度来看，这很重要，因为可变媒体会造成糟糕的用户体验。
3. Low latency. With large buffers along the end-to-end path, latency will increase when interactive real-time flows compete with TCP flows. This results in TCP filling up the buffers; increased buffering will lead to additional delays for the delivery of the interactive real-time media.
3. 低延迟。由于端到端路径上有大量缓冲区，当交互式实时流与TCP流竞争时，延迟将增加。这导致TCP填满缓冲区；缓冲的增加将导致交互式实时媒体交付的额外延迟。
Attempts to provide congestion control for interactive real-time media have previously been made in the IETF, for example, with the work on TCP Friendly Rate Control (TFRC) [12]. TFRC illustrates the challenges quite well. TFRC tries to accomplish the same throughput as TCP, but with a smoother transmission rate. It measures the loss and the round-trip time but follows a similar model as TCP to determine the sending rate.
IETF曾试图为交互式实时媒体提供拥塞控制，例如，通过TCP友好速率控制（TFRC）[12]。TFRC很好地说明了这些挑战。TFRC试图实现与TCP相同的吞吐量，但具有更平滑的传输速率。它测量损耗和往返时间，但遵循与TCP类似的模型来确定发送速率。
In a link with low statistical multiplexing, TCP can lead to bad oscillations. The sending rate hits the maximum rate of a bottleneck link, a lot of loss occurs, and then the sending rate peaks again. For very small buffers the result is acceptable, but bigger buffers lead to oscillations. The result is bad for networks and for applications. To deal with large buffers on these links, a short-term rate adaptation based on round-trip time (RTT) information is utilized in TRFC, but this requires good short-term RTT measurements.
在统计复用率较低的链路中，TCP可能导致严重的振荡。发送速率达到瓶颈链路的最大速率时，会发生大量丢失，然后发送速率再次达到峰值。对于非常小的缓冲器，结果是可以接受的，但较大的缓冲器会导致振荡。这对网络和应用程序都是不利的。为了处理这些链路上的大缓冲区，TRFC中使用了基于往返时间（RTT）信息的短期速率自适应，但这需要良好的短期RTT测量。
TRFC works pretty well in theory. TFRC assumes the network is in charge of the codec and that the codec can produce data at the demanded rate. Modern video codecs inherently produce variable-bitrate video streams based on the content being encoded, and it is hard to produce data at exactly the desired bitrate without excessive buffering or ugly quality changes.
TRFC在理论上运作良好。TFRC假设网络负责编解码器，并且编解码器可以按要求的速率生成数据。现代视频编解码器固有地根据被编码的内容生成可变比特率视频流，并且在没有过度缓冲或质量变化的情况下，很难精确地以所需比特率生成数据。
What if the codec is put in charge instead of the network? The network tells the codec the mean rate, but it does not worry about what happens in short time scales, and the codec matches the mean rate and does not worry whether it is over or under the rate for a relatively short time scale. This again leads to the low statistical multiplexing problem and leads to oscillations.
如果由编解码器而不是网络来负责呢？网络告诉编解码器平均速率，但它不担心在短时间尺度内会发生什么，编解码器匹配平均速率，也不担心在相对较短的时间尺度内该速率是否高于或低于该速率。这再次导致低统计复用问题并导致振荡。
Known congestion control mechanisms work well if they can respond quickly enough to changes and if they do not bump into the low statistical multiplexing problem.
如果已知的拥塞控制机制能够对变化做出足够快的响应，并且不会遇到统计复用率低的问题，那么它们就能很好地工作。
To avoid the low statistical multiplexing problem, techniques for inferring link speed are needed. The work from Van Jacobson's pathchar [37] (and successors) serve as valuable input. The idea is to send short packet trains, to measure timing accurately, and to infer the link speed from the relative delay. If we know the link speed, we can avoid exceeding it. Congestion control can give us an approximate rate, but we must not exceed link speed. This is a hybrid between codec being in charge (most of the time) and the network being in charge. These work well for some links, but not for others. Wireless links where speed can change in less than a single RTT because of fading, bitrate adaption, etc., cause problems. We would like to have the codec and the network be in charge. However, they both cannot be in charge at the same time.
为了避免低统计复用问题，需要推断链路速度的技术。Van Jacobson的pathchar[37]（及其继任者）的作品是有价值的投入。其思想是发送短数据包序列，精确测量定时，并根据相对延迟推断链路速度。如果我们知道链接速度，我们可以避免超过它。拥塞控制可以给我们一个近似的速率，但我们不能超过链路速度。这是由编解码器负责（大部分时间）和网络负责的混合体。这些方法对某些链接很有效，但对其他链接无效。由于衰落、比特率自适应等原因，速度在不到一个RTT内变化的无线链路会导致问题。我们希望由编解码器和网络负责。但是，他们不能同时负责。
Mark indicated that he is not entirely sure whether RTCP is suitable for congestion control. RTCP gives feedback, but it cannot send it often enough to avoid bumping into link speed. Circuit breakers [3], on the other hand, do not help to give good performance on an uncongested path. With circuit breakers, the sender measures the loss rate and RTT, and runs with a loose "cap."
马克表示，他并不完全确定RTCP是否适合拥塞控制。RTCP提供反馈，但它不能经常发送反馈，以免影响链路速度。另一方面，断路器[3]无助于在未阻塞的路径上提供良好的性能。对于断路器，发送器测量损耗率和RTT，并在“盖”松动的情况下运行
In conclusion, Mark Handley claimed that we know how to do good congestion control, but only if congestion control is in charge, and that's not acceptable for real-time applications. We only know how to do good congestion control if we change the packet/sec rate and not the packet size.
总之，Mark Handley声称我们知道如何做好拥塞控制，但只有在拥塞控制负责的情况下，这对于实时应用是不可接受的。只有当我们改变包/秒速率而不是包大小时，我们才知道如何做好拥塞控制。
This second part of the workshop was focused on the presentation and the discussion of data gathered from simulations and real-world measurements.
研讨会的第二部分侧重于介绍和讨论从模拟和真实测量中收集的数据。
Keith Winstein started the discussion with his presentation of measurements performed in cellular operator networks in the US [22]. The measurements indicate that the analyzed cellular networks showed varying RTT with transient latency spikes to hundreds of milliseconds, link speed that varies by a factor of 10 in a short time scale, and buffers that do not drop packets until they contain 5-10 seconds of data at bottleneck link speed.
Keith Winstein首先介绍了在美国蜂窝运营商网络中进行的测量[22]。测量结果表明，所分析的蜂窝网络显示出不同的RTT，瞬时延迟峰值达到数百毫秒，链路速度在短时间内变化10倍，缓冲区在包含5-10秒数据之前不会丢弃数据包，以瓶颈链路速度。
Zaheduzzaman Sarker [21] presented results from real-time video communication in a Long Term Evolution (LTE) simulator utilizing ECN-based packet marking and adaptation using implicit methods like packet loss and delay. ECN marking provides ways for the network to explicitly signal congestion and hence distributes the cost of congestion well and helps achieve lower latency. However, although RFC 3168 [19] was finalized in 2001, the deployment of ECN is still lacking as investigated by Bauer, et al. [25]. A few participants noted that they believe that the deployment of LTE networks will also increase the deployment of ECN with the recent work on ECN for RTP over UDP [11].
Zaheduzaman-Sarker[21]介绍了长期演进（LTE）模拟器中实时视频通信的结果，该模拟器使用基于ECN的分组标记和自适应，使用诸如分组丢失和延迟之类的隐式方法。ECN标记为网络提供了明确表示拥塞的方法，因此可以很好地分配拥塞成本，并有助于降低延迟。然而，尽管RFC 3168[19]于2001年最终确定，但根据Bauer等人的调查，ECN的部署仍然缺乏[25]。一些参与者指出，他们相信LTE网络的部署也将增加ECN的部署，最近在UDP上RTP的ECN上进行了研究[11]。
Mo Zahaty [20] discussed TFRC [12] and TFRC with weighted fairness (MulTFRC) [4], which tunes TFRC to consider multiple flows, and showed the impact of RTT and loss rates on the type of video quality that can be achieved under those conditions. TFRC requires frequent feedback, which RTCP does not provide even when considering the extended RTP profile for RTCP-based feedback (RFC 4585 [5]). Mo argued that application-specified weighted fairness is important but while MulTFRC provides better performance than TFRC, it is not clear whether the added complexity over an n-times-TFRC approach is indeed worth the effort.
Mo ZaaTay（20）用加权公平（MultFrc）〔4〕讨论TFRC〔12〕和TFRC，调谐TFRC考虑多个流，并显示RTT和损失率对在这些条件下可实现的视频质量类型的影响。TFRC需要频繁的反馈，即使在考虑基于RTCP的反馈的扩展RTP配置文件（RFC 4585[5]）时，RTCP也不提供这种反馈。Mo认为应用程序指定的加权公平性很重要，但尽管MulTFRC比TFRC提供了更好的性能，但不清楚n倍TFRC方法增加的复杂性是否值得付出努力。
Markku Kojo shared analysis results of how real-time audio is affected by competing TCP flows. In the experiments shown in Figure 2 of [27], a real-time interactive audio stream had to compete against one TCP flow and, as a comparison, against six TCP flows. With one concurrent TCP flow, voice is impacted on startup and six TCP flows destroy the quality of the call. Two types of losses were analyzed, namely losses that result from a packet being dropped in the network (e.g., due to congestion or link errors) and losses that result from the delayed arrival of the packet (due to buffering) when the audio packet misses the deadline for the codec to decode and play the transmitted content. Consequently, even a moderate number of TCP
Markku Kojo分享了实时音频如何受竞争TCP流影响的分析结果。在[27]图2所示的实验中，实时交互式音频流必须与一个TCP流竞争，作为比较，必须与六个TCP流竞争。对于一个并发TCP流，启动时语音会受到影响，六个TCP流会破坏呼叫质量。分析了两种类型的损失，即网络中丢包导致的损失（例如，由于拥塞或链路错误）和当音频包错过编解码器解码和播放传输内容的最后期限时，由于包延迟到达（由于缓冲）导致的损失。因此，即使是中等数量的TCP
flows typically used by browsers to retrieve content on web pages in parallel causes irreparable harm for audio transfers. The size of the initial window (IW) also impacts interactive real-time communication since a larger TCP IW size (e.g., IW10 with ten segments, as proposed in [18], instead of three) leads to a bigger burst of packets because of the initial window transmission. Note that the study in [24] does not necessarily lead to the same conclusion. It claims that the increased initial window size leads to no impact or only modest impact for buffering in the majority of cases.
浏览器通常使用流并行检索网页上的内容，这会对音频传输造成无法弥补的伤害。初始窗口（IW）的大小也会影响交互式实时通信，因为较大的TCP IW大小（例如，如[18]中所述，IW10具有十个段，而不是三个段）会由于初始窗口传输而导致较大的数据包突发。请注意，[24]中的研究不一定得出相同的结论。它声称，在大多数情况下，增加的初始窗口大小不会对缓冲产生影响，或者只会对缓冲产生轻微影响。
Cullen Jennings [28] presented measurement results showing interactions between RTP and TCP flows for several widely deployed video communication products: Apple FaceTime, Google Hangout, Cisco Movi, and Microsoft Skype. While all tested products implemented some form of congestion control, none of the applications did additive increase and multiplicative decrease (AIMD). In general, it was observable that video adapts more slowly than AIMD to changes in available bandwidth because most codecs cannot make small increases in sending rates when available bandwidth increases, and do not make large decreases in sending rates when available bandwidth decreases, in order to improve the user's experience.
Cullen Jennings[28]给出了测量结果，显示了几个广泛部署的视频通信产品的RTP和TCP流之间的交互：Apple FaceTime、Google Hangout、Cisco Movi和Microsoft Skype。虽然所有测试产品都实施了某种形式的拥塞控制，但没有一种应用程序实现了加法增加和乘法减少（AIMD）。一般来说，可以观察到视频比AIMD适应可用带宽变化的速度慢，因为大多数编解码器不能在可用带宽增加时小幅度提高发送速率，而在可用带宽减少时不会大幅降低发送速率，以改善用户体验。
Stefan Holmer [43] investigated the difference between loss-based and delay-based congestion control algorithms. The suitability of loss-based congestion control schemes for interactive real-time communication systems heavily depends on buffer sizes and the deployment of active queue management mechanisms. If most routers are using tail-drop queuing, then loss-based congestion control cannot fulfill the requirements of interactive real-time applications since those flows will effectively increase the bitrate until a loss event is identified, which only happens when the bottleneck queue is full.
Stefan Holmer[43]研究了基于丢失和基于延迟的拥塞控制算法之间的差异。基于丢失的拥塞控制方案在交互式实时通信系统中的适用性在很大程度上取决于缓冲区大小和主动队列管理机制的部署。如果大多数路由器使用尾部丢弃队列，则基于丢失的拥塞控制无法满足交互式实时应用程序的要求，因为这些流将有效地提高比特率，直到识别丢失事件为止，而丢失事件仅在瓶颈队列满时发生。
During the remaining part of the workshop, the participants discussed design aspects of both the problem and solution spaces. The discussions started with a presentation by Jim Gettys about problems related to bufferbloat [31][36]. Bufferbloat is "a phenomenon in packet-switched networks, in which excess buffering of packets causes high latency and packet delay variation (also known as jitter), as well as reducing the overall network throughput" [39]. A certain amount of buffering is helpful to improve the efficiency. Not dropping packets in the event of congestion leads to increasing delays for interactive real-time communication.
在研讨会的剩余部分，参与者讨论了问题空间和解决方案空间的设计方面。讨论开始于Jim Gettys关于bufferbloat相关问题的介绍[31][36]。Bufferbloat是“数据包交换网络中的一种现象，其中数据包的过度缓冲会导致高延迟和数据包延迟变化（也称为抖动），并降低整体网络吞吐量”[39]。一定量的缓冲有助于提高效率。在拥塞情况下不丢弃数据包会导致交互式实时通信的延迟增加。
Packets may get buffered at various places along the end-to-end path including in the operating system/device drivers, customer premise equipment (such as cable modem and DSL routers), base stations, and routers. While the understanding of too large buffers has improved over the last few years, workshop participants were still concerned that many equipment manufacturers and network operators do not yet acknowledge the existence of the problem. This lack of understanding is caused by the strong focus on throughput network performance measurements that do not take latency into account. For example, only recently the Federal Communications Commission (FCC) has added latency tests to their test suites [41].
数据包可以在端到端路径上的不同位置得到缓冲，包括在操作系统/设备驱动程序、客户场所设备（如电缆调制解调器和DSL路由器）、基站和路由器中。虽然在过去几年中，对过大缓冲区的理解有所提高，但研讨会参与者仍然担心，许多设备制造商和网络运营商尚未认识到问题的存在。这种缺乏理解是由于对吞吐量网络性能测量的强烈关注而导致的，这些测量没有考虑延迟。例如，直到最近，联邦通信委员会（FCC）才将延迟测试添加到他们的测试套件中[41]。
Active queue management (AQM) aims to prevent queues from growing too large. This is accomplished by monitoring queue length and informing the sender by dropping or marking packets to lower their transmission rate. Random Early Detection (RED) [9] is one such AQM algorithm, but it has not been widely deployed in routers largely because of challenges to configure it correctly [32]. According to [23], RED does not work with the default settings as it is "too "gentle" to handle fast changes due to TCP slow start, when the aggregate traffic is limited." There may also be a lack of incentives to deploy AQM algorithms. Participants speculated about the time it takes to update network equipment (to support AQM algorithms), considering the different replacement cycles of these devices.
主动队列管理（AQM）旨在防止队列过大。这是通过监视队列长度并通过丢弃或标记数据包来通知发送方以降低其传输速率来实现的。随机早期检测（Random Early Detection，RED）[9]就是这样一种AQM算法，但由于需要正确配置该算法[32]，该算法尚未广泛应用于路由器中。根据[23]，RED不适用于默认设置，因为它“太“温和”，无法在总流量有限的情况下处理由于TCP缓慢启动而导致的快速更改。”还可能缺乏部署AQM算法的激励。考虑到这些设备的不同更换周期，参与者推测更新网络设备（以支持AQM算法）所需的时间。
One outcome of that discussion on AQM at the workshop was a Birds of a Feather ("BoF") meeting on "Active Queue Management and Packet Scheduling" at IETF 87 (July 28 - August 5, 2013, Berlin, Germany). The AQM WG [35] was chartered a few weeks later and is now designing AQM and network infrastructure improvements to deal with bufferbloat and related issues.
研讨会上关于AQM的讨论的一个结果是在IETF 87（2013年7月28日至8月5日，德国柏林）召开了一次关于“主动队列管理和数据包调度”的同类会议（BoF）。AQM工作组[35]在几周后获得特许，目前正在设计AQM和网络基础设施改进，以处理缓冲区膨胀和相关问题。
Measurement tools that allow an end user to determine the performance of his or her network, including latency, is seen as a promising approach to motivate network operators to upgrade their equipment and to make use of AQM algorithms. Measurement tools would allow users to determine how bad their networks perform and to complain to their ISP, thereby creating a market force. As to what the right performance measurement metrics are, it was noted that the intent of the IETF IP Performance Metrics (IPPM) working group [33] was to develop such metrics to qualify networks. That work may have begun before its time, but there have been recent attempts to revisit the measurement work and an effort by the FCC has gotten a lot of attention recently (see [7] and [42]).
允许最终用户确定其网络性能（包括延迟）的测量工具被视为激励网络运营商升级其设备和使用AQM算法的一种有希望的方法。测量工具将允许用户确定他们的网络性能有多差，并向他们的ISP投诉，从而创造市场力量。关于什么是正确的性能度量指标，有人指出，IETF IP性能度量（IPPM）工作组[33]的目的是开发此类指标以鉴定网络。这项工作可能在它的时间之前就已经开始了，但最近有人试图重新审视测量工作，FCC的一项工作最近得到了很多关注（见[7]和[42]）。
Matt Mathis and others argued that the traffic of throughput-maximizing and delay-minimizing applications need to be in separate queues (segregated queuing). Requiring segregated queues assumes you
Matt Mathis和其他人认为，吞吐量最大化和延迟最小化应用程序的流量需要在单独的队列中（隔离队列）。要求隔离队列假定您
are sharing the network with other greedy traffic. Quality-of-Service (QoS) signaling is a way to deploy segregated queuing, but there are several simpler alternatives, such as Stochastic Fair Queuing [38]. The Controlled Delay (CoDel) AQM algorithm [6] can also be used in combination with stochastic fair queuing. Note that queue segregation is not necessary for every router to implement; using it at the edge of a network where bottleneck links are located is already sufficient.
正在与其他贪婪的流量共享网络。服务质量（QoS）信令是部署隔离队列的一种方法，但也有一些更简单的选择，如随机公平队列[38]。受控延迟（CoDel）AQM算法[6]也可与随机公平排队结合使用。注意，队列隔离并不是每个路由器都必须实现的；在瓶颈链路所在的网络边缘使用它已经足够了。
It was noted that current interactive voice usage over the Internet works most of the time satisfactorily. In typical networks, the reason voice works is because networks are underloaded. As long as there is idle capacity and the queue is empty when packets arrive, traffic does not need to be separated into distinct queues. Further explanations were offered as to why many networks work surprisingly well: Low Extra Delay Background Transport (LEDBAT) [8] is used for the download of software updates, voice traffic contributes only a small percentage of the overall Internet traffic, and users employ "human protocols" (e.g., parents asking their kids to get off the network during the time of a conference call).
据指出，目前互联网上的交互式语音使用在大多数情况下都令人满意。在典型的网络中，语音工作的原因是网络负载不足。只要数据包到达时存在空闲容量且队列为空，则不需要将流量分成不同的队列。进一步解释了为什么许多网络工作得出奇地好：低额外延迟后台传输（LEDBAT）[8]用于下载软件更新，语音流量只占整个互联网流量的一小部分，用户使用“人工协议”（例如，家长要求孩子在电话会议期间离开网络）。
Cullen Jennings raised a concern that although interactive voice may be functional without a congestion control mechanism, the potentially large uptake of interactive video spurred on by Real-Time Communications on the Web (RTCWEB) could create substantially more significant problems. In the class of space where voice is currently working, video may fail. Ted Hardie countered by saying that RTCWEB is trying to replace existing proprietary technologies. It may ramp up the amount of use we are expecting, but it is not doing much that was not being done by Adobe Flash or Skype. RTCWEB is not a totally novel context of Internet usage. Magnus Westerlund added that RTCWEB might be the driver for the moment, but web browsers are not the only consumers of such congestion control algorithm.
Cullen Jennings提出了一个担忧，即尽管交互式语音可能在没有拥塞控制机制的情况下发挥作用，但由网络实时通信（RTCWEB）刺激的交互式视频的潜在大量使用可能会产生更大的问题。在当前语音工作的空间类别中，视频可能会失败。泰德·哈迪反驳说，RTCWEB正试图取代现有的专有技术。它可能会提高我们预期的使用量，但它并没有像Adobe Flash或Skype那样做很多。RTCWEB并不是一个全新的互联网使用环境。Magnus Westerlund补充说，RTCWEB可能是目前的驱动因素，但网络浏览器并不是这种拥塞控制算法的唯一消费者。
Furthermore, Ted Hardie noted that applications will not produce media streams that grow to 10 Mbps because their sending rate is auto rate limited by the production of the video. He suggested to ask ourselves if we are trying to get TCP to be friendly to media streams that are already rate limited or if we are asking media streams that are already rate limited to be TCP friendly. To quote Andrew McGregor: "It's really not good to be TCP friendly because it's not going to return the favor." If the desired properties we want are no starvation, fairness, and effective goodput for the offered loads, are we only willing to consider changes in RTP control, or are we willing to consider changes in TCP congestion control?
此外，Ted Hardie指出，应用程序不会产生增长到10 Mbps的媒体流，因为它们的发送速率受视频制作的自动速率限制。他建议我们问问自己，我们是想让TCP对已经有速率限制的媒体流友好，还是想让已经有速率限制的媒体流对TCP友好。引用Andrew McGregor的话：“TCP友好是不好的，因为它不会带来回报。”如果我们想要的属性没有饥饿、公平和有效的负载，我们只愿意考虑RTP控制的变化，或者我们愿意考虑TCP拥塞控制的变化吗？
This led to a discussion about whether the development of a congestion control algorithm for interactive real-time applications provides any value if network equipment suffers from bufferbloat. Is there something that can be done today to help interactive real-time media or do we have to wait to get the network updated first? Replacing home routers and updating routers with modern AQM algorithms was seen as a longer-term effort. Also, the time scale for changing TCP's congestion control is on the same time scale as deploying ECN [19]. Colin Perkins noted that we cannot change TCP quickly; the way TCP is being used is changing quickly, and we can impact the way TCP is used. When TCP is used for file transfer, it will send data as fast as it can, but when TCP is used for WebSockets, the dynamics are different. WebSockets and SPDY are clearly changing the behavior of TCP. Also, Netflix-style video-streaming applications are huge users of TCP and those applications can change rather quickly. Matt Mathis added that real-time videoconferencing almost always produces video streams at a lower bitrate than downloading equivalent-sized stored video using best-effort file-sharing.
这引发了一场讨论，即如果网络设备出现缓冲区膨胀，为交互式实时应用程序开发拥塞控制算法是否有任何价值。今天是否可以做些什么来帮助交互式实时媒体，还是我们必须先等网络更新？用现代AQM算法替换家庭路由器和更新路由器被视为一项长期努力。此外，更改TCP拥塞控制的时间尺度与部署ECN的时间尺度相同[19]。科林·帕金斯指出，我们无法快速改变TCP；TCP的使用方式正在迅速改变，我们可以影响TCP的使用方式。当TCP用于文件传输时，它将以尽可能快的速度发送数据，但当TCP用于WebSocket时，动态是不同的。WebSocket和SPDY显然正在改变TCP的行为。此外，Netflix风格的视频流应用程序是TCP的巨大用户，这些应用程序的变化相当快。Matt Mathis补充说，实时视频会议几乎总是以比使用尽力而为的文件共享下载同等大小的存储视频更低的比特率生成视频流。
Bill Ver Steeg suggested to consider three different deployment environments, namely:
Bill Ver Steeg建议考虑三种不同的部署环境，即：
1. Flows competing with flows from the host ("self-inflicted queuing delay")
1. 与来自主机的流竞争的流（“自我造成的排队延迟”）
2. Flows competing with flows in the same subnetwork (e.g., home network)
2. 与同一子网（如家庭网络）中的流竞争的流
3. Flows competing with flows from other networks (e.g., traffic from different households that utilize the same DSL provider)
3. 与来自其他网络的流量竞争的流量（例如，来自使用同一DSL提供商的不同家庭的流量）
The narrowest problem domain that makes sense is to avoid self-inflicted queuing delay. Michael Welzl indicated that this requires an information exchange (called flow-state exchange) inside a browser (at the level of the same host or even beyond, as described in [29]) to synchronize congestion control of different audio, video, and data flows. Although it would provide great benefits if one could share information about a bottleneck with all the flows sharing that bottleneck, this is considered challenging even within a single host. John Leslie [30] also noted: "We're acting as if we believe congestion will magically be solved by a new transport algorithm. It won't." Instead, an interaction between the network layer, transport layer, and the application layer is needed whereby the application layer is the only practical place to balance what piece(s) to constrain to lower bandwidths. All flows relating to a user session
最狭隘的问题领域是避免自我造成的排队延迟。Michael Welzl指出，这需要在浏览器内部进行信息交换（称为流状态交换）（如[29]所述，在同一主机或甚至更高级别上），以同步不同音频、视频和数据流的拥塞控制。尽管如果一个人可以与共享瓶颈的所有流共享关于瓶颈的信息，这将带来巨大的好处，但这被认为是一个挑战，即使在单个主机内也是如此。John Leslie[30]还指出：“我们的行为就像我们相信新的传输算法可以神奇地解决拥塞问题一样。事实并非如此。”相反，需要网络层、传输层和应用层之间的交互，应用层是平衡哪一部分的唯一实际场所约束到较低的带宽。与用户会话相关的所有流
should have a common congestion controller. For many applications, audio is much more critical than video. In those cases, the video may back off, but the audio transmission remains unchanged.
应该有一个通用的拥塞控制器。对于许多应用来说，音频比视频更重要。在这些情况下，视频可能会后退，但音频传输保持不变。
Mo Zanaty pointed to the importance of the media start-up behavior, which is an area where the exchange of real-time interactive media is different from a TCP-based file transfer. The instantaneous experience in the first part of a video call is highly determinative of people's perception of the call quality. Vendors are using vague heuristics, for example, data from the last call to figure out what to do on the next call. Lars Eggert highlighted that the start-up behavior of an application affects ongoing performance of other flows if, for example, an application blasts at line rate at the beginning of a video stream. You need to start slow enough to not cause congestion to others. Randell Jesup argued that for an interactive real-time video application, you really need to have most of your bandwidth right away. Colin Perkins agreed and added that on startup you need good quality video quickly, but perhaps not as quickly as voice. The requirements are likely going to be different from audio to video and maybe even vary between different applications. Various protocol exchanges take place before media is exchanged between endpoints (such as Session Traversal Utilities for NAT (STUN) packets [13] as part of the Interactive Connectivity Establishment (ICE) [15] or a Datagram Transport Layer Security (DTLS) handshake [14]) and may be used to obtain simple start-up measurements.
Mo Zanaty指出了媒体启动行为的重要性，这是一个实时交互媒体交换不同于基于TCP的文件传输的领域。视频通话第一部分的即时体验在很大程度上决定了人们对通话质量的感知。供应商正在使用模糊的启发式方法，例如，上一次呼叫的数据，以确定下一次呼叫的操作。Lars Eggert强调，如果应用程序在视频流开始时以行速率爆炸，则应用程序的启动行为会影响其他流的持续性能。您需要足够慢地启动，以免给其他人造成拥堵。Randell Jesup认为，对于交互式实时视频应用程序，您确实需要立即获得大部分带宽。科林·帕金斯对此表示同意，并补充说，在创业之初，你们需要的是高质量的视频，但速度可能不如语音快。从音频到视频，要求可能会有所不同，甚至可能在不同的应用程序之间有所不同。各种协议交换在端点之间交换媒体之前发生（例如，作为交互式连接建立（ICE）[15]或数据报传输层安全（DTLS）握手[14]的一部分的NAT（STUN）数据包的会话遍历实用程序[13]），并可用于获得简单的启动测量。
The group agreed that it is feasible to design a congestion control algorithm that works on mostly idle networks. In the view of the participants, upgrades of the network infrastructure can happen in parallel. This view was later confirmed at the RTP Media Congestion Avoidance Techniques (RMCAT) BoF meeting at IETF 84 (July 29 - August 3, 2012, Vancouver, BC, Canada) that led to the formation of the RMCAT working group [34].
该小组一致认为，设计一种适用于大部分空闲网络的拥塞控制算法是可行的。在参与者看来，网络基础设施的升级可以并行进行。这一观点后来在IETF 84（2012年7月29日至8月3日，加拿大不列颠哥伦比亚省温哥华）召开的RTP媒体拥塞避免技术（RMCAT）BoF会议上得到证实，该会议促成了RMCAT工作组的成立[34]。
The participants suggested to explore two primary solution tracks: changes to network infrastructure and the development of algorithms to avoid self-inflicted queuing. These are discussed below. A third approach recommended by some participants was to change the way TCP is used in browsers and other HTTP-based applications. For example, by not opening too many concurrent TCP connections, and by improving the interaction with other non-real-time applications (such as video streaming and file sharing), additional improvements can be made. The work on HTTP 2.0 with SPDY [16] is already a step in the right direction since SPDY makes use of a more aggressive form of multiplexing instead of opening a larger number of TCP connections.
与会者建议探索两个主要的解决途径：改变网络基础设施和开发避免自我造成排队的算法。下文将讨论这些问题。一些参与者推荐的第三种方法是改变TCP在浏览器和其他基于HTTP的应用程序中的使用方式。例如，通过不打开太多并发TCP连接，并通过改进与其他非实时应用程序（如视频流和文件共享）的交互，可以进行其他改进。使用SPDY[16]开发HTTP 2.0已经是朝着正确方向迈出的一步，因为SPDY使用了更积极的多路复用形式，而不是打开更多的TCP连接。
As for all other traffic on the network, better data plane infrastructure improves the perceived quality of the best-effort service that the Internet provides for RTCWEB flows. The IETF has already developed several technologies that would be of immediate usefulness if they were to be deployed. The workshop participants expressed the hope that due to the volume and importance of RTCWEB traffic, some of these technologies might finally see widespread use.
对于网络上的所有其他流量，更好的数据平面基础设施可以提高互联网为RTCWEB流提供的尽力而为服务的感知质量。IETF已经开发了几种技术，如果部署这些技术，它们将立即发挥作用。研讨会参与者表示希望，由于RTCWEB流量的数量和重要性，其中一些技术最终可能会得到广泛使用。
The first and by far most important improvement is traffic segregation: the ability to use different queues for different traffic types. Specifically, jitter- and delay-sensitive protocols would benefit from being in different queues from throughput-maximizing protocols. It is not possible for a single queue/AQM to be optimal for both.
第一个也是迄今为止最重要的改进是流量隔离：能够为不同的流量类型使用不同的队列。具体来说，抖动和延迟敏感协议将受益于吞吐量最大化协议的不同队列。单个队列/AQM不可能对两者都是最优的。
Furthermore, ECN allows routers along the end-to-end path to signal the onset of congestion and allows applications to respond early, avoiding losses and keeping queue sizes short and, therefore, end-to-end delay low. ECN is implemented on some end system stacks and routers, but is frequently not enabled. The participants expressed the importance of increasing the deployment of ECN, even if used initially only in closed environments, such as data centers (as with Data Center TCP (DCTCP) [26]).
此外，ECN允许沿端到端路径的路由器发出拥塞开始的信号，并允许应用程序提前响应，避免丢失并保持队列大小较短，因此端到端延迟较低。ECN在一些终端系统堆栈和路由器上实现，但通常未启用。与会者表示了增加ECN部署的重要性，即使最初仅在封闭环境中使用，如数据中心（如数据中心TCP（DCTCP）[26]）。
Different mechanisms have been developed to facilitate traffic segregation. Differentiated Services [10] is one possibility in this space. If applications start to mark outgoing traffic appropriately and routers segregate traffic accordingly, browsers could more directly control the relative importance of their various flows and avoid self-competition. Compared to ECN, however, DiffServ is far more difficult to deploy meaningfully end to end, especially given that Differentiated Services Code Points (DSCPs) have no defined end-to-end meaning and packets can be re-marked.
已经制定了不同的机制来促进交通隔离。差异化服务[10]是这一领域的一种可能性。如果应用程序开始适当地标记传出流量，路由器相应地隔离流量，浏览器可以更直接地控制其各种流量的相对重要性，避免自我竞争。然而，与ECN相比，DiffServ更难有意义地部署端到端，特别是考虑到区分服务代码点（DSCP）没有定义的端到端含义，并且数据包可以重新标记。
QoS signaling together with resource reservation facilities would enable a fine-grained and flexible way to indicate resource needs to network elements, but it is also by far the most heavyweight proposal, and unlikely to be viable in the global Internet. However, as mentioned in Section 2.3, QoS signaling is not the only way to accomplish traffic segregation. Further investigations regarding stochastic fair queuing and new AQM algorithms are seen as desirable.
QoS信令和资源预留设施将能够以细粒度和灵活的方式向网元指示资源需求，但它也是迄今为止最重要的建议，在全球互联网上不太可能可行。然而，如第2.3节所述，QoS信令并不是实现流量隔离的唯一方法。关于随机公平排队和新的AQM算法的进一步研究被认为是可取的。
In any case, network infrastructure updates will take time, particularly if the interest of the involved stakeholders is not aligned (as is often the case for network operators when dealing with
在任何情况下，网络基础设施更新都需要时间，特别是当相关利益相关者的利益不一致时（网络运营商在处理
over-the-top real-time traffic). It is, therefore, imperative that RTCWEB congestion control provides adequate improvement in the absence of any of the aforementioned schemes.
超顶级实时流量）。因此，在没有任何上述方案的情况下，RTCWEB拥塞控制必须提供充分的改进。
This approach tries to ensure that the network does not suffer from congestion collapse and that one data flow from a single host does not harm another data flow from the same host. A single congestion manager within the end host or the browser could help to coordinate various congestion control activities and to ensure a more coordinated approach between different applications and different flows.
这种方法试图确保网络不会发生拥塞崩溃，并且来自单个主机的一个数据流不会损害来自同一主机的另一个数据流。终端主机或浏览器中的单个拥塞管理器可以帮助协调各种拥塞控制活动，并确保不同应用程序和不同流之间采用更协调的方法。
The following design and testing aspects were considered relevant to this approach:
以下设计和测试方面被认为与该方法相关：
Reacting to All Congestion Signals:
对所有拥堵信号作出反应：
To initiate the congestion control process, it is important to detect congestion in the communication path. Congestion can be detected using either an explicit mechanism or an implicit mechanism. An explicit mechanism involves direct congestion signaling usually from the congested network node, such as ECN. In case of an implicit mechanism, packet-loss events or observed delay increases are used as an indication for congestion. These measurements can also be made available in a variety of different protocols, such as RTCP reports or transport protocols. It is recommended for applications to take all available congestion signals into account and to couple the congestion control algorithm, the codec, and the application so that better information exchange between these components is possible since there are constraints on how quickly a codec can adapt to a specific sending rate.
为了启动拥塞控制过程，检测通信路径中的拥塞非常重要。可以使用显式机制或隐式机制检测拥塞。显式机制包括通常来自拥塞网络节点（如ECN）的直接拥塞信令。在隐式机制的情况下，丢包事件或观察到的延迟增加被用作拥塞的指示。这些测量也可以在各种不同的协议中提供，例如RTCP报告或传输协议。建议应用程序将所有可用的拥塞信号考虑在内，并将拥塞控制算法、编解码器和应用程序耦合起来，以便在这些组件之间进行更好的信息交换，因为编解码器适应特定发送速率的速度受到限制。
Delay- and Loss-Based Algorithms:
基于延迟和损耗的算法：
The main goal of designing a congestion control algorithm for real-time conversational media is to achieve low latency. Explicit congestion signals provide the most reliable way for applications to react, but due to the lack of ECN deployment, delay-based algorithms are needed. Since there is large delay variation in wireless networks (even in a non-congested network), the workshop participants recommended that more research should be done to better understand non-congestion-related delay variation in the network. General consensus among the workshop participants was that latency-based congestion control algorithms are needed
为实时会话媒体设计拥塞控制算法的主要目标是实现低延迟。显式拥塞信号为应用程序提供了最可靠的反应方式，但由于缺乏ECN部署，需要基于延迟的算法。由于无线网络（即使在非拥塞网络中）存在较大的延迟变化，研讨会参与者建议进行更多研究，以更好地了解网络中与非拥塞相关的延迟变化。研讨会参与者的普遍共识是，需要基于延迟的拥塞控制算法
due to the lack of loss indications caused by large buffers, even though loss-based techniques dominate latency-based techniques when the two are competing for bandwidth.
由于缺少由大缓冲区引起的丢失指示，即使基于丢失的技术在二者争夺带宽时主导基于延迟的技术。
Algorithm Evaluation:
算法评估：
The Internet consists of heterogeneous networks, which include misconfigured and unmanaged network nodes. Bandwidth and latency vary a lot. Different services deployed using RTP/UDP have different requirements in terms of media quality. A congestion control algorithm needs to perform well not only in simulators but also in the deployed Internet. To achieve this, it is recommended to test the algorithms with real-world loss and delay figures to ensure that the desired audio/video rates are attainable using the proposed algorithms for the desired services.
Internet由异构网络组成，其中包括配置错误和未管理的网络节点。带宽和延迟变化很大。使用RTP/UDP部署的不同服务在媒体质量方面有不同的要求。拥塞控制算法不仅需要在模拟器中表现良好，还需要在部署的Internet中表现良好。为了实现这一点，建议使用真实世界的损耗和延迟数字测试算法，以确保使用针对所需服务的拟议算法可以达到所需的音频/视频速率。
Media Characteristics:
媒体特征：
Interactive real-time voice and video data are inherently variable. Usually the content of the media and service requirements dictate the media coding. The codec may be bursty and not all frames are equally important (e.g., I-frames are more important than P-frames). Thus, codecs have limited room for adaptation. Congestion control for audio and video codecs is, therefore, different from congestion control applied to bulk file transfers where buffering is not a problem and the transmission rate can be changed to any rate suitable for the congestion control algorithm. In the workshop, these limitations were brought up and the workshop participants recommended that a congestion controller needs to be aware of these constraints. However, further investigation is needed to decide what information needs to be exchanged between a codec and the congestion manager.
交互式实时语音和视频数据本质上是可变的。通常，媒体内容和服务要求决定媒体编码。编解码器可能是突发的，并且并非所有帧都同等重要（例如，I帧比P帧更重要）。因此，编解码器的适应空间有限。因此，音频和视频编解码器的拥塞控制不同于应用于批量文件传输的拥塞控制，在批量文件传输中，缓冲不是问题，传输速率可以更改为适合拥塞控制算法的任何速率。在研讨会上，与会者提出了这些限制，并建议拥塞控制器需要了解这些限制。然而，需要进一步的调查来确定编解码器和拥塞管理器之间需要交换哪些信息。
Start-up Behavior:
启动行为：
The start-up media quality is very important for real-time interactive applications and for user-perceived application performance. The start-up behavior of these is also different from other traffic. By nature, real-time interactive communication applications want to provide a smooth user experience and maintain the best media quality possible to ease the interaction. While it may be desirable from a user-experience point of view to immediately start streaming video with high-definition quality and audio of a wideband codec, this will have impacts on the bandwidth of the already ongoing flows. As such,
启动媒体质量对于实时交互应用程序和用户感知的应用程序性能非常重要。这些流量的启动行为也不同于其他流量。从本质上讲，实时交互通信应用程序希望提供流畅的用户体验，并保持尽可能好的媒体质量，以简化交互。虽然从用户体验的角度来看，立即开始具有宽带编解码器的高清晰度质量和音频的流式视频可能是可取的，但这将对已经在进行的流的带宽产生影响。像这样的
it would be ideal to start slow enough to avoid causing excessive congestion to other flows but fast enough to offer a good user experience. The sweet spot, however, yet has to be found.
最好启动速度足够慢，以避免对其他流造成过度拥塞，但速度足够快，以提供良好的用户体验。然而，目前还没有找到最佳点。
Two position papers focused on security, but these papers were not discussed during the workshop. As such, nothing beyond the material contained in those position papers can be reported.
两份立场文件侧重于安全问题，但研讨会期间没有讨论这些文件。因此，除了这些立场文件中所载的材料外，无法报告任何内容。
We would like to thank the participants and the paper authors of the position papers for their input.
我们要感谢参与者和立场论文的作者的投入。
Additionally, we would like to thank the following persons for their review comments: Michael Welzl, John Leslie, Mirja Kuehlewind, Matt Mathis, Mary Barnes, Spencer Dawkins, Dave Thaler, and Alissa Cooper.
此外，我们还要感谢以下人士的评论：Michael Welzl、John Leslie、Mirja Kuehlewind、Matt Mathis、Mary Barnes、Spencer Dawkins、Dave Thaler和Alissa Cooper。
[1] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, November 2008.
[1] Eggert，L.和G.Fairhurst，“应用程序设计者的单播UDP使用指南”，BCP 145，RFC 5405，2008年11月。
[2] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
[2] Floyd，S.，“拥塞控制原则”，BCP 41，RFC 2914，2000年9月。
[3] Perkins, C. and V. Singh, "Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions", Work in Progress, February 2014.
[3] Perkins，C.和V.Singh，“多媒体拥塞控制：单播RTP会话的断路器”，正在进行的工作，2014年2月。
[4] Welzl, M., Damjanovic, D., and S. Gjessing, "MulTFRC: TFRC with weighted fairness", Work in Progress, July 2010.
[4] Welzl，M.，Damjanovic，D.，和S.Gjessing，“MulTFRC：加权公平的TFRC”，正在进行的工作，2010年7月。
[5] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006.
[5] Ott，J.，Wenger，S.，Sato，N.，Burmeister，C.，和J.Rey，“基于实时传输控制协议（RTCP）的反馈（RTP/AVPF）的扩展RTP配置文件”，RFC 45852006年7月。
[6] Nichols, K. and V. Jacobson, "Controlled Delay Active Queue Management", Work in Progress, March 2014.
[6] Nichols，K.和V.Jacobson，“受控延迟主动队列管理”，正在进行的工作，2014年3月。
[7] Schulzrinne, H., Johnston, W., and J. Miller, "Large-Scale Measurement of Broadband Performance: Use Cases, Architecture and Protocol Requirements", Work in Progress, September 2012.
[7] Schulzrinne，H.，Johnston，W.和J.Miller，“宽带性能的大规模测量：用例、架构和协议要求”，正在进行的工作，2012年9月。
[8] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, December 2012.
[8] Shalunov，S.，Hazel，G.，Iyengar，J.，和M.Kuehlewind，“低额外延迟背景传输（LEDBAT）”，RFC 68172012年12月。
[9] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, J., and L. Zhang, "Recommendations on Queue Management and Congestion Avoidance in the Internet", RFC 2309, April 1998.
[9] Braden，B.，Clark，D.，Crowcroft，J.，Davie，B.，Deering，S.，Estrin，D.，Floyd，S.，Jacobson，V.，Minshall，G.，Partridge，C.，Peterson，L.，Ramakrishnan，K.，Shenker，S.，Wroclawski，J.，和L.Zhang，“关于互联网中队列管理和拥塞避免的建议”，RFC 2309，1998年4月。
[10] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[10] Blake，S.，Black，D.，Carlson，M.，Davies，E.，Wang，Z.，和W.Weiss，“差异化服务架构”，RFC 24751998年12月。
[11] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., and K. Carlberg, "Explicit Congestion Notification (ECN) for RTP over UDP", RFC 6679, August 2012.
[11] Westerlund，M.，Johansson，I.，Perkins，C.，O'Hanlon，P.，和K.Carlberg，“UDP上RTP的显式拥塞通知（ECN）”，RFC 6679，2012年8月。
[12] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 5348, September 2008.
[12] Floyd，S.，Handley，M.，Padhye，J.，和J.Widmer，“TCP友好速率控制（TFRC）：协议规范”，RFC 5348，2008年9月。
[13] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[13] Rosenberg，J.，Mahy，R.，Matthews，P.，和D.Wing，“NAT（STUN）的会话遍历实用程序”，RFC 5389，2008年10月。
[14] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012.
[14] Rescorla，E.和N.Modadugu，“数据报传输层安全版本1.2”，RFC 6347，2012年1月。
[15] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.
[15] Rosenberg，J.，“交互式连接建立（ICE）：提供/应答协议的网络地址转换器（NAT）遍历协议”，RFC 52452010年4月。
[16] Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer Protocol version 2", Work in Progress, June 2014.
[16] Belshe，M.，Pain，R.，和M.Thomson，“超文本传输协议版本2”，正在进行的工作，2014年6月。
[17] Floyd, S. and J. Kempf, "IAB Concerns Regarding Congestion Control for Voice Traffic in the Internet", RFC 3714, March 2004.
[17] Floyd，S.和J.Kempf，“IAB对互联网语音流量拥塞控制的关注”，RFC 3714，2004年3月。
[18] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, "Increasing TCP's Initial Window", RFC 6928, April 2013.
[18] Chu，J.，Dukkipati，N.，Cheng，Y.，和M.Mathis，“增加TCP的初始窗口”，RFC 69282013年4月。
[19] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[19] Ramakrishnan，K.，Floyd，S.，和D.Black，“向IP添加显式拥塞通知（ECN）”，RFC 3168，2001年9月。
[20] Zanaty, M., "Fairness Considerations for Congestion Control for Interactive Real-Time Communication (IRTC)", IAB/ RTF Workshop on Congestion Control for Interactive Real-Time Communication, July 2012.
[20] Zanaty，M.，“交互式实时通信（IRTC）拥塞控制的公平性考虑”，IAB/RTF交互式实时通信拥塞控制研讨会，2012年7月。
[21] Sarker, Z. and I. Johansson, "Improving the Interactive Real-Time Video Communication with Network Provided Congestion Notification", IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication, July 2012.
[21] Sarker，Z.和I.Johansson，“利用网络提供的拥塞通知改进交互式实时视频通信”，IAB/IRTF交互式实时通信拥塞控制研讨会，2012年7月。
[22] Winstein, K., Sivaraman, A., and H. Balakrishnan, "Congestion Control for Interactive Real-Time Flows on Today's Internet", IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication, July 2012.
[22] Winstein，K.，Sivaraman，A.，和H.Balakrishnan，“当今互联网上交互式实时流的拥塞控制”，IAB/IRTF交互式实时通信拥塞控制研讨会，2012年7月。
[23] Jarvinen, I., Ding, A., Nyrhinen, A., and M. Kojo, "Harsh RED: Improving RED for Limited Aggregate Traffic", In Proceedings of the 26th IEEE International Conference on Advanced Information Networking and Applications (AINA 2012), March 2012.
[23] Jarvinen，I.，Ding，A.，Nyrhinen，A.，和M.Kojo，“刺眼的红色：改善有限总流量的红色”，第26届IEEE高级信息网络和应用国际会议记录（AINA 2012），2012年3月。
[24] Allman, M., "Comments on Bufferbloat", In ACM SIGCOMM Computer Communication Review, Volume 43, Issue 1, pp. 30-37, January 2013, <http://dl.acm.org/citation.cfm?doid=2427036.2427041>.
[24] Allman，M.，“关于缓冲区膨胀的评论”，《ACM SIGCOMM计算机通信评论》，第43卷，第1期，第30-37页，2013年1月<http://dl.acm.org/citation.cfm?doid=2427036.2427041>.
[25] Bauer, S., Beverly, R., and A. Berger, "Measuring the state of ECN readiness in servers, clients,and routers", In Proceedings of the 2011 ACM SIGCOMM conference on Internet measurement conference (IMC '11), New York, NY, USA, pp. 171-180, February 2011, <http://dl.acm.org/citation.cfm?doid=2068816.2068833>.
[25] Bauer，S.，Beverly，R.，和A.Berger，“测量服务器、客户端和路由器中的ECN就绪状态”，摘自2011年ACM SIGCOMM互联网测量会议记录（IMC'11），美国纽约州纽约市，第171-180页，2011年2月<http://dl.acm.org/citation.cfm?doid=2068816.2068833>.
[26] Bauer, S., Greenberg, A., Maltz, D., Padhye, J., Patel, P., Prabhakar, B., Sengupta, S., and M. Sridharan, "Data center TCP (DCTCP)", In Proceedings of the ACM SIGCOMM 2010 conference (SIGCOMM '10), New York, NY, USA, pp. 63-74, August 2010, <http://dl.acm.org/citation.cfm?doid=1851182.1851192>.
[26] Bauer，S.，Greenberg，A.，Maltz，D.，Padhye，J.，Patel，P.，Prabhakar，B.，Sengupta，S.，和M.Sridharan，“数据中心TCP（DCTCP）”，摘自美国纽约ACM SIGCOMM 2010年会议记录（SIGCOMM'10），第63-74页，2010年8月<http://dl.acm.org/citation.cfm?doid=1851182.1851192>.
[27] Jarvinen, I., Chemmagate, B., Daniel, L., Ding, A., Kojo, M., and M. Isomaki, "Impact of TCP on Interactive Real- Time Communication", IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication, July 2012.
[27] I.Jarvinen，Chemmagate，B.，Daniel，L.，Ding，A.，Kojo，M.，和M.Isomaki，“TCP对交互式实时通信的影响”，IAB/IRTF交互式实时通信拥塞控制研讨会，2012年7月。
[28] Jennings, C., Nandakumar, S., and H. Phan, "Vendors Considered Harmfull", IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication, July 2012.
[28] Jennings，C.，Nandakumar，S.，和H.Phan，“被认为有害的供应商”，IAB/IRTF交互式实时通信拥塞控制研讨会，2012年7月。
[29] Welzl, M., "One control to rule them all", IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication, July 2012.
[29] Welzl，M.，“一个控制来控制所有控制”，IAB/IRTF交互式实时通信拥塞控制研讨会，2012年7月。
[30] Leslie, J., "There is No Magic Transport Wand", IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication, July 2012.
[30] Leslie，J.，“没有神奇的交通棒”，IAB/IRTF互动实时通信拥塞控制研讨会，2012年7月。
[31] Gettys, J. and J. Gettys, "Bufferbloat: Dark Buffers in the Internet", IEEE Internet Computing, Volume 15, Issue 3, pp. 95-96, May/June 2011.
[31] Gettys，J.和J.Gettys，“缓冲区膨胀：互联网中的暗缓冲区”，IEEE互联网计算，第15卷，第3期，第95-96页，2011年5月/6月。
[32] Feng, W., Shin, K., Kandlur, D., and D. Saha, "The BLUE active queue management algorithms", In IEEE/ACM Transactions on Networking, Volume 10, Issue 4, pp. 513-528, August 2002.
[32] Feng，W.，Shin，K.，Kandlur，D.，和D.Saha，“蓝色主动队列管理算法”，载于IEEE/ACM网络事务，第10卷，第4期，第513-528页，2002年8月。
[33] IETF, "IP Performance Metrics (ippm) Working Group", January 2012, <http://datatracker.ietf.org/wg/ippm/charter/>.
[33] IETF，“IP性能度量（ippm）工作组”，2012年1月<http://datatracker.ietf.org/wg/ippm/charter/>.
[34] IETF, "RTP Media Congestion Avoidance Techniques (rmcat) Working Group", January 2012, <http://datatracker.ietf.org/wg/rmcat/charter/>.
[34] IETF，“RTP媒体拥塞避免技术（rmcat）工作组”，2012年1月<http://datatracker.ietf.org/wg/rmcat/charter/>.
[35] IETF, "Active Queue Management and Packet Scheduling (aqm) Working Group", September 2013, <http://datatracker.ietf.org/wg/aqm/charter/>.
[35] IETF，“主动队列管理和数据包调度（aqm）工作组”，2013年9月<http://datatracker.ietf.org/wg/aqm/charter/>.
[36] Gettys, J. and K. Nichols, "Bufferbloat: Dark Buffers in the Internet", Communications of the ACM, Vol. 55, No. 1, pp. 57-65, January 2012, <http://cacm.acm.org/magazines/2012/1/144810-bufferbloat/>.
[36] Gettys，J.和K.Nichols，“缓冲膨胀：互联网中的黑暗缓冲”，ACM通讯，第55卷，第1期，第57-65页，2012年1月<http://cacm.acm.org/magazines/2012/1/144810-bufferbloat/>.
[37] Jacobson, V., "pathchar - a tool to infer characteristics of Internet paths", Presented at the Mathematical Sciences Research Institute, April 1997, <ftp://ftp.ee.lbl.gov/pathchar/msri-talk.pdf>.
[37] Jacobson，V.，“pathchar-推断互联网路径特征的工具”，在数学科学研究所发表，1997年4月<ftp://ftp.ee.lbl.gov/pathchar/msri-talk.pdf>.
[38] McKenney, P., "Stochastic Fairness Queuing", In IEEE INFOCOM'90 Proceedings, Volume 2, pp. 733-740, June 1990.
[38] McKenney，P.，“随机公平排队”，载于IEEE INFOCOM'90会议录，第2卷，第733-740页，1990年6月。
[39] Wikipedia, "Bufferbloat", May 2014, <http://en.wikipedia.org/w/ index.php?title=Bufferbloat&oldid=608805474>.
[39] 维基百科，“Bufferbloat”，2014年5月<http://en.wikipedia.org/w/ index.php？title=Bufferbloat&oldid=608805474>。
[40] Wikipedia, "Video compression picture types", March 2014, <http://en.wikipedia.org/w/index.php? title=Video_compression_picture_types&oldid=602183340>.
[40] 维基百科，“视频压缩图片类型”，2014年3月<http://en.wikipedia.org/w/index.php? title=Video\u compression\u picture\u types&oldid=602183340>。
[41] FCC, "Methodology - Measuring Broadband America July Report 2012", July 2012, <http://www.fcc.gov/ measuring-broadband-america/2012/methodology-july-report-2012>.
[41] FCC，“2012年7月美国宽带测量方法报告”，2012年7月<http://www.fcc.gov/ 测量宽带美国/2012/methodology-july-report-2012>。
[42] IETF, "lmap -- Large Scale Measurement of Access network Performance Mailing List", 2012, <https://www.ietf.org/mailman/listinfo/lmap>.
[42] IETF，“lmap——接入网性能的大规模测量邮件列表”，2012年<https://www.ietf.org/mailman/listinfo/lmap>.
[43] Holmer, S., "On Fairness, Delay and Signaling of Different Approaches to Real-time Congestion Control", IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication, July 2012.
[43] Holmer，S.，“实时拥塞控制不同方法的公平性、延迟和信令”，IAB/IRTF交互式实时通信拥塞控制研讨会，2012年7月。
This workshop was organized by Harald Alvestrand, Bernard Aboba, Mary Barnes, Gonzalo Camarillo, Spencer Dawkins, Lars Eggert, Matthew Ford, Randell Jesup, Cullen Jennings, Jon Peterson, Robert Sparks, and Hannes Tschofenig.
本次研讨会由哈拉尔·阿尔维斯特朗、伯纳德·阿博巴、玛丽·巴恩斯、冈萨洛·卡马里洛、斯宾塞·道金斯、拉尔斯·艾格特、马修·福特、兰德尔·杰苏普、卡伦·詹宁斯、乔恩·彼得森、罗伯特·斯帕克斯和汉内斯·茨霍芬尼组织。
o Main Workshop Page: http://www.iab.org/activities/workshops/cc-workshop/
o 车间主页：http://www.iab.org/activities/workshops/cc-workshop/
o Position Papers: http://www.iab.org/activities/workshops/cc-workshop/papers/
o 立场文件：http://www.iab.org/activities/workshops/cc-workshop/papers/
o Slides: http://www.iab.org/activities/workshops/cc-workshop/slides/
o 幻灯片：http://www.iab.org/activities/workshops/cc-workshop/slides/
1. "One control to rule them all" by Michael Welzl
1. 迈克尔·韦尔兹尔的《一个控制来统治一切》
2. "Congestion Avoidance Through Deterministic" by Pier Luca Montessoro, Riccardo Bernardini, Franco Blanchini, Daniele Casagrande, Mirko Loghi, and Stefan Wieser
2. Pier Luca Montessoro、Riccardo Bernardini、Franco Blanchini、Daniele Casagrande、Mirko Loghi和Stefan Wieser的“通过确定性避免拥堵”
3. "Congestion Control in Real Time Media - Context" by Harald Alvestrand
3. Harald Alvestrand的“实时媒体环境中的拥塞控制”
4. "Improving the Interactive Real-Time Video Communication with Network Provided Congestion Notification" by ANM Zaheduzzaman Sarker and Ingemar Johansson
4. ANM Zaheduzzaman Sarker和Ingemar Johansson的“利用网络提供的拥塞通知改进交互式实时视频通信”
5. "Multiparty Requirements in Congestion Control for Real-Time Interactive Media" by Magnus Westerlund
5. Magnus Westerlund的“实时交互媒体拥塞控制中的多方要求”
6. "On Fairness, Delay and Signaling of Different Approaches to Real-time Congestion Control" by Stefan Holmer
6. Stefan Holmer的“不同实时拥塞控制方法的公平性、延迟和信令”
7. "RTP Congestion Control and RTCWEB Application Feedback" by Ted Hardie
7. Ted Hardie的“RTP拥塞控制和RTCWEB应用程序反馈”
8. "Issues with Using Packet Delays and Inter-arrival Times for Inference of Internet Congestion" by Wesley M. Eddy
8. Wesley M.Eddy的“使用数据包延迟和到达时间推断互联网拥塞的问题”
9. "Impact of TCP on Interactive Real-Time Communication" by Ilpo Jarvinen, Binoy Chemmagate, Laila Daniel, Aaron Yi Ding, Markku Kojo, and Markus Isomaki
9. Ilpo Jarvinen、Binoy Chemmagate、Laila Daniel、Aaron Yi Ding、Markku Kojo和Markus Isomaki合著的“TCP对交互式实时通信的影响”
10. "Security Concerns For RTCWEB Congestion Control" by Dan York
10. Dan York的“RTCWEB拥塞控制的安全问题”
11. "Vendors Considered Harmfull" by Cullen Jennings, Suhas Nandakumar, and Hein Phan
11. Cullen Jennings、Suhas Nandakumar和Hein Phan的“被认为有害的供应商”
12. "Network-Assisted Dynamic Adaptation" by Xiaoqing Zhu and Rong Pan
12. 朱晓青、潘蓉的“网络辅助动态适应”
13. "Congestion Control for Interactive Real-Time Applications" by Sanjeev Mehrotra and Jin Li
13. Sanjeev Mehrotra和Jin Li的“交互式实时应用的拥塞控制”
14. "There is No Magic Transport Wand" by John Leslie
14. 约翰·莱斯利的《没有魔法运输棒》
15. "Towards Adaptive Congestion Management for Interactive Real-Time Communications" by Dirk Kutscher and Miriam Kuehlewind
15. Dirk Kutscher和Miriam Kuehlewind的“面向交互式实时通信的自适应拥塞管理”
16. "Enlarge the pre-congestion spectrum usage?" by Xavier Marjou and Emile Stephan
16. “扩大拥塞前频谱使用？”由Xavier Marjou和Emile Stephan撰写
17. "Congestion control for users who don't have first-class internet access" by Maire Reavy
17. Maire Reavy的“没有一流互联网接入的用户的拥塞控制”
18. "Realtime Congestion Challenges" by Randell Jesup
18. Randell Jesup的“实时拥塞挑战”
19. "Congestion Control for Interactive Media: Control Loops & APIs" by Varun Singh, Joerg Ott, and Colin Perkins
19. Varun Singh、Joerg Ott和Colin Perkins的“交互式媒体的拥塞控制：控制循环和API”
20. "Some Notes on Threat Modelling Congestion Management" by Eric Rescorla
20. Eric Rescorla的“关于威胁建模拥塞管理的一些注释”
21. "Timely Detection of Lost Packets" by Ali C. Begen
21. Ali C.Begen的“及时检测丢失的数据包”
22. "Congestion Control Considerations for Data Channels" by Michael Tuexen
22. Michael Tuexen的“数据通道的拥塞控制考虑”
23. "Position paper on CC for Interactive RT" by Matt Mathis
23. Matt Mathis的“交互式RT的CC立场文件”
24. "Overall Considerations for Congestion Control" by Mo Zanaty, Bill VerSteeg, Bent Christensen, David Benham, and Allyn Romanow
24. Mo Zanaty、Bill VerSteeg、Bent Christensen、David Benham和Allyn Romanow的《拥堵控制的总体考虑》
25. "Fairness Considerations for Congestion Control" by Mo Zanaty
25. Mo Zanaty的“拥塞控制的公平考虑”
26. "Media is not Data: The Meaning of Fairness for Competing Multimedia Flows" by Timothy B. Terriberry
26. Timothy B.Terriberry的《媒体不是数据：竞争多媒体流的公平意义》
27. "Thoughts on Real-Time Congestion Control" by Murari Sridharan
27. Murari Sridharan的“关于实时拥塞控制的思考”
28. "Congestion Control for Interactive Real-Time Flows on Today's Internet" by Keith Winstein, Anirudh Sivaraman, and Hari Balakrishnan
28. Keith Winstein、Anirudh Sivaraman和Hari Balakrishnan的《当今互联网上交互式实时流的拥塞控制》
29. "Congestion Control Principles for CoAP" by Carsten Bormann and Klaus Hartke
29. Carsten Bormann和Klaus Hartke的“CoAP拥塞控制原则”
30. "Erasure Coding and Congestion Control for Interactive Real-Time Communication" by Pierre-Ugo Tournoux, Tuan Tran Thai, Emmanuel Lochin, Jerome Lacan, and Vincent Roca
30. Pierre Ugo Tournoux、Tuan Tran Thai、Emmanuel Lochin、Jerome Lacan和Vincent Roca的“交互式实时通信的擦除编码和拥塞控制”
31. "Video Conferencing Specific Considerations for RTP Congestion Control" by Stephen Botzko and Mary Barnes
31. Stephen Botzko和Mary Barnes的“RTP拥塞控制的视频会议特定注意事项”
32. "The Internet is Broken, and How to Fix It" by Jim Gettys
32. 吉姆·盖蒂斯的《互联网坏了，如何修复》
33. "Deployment Considerations for Congestion Control in Real-Time Interactive Media Systems" by Jari Arkko
33. Jari Arkko的“实时交互媒体系统中拥塞控制的部署考虑”
We would like to thank the following workshop participants for attending the workshop:
我们感谢以下研讨会参与者参加研讨会：
o Mat Ford o Bernard Aboba o Alissa Cooper o Mary Barnes o Lars Eggert o Harald Alvestrand o Gonzalo Camarillo o Robert Sparks o Cullen Jennings o Dirk Kutscher o Carsten Bormann o Michael Welzl o Magnus Westerlund o Colin Perkins o Murari Sridharan o Klaus Hartke o Pier Luca Montessoro o Xavier Marjou o Vincent Roca o Wes Eddy o Ali C. Begen o Mo Zanaty o Jin Li o Dave Thaler
o Mat Ford o Bernard Aboba o Alissa Cooper o Mary Barnes o Lars Eggert o Harald Alvestrand o Gonzalo Camarillo o Robert Sparks o Cullen Jennings o Dirk Kutscher o Carsten Bormann o Michael Welzl o Magnus Westerlund o Colin Perkins o Murari Sridharan o Klaus Hartke o Pier Luca Montessoro Xavier Marjou o Vincent Roca o Wes o Eddy o Ali C.Begen o MoZanaty o Jin Li o Dave Thaler
o Bob Briscoe o Barry Leiba o Jari Arkko o Stewart Bryant o Martin Stiemerling o Russ Housley o Marc Blanchet o Zaheduzzaman Sarker o Xiaoqing Zhu o Randell Jesup o Eric Rescorla o Suhas Nandakumar o Hannes Tschofenig o Bill VerSteeg o Sean Turner o Keith Winstein o Jon Peterson o Maire Reavy o Michael Tuexen o Stefan Holmer o Joerg Ott o Timothy Terriberry o Benoit Claise o Ted Hardie o Stephen Botzko o Matt Mathis o David Benham o Jim Gettys o Spencer Dawkins o Sanjeev Mehrotra o Adrian Farrel o Greg White o Markku Kojo
o Bob Briscoe o Barry Leiba o Jari Arkko o Stewart Bryant o Martin Stiemerling o Russ Housley o Marc Blanchet o Zaheduzzaman Sarker o Zhuang o Randell Jesup o Eric Rescorla o Suhas Nandakumar o Hannes Tschofenig o Bill VerSteeg o Sean Turner o Keith Winstein o Jon Peterson o Maire Reavy o Michael Tuexen o Stefan Holmer o Joerg o Timothy特瑞贝里·贝诺特·克莱斯、泰德·哈迪、斯蒂芬·博茨科、马特·马蒂斯、大卫·本汉姆、吉姆·盖蒂、斯宾塞·道金斯、桑吉夫·梅罗特拉、阿德里安·法雷尔、格雷格·怀特、马克库·科乔
We also had remote participants, namely:
我们还有远程参与者，即：
o Emmanuel Lochin o Mark Handley o Anirudh Sivaraman o John Leslie o Varun Singh
o 伊曼纽尔·洛钦、马克·汉德利、阿尼鲁德·西瓦拉曼、约翰·莱斯利、瓦伦·辛格
Authors' Addresses
作者地址
Hannes Tschofenig Hall, Tirol 6060 Austria
奥地利泰罗尔市汉内斯·茨霍芬尼大厅6060
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Lars Eggert Sonnenallee 1 Kirchheim 85551 Germany
德国基尔希海姆1号拉尔斯·埃格特·索内纳利85551
Phone: +49 151 12055791
EMail: lars@netapp.com
URI: http://eggert.org/
Phone: +49 151 12055791
EMail: lars@netapp.com
URI: http://eggert.org/
Zaheduzzaman Sarker Lulea SE-971 28 Sweden
Zaheduzaman Sarker Lulea SE-971 28瑞典
Phone: +46 10 717 37 43
EMail: zaheduzzaman.sarker@ericsson.com
Phone: +46 10 717 37 43
EMail: zaheduzzaman.sarker@ericsson.com