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

Kungsbron 2 | Kungsbron 2 | |||

Stockholm 11122 | Stockholm 11122 | |||

Sweden | Sweden | |||

Email: holmer@google.com | Email: holmer@google.com | |||

Henrik Lundin | Henrik Lundin | |||

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/ |