live_transCongestionControl

google 在webrtc上的拥塞控制rfc：

[Search] [txt|xml|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-alvestrand-rtcweb-congestion)          IPR declarations
          00 01 02 03 draft-ietf-rmcat-gcc                              
Network Working Group                                          S. Holmer
Internet-Draft                                                 H. Lundin
Intended status: Informational                                    Google
Expires: December 31, 2015                                   G. Carlucci
                                                             L. De Cicco
                                                              S. Mascolo
                                                     Politecnico di Bari
                                                           June 29, 2015


   A Google Congestion Control Algorithm for Real-Time Communication
                  draft-alvestrand-rmcat-congestion-03

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.
   这篇文档描述两种拥塞控制的方式，当在rtcweb上使用时；一个基于延迟，一个基于丢包；

   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 rmcat@ietf.org.
   它被作为一个内部文档发表到RMCAT工作组，为流媒体的拥塞控制。邮箱是rmcat@ietf.org

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

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.本互联网草案完全符合 BCP 78 和 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 是 Internet Engineering 的工作文件
工作组 (IETF)。请注意，其他组也可能分发
工作文件作为互联网草案。当前互联网的列表-
草稿位于 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."

互联网草案是有效期最长为六个月的草案文件
并且可能随时被其他文档更新、替换或废弃
时间。使用 Internet-Drafts 作为参考是不合适的
材料或引用它们而不是“正在进行的工作”。

   This Internet-Draft will expire on December 31, 2015.
这个互联网草案将于 2015 年 12 月 31 日到期。





Holmer, et al.          Expires December 31, 2015               [Page 1]


Internet-Draft        Congestion Control for RTCWEB            June 2015


Copyright Notice

   Copyright (c) 2015 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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Mathematical notation conventions . . . . . . . . . . . .   3
   2.  System model  . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Feedback and extensions . . . . . . . . . . . . . . . . . . .   5
   4.  Delay-based control . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  Arrival-time model  . . . . . . . . . . . . . . . . . . .   5
     4.2.  Arrival-time filter . . . . . . . . . . . . . . . . . . .   7
     4.3.  Over-use detector . . . . . . . . . . . . . . . . . . . .   9
     4.4.  Rate control  . . . . . . . . . . . . . . . . . . . . . .  10
     4.5.  Parameters settings . . . . . . . . . . . . . . . . . . .  13
   5.  Loss-based control  . . . . . . . . . . . . . . . . . . . . .  13
   6.  Interoperability Considerations . . . . . . . . . . . . . . .  15
   7.  Implementation Experience . . . . . . . . . . . . . . . . . .  15
   8.  Further Work  . . . . . . . . . . . . . . . . . . . . . . . .  15
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  16
   11. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  16
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  16
     12.2.  Informative References . . . . . . . . . . . . . . . . .  17
   Appendix A.  Change log . . . . . . . . . . . . . . . . . . . . .  17
     A.1.  Version -00 to -01  . . . . . . . . . . . . . . . . . . .  17
     A.2.  Version -01 to -02  . . . . . . . . . . . . . . . . . . .  17
     A.3.  Version -02 to -03  . . . . . . . . . . . . . . . . . . .  18
     A.4.  rtcweb-03 to rmcat-00 . . . . . . . . . . . . . . . . . .  18
     A.5.  rmcat -00 to -01  . . . . . . . . . . . . . . . . . . . .  18
     A.6.  rmcat -01 to -02  . . . . . . . . . . . . . . . . . . . .  18
     A.7.  rmcat -02 to -03  . . . . . . . . . . . . . . . . . . . .  18
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19





Holmer, et al.          Expires December 31, 2015               [Page 2]


Internet-Draft        Congestion Control for RTCWEB            June 2015


1.  Introduction

   Congestion control is a requirement for all applications sharing the
   Internet resources [RFC2914].
   拥塞控制时所有应用程序共享互联网资源的要求，见RFC2914

   Congestion control for real-time media is challenging for a number of
   reasons: 在实时媒体上的拥塞控制是具有挑战性的，因为如下原因：

   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 
编码通常对丢包敏感，实时传输要求尽量避免出现重传修复丢包的情况。

   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.
   
本备忘录描述了两种拥塞控制算法，它们一起能够提供良好的性能和与使用相同拥塞控制的其他视频流以及
共享相同链路的 TCP 流的合理带宽共享。

   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].使用的信令包括实验性 RTP 报头扩展RTCP 信息。。。。

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_bar  The variable X, where X is a vector - conventionally marked by
      a bar on top of the variable name.
X_bar 变量 X，其中 X 是向量 - 通常由
变量名称顶部的栏。

   X_hat  An estimate of the true value of variable X - conventionally
      marked by a circumflex accent on top of the variable name.
X_hat 对变量 X 真实值的估计 - 传统上
由变量名称顶部的抑扬符号标记。^ 


   X(i)  The "i"th value of vector X - conventionally marked by a
      subscript i.X(i) 向量 X 的第 i 个值 - 通常由 a 标记
下标 i.

   [x y z]  A row vector consisting of elements x, y and z.[x y z] 由元素 x、y 和 z 组成的行向量。



Holmer, et al.          Expires December 31, 2015               [Page 3]


Internet-Draft        Congestion Control for RTCWEB            June 2015


   X_bar^T  The transpose of vector X_bar.向量 X_bar 的转置。

   E{X}  The expected value of the stochastic variable X 随机变量 X 的期望值

2.  System model

   The following elements are in the system:

   o  RTP packet - an RTP packet containing media data.

   o  Packet group - 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.
     数据包组 - 从发送方传输的一组 ​​RTP 数据包
    由团体出发和团体到达时间唯一标识     (absolute send time) [abs-send-time].
    可能是视频或音频包或者是两者的混合
   o  Incoming media stream - a stream of frames consisting of RTP 
      packets.传入媒体流： 即一条由rtp包组成帧的流；

   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 
      RTP发送者，发送RTP流通过网络到RTP接收者。它生成RTP时间戳和绝对发送时间头部扩展、

   o  RTP receiver - receives the RTP stream, marks the time of arrival. 
      RTP接收者： 接收RTP流并标记到达时间。

   o  RTCP sender at RTP receiver - sends receiver reports, REMB
      messages and transport-wide RTCP feedback messages. 
      RTCP发送方在RTP接收方； 发送接收者报告，REMB 信息和传输范围的 RTCP 反馈消息。

   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. 
      RTP 发送方的 RTCP 接收方-接收接收方报告和REMB信息和传输范围的RTCP反馈信息，报告这些到发送方控制器
   o  RTCP receiver at RTP receiver, receives sender reports from the    
      sender. 
     RTCP 接收器位于 RTP 接收器，从发送器接收发送器报告。
   o  Loss-based controller - takes loss rate measurement, round trip
      time measurement and REMB messages, and computes a target sending
      bitrate.
     基于丢包的控制器 - 进行丢包率测量、往返时间测量和 REMB 消息，并计算目标发送比特率。
   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.
       基于延迟的控制器 - 获取数据包到达信息，或者在
      RTP 接收器，或从 RTP 发送器接收到的反馈，并计算它传递给基于丢包的控制器的最大比特率。
   Together, loss-based controller and delay-based controller implement
   the congestion control algorithm.
    基于丢包的控制器和基于延迟的控制器一起实现拥塞控制算法。






Holmer, et al.          Expires December 31, 2015               [Page 4]


Internet-Draft        Congestion Control for RTCWEB            June 2015


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.
第一个版本可以通过使用 [I-D.holmer-rmcat-transport-wide-cc-extensions] 中描述的每包反馈协议来实现。 
在这里，RTP 接收器将记录每个接收到的数据包的到达时间和传输范围的seqnum，这些信息将使用传输范围的反馈消息定期发送回发送方。 
推荐的反馈间隔是每接收到一个视频帧一次，如果是纯音频或多流，则至少每 30 毫秒一次。 如果需要限制反馈开销，该间隔可以增加到 100 毫秒。
   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.
发送方将接收到的{序列号，到达时间}对映射到反馈报告涵盖的每个数据包的发送时间，并将这些时间戳提供给基于延迟的控制器。 它还将根据反馈消息中的序列号计算丢失率。


   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 接收器报告发回。 在发送方，REMB 消息中的比特率和丢失的数据包部分被送入基于丢失的控制器，后者输出最终目标比特率。 建议在检测到拥塞时立即发送 REMB 消息，否则至少每秒发送一次。

不管怎样最终都是发送方根据信息得到最后的发送bitrate，并调整速率进行拥塞控制；


4.  Delay-based control

   The delay-based control algorithm can be further decomposed into
   three parts: an arrival-time filter, an over-use detector, and a rate
   controller.基于延迟的控制算法可以进一步分解为
三部分：到达时间滤波器、过度使用检测器和速率
控制器。

4.1.  Arrival-time model

   This section describes an adaptive filter that continuously updates
   estimates of network parameters based on the timing of the received
   packets.



Holmer, et al.          Expires December 31, 2015               [Page 5]


Internet-Draft        Congestion Control for RTCWEB            June 2015


   We define the inter-arrival time, t(i) - t(i-1), as the difference in
   arrival time of two packets or two groups of packets.
   Correspondingly, the inter-departure time, T(i) - T(i-1), is defined
   as the difference in departure-time of two packets or 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.
我们将到达间隔时间 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))


   At the receiving side we are observing groups of incoming packets,
   where a group of packets is defined as follows:

在接收端，我们观察传入的数据包组，
其中一组数据包定义如下：
   o  A sequence of packets which are sent within a burst_time interval
      constitute a group.  RECOMMENDED value for burst_time is 5 ms.
在 burst_time 间隔内发送的数据包序列
组成一个群体。 Burst_time 的推荐值为 5 ms。
   o  In addition, any packet which has an inter-arrival time less than
      burst_time and an inter-group delay variation d(i) less than 0 is
      also considered being part of the current group of packets.  The
      reasoning behind including these packets in the group is to better
      handle delay transients, caused by packets being queued up for
      reasons unrelated to congestion.  As an example this has been
      observed to happen on many Wi-Fi and wireless networks.
此外，具有小于burst_time的到达间隔时间和小于0的组间延迟变化d(i)的任何分组也被认为是当前分组分组的一部分。
 将这些数据包包含在组中的原因是为了更好地处理延迟瞬变，这是由于数据包因与拥塞无关的原因排队而引起的。 例如，在许多 Wi-Fi 和无线网络上都观察到了这种情况。

   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.
连续组之间的出发间隔时间计算为 T(i) - T(i-1)，其中 T(i) 是当前正在处理的分组组中最后一个分组的出发时间戳。 
任何无序接收的数据包都会被到达时间模型忽略。
   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.
每个组被分配一个接收时间 t(i)，它对应于
收到组的最后一个数据包的时间。

如果 t(i) - t(i-1)> T(i) - T(i-1)，则一组是相对于其前任延迟，
即，如果到达间隔时间大于出发间隔时间
时间
   Since the time ts to send a group of packets of size L over a path
   with a capacity of C is roughly
由于在容量为 C 的路径上发送一组大小为 L 的数据包的时间 ts 大致为
     ts = L/C

   we can model the inter-group delay variation as:

我们可以将组间延迟变化建模为：






Holmer, et al.          Expires December 31, 2015               [Page 6]


Internet-Draft        Congestion Control for RTCWEB            June 2015


     d(i) = L(i)/C(i) - L(i-1)/C(i-1) + w(i) =

              L(i)-L(i-1)
          = -------------- + w(i) = dL(i)/C(i) + w(i)
                  C(i)


   Here, w(i) is a sample from a stochastic process W, which is a
   function of the capacity C(i), the current cross traffic, and the
   current sent bitrate.  C is modeled as being constant as we expect it
   to vary more slowly than other parameters of this model.  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.
这里，w(i) 是来自随机过程 W 的样本，它是容量 C(i)、当前交叉流量和当前发送比特率的函数。
  C 被建模为常数，因为我们预计它比该模型的其他参数变化得更慢。 我们将 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) = dL(i)/C(i) + m(i) + v(i)//这里的v(i）属于观测噪声，可以看看：//https://www.cnblogs.com/ishen/p/15000909.html#!comments

   This is our fundamental model, where we take into account that a
   large group of packets need more time to traverse the link than a
   small group, thus arriving with higher relative delay.  The noise
   term represents network jitter and other delay effects not captured
   by the model.
从 w(i) 中取出均值 m(i) 使过程均值为零，
    我们得到

    等式 1

      d(i) = dL(i)/C(i) + m(i) + v(i)

    这是我们的基本模型，我们考虑到一大群数据包比一小群数据包需要更多的时间来遍历链路，因此到达时具有更高的相对延迟。
 噪声项表示模型未捕获的网络抖动和其他延迟效应。
4.2.  Arrival-time filter

   The parameters d(i) and dL(i) are readily available for each group of
   packets, i > 1, and we want to estimate C(i) and m(i) and use those
   estimates to detect whether or not the bottleneck link is over-used.
   These parameters can be estimated by any adaptive filter - we are
   using the Kalman filter.
参数 d(i) 和 dL(i) 可用于每组
数据包，i>1，我们想估计 C(i) 和 m(i) 并使用它们
估计以检测瓶颈链路是否被过度使用。
这些参数可以通过任何自适应滤波器来估计——我们是
使用卡尔曼滤波器。
   Let

     theta_bar(i) = [1/C(i)  m(i)]^T

   and call it the state at time i.  We model the state evolution from
   time i to time i+1 as
并将其称为时间 i 的状态。我们对状态演化进行建模
时间 i 到时间 i+1 为
     theta_bar(i+1) = theta_bar(i) + u_bar(i)

   where u_bar(i) is the state noise that we model as a stationary
   process with Gaussian statistic with zero mean and covariance
其中 u_bar(i) 是我们建模为平稳的状态噪声
处理具有零均值和协方差的高斯统计量


Holmer, et al.          Expires December 31, 2015               [Page 7]


Internet-Draft        Congestion Control for RTCWEB            June 2015


     Q(i) = E{u_bar(i) * u_bar(i)^T}

   Q(i) is RECOMMENDED as a diagonal matrix with main diagonal elements
   as:

     diag(Q(i)) = [10^-13 10^-3]^T

   Given equation 1 we get

     d(i) = h_bar(i)^T * theta_bar(i) + v(i)

     h_bar(i) = [dL(i)  1]^T

   where v(i) is zero mean white Gaussian measurement noise with
   variance var_v = sigma(v,i)^2

   The Kalman filter recursively updates our estimate

     theta_hat(i) = [1/C_hat(i) m_hat(i)]^T

   as

     z(i) = d(i) - h_bar(i)^T * theta_hat(i-1)

     theta_hat(i) = theta_hat(i-1) + z(i) * k_bar(i)

                       ( E(i-1) + Q(i) ) * h_bar(i)
     k_bar(i) = ------------------------------------------------------
                var_v_hat(i) + h_bar(i)^T * (E(i-1) + Q(i)) * h_bar(i)

     E(i) = (I - k_bar(i) * h_bar(i)^T) * (E(i-1) + Q(i))

   where I is the 2-by-2 identity matrix.

   The variance var_v(i) = sigma_v(i)^2 is estimated using an
   exponential averaging filter, modified for variable sampling rate

     var_v_hat(i) = max(beta * var_v_hat(i-1) + (1-beta) * z(i)^2, 1)

     beta = (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



Holmer, et al.          Expires December 31, 2015               [Page 8]


Internet-Draft        Congestion Control for RTCWEB            June 2015


   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.

4.3.  Over-use detector

   The offset estimate m(i), obtained as the output of the arrival-time
   filter, is compared with a threshold gamma_1(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 gamma_2 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) < -gamma_1(i).  If neither over-use nor
   under-use is detected, the detector will be in the normal state.
作为到达时间滤波器的输出获得的偏移估计 m(i) 与阈值 gamma_1(i) 进行比较。 高于阈值的估计被视为过度使用的迹象。
 这种指示不足以使检测器向速率控制子系统发出过度使用信号。 只有在至少 gamma_2 毫秒内检测到过度使用时，才会发出明确的过度使用信号。
    但是，如果 m(i) < m(i-1)，即使满足上述所有条件，也不会发出过度使用信号。 类似地，当 m(i) < -gamma_1(i) 时，检测到相反的状态，即使用不足。
 如果没有检测到过度使用和使用不足，则探测器将处于正常状态。
   The threshold gamma_1 has a remarkable impact on the overall dynamics
   and performance of the algorithm.  In particular, it has been shown
   that using a static threshold gamma_1, 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 gamma_1 to
   a sufficiently large value.
阈值 gamma_1 对算法的整体动态和性能有显着影响。 特别是，已经表明，使用静态阈值 gamma_1，由所提出的算法控制的流可能会被并发 TCP 流 [Pv13] 饿死。
    可以通过将阈值 gamma_1 增加到足够大的值来避免这种饥饿。
   The reason is that, by using a larger value of gamma_1, a larger
   queuing delay can be tolerated, whereas with a small gamma_1, 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 gamma_1 to get good performance in the most common
   scenarios, such as when competing with loss-based flows.
原因是，通过使用较大的 gamma_1 值，可以容忍较大的排队延迟，而对于较小的 gamma_1，
过度使用检测器通过生成过度使用快速响应偏移估计 m(i) 的小幅增加 - 使用减少可用带宽 A_hat 的基于延迟的估计的信号（参见第 4.4 节）。
 因此，有必要动态调整阈值 gamma_1 以在最常见的场景中获得良好的性能，例如与基于损失的流竞争时。
   For this reason, we propose to vary the threshold gamma_1(i)
   according to the following dynamic equation:
出于这个原因，我们建议改变阈值 gamma_1(i)
根据以下动态方程：
gamma_1(i) = gamma_1(i-1) + (t(i)-t(i-1)) * K(i) * (|m(i)|-gamma_1(i-1))

   with K(i)=K_d if |m(i)| < gamma_1(i-1) or K(i)=K_u otherwise.  The
   rationale is to increase gamma_1(i) when m(i) is outside of the range
   [-gamma_1(i-1),gamma_1(i-1)], whereas, when the offset estimate m(i)
   falls back into the range, gamma_1 is decreased.  In this way when
   m(i) increases, for instance due to a TCP flow entering the same
   bottleneck, gamma_1(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,
   gamma_1(i) SHOULD NOT be updated if this condition holds:
K(i)=K_d 如果 |m(i)| < gamma_1(i-1) 否则 K(i)=K_u 。 
基本原理是当 m(i) 超出范围 [-gamma_1(i-1),gamma_1(i-1)] 时增加 gamma_1(i)，而当偏移估计值 m(i) 回落到 范围内，gamma_1 减小。
 通过这种方式，当 m(i) 增加时，例如由于 TCP 流进入同一瓶颈，gamma_1(i) 会增加并避免过度使用信号的不受控制的生成，
 这可能导致所提出的算法控制的流饥饿 [Pv13]。 
此外，如果此条件成立，则不应更新 gamma_1(i)：



Holmer, et al.          Expires December 31, 2015               [Page 9]


Internet-Draft        Congestion Control for RTCWEB            June 2015


     |m(i)| - gamma_1(i) > 15

   It is also RECOMMENDED to clamp gamma_1(i) to the range [6, 600],
   since a too small gamma_1(i) can cause the detector to become overly
   sensitive.
还建议将 gamma_1(i) 限制在 [6, 600] 范围内，因为太小 gamma_1(i) 会导致检测器变得过于敏感。
   On the other hand, when m(i) falls back into the range
   [-gamma_1(i-1),gamma_1(i-1)] the threshold gamma_1(i) is decreased so
   that a lower queuing delay can be achieved.
另一方面，当 m(i) 回落到范围 [-gamma_1(i-1),gamma_1(i-1)] 时，阈值 gamma_1(i) 会降低，从而可以实现较低的排队延迟。
   It is RECOMMENDED to choose K_u > K_d so that the rate at which
   gamma_1 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
   gamma_1(0), gamma_2, K_u and K_d are respectively 12.5 ms, 10 ms,
   0.01 and 0.00018.
建议选择 K_u > K_d，以便 gamma_1 增加的速率高于其减少的速率。 通过此设置，可以在并发 TCP 流的情况下增加阈值并防止饥饿以及强制执行协议内公平性。
 gamma_1(0)、gamma_2、K_u 和 K_d 的推荐值分别为 12.5 ms、10 ms、0.01 和 0.00018。

 
 
 4.4.  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.
速率控制分为两部分，一部分控制基于延迟的带宽估计，另一部分控制基于损耗的带宽估计。 
只要没有检测到拥塞，两者都旨在增加对可用带宽 A_hat 的估计，并确保我们最终将匹配信道的可用带宽并检测过度使用。
   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.
速率控制子系统有 3 种状态：增加、减少和保持。
“增加”是没有检测到拥塞时的状态； “减少”是
检测到拥塞的状态，“保持”是一种状态
在“增加”之前等待已建立的队列耗尽
状态。
   The state transitions (with blank fields meaning "remain in state")
   are:


状态转换（空白字段表示“保持状态”）
是：






Holmer, et al.          Expires December 31, 2015              [Page 10]


Internet-Draft        Congestion Control for RTCWEB            June 2015


   +----+--------+-----------+------------+--------+
   |     \ State |   Hold    |  Increase  |Decrease|
   |      \      |           |            |        |
   | Signal\     |           |            |        |
   +--------+----+-----------+------------+--------+
   |  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) 接近我们之前处于降低状态时的传入比特率的平均值，我们假设我们接近收敛。
 “Close” 定义为围绕该平均值的三个标准偏差。 建议使用平滑因子为 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) 增加到平均最大比特率的三个标准偏差以上，我们假设当前的拥塞程度已经改变，
此时我们重置平均最大比特率并返回
乘法递增状态。
   R_hat(i) is the incoming bitrate measured by the delay-based
   controller over a T seconds window:
R_hat(i) 是基于延迟的控制器在 T 秒窗口内测量的传入比特率：
     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.
N(i) 是过去 T 秒收到的数据包数量，L(j) 是
数据包 j 的有效载荷大小。 0.5 到 1 秒之间的窗口是
受到推崇的。




Holmer, et al.          Expires December 31, 2015              [Page 11]


Internet-Draft        Congestion Control for RTCWEB            June 2015


   During multiplicative increase, the estimate is increased by at most
   8% per second.

在乘法增加期间，估计最多增加
每秒 8%。
     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.
在加法增加期间，每个 response_time 间隔最多增加半个数据包的估计值。 response_time 间隔估计为往返时间加上 100 ms 作为过度使用估计器和检测器反应时间的估计。
     response_time_ms = 100 + rtt_ms
     beta = 0.5 * min(time_since_last_update_ms / response_time_ms, 1.0)
     A_hat(i) = A_hat(i-1) + max(1000, beta * 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:
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)

   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) = alpha * R_hat(i)

   alpha is typically chosen to be in the interval [0.8, 0.95], 0.85 is
   the RECOMMENDED value.
alpha 通常选择在区间 [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



Holmer, et al.          Expires December 31, 2015              [Page 12]


Internet-Draft        Congestion Control for RTCWEB            June 2015


   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.

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

   
   4.5.  Parameters settings

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

          Table 1: RECOMMENDED values for delay based controller

                                  Table 1

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




Holmer, et al.          Expires December 31, 2015              [Page 13]


Internet-Draft        Congestion Control for RTCWEB            June 2015


   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.
拥塞控制器的第二部分基于从基于延迟的控制器接收到的往返时间、数据包丢失和可用带宽估计 A_hat 做出决定。 
由基于丢包的控制器计算的可用带宽估计用 As_hat 表示。
    仅当沿路径的队列大小足够大时，基于延迟的控制器产生的可用带宽估计 A_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))

   The new bandwidth estimate is lower-bounded by the TCP Friendly Rate
   Control formula [RFC3448] and upper-bounded by the delay-based
   estimate of the available bandwidth A_hat(i), where the delay-based
   estimate has precedence:
新的带宽估计由 TCP 友好速率控制公式 [RFC3448] 下限，上限由可用带宽 A_hat(i) 的基于延迟的估计确定，其中基于延迟的估计具有优先权：
                                    8 s
  As_hat(i) >= ---------------------------------------------------------
               R*sqrt(2*b*p/3) + (t_RTO*(3*sqrt(3*b*p/8)*p*(1+32*p^2)))

  As_hat(i) <= A_hat(i)


   where b is the number of packets acknowledged by a single TCP
   acknowledgment (set to 1 per TFRC recommendations), t_RTO is the TCP
   retransmission timeout value in seconds (set to 4*R) and s is the
   average packet size in bytes.  R is the round-trip time in seconds.
其中 b 是单个 TCP 确认的数据包数
确认（根据 TFRC 建议设置为 1），t_RTO 是 TCP
以秒为单位的重传超时值（设置为 4*R），s 是
平均数据包大小（以字节为单位）。 R 是以秒为单位的往返时间。
   (The multiplication by 8 comes because TFRC is computing bandwidth in
   bytes, while this document computes bandwidth in bits.)
（乘以 8 是因为 TFRC 在计算带宽
字节，而本文档以位为单位计算带宽。）
   In words: The loss-based estimate will never be larger than the
   delay-based estimate, and will never be lower than the estimate from
   the TFRC formula except if the delay-based estimate is lower than the
   TFRC estimate.

换句话说：基于丢包的估计永远不会大于
基于延迟的估计，并且永远不会低于来自
TFRC 公式，除非基于延迟的估计低于
TFRC 估计。


Holmer, et al.          Expires December 31, 2015              [Page 14]


Internet-Draft        Congestion Control for RTCWEB            June 2015


   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.
我们通过注意到如果传输通道由于过度使用而有少量数据包丢失来激发丢包阈值，如果发送方不调整他的比特率，该数量将很快增加。 
因此，我们将很快达到 10% 以上的阈值并调整 As_hat(i)。 但是，如果丢包率没有增加，则丢包可能与自己造成的拥塞无关，因此我们不应对其做出反应。




6.  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 接收方报告并使用丢失数据包的比例和往返时间作为 输入到基于损失的控制器。 
基于延迟的控制器应保持禁用状态。



7.  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.
该算法已在开源WebRTC中实现
项目，自 M23 以来一直在 Chrome 中使用，并且正在被使用
谷歌环聊。
   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.
该算法的部署揭示了与拥塞或其他有问题的 WiFi 网络相关的问题，这导致了算法的改进。 该算法还在多方会议场景中进行了测试，会议服务器终止了端点之间的拥塞控制。 
这确保了拥塞控制不会做出关于最大发送和接收比特率等的假设，这对于会议服务器来说通常是无法控制的。


8.  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 作为拥塞估计和链路过度使用检测的信号。



Holmer, et al.          Expires December 31, 2015              [Page 15]


Internet-Draft        Congestion Control for RTCWEB            June 2015


9.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.

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

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

12.  References

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





Holmer, et al.          Expires December 31, 2015              [Page 16]


Internet-Draft        Congestion Control for RTCWEB            June 2015


   [RFC3448]  Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP
              Friendly Rate Control (TFRC): Protocol Specification", RFC
              3448, January 2003.

   [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",
              <http://www.webrtc.org/experiments/rtp-hdrext/
              abs-send-time>.

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

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




Holmer, et al.          Expires December 31, 2015              [Page 17]


Internet-Draft        Congestion Control for RTCWEB            June 2015


   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.

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.

A.4.  rtcweb-03 to rmcat-00

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

A.5.  rmcat -00 to -01

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

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 gamma_1 for improved
      fairness properties.

   o  Added reference to a paper analyzing the behavior of the proposed
      algorithm.

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.



Holmer, et al.          Expires December 31, 2015              [Page 18]


Internet-Draft        Congestion Control for RTCWEB            June 2015


   o  Swapped the previous MIMD rate control algorithm for a new AIMD
      rate control algorithm.

Authors' Addresses

   Stefan Holmer
   Google
   Kungsbron 2
   Stockholm  11122
   Sweden

   Email: holmer@google.com


   Henrik Lundin
   Google
   Kungsbron 2
   Stockholm  11122
   Sweden


   Gaetano Carlucci
   Politecnico di Bari
   Via Orabona, 4
   Bari  70125
   Italy

   Email: gaetano.carlucci@poliba.it


   Luca De Cicco
   Politecnico di Bari
   Via Orabona, 4
   Bari  70125
   Italy

   Email: l.decicco@poliba.it


   Saverio Mascolo
   Politecnico di Bari
   Via Orabona, 4
   Bari  70125
   Italy

   Email: mascolo@poliba.it