 1/draftietfrmcatgcc00.txt 20151019 11:15:06.318382231 0700
+++ 2/draftietfrmcatgcc01.txt 20151019 11:15:06.358383198 0700
@@ 1,22 +1,22 @@
Network Working Group S. Holmer
InternetDraft H. Lundin
Intended status: Informational Google
Expires: March 11, 2016 G. Carlucci
+Expires: April 21, 2016 G. Carlucci
L. De Cicco
S. Mascolo
Politecnico di Bari
 September 8, 2015
+ October 19, 2015
A Google Congestion Control Algorithm for RealTime Communication
 draftietfrmcatgcc00
+ draftietfrmcatgcc01
Abstract
This document describes two methods of congestion control when using
realtime communications on the World Wide Web (RTCWEB); one delay
based and one lossbased.
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.
@@ 35,21 +35,21 @@
InternetDrafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as InternetDrafts. The list of current Internet
Drafts is at http://datatracker.ietf.org/drafts/current/.
InternetDrafts 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 InternetDrafts as reference
material or to cite them other than as "work in progress."
 This InternetDraft will expire on March 11, 2016.
+ This InternetDraft will expire on April 21, 2016.
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/licenseinfo) in effect on the date of
publication of this document. Please review these documents
@@ 57,46 +57,47 @@
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
+ 3. Feedback and extensions . . . . . . . . . . . . . . . . . . . 4
4. Delaybased control . . . . . . . . . . . . . . . . . . . . . 5
4.1. Arrivaltime model . . . . . . . . . . . . . . . . . . . 5
4.2. Arrivaltime filter . . . . . . . . . . . . . . . . . . . 7
 4.3. Overuse detector . . . . . . . . . . . . . . . . . . . . 9
 4.4. Rate control . . . . . . . . . . . . . . . . . . . . . . 10
 4.5. Parameters settings . . . . . . . . . . . . . . . . . . . 13
+ 4.3. Overuse detector . . . . . . . . . . . . . . . . . . . . 8
+ 4.4. Rate control . . . . . . . . . . . . . . . . . . . . . . 9
+ 4.5. Parameters settings . . . . . . . . . . . . . . . . . . . 12
5. Lossbased 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. rtcweb03 to rmcat00 . . . . . . . . . . . . . . . . . . 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
+ 6. Interoperability Considerations . . . . . . . . . . . . . . . 13
+ 7. Implementation Experience . . . . . . . . . . . . . . . . . . 14
+ 8. Further Work . . . . . . . . . . . . . . . . . . . . . . . . 14
+ 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
+ 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14
+ 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
+ 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
+ 12.1. Normative References . . . . . . . . . . . . . . . . . . 15
+ 12.2. Informative References . . . . . . . . . . . . . . . . . 15
+ Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 16
+ A.1. Version 00 to 01 . . . . . . . . . . . . . . . . . . . 16
+ A.2. Version 01 to 02 . . . . . . . . . . . . . . . . . . . 16
+ A.3. Version 02 to 03 . . . . . . . . . . . . . . . . . . . 16
+ A.4. rtcweb03 to rmcat00 . . . . . . . . . . . . . . . . . . 16
+ A.5. rmcat 00 to 01 . . . . . . . . . . . . . . . . . . . . 17
+ A.6. rmcat 01 to 02 . . . . . . . . . . . . . . . . . . . . 17
+ A.7. rmcat 02 to 03 . . . . . . . . . . . . . . . . . . . . 17
+ A.8. ietfrmcat 00 to ietfrmcat 01 . . . . . . . . . . . . 17
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
Congestion control is a requirement for all applications sharing the
Internet resources [RFC2914].
Congestion control for realtime media is challenging for a number of
reasons:
o The media is usually encoded in forms that cannot be quickly
@@ 122,33 +123,26 @@
[ID.alvestrandrmcatremb] and
[ID.holmerrmcattransportwideccextensions].
1.1. Mathematical notation conventions
The mathematics of this document have been transcribed from a more
formulafriendly 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_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.
 [x y z] A row vector consisting of elements x, y and z.

 X_bar^T The transpose of vector X_bar.

E{X} The expected value of the stochastic variable 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
@@ 264,187 +258,162 @@
T(i)  T(i1), 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 arrivaltime 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(i1) > T(i)  T(i1),
i.e., if the interarrival time is larger than the interdeparture
time.
 Since the time ts to send a group of packets of size L over a path
 with a capacity of C is roughly

 ts = L/C

 we can model the intergroup delay variation as:

 d(i) = L(i)/C(i)  L(i1)/C(i1) + w(i) =
+ We can model the intergroup delay variation as:
 L(i)L(i1)
 =  + w(i) = dL(i)/C(i) + w(i)
 C(i)
+ d(i) = w(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 overusing 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.
+ 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 overusing 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.
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)
+ d(i) = m(i) + v(i)
 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.
+ The noise term v(i) represents network jitter and other delay effects
+ not captured by the model.
4.2. Arrivaltime 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 overused.
 These parameters can be estimated by any adaptive filter  we are
 using the Kalman filter.

 Let
+ 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 overused. The parameter can
+ be estimated by any adaptive filter  we are using the Kalman filter.
 theta_bar(i) = [1/C(i) m(i)]^T
+ Let m(i) be the estimate at time i
 and call it the state at time i. We model the state evolution from
 time i to time i+1 as
+ We model the state evolution from time i to time i+1 as
 theta_bar(i+1) = theta_bar(i) + u_bar(i)
+ m(i+1) = m(i) + u(i)
 where u_bar(i) is the state noise that we model as a stationary
 process with Gaussian statistic with zero mean and covariance
 Q(i) = E{u_bar(i) * u_bar(i)^T}
+ where u(i) is the state noise that we model as a stationary process
+ with Gaussian statistic with zero mean and variance
 Q(i) is RECOMMENDED as a diagonal matrix with main diagonal elements
 as:
+ q(i) = E{u(i)^2}
 diag(Q(i)) = [10^13 10^3]^T
+ q(i) is RECOMMENDED equal to 10^3
Given equation 1 we get
 d(i) = h_bar(i)^T * theta_bar(i) + v(i)

 h_bar(i) = [dL(i) 1]^T
+ d(i) = m(i) + v(i)
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
+ variance var_v = E{v(i)^2}
 z(i) = d(i)  h_bar(i)^T * theta_hat(i1)
+ The Kalman filter recursively updates our estimate m_hat(i) as
 theta_hat(i) = theta_hat(i1) + z(i) * k_bar(i)
+ z(i) = d(i)  m_hat(i1)
 ( E(i1) + Q(i) ) * h_bar(i)
 k_bar(i) = 
 var_v_hat(i) + h_bar(i)^T * (E(i1) + Q(i)) * h_bar(i)
+ m_hat(i) = m_hat(i1) + z(i) * k(i)
 E(i) = (I  k_bar(i) * h_bar(i)^T) * (E(i1) + Q(i))
+ e(i1) + q(i)
+ k(i) = 
+ var_v_hat(i) + (e(i1) + q(i))
 where I is the 2by2 identity matrix.
+ e(i) = (1  k(i)) * (e(i1) + q(i))
 The variance var_v(i) = sigma_v(i)^2 is estimated using an
 exponential averaging filter, modified for variable sampling rate
+ 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(beta * var_v_hat(i1) + (1beta) * z(i)^2, 1)
+ var_v_hat(i) = max(alpha * var_v_hat(i1) + (1alpha) * z(i)^2, 1)
 beta = (1chi)^(30/(1000 * f_max))
+ alpha = (1chi)^(30/(1000 * f_max))
where f_max = max {1/(T(j)  T(j1))} for j in iK+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.
4.3. Overuse detector
 The offset estimate m(i), obtained as the output of the arrivaltime
 filter, is compared with a threshold gamma_1(i). An estimate above
 the threshold is considered as an indication of overuse. Such an
 indication is not enough for the detector to signal overuse to the
 rate control subsystem. A definitive overuse will be signaled only
 if overuse has been detected for at least gamma_2 milliseconds.
 However, if m(i) < m(i1), overuse 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 overuse nor
 underuse is detected, the detector will be in the normal state.
+ The intergroup delay variation estimate m(i), obtained as the output
+ of the arrivaltime filter, is compared with a threshold
+ del_var_th(i). An estimate above the threshold is considered as an
+ indication of overuse. Such an indication is not enough for the
+ detector to signal overuse to the rate control subsystem. A
+ definitive overuse will be signaled only if overuse has been
+ detected for at least overuse_time_th milliseconds. However, if m(i)
+ < m(i1), overuse will not be signaled even if all the above
+ conditions are met. Similarly, the opposite state, underuse, is
+ detected when m(i) < del_var_th(i). If neither overuse nor under
+ use is detected, the detector will be in the normal state.
 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.
+ 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.
 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
+ 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
overuse detector quickly reacts to a small increase in the offset
estimate m(i) by generating an overuse signal that reduces the
delaybased 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
+ threshold del_var_th to get good performance in the most common
scenarios, such as when competing with lossbased flows.
 For this reason, we propose to vary the threshold gamma_1(i)
+ For this reason, we propose to vary the threshold del_var_th(i)
according to the following dynamic equation:
gamma_1(i) = gamma_1(i1) + (t(i)t(i1)) * K(i) * (m(i)gamma_1(i1))
+del_var_th(i) =
+ del_var_th(i1) + (t(i)t(i1)) * K(i) * (m(i)del_var_th(i1))
 with K(i)=K_d if m(i) < gamma_1(i1) or K(i)=K_u otherwise. The
 rationale is to increase gamma_1(i) when m(i) is outside of the range
 [gamma_1(i1),gamma_1(i1)], 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 overuse 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:
+ with K(i)=K_d if m(i) < del_var_th(i1) 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(i1),del_var_th(i1)], 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 overuse 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)  gamma_1(i) > 15
+ m(i)  del_var_th(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.
+ 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.
On the other hand, when m(i) falls back into the range
 [gamma_1(i1),gamma_1(i1)] the threshold gamma_1(i) is decreased so
 that a lower queuing delay can be achieved.
+ [del_var_th(i1),del_var_th(i1)] 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
 gamma_1 is increased is higher than the rate at which it is
+ 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 intraprotocol 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.
+ del_var_th(0), overuse_time_th, K_u and K_d are respectively 12.5 ms,
+ 10 ms, 0.01 and 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 overuse.
@@ 516,22 +485,22 @@
eta = 1.08^min(time_since_last_update_ms / 1000, 1.0)
A_hat(i) = eta * A_hat(i1)
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 roundtrip time plus 100 ms as an estimate of
overuse estimator and detector reaction time.
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(i1) + max(1000, beta * expected_packet_size_bits)
+ alpha = 0.5 * min(time_since_last_update_ms / response_time_ms, 1.0)
+ A_hat(i) = A_hat(i1) + 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(i1) / 30
packets_per_frame = ceil(bits_per_frame / (1200 * 8))
avg_packet_size_bits = bits_per_frame / packets_per_frame
@@ 542,67 +511,65 @@
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 overuse is detected the system transitions to the decrease
state, where the delaybased available bandwidth estimate is
decreased to a factor times the currently incoming bitrate.
 A_hat(i) = alpha * R_hat(i)
+ A_hat(i) = beta * R_hat(i)
 alpha is typically chosen to be in the interval [0.8, 0.95], 0.85 is
+ beta is typically chosen to be in the interval [0.8, 0.95], 0.85 is
the RECOMMENDED value.
When the detector signals underuse 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 receiveside 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 overuse, 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.
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 
+ ++++
+  burst_time  Time limit in milliseconds  5 ms 
+   between packet bursts which  
+   identifies a group  
+  q  State noise covariance matrix  q = 10^3 
+  e(0)  Initial value of the system  e(0) = 0.1 
+   error covariance  
+  chi  Coefficient used for the  [0.1, 
+   measured noise variance  0.001] 
+  del_var_th(0)  Initial value for the adaptive  12.5 ms 
  threshold  
  gamma_2  Time required to trigger an overuse  10 ms 
   signal  
+  overuse_time_th  Time required to trigger an  10 ms 
+   overuse 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 
 ++++
+  beta  Decrease rate factor  0.85 
+ ++++
Table 1: RECOMMENDED values for delay based controller
Table 1
5. Lossbased control
A second part of the congestion controller bases its decisions on the
roundtrip time, packet loss and available bandwidth estimates A_hat
received from the delaybased controller. The available bandwidth
@@ 622,43 +589,23 @@
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(i1)(10.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(i1))
 The new bandwidth estimate is lowerbounded by the TCP Friendly Rate
 Control formula [RFC3448] and upperbounded by the delaybased
 estimate of the available bandwidth A_hat(i), where the delaybased
 estimate has precedence:

 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 roundtrip time in seconds.

 (The multiplication by 8 comes because TFRC is computing bandwidth in
 bytes, while this document computes bandwidth in bits.)

 In words: The lossbased estimate will never be larger than the
 delaybased estimate, and will never be lower than the estimate from
 the TFRC formula except if the delaybased estimate is lower than the
 TFRC estimate.
+ The lossbased estimate As_hat is compared with the delaybased
+ 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 selfinflicted
congestion and therefore we should not react on them.
6. Interoperability Considerations
@@ 741,24 +688,20 @@
[ID.holmerrmcattransportwideccextensions]
Holmer, S., Flodman, M., and E. Sprang, "RTP Extensions
for Transportwide Congestion Control", draftholmer
rmcattransportwideccextensions00 (work in progress),
March 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
 [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 RealTime
Applications", STD 64, RFC 3550, July 2003.
[abssendtime]
"RTP Header Extension for Absolute Sender Time",
.
12.2. Informative References
@@ 818,22 +761,22 @@
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 "Overuse detector" section with new technical
 details on how to dynamically tune the offset gamma_1 for improved
 fairness properties.
+ 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.
A.7. rmcat 02 to 03
o Swapped receiverside/senderside controller with delaybased/
lossbased controller as there is no longer a requirement to run
the delaybased controller on the receiverside.
@@ 841,36 +784,46 @@
time offsets.
o Introduced a new section about "Feedback and extensions".
o Improvements to the threshold adaptation in the "Overuse
detector" section.
o Swapped the previous MIMD rate control algorithm for a new AIMD
rate control algorithm.
Authors' Addresses
+A.8. ietfrmcat 00 to ietfrmcat 01
+ o Arrivaltime filter converted from a two dimensional Kalman filter
+ to a scalar Kalman filter.
+
+ o The use of the TFRC equation was removed from the lossbased
+ controller, as it turned out to have little to no effect in
+ practice.
+
+Authors' Addresses
Stefan Holmer
Google
Kungsbron 2
Stockholm 11122
Sweden
Email: holmer@google.com
Henrik Lundin
Google
Kungsbron 2
Stockholm 11122
Sweden
+ Email: hlundin@google.com
+
Gaetano Carlucci
Politecnico di Bari
Via Orabona, 4
Bari 70125
Italy
Email: gaetano.carlucci@poliba.it
Luca De Cicco
Politecnico di Bari