A Google Congestion Control Algorithm for Real-Time Communication

原文地址 https://datatracker.ietf.org/doc/html/draft-ietf-rmcat-gcc

Abstract 摘要

This document describes two methods of congestion control when using real-time communications on the World Wide Web (RTCWEB); one delay- based and one loss-based. It is published as an input document to the RMCAT working group on congestion control for media streams. The mailing list of that working group is [email protected].

本文档描述了通过万维网（RTCWEB）进行实时通信时的两种拥塞控制方法；一个是基于延时的拥塞控制，另一个是基于丢包的拥塞控制。 它作为输入文件发布给RMCAT媒体流拥塞控制工作组。该工作组的邮件地址如下：[email protected].

Requirements Language 需求用语

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119中所述进行解释。

Status of This Memo 文档状态

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 9, 2017.

本互联网草案完全符合BCP 78和BCP 79的规定。 互联网草案是互联网工程任务组（IETF）的工作文件。请注意，其他小组也可以将工作文件作为互联网草稿分发。当前互联网草稿列表位于http://datatracker.ietf.org/drafts/current/。 互联网草案是最长有效期为六个月的文件草案，可能随时被其它文件更新、替换或废弃。使用互联网草案作为参考资料或引用互联网草案都是不合适的。 本互联网草案将于2017年1月9日到期。

Copyright Notice 版权公告

Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. 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.

版权所有（c）2016 IETF Trust 和确定为文档作者的人员。保留所有权利。 本文档受 BCP 78 和 IETF Trust 的与 IETF 文档相关的法律规定(https://trustee.ietf.org/license-info) 约束，在本文档发布之日生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。 从该文档中提取的代码组件必须包括简化的BSD许可证文本，如本规范第4.e节所述Trust法律条款以及在简化的BSD许可证中描述的不作任何保证的条款。

Table of Contents 目录

1. Introduction·····························································3 1.1. Mathematical notation conventions····························3 2. System model·························································4 3. Feedback and extensions··········································4 4. Sending Engine·······················································5 5. Delay-based control··················································5 5.1. Arrival-time model··················································6 5.2. Pre-filtering···························································7 5.3. Arrival-time filter····················································7 5.4. Over-use detector·················································8 5.5. Rate control·······················································10 5.6. Parameters settings·············································12 6. Loss-based control·················································13 7. Interoperability Considerations··································14 8. Implementation Experience······································14 9. Further Work·························································15 10. IANA Considerations·············································15 11. Security Considerations·········································15 12. Acknowledgements···············································15 13. References··························································16 13.1. Normative References·········································16 13.2. Informative References········································16 Appendix A. Change log··············································16 A.1. Version -00 to -01················································16 A.2. Version -01 to -02················································17 A.3. Version -02 to -03················································17 A.4. rtcweb-03 to rmcat-00···········································17 A.5. rmcat -00 to -01···················································17 A.6. rmcat -01 to -02···················································17 A.7. rmcat -02 to -03···················································18 A.8. ietf-rmcat -00 to ietf-rmcat -01·································18 A.9. ietf-rmcat -01 to ietf-rmcat -02·································18 Authors' Addresses·····················································18

1. Introduction 简介

Congestion control is a requirement for all applications sharing the Internet resources [RFC2914]. Congestion control for real-time media is challenging for a number of reasons:

拥塞控制是针对所有共享Internet网络资源的应用程序的一种要求[RFC2914]。 针对实时流媒体的拥塞控制面临一些挑战，原因如下：

o The media is usually encoded in forms that cannot be quickly changed to accommodate varying bandwidth, and bandwidth requirements can often be changed only in discrete, rather large steps o The participants may have certain specific wishes on how to respond - which may not be reducing the bandwidth required by the flow on which congestion is discovered o The encodings are usually sensitive to packet loss, while the real-time requirement precludes the repair of packet loss by retransmission

o 流媒体通常形式的编码无法针对不同带宽做出快速改变，流媒体需要的带宽通常是离散的、甚至是大跨度的变化 o 当网络拥塞发生时，共享网络的其他程序有可能不会减小带宽。 o 编码(输出的数据)通常对数据包丢失很敏感，然而实时性的要求有时会阻止通过重传恢复丢失的数据包。

This memo describes two congestion control algorithms that together are able to provide good performance and reasonable bandwidth sharing with other video flows using the same congestion control and with TCP flows that share the same links. The signaling used consists of experimental RTP header extensions and RTCP messages RFC 3550 [RFC3550] as defined in [abs-send-time], [I-D.alvestrand-rmcat-remb] and [I-D.holmer-rmcat-transport-wide-cc-extensions].

本文描述了两种拥塞控制算法，它们在一起能够提供良好的性能，并能够和使用相同拥塞控制算法的其它视频流甚至包括相同物理链路上的TCP流一起，合理的共享带宽。 本控制算法使用的信令需要实验性RTP报头扩展和RTCP消息，详见RFC 3550[RFC3550]中定义的[abs-send-time]、[I-D.alvestrand-rmcat-remb]和[I-D.holmer-rmcat-transport-wide-cc-extensions]。

1.1. Mathematical notation conventions 数学符号约定

The mathematics of this document have been transcribed from a more formula-friendly format. The following notational conventions are used: X_hat An estimate of the true value of variable X - conventionally marked by a circumflex accent on top of the variable name. X(i) The "i"th value of vector X - conventionally marked by a subscript i. E{X} The expected value of the stochastic variable X

本文的数学内容是从一种更为公式友好的格式转录而来的。 使用以下符号约定： X_hat 变量X的真实值的估计值 - 通常在变量名的顶部用符号标记。 X(i) 数组X的第i个值-通常用下标i标记。 E{X} 随机变量X的期望值

2. System model 系统模型

The following elements are in the system: 本系统中包含下列元素：

o RTP packet - an RTP packet containing media data. o Group of packets - a set of RTP packets transmitted from the sender uniquely identified by the group departure and group arrival time (absolute send time) [abs-send-time]. These could be video packets, audio packets, or a mix of audio and video packets. o Incoming media stream - a stream of frames consisting of RTP packets. o RTP sender - sends the RTP stream over the network to the RTP receiver. It generates the RTP timestamp and the abs-send-time header extension o RTP receiver - receives the RTP stream, marks the time of arrival.

o RTP数据包 - 包含流媒体数据的RTP数据包。 o 数据包组 - (连续)RTP数据包构成的集合，通过数据包组的发送时间和到达时间（绝对发送时间）[abs-send-time]可以唯一标识这个由发送方发送的RTP数据包组。这里的RTP包可以是视频包、音频包或音频和视频包的混合。 o 传入媒体流 - 由RTP数据包组成的帧流。 o RTP发送方 - 通过网络向RTP接收方发送RTP流。RTP发送方负责生成RTP时间戳以及abs-send-time头扩展 o RTP接收器 - 接收RTP流，并记录RTP报文的到达时间。

o RTCP sender at RTP receiver - sends receiver reports, REMB messages and transport-wide RTCP feedback messages. o RTCP receiver at RTP sender - receives receiver reports and REMB messages and transport-wide RTCP feedback messages, reports these to the sender side controller. o RTCP receiver at RTP receiver, receives sender reports from the sender. o Loss-based controller - takes loss rate measurement, round trip time measurement and REMB messages, and computes a target sending bitrate. o Delay-based controller - takes the packet arrival info, either at the RTP receiver, or from the feedback received by the RTP sender, and computes a maximum bitrate which it passes to the loss-based controller.

o RTP接收方同时作为RTCP的发送方 - 负责发送RR报文、REMB报文和传输层RTCP反馈报文(transport wide feedback packet)。 o RTP发送方同时作为RTCP接收方 - 负责接收RR报文、REMB报文、传输层RTCP反馈报文(transport wide feedback packet)，并将接收信息通知到本方控制器。 o RTP接收方同时作为RTCP的接收方，负责接收发送方生成的SR报文。 o 基于丢包的控制器 - 进行丢失率测量、RTT时间测量和(接收)REMB消息，并计算发送端的目标发送比特率。 o 基于延迟的控制器 - 可以部署在RTP接收端记录RTP报文的到达时间或部署在RTP发送端从接收端的反馈报文中获取数据包的到达时间，计算最大比特率并传递给基于丢包的控制器。

Together, loss-based controller and delay-based controller implement the congestion control algorithm.

基于丢包的控制器和基于延迟的控制器共同实现了拥塞控制算法。

3. Feedback and extensions 反馈和扩展

There are two ways to implement the proposed algorithm. One where both the controllers are running at the send-side, and one where the delay-based controller runs on the receive-side and the loss-based controller runs on the send-side.

本算法有两种实现方式。一种是两个控制器都在发送端运行，另一种是基于延迟的控制器在接收端运行，基于丢包的控制器在发送端运行。

The first version can be realized by using a per-packet feedback protocol as described in [I-D.holmer-rmcat-transport-wide-cc-extensions]. Here, the RTP receiver will record the arrival time and the transport-wide sequence number of each received packet, which will be sent back to the sender periodically using the transport-wide feedback message. The RECOMMENDED feedback interval is once per received video frame or at least once every 30 ms if audio-only or multi-stream. If the feedback overhead needs to be limited this interval can be increased to 100 ms. The sender will map the received {sequence number, arrival time} pairs to the send-time of each packet covered by the feedback report, and feed those timestamps to the delay-based controller. It will also compute a loss ratio based on the sequence numbers in the feedback message.

第一种方法可以通过使用[I-D.holmer-rmcat-transport-wide-cc-extensions]中描述的每包反馈协议来实现。这里，RTP接收端将记录每个接收到的数据包的到达时间和传输层序列号(transport-wide sequence)，该序列号将使用传输层反馈消息(transport-wide feedback)周期性地发送回发送方。建议的反馈间隔为每接收一个视频帧一次，或者如果仅音频或多流，则至少每30ms一次。如果需要限制反馈开销，该间隔可增加至100ms。 发送方从反馈报文中获取RTP数据包的 {(传输层)序列号，到达时间} 信息，并与每个RTP数据包的发送时间建立映射(Map)，再将这些时间戳提供给基于延迟的控制器。它还将根据反馈消息中的(传输层)序列号计算丢包率。

The second version can be realized by having a delay-based controller at the receive-side, monitoring and processing the arrival time and size of incoming packets. The sender SHOULD use the abs-send-time RTP header extension [abs-send-time] to enable the receiver to compute the inter-group delay variation. The output from the delay- based controller will be a bitrate, which will be sent back to the sender using the REMB feedback message [I-D.alvestrand-rmcat-remb]. The packet loss ratio is sent back via RTCP receiver reports. At the sender the bitrate in the REMB message and the fraction of packets lost are fed into the loss-based controller, which outputs a final target bitrate. It is RECOMMENDED to send the REMB message as soon as congestion is detected, and otherwise at least once every second.

第二种方法可以通过在接收端部署基于延迟的控制器来实现，该控制器监视和处理传入数据包的到达时间和大小。发送方应该使用abs-send-time RTP报头扩展[abs-send-time]，使接收方能够计算数据包组之间的延迟变化。基于延迟的控制器的输出将是比特率，该比特率将使用REMB消息[I-D.alvestrand-rmcat-REMB]反馈回发送方。丢包率通过RTCP-RR报文反馈。在发送方，REMB消息中的比特率和(RR报文中的)丢包率信息将被送入基于丢失的控制器，该控制器输出最终的目标比特率。建议在检测到拥塞时立即发送REMB消息，否则至少每秒发送一次。

4. Sending Engine 发送引擎

Pacing is used to actuate the target bitrate computed by the controllers. When media encoder produces data, this is fed into a Pacer queue. The Pacer sends a group of packets to the network every burst_time interval. RECOMMENDED value for burst_time is 5 ms. The size of a group of packets is computed as the product between the target bitrate and the burst_time.

控制器计算的目标比特率通过Pacing(调速器)生效 当媒体编码器产生数据时，数据被送入Pacer队列。Pacer在每个突发时间间隔向网络发送一组数据包。突发时间的建议值为5ms。通过计算目标比特率和突发时间之间的乘积，用来确定一组数据包的大小。

5. Delay-based control 基于延迟的(码率/拥塞)控制

The delay-based control algorithm can be further decomposed into four parts: a pre-filtering, an arrival-time filter, an over-use detector, and a rate controller.

基于延迟的控制算法可以进一步分解为四个部分：预滤波、到达时间滤波器、过载检测器和速率控制器。

5.1. Arrival-time model 到达时间模型

This section describes an adaptive filter that continuously updates estimates of network parameters based on the timing of the received groups of packets. We define the inter-arrival time, t(i) - t(i-1), as the difference in arrival time of two groups of packets. Correspondingly, the inter- departure time, T(i) - T(i-1), is defined as the difference in departure-time of two groups of packets. Finally, the inter-group delay variation, d(i), is defined as the difference between the inter-arrival time and the inter-departure time. Or interpreted differently, as the difference between the delay of group i and group i-1. d(i) = t(i) - t(i-1) - (T(i) - T(i-1))

本节描述一种自适应滤波器，该自适应滤波器基于接收数据包的时间，连续更新网络参数的估计值。 我们将到达时间t(i) - t(i-1)定义为两个数据包组的到达时间间隔。相应地，发送时间间隔T(i) - T(i-1)被定义为两个数据包组的发送时间差。最后，包组间延迟变化d(i)被定义为到达时间间隔与发送时间间隔的差值。或以换一种说法，如第i组延迟 和 第i-1组延迟 之间的差值。

$d(i)=t(i)-t(i-1)-(T(i)-T(i-1))$

An inter-departure time is computed between consecutive groups as T(i) - T(i-1), where T(i) is the departure timestamp of the last packet in the current packet group being processed. Any packets received out of order are ignored by the arrival-time model. Each group is assigned a receive time t(i), which corresponds to the time at which the last packet of the group was received. A group is delayed relative to its predecessor if t(i) - t(i-1) > T(i) - T(i-1), i.e., if the inter-arrival time is larger than the inter-departure time. We can model the inter-group delay variation as: d(i) = w(i) Here, w(i) is a sample from a stochastic process W, which is a function of the link capacity, the current cross traffic, and the current sent bitrate. We model W as a white Gaussian process. If we are over-using the channel we expect the mean of w(i) to increase, and if a queue on the network path is being emptied, the mean of w(i) will decrease; otherwise the mean of w(i) will be zero.

使用T(i) -T(i-1)计算连续包组之间的发送时间间隔，其中T(i)是正在处理的当前包组中的最后一个报文的发送时间戳。另外，到达时间模型会忽略任何接收到的乱序报文。 每个包组的接收时间都对应一个t(i)，该时间对应于包组内最后一个报文被接收的时间。如果t(i) - t(i-1) > T(i)-T(i-1)，即接收时间间隔大于发送时间间隔，表示当前组包相对于前一个组的(传输)延迟变得更大了。 我们可以将包组之间的延迟的变化建模为： d(i) = w(i) 这里，w(i)是来自随机过程W的样本，它是链路容量、当前双向流量和当前发送比特率的函数。我们将W建模为一个白高斯过程。如果我们的信道被过度使用(过载)，我们期望w(i)的平均值增加，如果网络路径上的队列被清空，w(i)的平均值将减少；否则，w(i)的平均值将为零。

Breaking out the mean, m(i), from w(i) to make the process zero mean, we get Equation 1 : d(i) = m(i) + v(i) The noise term v(i) represents network jitter and other delay effects not captured by the model.

从w(i)中取平均值m(i)，使过程的平均值为零，我们得到 方程式1: d(i) = m(i) + v(i) 噪声项v(i)表示网络抖动和模型未捕获的其它影响延迟的因素。

5.2. Pre-filtering 预滤波

The pre-filtering aims at handling delay transients caused by channel outages. During an outage, packets being queued in network buffers, for reasons unrelated to congestion, are delivered in a burst when the outage ends. The pre-filtering merges together groups of packets that arrive in a burst. Packets are merged in the same group if one of these two conditions holds: o A sequence of packets which are sent within a burst_time interval constitute a group. o A Packet which has an inter-arrival time less than burst_time and an inter-group delay variation d(i) less than 0 is considered being part of the current group of packets.

预滤波旨在处理由通道中断引起的延迟瞬变。在中断期间，由于与拥塞无关的原因而在网络缓冲区中排队的数据包在中断结束时以突发方式发送。 预过滤将突发到达的数据包组合并在一起。如果以下两种情况之一成立，则数据包合并到同一组中： o 在突发时间间隔内发送的数据包序列构成一个组。 o 到达时间间隔小于突发时间且包组间延迟变化d(i)小于0的报文被认为是当前数据包组的一部分。

5.3. Arrival-time filter 到达时间滤波器

The parameter d(i) is readily available for each group of packets, i > 1. We want to estimate m(i) and use this estimate to detect whether or not the bottleneck link is over-used. The parameter can be estimated by any adaptive filter - we are using the Kalman filter. Let m(i) be the estimate at time i We model the state evolution from time i to time i+1 as m(i+1) = m(i) + u(i) where u(i) is the state noise that we model as a stationary process with Gaussian statistic with zero mean and variance

i>1时，参数d(i)可方便地用于每个包组。我们想估计m(i)，并使用这个估计值来检测存在带宽瓶颈的链路上是否出现过载。可以使用任何自适应滤波器来估计这个参数 - 这里我们使用的是卡尔曼滤波器。 设m(i)为i时刻的估计值 我们将从时间i到时间i+1的状态演化建模为 m(i+1) = m(i) + u(i) 其中，u(i)是我们建模为平稳过程的状态噪声，具有零均值和零方差的高斯统计量

q(i) = E{u(i)^2} q(i) is RECOMMENDED equal to 10^-3 Given equation 1 we get d(i) = m(i) + v(i) where v(i) is zero mean white Gaussian measurement noise with variance var_v = E{v(i)^2} The Kalman filter recursively updates our estimate m_hat(i) as z(i) = d(i) - m_hat(i-1) m_hat(i) = m_hat(i-1) + z(i) * k(i)       e(i-1) + q(i) k(i) = ----------------------------------------             var_v_hat(i) + (e(i-1) + q(i)) e(i) = (1 - k(i)) * (e(i-1) + q(i)) The variance var_v(i) = E{v(i)^2} is estimated using an exponential averaging filter, modified for variable sampling rate var_v_hat(i) = max(alpha * var_v_hat(i-1) + (1-alpha) * z(i)^2, 1) alpha = (1-chi)^(30/(1000 * f_max))

q(i) = E{u(i)^2} 建议q(i) = 10^-3 代入方程1中，我们可以得到 d(i) = m(i) + v(i) 其中，v(i)是零均值高斯白噪声测量，方差 var_v = E{ v(i)^2 } 卡尔曼滤波器递归更新我们的估计m_hat(i)为 z(i) = d(i) - m_hat(i-1) m_hat(i) = m_hat(i-1) + z(i) * k(i)       e(i-1) + q(i) k(i) = ----------------------------------------             var_v_hat(i) + (e(i-1) + q(i)) e(i) = (1 - k(i)) * (e(i-1) + q(i)) 方差var_v(i) = E{ v(i)^2 }使用指数平均滤波器估计，该滤波器针对可变采样率进行了修改 var_v_hat(i) = max(alpha * var_v_hat(i-1) + (1-alpha) * z(i)^2, 1) alpha = (1-chi)^(30/(1000 * f_max))

where f_max = max {1/(T(j) - T(j-1))} for j in i-K+1,...,i is the highest rate at which the last K packet groups have been received and chi is a filter coefficient typically chosen as a number in the interval [0.1, 0.001]. Since our assumption that v(i) should be zero mean WGN is less accurate in some cases, we have introduced an additional outlier filter around the updates of var_v_hat. If z(i) > 3*sqrt(var_v_hat) the filter is updated with 3*sqrt(var_v_hat) rather than z(i). For instance v(i) will not be white in situations where packets are sent at a higher rate than the channel capacity, in which case they will be queued behind each other.

其中f_max=max{ 1/(T(j) -T(j-1)) }，j 为从 i-K+1 到 i，我们取最近收到的K个组中的最大值。chi是一个滤波系数，可以在0.001到0.1之间选择。由于我们假设v(i)应为零，因此在某些情况下，WGN的平均值不太准确，因此我们在var_v_hat的更新中引入了额外的异常值过滤器。如果z(i) > 3*sqrt(var_v_hat)，则使用3*sqrt(var_v_hat)而不是z(i)更新过滤器。例如，在以高于信道容量的速率发送数据包的情况下，在这种情况下，这些包将会排队，v(i)将不会是白色的(即测量值要大于预测值)

5.4. Over-use detector 过载检测器

The inter-group delay variation estimate m(i), obtained as the output of the arrival-time filter, is compared with a threshold del_var_th(i). An estimate above the threshold is considered as an indication of over-use. Such an indication is not enough for the detector to signal over-use to the rate control subsystem. A definitive over-use will be signaled only if over-use has been detected for at least overuse_time_th milliseconds. However, if m(i) < m(i-1), over-use will not be signaled even if all the above conditions are met. Similarly, the opposite state, under-use, is detected when m(i) < -del_var_th(i). If neither over-use nor under- use is detected, the detector will be in the normal state. The threshold del_var_th has a remarkable impact on the overall dynamics and performance of the algorithm. In particular, it has been shown that using a static threshold del_var_th, a flow controlled by the proposed algorithm can be starved by a concurrent TCP flow [Pv13]. This starvation can be avoided by increasing the threshold del_var_th to a sufficiently large value.

包组间延迟变化的估计值m(i)作为到达时间滤波器的输出，与阈值del_var_th(i)进行比较。超过此阈值的估计值被视为过载指示。但仅有这种指示不足以使检测器向速率控制子系统发出过载(over-use)信号。只有在检测到过载时间至少超过overuse_time_th毫秒的情况下，才会发出确定的过载信号。但是，如果m(i) < m(i-1)，即使满足上述所有条件，也不会触发过载信号。 类似地，当m(i) < -del_var_th(i)时，与过载状态相反的轻载状态将被检测到。如果未检测到过载状态和轻载状态，则探测器将处于正常状态。 阈值del_var_th对算法的整体动态性和性能有显著影响。特别是，已经证明，如果del_var_th使用固定的阈值，则由该算法控制的流可以被并发TCP流(抢占而导致被)饿死[Pv13]。通过将阈值del_var_th增加到足够大的值，可以避免这种饿死。

The reason is that, by using a larger value of del_var_th, a larger queuing delay can be tolerated, whereas with a small del_var_th, the over-use detector quickly reacts to a small increase in the offset estimate m(i) by generating an over-use signal that reduces the delay-based estimate of the available bandwidth A_hat (see Section 4.4). Thus, it is necessary to dynamically tune the threshold del_var_th to get good performance in the most common scenarios, such as when competing with loss-based flows. For this reason, we propose to vary the threshold del_var_th(i) according to the following dynamic equation: del_var_th(i) = del_var_th(i-1) + (t(i)-t(i-1)) * K(i) * (|m(i)|-del_var_th(i-1))

具体原因是，使用更大的del_var_th值，可以容忍更大的队列延迟，而较小的del_var_th可以让过载检测器对偏移估计m(i)的小幅增加作出快速反应，生成过载信号减少基于延迟的可用带宽估计值A_hat (参见第4.4节)。因此，有必要动态调整阈值del_var_th，以便在最常见的场景中获得良好的性能，例如在与基于丢包的流发生竞争时。 因此，我们建议根据下面的动态方程改变阈值del_var_th(i)： del_var_th(i) = del_var_th(i-1) + [t(i)-t(i-1)] * K(i) * [|m(i)|-del_var_th(i-1)]

with K(i)=K_d if |m(i)| < del_var_th(i-1) or K(i)=K_u otherwise. The rationale is to increase del_var_th(i) when m(i) is outside of the range [-del_var_th(i-1),del_var_th(i-1)], whereas, when the offset estimate m(i) falls back into the range, del_var_th is decreased. In this way when m(i) increases, for instance due to a TCP flow entering the same bottleneck, del_var_th(i) increases and avoids the uncontrolled generation of over-use signals which may lead to starvation of the flow controlled by the proposed algorithm [Pv13]. Moreover, del_var_th(i) SHOULD NOT be updated if this condition holds: |m(i)| - del_var_th(i) > 15 It is also RECOMMENDED to clamp del_var_th(i) to the range [6, 600], since a too small del_var_th(i) can cause the detector to become overly sensitive.

如果 |m(i)| < del_var_th(i-1) 时，则 K(i)=K_d，否则 K(i)=K_u。这里的基本原理是，当 |m(i)| 超出 [-del_var_th(i-1)，del_var_th(i-1)] 的范围时，我们应该增加del_var_th(i)，而当偏移估计m(i)回落到范围内时，应该减小del_var_th。 例如，由于TCP流进入同一个存在(带宽)瓶颈的链路时，m(i)会增加，此时增加del_var_th(i)可避免因为不受控制的生成过载信号而导致本算法控制的流被饿死[Pv13]。 此外，如果下面的条件成立，则不应更新del_var_th(i)： |m(i)| - del_var_th(i) > 15 所以，建议将del_var_th(i)限制在[6, 600]范围内，因为太小的del_var_th(i)会导致检测器变得过于敏感。

On the other hand, when m(i) falls back into the range [-del_var_th(i-1),del_var_th(i-1)] the threshold del_var_th(i) is decreased so that a lower queuing delay can be achieved. It is RECOMMENDED to choose K_u > K_d so that the rate at which del_var_th is increased is higher than the rate at which it is decreased. With this setting it is possible to increase the threshold in the case of a concurrent TCP flow and prevent starvation as well as enforcing intra-protocol fairness. RECOMMENDED values for del_var_th(0), overuse_time_th, K_u and K_d are respectively 12.5 ms, 10 ms, 0.01 and 0.00018.

另外，当m(i)回落到 [-del_var_th(i-1)，del_var_th(i-1)] 范围内时，阈值del_var_th(i)应该被减小，以便可以实现较低的排队延迟(使算法对延迟变化更敏感)。 建议选择K_u > K_d，以使del_var_th增长的速度高于其下降的速度。通过此设置，可以在并发TCP流的情况下提高阈值，防止饿死，并强制协议内公平性。del_var_th(0)、过载时间阈值、K_u 和K_d的建议值分别为12.5 ms、10 ms、0.01和0.00018。

5.5. Rate control 速率控制

The rate control is split in two parts, one controlling the bandwidth estimate based on delay, and one controlling the bandwidth estimate based on loss. Both are designed to increase the estimate of the available bandwidth A_hat as long as there is no detected congestion and to ensure that we will eventually match the available bandwidth of the channel and detect an over-use. As soon as over-use has been detected, the available bandwidth estimated by the delay-based controller is decreased. In this way we get a recursive and adaptive estimate of the available bandwidth. In this document we make the assumption that the rate control subsystem is executed periodically and that this period is constant. The rate control subsystem has 3 states: Increase, Decrease and Hold. "Increase" is the state when no congestion is detected; "Decrease" is the state where congestion is detected, and "Hold" is a state that waits until built-up queues have drained before going to "increase" state.

速率控制分为两部分，一部分是通过基于延迟的带宽估计进行控制，另一部分是通过基于丢包带宽的估计进行控制。设计这两种方法的目的都是为了在没有检测到拥塞的情况下，增加可用带宽的估计值(A_hat)，最终确保我们既能匹配信道的可用带宽也能对信道的过载状态进行检测。 一旦检测到过载，基于延迟的控制器输出的可用带宽估计值就会减少。通过这种方式，可以得到一个递归且自适应的可用带宽估计值。 在本文中，我们假设速率控制子系统是周期性执行的，并且这个周期是恒定的。 速率控制子系统有3种状态：增加、减少和保持。“增加”是未检测到拥塞时的速率控制状态；“减少”是检测到拥塞时的速率控制状态，“保持”状态是为了在进入“增加”状态前耗尽已建立的(缓存)队列。

The state transitions (with blank fields meaning "remain in state") are: 【信号触发】状态迁移规则表(空白表示“停留在【之前的】状态”)：

Signal \ State	Hold	Increase	Decrease
Over-use	Decrease	Decrease
Normal	Increase		Hold
Under-use		Hold	Hold

信号 \ 状态	保持	增加	减少
过载	减少	减少
正常	增加		保持
轻载		保持	保持

The subsystem starts in the increase state, where it will stay until over-use or under-use has been detected by the detector subsystem. On every update the delay-based estimate of the available bandwidth is increased, either multiplicatively or additively, depending on its current state. The system does a multiplicative increase if the current bandwidth estimate appears to be far from convergence, while it does an additive increase if it appears to be closer to convergence. We assume that we are close to convergence if the currently incoming bitrate, R_hat(i), is close to an average of the incoming bitrates at the time when we previously have been in the Decrease state. "Close" is defined as three standard deviations around this average. It is RECOMMENDED to measure this average and standard deviation with an exponential moving average with the smoothing factor 0.95, as it is expected that this average covers multiple occasions at which we are in the Decrease state. Whenever valid estimates of these statistics are not available, we assume that we have not yet come close to convergence and therefore remain in the multiplicative increase state.

子系统启动时的初始状态是增加状态，直到探测器子系统检测到过载或轻载为止。在每次更新时，基于延迟的可用带宽估计会根据当前状态采用乘法或加法的方式增加带宽估计值。 如果当前带宽估计远未收敛，则系统会使用乘法增加估计带宽，而如果更接近收敛，则系统会使用加法增加估计带宽。如果当前传入的比特率R_hat(i)接近之前处于下降状态时传入的比特率的平均值，则可以认为是接近收敛。 所谓“接近”，在这里被定义为距离该平均值在三个标准差之内。 我们建议使用0.95作为指数平滑系数来测量输入的 比特率 的平均值和标准差，因为我们认为它可以覆盖在 减少 状态下的多个场景。 当这些统计数据的有效估计不可用时，我们认为尚未接近收敛，因此仍处于乘法增加状态。

If R_hat(i) increases above three standard deviations of the average max bitrate, we assume that the current congestion level has changed, at which point we reset the average max bitrate and go back to the multiplicative increase state. R_hat(i) is the incoming bitrate measured by the delay-based controller over a T seconds window: R_hat(i) = 1/T * sum(L(j)) for j from 1 to N(i) N(i) is the number of packets received the past T seconds and L(j) is the payload size of packet j. A window between 0.5 and 1 second is RECOMMENDED.

如果R_hat(i)增加到平均最大比特率的三个标准偏差以上，我们认为当前拥塞等级已经改变，此时我们重置平均最大比特率并回到乘法增加状态。 R_hat(i)是基于延迟的控制器在T秒窗口内测量的输入比特率： R_hat(i) = 1/T * sum(L(j)) for j from 1 to N(i) N(i)是过去T秒内接收的数据包数量，L(j)是数据包j的有效载荷大小。建议使用0.5到1秒之间的窗口。

During multiplicative increase, the estimate is increased by at most 8% per second. eta = 1.08^min(time_since_last_update_ms / 1000, 1.0) A_hat(i) = eta * A_hat(i-1) During the additive increase the estimate is increased with at most half a packet per response_time interval. The response_time interval is estimated as the round-trip time plus 100 ms as an estimate of over-use estimator and detector reaction time.

在乘法增加期间，估计值每秒最多被增加8%。 eta = 1.08^min(time_since_last_update_ms / 1000, 1.0) A_hat(i) = eta * A_hat(i-1) 在加法增加期间，估计值增加，每个响应时间间隔最多增加半个数据包。响应时间间隔估计为往返时间加上100ms，作为过载估计器和检测器反应时间的估计。

response_time_ms = 100 + rtt_ms alpha = 0.5 * min(time_since_last_update_ms / response_time_ms, 1.0) A_hat(i) = A_hat(i-1) + max(1000, alpha * expected_packet_size_bits) expected_packet_size_bits is used to get a slightly slower slope for the additive increase at lower bitrates. It can for instance be computed from the current bitrate by assuming a frame rate of 30 frames per second: bits_per_frame = A_hat(i-1) / 30 packets_per_frame = ceil(bits_per_frame / (1200 * 8)) avg_packet_size_bits = bits_per_frame / packets_per_frame

response_time_ms = 100 + rtt_ms alpha = 0.5 * min(time_since_last_update_ms / response_time_ms, 1.0) A_hat(i) = A_hat(i-1) + max(1000, alpha * expected_packet_size_bits) expected_packet_size_bits 被用于在较低比特率下为加法增加获得稍慢的斜率。例如，可以通过假设每秒30帧的帧速率计算当前比特率： bits_per_frame = A_hat(i-1) / 30 packets_per_frame = ceil(bits_per_frame / (1200 * 8)) avg_packet_size_bits = bits_per_frame / packets_per_frame

Since the system depends on over-using the channel to verify the current available bandwidth estimate, we must make sure that our estimate does not diverge from the rate at which the sender is actually sending. Thus, if the sender is unable to produce a bit stream with the bitrate the congestion controller is asking for, the available bandwidth estimate should stay within a given bound. Therefore we introduce a threshold A_hat(i) < 1.5 * R_hat(i)

由于本系统依赖于信道过载来验证当前可用带宽估计，因此我们必须确保我们的估计值不会远离发送端实际的发送码率。因此，如果发送端无法产生具有拥塞控制器要求的比特率的数据流，为了将可用带宽估计值限制到一个范围。我们引入了一个阈值 A_hat(i) < 1.5 * R_hat(i)

When an over-use is detected the system transitions to the decrease state, where the delay-based available bandwidth estimate is decreased to a factor times the currently incoming bitrate. A_hat(i) = beta * R_hat(i) beta is typically chosen to be in the interval [0.8, 0.95], 0.85 is the RECOMMENDED value.

当检测到过载时，系统迁移到减少状态，在此状态下，基于延迟的可用带宽估计值应该减少到当前输入比特率乘以一个系数(beta)。 A_hat(i) = beta * R_hat(i) beta通常选择在区间 [0.8, 0.95] 内，建议值为0.85。

When the detector signals under-use to the rate control subsystem, we know that queues in the network path are being emptied, indicating that our available bandwidth estimate A_hat is lower than the actual available bandwidth. Upon that signal the rate control subsystem will enter the hold state, where the receive-side available bandwidth estimate will be held constant while waiting for the queues to stabilize at a lower level - a way of keeping the delay as low as possible. This decrease of delay is wanted, and expected, immediately after the estimate has been reduced due to over-use, but can also happen if the cross traffic over some links is reduced. It is RECOMMENDED that the routine to update A_hat(i) is run at least once every response_time interval.

在估计值由于过载而减少之后，当检测器向速率控制子系统发送轻载信号时，我们知道网络路径上的队列正在清空，这表明我们的带宽估计值低于实际可用带宽。收到该信号后，速率控制子系统将进入保持状态，在该状态下，接收端可用带宽估计值将保持不变，同时等待队列稳定在较低水平，这是一种尽可能降低延迟的方法。这种延迟的减少是需要的，也是被期望的，但是如果某些链路上的交叉流量减少，也可能发生这种情况。 建议每个响应时间间隔(response_time)至少更新一次A_hat(i)。

5.6. Parameters settings 参数设置

Parameter	Description	RECOMMENDED
burst_time	Time limit in milliseconds between packet bursts which identifies a group	5 ms
q	State noise covariance matrix	q = 10^-3
e(0)	Initial value of the system error covariance	e(0) = 0.1
chi	Coefficient used for the measured noise variance	[0.1, 0.001]
del_var_th(0)	Initial value for the adaptive threshold	12.5 ms
overuse_time_th	Time required to trigger an overuse signal	10 ms
K_u	Coefficient for the adaptive threshold	0.01
K_d	Coefficient for the adaptive threshold	0.00018
T	Time window for measuring the received bitrate	[0.5, 1] s
beta	Decrease rate factor	0.85

Table 1: RECOMMENDED values for delay based controller

参数	描述	推荐值
突发时间	标识组的数据包突发之间的时间限制(以毫秒为单位)	5 ms
q	状态噪声协方差矩阵	q = 10^-3
e(0)	系统误差协方差的初始值	e(0) = 0.1
chi	用于测量噪声方差的系数	[0.1, 0.001]
del_var_th(0)	自适应阈值的初始值	12.5 ms
overuse_time_th	触发过载信号所需的时间	10 ms
K_u	自适应阈值系数	0.01
K_d	自适应阈值系数	0.00018
T	用于测量接收比特率的时间窗口	[0.5, 1] s
beta	递减率系数	0.85

表1: 基于延时的控制器参数的推荐者

6. Loss-based control 基于丢包的(码率)控制

A second part of the congestion controller bases its decisions on the round-trip time, packet loss and available bandwidth estimates A_hat received from the delay-based controller. The available bandwidth estimates computed by the loss-based controller are denoted with As_hat. The available bandwidth estimates A_hat produced by the delay-based controller are only reliable when the size of the queues along the path sufficiently large. If the queues are very short, over-use will only be visible through packet losses, which are not used by the delay-based controller. The loss-based controller SHOULD run every time feedback from the receiver is received.

拥塞控制器的第二部分基于从基于延迟的控制器接收到的往返时间、分组丢失和可用带宽估计来做出决策。由基于损耗的控制器计算的可用带宽估计值用As_hat表示。 只有当路径上的队列足够大时，基于延迟的控制器产生的可用带宽估计才是可靠的。如果队列非常短，则过度使用将仅通过数据包丢失可见，而基于延迟的控制器不使用数据包丢失。 每次接收到来自接收器的反馈时，应运行基于损耗的控制器。

o If 2-10% of the packets have been lost since the previous report from the receiver, the sender available bandwidth estimate As_hat(i) will be kept unchanged. o If more than 10% of the packets have been lost a new estimate is calculated as As_hat(i) = As_hat(i-1)(1-0.5p), where p is the loss ratio. o As long as less than 2% of the packets have been lost As_hat(i) will be increased as As_hat(i) = 1.05(As_hat(i-1))

o 如果自上一次来自接收方的报告以来有2-10%的数据包丢失，则发送方可用带宽估计值As_hat(i)将保持不变。 o 如果超过10%的数据包丢失，则新的估计值计算为As_hat(i) =As_hat(i-1)(1-0.5p)，其中p是丢失率。 o 只要丢失的数据包不到2%，那么将增加As_hat(i) ＝1.05(As_hat(i-1))

The loss-based estimate As_hat is compared with the delay-based estimate A_hat. The actual sending rate is set as the minimum between As_hat and A_hat. We motivate the packet loss thresholds by noting that if the transmission channel has a small amount of packet loss due to over- use, that amount will soon increase if the sender does not adjust his bitrate. Therefore we will soon enough reach above the 10% threshold and adjust As_hat(i). However, if the packet loss ratio does not increase, the losses are probably not related to self-inflicted congestion and therefore we should not react on them.

将基于丢包的估计值As_hat与基于延迟的估计值A_hat进行比较。实际发送速率设置为As_hat和A_hat之间的最小值。 我们设置(10%的)丢包阈值是因为，当传输信道由于过载而有少量的数据包丢失，如果发送方不调整其比特率，该传输信道的数据包丢失量将快速增加，从而很快达到和超过10%这个阈值，并触发As_hat(i)调整。然而，如果数据包的丢包率没有(继续)增加，那么丢包可能与自身造成的拥塞无关，因此我们也不应该对它们作出反应。（所以10%阈值可以防止我们因为微小的风吹草动而做出错误反应）

7. Interoperability Considerations 互操作性注意事项

In case a sender implementing these algorithms talks to a receiver which do not implement any of the proposed RTCP messages and RTP header extensions, it is suggested that the sender monitors RTCP receiver reports and uses the fraction of lost packets and the round- trip time as input to the loss-based controller. The delay-based controller should be left disabled.

如果发送方支持本文描述的控制算法，而接收方未实现任何本文描述的两种控制协议所需要的RTCP消息和RTP报头扩展，则建议发送方监控RTCP-RR报文，并使用丢包率和RTT往返时间作为基于丢包的控制器(loss-based controller)的输入。基于延迟的控制器(delay-based controller)应保持禁用状态。

8. Implementation Experience 实施经验

This algorithm has been implemented in the open-source WebRTC project, has been in use in Chrome since M23, and is being used by Google Hangouts. Deployment of the algorithm have revealed problems related to, e.g, congested or otherwise problematic WiFi networks, which have led to algorithm improvements. The algorithm has also been tested in a multi-party conference scenario with a conference server which terminates the congestion control between endpoints. This ensures that no assumptions are being made by the congestion control about maximum send and receive bitrates, etc., which typically is out of control for a conference server.

该算法已在开源WebRTC项目中实现，自M23开始在Chrome中使用，并被Google Hangouts使用。 该算法部署在拥塞或有其他问题的WiFi网络中，出现了相关的问题，而这些问题也导致了算法的改进。这些算法也在多方会议场景中进行了测试，会议服务器结束了端点之间的拥塞控制。这确保了拥塞控制不会对会议服务器无法控制的最大发送比特率和最大接收比特率等做出任何假设。

9. Further Work 进一步工作

This draft is offered as input to the congestion control discussion. Work that can be done on this basis includes: o Considerations of integrated loss control: How loss and delay control can be better integrated, and the loss control improved. o Considerations of locus of control: evaluate the performance of having all congestion control logic at the sender, compared to splitting logic between sender and receiver. o Considerations of utilizing ECN as a signal for congestion estimation and link over-use detection.

提交本草案作为拥塞控制讨论的输入。 在此基础上可以完成的工作包括： o 综合损失控制的考虑因素：如何更好地整合损失和延迟控制，并改进损失控制。 o 对控制点的考虑：对于拥塞控制逻辑集中部署在发送方和塞控制逻辑分置部署在发送方和接收方，需要比较并评估这两种部署方式的性能差异。 o 考虑将ECN用作拥塞估计和链路过载的检测信号。

10. IANA Considerations IANA 考虑

This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC.

本文件对于IANA无任何要求。 注意RFC编辑器：本文在RFC发布时本节可能会被删除。

11. Security Considerations 安全考虑

An attacker with the ability to insert or remove messages on the connection would have the ability to disrupt rate control. This could make the algorithm to produce either a sending rate under- utilizing the bottleneck link capacity, or a too high sending rate causing network congestion. In this case, the control information is carried inside RTP, and can be protected against modification or message insertion using SRTP, just as for the media. Given that timestamps are carried in the RTP header, which is not encrypted, this is not protected against disclosure, but it seems hard to mount an attack based on timing information only.

如果攻击者能够在连接上插入或删除消息，就能够中断(本文描述的)速率控制(算法)。这可能导致算法要么是发送速率低于瓶颈链路的实际容量，要么是过高的发送速率导致网络拥塞。 在这种情况下，RTP报文中的控制信息，可以像(音视频)媒体数据一样，通过SRTP(加密)来防止修改或消息插入。由于RTP报头中带有时间戳，而RTP报头未加密，因此不受泄露的保护，但似乎很难仅基于时间信息发起攻击。

12. Acknowledgements 致谢

Thanks to Randell Jesup, Magnus Westerlund, Varun Singh, Tim Panton, Soo-Hyun Choo, Jim Gettys, Ingemar Johansson, Michael Welzl and others for providing valuable feedback on earlier versions of this draft.

感谢Randell Jesup、Magnus Westerlund、Varun Singh、Tim Panton、Soo Hyun Choo、Jim Gettys、Ingemar Johansson、Michael Welzl和其他人为本草案的早期版本提供了宝贵的意见。

13. References 参考资料

13.1. Normative References 规范性引用文件

[I-D.alvestrand-rmcat-remb] Alvestrand, H., "RTCP message for Receiver Estimated Maximum Bitrate", draft-alvestrand-rmcat-remb-03 (work in progress), October 2013. [I-D.holmer-rmcat-transport-wide-cc-extensions] Holmer, S., Flodman, M., and E. Sprang, "RTP Extensions for Transport-wide Congestion Control", draft-holmer- rmcat-transport-wide-cc-extensions-00 (work in progress), March 2015. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [abs-send-time] "RTP Header Extension for Absolute Sender Time",

13.2. Informative References 资料性引用

[Pv13] De Cicco, L., Carlucci, G., and S. Mascolo, "Understanding the Dynamic Behaviour of the Google Congestion Control", Packet Video Workshop , December 2013. [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.

Appendix A. Change log 附录A. 修订记录

A.1. Version -00 to -01

o Added change log o Added appendix outlining new extensions o Added a section on when to send feedback to the end of section 3.3 "Rate control", and defined min/max FB intervals. o Added size of over-bandwidth estimate usage to "further work" section. o Added startup considerations to "further work" section. o Added sender-delay considerations to "further work" section. o Filled in acknowledgments section from mailing list discussion.

o 添加了更改日志 o 增加了概述新扩展的附录 o 在第3.3节“速率控制”末尾增加了一节，说明何时发送反馈，并定义了最小/最大FB间隔。 o 在“进一步工作”部分增加了带宽估计使用量的大小。 o 在“进一步工作”部分增加了启动注意事项。 o 在“进一步工作”部分增加了发送方延迟注意事项。 o 填写邮件列表讨论中的确认部分。

A.2. Version -01 to -02

o Defined the term "frame", incorporating the transmission time offset into its definition, and removed references to "video frame". o Referred to "m(i)" from the text to make the derivation clearer. o Made it clearer that we modify our estimates of available bandwidth, and not the true available bandwidth. o Removed the appendixes outlining new extensions, added pointers to REMB draft and RFC 5450.

o 定义术语“帧”，将传输时间偏移纳入其定义，并删除对“视频帧”的引用。 o 从案文中提到“m（i）”，以使推导更清楚。 o 更清楚地表明，我们修改了对可用带宽的估计，而不是真正的可用带宽。 o 删除概述新扩展的附录，添加指向REMB草案和RFC 5450的指针。

A.3. Version -02 to -03

o Added a section on how to process multiple streams in a single estimator using RTP timestamps to NTP time conversion. o Stated in introduction that the draft is aimed at the RMCAT working group.

o 增加了一节，介绍如何使用RTP时间戳到NTP时间转换在单个估计器中处理多个流。 o 在导言中指出，草案的目标是RMCAT工作组。

A.4. rtcweb-03 to rmcat-00

Renamed draft to link the draft name to the RMCAT WG.

重命名草稿以将草稿名称链接到RMCAT WG。

A.5. rmcat -00 to -01

Spellcheck. Otherwise no changes, this is a "keepalive" release.

拼写检查。否则没有更改，这是一个“keepalive”版本。

A.6. rmcat -01 to -02

o Added Luca De Cicco and Saverio Mascolo as authors. o Extended the "Over-use detector" section with new technical details on how to dynamically tune the offset del_var_th for improved fairness properties. o Added reference to a paper analyzing the behavior of the proposed algorithm.

o 增加了卢卡·德·西科和萨维里奥·马斯科洛作为作者。 o 扩展了“过度使用检测器”部分，提供了关于如何动态调整偏移量del_var_th以改进公平性属性的新技术细节。 o 在一篇分析所提出算法行为的论文中增加了参考。

A.7. rmcat -02 to -03

o Swapped receiver-side/sender-side controller with delay-based/ loss-based controller as there is no longer a requirement to run the delay-based controller on the receiver-side. o Removed the discussion about multiple streams and transmission time offsets. o Introduced a new section about "Feedback and extensions". o Improvements to the threshold adaptation in the "Over-use detector" section. o Swapped the previous MIMD rate control algorithm for a new AIMD rate control algorithm.

o 由于不再需要在接收方运行基于延迟的控制器，因此将接收方/发送方控制器与基于延迟/丢失的控制器交换。 o 删除了关于多个流和传输时间偏移的讨论。 o 引入了关于“反馈和扩展”的新章节。 o 改进“过度使用检测器”部分中的阈值自适应。 o 将以前的MIMD速率控制算法替换为新的AIMD速率控制算法。

A.8. ietf-rmcat -00 to ietf-rmcat -01

o Arrival-time filter converted from a two dimensional Kalman filter to a scalar Kalman filter. o The use of the TFRC equation was removed from the loss-based controller, as it turned out to have little to no effect in practice.

o 到达时间滤波器从二维卡尔曼滤波器转换为标量卡尔曼滤波器。 o 从基于损耗的控制器中删除了TFRC方程的使用，因为它在实践中几乎没有影响。

A.9. ietf-rmcat -01 to ietf-rmcat -02

o Added a section which better describes the pre-filtering algorithm.

o 增加了一节，更好地描述了预过滤算法。

Authors’ Addresses 作者联系方式

Stefan Holmer Google Kungsbron 2 Stockholm 11122 Sweden Email: [email protected] Henrik Lundin Google Kungsbron 2 Stockholm 11122 Sweden Email: [email protected] Gaetano Carlucci Politecnico di Bari Via Orabona, 4 Bari 70125 Italy Email: [email protected] Luca De Cicco Politecnico di Bari Via Orabona, 4 Bari 70125 Italy Email: [email protected] Saverio Mascolo Politecnico di Bari Via Orabona, 4 Bari 70125 Italy Email: [email protected]

参考文档：

RFC和IETF不为人知的秘密 https://zhuanlan.zhihu.com/p/426531687