Internet Engineering Task Force (IETF) I. Johansson
Request for Comments: 8298 Z. Sarker
Category: Experimental Ericsson AB
ISSN: 2070-1721 December 2017
Internet Engineering Task Force (IETF) I. Johansson
Request for Comments: 8298 Z. Sarker
Category: Experimental Ericsson AB
ISSN: 2070-1721 December 2017
Self-Clocked Rate Adaptation for Multimedia
多媒体自时钟速率自适应
Abstract
摘要
This memo describes a rate adaptation algorithm for conversational media services such as interactive video. The solution conforms to the packet conservation principle and uses a hybrid loss-and-delay-based congestion control algorithm. The algorithm is evaluated over both simulated Internet bottleneck scenarios as well as in a Long Term Evolution (LTE) system simulator and is shown to achieve both low latency and high video throughput in these scenarios.
本备忘录描述了交互式视频等对话媒体服务的速率自适应算法。该解决方案符合数据包守恒原理，并使用了基于丢失和延迟的混合拥塞控制算法。该算法在两种模拟的互联网瓶颈场景以及长期演进（LTE）系统模拟器中进行了评估，并在这些场景中实现了低延迟和高视频吞吐量。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
本文档为互联网社区定义了一个实验协议。本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8298.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8298.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Wireless (LTE) Access Properties . . . . . . . . . . . . 4
1.2. Why is it a self-clocked algorithm? . . . . . . . . . . . 5
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
3. Overview of SCReAM Algorithm . . . . . . . . . . . . . . . . 6
3.1. Network Congestion Control . . . . . . . . . . . . . . . 8
3.2. Sender Transmission Control . . . . . . . . . . . . . . . 9
3.3. Media Rate Control . . . . . . . . . . . . . . . . . . . 9
4. Detailed Description of SCReAM . . . . . . . . . . . . . . . 10
4.1. SCReAM Sender . . . . . . . . . . . . . . . . . . . . . . 10
4.1.1. Constants and Parameter Values . . . . . . . . . . . 10
4.1.1.1. Constants . . . . . . . . . . . . . . . . . . . . 11
4.1.1.2. State Variables . . . . . . . . . . . . . . . . . 12
4.1.2. Network Congestion Control . . . . . . . . . . . . . 14
4.1.2.1. Reaction to Packet Loss and ECN . . . . . . . . . 17
4.1.2.2. Congestion Window Update . . . . . . . . . . . . 17
4.1.2.3. Competing Flows Compensation . . . . . . . . . . 20
4.1.2.4. Lost Packet Detection . . . . . . . . . . . . . . 22
4.1.2.5. Send Window Calculation . . . . . . . . . . . . . 23
4.1.2.6. Packet Pacing . . . . . . . . . . . . . . . . . . 24
4.1.2.7. Resuming Fast Increase Mode . . . . . . . . . . . 24
4.1.2.8. Stream Prioritization . . . . . . . . . . . . . . 24
4.1.3. Media Rate Control . . . . . . . . . . . . . . . . . 25
4.2. SCReAM Receiver . . . . . . . . . . . . . . . . . . . . . 28
4.2.1. Requirements on Feedback Elements . . . . . . . . . . 28
4.2.2. Requirements on Feedback Intensity . . . . . . . . . 30
5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 31
6. Suggested Experiments . . . . . . . . . . . . . . . . . . . . 31
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
8. Security Considerations . . . . . . . . . . . . . . . . . . . 32
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
9.1. Normative References . . . . . . . . . . . . . . . . . . 33
9.2. Informative References . . . . . . . . . . . . . . . . . 34
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Wireless (LTE) Access Properties . . . . . . . . . . . . 4
1.2. Why is it a self-clocked algorithm? . . . . . . . . . . . 5
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
3. Overview of SCReAM Algorithm . . . . . . . . . . . . . . . . 6
3.1. Network Congestion Control . . . . . . . . . . . . . . . 8
3.2. Sender Transmission Control . . . . . . . . . . . . . . . 9
3.3. Media Rate Control . . . . . . . . . . . . . . . . . . . 9
4. Detailed Description of SCReAM . . . . . . . . . . . . . . . 10
4.1. SCReAM Sender . . . . . . . . . . . . . . . . . . . . . . 10
4.1.1. Constants and Parameter Values . . . . . . . . . . . 10
4.1.1.1. Constants . . . . . . . . . . . . . . . . . . . . 11
4.1.1.2. State Variables . . . . . . . . . . . . . . . . . 12
4.1.2. Network Congestion Control . . . . . . . . . . . . . 14
4.1.2.1. Reaction to Packet Loss and ECN . . . . . . . . . 17
4.1.2.2. Congestion Window Update . . . . . . . . . . . . 17
4.1.2.3. Competing Flows Compensation . . . . . . . . . . 20
4.1.2.4. Lost Packet Detection . . . . . . . . . . . . . . 22
4.1.2.5. Send Window Calculation . . . . . . . . . . . . . 23
4.1.2.6. Packet Pacing . . . . . . . . . . . . . . . . . . 24
4.1.2.7. Resuming Fast Increase Mode . . . . . . . . . . . 24
4.1.2.8. Stream Prioritization . . . . . . . . . . . . . . 24
4.1.3. Media Rate Control . . . . . . . . . . . . . . . . . 25
4.2. SCReAM Receiver . . . . . . . . . . . . . . . . . . . . . 28
4.2.1. Requirements on Feedback Elements . . . . . . . . . . 28
4.2.2. Requirements on Feedback Intensity . . . . . . . . . 30
5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 31
6. Suggested Experiments . . . . . . . . . . . . . . . . . . . . 31
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
8. Security Considerations . . . . . . . . . . . . . . . . . . . 32
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
9.1. Normative References . . . . . . . . . . . . . . . . . . 33
9.2. Informative References . . . . . . . . . . . . . . . . . 34
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
Congestion in the Internet occurs when the transmitted bitrate is higher than the available capacity over a given transmission path. Applications that are deployed in the Internet have to employ congestion control to achieve robust performance and to avoid congestion collapse in the Internet. Interactive real-time communication imposes a lot of requirements on the transport; therefore, a robust, efficient rate adaptation for all access types is an important part of interactive real-time communications, as the transmission channel bandwidth can vary over time. Wireless access such as LTE, which is an integral part of the current Internet, increases the importance of rate adaptation as the channel bandwidth of a default LTE bearer [QoS-3GPP] can change considerably in a very short time frame. Thus, a rate adaptation solution for interactive real-time media, such as WebRTC [RFC7478], should be both quick and be able to operate over a large range in channel capacity. This memo describes Self-Clocked Rate Adaptation for Multimedia (SCReAM), a solution that implements congestion control for RTP streams [RFC3550]. While SCReAM was originally devised for WebRTC, it can also be used for other applications where congestion control of RTP streams is necessary. SCReAM is based on the self-clocking principle of TCP and uses techniques similar to what is used in the rate adaptation algorithm based on Low Extra Delay Background Transport (LEDBAT) [RFC6817]. SCReAM is not entirely self-clocked as it augments self-clocking with pacing and a minimum send rate. SCReAM can take advantage of Explicit Congestion Notification (ECN) in cases where ECN is supported by the network and the hosts. However, ECN is not required for the basic congestion control functionality in SCReAM.
当传输的比特率高于给定传输路径上的可用容量时，互联网就会发生拥塞。部署在Internet上的应用程序必须采用拥塞控制来实现强健的性能，并避免Internet上的拥塞崩溃。交互式实时通信对交通运输提出了很多要求；因此，针对所有接入类型的健壮、高效的速率自适应是交互式实时通信的重要组成部分，因为传输信道带宽可以随时间变化。作为当前因特网的一个组成部分的无线接入，例如LTE，增加了速率自适应的重要性，因为默认LTE承载[QoS-3GPP]的信道带宽可以在非常短的时间帧内显著改变。因此，交互式实时媒体的速率自适应解决方案（如WebRTC[RFC7478]）应该既快速又能够在信道容量的大范围内运行。本备忘录描述了多媒体自时钟速率自适应（CREAM），这是一种实现RTP流拥塞控制的解决方案[RFC3550]。虽然CREAM最初是为WebRTC设计的，但它也可以用于其他需要RTP流拥塞控制的应用程序。CREAR基于TCP的自时钟原理，并使用与基于低额外延迟背景传输（LEDBAT）的速率自适应算法类似的技术[RFC6817]。尖叫并非完全自动计时，因为它通过配速和最低发送速率增强了自动计时。在网络和主机支持ECN的情况下，CREAM可以利用显式拥塞通知（ECN）。但是，CREAM中的基本拥塞控制功能不需要ECN。
[WIRELESS-TESTS] describes the complications that can be observed in wireless environments. Wireless access such as LTE typically cannot guarantee a given bandwidth; this is true especially for default bearers. The network throughput can vary considerably, for instance, in cases where the wireless terminal is moving around. Even though LTE can support bitrates well above 100 Mbps, there are cases when the available bitrate can be much lower; examples are situations with high network load and poor coverage. An additional complication is that the network throughput can drop for short time intervals (e.g., at handover); these short glitches are initially very difficult to distinguish from more permanent reductions in throughput.
[WIRELESS-TESTS]描述了在无线环境中可以观察到的复杂情况。诸如LTE的无线接入通常不能保证给定的带宽；这尤其适用于默认承载者。例如，在无线终端四处移动的情况下，网络吞吐量可以显著变化。尽管LTE可以支持远高于100Mbps的比特率，但在某些情况下，可用比特率可以低得多；例如，高网络负载和低覆盖率的情况。另一个复杂性是网络吞吐量可能在短时间间隔内下降（例如，在切换时）；这些短期故障最初很难与吞吐量的永久性下降区分开来。
Unlike wireline bottlenecks with large statistical multiplexing, it is not possible to try to maintain a given bitrate when congestion is detected with the hope that other flows will yield. This is because
与具有大量统计多路复用的有线瓶颈不同，当检测到拥塞时，不可能试图保持给定的比特率，希望其他流将产生拥塞。这是因为
there are generally few other flows competing for the same bottleneck. Each user gets its own variable throughput bottleneck, where the throughput depends on factors like channel quality, network load, and historical throughput. The bottom line is, if the throughput drops, the sender has no other option than to reduce the bitrate. Once the radio scheduler has reduced the resource allocation for a bearer, a flow (which is using RTP Media Congestion Avoidance Techniques (RMCAT)) in that bearer aims to reduce the sending rate quite quickly (within one RTT) in order to avoid excessive queuing delay or packet loss.
通常很少有其他流竞争相同的瓶颈。每个用户都有自己的可变吞吐量瓶颈，其中吞吐量取决于信道质量、网络负载和历史吞吐量等因素。底线是，如果吞吐量下降，发送方除了降低比特率之外别无选择。一旦无线电调度器减少了对承载的资源分配，该承载中的流（使用RTP媒体拥塞避免技术（RMCAT））旨在相当快地降低发送速率（在一个RTT内），以避免过度排队延迟或分组丢失。
Self-clocked congestion control algorithms provide a benefit over their rate-based counterparts in that the former consists of two adaptation mechanisms:
与基于速率的拥塞控制算法相比，自时钟拥塞控制算法具有优势，因为前者包括两种自适应机制：
o A congestion window computation that evolves over a longer timescale (several RTTs) especially when the congestion window evolution is dictated by estimated delay (to minimize vulnerability to, e.g., short-term delay variations).
o 一种在较长时间尺度（若干RTT）上演化的拥塞窗口计算，特别是当拥塞窗口演化由估计的延迟决定时（以最小化对例如短期延迟变化的脆弱性）。
o A fine-grained congestion control given by the self-clocking; it operates on a shorter time scale (1 RTT). The benefits of self-clocking are also elaborated upon in [TFWC].
o 自时钟提供的细粒度拥塞控制；它以较短的时间尺度（1 RTT）运行。[TFWC]中还阐述了自时钟的好处。
A rate-based congestion control algorithm typically adjusts the rate based on delay and loss. The congestion detection needs to be done with a certain time lag to avoid overreaction to spurious congestion events such as delay spikes. Despite the fact that there are two or more congestion indications, the outcome is that there is still only one mechanism to adjust the sending rate. This makes it difficult to reach the goals of high throughput and prompt reaction to congestion.
基于速率的拥塞控制算法通常根据延迟和丢失调整速率。拥塞检测需要有一定的时间延迟，以避免对虚假拥塞事件（如延迟峰值）的过度反应。尽管存在两个或多个拥塞指示，结果仍然只有一种机制可以调整发送速率。这使得它很难达到高吞吐量和对拥塞做出快速反应的目标。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
The core SCReAM algorithm has similarities to the concepts of self-clocking used in TCP-friendly window-based congestion control [TFWC] and follows the packet conservation principle. The packet conservation principle is described as a key factor behind the protection of networks from congestion [Packet-conservation].
核心尖叫算法与TCP友好的基于窗口的拥塞控制[TFWC]中使用的自时钟概念相似，并遵循数据包保护原则。数据包保护原则被描述为保护网络免受拥塞的关键因素[数据包保护]。
In SCReAM, the receiver of the media echoes a list of received RTP packets and the timestamp of the RTP packet with the highest sequence number back to the sender in feedback packets. The sender keeps a list of transmitted packets, their respective sizes, and the time they were transmitted. This information is used to determine the number of bytes that can be transmitted at any given time instant. A congestion window puts an upper limit on how many bytes can be in flight, i.e., transmitted but not yet acknowledged.
在尖叫中，媒体的接收器在反馈分组中将接收到的RTP分组的列表和具有最高序列号的RTP分组的时间戳回传给发送者。发送方保存一个已传输数据包的列表，它们各自的大小以及它们被传输的时间。此信息用于确定在任何给定时刻可以传输的字节数。拥塞窗口对可以传输的字节数设置了上限，即传输但尚未确认的字节数。
The congestion window is determined in a way similar to LEDBAT [RFC6817]. LEDBAT is a congestion control algorithm that uses send and receive timestamps to estimate the queuing delay (from now on denoted "qdelay") along the transmission path. This information is used to adjust the congestion window. The use of LEDBAT ensures that the end-to-end latency is kept low. [LEDBAT-delay-impact] shows that LEDBAT has certain inherent issues that make it counteract its purpose of achieving low delay. The general problem described in the paper is that the base delay is offset by LEDBAT's own queue buildup. The big difference with using LEDBAT in the SCReAM context lies in the facts that the source is rate limited and that the RTP queue must be kept short (preferably empty). In addition, the output from a video encoder is rarely constant bitrate; static content (talking heads, for instance) gives almost zero video bitrate. This yields two useful properties when LEDBAT is used with SCReAM; they help to avoid the issues described in [LEDBAT-delay-impact]:
拥塞窗口的确定方式类似于LEDBAT[RFC6817]。LEDBAT是一种拥塞控制算法，它使用发送和接收时间戳来估计沿传输路径的排队延迟（从现在起表示为“qdelay”）。此信息用于调整拥塞窗口。使用LEDBAT可确保端到端延迟保持较低。[LEDBAT延迟影响]表明，LEDBAT存在某些固有问题，使其无法实现低延迟的目的。本文描述的一般问题是基本延迟被LEDBAT自身的队列累积所抵消。在尖叫上下文中使用LEDBAT的最大区别在于源是速率受限的，RTP队列必须保持较短（最好是空的）。此外，视频编码器的输出很少是恒定比特率；静态内容（例如，会说话的头部）提供几乎为零的视频比特率。当LEDBAT与CREAR一起使用时，这会产生两个有用的特性；它们有助于避免[LEDBAT延迟影响]中描述的问题：
1. There is always a certain probability that SCReAM is short of data to transmit; this means that the network queue will become empty every once in a while.
1. 总有一定的可能性，尖叫是缺乏数据传输；这意味着网络队列将每隔一段时间变为空。
2. The max video bitrate can be lower than the link capacity. If the max video bitrate is 5 Mbps and the capacity is 10 Mbps, then the network queue will become empty.
2. 最大视频比特率可以低于链路容量。如果最大视频比特率为5 Mbps，容量为10 Mbps，则网络队列将变为空。
It is sufficient that any of the two conditions above is fulfilled to make the base delay update properly. Furthermore, [LEDBAT-delay-impact] describes an issue with short-lived competing flows. In SCReAM, these short-lived flows will cause the self-clocking to slow down, thereby building up the RTP queue; in turn, this results in a reduced media video bitrate. Thus, SCReAM slows
满足上述两个条件中的任何一个就足以使基本延迟正确更新。此外，[LEDBAT延迟影响]描述了短生命竞争流的问题。在CREAM中，这些短暂的流将导致自时钟减慢，从而建立RTP队列；反过来，这会降低媒体视频比特率。因此，尖叫声变慢了
the bitrate more when there are competing short-lived flows than the traditional use of LEDBAT does. The basic functionality in the use of LEDBAT in SCReAM is quite simple; however, there are a few steps in order to make the concept work with conversational media:
与传统的LEDBAT使用相比，当存在竞争性的短期流时，比特率更高。在尖叫中使用LEDBAT的基本功能非常简单；然而，要使该概念在对话媒体中发挥作用，有几个步骤：
o Congestion window validation techniques. These are similar to the method described in [RFC7661]. Congestion window validation ensures that the congestion window is limited by the actual number bytes in flight; this is important especially in the context of rate-limited sources such as video. Lack of congestion window validation would lead to a slow reaction to congestion as the congestion window does not properly reflect the congestion state in the network. The allowed idle period in this memo is shorter than in [RFC7661]; this to avoid excessive delays in the cases where, e.g., wireless throughput has decreased during a period where the output bitrate from the media coder has been low (for instance, due to inactivity). Furthermore, this memo allows for more relaxed rules for when the congestion window is allowed to grow; this is necessary as the variable output bitrate generally means that the congestion window is often underutilized.
o 拥塞窗口验证技术。这些类似于[RFC7661]中描述的方法。拥塞窗口验证确保拥塞窗口受到飞行中实际字节数的限制；这一点非常重要，尤其是在视频等速率受限源的情况下。由于拥塞窗口不能正确反映网络中的拥塞状态，因此缺少拥塞窗口验证将导致对拥塞的反应缓慢。此备忘录中允许的空闲时间比[RFC7661]中的短；这是为了避免在例如无线吞吐量在来自媒体编码器的输出比特率已经低（例如，由于不活动）的时段期间已经降低的情况下的过度延迟。此外，该备忘录允许更宽松的规则，规定何时允许拥堵窗口增长；这是必要的，因为可变输出比特率通常意味着拥塞窗口通常未得到充分利用。
o Fast increase mode makes the bitrate increase faster when no congestion is detected. It makes the media bitrate ramp up within 5 to 10 seconds. The behavior is similar to TCP slowstart. Fast increase mode is exited when congestion is detected. However, fast increase mode can resume if the congestion level is low; this enables a reasonably quick rate increase in case link throughput increases.
o 快速增加模式使比特率在未检测到拥塞时增加得更快。它使媒体比特率在5到10秒内上升。该行为类似于TCP slowstart。当检测到拥塞时，快速增加模式退出。然而，如果拥塞水平较低，快速增加模式可以恢复；这使得在链路吞吐量增加的情况下能够合理快速地提高速率。
o A qdelay trend is computed for earlier detection of incipient congestion; as a result, it reduces jitter.
o 计算qdelay趋势，以便早期检测早期拥堵；因此，它减少了抖动。
o Addition of a media rate control function.
o 添加媒体速率控制功能。
o Use of inflection points in the media rate calculation to achieve reduced jitter.
o 在媒体速率计算中使用拐点，以减少抖动。
o Adjustment of qdelay target for better performance when competing with other loss-based congestion-controlled flows.
o 调整qdelay目标，以便在与其他基于损耗的拥塞控制流竞争时获得更好的性能。
The above-mentioned features will be described in more detail in Sections 3.1 to 3.3. The full details are described in Section 4.
第3.1节至第3.3节将更详细地描述上述特征。第4节描述了全部细节。
+---------------------------+
| Media encoder |
+---------------------------+
^ |
| |(1)
|(3) RTP
| V
| +-----------+
+---------+ | |
| Media | (2) | Queue |
| rate |<------| |
| control | |RTP packets|
+---------+ | |
+-----------+
|
|(4)
RTP
|
v
+------------+ +--------------+
| Network | (7) | Sender |
+-->| congestion |------>| Transmission |
| | control | | Control |
| +------------+ +--------------+
| |
|-------------RTCP----------| |(5)
(6) | RTP
| v
+------------+
| UDP |
| socket |
+------------+
+---------------------------+
| Media encoder |
+---------------------------+
^ |
| |(1)
|(3) RTP
| V
| +-----------+
+---------+ | |
| Media | (2) | Queue |
| rate |<------| |
| control | |RTP packets|
+---------+ | |
+-----------+
|
|(4)
RTP
|
v
+------------+ +--------------+
| Network | (7) | Sender |
+-->| congestion |------>| Transmission |
| | control | | Control |
| +------------+ +--------------+
| |
|-------------RTCP----------| |(5)
(6) | RTP
| v
+------------+
| UDP |
| socket |
+------------+
Figure 1: SCReAM Sender Functional View
图1：尖叫发送器功能视图
The SCReAM algorithm consists of three main parts: network congestion control, sender transmission control, and media rate control. All of these parts reside at the sender side. Figure 1 shows the functional overview of a SCReAM sender. The receiver-side algorithm is very simple in comparison, as it only generates feedback containing acknowledgements of received RTP packets and an ECN count.
尖叫算法由三个主要部分组成：网络拥塞控制、发送方传输控制和媒体速率控制。所有这些部件都位于发送方侧。图1显示了尖叫发送器的功能概述。相比之下，接收方算法非常简单，因为它只生成包含接收到的RTP数据包的确认和ECN计数的反馈。
The network congestion control sets an upper limit on how much data can be in the network (bytes in flight); this limit is called CWND (congestion window) and is used in the sender transmission control.
网络拥塞控制设置了网络中数据量的上限（传输中的字节）；此限制称为CWND（拥塞窗口），用于发送方传输控制。
The SCReAM congestion control method uses techniques similar to LEDBAT [RFC6817] to measure the qdelay. As is the case with LEDBAT, it is not necessary to use synchronized clocks in the sender and receiver in order to compute the qdelay. However, it is necessary that they use the same clock frequency, or that the clock frequency at the receiver can be inferred reliably by the sender. Failure to meet this requirement leads to malfunction in the SCReAM congestion control algorithm due to incorrect estimation of the network queue delay.
尖叫拥塞控制方法使用类似于LEDBAT[RFC6817]的技术来测量qdelay。与LEDBAT的情况一样，不需要在发送方和接收方使用同步时钟来计算qdelay。然而，它们必须使用相同的时钟频率，或者发送方可以可靠地推断出接收器处的时钟频率。由于对网络队列延迟的错误估计，未能满足此要求会导致CREAM拥塞控制算法出现故障。
The SCReAM sender calculates the congestion window based on the feedback from the SCReAM receiver. The congestion window is allowed to increase if the qdelay is below a predefined qdelay target; otherwise, the congestion window decreases. The qdelay target is typically set to 50-100 ms. This ensures that the queuing delay is kept low. The reaction to loss or ECN events leads to an instant reduction of CWND. Note that the source rate-limited nature of real-time media, such as video, typically means that the queuing delay will mostly be below the given delay target. This is contrary to the case where large files are transmitted using LEDBAT congestion control and the queuing delay will stay close to the delay target.
尖叫发送方根据尖叫接收方的反馈计算拥塞窗口。如果qdelay低于预定义的qdelay目标，则允许增加拥塞窗口；否则，拥塞窗口将减小。qdelay目标通常设置为50-100毫秒。这可确保排队延迟保持较低。对丢失或ECN事件的反应导致CWND的瞬间减少。请注意，实时媒体（如视频）的源速率受限特性通常意味着排队延迟将主要低于给定的延迟目标。这与使用LEDBAT拥塞控制传输大文件的情况相反，排队延迟将保持接近延迟目标。
The sender transmission control limits the output of data, given by the relation between the number of bytes in flight and the congestion window. Packet pacing is used to mitigate issues with ACK compression that MAY cause increased jitter and/or packet loss in the media traffic. Packet pacing limits the packet transmission rate given by the estimated link throughput. Even if the send window allows for the transmission of a number of packets, these packets are not transmitted immediately; rather, they are transmitted in intervals given by the packet size and the estimated link throughput.
发送方传输控制限制数据的输出，这是由传输中的字节数与拥塞窗口之间的关系给出的。数据包调整用于缓解ACK压缩问题，这些问题可能导致媒体流量中的抖动增加和/或数据包丢失。数据包调整限制了由估计链路吞吐量给出的数据包传输速率。即使发送窗口允许发送多个分组，也不会立即发送这些分组；相反，它们是按分组大小和估计链路吞吐量给定的间隔发送的。
The media rate control serves to adjust the media bitrate to ramp up quickly enough to get a fair share of the system resources when link throughput increases.
媒体速率控制用于调整媒体比特率，以便在链路吞吐量增加时足够快地提升，以获得系统资源的公平份额。
The reaction to reduced throughput MUST be prompt in order to avoid getting too much data queued in the RTP packet queue(s) in the sender. The media bitrate is decreased if the RTP queue size exceeds a threshold.
对吞吐量降低的反应必须及时，以避免在发送方的RTP数据包队列中排队的数据过多。如果RTP队列大小超过阈值，则会降低媒体比特率。
In cases where the sender's frame queues increase rapidly, such as in the case of a Radio Access Type (RAT) handover, the SCReAM sender MAY implement additional actions, such as discarding of encoded media
在发送方的帧队列迅速增加的情况下，例如在无线接入类型（RAT）切换的情况下，尖叫发送方可以实施附加动作，例如丢弃编码媒体
frames or frame skipping in order to ensure that the RTP queues are drained quickly. Frame skipping results in the frame rate being temporarily reduced. Which method to use is a design choice and is outside the scope of this algorithm description.
帧或帧跳过，以确保RTP队列快速排空。跳帧会导致帧速率暂时降低。使用哪种方法是一种设计选择，不在本算法描述的范围内。
This section describes the sender-side algorithm in more detail. It is split between the network congestion control, sender transmission control, and media rate control.
本节将更详细地描述发送方端算法。它分为网络拥塞控制、发送方传输控制和媒体速率控制。
A SCReAM sender implements media rate control and an RTP queue for each media type or source, where RTP packets containing encoded media frames are temporarily stored for transmission. Figure 1 shows the details when a single media source (or stream) is used. A transmission scheduler (not shown in the figure) is added to support multiple streams. The transmission scheduler can enforce differing priorities between the streams and act like a coupled congestion controller for multiple flows. Support for multiple streams is implemented in [SCReAM-CPP-implementation].
尖叫发送器为每种媒体类型或源实现媒体速率控制和RTP队列，其中包含编码媒体帧的RTP数据包被临时存储以供传输。图1显示了使用单个媒体源（或流）时的详细信息。添加了传输调度器（图中未显示）以支持多个流。传输调度器可以在流之间实施不同的优先级，并像多个流的耦合拥塞控制器一样工作。对多个流的支持在[SCReAM CPP实现]中实现。
Media frames are encoded and forwarded to the RTP queue (1) in Figure 1. The media rate adaptation adapts to the size of the RTP queue (2) and provides a target rate for the media encoder (3). The RTP packets are picked from the RTP queue (4), for multiple flows from each RTP queue based on some defined priority order or simply in a round-robin fashion, by the sender transmission controller. The sender transmission controller (in case of multiple flows a transmission scheduler) sends the RTP packets to the UDP socket (5). In the general case, all media SHOULD go through the sender transmission controller and is limited so that the number of bytes in flight is less than the congestion window. RTCP packets are received (6) and the information about the bytes in flight and congestion window is exchanged between the network congestion control and the sender transmission control (7).
媒体帧被编码并转发到图1中的RTP队列（1）。媒体速率自适应适应RTP队列（2）的大小，并为媒体编码器（3）提供目标速率。对于来自每个RTP队列的多个流，发送方传输控制器基于某个定义的优先级顺序或简单地以循环方式从RTP队列（4）拾取RTP分组。发送方传输控制器（在多个流的情况下，传输调度器）将RTP数据包发送到UDP套接字（5）。在一般情况下，所有媒体都应通过发送方传输控制器，并受到限制，以便传输中的字节数小于拥塞窗口。接收RTCP数据包（6），并在网络拥塞控制和发送方传输控制（7）之间交换有关传输和拥塞窗口中字节的信息。
Constants and state variables are listed in this section. Temporary variables are not listed; instead, they are appended with '_t' in the pseudocode to indicate their local scope.
本节列出了常数和状态变量。未列出临时变量；相反，它们在伪代码中附加了“\u t”，以指示其局部范围。
The RECOMMENDED values, within parentheses "()", for the constants are deduced from experiments.
括号“（）”内的常数建议值是从实验中推导出来的。
QDELAY_TARGET_LO (0.1 s) Target value for the minimum qdelay.
QDELAY_目标_LO（0.1 s）最小QDELAY的目标值。
QDELAY_TARGET_HI (0.4 s) Target value for the maximum qdelay. This parameter provides an upper limit to how much the target qdelay (qdelay_target) can be increased in order to cope with competing loss-based flows. However, the target qdelay does not have to be initialized to this high value, as it would increase end-to-end delay and also make the rate control and congestion control loops sluggish.
QDELAY_TARGET_HI（0.4 s）最大QDELAY的目标值。该参数提供了目标qdelay（qdelay_target）可以增加多少的上限，以应对基于损失的竞争流量。但是，不必将目标qdelay初始化为这个高值，因为它会增加端到端延迟，并且还会使速率控制和拥塞控制环路变得缓慢。
QDELAY_WEIGHT (0.1) Averaging factor for qdelay_fraction_avg.
QDELAY_权重（0.1）QDELAY_分数平均值的平均因子。
QDELAY_TREND_TH (0.2) Threshold for the detection of incipient congestion.
QDELAY_TREND_TH（0.2）阈值，用于检测早期拥堵。
MIN_CWND (3000 bytes) Minimum congestion window.
最小CWND（3000字节）最小拥塞窗口。
MAX_BYTES_IN_FLIGHT_HEAD_ROOM (1.1) Headroom for the limitation of CWND.
限制CWND的最大飞行高度（1.1）净空。
GAIN (1.0) Gain factor for congestion window adjustment.
增益（1.0）拥塞窗口调整的增益因子。
BETA_LOSS (0.8) CWND scale factor due to loss event.
损失事件导致的贝塔损失（0.8）CWND比例系数。
BETA_ECN (0.9) CWND scale factor due to ECN event.
由于ECN事件，BETA_ECN（0.9）CWND比例因子。
BETA_R (0.9) Scale factor for target rate due to loss event.
损失事件导致的目标利率的贝塔系数（0.9）。
MSS (1000 byte) Maximum segment size = Max RTP packet size.
MSS（1000字节）最大段大小=最大RTP数据包大小。
RATE_ADJUST_INTERVAL (0.2 s) Interval between media bitrate adjustments.
速率调整间隔（0.2秒）媒体比特率调整之间的间隔。
TARGET_BITRATE_MIN Minimum target bitrate in bps (bits per second).
目标\比特率\最小目标比特率，单位为bps（比特/秒）。
TARGET_BITRATE_MAX Maximum target bitrate in bps.
目标\比特率\最大目标比特率（以bps为单位）。
RAMP_UP_SPEED (200000 bps/s) Maximum allowed rate increase speed.
爬升速度（200000 bps/s）最大允许速率增加速度。
PRE_CONGESTION_GUARD (0.0..1.0) Guard factor against early congestion onset. A higher value gives less jitter, possibly at the expense of a lower link utilization. This value MAY be subject to tuning depending on e.g., media coder characteristics. Experiments with H264 and VP8 indicate that 0.1 is a suitable value. See [SCReAM-CPP-implementation] and [SCReAM-implementation-experience] for evaluation of a real implementation.
PRE_拥塞_GUARD（0.0..1.0）防止早期拥塞发生的保护因子。值越高，抖动越小，可能以降低链路利用率为代价。该值可根据例如媒体编码器特性进行调整。H264和VP8的实验表明，0.1是一个合适的值。有关实际实施的评估，请参见[尖叫CPP实施]和[尖叫实施体验]。
TX_QUEUE_SIZE_FACTOR (0.0..2.0) Guard factor against RTP queue buildup. This value MAY be subject to tuning depending on, e.g., media coder characteristics. Experiments with H264 and VP8 indicate that 1.0 is a suitable value. See [SCReAM-CPP-implementation] and [SCReAM-implementation-experience] for evaluation of a real implementation.
发送队列大小因子（0.0..2.0）防止RTP队列累积的保护因子。该值可根据例如媒体编码器特性进行调整。H264和VP8的实验表明，1.0是一个合适的值。有关实际实施的评估，请参见[尖叫CPP实施]和[尖叫实施体验]。
RTP_QDELAY_TH (0.02 s) RTP queue delay threshold for a target rate reduction.
目标速率降低的RTP队列延迟阈值（0.02秒）。
TARGET_RATE_SCALE_RTP_QDELAY (0.95) Scale factor for target rate when RTP qdelay threshold exceeds RTP_QDELAY_TH.
当RTP QDELAY阈值超过RTP QDELAY时，目标速率的标度因数（0.95）。
QDELAY_TREND_LO (0.2) Threshold value for qdelay_trend.
QDELAY_TREND_LO（0.2）QDELAY_TREND的阈值。
T_RESUME_FAST_INCREASE (5 s) Time span until fast increase mode can be resumed, given that the qdelay_trend is below QDELAY_TREND_LO.
T_RESUME_FAST_INCREASE（5秒）时间跨度，直到可以恢复快速增加模式，前提是qdelay_趋势低于qdelay_趋势。
RATE_PACE_MIN (50000 bps) Minimum pacing rate.
最小起搏速率（50000 bps）。
The values within parentheses "()" indicate initial values.
括号“（）”内的值表示初始值。
qdelay_target (QDELAY_TARGET_LO) qdelay target, a variable qdelay target is introduced to manage cases where a fixed qdelay target would otherwise starve the RMCAT flow under such circumstances (e.g., FTP competes for the bandwidth over the same bottleneck). The qdelay target is allowed to vary between QDELAY_TARGET_LO and QDELAY_TARGET_HI.
qdelay_target（qdelay_target_LO）qdelay target，引入变量qdelay target，以管理在这种情况下固定qdelay target会导致RMCAT流不足的情况（例如，FTP在同一瓶颈上争夺带宽）。qdelay目标允许在qdelay_target_LO和qdelay_target_HI之间变化。
qdelay_fraction_avg (0.0) Fractional qdelay filtered by the Exponentially Weighted Moving Average (EWMA).
qdelay_分数_平均值（0.0）通过指数加权移动平均（EWMA）过滤的分数qdelay。
qdelay_fraction_hist[20] ({0,..,0}) Vector of the last 20 fractional qdelay samples.
最后20个分数qdelay样本的qdelay_分数_hist[20]（{0，…，0}）向量。
qdelay_trend (0.0) qdelay trend; indicates incipient congestion.
qdelay_趋势（0.0）qdelay趋势；表示初期拥堵。
qdelay_trend_mem (0.0) Low-pass filtered version of qdelay_trend.
qdelay_trend_mem（0.0）qdelay_trend的低通滤波版本。
qdelay_norm_hist[100] ({0,..,0}) Vector of the last 100 normalized qdelay samples.
最后100个标准化qdelay样本的qdelay_norm_hist[100]（{0，…，0}）向量。
in_fast_increase (true) True if in fast increase mode.
如果处于快速增加模式，则为快速增加（真）。
cwnd (MIN_CWND) Congestion window.
cwnd（最小cwnd）拥塞窗口。
bytes_newly_acked (0) The number of bytes that was acknowledged with the last received acknowledgement, i.e., bytes acknowledged since the last CWND update.
bytes_New_acked（0）上次收到确认时确认的字节数，即自上次CWND更新以来确认的字节数。
max_bytes_in_flight (0) The maximum number of bytes in flight over a sliding time window, i.e., transmitted but not yet acknowledged bytes.
max_bytes_in_flight（0）滑动时间窗口内飞行的最大字节数，即已传输但尚未确认的字节数。
send_wnd (0) Upper limit to how many bytes can currently be transmitted. Updated when cwnd is updated and when RTP packet is transmitted.
send_wnd（0）当前可以传输的字节数上限。更新cwnd和传输RTP数据包时更新。
target_bitrate (0 bps) Media target bitrate.
目标比特率（0 bps）媒体目标比特率。
target_bitrate_last_max (1 bps) Inflection point of the media target bitrate, i.e., the last known highest target_bitrate. Used to limit bitrate increase speed close to the last known congestion point.
目标比特率\媒体目标比特率的最后一个最大（1 bps）拐点，即最后一个已知的最高目标比特率。用于将比特率增加速度限制在接近最后一个已知拥塞点的位置。
rate_transmit (0.0 bps) Measured transmit bitrate.
传输速率（0.0 bps）测量的传输比特率。
rate_ack (0.0 bps) Measured throughput based on received acknowledgements.
速率确认（0.0 bps）基于接收到的确认测量吞吐量。
rate_media (0.0 bps) Measured bitrate from the media encoder.
媒体速率（0.0 bps）从媒体编码器测量的比特率。
rate_media_median (0.0 bps) Median value of rate_media, computed over more than 10 s.
rate_media_median（0.0个基点）rate_media的中值，计算时间超过10秒。
s_rtt (0.0s) Smoothed RTT (in seconds), computed with a similar method to that described in [RFC6298].
s_rtt（0.0s）平滑rtt（以秒为单位），计算方法与[RFC6298]中描述的方法类似。
rtp_queue_size (0 bits) Sum of the sizes of RTP packets in queue.
rtp_队列_大小（0位）队列中rtp数据包大小的总和。
rtp_size (0 byte) Size of the last transmitted RTP packet.
rtp_大小（0字节）最后传输的rtp数据包的大小。
loss_event_rate (0.0) The estimated fraction of RTTs with lost packets detected.
丢失事件率（0.0）检测到丢失数据包的RTT的估计分数。
This section explains the network congestion control, which performs two main functions:
本节介绍网络拥塞控制，它执行两个主要功能：
o Computation of congestion window at the sender: This gives an upper limit to the number of bytes in flight.
o 发送方拥塞窗口的计算：这为传输中的字节数提供了上限。
o Calculation of send window at the sender: RTP packets are transmitted if allowed by the relation between the number of bytes in flight and the congestion window. This is controlled by the send window.
o 发送方发送窗口的计算：如果飞行中的字节数与拥塞窗口之间的关系允许，则传输RTP数据包。这由“发送”窗口控制。
SCReAM is a window-based and byte-oriented congestion control protocol, where the number of bytes transmitted is inferred from the size of the transmitted RTP packets. Thus, a list of transmitted RTP packets and their respective transmission times (wall-clock time) MUST be kept for further calculation.
CREAR是一种基于窗口和面向字节的拥塞控制协议，其中传输的字节数根据传输的RTP数据包的大小推断。因此，必须保留传输的RTP分组及其各自的传输时间（挂钟时间）的列表，以便进一步计算。
The number of bytes in flight (bytes_in_flight) is computed as the sum of the sizes of the RTP packets ranging from the RTP packet most recently transmitted, down to but not including the acknowledged packet with the highest sequence number. This can be translated to the difference between the highest transmitted byte sequence number and the highest acknowledged byte sequence number. As an example: If an RTP packet with sequence number SN is transmitted and the last acknowledgement indicates SN-5 as the highest received sequence number, then bytes_in_flight is computed as the sum of the size of RTP packets with sequence number SN-4, SN-3, SN-2, SN-1, and SN. It
飞行中的字节数（飞行中的字节数）计算为RTP分组大小的总和，范围从最近发送的RTP分组到但不包括具有最高序列号的已确认分组。这可以转化为最高传输字节序列号和最高确认字节序列号之间的差异。例如：如果发送序列号为SN的RTP数据包，且最后一次确认指示SN-5为最高接收序列号，则将_飞行中的字节_计算为序列号为SN-4、SN-3、SN-2、SN-1和SN的RTP数据包的大小之和。信息技术
does not matter if, for instance, the packet with sequence number SN-3 was lost -- the size of RTP packet with sequence number SN-3 will still be considered in the computation of bytes_in_flight.
例如，如果序列号为SN-3的数据包丢失，则无所谓——序列号为SN-3的RTP数据包的大小仍将在计算字节数时予以考虑。
Furthermore, a variable bytes_newly_acked is incremented with a value corresponding to how much the highest sequence number has increased since the last feedback. As an example: If the previous acknowledgement indicated the highest sequence number N and the new acknowledgement indicated N+3, then bytes_newly_acked is incremented by a value equal to the sum of the sizes of RTP packets with sequence number N+1, N+2, and N+3. Packets that are lost are also included, which means that even though, e.g., packet N+2 was lost, its size is still included in the update of bytes_newly_acked. The bytes_newly_acked variable is reset to zero after a CWND update.
此外，新确认的变量bytes_增加一个值，该值对应于自上次反馈以来最高序列号增加了多少。例如：如果先前的确认指示最高序列号N，而新的确认指示N+3，则新确认的字节数将增加一个值，该值等于序列号为N+1、N+2和N+3的RTP数据包大小之和。还包括丢失的数据包，这意味着即使数据包N+2丢失，其大小仍包括在新确认的字节的更新中。CWND更新后，新确认的字节变量重置为零。
The feedback from the receiver is assumed to consist of the following elements.
假定来自接收器的反馈由以下元素组成。
o A list of received RTP packets' sequence numbers.
o 接收到的RTP数据包序列号的列表。
o The wall-clock timestamp corresponding to the received RTP packet with the highest sequence number.
o 与接收到的具有最高序列号的RTP数据包相对应的挂钟时间戳。
o The accumulated number of ECN-CE-marked packets (n_ECN). Here, "CE" refers to "Congestion Experienced".
o ECN CE标记的数据包（n_ECN）的累积数量。这里，“CE”指的是“经历过的拥堵”。
When the sender receives RTCP feedback, the qdelay is calculated as outlined in [RFC6817]. A qdelay sample is obtained for each received acknowledgement. No smoothing of the qdelay is performed; however, some smoothing occurs anyway because the CWND computation is a low-pass filter function. A number of variables are updated as illustrated by the pseudocode below; temporary variables are appended with '_t'. As mentioned in Section 6, calculation of the proper congestion window and media bitrate may benefit from additional optimizations to handle very high and very low bitrates, and from additional damping to handle periodic packet bursts. Some such optimizations are implemented in [SCReAM-CPP-implementation], but they do not form part of the specification of SCReAM at this time.
当发送方收到RTCP反馈时，按照[RFC6817]中所述计算qdelay。为每个收到的确认获取一个qdelay样本。不执行qdelay的平滑处理；但是，由于CWND计算是一个低通滤波函数，因此仍然会发生一些平滑。如下面的伪代码所示，许多变量被更新；临时变量附加有“\u t”。如第6节所述，适当拥塞窗口和媒体比特率的计算可能受益于处理极高和极低比特率的额外优化，以及处理周期性分组突发的额外阻尼。一些这样的优化是在[SCReAM CPP implementation]中实现的，但目前它们并不构成SCReAM规范的一部分。
<CODE BEGINS>
update_variables(qdelay):
qdelay_fraction_t = qdelay / qdelay_target
# Calculate moving average
qdelay_fraction_avg = (1 - QDELAY_WEIGHT) * qdelay_fraction_avg +
QDELAY_WEIGHT * qdelay_fraction_t
update_qdelay_fraction_hist(qdelay_fraction_t)
# Compute the average of the values in qdelay_fraction_hist
avg_t = average(qdelay_fraction_hist)
# R is an autocorrelation function of qdelay_fraction_hist,
# with the mean (DC component) removed, at lag K
# The subtraction of the scalar avg_t from
# qdelay_fraction_hist is performed element-wise
a_t = R(qdelay_fraction_hist-avg_t, 1) /
R(qdelay_fraction_hist-avg_t, 0)
# Calculate qdelay trend
qdelay_trend = min(1.0, max(0.0, a_t * qdelay_fraction_avg))
# Calculate a 'peak-hold' qdelay_trend; this gives a memory
# of congestion in the past
qdelay_trend_mem = max(0.99 * qdelay_trend_mem, qdelay_trend)
<CODE ENDS>
<CODE BEGINS>
update_variables(qdelay):
qdelay_fraction_t = qdelay / qdelay_target
# Calculate moving average
qdelay_fraction_avg = (1 - QDELAY_WEIGHT) * qdelay_fraction_avg +
QDELAY_WEIGHT * qdelay_fraction_t
update_qdelay_fraction_hist(qdelay_fraction_t)
# Compute the average of the values in qdelay_fraction_hist
avg_t = average(qdelay_fraction_hist)
# R is an autocorrelation function of qdelay_fraction_hist,
# with the mean (DC component) removed, at lag K
# The subtraction of the scalar avg_t from
# qdelay_fraction_hist is performed element-wise
a_t = R(qdelay_fraction_hist-avg_t, 1) /
R(qdelay_fraction_hist-avg_t, 0)
# Calculate qdelay trend
qdelay_trend = min(1.0, max(0.0, a_t * qdelay_fraction_avg))
# Calculate a 'peak-hold' qdelay_trend; this gives a memory
# of congestion in the past
qdelay_trend_mem = max(0.99 * qdelay_trend_mem, qdelay_trend)
<CODE ENDS>
The qdelay fraction is sampled every 50 ms, and the last 20 samples are stored in a vector (qdelay_fraction_hist). This vector is used in the computation of a qdelay trend that gives a value between 0.0 and 1.0 depending on the estimated congestion level. The prediction coefficient 'a_t' has positive values if qdelay shows an increasing or decreasing trend; thus, an indication of congestion is obtained before the qdelay target is reached. As a side effect, if qdelay decreases, it's taken as a sign of congestion; however, experiments have shown that this is beneficial, as increasing or decreasing queue delay is an indication that the transmit rate is very close to the path capacity.
每50 ms对qdelay分数进行采样，最后20个样品存储在向量（qdelay_分数_hist）中。该向量用于计算qdelay趋势，该趋势根据估计的拥塞水平给出介于0.0和1.0之间的值。如果qdelay呈现增加或减少趋势，则预测系数“a_t”具有正值；因此，在达到qdelay目标之前获得拥塞指示。作为一种副作用，如果qdelay减少，则被视为拥塞的迹象；然而，实验表明这是有益的，因为增加或减少队列延迟表明传输速率非常接近路径容量。
The autocorrelation function 'R' is defined as follows. Let x be a vector constituting N values, the biased autocorrelation function for a given lag=k for the vector x is given by.
自相关函数“R”的定义如下。设x为构成N个值的向量，向量x的给定滞后=k的偏置自相关函数由下式给出。
n=N-k
R(x,k) = SUM x(n) * x(n + k)
n=1
n=N-k
R(x,k) = SUM x(n) * x(n + k)
n=1
The prediction coefficient is further multiplied with qdelay_fraction_avg to reduce sensitivity to increasing qdelay when it is very small. The 50 ms sampling is a simplification that could have the effect that the same qdelay is sampled several times; however, this does not pose any problem, as the vector is only used to determine if the qdelay is increasing or decreasing. The
预测系数进一步乘以qdelay_分数_平均值，以降低当qdelay非常小时对增加qdelay的敏感性。50 ms取样是一种简化，可能会产生相同的时间段多次取样的效果；但是，这不会带来任何问题，因为向量仅用于确定qdelay是增加还是减少。这个
qdelay_trend is utilized in the media rate control to indicate incipient congestion and to determine when to exit from fast increase mode. qdelay_trend_mem is used to enforce a less aggressive rate increase after congestion events. The function update_qdelay_fraction_hist(..) removes the oldest element and adds the latest qdelay_fraction element to the qdelay_fraction_hist vector.
qdelay_趋势用于媒体速率控制，以指示初始拥塞，并确定何时退出快速增加模式。qdelay_trend_mem用于在发生拥塞事件后强制执行不太激进的速率增加。函数update_qdelay_fraction_hist（..）删除最旧的元素，并将最新的qdelay_fraction元素添加到qdelay_fraction_hist向量中。
A loss event is indicated if one or more RTP packets are declared missing. The loss detection is described in Section 4.1.2.4. Once a loss event is detected, further detected lost RTP packets SHOULD be ignored for a full smoothed round-trip time; the intention is to limit the congestion window decrease to at most once per round trip.
如果一个或多个RTP数据包声明丢失，则指示丢失事件。第4.1.2.4节描述了损耗检测。一旦检测到丢失事件，应在完全平滑的往返时间内忽略进一步检测到的丢失RTP数据包；其目的是将拥堵窗口减少限制为每次往返最多一次。
The congestion window back-off due to loss events is deliberately a bit less than is the case with TCP Reno, for example. TCP is generally used to transmit whole files; the file is then like a source with an infinite bitrate until the whole file has been transmitted. SCReAM, on the other hand, has a source whose rate is limited to a value close to the available transmit rate and often below that value; the effect is that SCReAM has less opportunity to grab free capacity than a TCP-based file transfer. To compensate for this, it is RECOMMENDED to let SCReAM reduce the congestion window less than what is the case with TCP when loss events occur.
例如，由于丢失事件导致的拥塞窗口后退故意比TCP Reno的情况要小一些。TCP通常用于传输整个文件；然后，该文件就像一个具有无限比特率的源，直到整个文件被传输。另一方面，“尖叫”有一个源，其速率被限制在接近可用传输速率的值，并且通常低于该值；其效果是，与基于TCP的文件传输相比，CREAM获得空闲容量的机会更少。为了补偿这一点，建议让CREAM在发生丢失事件时将拥塞窗口减少到比TCP更少的程度。
An ECN event is detected if the n_ECN counter in the feedback report has increased since the previous received feedback. Once an ECN event is detected, the n_ECN counter is ignored for a full smoothed round-trip time; the intention is to limit the congestion window decrease to at most once per round trip. The congestion window back-off due to an ECN event MAY be smaller than if a loss event occurs. This is in line with the idea outlined in [ALT-BACKOFF] to enable ECN marking thresholds lower than the corresponding packet drop thresholds.
如果反馈报告中的n_ECN计数器自上次收到反馈后增加，则检测到ECN事件。一旦检测到ECN事件，n_ECN计数器将在完整平滑的往返时间内被忽略；其目的是将拥堵窗口减少限制为每次往返最多一次。ECN事件导致的拥塞窗口后退可能小于发生丢失事件时的后退。这与[ALT-BACKOFF]中概述的想法一致，即使ECN标记阈值低于相应的数据包丢弃阈值。
The update of the congestion window depends on if loss, ECN-marking, or neither of the two occurs. The pseudocode below describes the actions for each case.
拥塞窗口的更新取决于丢失、ECN标记或两者均未发生。下面的伪代码描述了每种情况下的操作。
<CODE BEGINS>
on congestion event(qdelay):
# Either loss or ECN mark is detected
in_fast_increase = false
if (is loss)
# Loss is detected
cwnd = max(MIN_CWND, cwnd * BETA_LOSS)
else
# No loss, so it is then an ECN mark
cwnd = max(MIN_CWND, cwnd * BETA_ECN)
end
adjust_qdelay_target(qdelay) #compensating for competing flows
calculate_send_window(qdelay, qdelay_target)
<CODE BEGINS>
on congestion event(qdelay):
# Either loss or ECN mark is detected
in_fast_increase = false
if (is loss)
# Loss is detected
cwnd = max(MIN_CWND, cwnd * BETA_LOSS)
else
# No loss, so it is then an ECN mark
cwnd = max(MIN_CWND, cwnd * BETA_ECN)
end
adjust_qdelay_target(qdelay) #compensating for competing flows
calculate_send_window(qdelay, qdelay_target)
# When no congestion event
on acknowledgement(qdelay):
update_bytes_newly_acked()
update_cwnd(bytes_newly_acked)
adjust_qdelay_target(qdelay) # compensating for competing flows
calculate_send_window(qdelay, qdelay_target)
check_to_resume_fast_increase()
<CODE ENDS>
# When no congestion event
on acknowledgement(qdelay):
update_bytes_newly_acked()
update_cwnd(bytes_newly_acked)
adjust_qdelay_target(qdelay) # compensating for competing flows
calculate_send_window(qdelay, qdelay_target)
check_to_resume_fast_increase()
<CODE ENDS>
The methods are described in detail below.
下面详细描述这些方法。
The congestion window update is based on qdelay, except for the occurrence of loss events (one or more lost RTP packets in one RTT) or ECN events, which were described earlier.
拥塞窗口更新基于qdelay，但丢失事件（一个RTT中的一个或多个丢失RTP数据包）或ECN事件的发生除外，如前所述。
Pseudocode for the update of the congestion window is found below.
下面是更新拥塞窗口的伪代码。
<CODE BEGINS>
update_cwnd(bytes_newly_acked):
# In fast increase mode?
if (in_fast_increase)
if (qdelay_trend >= QDELAY_TREND_TH)
# Incipient congestion detected; exit fast increase mode
in_fast_increase = false
else
# No congestion yet; increase cwnd if it
# is sufficiently used
# Additional slack of bytes_newly_acked is
# added to ensure that CWND growth occurs
# even when feedback is sparse
if (bytes_in_flight * 1.5 + bytes_newly_acked > cwnd)
cwnd = cwnd + bytes_newly_acked
end
return
end
end
<CODE BEGINS>
update_cwnd(bytes_newly_acked):
# In fast increase mode?
if (in_fast_increase)
if (qdelay_trend >= QDELAY_TREND_TH)
# Incipient congestion detected; exit fast increase mode
in_fast_increase = false
else
# No congestion yet; increase cwnd if it
# is sufficiently used
# Additional slack of bytes_newly_acked is
# added to ensure that CWND growth occurs
# even when feedback is sparse
if (bytes_in_flight * 1.5 + bytes_newly_acked > cwnd)
cwnd = cwnd + bytes_newly_acked
end
return
end
end
# Not in fast increase mode
# off_target calculated as with LEDBAT
off_target_t = (qdelay_target - qdelay) / qdelay_target
# Not in fast increase mode
# off_target calculated as with LEDBAT
off_target_t = (qdelay_target - qdelay) / qdelay_target
gain_t = GAIN
# Adjust congestion window
cwnd_delta_t =
gain_t * off_target_t * bytes_newly_acked * MSS / cwnd
if (off_target_t > 0 &&
bytes_in_flight * 1.25 + bytes_newly_acked <= cwnd)
# No cwnd increase if window is underutilized
# Additional slack of bytes_newly_acked is
# added to ensure that CWND growth occurs
# even when feedback is sparse
cwnd_delta_t = 0;
end
gain_t = GAIN
# Adjust congestion window
cwnd_delta_t =
gain_t * off_target_t * bytes_newly_acked * MSS / cwnd
if (off_target_t > 0 &&
bytes_in_flight * 1.25 + bytes_newly_acked <= cwnd)
# No cwnd increase if window is underutilized
# Additional slack of bytes_newly_acked is
# added to ensure that CWND growth occurs
# even when feedback is sparse
cwnd_delta_t = 0;
end
# Apply delta
cwnd += cwnd_delta_t
# limit cwnd to the maximum number of bytes in flight
cwnd = min(cwnd, max_bytes_in_flight *
MAX_BYTES_IN_FLIGHT_HEAD_ROOM)
cwnd = max(cwnd, MIN_CWND)
# Apply delta
cwnd += cwnd_delta_t
# limit cwnd to the maximum number of bytes in flight
cwnd = min(cwnd, max_bytes_in_flight *
MAX_BYTES_IN_FLIGHT_HEAD_ROOM)
cwnd = max(cwnd, MIN_CWND)
<CODE ENDS>
<代码结束>
CWND is updated differently depending on whether or not the congestion control is in fast increase mode, as controlled by the variable in_fast_increase.
根据拥塞控制是否处于快速增加模式，CWND的更新方式有所不同，这由_fast_increase中的变量控制。
When in fast increase mode, the congestion window is increased with the number of newly acknowledged bytes as long as the window is sufficiently used. Sparse feedback can potentially limit congestion window growth; therefore, additional slack is added, given by the number of newly acknowledged bytes.
在快速增加模式下，只要窗口得到充分利用，拥塞窗口就会随着新确认的字节数而增加。稀疏反馈可能会限制拥塞窗口的增长；因此，根据新确认的字节数增加额外的空闲时间。
The congestion window growth when in_fast_increase is false is dictated by the relation between qdelay and qdelay_target; congestion window growth is limited if the window is not used sufficiently.
当in_fast_增加为false时，拥塞窗口增长由qdelay和qdelay_目标之间的关系决定；如果窗口没有得到充分利用，拥塞窗口的增长将受到限制。
SCReAM calculates the GAIN in a similar way to what is specified in [RFC6817]. However, [RFC6817] specifies that the CWND increase is limited by an additional function controlled by a constant ALLOWED_INCREASE. This additional limitation is removed in this specification.
CREAM以与[RFC6817]中规定的类似方式计算增益。但是，[RFC6817]指定CWND增加受一个由常量允许的_增加控制的附加函数的限制。本规范中删除了此附加限制。
Further, the CWND is limited by max_bytes_in_flight and MIN_CWND. The limitation of the congestion window by the maximum number of bytes in flight over the last 5 seconds (max_bytes_in_flight) avoids possible overestimation of the throughput after, for example, idle periods. An additional MAX_BYTES_IN_FLIGHT_HEAD_ROOM provides slack to allow for a certain amount of variability in the media coder output rate.
此外，CWND受飞行中的最大字节数和最小CWND的限制。将拥塞窗口限制在过去5秒内的最大传输字节数（最大传输字节数）可避免在空闲时间后可能过高估计吞吐量。飞行头室内的额外最大字节提供了空闲时间，以允许媒体编码器输出速率的一定变化。
It is likely that a flow using the SCReAM algorithm will have to share congested bottlenecks with other flows that use a more aggressive congestion control algorithm (for example, large FTP flows using loss-based congestion control). The worst condition occurs when the bottleneck queues are of tail-drop type with a large buffer size. SCReAM takes care of such situations by adjusting the qdelay_target when loss-based flows are detected, as shown in the pseudocode below.
使用尖叫算法的流可能必须与使用更激进的拥塞控制算法的其他流（例如，使用基于丢失的拥塞控制的大型FTP流）共享拥塞瓶颈。最坏的情况发生在瓶颈队列为尾部丢弃类型且缓冲区较大时。CREAM通过在检测到基于损失的流量时调整qdelay_目标来处理这种情况，如下面的伪代码所示。
<CODE BEGINS>
adjust_qdelay_target(qdelay)
qdelay_norm_t = qdelay / QDELAY_TARGET_LOW
update_qdelay_norm_history(qdelay_norm_t)
# Compute variance
qdelay_norm_var_t = VARIANCE(qdelay_norm_history(200))
# Compensation for competing traffic
# Compute average
qdelay_norm_avg_t = AVERAGE(qdelay_norm_history(50))
# Compute upper limit to target delay
new_target_t = qdelay_norm_avg_t + sqrt(qdelay_norm_var_t)
new_target_t *= QDELAY_TARGET_LO
if (loss_event_rate > 0.002)
# Packet losses detected
qdelay_target = 1.5 * new_target_t
else
if (qdelay_norm_var_t < 0.2)
# Reasonably safe to set target qdelay
qdelay_target = new_target_t
else
# Check if target delay can be reduced; this helps prevent
# the target delay from being locked to high values forever
if (new_target_t < QDELAY_TARGET_LO)
# Decrease target delay quickly, as measured queuing
# delay is lower than target
qdelay_target = max(qdelay_target * 0.5, new_target_t)
else
# Decrease target delay slowly
qdelay_target *= 0.9
end
end
end
<CODE BEGINS>
adjust_qdelay_target(qdelay)
qdelay_norm_t = qdelay / QDELAY_TARGET_LOW
update_qdelay_norm_history(qdelay_norm_t)
# Compute variance
qdelay_norm_var_t = VARIANCE(qdelay_norm_history(200))
# Compensation for competing traffic
# Compute average
qdelay_norm_avg_t = AVERAGE(qdelay_norm_history(50))
# Compute upper limit to target delay
new_target_t = qdelay_norm_avg_t + sqrt(qdelay_norm_var_t)
new_target_t *= QDELAY_TARGET_LO
if (loss_event_rate > 0.002)
# Packet losses detected
qdelay_target = 1.5 * new_target_t
else
if (qdelay_norm_var_t < 0.2)
# Reasonably safe to set target qdelay
qdelay_target = new_target_t
else
# Check if target delay can be reduced; this helps prevent
# the target delay from being locked to high values forever
if (new_target_t < QDELAY_TARGET_LO)
# Decrease target delay quickly, as measured queuing
# delay is lower than target
qdelay_target = max(qdelay_target * 0.5, new_target_t)
else
# Decrease target delay slowly
qdelay_target *= 0.9
end
end
end
# Apply limits
qdelay_target = min(QDELAY_TARGET_HI, qdelay_target)
qdelay_target = max(QDELAY_TARGET_LO, qdelay_target)
<CODE ENDS>
# Apply limits
qdelay_target = min(QDELAY_TARGET_HI, qdelay_target)
qdelay_target = max(QDELAY_TARGET_LO, qdelay_target)
<CODE ENDS>
Two temporary variables are calculated. qdelay_norm_avg_t is the long-term average queue delay, qdelay_norm_var_t is the long-term variance of the queue delay. A high qdelay_norm_var_t indicates that the queue delay changes; this can be an indication that bottleneck bandwidth is reduced or that a competing flow has just entered. Thus, it indicates that it is not safe to adjust the queue delay target.
计算两个临时变量。qdelay_norm_avg_t是长期平均队列延迟，qdelay_norm_var_t是队列延迟的长期方差。高qdelay_norm_var_t表示队列延迟发生变化；这可能表示瓶颈带宽减少或竞争流刚刚进入。因此，这表明调整队列延迟目标是不安全的。
A low qdelay_norm_var_t indicates that the queue delay is relatively stable. The reason could be that the queue delay is low, but it
较低的qdelay_norm_var_t表示队列延迟相对稳定。原因可能是队列延迟较低，但是
could also be that a competing flow is causing the bottleneck to reach the point that packet losses start to occur, in which case the queue delay will stay relatively high for a longer time.
也可能是竞争流导致瓶颈达到数据包丢失开始发生的点，在这种情况下，队列延迟将在较长时间内保持相对较高。
The queue delay target is allowed to be increased if either the loss event rate is above a given threshold or qdelay_norm_var_t is low. Both these conditions indicate that a competing flow may be present. In all other cases, the queue delay target is decreased.
如果丢失事件率高于给定阈值或qdelay_norm_var_t较低，则允许增加队列延迟目标。这两种情况都表明可能存在竞争流。在所有其他情况下，队列延迟目标都会降低。
The function that adjusts the qdelay_target is simple and could produce false positives and false negatives. The case that self-inflicted congestion by the SCReAM algorithm may be falsely interpreted as the presence of competing loss-based FTP flows is a false positive. The opposite case -- where the algorithm fails to detect the presence of a competing FTP flow -- is a false negative.
调整qdelay_目标的功能很简单，可能会产生误报和误报。尖叫算法自我造成的拥塞可能被错误地解释为存在竞争性的基于丢失的FTP流，这种情况是错误的。相反的情况——算法无法检测到竞争FTP流的存在——是假阴性。
Extensive simulations have shown that the algorithm performs well in LTE test cases and that it also performs well in simple bandwidth-limited bottleneck test cases with competing FTP flows. However, the potential failure of the algorithm cannot be completely ruled out. A false positive (i.e., when self-inflicted congestion is mistakenly identified as competing flows) is especially problematic when it leads to increasing the target queue delay, which can cause the end-to-end delay to increase dramatically.
大量仿真表明，该算法在LTE测试用例中表现良好，并且在具有竞争FTP流的简单带宽受限瓶颈测试用例中也表现良好。然而，无法完全排除算法的潜在故障。误报（即，当自我造成的拥塞被错误地识别为竞争流时）在导致目标队列延迟增加时尤其成问题，这可能导致端到端延迟显著增加。
If it is deemed unlikely that competing flows occur over the same bottleneck, the algorithm described in this section MAY be turned off. One such case is QoS-enabled bearers in 3GPP-based access such as LTE. However, when sending over the Internet, often the network conditions are not known for sure, so in general it is not possible to make safe assumptions on how a network is used and whether or not competing flows share the same bottleneck. Therefore, turning this algorithm off must be considered with caution, as it can lead to basically zero throughput if competing with loss-based traffic.
如果认为竞争流不太可能发生在同一瓶颈上，则可关闭本节中描述的算法。其中一种情况是基于3GPP的接入（例如LTE）中的支持QoS的承载。但是，当通过Internet发送时，通常无法确定网络状况，因此通常不可能对如何使用网络以及竞争流是否共享同一瓶颈做出安全的假设。因此，必须谨慎地考虑关闭此算法，因为如果与基于丢失的流量竞争，它可能导致吞吐量基本为零。
Lost packet detection is based on the received sequence number list. A reordering window SHOULD be applied to prevent packet reordering from triggering loss events. The reordering window is specified as a time unit, similar to the ideas behind Recent ACKnowledgement (RACK) [RACK]. The computation of the reordering window is made possible by means of a lost flag in the list of transmitted RTP packets. This flag is set if the received sequence number list indicates that the given RTP packet is missing. If later feedback indicates that a previously lost marked packet was indeed received, then the reordering window is updated to reflect the reordering delay. The reordering window is given by the difference in time between the
丢失数据包检测基于接收到的序列号列表。应该应用重新排序窗口来防止数据包重新排序触发丢失事件。重新排序窗口被指定为一个时间单位，类似于最近确认（RACK）[RACK]背后的思想。通过传输的RTP分组列表中的丢失标志，可以计算重新排序窗口。如果接收到的序列号列表指示给定RTP数据包丢失，则设置此标志。如果稍后的反馈表明确实收到了先前丢失的标记数据包，则重新排序窗口将更新以反映重新排序延迟。重新排序窗口由
event that the packet was marked as lost and the event that it was indicated as successfully received. Loss is detected if a given RTP packet is not acknowledged within a time window (indicated by the reordering window) after an RTP packet with a higher sequence number was acknowledged.
将数据包标记为丢失的事件以及将其指示为成功接收的事件。如果在确认序列号较高的RTP数据包后，给定RTP数据包未在时间窗口（由重新排序窗口指示）内得到确认，则会检测到丢失。
The basic design principle behind packet transmission in SCReAM is to allow transmission only if the number of bytes in flight is less than the congestion window. There are, however, two reasons why this strict rule will not work optimally:
尖叫中数据包传输的基本设计原则是，仅当传输中的字节数小于拥塞窗口时，才允许传输。然而，有两个原因导致这一严格规则无法发挥最佳作用：
o Bitrate variations: Media sources such as video encoders generally produce frames whose size always vary to a larger or smaller extent. The RTP queue absorbs the natural variations in frame sizes. However, the RTP queue should be as short as possible to prevent the end-to-end delay from increasing. To achieve that, the media rate control takes the RTP queue size into account when the target bitrate for the media is computed. A strict 'send only when bytes in flight is less than the congestion window' rule can cause the RTP queue to grow simply because the send window is limited; in turn, this can cause the target bitrate to be pushed down. The consequence is that the congestion window will not increase, or will increase very slowly, because the congestion window is only allowed to increase when there is a sufficient amount of data in flight. The final effect is that the media bitrate increases very slowly or not at all.
o 比特率变化：媒体源（如视频编码器）通常会产生帧，其大小总是在较大或较小的范围内变化。RTP队列吸收了帧大小的自然变化。但是，RTP队列应尽可能短，以防止端到端延迟增加。为此，在计算媒体的目标比特率时，媒体速率控制会考虑RTP队列大小。严格的“仅当传输中的字节数小于拥塞窗口时发送”规则可能会导致RTP队列增长，因为发送窗口有限；反过来，这会导致目标比特率降低。其结果是拥塞窗口将不会增加，或将非常缓慢地增加，因为只有当飞行中有足够的数据量时，才允许拥塞窗口增加。最后的效果是媒体比特率增长非常缓慢或根本没有增长。
o Reverse (feedback) path congestion: Especially in transport over buffer-bloated networks, the one-way delay in the reverse direction can jump due to congestion. The effect is that the acknowledgements are delayed, and the self-clocking is temporarily halted, even though the forward path is not congested.
o 反向（反馈）路径拥塞：特别是在缓冲区膨胀网络上的传输中，反向的单向延迟可能由于拥塞而跳跃。其结果是，即使前向路径不拥挤，确认被延迟，并且自时钟被暂时停止。
The send window is adjusted depending on qdelay, its relation to the qdelay target, and the relation between the congestion window and the number of bytes in flight. A strict rule is applied when qdelay is higher than qdelay_target, to avoid further queue buildup in the network. For cases when qdelay is lower than the qdelay_target, a more relaxed rule is applied. This allows the bitrate to increase quickly when no congestion is detected while still being able to exhibit stable behavior in congested situations.
发送窗口根据qdelay、其与qdelay目标的关系以及拥塞窗口与传输中的字节数之间的关系进行调整。当qdelay高于qdelay_目标时，将应用严格的规则，以避免网络中进一步的队列累积。对于qdelay低于qdelay_目标的情况，将应用更宽松的规则。这允许在未检测到拥塞时比特率快速增加，同时在拥塞情况下仍能表现出稳定的行为。
The send window is given by the relation between the adjusted congestion window and the amount of bytes in flight according to the pseudocode below.
根据下面的伪码，通过调整的拥塞窗口和传输中的字节数之间的关系给出发送窗口。
<CODE BEGINS>
calculate_send_window(qdelay, qdelay_target)
# send window is computed differently depending on congestion level
if (qdelay <= qdelay_target)
send_wnd = cwnd + MSS - bytes_in_flight
else
send_wnd = cwnd - bytes_in_flight
end
<CODE ENDS>
<CODE BEGINS>
calculate_send_window(qdelay, qdelay_target)
# send window is computed differently depending on congestion level
if (qdelay <= qdelay_target)
send_wnd = cwnd + MSS - bytes_in_flight
else
send_wnd = cwnd - bytes_in_flight
end
<CODE ENDS>
The send window is updated whenever an RTP packet is transmitted or an RTCP feedback messaged is received.
无论何时发送RTP数据包或接收到RTCP反馈消息，发送窗口都会更新。
Packet pacing is used in order to mitigate coalescing, i.e., when packets are transmitted in bursts, with the risks of increased jitter and potentially increased packet loss. Packet pacing also mitigates possible issues with queue overflow due to key-frame generation in video coders. The time interval between consecutive packet transmissions is greater than or equal to t_pace, where t_pace is given by the equations below :
数据包调速用于缓解合并，即当数据包以突发方式传输时，会增加抖动和潜在的数据包丢失风险。数据包调整还可以缓解由于视频编码器中关键帧的生成而可能出现的队列溢出问题。连续分组传输之间的时间间隔大于或等于t_-pace，其中t_-pace由下式给出：
<CODE BEGINS>
pace_bitrate = max (RATE_PACE_MIN, cwnd * 8 / s_rtt)
t_pace = rtp_size * 8 / pace_bitrate
<CODE ENDS>
<CODE BEGINS>
pace_bitrate = max (RATE_PACE_MIN, cwnd * 8 / s_rtt)
t_pace = rtp_size * 8 / pace_bitrate
<CODE ENDS>
rtp_size is the size of the last transmitted RTP packet, and s_rtt is the smoothed round trip time. RATE_PACE_MIN is the minimum pacing rate.
rtp_size是最后发送的rtp数据包的大小，s_rtt是平滑的往返时间。RATE_PACE_MIN是最小起搏速率。
Fast increase mode can resume in order to speed up the bitrate increase if congestion abates. The condition to resume fast increase mode (in_fast_increase = true) is that qdelay_trend is less than QDELAY_TREND_LO for T_RESUME_FAST_INCREASE seconds or more.
如果拥塞减轻，可以恢复快速增加模式以加快比特率的增加。恢复快速增加模式的条件（在快速增加=真）是，对于T_resume_fast_increase秒或更长时间，qdelay_trend小于qdelay_trend_LO。
The SCReAM algorithm makes a good distinction between network congestion control and media rate control. This is easily extended to many streams -- RTP packets from two or more RTP queues are scheduled at the rate permitted by the network congestion control.
尖叫算法很好地区分了网络拥塞控制和媒体速率控制。这很容易扩展到许多流——来自两个或多个RTP队列的RTP数据包以网络拥塞控制允许的速率进行调度。
The scheduling can be done by means of a few different scheduling regimes. For example, the method for coupled congestion control
调度可以通过几种不同的调度机制来完成。例如，耦合拥塞控制方法
specified in [COUPLED-CC] can be used. One implementation of SCReAM [SCReAM-CPP-implementation] uses credit-based scheduling. In credit-based scheduling, credit is accumulated by queues as they wait for service and is spent while the queues are being serviced. For instance, if one queue is allowed to transmit 1000 bytes, then a credit of 1000 bytes is allocated to the other unscheduled queues. This principle can be extended to weighted scheduling, where the credit allocated to unscheduled queues depends on the relative weights. The latter is also implemented in [SCReAM-CPP-implementation].
可以使用[COUPLED-CC]中指定的。CREAR[CREAR CPP implementation]的一个实现使用基于信用的调度。在基于信用的调度中，信用由队列在等待服务时累积，并在队列服务时消耗。例如，如果允许一个队列传输1000字节，那么1000字节的信用将分配给其他未计划的队列。该原理可以推广到加权调度，其中分配给未调度队列的信用取决于相对权重。后者也在[尖叫CPP实现]中实现。
The media rate control algorithm is executed at regular intervals, indicated by RATE_ADJUSTMENT_INTERVAL, with the exception of a prompt reaction to loss events. The media rate control operates based on the size of the RTP packet send queue and observed loss events. In addition, qdelay_trend is also considered in the media rate control in order to reduce the amount of induced network jitter.
媒体速率控制算法以固定的间隔执行，以速率调整间隔表示，对丢失事件的快速反应除外。媒体速率控制根据RTP数据包发送队列的大小和观察到的丢失事件进行操作。此外，在媒体速率控制中还考虑了qdelay_趋势，以减少诱发的网络抖动量。
The role of the media rate control is to strike a reasonable balance between a low amount of queuing in the RTP queue(s) and a sufficient amount of data to send in order to keep the data path busy. Setting the media rate control too cautiously leads to possible underutilization of network capacity; this can cause the flow to become starved out by other more opportunistic traffic. On the other hand, setting it too aggressively leads to increased jitter.
媒体速率控制的作用是在RTP队列中的低排队量和要发送的足够数据量之间达成合理的平衡，以保持数据路径繁忙。过于谨慎地设置媒体速率控制可能导致网络容量利用不足；这可能导致流被其他更机会主义的流量耗尽。另一方面，设置太过激进会导致抖动增加。
The target_bitrate is adjusted depending on the congestion state. The target bitrate can vary between a minimum value (TARGET_BITRATE_MIN) and a maximum value (TARGET_BITRATE_MAX). TARGET_BITRATE_MIN SHOULD be set to a low enough value to prevent RTP packets from becoming queued up when the network throughput is reduced. The sender SHOULD also be equipped with a mechanism that discards RTP packets when the network throughput becomes very low and RTP packets are excessively delayed.
目标_比特率根据拥塞状态进行调整。目标比特率可以在最小值（目标比特率）和最大值（目标比特率）之间变化。应将TARGET_BITRATE_MIN设置为足够低的值，以防止RTP数据包在网络吞吐量降低时排队。发送方还应配备一种机制，当网络吞吐量变得非常低且RTP数据包过度延迟时，该机制将丢弃RTP数据包。
For the overall bitrate adjustment, two network throughput estimates are computed :
对于整体比特率调整，计算两个网络吞吐量估计值：
o rate_transmit: The measured transmit bitrate.
o 传输速率：测量的传输比特率。
o rate_ack: The ACKed bitrate, i.e., the volume of ACKed bits per second.
o rate_ack：已确认的比特率，即每秒已确认比特的数量。
Both estimates are updated every 200 ms.
这两个估计值每200毫秒更新一次。
The current throughput, current_rate, is computed as the maximum value of rate_transmit and rate_ack. The rationale behind the use of rate_ack in addition to rate_transmit is that rate_transmit is affected also by the amount of data that is available to transmit, thus a lack of data to transmit can be seen as reduced throughput that can cause an unnecessary rate reduction. To overcome this shortcoming, rate_ack is used as well. This gives a more stable throughput estimate.
当前吞吐量，即当前速率，计算为速率发送和速率确认的最大值。除了rate_传输之外，使用rate_ack的基本原理是，rate_传输也受可传输数据量的影响，因此，缺少要传输的数据可被视为吞吐量降低，从而导致不必要的速率降低。为了克服这个缺点，还使用了rate_ack。这提供了一个更稳定的吞吐量估计。
The rate change behavior depends on whether a loss or ECN event has occurred and whether the congestion control is in fast increase mode.
速率变化行为取决于是否发生丢失或ECN事件，以及拥塞控制是否处于快速增加模式。
<CODE BEGINS> # The target_bitrate is updated at a regular interval according # to RATE_ADJUST_INTERVAL
<CODE BEGINS>#目标#比特率根据#速率#调整#间隔定期更新
on loss: # Loss event detected target_bitrate = max(BETA_R * target_bitrate, TARGET_BITRATE_MIN) exit on ecn_mark: # ECN event detected target_bitrate = max(BETA_ECN * target_bitrate, TARGET_BITRATE_MIN) exit
丢失时：#丢失事件检测到的目标比特率=最大值（BETA#R*目标比特率，目标比特率，目标比特率，最小值）退出ecn标记：#ecn事件检测到的目标比特率=最大值（BETA#ecn*目标比特率，目标比特率，最小值）退出
ramp_up_speed_t = min(RAMP_UP_SPEED, target_bitrate / 2.0)
scale_t = (target_bitrate - target_bitrate_last_max) /
target_bitrate_last_max
scale_t = max(0.2, min(1.0, (scale_t * 4)^2))
# min scale_t value 0.2, as the bitrate should be allowed to
# increase slowly. This prevents locking the rate to
# target_bitrate_last_max
if (in_fast_increase = true)
increment_t = ramp_up_speed_t * RATE_ADJUST_INTERVAL
increment_t *= scale_t
target_bitrate += increment_t
else
current_rate_t = max(rate_transmit, rate_ack)
# Compute a bitrate change
delta_rate_t = current_rate_t * (1.0 - PRE_CONGESTION_GUARD *
queue_delay_trend) - TX_QUEUE_SIZE_FACTOR * rtp_queue_size
# Limit a positive increase if close to target_bitrate_last_max
if (delta_rate_t > 0)
delta_rate_t *= scale_t
delta_rate_t =
min(delta_rate_t, ramp_up_speed_t * RATE_ADJUST_INTERVAL)
ramp_up_speed_t = min(RAMP_UP_SPEED, target_bitrate / 2.0)
scale_t = (target_bitrate - target_bitrate_last_max) /
target_bitrate_last_max
scale_t = max(0.2, min(1.0, (scale_t * 4)^2))
# min scale_t value 0.2, as the bitrate should be allowed to
# increase slowly. This prevents locking the rate to
# target_bitrate_last_max
if (in_fast_increase = true)
increment_t = ramp_up_speed_t * RATE_ADJUST_INTERVAL
increment_t *= scale_t
target_bitrate += increment_t
else
current_rate_t = max(rate_transmit, rate_ack)
# Compute a bitrate change
delta_rate_t = current_rate_t * (1.0 - PRE_CONGESTION_GUARD *
queue_delay_trend) - TX_QUEUE_SIZE_FACTOR * rtp_queue_size
# Limit a positive increase if close to target_bitrate_last_max
if (delta_rate_t > 0)
delta_rate_t *= scale_t
delta_rate_t =
min(delta_rate_t, ramp_up_speed_t * RATE_ADJUST_INTERVAL)
end target_bitrate += delta_rate_t # Force a slight reduction in bitrate if RTP queue # builds up rtp_queue_delay_t = rtp_queue_size / current_rate_t if (rtp_queue_delay_t > RTP_QDELAY_TH) target_bitrate *= TARGET_RATE_SCALE_RTP_QDELAY end end
end target_bitrate+=delta_rate#如果RTP queue#建立RTP_queue_delay#t=RTP_queue_size/current_rate_t>RTP_QDELAY_TH）目标_bitrate*=目标_rate_SCALE_RTP_QDELAY end end end end
rate_media_limit_t =
max(current_rate_t, max(rate_media, rtp_rate_median))
rate_media_limit_t *= (2.0 - qdelay_trend_mem)
target_bitrate = min(target_bitrate, rate_media_limit_t)
target_bitrate = min(TARGET_BITRATE_MAX,
max(TARGET_BITRATE_MIN, target_bitrate))
<CODE ENDS>
rate_media_limit_t =
max(current_rate_t, max(rate_media, rtp_rate_median))
rate_media_limit_t *= (2.0 - qdelay_trend_mem)
target_bitrate = min(target_bitrate, rate_media_limit_t)
target_bitrate = min(TARGET_BITRATE_MAX,
max(TARGET_BITRATE_MIN, target_bitrate))
<CODE ENDS>
In case of a loss event, the target_bitrate is updated and the rate change procedure is exited. Otherwise, the rate change procedure continues. The rationale behind the rate reduction due to loss is that a congestion window reduction will take effect, and a rate reduction proactively prevents RTP packets from being queued up when the transmit rate decreases due to the reduced congestion window. A similar rate reduction happens when ECN events are detected.
如果发生丢失事件，则更新目标_比特率并退出速率更改过程。否则，速率更改过程将继续。由于丢失而导致的速率降低的基本原理是，拥塞窗口的降低将生效，并且当传输速率由于拥塞窗口的减小而降低时，速率降低会主动防止RTP数据包排队。当检测到ECN事件时，也会发生类似的速率降低。
The rate update frequency is limited by RATE_ADJUST_INTERVAL, unless a loss event occurs. The value is based on experimentation with real-life limitations in video coders taken into account [SCReAM-CPP-implementation]. A too short interval is shown to make the rate control loop in video coders more unstable; a too long interval makes the overall congestion control sluggish.
除非发生丢失事件，否则速率更新频率受速率调整间隔的限制。该值基于对视频编码器的实际限制进行的实验，并将其考虑在内[尖叫CPP实现]。时间间隔过短会使视频编码器中的速率控制环路更加不稳定；间隔太长会导致整体拥塞控制缓慢。
When in fast increase mode (in_fast_increase = true), the bitrate increase is given by the desired ramp-up speed (RAMP_UP_SPEED). The ramp-up speed is limited when the target bitrate is low to avoid rate oscillation at low bottleneck bitrates. The setting of RAMP_UP_SPEED depends on preferences. A high setting such as 1000 kbps/s makes it possible to quickly get high-quality media; however, this is at the expense of increased jitter, which can manifest itself as choppy video rendering, for example.
在快速增加模式下（in_fast_increase=true），比特率增加由所需的爬升速度（ramp_up_speed）给出。当目标比特率较低时，爬升速度受到限制，以避免在低瓶颈比特率下的速率振荡。斜坡上升速度的设置取决于首选项。高设置（如1000 kbps/s）使快速获取高质量介质成为可能；然而，这是以增加抖动为代价的，例如，抖动可以表现为视频渲染的起伏。
When in_fast_increase is false, the bitrate increase is given by the current bitrate and is also controlled by the estimated RTP queue and the qdelay trend, thus it is sufficient that an increased congestion level is sensed by the network congestion control to limit the bitrate. The target_bitrate_last_max is updated when congestion is detected.
当in_fast_increase为false时，比特率增加由当前比特率给出，并且还由估计的RTP队列和qdelay趋势控制，因此网络拥塞控制感测到增加的拥塞级别足以限制比特率。当检测到拥塞时，将更新目标比特率\u last\u max。
Finally, the target_bitrate is within the defined min and max values.
最后，目标_比特率在定义的最小值和最大值内。
The aware reader may notice the dependency on the qdelay in the computation of the target bitrate; this manifests itself in the use of the qdelay_trend. As these parameters are used also in the network congestion control, one may suspect some odd interaction between the media rate control and the network congestion control. This is in fact the case if the parameter PRE_CONGESTION_GUARD is set to a high value. The use of qdelay_trend in the media rate control is solely to reduce jitter; the dependency can be removed by setting PRE_CONGESTION_GUARD=0. The effect is a somewhat larger rate increase after congestion, at the expense of increased jitter in congested situations.
意识到的读取器可以注意到在目标比特率的计算中对qdelay的依赖性；这体现在qdelay_趋势的使用上。由于这些参数也用于网络拥塞控制，人们可能会怀疑媒体速率控制和网络拥塞控制之间存在一些奇怪的交互作用。如果参数PRE_拥塞_GUARD设置为高值，则实际上就是这种情况。在媒体速率控制中使用qdelay_trend仅仅是为了减少抖动；通过将PRE_拥塞_GUARD设置为0，可以删除依赖关系。其效果是在拥塞后速率有较大的增加，而在拥塞情况下抖动会增加。
The simple task of the SCReAM receiver is to feed back acknowledgements of received packets and total ECN count to the SCReAM sender. In addition, the receive time of the RTP packet with the highest sequence number is echoed back. Upon reception of each RTP packet, the receiver MUST maintain enough information to send the aforementioned values to the SCReAM sender via an RTCP transport-layer feedback message. The frequency of the feedback message depends on the available RTCP bandwidth. The requirements on the feedback elements and the feedback interval are described below.
尖叫接收器的简单任务是将接收到的数据包的确认和总ECN计数反馈给尖叫发送者。此外，具有最高序列号的RTP分组的接收时间被回显。在接收到每个RTP数据包后，接收器必须保持足够的信息，以便通过RTCP传输层反馈消息将上述值发送给尖叫发送器。反馈消息的频率取决于可用RTCP带宽。反馈元件和反馈间隔的要求如下所述。
The following feedback elements are REQUIRED for basic functionality in SCReAM.
尖叫中的基本功能需要以下反馈元素。
o A list of received RTP packets. This list SHOULD be sufficiently long to cover all received RTP packets. This list can be realized with the Loss RLE (Run Length Encoding) Report Block in [RFC3611].
o 接收到的RTP数据包的列表。该列表应足够长，以覆盖所有接收到的RTP数据包。此列表可通过[RFC3611]中的丢失RLE（行程编码）报告块实现。
o A wall-clock timestamp corresponding to the received RTP packet with the highest sequence number is required in order to compute the qdelay. This can be realized by means of the Packet Receipt Times Report Block in [RFC3611]. begin_seq MUST be set to the highest received sequence number (which has possibly wrapped around); end_seq MUST be set to begin_seq+1 modulo 65536. The timestamp clock MAY be set according to [RFC3611], i.e., equal to the RTP timestamp clock. Detailed individual packet receive times are not necessary, as SCReAM does currently not describe how they can be used.
o 为了计算qdelay，需要与具有最高序列号的接收RTP分组相对应的挂钟时间戳。这可以通过[RFC3611]中的数据包接收时间报告块实现。begin_seq必须设置为最高接收序列号（可能已环绕）；结束顺序必须设置为开始顺序+1模65536。时间戳时钟可根据[RFC3611]设置，即等于RTP时间戳时钟。详细的单个数据包接收时间是不必要的，因为CREAM目前没有描述如何使用它们。
The basic feedback needed for SCReAM involves the use of the Loss RLE Report Block and the Packet Receipt Times Report Block as shown in Figure 2.
CREAM所需的基本反馈包括使用丢失RLE报告块和数据包接收时间报告块，如图2所示。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|reserved | PT=XR=207 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=2 | rsvd. | T=0 | block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| chunk 1 | chunk 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| chunk n-1 | chunk n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=3 | rsvd. | T=0 | block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receipt time of packet begin_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|reserved | PT=XR=207 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=2 | rsvd. | T=0 | block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| chunk 1 | chunk 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| chunk n-1 | chunk n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=3 | rsvd. | T=0 | block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receipt time of packet begin_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Basic Feedback Message for SCReAM, Based on RFC 3611
图2：基于RFC3611的尖叫的基本反馈信息
In a typical use case, no more than four Loss RLE chunks are needed, thus the feedback message will be 44 bytes. It is obvious from Figure 2 that there is a lot of redundant information in the feedback message. A more optimized feedback format, including the additional feedback elements listed below, could reduce the feedback message size a bit.
在典型的用例中，不需要超过四个丢失的RLE块，因此反馈消息将是44字节。从图2中可以明显看出，反馈消息中存在大量冗余信息。更优化的反馈格式，包括下面列出的其他反馈元素，可以稍微减少反馈消息的大小。
An additional feedback element that can improve the performance of SCReAM is:
可以提高尖叫性能的另一个反馈元素是：
o Accumulated number of ECN-CE-marked packets (n_ECN). For instance, this can be realized with the ECN Feedback Report Format in [RFC6679]. The given feedback report format is slightly overkill, as SCReAM would do quite well with only a counter that
o ECN CE标记数据包（n_ECN）的累积数量。例如，这可以通过[RFC6679]中的ECN反馈报告格式实现。给定的反馈报告格式有点过分，因为只有一个计数器
increments by one for each received packet with the ECN-CE codepoint set. The more bulky format could nevertheless be useful for, e.g., ECN black-hole detection.
对于使用ECN-CE码点集的每个接收数据包，增量为1。然而，更大的格式可能对ECN黑洞探测有用。
SCReAM benefits from relatively frequent feedback. It is RECOMMENDED that a SCReAM implementation follows the guidelines below.
尖叫得益于相对频繁的反馈。建议尖叫实现遵循以下指导原则。
The feedback interval depends on the media bitrate. At low bitrates, it is sufficient with a feedback interval of 100 to 400 ms; while at high bitrates, a feedback interval of roughly 20 ms is preferred. At very high bitrates, even shorter feedback intervals MAY be needed in order to keep the self-clocking in SCReAM working well. One indication that feedback is too sparse is that the SCReAM implementation cannot reach high bitrates, even in uncongested links. More frequent feedback might solve this issue.
反馈间隔取决于媒体比特率。在低比特率下，反馈间隔为100到400ms就足够了；而在高比特率下，最好是大约20毫秒的反馈间隔。在非常高的比特率下，可能需要更短的反馈间隔，以保持自计时尖叫正常工作。反馈过于稀疏的一个迹象是尖叫实现无法达到高比特率，即使在未压缩的链路中也是如此。更频繁的反馈可能会解决这个问题。
The numbers above can be formulated as a feedback interval function that can be useful for the computation of the desired RTCP bandwidth. The following equation expresses the feedback rate:
上述数字可表示为反馈间隔函数，可用于计算所需RTCP带宽。以下方程式表示反馈率：
rate_fb = min(50, max(2.5, rate_media / 10000))
rate_fb = min(50, max(2.5, rate_media / 10000))
rate_media is the RTP media bitrate expressed in bps; rate_fb is the feedback rate expressed in packets/s. Converting to feedback interval, we get:
rate_media是以bps表示的RTP媒体比特率；rate_fb是以数据包/秒表示的反馈速率。转换为反馈间隔，我们得到：
fb_int = 1.0 / min(50, max(2.5, rate_media / 10000))
fb_int = 1.0 / min(50, max(2.5, rate_media / 10000))
The transmission interval is not critical. So, in the case of multi-stream handling between two hosts, the feedback for two or more synchronization sources (SSRCs) can be bundled to save UDP/IP overhead. However, the final realized feedback interval SHOULD not exceed 2*fb_int in such cases, meaning that a scheduled feedback transmission event should not be delayed more than fb_int.
传输间隔不是关键的。因此，在两台主机之间进行多流处理的情况下，可以绑定两个或多个同步源（SSRC）的反馈，以节省UDP/IP开销。然而，在这种情况下，最终实现的反馈间隔不应超过2*fb_int，这意味着预定反馈传输事件的延迟不应超过fb_int。
SCReAM works with AVPF regular mode; immediate or early mode is not required by SCReAM but can nonetheless be useful for RTCP messages not directly related to SCReAM, such as those specified in [RFC4585]. It is RECOMMENDED to use reduced-size RTCP [RFC5506], where regular full compound RTCP transmission is controlled by trr-int as described in [RFC4585].
尖叫与AVPF常规模式一起工作；CREAM不需要立即或早期模式，但对于与CREAM不直接相关的RTCP消息（如[RFC4585]中指定的消息）仍然有用。建议使用缩小的RTCP[RFC5506]，其中常规的全复合RTCP传输由[RFC4585]中所述的trr int控制。
This section covers a few discussion points.
本节介绍几个讨论点。
o Clock drift: SCReAM can suffer from the same issues with clock drift as is the case with LEDBAT [RFC6817]. However, Appendix A.2 in [RFC6817] describes ways to mitigate issues with clock drift.
o 时钟漂移：CREAM可能会遇到与LEDBAT相同的时钟漂移问题[RFC6817]。然而，[RFC6817]中的附录A.2描述了缓解时钟漂移问题的方法。
o Support for alternate ECN semantics: This specification adopts the proposal in [ALT-BACKOFF] to reduce the congestion window less when ECN-based congestion events are detected. Future work on Low Loss, Low Latency for Scalable throughput (L4S) may lead to updates in a future document that describes SCReAM support for L4S.
o 支持备用ECN语义：本规范采用[ALT-BACKOFF]中的建议，在检测到基于ECN的拥塞事件时减少拥塞窗口。未来关于低损耗、低延迟的可扩展吞吐量（L4S）的工作可能会导致在未来的文档中进行更新，该文档描述了对L4S的尖叫支持。
o A new transport-layer feedback message (as specified in RFC 4585) could be standardized if the use of the already existing RTCP extensions as described in Section 4.2 is not deemed sufficient.
o 如果使用第4.2节所述的现有RTCP扩展不够，则可以标准化新的传输层反馈消息（如RFC 4585中规定）。
o The target bitrate given by SCReAM is the bitrate including the RTP and Forward Error Correction (FEC) overhead. The media encoder SHOULD take this overhead into account when the media bitrate is set. This means that the media coder bitrate SHOULD be computed as
o CREAM给出的目标比特率是包括RTP和前向纠错（FEC）开销的比特率。在设置媒体比特率时，媒体编码器应将此开销考虑在内。这意味着媒体编码器比特率应计算为
media_rate = target_bitrate - rtp_plus_fec_overhead_bitrate
媒体比特率=目标比特率-rtp比特率加上fec开销比特率
It is not necessary to make a 100% perfect compensation for the overhead, as the SCReAM algorithm will inherently compensate for moderate errors. Under-compensating for the overhead has the effect of increasing jitter, while overcompensating will cause the bottleneck link to become underutilized.
没有必要对开销进行100%的完美补偿，因为尖叫算法本身会补偿中等误差。开销补偿不足会增加抖动，而过度补偿会导致瓶颈链路未充分利用。
SCReAM has been evaluated in a number of different ways, mostly in a simulator. The OpenWebRTC implementation work ([OpenWebRTC] and [SCReAM-implementation]) involved extensive testing with artificial bottlenecks with varying bandwidths and using two different video coders (OpenH264 and VP9).
尖叫已经通过许多不同的方式进行了评估，主要是在模拟器中。OpenWebRTC实施工作（[OpenWebRTC]和[CREAR实施]）涉及使用不同带宽的人工瓶颈进行广泛测试，并使用两种不同的视频编码器（OpenH264和VP9）。
Preferably, further experiments will be done by means of implementation in real clients and web browsers. RECOMMENDED experiments are:
优选地，将通过在真实客户端和web浏览器中实现来进行进一步的实验。建议的实验包括：
o Trials with various access technologies: EDGE/3G/4G, Wi-Fi, DSL. Some experiments have already been carried out with LTE access; see [SCReAM-CPP-implementation] and [SCReAM-implementation-experience].
o 各种接入技术的试用：EDGE/3G/4G、Wi-Fi、DSL。已经使用LTE接入进行了一些实验；请参阅[尖叫CPP实施]和[尖叫实施经验]。
o Trials with different kinds of media: Audio, video, slideshow content. Evaluation of multi-stream handling in SCReAM.
o 不同媒体的试用：音频、视频、幻灯片内容。尖叫中多流处理的评估。
o Evaluation of functionality of the compensation mechanism when there are competing flows: Evaluate how SCReAM performs with competing TCP-like traffic and to what extent the compensation for competing flows causes self-inflicted congestion.
o 当存在竞争流时，评估补偿机制的功能：评估SCReAM如何处理竞争的TCP类流量，以及竞争流的补偿在多大程度上会导致自身造成的拥塞。
o Determine proper parameters: A set of default parameters are given that makes SCReAM work over a reasonably large operation range. However, for very low or very high bitrates, it may be necessary to use different values for the RAMP_UP_SPEED, for instance.
o 确定合适的参数：给出一组默认参数，使CREARE在相当大的操作范围内工作。然而，对于非常低或非常高的比特率，例如，可能需要使用不同的斜坡上升速度值。
o Experimentation with further improvements to the congestion window and media bitrate calculation. [SCReAM-CPP-implementation] implements some optimizations, not described in this memo, that improve performance slightly. Further experiments are likely to lead to more optimizations of the algorithm.
o 进一步改进拥塞窗口和媒体比特率计算的实验。[SCReAM CPP实施]实施了一些优化，这些优化没有在本备忘录中描述，只是略微提高了性能。进一步的实验可能会导致对算法进行更多的优化。
This document does not require any IANA actions.
本文件不要求IANA采取任何行动。
The feedback can be vulnerable to attacks similar to those that can affect TCP. It is therefore RECOMMENDED that the RTCP feedback is at least integrity protected. Furthermore, as SCReAM is self-clocked, a malicious middlebox can drop RTCP feedback packets and thus cause the self-clocking in SCReAM to stall. However, this attack is mitigated by the minimum send rate maintained by SCReAM when no feedback is received.
反馈可能容易受到与影响TCP的攻击类似的攻击。因此，建议RTCP反馈至少受到完整性保护。此外，由于SCReAM是自计时的，恶意的中间盒可能会丢弃RTCP反馈数据包，从而导致自计时的SCReAM暂停。但是，当没有收到反馈时，通过CREAM保持的最小发送速率可以减轻此攻击。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 3550，DOI 10.17487/RFC3550，2003年7月<https://www.rfc-editor.org/info/rfc3550>.
[RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, DOI 10.17487/RFC3611, November 2003, <https://www.rfc-editor.org/info/rfc3611>.
[RFC3611]Friedman，T.，Ed.，Caceres，R.，Ed.，和A.Clark，Ed.，“RTP控制协议扩展报告（RTCP XR）”，RFC 3611，DOI 10.17487/RFC36112003年11月<https://www.rfc-editor.org/info/rfc3611>.
[RFC4585] 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, DOI 10.17487/RFC4585, July 2006, <https://www.rfc-editor.org/info/rfc4585>.
[RFC4585]Ott，J.，Wenger，S.，Sato，N.，Burmeister，C.，和J.Rey，“基于实时传输控制协议（RTCP）的反馈（RTP/AVPF）的扩展RTP配置文件”，RFC 4585，DOI 10.17487/RFC4585，2006年7月<https://www.rfc-editor.org/info/rfc4585>.
[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences", RFC 5506, DOI 10.17487/RFC5506, April 2009, <https://www.rfc-editor.org/info/rfc5506>.
[RFC5506]Johansson，I.和M.Westerlund，“支持缩小尺寸实时传输控制协议（RTCP）：机会和后果”，RFC 5506，DOI 10.17487/RFC5506，2009年4月<https://www.rfc-editor.org/info/rfc5506>.
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, "Computing TCP's Retransmission Timer", RFC 6298, DOI 10.17487/RFC6298, June 2011, <https://www.rfc-editor.org/info/rfc6298>.
[RFC6298]Paxson，V.，Allman，M.，Chu，J.，和M.Sargent，“计算TCP的重传计时器”，RFC 6298，DOI 10.17487/RFC62982011年6月<https://www.rfc-editor.org/info/rfc6298>.
[RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, DOI 10.17487/RFC6817, December 2012, <https://www.rfc-editor.org/info/rfc6817>.
[RFC6817]Shalunov，S.，Hazel，G.，Iyengar，J.，和M.Kuehlewind，“低额外延迟背景传输（LEDBAT）”，RFC 6817，DOI 10.17487/RFC6817，2012年12月<https://www.rfc-editor.org/info/rfc6817>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[ALT-BACKOFF] Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst, "TCP Alternative Backoff with ECN (ABE)", Work in Progress, draft-ietf-tcpm-alternativebackoff-ecn-04, November 2017.
[ALT-BACKOFF]Khademi，N.，Welzl，M.，Armitage，G.，和G.Fairhurst，“使用ECN（ABE）的TCP替代性退避”，正在进行的工作，草案-ietf-tcpm-Alternative BACKOFF-ECN-042017年11月。
[COUPLED-CC] Islam, S., Welzl, M., and S. Gjessing, "Coupled congestion control for RTP media", Work in Progress, draft-ietf-rmcat-coupled-cc-07, September 2017.
[COUPLED-CC]Islam，S.，Welzl，M.，和S.Gjessing，“RTP媒体的耦合拥塞控制”，正在进行的工作，草稿-ietf-rmcat-COUPLED-CC-07，2017年9月。
[LEDBAT-delay-impact] Ros, D. and M. Welzl, "Assessing LEDBAT's Delay Impact", IEEE Communications Letters, Vol. 17, No. 5, DOI 10.1109/LCOMM.2013.040213.130137, May 2013, <http://home.ifi.uio.no/michawe/research/publications/ ledbat-impact-letters.pdf>.
[LEDBAT延迟影响]Ros，D.和M.Welzl，“评估LEDBAT的延迟影响”，《IEEE通讯快报》，第17卷，第5期，DOI 10.1109/LCOMM.2013.040213.130137，2013年5月<http://home.ifi.uio.no/michawe/research/publications/ ledbat impact letters.pdf>。
[OpenWebRTC] Ericsson Research, "OpenWebRTC", <http://www.openwebrtc.org>.
[OpenWebRTC]爱立信研究公司，“OpenWebRTC”<http://www.openwebrtc.org>.
[Packet-conservation] Jacobson, V., "Congestion Avoidance and Control", ACM SIGCOMM Computer Communication Review, DOI 10.1145/52325.52356, August 1988.
[数据包保护]Jacobson，V.，“拥塞避免和控制”，ACM SIGCOMM计算机通信评论，DOI 10.1145/52325.52356，1988年8月。
[QoS-3GPP] 3GPP, "Policy and charging control architecture", 3GPP TS 23.203, July 2017, <http://www.3gpp.org/ftp/specs/archive/23_series/23.203/>.
[QoS-3GPP]3GPP，“策略和计费控制体系结构”，3GPP TS 23.203，2017年7月<http://www.3gpp.org/ftp/specs/archive/23_series/23.203/>.
[RACK] Cheng, Y., Cardwell, N., and N. Dukkipati, "RACK: a time-based fast loss detection algorithm for TCP", Work in Progress, draft-ietf-tcpm-rack-02, March 2017.
[RACK]Cheng，Y.，Cardwell，N.，和N.Dukkipati，“RACK:TCP基于时间的快速丢失检测算法”，正在进行的工作，草稿-ietf-tcpm-RACK-02，2017年3月。
[RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., and K. Carlberg, "Explicit Congestion Notification (ECN) for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 2012, <https://www.rfc-editor.org/info/rfc6679>.
[RFC6679]Westerlund，M.，Johansson，I.，Perkins，C.，O'Hanlon，P.，和K.Carlberg，“UDP上RTP的显式拥塞通知（ECN）”，RFC 6679，DOI 10.17487/RFC66792012年8月<https://www.rfc-editor.org/info/rfc6679>.
[RFC7478] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real-Time Communication Use Cases and Requirements", RFC 7478, DOI 10.17487/RFC7478, March 2015, <https://www.rfc-editor.org/info/rfc7478>.
[RFC7478]Holmberg，C.，Hakanson，S.，和G.Eriksson，“网络实时通信用例和需求”，RFC 7478，DOI 10.17487/RFC7478，2015年3月<https://www.rfc-editor.org/info/rfc7478>.
[RFC7661] Fairhurst, G., Sathiaseelan, A., and R. Secchi, "Updating TCP to Support Rate-Limited Traffic", RFC 7661, DOI 10.17487/RFC7661, October 2015, <https://www.rfc-editor.org/info/rfc7661>.
[RFC7661]Fairhurst，G.，Sathiaseelan，A.，和R.Secchi，“更新TCP以支持速率受限的流量”，RFC 7661，DOI 10.17487/RFC7661，2015年10月<https://www.rfc-editor.org/info/rfc7661>.
[SCReAM-CPP-implementation] Ericsson Research, "SCReAM - Mobile optimised congestion control algorithm", <https://github.com/EricssonResearch/scream>.
[尖叫CPP实施]爱立信研究，“尖叫-移动优化拥塞控制算法”<https://github.com/EricssonResearch/scream>.
[SCReAM-implementation] Ericsson Research, "OpenWebRTC specific GStreamer plugins", <https://github.com/EricssonResearch/ openwebrtc-gst-plugins>.
[尖叫实施]爱立信研究，“OpenWebRTC特定GStreamer插件”<https://github.com/EricssonResearch/ openwebrtc gst插件>。
[SCReAM-implementation-experience] Sarker, Z. and I. Johansson, "Updates on SCReAM: An implementation experience", November 2015, <https://www.ietf.org/proceedings/94/slides/ slides-94-rmcat-8.pdf>.
[尖叫实施经验]Sarker，Z.和I.Johansson，“尖叫更新：实施经验”，2015年11月<https://www.ietf.org/proceedings/94/slides/ 幻灯片-94-rmcat-8.pdf>。
[TFWC] Choi, S. and M. Handley, "Fairer TCP-Friendly Congestion Control Protocol for Multimedia Streaming Applications", DOI 10.1145/1364654.1364717, December 2007, <http://www-dept.cs.ucl.ac.uk/staff/M.Handley/papers/ tfwc-conext.pdf>.
[TFWC]Choi，S.和M.Handley，“用于多媒体流应用的更公平的TCP友好拥塞控制协议”，DOI 10.1145/1364654.13647172007年12月<http://www-dept.cs.ucl.ac.uk/staff/M.Handley/papers/ tfwc conext.pdf>。
[WIRELESS-TESTS] Sarker, Z., Johansson, I., Zhu, X., Fu, J., Tan, W., and M. Ramalho, "Evaluation Test Cases for Interactive Real-Time Media over Wireless Networks", Work in Progress, draft-ietf-rmcat-wireless-tests-04, May 2017.
[WIRELESS-TESTS]Sarker，Z.，Johansson，I.，Zhu，X.，Fu，J.，Tan，W.，和M.Ramalho，“无线网络上交互式实时媒体的评估测试案例”，正在进行中，草稿-ietf-rmcat-WIRELESS-TESTS-042017年5月。
Acknowledgements
致谢
We would like to thank the following people for their comments, questions, and support during the work that led to this memo: Markus Andersson, Bo Burman, Tomas Frankkila, Frederic Gabin, Laurits Hamm, Hans Hannu, Nikolas Hermanns, Stefan Haakansson, Erlendur Karlsson, Daniel Lindstroem, Mats Nordberg, Jonathan Samuelsson, Rickard Sjoeberg, Robert Swain, Magnus Westerlund, and Stefan Aalund. Many additional thanks to RMCAT chairs Karen E. E. Nielsen and Mirja Kuehlewind for patiently reading, suggesting improvements and also for asking all the difficult but necessary questions. Thanks to Stefan Holmer, Xiaoqing Zhu, Safiqul Islam, and David Hayes for the additional review of this document. Thanks to Ralf Globisch for taking time to try out SCReAM in his challenging low-bitrate use cases, Robert Hedman for finding a few additional flaws in the running code, and Gustavo Garcia and 'miseri' for code contributions.
我们要感谢以下人员在撰写本备忘录的过程中提出的意见、问题和支持：马库斯·安德森、博·伯曼、托马斯·弗兰克基拉、弗雷德里克·加宾、劳里斯·哈姆、汉斯·汉努、尼古拉斯·赫曼斯、斯特凡·哈坎松、厄伦杜·卡尔松、丹尼尔·林德斯特伦、马茨·诺德伯格、乔纳森·萨缪尔森、里卡德·舍伯格、，罗伯特·斯温、马格努斯·韦斯特隆德和斯特凡·阿隆德。感谢RMCAT主席Karen E.E.Nielsen和Mirja Kuehlewind耐心阅读，提出改进建议，并提出所有困难但必要的问题。感谢Stefan Holmer、Zhuaoqing、Safiqul Islam和David Hayes对本文件的进一步审查。感谢Ralf Globisch在其具有挑战性的低比特率用例中花时间尝试了尖叫，感谢Robert Hedman在运行的代码中发现了一些额外的缺陷，感谢Gustavo Garcia和“miseri”对代码的贡献。
Authors' Addresses
作者地址
Ingemar Johansson Ericsson AB Laboratoriegraend 11 Luleaa 977 53 Sweden
英格玛·约翰逊·爱立信AB实验室德国11卢利亚977 53瑞典
Phone: +46 730783289
Email: ingemar.s.johansson@ericsson.com
Phone: +46 730783289
Email: ingemar.s.johansson@ericsson.com
Zaheduzzaman Sarker Ericsson AB Laboratoriegraend 11 Luleaa 977 53 Sweden
Zaheduzaman Sarker Ericsson AB实验室位于瑞典卢利亚11号977 53
Phone: +46 761153743
Email: zaheduzzaman.sarker@ericsson.com
Phone: +46 761153743
Email: zaheduzzaman.sarker@ericsson.com