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




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.


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).


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


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 ( 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文件的法律规定的约束(自本文件出版之日起生效。请仔细阅读这些文件,因为它们描述了您对本文件的权利和限制。

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
1. Introduction
1. 介绍

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.


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.


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.


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的应用程序。这些缓冲区引入了额外的通信延迟,这损害了交互式实时应用程序可用的小延迟预算。

2. Workshop Structure
2. 车间结构

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)的主旨演讲,描述了实时媒体拥塞控制工作的历史以及他对当前问题的看法;演示当前问题和解决方案的模拟和数据;以及讨论理想的解决方案属性和部署解决方案时面临的挑战。

2.1. History and Current Challenges
2.1. 历史和当前的挑战

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 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.


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


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.


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.


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.


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.


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."


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声称我们知道如何做好拥塞控制,但只有在拥塞控制负责的情况下,这对于实时应用是不可接受的。只有当我们改变包/秒速率而不是包大小时,我们才知道如何做好拥塞控制。

2.2. Simulations and Measurements
2.2. 模拟和测量

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]研究了基于丢失和基于延迟的拥塞控制算法之间的差异。基于丢失的拥塞控制方案在交互式实时通信系统中的适用性在很大程度上取决于缓冲区大小和主动队列管理机制的部署。如果大多数路由器使用尾部丢弃队列,则基于丢失的拥塞控制无法满足交互式实时应用程序的要求,因为这些流将有效地提高比特率,直到识别丢失事件为止,而丢失事件仅在瓶颈队列满时发生。

2.3. Design Aspects of Problems and Solutions
2.3. 问题和解决方案的设计方面

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].


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.


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).


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]。

3. Recommendations
3. 建议

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连接。

3.1. Changes to Network Infrastructure
3.1. 网络基础设施的变化

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.


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.


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]).


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.


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.


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.


3.2. Avoiding Self-Inflicted Queuing
3.2. 避免自我造成排队

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.


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


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.


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.


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.


4. Security Considerations
4. 安全考虑

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.


5. Acknowledgments
5. 致谢

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。

6. Informative References
6. 资料性引用

[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, <>.

[24] Allman,M.,“关于缓冲区膨胀的评论”,《ACM SIGCOMM计算机通信评论》,第43卷,第1期,第30-37页,2013年1月<>.

[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, <>.

[25] Bauer,S.,Beverly,R.,和A.Berger,“测量服务器、客户端和路由器中的ECN就绪状态”,摘自2011年ACM SIGCOMM互联网测量会议记录(IMC'11),美国纽约州纽约市,第171-180页,2011年2月<>.

[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, <>.

[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月<>.

[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, <>.

[33] IETF,“IP性能度量(ippm)工作组”,2012年1月<>.

[34] IETF, "RTP Media Congestion Avoidance Techniques (rmcat) Working Group", January 2012, <>.

[34] IETF,“RTP媒体拥塞避免技术(rmcat)工作组”,2012年1月<>.

[35] IETF, "Active Queue Management and Packet Scheduling (aqm) Working Group", September 2013, <>.

[35] IETF,“主动队列管理和数据包调度(aqm)工作组”,2013年9月<>.

[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, <>.

[36] Gettys,J.和K.Nichols,“缓冲膨胀:互联网中的黑暗缓冲”,ACM通讯,第55卷,第1期,第57-65页,2012年1月<>.

[37] Jacobson, V., "pathchar - a tool to infer characteristics of Internet paths", Presented at the Mathematical Sciences Research Institute, April 1997, <>.

[37] Jacobson,V.,“pathchar-推断互联网路径特征的工具”,在数学科学研究所发表,1997年4月<>.

[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, < index.php?title=Bufferbloat&oldid=608805474>.

[39] 维基百科,“Bufferbloat”,2014年5月< index.php?title=Bufferbloat&oldid=608805474>。

[40] Wikipedia, "Video compression picture types", March 2014, < title=Video_compression_picture_types&oldid=602183340>.

[40] 维基百科,“视频压缩图片类型”,2014年3月< title=Video\u compression\u picture\u types&oldid=602183340>。

[41] FCC, "Methodology - Measuring Broadband America July Report 2012", July 2012, < measuring-broadband-america/2012/methodology-july-report-2012>.

[41] FCC,“2012年7月美国宽带测量方法报告”,2012年7月< 测量宽带美国/2012/methodology-july-report-2012>。

[42] IETF, "lmap -- Large Scale Measurement of Access network Performance Mailing List", 2012, <>.

[42] IETF,“lmap——接入网性能的大规模测量邮件列表”,2012年<>.

[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月。

Appendix A. Program Committee

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.


Appendix B. Workshop Material

o Main Workshop Page:

o 车间主页:

o Position Papers:

o 立场文件:

o Slides:

o 幻灯片:

Appendix C. Accepted Position Papers

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的“实时交互媒体系统中拥塞控制的部署考虑”

Appendix D. Workshop Participants

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



Lars Eggert Sonnenallee 1 Kirchheim 85551 Germany


   Phone: +49 151 12055791
   Phone: +49 151 12055791

Zaheduzzaman Sarker Lulea SE-971 28 Sweden

Zaheduzaman Sarker Lulea SE-971 28瑞典

   Phone: +46 10 717 37 43
   Phone: +46 10 717 37 43