draft-ietf-rmcat-scream-cc-11.txt   draft-ietf-rmcat-scream-cc-12.txt 
RMCAT WG I. Johansson RMCAT WG I. Johansson
Internet-Draft Z. Sarker Internet-Draft Z. Sarker
Intended status: Experimental Ericsson AB Intended status: Experimental Ericsson AB
Expires: April 12, 2018 October 9, 2017 Expires: April 26, 2018 October 23, 2017
Self-Clocked Rate Adaptation for Multimedia Self-Clocked Rate Adaptation for Multimedia
draft-ietf-rmcat-scream-cc-11 draft-ietf-rmcat-scream-cc-12
Abstract Abstract
This memo describes a rate adaptation algorithm for conversational This memo describes a rate adaptation algorithm for conversational
media services such as video. The solution conforms to the packet media services such as video. The solution conforms to the packet
conservation principle and uses a hybrid loss and delay based conservation principle and uses a hybrid loss and delay based
congestion control algorithm. The algorithm is evaluated over both congestion control algorithm. The algorithm is evaluated over both
simulated Internet bottleneck scenarios as well as in a Long Term simulated Internet bottleneck scenarios as well as in a Long Term
Evolution (LTE) system simulator and is shown to achieve both low Evolution (LTE) system simulator and is shown to achieve both low
latency and high video throughput in these scenarios. latency and high video throughput in these scenarios.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 April 12, 2018. This Internet-Draft will expire on April 26, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 20 skipping to change at page 2, line 20
1.1. Wireless (LTE) access properties . . . . . . . . . . . . 3 1.1. Wireless (LTE) access properties . . . . . . . . . . . . 3
1.2. Why is it a self-clocked algorithm? . . . . . . . . . . . 4 1.2. Why is it a self-clocked algorithm? . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of SCReAM Algorithm . . . . . . . . . . . . . . . . 4 3. Overview of SCReAM Algorithm . . . . . . . . . . . . . . . . 4
3.1. Network Congestion Control . . . . . . . . . . . . . . . 7 3.1. Network Congestion Control . . . . . . . . . . . . . . . 7
3.2. Sender Transmission Control . . . . . . . . . . . . . . . 8 3.2. Sender Transmission Control . . . . . . . . . . . . . . . 8
3.3. Media Rate Control . . . . . . . . . . . . . . . . . . . 8 3.3. Media Rate Control . . . . . . . . . . . . . . . . . . . 8
4. Detailed Description of SCReAM . . . . . . . . . . . . . . . 9 4. Detailed Description of SCReAM . . . . . . . . . . . . . . . 9
4.1. SCReAM Sender . . . . . . . . . . . . . . . . . . . . . . 9 4.1. SCReAM Sender . . . . . . . . . . . . . . . . . . . . . . 9
4.1.1. Constants and Parameter values . . . . . . . . . . . 9 4.1.1. Constants and Parameter values . . . . . . . . . . . 9
4.1.1.1. Constants . . . . . . . . . . . . . . . . . . . . 9 4.1.1.1. Constants . . . . . . . . . . . . . . . . . . . . 10
4.1.1.2. State variables . . . . . . . . . . . . . . . . . 11 4.1.1.2. State variables . . . . . . . . . . . . . . . . . 11
4.1.2. Network congestion control . . . . . . . . . . . . . 13 4.1.2. Network congestion control . . . . . . . . . . . . . 13
4.1.2.1. Reaction to packets loss and ECN . . . . . . . . 15 4.1.2.1. Reaction to packets loss and ECN . . . . . . . . 16
4.1.2.2. Congestion window update . . . . . . . . . . . . 16 4.1.2.2. Congestion window update . . . . . . . . . . . . 16
4.1.2.3. Competing flows compensation . . . . . . . . . . 18 4.1.2.3. Competing flows compensation . . . . . . . . . . 19
4.1.2.4. Lost packet detection . . . . . . . . . . . . . . 20 4.1.2.4. Lost packet detection . . . . . . . . . . . . . . 21
4.1.2.5. Send window calculation . . . . . . . . . . . . . 20 4.1.2.5. Send window calculation . . . . . . . . . . . . . 21
4.1.2.6. Packet pacing . . . . . . . . . . . . . . . . . . 21 4.1.2.6. Packet pacing . . . . . . . . . . . . . . . . . . 22
4.1.2.7. Resuming fast increase . . . . . . . . . . . . . 22 4.1.2.7. Resuming fast increase . . . . . . . . . . . . . 23
4.1.2.8. Stream prioritization . . . . . . . . . . . . . . 22 4.1.2.8. Stream prioritization . . . . . . . . . . . . . . 23
4.1.3. Media rate control . . . . . . . . . . . . . . . . . 22 4.1.3. Media rate control . . . . . . . . . . . . . . . . . 23
4.2. SCReAM Receiver . . . . . . . . . . . . . . . . . . . . . 25 4.2. SCReAM Receiver . . . . . . . . . . . . . . . . . . . . . 26
4.2.1. Requirements on feedback elements . . . . . . . . . . 25 4.2.1. Requirements on feedback elements . . . . . . . . . . 26
4.2.2. Requirements on feedback intensity . . . . . . . . . 27 4.2.2. Requirements on feedback intensity . . . . . . . . . 28
5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 28 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 29
6. Implementation status . . . . . . . . . . . . . . . . . . . . 29 6. Implementation status . . . . . . . . . . . . . . . . . . . . 30
6.1. OpenWebRTC . . . . . . . . . . . . . . . . . . . . . . . 29 6.1. OpenWebRTC . . . . . . . . . . . . . . . . . . . . . . . 30
6.2. A C++ Implementation of SCReAM . . . . . . . . . . . . . 30 6.2. A C++ Implementation of SCReAM . . . . . . . . . . . . . 31
7. Suggested experiments . . . . . . . . . . . . . . . . . . . . 30 7. Suggested experiments . . . . . . . . . . . . . . . . . . . . 31
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
10. Security Considerations . . . . . . . . . . . . . . . . . . . 31 10. Security Considerations . . . . . . . . . . . . . . . . . . . 32
11. Change history . . . . . . . . . . . . . . . . . . . . . . . 31 11. Change history . . . . . . . . . . . . . . . . . . . . . . . 32
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
12.1. Normative References . . . . . . . . . . . . . . . . . . 33 12.1. Normative References . . . . . . . . . . . . . . . . . . 34
12.2. Informative References . . . . . . . . . . . . . . . . . 33 12.2. Informative References . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
1. Introduction 1. Introduction
Congestion in the Internet occurs when the transmitted bitrate is Congestion in the Internet occurs when the transmitted bitrate is
higher than the available capacity over a given transmission path. higher than the available capacity over a given transmission path.
Applications that are deployed in the Internet have to employ Applications that are deployed in the Internet have to employ
congestion control, to achieve robust performance and to avoid congestion control, to achieve robust performance and to avoid
congestion collapse in the Internet. Interactive realtime congestion collapse in the Internet. Interactive realtime
communication imposes a lot of requirements on the transport, communication imposes a lot of requirements on the transport,
therefore a robust, efficient rate adaptation for all access types is therefore a robust, efficient rate adaptation for all access types is
skipping to change at page 8, line 10 skipping to change at page 8, line 10
The network congestion control sets an upper limit on how much data The network congestion control sets an upper limit on how much data
can be in the network (bytes in flight); this limit is called CWND can be in the network (bytes in flight); this limit is called CWND
(congestion window) and is used in the sender transmission control. (congestion window) and is used in the sender transmission control.
The SCReAM congestion control method, uses techniques similar to The SCReAM congestion control method, uses techniques similar to
LEDBAT [RFC6817] to measure the qdelay. As is the case with LEDBAT, LEDBAT [RFC6817] to measure the qdelay. As is the case with LEDBAT,
it is not necessary to use synchronized clocks in sender and receiver it is not necessary to use synchronized clocks in sender and receiver
in order to compute the qdelay. It is however necessary that they in order to compute the qdelay. It is however necessary that they
use the same clock frequency, or that the clock frequency at the use the same clock frequency, or that the clock frequency at the
receiver can be inferred reliably by the sender. receiver can be inferred reliably by the sender. Failure to meet
this requirement leads to malfunction in the SCReAM congestion
control algorithm due to incorrect estimation of the network queue
delay.
The SCReAM sender calculates the congestion window based on the The SCReAM sender calculates the congestion window based on the
feedback from the SCReAM receiver. The congestion window is allowed feedback from the SCReAM receiver. The congestion window is allowed
to increase if the qdelay is below a predefined qdelay target, to increase if the qdelay is below a predefined qdelay target,
otherwise the congestion window decreases. The qdelay target is otherwise the congestion window decreases. The qdelay target is
typically set to 50-100ms. This ensures that the queuing delay is typically set to 50-100ms. This ensures that the queuing delay is
kept low. The reaction to loss or ECN events leads to an instant kept low. The reaction to loss or ECN events leads to an instant
reduction of CWND. Note that the source rate limited nature of real reduction of CWND. Note that the source rate limited nature of real
time media such as video, typically means that the queuing delay will time media such as video, typically means that the queuing delay will
mostly be below the given delay target, this is contrary to the case mostly be below the given delay target, this is contrary to the case
skipping to change at page 10, line 24 skipping to change at page 10, line 31
QDELAY_WEIGHT (0.1) QDELAY_WEIGHT (0.1)
Averaging factor for qdelay_fraction_avg. Averaging factor for qdelay_fraction_avg.
QDELAY_TREND_TH (0.2) QDELAY_TREND_TH (0.2)
Averaging factor for qdelay_fraction_avg. Averaging factor for qdelay_fraction_avg.
QDELAY_TREND_TH (0.2) QDELAY_TREND_TH (0.2)
Averaging factor for qdelay_fraction_avg. Averaging factor for qdelay_fraction_avg.
MIN_CWND (3000byte) MIN_CWND (3000byte)
Min CWND. Minimum congestion window.
MAX_BYTES_IN_FLIGHT_HEAD_ROOM (1.1) MAX_BYTES_IN_FLIGHT_HEAD_ROOM (1.1)
Headroom for the limitation of CWND. Headroom for the limitation of CWND.
GAIN (1.0) GAIN (1.0)
Gain factor for congestion window adjustment. Gain factor for congestion window adjustment.
BETA_LOSS (0.8) BETA_LOSS (0.8)
CWND scale factor due to loss event. CWND scale factor due to loss event.
skipping to change at page 11, line 28 skipping to change at page 11, line 34
Guard factor against RTP queue buildup. This value MAY be subject Guard factor against RTP queue buildup. This value MAY be subject
to tuning depending on e.g media coder characteristics, experiments to tuning depending on e.g media coder characteristics, experiments
with H264 and VP8 indicate that 1.0 is a suitable value. See with H264 and VP8 indicate that 1.0 is a suitable value. See
[SCReAM-CPP-implementation] and [SCReAM-implementation-experience] [SCReAM-CPP-implementation] and [SCReAM-implementation-experience]
for evaluation of a real implementation. for evaluation of a real implementation.
RTP_QDELAY_TH (0.02s) RTP queue delay threshold for a target rate RTP_QDELAY_TH (0.02s) RTP queue delay threshold for a target rate
reduction. reduction.
TARGET_RATE_SCALE_RTP_QDELAY (0.95) Target rate scale when RTP TARGET_RATE_SCALE_RTP_QDELAY (0.95) Target rate scale when RTP
qdelay threshold exceeds. qdelay threshold exceeds RTP_QDELAY_TH.
QDELAY_TREND_LO (0.2) Threshold value for qdelay_trend. QDELAY_TREND_LO (0.2) Threshold value for qdelay_trend.
T_RESUME_FAST_INCREASE (5s) Time span until fast increase can be T_RESUME_FAST_INCREASE (5s) Time span until fast increase can be
resumed, given that the qdelay_trend is below QDELAY_TREND_LO. resumed, given that the qdelay_trend is below QDELAY_TREND_LO.
RATE_PACE_MIN (50000bps) Minimum pacing rate. RATE_PACE_MIN (50000bps) Minimum pacing rate.
4.1.1.2. State variables 4.1.1.2. State variables
skipping to change at page 12, line 14 skipping to change at page 12, line 20
qdelay_trend (0.0) qdelay_trend (0.0)
qdelay trend, indicates incipient congestion. qdelay trend, indicates incipient congestion.
qdelay_trend_mem (0.0) qdelay_trend_mem (0.0)
Low pass filtered version of qdelay_trend. Low pass filtered version of qdelay_trend.
qdelay_norm_hist[100] ({0,..,0}) qdelay_norm_hist[100] ({0,..,0})
Vector of the last 100 normalized qdelay samples. Vector of the last 100 normalized qdelay samples.
min_cwnd (2*MSS)
Minimum congestion window.
in_fast_increase (true) in_fast_increase (true)
True if in fast increase state. True if in fast increase state.
cwnd (min_cwnd) cwnd (MIN_CWND)
Congestion window. Congestion window.
bytes_newly_acked (0) bytes_newly_acked (0)
The number of bytes that was acknowledged with the last received The number of bytes that was acknowledged with the last received
acknowledgement i.e. bytes acknowledged since the last CWND update. acknowledgement i.e. bytes acknowledged since the last CWND update.
max_bytes_in_flight (0)
The maximum number of bytes in flight over a sliding time window,
i.e. transmitted but not yet acknowledged bytes.
send_wnd (0) send_wnd (0)
Upper limit to how many bytes that can currently be transmitted. Upper limit to how many bytes that can currently be transmitted.
Updated when cwnd is updated and when RTP packet is transmitted. Updated when cwnd is updated and when RTP packet is transmitted.
target_bitrate (0 bps) target_bitrate (0 bps)
Media target bitrate. Media target bitrate.
target_bitrate_last_max (1 bps) target_bitrate_last_max (1 bps)
Media target bitrate inflection point i.e. the last known highest Media target bitrate inflection point i.e. the last known highest
target_bitrate. Used to limit bitrate increase speed close to the target_bitrate. Used to limit bitrate increase speed close to the
skipping to change at page 14, line 35 skipping to change at page 15, line 8
some smoothing occurs anyway as the computation of the CWND is a low some smoothing occurs anyway as the computation of the CWND is a low
pass filter function. A number of variables are updated as pass filter function. A number of variables are updated as
illustrated by the pseudo code below, temporary variables are illustrated by the pseudo code below, temporary variables are
appended with '_t'. Note that the pseudo code does not show all appended with '_t'. Note that the pseudo code does not show all
details for reasons of readability, the reader is encouraged to look details for reasons of readability, the reader is encouraged to look
into the C++ code in [SCReAM-CPP-implementation] for the details. into the C++ code in [SCReAM-CPP-implementation] for the details.
<CODE BEGINS> <CODE BEGINS>
update_variables(qdelay): update_variables(qdelay):
qdelay_fraction_t = qdelay/qdelay_target qdelay_fraction_t = qdelay/qdelay_target
#calculate moving average # Calculate moving average
qdelay_fraction_avg = (1-QDELAY_WEIGHT)*qdelay_fraction_avg+ qdelay_fraction_avg = (1-QDELAY_WEIGHT)*qdelay_fraction_avg+
QDELAY_WEIGHT*qdelay_fraction_t QDELAY_WEIGHT*qdelay_fraction_t
update_qdelay_fraction_hist(qdelay_fraction_t) update_qdelay_fraction_hist(qdelay_fraction_t)
# R is an autocorrelation function of qdelay_fraction_hist # Compute the average of the values in qdelay_fraction_hist
# at lag K avg_t = average(qdelay_fraction_hist)
a = R(qdelay_fraction_hist,1)/R(qdelay_fraction_hist,0) # R is an autocorrelation function of qdelay_fraction_hist,
#calculate qdelay trend # with the mean (DC component) removed, at lag K
qdelay_trend = min(1.0,max(0.0,a*qdelay_fraction_avg)) # The subtraction of the scalar avg_t from
#calculate a 'peak-hold' qdelay_trend, this gives a memory # qdelay_fraction_hist is performed element-wise
# of congestion in the past a_t = R(qdelay_fraction_hist-avg_t,1)/
R(qdelay_fraction_hist-avg_t,0)
# Calculate qdelay trend
qdelay_trend = min(1.0,max(0.0,a_t*qdelay_fraction_avg))
# Calculate a 'peak-hold' qdelay_trend, this gives a memory
# of congestion in the past
qdelay_trend_mem = max(0.99*qdelay_trend_mem, qdelay_trend) qdelay_trend_mem = max(0.99*qdelay_trend_mem, qdelay_trend)
<CODE ENDS> <CODE ENDS>
The qdelay fraction is sampled every 50ms and the last 20 samples are The qdelay fraction is sampled every 50ms and the last 20 samples are
stored in a vector (qdelay_fraction_hist). This vector is used in stored in a vector (qdelay_fraction_hist). This vector is used in
the computation of an qdelay trend that gives a value between 0.0 and the computation of an qdelay trend that gives a value between 0.0 and
1.0 depending on the estimated congestion level. The prediction 1.0 depending on the estimated congestion level. The prediction
coefficient 'a' has positive values if qdelay shows an increasing coefficient 'a_t' has positive values if qdelay shows an increasing
trend, thus an indication of congestion is obtained before the qdelay or decreasing trend, thus an indication of congestion is obtained
target is reached. before the qdelay target is reached. As a side effect, also the case
that qdelay decreases is taken as a sign of congestion, experiments
have however shown that this is beneficial as varying queue delay up
or down is an indication that the transmit rate is very close to the
path capacity.
The autocorrelation function 'R' is defined as follows. Let x be a The autocorrelation function 'R' is defined as follows. Let x be a
vector constituting N values, the biased autocorrelation function for vector constituting N values, the biased autocorrelation function for
a given lag=k for the vector x is given by. a given lag=k for the vector x is given by.
n=N-k n=N-k
R(x,k) = SUM x(n)*x(n+k) R(x,k) = SUM x(n)*x(n+k)
n=1 n=1
The prediction coefficient is further multiplied with The prediction coefficient is further multiplied with
skipping to change at page 16, line 23 skipping to change at page 17, line 10
The update of the congestion window depends on whether loss or ECN- The update of the congestion window depends on whether loss or ECN-
marking or neither occurs. The pseudo code below describes actions marking or neither occurs. The pseudo code below describes actions
taken in case of the different events. taken in case of the different events.
<CODE BEGINS> <CODE BEGINS>
on congestion event(qdelay): on congestion event(qdelay):
# Either loss or ECN mark is detected # Either loss or ECN mark is detected
in_fast_increase = false in_fast_increase = false
if (is loss) if (is loss)
# loss is detected # Loss is detected
cwnd = max(MIN_CWND,cwnd*BETA_LOSS) cwnd = max(MIN_CWND,cwnd*BETA_LOSS)
else else
# No loss, so it is then an ECN mark # No loss, so it is then an ECN mark
cwnd = max(MIN_CWND,cwnd*BETA_ECN) cwnd = max(MIN_CWND,cwnd*BETA_ECN)
end end
adjust_qdelay_target(qdelay) #compensating for competing flows adjust_qdelay_target(qdelay) #compensating for competing flows
calculate_send_window(qdelay,qdelay_target) calculate_send_window(qdelay,qdelay_target)
# when no congestion event # When no congestion event
on acknowledgement(qdelay): on acknowledgement(qdelay):
update_bytes_newly_acked() update_bytes_newly_acked()
update_cwnd(bytes_newly_acked) update_cwnd(bytes_newly_acked)
adjust_qdelay_target(qdelay) #compensating for competing flows adjust_qdelay_target(qdelay) #compensating for competing flows
calculate_send_window(qdelay, qdelay_target) calculate_send_window(qdelay, qdelay_target)
check_to_resume_fast_increase() check_to_resume_fast_increase()
<CODE ENDS> <CODE ENDS>
The methods are further described in detail below. The methods are further described in detail below.
The congestion window update is based on qdelay, except for the The congestion window update is based on qdelay, except for the
occurrence of loss events (one or more lost RTP packets in one RTT), occurrence of loss events (one or more lost RTP packets in one RTT),
or ECN events, which was described earlier. or ECN events, which was described earlier.
Pseudo code for the update of the congestion window is found below. Pseudo code for the update of the congestion window is found below.
<CODE BEGINS> <CODE BEGINS>
update_cwnd(bytes_newly_acked): update_cwnd(bytes_newly_acked):
# In fast increase ?
# in fast increase ?
if (in_fast_increase) if (in_fast_increase)
if (qdelay_trend >= QDELAY_TREND_TH) if (qdelay_trend >= QDELAY_TREND_TH)
# incipient congestion detected, exit fast increase # Incipient congestion detected, exit fast increase
in_fast_increase = false in_fast_increase = false
else else
# no congestion yet, increase cwnd if it # No congestion yet, increase cwnd if it
# is sufficiently used # is sufficiently used
# an additional slack of bytes_newly_acked is # An additional slack of bytes_newly_acked is
# added to ensure that CWND growth occurs # added to ensure that CWND growth occurs
# even when feedback is sparse # even when feedback is sparse
if (bytes_in_flight*1.5+bytes_newly_acked > cwnd) if (bytes_in_flight*1.5+bytes_newly_acked > cwnd)
cwnd = cwnd+bytes_newly_acked cwnd = cwnd+bytes_newly_acked
end end
return return
end end
end end
# not in fast increase phase # Not in fast increase phase
# off_target calculated as with LEDBAT # off_target calculated as with LEDBAT
off_target_t = (qdelay_target - qdelay) / qdelay_target off_target_t = (qdelay_target - qdelay) / qdelay_target
gain_t = GAIN gain_t = GAIN
# adjust congestion window # Adjust congestion window
cwnd_delta_t = cwnd_delta_t =
gain_t * off_target_t * bytes_newly_acked * MSS / cwnd gain_t * off_target_t * bytes_newly_acked * MSS / cwnd
if (off_target_t > 0 && if (off_target_t > 0 &&
bytes_in_flight*1.25+bytes_newly_acked <= cwnd) bytes_in_flight*1.25+bytes_newly_acked <= cwnd)
# no cwnd increase if window is underutilized # No cwnd increase if window is underutilized
# an additional slack of bytes_newly_acked is # An additional slack of bytes_newly_acked is
# added to ensure that CWND growth occurs # added to ensure that CWND growth occurs
# even when feedback is sparse # even when feedback is sparse
cwnd_delta_t = 0; cwnd_delta_t = 0;
end end
# apply delta # Apply delta
cwnd += cwnd_delta_t cwnd += cwnd_delta_t
# limit cwnd to the maximum number of bytes in flight # limit cwnd to the maximum number of bytes in flight
cwnd = min(cwnd, max_bytes_in_flight*MAX_BYTES_IN_FLIGHT_HEAD_ROOM) cwnd = min(cwnd, max_bytes_in_flight*MAX_BYTES_IN_FLIGHT_HEAD_ROOM)
cwnd = max(cwnd, MIN_CWND) cwnd = max(cwnd, MIN_CWND)
<CODE ENDS> <CODE ENDS>
CWND is updated differently depending on whether the congestion CWND is updated differently depending on whether the congestion
control is in fast increase state or not, as controlled by the control is in fast increase state or not, as controlled by the
variable in_fast_increase. variable in_fast_increase.
When in fast increase state, the congestion window is increased with When in fast increase state, the congestion window is increased with
the number of newly acknowledged bytes as long as the window is the number of newly acknowledged bytes as long as the window is
sufficiently used. Sparse feedback can potentially limit congestion sufficiently used. Sparse feedback can potentially limit congestion
window growth, an additional slack is therefore added, given by the window growth, an additional slack is therefore added, given by the
number of newly acknowledged bytes. number of newly acknowledged bytes.
skipping to change at page 18, line 24 skipping to change at page 19, line 21
The congestion window growth when in_fast_increase is false is The congestion window growth when in_fast_increase is false is
dictated by the relation between qdelay and qdelay_target, congestion dictated by the relation between qdelay and qdelay_target, congestion
window growth is limited if the window is not used sufficiently. window growth is limited if the window is not used sufficiently.
SCReAM calculates the GAIN in a similar way to what is specified in SCReAM calculates the GAIN in a similar way to what is specified in
[RFC6817]. However, [RFC6817] specifies that the CWND increase is [RFC6817]. However, [RFC6817] specifies that the CWND increase is
limited by an additional function controlled by a constant limited by an additional function controlled by a constant
ALLOWED_INCREASE. This additional limitation is removed in this ALLOWED_INCREASE. This additional limitation is removed in this
specification. specification.
Further the CWND is limited by max_bytes_in_flight and min_cwnd. The Further the CWND is limited by max_bytes_in_flight and MIN_CWND. The
limitation of the congestion window by the maximum number of bytes in limitation of the congestion window by the maximum number of bytes in
flight over the last 5 seconds (max_bytes_in_flight) avoids possible flight over the last 5 seconds (max_bytes_in_flight) avoids possible
over-estimation of the throughput after for example, idle periods. over-estimation of the throughput after for example, idle periods.
An additional MAX_BYTES_IN_FLIGHT_HEAD_ROOM allows for a slack, to An additional MAX_BYTES_IN_FLIGHT_HEAD_ROOM allows for a slack, to
allow for a certain amount of media coder output rate variability. allow for a certain amount of media coder output rate variability.
4.1.2.3. Competing flows compensation 4.1.2.3. Competing flows compensation
It is likely that a flow using SCReAM algorithm will have to share It is likely that a flow using SCReAM algorithm will have to share
congested bottlenecks with other flows that use a more aggressive congested bottlenecks with other flows that use a more aggressive
skipping to change at page 24, line 10 skipping to change at page 25, line 10
scale_t = max(0.2, min(1.0, (scale_t*4)^2)) scale_t = max(0.2, min(1.0, (scale_t*4)^2))
# min scale_t value 0.2 as the bitrate should be allowed to # min scale_t value 0.2 as the bitrate should be allowed to
# increase at least slowly --> avoid locking the rate to # increase at least slowly --> avoid locking the rate to
# target_bitrate_last_max # target_bitrate_last_max
if (in_fast_increase = true) if (in_fast_increase = true)
increment_t = ramp_up_speed_t*RATE_ADJUST_INTERVAL increment_t = ramp_up_speed_t*RATE_ADJUST_INTERVAL
increment_t *= scale_t increment_t *= scale_t
target_bitrate += increment_t target_bitrate += increment_t
else else
current_rate_t = max(rate_transmit, rate_ack) current_rate_t = max(rate_transmit, rate_ack)
# compute a bitrate change # Compute a bitrate change
delta_rate_t = current_rate_t*(1.0-PRE_CONGESTION_GUARD* delta_rate_t = current_rate_t*(1.0-PRE_CONGESTION_GUARD*
queue_delay_trend)-TX_QUEUE_SIZE_FACTOR *rtp_queue_size queue_delay_trend)-TX_QUEUE_SIZE_FACTOR *rtp_queue_size
# limit a positive increase if close to target_bitrate_last_max # Limit a positive increase if close to target_bitrate_last_max
if (delta_rate_t > 0) if (delta_rate_t > 0)
delta_rate_t *= scale_t delta_rate_t *= scale_t
delta_rate_t = delta_rate_t =
min(delta_rate_t,ramp_up_speed_t*RATE_ADJUST_INTERVAL) min(delta_rate_t,ramp_up_speed_t*RATE_ADJUST_INTERVAL)
end end
target_bitrate += delta_rate_t target_bitrate += delta_rate_t
# force a slight reduction in bitrate if RTP queue # Force a slight reduction in bitrate if RTP queue
# builds up # builds up
rtp_queue_delay_t = rtp_queue_size/current_rate_t rtp_queue_delay_t = rtp_queue_size/current_rate_t
if (rtp_queue_delay_t > RTP_QDELAY_TH) if (rtp_queue_delay_t > RTP_QDELAY_TH)
target_bitrate *= TARGET_RATE_SCALE_RTP_QDELAY target_bitrate *= TARGET_RATE_SCALE_RTP_QDELAY
end end
end end
rate_media_limit_t = rate_media_limit_t =
max(current_rate_t, max(rate_media,rtp_rate_median)) max(current_rate_t, max(rate_media,rtp_rate_median))
rate_media_limit_t *= (2.0-qdelay_trend_mem) rate_media_limit_t *= (2.0-qdelay_trend_mem)
skipping to change at page 27, line 36 skipping to change at page 28, line 36
RECOMMENDED that a SCReAM implementation follows the guidelines RECOMMENDED that a SCReAM implementation follows the guidelines
below. below.
The feedback interval depends on the media bitrate. At low bitrates The feedback interval depends on the media bitrate. At low bitrates
it is sufficient with a feedback interval of 100 to 400ms, while at it is sufficient with a feedback interval of 100 to 400ms, while at
high bitrates a feedback interval of roughly 20ms is to prefer, at high bitrates a feedback interval of roughly 20ms is to prefer, at
very high bitrates, even shorter feedback intervals MAY be needed in very high bitrates, even shorter feedback intervals MAY be needed in
order to keep the self-clocking in SCReAM working well. One piece of order to keep the self-clocking in SCReAM working well. One piece of
evidence of a too sparse feedback is that the SCReAM implementation evidence of a too sparse feedback is that the SCReAM implementation
cannot reach high bitrates, even in uncongested links. A more cannot reach high bitrates, even in uncongested links. A more
frequent feedback MAY solve this issue. frequent feedback might solve this issue.
The numbers above can be formulated as feedback interval function The numbers above can be formulated as feedback interval function
that can be useful for the computation of the desired RTCP bandwidth. that can be useful for the computation of the desired RTCP bandwidth.
The following equation expresses the feedback rate: The following equation expresses the feedback rate:
rate_fb = min(50,max(2.5,rate_media/10000)) rate_fb = min(50,max(2.5,rate_media/10000))
rate_media is the RTP media bitrate expressed in [bits/s], rate_fb is rate_media is the RTP media bitrate expressed in [bits/s], rate_fb is
the feedback rate expressed in [packets/s]. Converted to feedback the feedback rate expressed in [packets/s]. Converted to feedback
interval we get: interval we get:
skipping to change at page 31, line 51 skipping to change at page 32, line 51
least integrity protected. Furthermore, as SCReAM is self-clocked, a least integrity protected. Furthermore, as SCReAM is self-clocked, a
malicious middlebox can drop RTCP feedback packets and thus cause the malicious middlebox can drop RTCP feedback packets and thus cause the
self-clocking in SCReAM to stall. This attack is however mitigated self-clocking in SCReAM to stall. This attack is however mitigated
by the minimum send rate maintained by SCReAM when no feedback is by the minimum send rate maintained by SCReAM when no feedback is
received. received.
11. Change history 11. Change history
A list of changes: A list of changes:
o WG-11 to WG-12: Review comments from Joel Halbern and Mirja
o WG-10 to WG-11: Review comments from Mirja o WG-10 to WG-11: Review comments from Mirja
o WG-9 to WG-10: Minor edits o WG-9 to WG-10: Minor edits
o WG-08 to WG-09: Updated based shepherd review by Martin o WG-08 to WG-09: Updated based shepherd review by Martin
Stiemerling, Q-bit semantics are removed as this is superfluous Stiemerling, Q-bit semantics are removed as this is superfluous
for the moment. Pacing and RTCP considerations are moved up from for the moment. Pacing and RTCP considerations are moved up from
the appendix, FEC discussion moved to discussion section. the appendix, FEC discussion moved to discussion section.
o WG-07 to WG-08: Avoid draft expiry o WG-07 to WG-08: Avoid draft expiry
o WG-06 to WG-07: Updated based on WGLC review by David Hayes and o WG-06 to WG-07: Updated based on WGLC review by David Hayes and
skipping to change at page 34, line 8 skipping to change at page 35, line 8
[I-D.ietf-rmcat-wireless-tests] [I-D.ietf-rmcat-wireless-tests]
Sarker, Z., Johansson, I., Zhu, X., Fu, J., Tan, W., and Sarker, Z., Johansson, I., Zhu, X., Fu, J., Tan, W., and
M. Ramalho, "Evaluation Test Cases for Interactive Real- M. Ramalho, "Evaluation Test Cases for Interactive Real-
Time Media over Wireless Networks", draft-ietf-rmcat- Time Media over Wireless Networks", draft-ietf-rmcat-
wireless-tests-04 (work in progress), May 2017. wireless-tests-04 (work in progress), May 2017.
[I-D.ietf-tcpm-alternativebackoff-ecn] [I-D.ietf-tcpm-alternativebackoff-ecn]
Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst, Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst,
"TCP Alternative Backoff with ECN (ABE)", draft-ietf-tcpm- "TCP Alternative Backoff with ECN (ABE)", draft-ietf-tcpm-
alternativebackoff-ecn-01 (work in progress), May 2017. alternativebackoff-ecn-02 (work in progress), October
2017.
[I-D.ietf-tcpm-rack] [I-D.ietf-tcpm-rack]
Cheng, Y., Cardwell, N., and N. Dukkipati, "RACK: a time- Cheng, Y., Cardwell, N., and N. Dukkipati, "RACK: a time-
based fast loss detection algorithm for TCP", draft-ietf- based fast loss detection algorithm for TCP", draft-ietf-
tcpm-rack-02 (work in progress), March 2017. tcpm-rack-02 (work in progress), March 2017.
[LEDBAT-delay-impact] [LEDBAT-delay-impact]
"Assessing LEDBAT's Delay Impact, IEEE communications "Assessing LEDBAT's Delay Impact, IEEE communications
letters, vol. 17, no. 5, May 2013", May 2013, letters, vol. 17, no. 5, May 2013", May 2013,
<http://home.ifi.uio.no/michawe/research/publications/ <http://home.ifi.uio.no/michawe/research/publications/
 End of changes. 34 change blocks. 
64 lines changed or deleted 80 lines changed or added

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