draft-ietf-rmcat-gcc-00.txt   draft-ietf-rmcat-gcc-01.txt 
Network Working Group S. Holmer Network Working Group S. Holmer
Internet-Draft H. Lundin Internet-Draft H. Lundin
Intended status: Informational Google Intended status: Informational Google
Expires: March 11, 2016 G. Carlucci Expires: April 21, 2016 G. Carlucci
L. De Cicco L. De Cicco
S. Mascolo S. Mascolo
Politecnico di Bari Politecnico di Bari
September 8, 2015 October 19, 2015
A Google Congestion Control Algorithm for Real-Time Communication A Google Congestion Control Algorithm for Real-Time Communication
draft-ietf-rmcat-gcc-00 draft-ietf-rmcat-gcc-01
Abstract Abstract
This document describes two methods of congestion control when using This document describes two methods of congestion control when using
real-time communications on the World Wide Web (RTCWEB); one delay- real-time communications on the World Wide Web (RTCWEB); one delay-
based and one loss-based. based and one loss-based.
It is published as an input document to the RMCAT working group on It is published as an input document to the RMCAT working group on
congestion control for media streams. The mailing list of that congestion control for media streams. The mailing list of that
working group is rmcat@ietf.org. working group is rmcat@ietf.org.
skipping to change at page 1, line 46 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 11, 2016. This Internet-Draft will expire on April 21, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 25 skipping to change at page 2, line 25
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Mathematical notation conventions . . . . . . . . . . . . 3 1.1. Mathematical notation conventions . . . . . . . . . . . . 3
2. System model . . . . . . . . . . . . . . . . . . . . . . . . 4 2. System model . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Feedback and extensions . . . . . . . . . . . . . . . . . . . 5 3. Feedback and extensions . . . . . . . . . . . . . . . . . . . 4
4. Delay-based control . . . . . . . . . . . . . . . . . . . . . 5 4. Delay-based control . . . . . . . . . . . . . . . . . . . . . 5
4.1. Arrival-time model . . . . . . . . . . . . . . . . . . . 5 4.1. Arrival-time model . . . . . . . . . . . . . . . . . . . 5
4.2. Arrival-time filter . . . . . . . . . . . . . . . . . . . 7 4.2. Arrival-time filter . . . . . . . . . . . . . . . . . . . 7
4.3. Over-use detector . . . . . . . . . . . . . . . . . . . . 9 4.3. Over-use detector . . . . . . . . . . . . . . . . . . . . 8
4.4. Rate control . . . . . . . . . . . . . . . . . . . . . . 10 4.4. Rate control . . . . . . . . . . . . . . . . . . . . . . 9
4.5. Parameters settings . . . . . . . . . . . . . . . . . . . 13 4.5. Parameters settings . . . . . . . . . . . . . . . . . . . 12
5. Loss-based control . . . . . . . . . . . . . . . . . . . . . 13 5. Loss-based control . . . . . . . . . . . . . . . . . . . . . 13
6. Interoperability Considerations . . . . . . . . . . . . . . . 15 6. Interoperability Considerations . . . . . . . . . . . . . . . 13
7. Implementation Experience . . . . . . . . . . . . . . . . . . 15 7. Implementation Experience . . . . . . . . . . . . . . . . . . 14
8. Further Work . . . . . . . . . . . . . . . . . . . . . . . . 15 8. Further Work . . . . . . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
12.1. Normative References . . . . . . . . . . . . . . . . . . 16 12.1. Normative References . . . . . . . . . . . . . . . . . . 15
12.2. Informative References . . . . . . . . . . . . . . . . . 17 12.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 17 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 16
A.1. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 17 A.1. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 16
A.2. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 17 A.2. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 16
A.3. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 18 A.3. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 16
A.4. rtcweb-03 to rmcat-00 . . . . . . . . . . . . . . . . . . 18 A.4. rtcweb-03 to rmcat-00 . . . . . . . . . . . . . . . . . . 16
A.5. rmcat -00 to -01 . . . . . . . . . . . . . . . . . . . . 18 A.5. rmcat -00 to -01 . . . . . . . . . . . . . . . . . . . . 17
A.6. rmcat -01 to -02 . . . . . . . . . . . . . . . . . . . . 18 A.6. rmcat -01 to -02 . . . . . . . . . . . . . . . . . . . . 17
A.7. rmcat -02 to -03 . . . . . . . . . . . . . . . . . . . . 18 A.7. rmcat -02 to -03 . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 A.8. ietf-rmcat -00 to ietf-rmcat -01 . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
Congestion control is a requirement for all applications sharing the Congestion control is a requirement for all applications sharing the
Internet resources [RFC2914]. Internet resources [RFC2914].
Congestion control for real-time media is challenging for a number of Congestion control for real-time media is challenging for a number of
reasons: reasons:
o The media is usually encoded in forms that cannot be quickly o The media is usually encoded in forms that cannot be quickly
skipping to change at page 3, line 43 skipping to change at page 3, line 43
[I-D.alvestrand-rmcat-remb] and [I-D.alvestrand-rmcat-remb] and
[I-D.holmer-rmcat-transport-wide-cc-extensions]. [I-D.holmer-rmcat-transport-wide-cc-extensions].
1.1. Mathematical notation conventions 1.1. Mathematical notation conventions
The mathematics of this document have been transcribed from a more The mathematics of this document have been transcribed from a more
formula-friendly format. formula-friendly format.
The following notational conventions are used: 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 X_hat An estimate of the true value of variable X - conventionally
marked by a circumflex accent on top of the variable name. marked by a circumflex accent on top of the variable name.
X(i) The "i"th value of vector X - conventionally marked by a X(i) The "i"th value of vector X - conventionally marked by a
subscript i. 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 E{X} The expected value of the stochastic variable X
2. System model 2. System model
The following elements are in the system: The following elements are in the system:
o RTP packet - an RTP packet containing media data. o RTP packet - an RTP packet containing media data.
o Packet group - a set of RTP packets transmitted from the sender o Packet group - a set of RTP packets transmitted from the sender
uniquely identified by the group departure and group arrival time uniquely identified by the group departure and group arrival time
skipping to change at page 6, line 41 skipping to change at page 6, line 34
T(i) - T(i-1), where T(i) is the departure timestamp of the last 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 packet in the current packet group being processed. Any packets
received out of order are ignored by the arrival-time model. received out of order are ignored by the arrival-time model.
Each group is assigned a receive time t(i), which corresponds to the 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 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), 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 i.e., if the inter-arrival time is larger than the inter-departure
time. time.
Since the time ts to send a group of packets of size L over a path We can model the inter-group delay variation as:
with a capacity of C is roughly
ts = L/C
we can model the inter-group delay variation as:
d(i) = L(i)/C(i) - L(i-1)/C(i-1) + w(i) =
L(i)-L(i-1) d(i) = w(i)
= -------------- + w(i) = dL(i)/C(i) + w(i)
C(i)
Here, w(i) is a sample from a stochastic process W, which is a 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 function of the link capacity, the current cross traffic, and the
current sent bitrate. C is modeled as being constant as we expect it current sent bitrate. We model W as a white Gaussian process. If we
to vary more slowly than other parameters of this model. We model W are over-using the channel we expect the mean of w(i) to increase,
as a white Gaussian process. If we are over-using the channel we and if a queue on the network path is being emptied, the mean of w(i)
expect the mean of w(i) to increase, and if a queue on the network will decrease; otherwise the mean of w(i) will be zero.
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, Breaking out the mean, m(i), from w(i) to make the process zero mean,
we get we get
Equation 1 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 The noise term v(i) represents network jitter and other delay effects
large group of packets need more time to traverse the link than a not captured by the model.
small group, thus arriving with higher relative delay. The noise
term represents network jitter and other delay effects not captured
by the model.
4.2. Arrival-time filter 4.2. Arrival-time filter
The parameters d(i) and dL(i) are readily available for each group of The parameter d(i) is readily available for each group of packets, i
packets, i > 1, and we want to estimate C(i) and m(i) and use those > 1. We want to estimate m(i) and use this estimate to detect
estimates to detect whether or not the bottleneck link is over-used. whether or not the bottleneck link is over-used. The parameter can
These parameters can be estimated by any adaptive filter - we are be estimated by any adaptive filter - we are using the Kalman filter.
using the Kalman filter.
Let
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 We model the state evolution from time i to time i+1 as
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 where u(i) is the state noise that we model as a stationary process
process with Gaussian statistic with zero mean and covariance with Gaussian statistic with zero mean and variance
Q(i) = E{u_bar(i) * u_bar(i)^T}
Q(i) is RECOMMENDED as a diagonal matrix with main diagonal elements q(i) = E{u(i)^2}
as:
diag(Q(i)) = [10^-13 10^-3]^T q(i) is RECOMMENDED equal to 10^-3
Given equation 1 we get Given equation 1 we get
d(i) = h_bar(i)^T * theta_bar(i) + v(i) d(i) = m(i) + v(i)
h_bar(i) = [dL(i) 1]^T
where v(i) is zero mean white Gaussian measurement noise with where v(i) is zero mean white Gaussian measurement noise with
variance var_v = sigma(v,i)^2 variance var_v = E{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) The Kalman filter recursively updates our estimate m_hat(i) as
theta_hat(i) = theta_hat(i-1) + z(i) * k_bar(i) z(i) = d(i) - m_hat(i-1)
( E(i-1) + Q(i) ) * h_bar(i) m_hat(i) = m_hat(i-1) + z(i) * k(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)) e(i-1) + q(i)
k(i) = ----------------------------------------
var_v_hat(i) + (e(i-1) + q(i))
where I is the 2-by-2 identity matrix. e(i) = (1 - k(i)) * (e(i-1) + q(i))
The variance var_v(i) = sigma_v(i)^2 is estimated using an The variance var_v(i) = E{v(i)^2} is estimated using an exponential
exponential averaging filter, modified for variable sampling rate averaging filter, modified for variable sampling rate
var_v_hat(i) = max(beta * var_v_hat(i-1) + (1-beta) * z(i)^2, 1) var_v_hat(i) = max(alpha * var_v_hat(i-1) + (1-alpha) * z(i)^2, 1)
beta = (1-chi)^(30/(1000 * f_max)) 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 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 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 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 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 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) > 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 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 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 packets are sent at a higher rate than the channel capacity, in which
case they will be queued behind each other. case they will be queued behind each other.
4.3. Over-use detector 4.3. Over-use detector
The offset estimate m(i), obtained as the output of the arrival-time The inter-group delay variation estimate m(i), obtained as the output
filter, is compared with a threshold gamma_1(i). An estimate above of the arrival-time filter, is compared with a threshold
the threshold is considered as an indication of over-use. Such an del_var_th(i). An estimate above the threshold is considered as an
indication is not enough for the detector to signal over-use to the indication of over-use. Such an indication is not enough for the
rate control subsystem. A definitive over-use will be signaled only detector to signal over-use to the rate control subsystem. A
if over-use has been detected for at least gamma_2 milliseconds. definitive over-use will be signaled only if over-use has been
However, if m(i) < m(i-1), over-use will not be signaled even if all detected for at least overuse_time_th milliseconds. However, if m(i)
the above conditions are met. Similarly, the opposite state, under- < m(i-1), over-use will not be signaled even if all the above
use, is detected when m(i) < -gamma_1(i). If neither over-use nor conditions are met. Similarly, the opposite state, under-use, is
under-use is detected, the detector will be in the normal state. 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 gamma_1 has a remarkable impact on the overall dynamics The threshold del_var_th has a remarkable impact on the overall
and performance of the algorithm. In particular, it has been shown dynamics and performance of the algorithm. In particular, it has
that using a static threshold gamma_1, a flow controlled by the been shown that using a static threshold del_var_th, a flow
proposed algorithm can be starved by a concurrent TCP flow [Pv13]. controlled by the proposed algorithm can be starved by a concurrent
This starvation can be avoided by increasing the threshold gamma_1 to TCP flow [Pv13]. This starvation can be avoided by increasing the
a sufficiently large value. threshold del_var_th to a sufficiently large value.
The reason is that, by using a larger value of gamma_1, a larger The reason is that, by using a larger value of del_var_th, a larger
queuing delay can be tolerated, whereas with a small gamma_1, the 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 over-use detector quickly reacts to a small increase in the offset
estimate m(i) by generating an over-use signal that reduces the estimate m(i) by generating an over-use signal that reduces the
delay-based estimate of the available bandwidth A_hat (see delay-based estimate of the available bandwidth A_hat (see
Section 4.4). Thus, it is necessary to dynamically tune the 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 loss-based flows. scenarios, such as when competing with loss-based 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: according to the following dynamic equation:
gamma_1(i) = gamma_1(i-1) + (t(i)-t(i-1)) * K(i) * (|m(i)|-gamma_1(i-1)) 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)| < gamma_1(i-1) or K(i)=K_u otherwise. The with K(i)=K_d if |m(i)| < del_var_th(i-1) or K(i)=K_u otherwise. The
rationale is to increase gamma_1(i) when m(i) is outside of the range rationale is to increase del_var_th(i) when m(i) is outside of the
[-gamma_1(i-1),gamma_1(i-1)], whereas, when the offset estimate m(i) range [-del_var_th(i-1),del_var_th(i-1)], whereas, when the offset
falls back into the range, gamma_1 is decreased. In this way when estimate m(i) falls back into the range, del_var_th is decreased. In
m(i) increases, for instance due to a TCP flow entering the same this way when m(i) increases, for instance due to a TCP flow entering
bottleneck, gamma_1(i) increases and avoids the uncontrolled the same bottleneck, del_var_th(i) increases and avoids the
generation of over-use signals which may lead to starvation of the uncontrolled generation of over-use signals which may lead to
flow controlled by the proposed algorithm [Pv13]. Moreover, starvation of the flow controlled by the proposed algorithm [Pv13].
gamma_1(i) SHOULD NOT be updated if this condition holds: 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], It is also RECOMMENDED to clamp del_var_th(i) to the range [6, 600],
since a too small gamma_1(i) can cause the detector to become overly since a too small del_var_th(i) can cause the detector to become
sensitive. overly sensitive.
On the other hand, when m(i) falls back into the range 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 [-del_var_th(i-1),del_var_th(i-1)] the threshold del_var_th(i) is
that a lower queuing delay can be achieved. 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 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 decreased. With this setting it is possible to increase the
threshold in the case of a concurrent TCP flow and prevent starvation threshold in the case of a concurrent TCP flow and prevent starvation
as well as enforcing intra-protocol fairness. RECOMMENDED values for 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, del_var_th(0), overuse_time_th, K_u and K_d are respectively 12.5 ms,
0.01 and 0.00018. 10 ms, 0.01 and 0.00018.
4.4. Rate control 4.4. Rate control
The rate control is split in two parts, one controlling the bandwidth The rate control is split in two parts, one controlling the bandwidth
estimate based on delay, and one controlling the bandwidth estimate estimate based on delay, and one controlling the bandwidth estimate
based on loss. Both are designed to increase the estimate of the based on loss. Both are designed to increase the estimate of the
available bandwidth A_hat as long as there is no detected congestion available bandwidth A_hat as long as there is no detected congestion
and to ensure that we will eventually match the available bandwidth and to ensure that we will eventually match the available bandwidth
of the channel and detect an over-use. of the channel and detect an over-use.
skipping to change at page 12, line 16 skipping to change at page 11, line 20
8% per second. 8% per second.
eta = 1.08^min(time_since_last_update_ms / 1000, 1.0) eta = 1.08^min(time_since_last_update_ms / 1000, 1.0)
A_hat(i) = eta * A_hat(i-1) A_hat(i) = eta * A_hat(i-1)
During the additive increase the estimate is increased with at most During the additive increase the estimate is increased with at most
half a packet per response_time interval. The response_time interval 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 is estimated as the round-trip time plus 100 ms as an estimate of
over-use estimator and detector reaction time. over-use estimator and detector reaction time.
response_time_ms = 100 + rtt_ms response_time_ms = 100 + rtt_ms
beta = 0.5 * min(time_since_last_update_ms / response_time_ms, 1.0) alpha = 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) 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 expected_packet_size_bits is used to get a slightly slower slope for
the additive increase at lower bitrates. It can for instance be the additive increase at lower bitrates. It can for instance be
computed from the current bitrate by assuming a frame rate of 30 computed from the current bitrate by assuming a frame rate of 30
frames per second: frames per second:
bits_per_frame = A_hat(i-1) / 30 bits_per_frame = A_hat(i-1) / 30
packets_per_frame = ceil(bits_per_frame / (1200 * 8)) packets_per_frame = ceil(bits_per_frame / (1200 * 8))
avg_packet_size_bits = bits_per_frame / packets_per_frame avg_packet_size_bits = bits_per_frame / packets_per_frame
skipping to change at page 12, line 43 skipping to change at page 11, line 47
stream with the bitrate the congestion controller is asking for, the stream with the bitrate the congestion controller is asking for, the
available bandwidth estimate should stay within a given bound. available bandwidth estimate should stay within a given bound.
Therefore we introduce a threshold 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 When an over-use is detected the system transitions to the decrease
state, where the delay-based available bandwidth estimate is state, where the delay-based available bandwidth estimate is
decreased to a factor times the currently incoming bitrate. 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. the RECOMMENDED value.
When the detector signals under-use to the rate control subsystem, we When the detector signals under-use to the rate control subsystem, we
know that queues in the network path are being emptied, indicating know that queues in the network path are being emptied, indicating
that our available bandwidth estimate A_hat is lower than the actual that our available bandwidth estimate A_hat is lower than the actual
available bandwidth. Upon that signal the rate control subsystem available bandwidth. Upon that signal the rate control subsystem
will enter the hold state, where the receive-side available bandwidth will enter the hold state, where the receive-side available bandwidth
estimate will be held constant while waiting for the queues to 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 stabilize at a lower level - a way of keeping the delay as low as
possible. This decrease of delay is wanted, and expected, possible. This decrease of delay is wanted, and expected,
immediately after the estimate has been reduced due to over-use, but immediately after the estimate has been reduced due to over-use, but
can also happen if the cross traffic over some links is reduced. 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 It is RECOMMENDED that the routine to update A_hat(i) is run at least
once every response_time interval. once every response_time interval.
4.5. Parameters settings 4.5. Parameters settings
+------------+-------------------------------------+----------------+ +-----------------+-----------------------------------+-------------+
| Parameter | Description | RECOMMENDED | | Parameter | Description | RECOMMENDED |
| | | Value | | | | Value |
+------------+-------------------------------------+----------------+ +-----------------+-----------------------------------+-------------+
| burst_time | Time limit in milliseconds between | 5 ms | | burst_time | Time limit in milliseconds | 5 ms |
| | packet bursts which identifies a | | | | between packet bursts which | |
| | group | | | | identifies a group | |
| Q | State noise covariance matrix | diag(Q(i)) = | | q | State noise covariance matrix | q = 10^-3 |
| | | [10^-13 | | e(0) | Initial value of the system | e(0) = 0.1 |
| | | 10^-3]^T | | | error covariance | |
| E(0) | Initial value of the system error | diag(E(0)) = | | chi | Coefficient used for the | [0.1, |
| | covariance | [100 0.1]^T | | | measured noise variance | 0.001] |
| chi | Coefficient used for the measured | [0.1, 0.001] | | del_var_th(0) | Initial value for the adaptive | 12.5 ms |
| | noise variance | | | | threshold | |
| gamma_1(0) | Initial value for the adaptive | 12.5 ms | | overuse_time_th | Time required to trigger an | 10 ms |
| | threshold | | | | overuse signal | |
| gamma_2 | Time required to trigger an overuse | 10 ms | | K_u | Coefficient for the adaptive | 0.01 |
| | signal | | | | threshold | |
| K_u | Coefficient for the adaptive | 0.01 | | K_d | Coefficient for the adaptive | 0.00018 |
| | threshold | | | | threshold | |
| K_d | Coefficient for the adaptive | 0.00018 | | T | Time window for measuring the | [0.5, 1] s |
| | threshold | | | | received bitrate | |
| T | Time window for measuring the | [0.5, 1] s | | beta | Decrease rate factor | 0.85 |
| | received bitrate | | +-----------------+-----------------------------------+-------------+
| alpha | Decrease rate factor | 0.85 |
+------------+-------------------------------------+----------------+
Table 1: RECOMMENDED values for delay based controller Table 1: RECOMMENDED values for delay based controller
Table 1 Table 1
5. Loss-based control 5. Loss-based control
A second part of the congestion controller bases its decisions on the A second part of the congestion controller bases its decisions on the
round-trip time, packet loss and available bandwidth estimates A_hat round-trip time, packet loss and available bandwidth estimates A_hat
received from the delay-based controller. The available bandwidth received from the delay-based controller. The available bandwidth
skipping to change at page 14, line 27 skipping to change at page 13, line 33
from the receiver, the sender available bandwidth estimate from the receiver, the sender available bandwidth estimate
As_hat(i) will be kept unchanged. As_hat(i) will be kept unchanged.
o If more than 10% of the packets have been lost a new estimate is 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 calculated as As_hat(i) = As_hat(i-1)(1-0.5p), where p is the loss
ratio. ratio.
o As long as less than 2% of the packets have been lost As_hat(i) 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)) 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 The loss-based estimate As_hat is compared with the delay-based
Control formula [RFC3448] and upper-bounded by the delay-based estimate A_hat. The actual sending rate is set as the minimum
estimate of the available bandwidth A_hat(i), where the delay-based between As_hat and A_hat.
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 round-trip 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 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.
We motivate the packet loss thresholds by noting that if the We motivate the packet loss thresholds by noting that if the
transmission channel has a small amount of packet loss due to over- 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 use, that amount will soon increase if the sender does not adjust his
bitrate. Therefore we will soon enough reach above the 10% threshold bitrate. Therefore we will soon enough reach above the 10% threshold
and adjust As_hat(i). However, if the packet loss ratio does not and adjust As_hat(i). However, if the packet loss ratio does not
increase, the losses are probably not related to self-inflicted increase, the losses are probably not related to self-inflicted
congestion and therefore we should not react on them. congestion and therefore we should not react on them.
6. Interoperability Considerations 6. Interoperability Considerations
skipping to change at page 17, line 5 skipping to change at page 15, line 34
[I-D.holmer-rmcat-transport-wide-cc-extensions] [I-D.holmer-rmcat-transport-wide-cc-extensions]
Holmer, S., Flodman, M., and E. Sprang, "RTP Extensions Holmer, S., Flodman, M., and E. Sprang, "RTP Extensions
for Transport-wide Congestion Control", draft-holmer- for Transport-wide Congestion Control", draft-holmer-
rmcat-transport-wide-cc-extensions-00 (work in progress), rmcat-transport-wide-cc-extensions-00 (work in progress),
March 2015. March 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. 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. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[abs-send-time] [abs-send-time]
"RTP Header Extension for Absolute Sender Time", "RTP Header Extension for Absolute Sender Time",
<http://www.webrtc.org/experiments/rtp-hdrext/ <http://www.webrtc.org/experiments/rtp-hdrext/
abs-send-time>. abs-send-time>.
12.2. Informative References 12.2. Informative References
skipping to change at page 18, line 34 skipping to change at page 17, line 14
A.5. rmcat -00 to -01 A.5. rmcat -00 to -01
Spellcheck. Otherwise no changes, this is a "keepalive" release. Spellcheck. Otherwise no changes, this is a "keepalive" release.
A.6. rmcat -01 to -02 A.6. rmcat -01 to -02
o Added Luca De Cicco and Saverio Mascolo as authors. o Added Luca De Cicco and Saverio Mascolo as authors.
o Extended the "Over-use detector" section with new technical o Extended the "Over-use detector" section with new technical
details on how to dynamically tune the offset gamma_1 for improved details on how to dynamically tune the offset del_var_th for
fairness properties. improved fairness properties.
o Added reference to a paper analyzing the behavior of the proposed o Added reference to a paper analyzing the behavior of the proposed
algorithm. algorithm.
A.7. rmcat -02 to -03 A.7. rmcat -02 to -03
o Swapped receiver-side/sender-side controller with delay-based/ o Swapped receiver-side/sender-side controller with delay-based/
loss-based controller as there is no longer a requirement to run loss-based controller as there is no longer a requirement to run
the delay-based controller on the receiver-side. the delay-based controller on the receiver-side.
skipping to change at page 19, line 8 skipping to change at page 17, line 37
time offsets. time offsets.
o Introduced a new section about "Feedback and extensions". o Introduced a new section about "Feedback and extensions".
o Improvements to the threshold adaptation in the "Over-use o Improvements to the threshold adaptation in the "Over-use
detector" section. detector" section.
o Swapped the previous MIMD rate control algorithm for a new AIMD o Swapped the previous MIMD rate control algorithm for a new AIMD
rate control algorithm. rate control algorithm.
Authors' Addresses 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.
Authors' Addresses
Stefan Holmer Stefan Holmer
Google Google
Kungsbron 2 Kungsbron 2
Stockholm 11122 Stockholm 11122
Sweden Sweden
Email: holmer@google.com Email: holmer@google.com
Henrik Lundin Henrik Lundin
Google Google
Kungsbron 2 Kungsbron 2
Stockholm 11122 Stockholm 11122
Sweden Sweden
Email: hlundin@google.com
Gaetano Carlucci Gaetano Carlucci
Politecnico di Bari Politecnico di Bari
Via Orabona, 4 Via Orabona, 4
Bari 70125 Bari 70125
Italy Italy
Email: gaetano.carlucci@poliba.it Email: gaetano.carlucci@poliba.it
Luca De Cicco Luca De Cicco
Politecnico di Bari Politecnico di Bari
 End of changes. 53 change blocks. 
195 lines changed or deleted 148 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/