--- 1/draft-ietf-rmcat-gcc-00.txt 2015-10-19 11:15:06.318382231 -0700 +++ 2/draft-ietf-rmcat-gcc-01.txt 2015-10-19 11:15:06.358383198 -0700 @@ -1,22 +1,22 @@ Network Working Group S. Holmer Internet-Draft 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 Real-Time Communication - draft-ietf-rmcat-gcc-00 + draft-ietf-rmcat-gcc-01 Abstract This document describes two methods of congestion control when using real-time communications on the World Wide Web (RTCWEB); one delay- based and one loss-based. It is published as an input document to the RMCAT working group on congestion control for media streams. The mailing list of that working group is rmcat@ietf.org. @@ -35,21 +35,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on March 11, 2016. + This Internet-Draft 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/license-info) 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. Delay-based control . . . . . . . . . . . . . . . . . . . . . 5 4.1. Arrival-time model . . . . . . . . . . . . . . . . . . . 5 4.2. Arrival-time filter . . . . . . . . . . . . . . . . . . . 7 - 4.3. Over-use detector . . . . . . . . . . . . . . . . . . . . 9 - 4.4. Rate control . . . . . . . . . . . . . . . . . . . . . . 10 - 4.5. Parameters settings . . . . . . . . . . . . . . . . . . . 13 + 4.3. Over-use detector . . . . . . . . . . . . . . . . . . . . 8 + 4.4. Rate control . . . . . . . . . . . . . . . . . . . . . . 9 + 4.5. Parameters settings . . . . . . . . . . . . . . . . . . . 12 5. Loss-based control . . . . . . . . . . . . . . . . . . . . . 13 - 6. Interoperability Considerations . . . . . . . . . . . . . . . 15 - 7. Implementation Experience . . . . . . . . . . . . . . . . . . 15 - 8. Further Work . . . . . . . . . . . . . . . . . . . . . . . . 15 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 - 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 - 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 - 12.1. Normative References . . . . . . . . . . . . . . . . . . 16 - 12.2. Informative References . . . . . . . . . . . . . . . . . 17 - Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 17 - A.1. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 17 - A.2. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 17 - A.3. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 18 - A.4. rtcweb-03 to rmcat-00 . . . . . . . . . . . . . . . . . . 18 - A.5. rmcat -00 to -01 . . . . . . . . . . . . . . . . . . . . 18 - A.6. rmcat -01 to -02 . . . . . . . . . . . . . . . . . . . . 18 - A.7. rmcat -02 to -03 . . . . . . . . . . . . . . . . . . . . 18 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 + 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. rtcweb-03 to rmcat-00 . . . . . . . . . . . . . . . . . . 16 + A.5. rmcat -00 to -01 . . . . . . . . . . . . . . . . . . . . 17 + A.6. rmcat -01 to -02 . . . . . . . . . . . . . . . . . . . . 17 + A.7. rmcat -02 to -03 . . . . . . . . . . . . . . . . . . . . 17 + A.8. ietf-rmcat -00 to ietf-rmcat -01 . . . . . . . . . . . . 17 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction Congestion control is a requirement for all applications sharing the Internet resources [RFC2914]. Congestion control for real-time media is challenging for a number of reasons: o The media is usually encoded in forms that cannot be quickly @@ -122,33 +123,26 @@ [I-D.alvestrand-rmcat-remb] and [I-D.holmer-rmcat-transport-wide-cc-extensions]. 1.1. Mathematical notation conventions The mathematics of this document have been transcribed from a more formula-friendly format. The following notational conventions are used: - X_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(i-1), where T(i) is the departure timestamp of the last packet in the current packet group being processed. Any packets received out of order are ignored by the arrival-time model. Each group is assigned a receive time t(i), which corresponds to the time at which the last packet of the group was received. A group is delayed relative to its predecessor if t(i) - t(i-1) > T(i) - T(i-1), i.e., if the inter-arrival time is larger than the inter-departure time. - 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 inter-group delay variation as: - - d(i) = L(i)/C(i) - L(i-1)/C(i-1) + w(i) = + We can model the inter-group delay variation as: - L(i)-L(i-1) - = -------------- + 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 over-using the channel we - expect the mean of w(i) to increase, and if a queue on the network - path is being emptied, the mean of w(i) will decrease; otherwise the - mean of w(i) will be zero. + function of the link capacity, the current cross traffic, and the + current sent bitrate. We model W as a white Gaussian process. If we + are over-using the channel we expect the mean of w(i) to increase, + and if a queue on the network path is being emptied, the mean of w(i) + will decrease; otherwise the mean of w(i) will be zero. 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. Arrival-time filter - The parameters d(i) and dL(i) are readily available for each group of - packets, i > 1, and we want to estimate C(i) and m(i) and use those - estimates to detect whether or not the bottleneck link is over-used. - These parameters can be estimated by any adaptive filter - we are - using the Kalman filter. - - 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 over-used. 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(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) - k_bar(i) = ------------------------------------------------------ - var_v_hat(i) + h_bar(i)^T * (E(i-1) + Q(i)) * h_bar(i) + m_hat(i) = m_hat(i-1) + z(i) * k(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 - 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(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 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. Over-use detector - The offset estimate m(i), obtained as the output of the arrival-time - filter, is compared with a threshold gamma_1(i). An estimate above - the threshold is considered as an indication of over-use. Such an - indication is not enough for the detector to signal over-use to the - rate control subsystem. A definitive over-use will be signaled only - if over-use has been detected for at least gamma_2 milliseconds. - However, if m(i) < m(i-1), over-use will not be signaled even if all - the above conditions are met. Similarly, the opposite state, under- - use, is detected when m(i) < -gamma_1(i). If neither over-use nor - under-use is detected, the detector will be in the normal state. + The inter-group delay variation estimate m(i), obtained as the output + of the arrival-time filter, is compared with a threshold + del_var_th(i). An estimate above the threshold is considered as an + indication of over-use. Such an indication is not enough for the + detector to signal over-use to the rate control subsystem. A + definitive over-use will be signaled only if over-use has been + detected for at least overuse_time_th milliseconds. However, if m(i) + < m(i-1), over-use will not be signaled even if all the above + conditions are met. Similarly, the opposite state, under-use, is + detected when m(i) < -del_var_th(i). If neither over-use nor under- + use is detected, the detector will be in the normal state. - The threshold 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 over-use detector quickly reacts to a small increase in the offset estimate m(i) by generating an over-use signal that reduces the delay-based estimate of the available bandwidth A_hat (see Section 4.4). Thus, it is necessary to dynamically tune the - threshold gamma_1 to get good performance in the most common + threshold del_var_th to get good performance in the most common scenarios, such as when competing with loss-based flows. - For this reason, we propose to vary the threshold 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(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 - rationale is to increase gamma_1(i) when m(i) is outside of the range - [-gamma_1(i-1),gamma_1(i-1)], whereas, when the offset estimate m(i) - falls back into the range, gamma_1 is decreased. In this way when - m(i) increases, for instance due to a TCP flow entering the same - bottleneck, gamma_1(i) increases and avoids the uncontrolled - generation of over-use signals which may lead to starvation of the - flow controlled by the proposed algorithm [Pv13]. Moreover, - gamma_1(i) SHOULD NOT be updated if this condition holds: + with K(i)=K_d if |m(i)| < del_var_th(i-1) or K(i)=K_u otherwise. The + rationale is to increase del_var_th(i) when m(i) is outside of the + range [-del_var_th(i-1),del_var_th(i-1)], whereas, when the offset + estimate m(i) falls back into the range, del_var_th is decreased. In + this way when m(i) increases, for instance due to a TCP flow entering + the same bottleneck, del_var_th(i) increases and avoids the + uncontrolled generation of over-use signals which may lead to + starvation of the flow controlled by the proposed algorithm [Pv13]. + Moreover, del_var_th(i) SHOULD NOT be updated if this condition + holds: - |m(i)| - 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(i-1),gamma_1(i-1)] the threshold gamma_1(i) is decreased so - that a lower queuing delay can be achieved. + [-del_var_th(i-1),del_var_th(i-1)] the threshold del_var_th(i) is + decreased so that a lower queuing delay can be achieved. It is RECOMMENDED to choose K_u > K_d so that the rate at which - 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 intra-protocol fairness. RECOMMENDED values for - gamma_1(0), gamma_2, K_u and K_d are respectively 12.5 ms, 10 ms, - 0.01 and 0.00018. + 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 over-use. @@ -516,22 +485,22 @@ eta = 1.08^min(time_since_last_update_ms / 1000, 1.0) A_hat(i) = eta * A_hat(i-1) During the additive increase the estimate is increased with at most half a packet per response_time interval. The response_time interval is estimated as the round-trip time plus 100 ms as an estimate of over-use estimator and detector reaction time. response_time_ms = 100 + rtt_ms - beta = 0.5 * min(time_since_last_update_ms / response_time_ms, 1.0) - A_hat(i) = A_hat(i-1) + max(1000, beta * expected_packet_size_bits) + alpha = 0.5 * min(time_since_last_update_ms / response_time_ms, 1.0) + A_hat(i) = A_hat(i-1) + max(1000, alpha * expected_packet_size_bits) expected_packet_size_bits is used to get a slightly slower slope for the additive increase at lower bitrates. It can for instance be computed from the current bitrate by assuming a frame rate of 30 frames per second: bits_per_frame = A_hat(i-1) / 30 packets_per_frame = ceil(bits_per_frame / (1200 * 8)) avg_packet_size_bits = bits_per_frame / packets_per_frame @@ -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 over-use is detected the system transitions to the decrease state, where the delay-based available bandwidth estimate is decreased to a factor times the currently incoming bitrate. - A_hat(i) = alpha * R_hat(i) + 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 under-use to the rate control subsystem, we know that queues in the network path are being emptied, indicating that our available bandwidth estimate A_hat is lower than the actual available bandwidth. Upon that signal the rate control subsystem will enter the hold state, where the receive-side available bandwidth estimate will be held constant while waiting for the queues to stabilize at a lower level - a way of keeping the delay as low as possible. This decrease of delay is wanted, and expected, immediately after the estimate has been reduced due to over-use, but can also happen if the cross traffic over some links is reduced. It is RECOMMENDED that the routine to update A_hat(i) is run at least once every response_time interval. 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. Loss-based control A second part of the congestion controller bases its decisions on the round-trip time, packet loss and available bandwidth estimates A_hat received from the delay-based controller. The available bandwidth @@ -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(i-1)(1-0.5p), where p is the loss ratio. o As long as less than 2% of the packets have been lost As_hat(i) will be increased as As_hat(i) = 1.05(As_hat(i-1)) - The new bandwidth estimate is lower-bounded by the TCP Friendly Rate - Control formula [RFC3448] and upper-bounded by the delay-based - estimate of the available bandwidth A_hat(i), where the delay-based - estimate has precedence: - - 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. + The loss-based estimate As_hat is compared with the delay-based + estimate A_hat. The actual sending rate is set as the minimum + between As_hat and A_hat. We motivate the packet loss thresholds by noting that if the transmission channel has a small amount of packet loss due to over- use, that amount will soon increase if the sender does not adjust his bitrate. Therefore we will soon enough reach above the 10% threshold and adjust As_hat(i). However, if the packet loss ratio does not increase, the losses are probably not related to self-inflicted congestion and therefore we should not react on them. 6. Interoperability Considerations @@ -741,24 +688,20 @@ [I-D.holmer-rmcat-transport-wide-cc-extensions] Holmer, S., Flodman, M., and E. Sprang, "RTP Extensions for Transport-wide Congestion Control", draft-holmer- rmcat-transport-wide-cc-extensions-00 (work in progress), March 2015. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. - [RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP - Friendly Rate Control (TFRC): Protocol Specification", RFC - 3448, January 2003. - [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [abs-send-time] "RTP Header Extension for Absolute Sender Time", . 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 "Over-use 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 receiver-side/sender-side controller with delay-based/ loss-based controller as there is no longer a requirement to run the delay-based controller on the receiver-side. @@ -841,36 +784,46 @@ time offsets. o Introduced a new section about "Feedback and extensions". o Improvements to the threshold adaptation in the "Over-use detector" section. o Swapped the previous MIMD rate control algorithm for a new AIMD rate control algorithm. -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 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