draft-ietf-rmcat-scream-cc-04.txt   draft-ietf-rmcat-scream-cc-05.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: December 11, 2016 June 9, 2016 Expires: December 29, 2016 June 27, 2016
Self-Clocked Rate Adaptation for Multimedia Self-Clocked Rate Adaptation for Multimedia
draft-ietf-rmcat-scream-cc-04 draft-ietf-rmcat-scream-cc-05
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 LTE (Long simulated Internet bottleneck scenarios as well as in a LTE (Long
Term Evolution) system simulator and is shown to achieve both low Term Evolution) 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 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 December 11, 2016. This Internet-Draft will expire on December 29, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
3.2. Sender Transmission Control . . . . . . . . . . . . . . . 7 3.2. Sender Transmission Control . . . . . . . . . . . . . . . 7
3.3. Media Rate Control . . . . . . . . . . . . . . . . . . . 7 3.3. Media Rate Control . . . . . . . . . . . . . . . . . . . 7
4. Detailed Description of SCReAM . . . . . . . . . . . . . . . 8 4. Detailed Description of SCReAM . . . . . . . . . . . . . . . 8
4.1. SCReAM Sender . . . . . . . . . . . . . . . . . . . . . . 8 4.1. SCReAM Sender . . . . . . . . . . . . . . . . . . . . . . 8
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 . . . . . . . . . . . . . . . . . . . . 9
4.1.1.2. State variables . . . . . . . . . . . . . . . . . 10 4.1.1.2. State variables . . . . . . . . . . . . . . . . . 10
4.1.2. Network congestion control . . . . . . . . . . . . . 12 4.1.2. Network congestion control . . . . . . . . . . . . . 12
4.1.2.1. Congestion window update . . . . . . . . . . . . 15 4.1.2.1. Congestion window update . . . . . . . . . . . . 15
4.1.2.2. Competing flows compensation . . . . . . . . . . 17 4.1.2.2. Competing flows compensation . . . . . . . . . . 17
4.1.2.3. Lost packets detection . . . . . . . . . . . . . 18 4.1.2.3. Lost packets detection . . . . . . . . . . . . . 19
4.1.2.4. Send window calculation . . . . . . . . . . . . . 19 4.1.2.4. Send window calculation . . . . . . . . . . . . . 19
4.1.2.5. Resuming fast increase . . . . . . . . . . . . . 20 4.1.2.5. Resuming fast increase . . . . . . . . . . . . . 20
4.1.3. Media rate control . . . . . . . . . . . . . . . . . 20 4.1.3. Media rate control . . . . . . . . . . . . . . . . . 20
4.1.3.1. FEC and packet overhead considerations . . . . . 24 4.1.3.1. FEC and packet overhead considerations . . . . . 24
4.2. SCReAM Receiver . . . . . . . . . . . . . . . . . . . . . 24 4.2. SCReAM Receiver . . . . . . . . . . . . . . . . . . . . . 24
5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 24 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 24
6. Implementation status . . . . . . . . . . . . . . . . . . . . 24 6. Implementation status . . . . . . . . . . . . . . . . . . . . 25
6.1. OpenWebRTC . . . . . . . . . . . . . . . . . . . . . . . 25 6.1. OpenWebRTC . . . . . . . . . . . . . . . . . . . . . . . 25
6.2. A C++ Implementation of SCReAM . . . . . . . . . . . . . 26 6.2. A C++ Implementation of SCReAM . . . . . . . . . . . . . 26
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
9. Security Considerations . . . . . . . . . . . . . . . . . . . 26 9. Security Considerations . . . . . . . . . . . . . . . . . . . 27
10. Change history . . . . . . . . . . . . . . . . . . . . . . . 27 10. Change history . . . . . . . . . . . . . . . . . . . . . . . 27
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
11.1. Normative References . . . . . . . . . . . . . . . . . . 27 11.1. Normative References . . . . . . . . . . . . . . . . . . 28
11.2. Informative References . . . . . . . . . . . . . . . . . 28 11.2. Informative References . . . . . . . . . . . . . . . . . 28
Appendix A. Additional information . . . . . . . . . . . . . . . 30 Appendix A. Additional information . . . . . . . . . . . . . . . 30
A.1. Stream prioritization . . . . . . . . . . . . . . . . . . 30 A.1. Stream prioritization . . . . . . . . . . . . . . . . . . 30
A.2. Computation of autocorrelation function . . . . . . . . . 30 A.2. Computation of autocorrelation function . . . . . . . . . 31
A.3. Sender transmission control and packet pacing . . . . . . 31 A.3. Sender transmission control and packet pacing . . . . . . 31
A.4. RTCP feedback considerations . . . . . . . . . . . . . . 31 A.4. RTCP feedback considerations . . . . . . . . . . . . . . 31
A.4.1. Requirements on feedback elements . . . . . . . . . . 31 A.4.1. Requirements on feedback elements . . . . . . . . . . 31
A.4.2. Requirements on feedback intensity . . . . . . . . . 33 A.4.2. Requirements on feedback intensity . . . . . . . . . 33
A.5. Q-bit semantics (source quench) . . . . . . . . . . . . . 34 A.5. Q-bit semantics (source quench) . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
1. Introduction 1. Introduction
Congestion in the Internet occurs when the transmitted bitrate is Congestion in the Internet occurs when the transmitted bitrate is
skipping to change at page 4, line 50 skipping to change at page 4, line 50
packets and the timestamp of the RTP packet with the highest sequence packets and the timestamp of the RTP packet with the highest sequence
number back to the sender in feedback packets, the sender keeps a number back to the sender in feedback packets, the sender keeps a
list of transmitted packets, their respective sizes and the time they list of transmitted packets, their respective sizes and the time they
were transmitted. This information is used to determine the amount were transmitted. This information is used to determine the amount
of bytes that can be transmitted at any given time instant. A of bytes that can be transmitted at any given time instant. A
congestion window puts an upper limit on how many bytes can be in congestion window puts an upper limit on how many bytes can be in
flight, i.e transmitted but not yet acknowledged. All this flight, i.e transmitted but not yet acknowledged. All this
implements a congestion control that follows the packet conservation implements a congestion control that follows the packet conservation
principle. The fact that SCReAM follows the packet conservation principle. The fact that SCReAM follows the packet conservation
principle, makes it as safe to deploy as a congestion control principle, makes it as safe to deploy as a congestion control
algorithm for the internet as TCP and its most commonly used algorithm for the Internet as TCP and its most commonly used
congestion control algorithms is. No additional circuit breaker congestion control algorithms are. No additional circuit breaker
mechanisms are necessary with SCReAM as the ACK-clocking mechanisms are necessary with SCReAM as the ACK-clocking
automatically stops transmission when the acknowledgements no longer automatically falls back to a very low transmission rate (1 RTP
arrive at the sender. packet/200ms) when the acknowledgements no longer arrive at the
sender. Furthermore, high packet loss rates reduces the congestion
value to very low values and thus a low transmission rate.
The congestion window is determined in a way similar to LEDBAT The congestion window is determined in a way similar to LEDBAT
[RFC6817]. [RFC6817].
LEDBAT is a congestion control algorithm that uses send and receive LEDBAT is a congestion control algorithm that uses send and receive
timestamps to estimate the queuing delay along the transmission path. timestamps to estimate the queuing delay along the transmission path.
This information is used to adjust the congestion window. The use of This information is used to adjust the congestion window. The use of
LEDBAT ensures that the end-to-end latency is kept low. The basic LEDBAT ensures that the end-to-end latency is kept low. The basic
functionality is quite simple, there are however a few steps to take functionality is quite simple, there are however a few steps to take
to make the concept work with conversational media. In a few words to make the concept work with conversational media. In a few words
skipping to change at page 5, line 46 skipping to change at page 5, line 48
to TCP slowstart. The fast increase is exited when congestion is to TCP slowstart. The fast increase is exited when congestion is
detected. The fast increase state can however resume if the detected. The fast increase state can however resume if the
congestion level is low, this to enable a reasonably quick rate congestion level is low, this to enable a reasonably quick rate
increase in case link throughput increases. increase in case link throughput increases.
o A delay trend is computed for earlier detection of incipient o A delay trend is computed for earlier detection of incipient
congestion and as a result it reduces jitter. congestion and as a result it reduces jitter.
o Addition of a media rate control function. o Addition of a media rate control function.
o Use of inflection points to calculate congestion window and media o Use of inflection points in the media rate calculation to achieve
rate to achieve reduced jitter. reduced jitter.
o Adjustment of delay target for better performance when competing o Adjustment of delay target for better performance when competing
with other loss based congestion controlled flows. with other loss based congestion controlled flows.
The above mentioned features will be described in more detail in The above mentioned features will be described in more detail in
sections Section 3.1 to Section 3.3. sections Section 3.1 to Section 3.3.
+---------------------------+ +---------------------------+
| Media encoder | | Media encoder |
+---------------------------+ +---------------------------+
skipping to change at page 10, line 6 skipping to change at page 10, line 6
TARGET_BITRATE_MIN TARGET_BITRATE_MIN
Min target bitrate [bps]. Min target bitrate [bps].
TARGET_BITRATE_MAX TARGET_BITRATE_MAX
Max target bitrate [bps]. Max target bitrate [bps].
RAMP_UP_SPEED (200000bps/s) RAMP_UP_SPEED (200000bps/s)
Maximum allowed rate increase speed. Maximum allowed rate increase speed.
PRE_CONGESTION_GUARD (0.0..0.2) PRE_CONGESTION_GUARD (0.0..1.0)
Guard factor against early congestion onset. A higher value gives Guard factor against early congestion onset. A higher value gives
less jitter, possibly at the expense of a lower link utilization. less jitter, possibly at the expense of a lower link utilization.
This value may be subject to tuning depending on e.g media coder This value may be subject to tuning depending on e.g media coder
characteristics, experiments with H264 and VP8 have however given characteristics, experiments with H264 and VP8 have however given
that 0.1 is a suitable value. that 0.1 is a suitable value.
TX_QUEUE_SIZE_FACTOR (0.0..2.0) TX_QUEUE_SIZE_FACTOR (0.0..2.0)
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 have however given that 1.0 is a suitable value. with H264 and VP8 have however given that 1.0 is a suitable value.
RTP_QDELAY_TH (0.02s) RTP queue delay threshold for a target rate
reduction.
TARGET_RATE_SCALE_RTP_QDELAY (0.95) Target rate scale when RTP queue
delay threshold exceeded.
QDELAY_TREND_LO (0.2) Threshold value for qdelay_trend. QDELAY_TREND_LO (0.2) Threshold value for qdelay_trend.
T_RESUME_FAST_INCREASE Time span until fast increase can be resumed, T_RESUME_FAST_INCREASE Time span until fast increase can be resumed,
given that the qdelay_trend is below QDELAY_TREND_LO. given that the qdelay_trend is below QDELAY_TREND_LO.
4.1.1.2. State variables 4.1.1.2. State variables
qdelay_target (QDELAY_TARGET_LO) qdelay_target (QDELAY_TARGET_LO)
qdelay target, a variable qdelay target is introduced to manage qdelay target, a variable qdelay target is introduced to manage
cases where e.g. FTP competes for the bandwidth over the same cases where e.g. FTP competes for the bandwidth over the same
skipping to change at page 11, line 8 skipping to change at page 11, line 14
min_cwnd (2*MSS) min_cwnd (2*MSS)
Minimum congestion window. 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.
cwnd_last_max (1 byte)
Congestion window inflection point, i.e the last known highest
cwnd. Used to limit cwnd increase speed close to the last known
congestion point.
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.
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.
skipping to change at page 12, line 5 skipping to change at page 11, line 51
s_rtt (0.0s) s_rtt (0.0s)
Smoothed RTT [s], computed similar to method depicted in [RFC6298] Smoothed RTT [s], computed similar to method depicted in [RFC6298]
rtp_queue_size (0 bits) rtp_queue_size (0 bits)
Size of RTP packets in queue. Size of RTP packets in queue.
rtp_size (0 byte) rtp_size (0 byte)
Size of the last transmitted RTP packet. Size of the last transmitted RTP packet.
loss_event_rate (0.0)
The estimated fraction of RTTs with lost packets detected.
4.1.2. Network congestion control 4.1.2. Network congestion control
This section explains the network congestion control, it contains two This section explains the network congestion control, it contains two
main functions main functions
o Computation of congestion window at the sender: Gives an upper o Computation of congestion window at the sender: Gives an upper
limit to the number of bytes in flight i.e how many bytes that limit to the number of bytes in flight i.e how many bytes that
have been transmitted but not yet acknowledged. have been transmitted but not yet acknowledged.
o Calculation of send window at the sender: RTP packets are o Calculation of send window at the sender: RTP packets are
skipping to change at page 14, line 30 skipping to change at page 14, line 30
file transfer. To compensate for this it is necessary to let SCReAM file transfer. To compensate for this it is necessary to let SCReAM
reduce the congestion window slightly less than what is the case with reduce the congestion window slightly less than what is the case with
TCP when loss events occur. TCP when loss events occur.
An ECN event is detected if the n_ECN counter in the feedback report An ECN event is detected if the n_ECN counter in the feedback report
has increased since the previous received feedback. Once an ECN has increased since the previous received feedback. Once an ECN
event is detected, the n_ECN counter is ignored for a full smoothed event is detected, the n_ECN counter is ignored for a full smoothed
round trip time, the intention of this is to limit the congestion round trip time, the intention of this is to limit the congestion
window decrease to at most once per round trip. The congestion window decrease to at most once per round trip. The congestion
window backoff due to an ECN event is deliberately smaller than if a window backoff due to an ECN event is deliberately smaller than if a
loss event occurs. This is inline with the idea outlined in loss event occurs. This is in line with the idea outlined in
[Khademi_alternative_backoff_ECN] to enable ECN marking thresholds [Khademi_alternative_backoff_ECN] to enable ECN marking thresholds
lower than the corresponding packet drop thresholds. lower than the corresponding packet drop thresholds.
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.
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
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()
skipping to change at page 16, line 6 skipping to change at page 16, line 6
4.1.2.1. Congestion window update 4.1.2.1. Congestion window update
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.
update_cwnd(bytes_newly_acked): update_cwnd(bytes_newly_acked):
# additional scaling factor to slow down closer to target
# The min scale factor is 0.2 to avoid that the congestion window
# growth is stalled when cwnd is close to cwnd_last_max
scale_t = max(0.2,min(1.0,(4*(cwnd-cwnd_last_max)/cwnd_last_max)^2))
# in fast increase ? # in fast increase ?
if (in_fast_increase) if (in_fast_increase)
if (qdelay_trend >= 0.2) if (qdelay_trend >= 0.2)
# 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 # no congestion yet, increase cwnd if it
cwnd = cwnd+bytes_newly_acked*scale_t # is sufficiently used
if (bytes_in_flight*1.5 > cwnd)
cwnd = cwnd+bytes_newly_acked
end
return return
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 increase based on scale and qdelay_trend # adjust congestion window
if (off_target_t > 0) cwnd_delta_t =
gain_t *= max(0.0, (1 - qdelay_trend/ 0.2)) * scale_t gain_t * off_target_t * bytes_newly_acked * MSS / cwnd
if (off_target_t > 0 && bytes_in_flight*1.25 <= cwnd)
# no cwnd increase if window is underutilized
cwnd_delta_t = 0;
end
# increase/decrease the congestion window # apply delta
# off_target can be positive or negative cwnd += cwnd_delta_t
cwnd += gain_t * off_target_t * bytes_newly_acked * MSS / cwnd # 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)
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 scaled by a scale factor that the number of newly acknowledged bytes as long as the window is
depends on the relation between CWND and the last known maximum value sufficiently used.
of CWND (cwnd_last_max).
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, also here dictated by the relation between qdelay and qdelay_target, congestion
a scale factor is applied to limit the congestion window growth when window growth is limited if the window is not used sufficiently.
cwnd gets close to cwnd_last_max, cwnd_last_max is updated when
congestion is detected. The scale factor makes the congestion window
grow in a similar way as is the case with the Cubic congestion
control algorithm i.e a slow increase around the last known maximum
value.
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]. There are however a few differences. [RFC6817]. There are however a few differences.
o [RFC6817] specifies a constant GAIN, this specification however o [RFC6817] specifies a constant GAIN, this specification however
limits the gain when CWND is increased dependent on near limits the gain when CWND is increased dependent on near
congestion state and the relation to the last known max CWND congestion state and the relation to the last known max CWND
value. value.
o [RFC6817] specifies that the CWND increase is limited by an o [RFC6817] specifies that the CWND increase is limited by an
skipping to change at page 18, line 9 skipping to change at page 18, line 9
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
congestion control algorithm. SCReAM takes care of such situations congestion control algorithm. SCReAM takes care of such situations
by adjusting the qdelay_target. by adjusting the qdelay_target.
adjust_qdelay_target(qdelay) adjust_qdelay_target(qdelay)
qdelay_norm_t = qdelay / QDELAY_TARGET_LOW qdelay_norm_t = qdelay / QDELAY_TARGET_LOW
update_qdelay_norm_history(qdelay_norm_t) update_qdelay_norm_history(qdelay_norm_t)
# Compute variance # Compute variance
qdelay_norm_var_t = VARIANCE(qdelay_norm_history(100)) qdelay_norm_var_t = VARIANCE(qdelay_norm_history(200))
# Compensation for competing traffic # Compensation for competing traffic
# Compute average # Compute average
qdelay_norm_avg_t = AVERAGE(qdelay_norm_history(50)) qdelay_norm_avg_t = AVERAGE(qdelay_norm_history(50))
# Compute upper limit to target delay # Compute upper limit to target delay
oh_t = qdelay_norm_avg_t + oh_t = qdelay_norm_avg_t + sqrt(qdelay_norm_var_t)
min(qdelay_norm_avg_t/2,sqrt(qdelay_norm_var_t))*2.0
oh_t *= QDELAY_TARGET_LO oh_t *= QDELAY_TARGET_LO
if (qdelay_norm_var_t < 0.2) if (loss_event_rate > 0.002)
# Reasonably safe to set target qdelay # Packet losses detected
qdelay_target = oh_t qdelay_target = 1.5*oh_t
else else
# Check if target delay can be reduced, this helps to avoid if (qdelay_norm_var_t < 0.2)
# that the target delay is locked to high values for ever # Reasonably safe to set target qdelay
if (oh_t < QDELAY_TARGET_LO) qdelay_target = oh_t
# Decrease target delay quickly as measured queueing
# delay is lower than target
qdelay_target = max(qdelay_target*0.5,oh_t)
else else
# Decrease target delay slowly # Check if target delay can be reduced, this helps to avoid
qdelay_target *= 0.9 # that the target delay is locked to high values for ever
if (oh_t < QDELAY_TARGET_LO)
# Decrease target delay quickly as measured queueing
# delay is lower than target
qdelay_target = max(qdelay_target*0.5,oh_t)
else
# Decrease target delay slowly
qdelay_target *= 0.9
end
end
end
# Apply limits # Apply limits
qdelay_target = min(QDELAY_TARGET_HI, qdelay_target) qdelay_target = min(QDELAY_TARGET_HI, qdelay_target)
qdelay_target = max(QDELAY_TARGET_LO, qdelay_target) qdelay_target = max(QDELAY_TARGET_LO, qdelay_target)
The qdelay_target is adjusted differently, depending on if The qdelay_target is adjusted differently, depending on if
qdelay_norm_var_t is above or below a given value. qdelay_norm_var_t is above or below a given value.
A low qdelay_norm_avg_t value indicates that the qdelay does not A low qdelay_norm_avg_t value indicates that the qdelay does not
change rapidly. It is desired avoid the case that the qdelay target change rapidly. It is desired avoid the case that the qdelay target
is increased due to self-congestion, indicated by a changing qdelay is increased due to self-congestion, indicated by a changing qdelay
and consequently an increased qdelay_norm_var_t. Still it should be and consequently an increased qdelay_norm_var_t. Still it should be
possible to increase the qdelay target if the qdelay continues to be possible to increase the qdelay target if the qdelay continues to be
high. This is a simple function with a certain risk of both false high. This is a simple function with a certain risk of both false
positives and negatives but it manages competing FTP flows reasonably positives and negatives but it manages competing FTP flows reasonably
well at the same time as it has proven to avoid accidental increased well at the same time as it has proven to avoid accidental increased
qdelay target in simulated LTE test cases. qdelay target relatively well in simulated LTE test cases.
4.1.2.3. Lost packets detection 4.1.2.3. Lost packets detection
Lost packets detection is based on the received sequence number list. Lost packets detection is based on the received sequence number list.
A reordering window should be applied to avoid that packet reordering A reordering window should be applied to avoid that packet reordering
triggers loss events. triggers loss events.
The reordering window is specified as a time unit, similar to the The reordering window is specified as a time unit, similar to the
ideas behind RACK (Recent ACKnowledgement) [RACK]. The computation ideas behind RACK (Recent ACKnowledgement) [RACK]. The computation
of the reordering window is made possible by means of a lost flag in of the reordering window is made possible by means of a lost flag in
the list of transmitted RTP packets. This flag is set if the the list of transmitted RTP packets. This flag is set if the
received sequence number list indicates that the given RTP packet is received sequence number list indicates that the given RTP packet is
missing. If a later feedback indicates that a previously lost marked missing. If a later feedback indicates that a previously lost marked
packet was indeed received, then the reordering window is updated to packet was indeed received, then the reordering window is updated to
reflect the reordering delay. The reordering window is given by the reflect the reordering delay. The reordering window is given by the
difference in time between the event that the packet was marked as difference in time between the event that the packet was marked as
lost and the event that it was indicated as successfully received. lost and the event that it was indicated as successfully received.
skipping to change at page 20, line 11 skipping to change at page 20, line 17
The send window is given by the relation between the adjusted The send window is given by the relation between the adjusted
congestion window and the amount of bytes in flight according to the congestion window and the amount of bytes in flight according to the
pseudo code below. pseudo code below.
calculate_send_window(qdelay, qdelay_target) calculate_send_window(qdelay, qdelay_target)
# send window is computed differently depending on congestion level # send window is computed differently depending on congestion level
if (qdelay <= qdelay_target) if (qdelay <= qdelay_target)
send_wnd = cwnd+MSS-bytes_in_flight send_wnd = cwnd+MSS-bytes_in_flight
else else
send_wnd = cwnd-bytes_in_flight send_wnd = cwnd-bytes_in_flight
end
The send window is updated whenever an RTP packet is transmitted or The send window is updated whenever an RTP packet is transmitted or
an RTCP feedback messaged is received. More details around sender an RTCP feedback messaged is received. More details around sender
transmission control and packet pacing is found in Appendix A.3. transmission control and packet pacing is found in Appendix A.3.
4.1.2.5. Resuming fast increase 4.1.2.5. Resuming fast increase
Fast increase can resume in order to speed up the bitrate increase in Fast increase can resume in order to speed up the bitrate increase in
case congestion abates. The condition to resume fast increase case congestion abates. The condition to resume fast increase
(in_fast_increase = true) is that qdelay_trend is less than (in_fast_increase = true) is that qdelay_trend is less than
skipping to change at page 22, line 12 skipping to change at page 22, line 12
The rate change behavior depends on whether a loss event has occurred The rate change behavior depends on whether a loss event has occurred
and if the congestion control is in fast increase or not. and if the congestion control is in fast increase or not.
# The target_bitrate is updated at a regular interval according # The target_bitrate is updated at a regular interval according
# to RATE_ADJUST_INTERVAL # to RATE_ADJUST_INTERVAL
on loss: on loss:
target_bitrate = max(BETA_R* target_bitrate, TARGET_BITRATE_MIN) target_bitrate = max(BETA_R* target_bitrate, TARGET_BITRATE_MIN)
exit exit
ramp_up_speed_t = min(RAMP_UP_SPEED, target_bitrate) ramp_up_speed_t = min(RAMP_UP_SPEED, target_bitrate/2.0)
if (in_fast_increase = true) scale_t = (target_bitrate - target_bitrate_last_max)/
scale_t = (target_bitrate - target_bitrate_last_max)/
target_bitrate_last_max target_bitrate_last_max
increment_t = ramp_up_speed_t*RATE_ADJUST_INTERVAL* scale_t = max(0.2, min(1.0, (scale_t*4)^2))
(1.0-min(1.0, qdelay_trend/0.2)) # min scale_t value 0.2 as the bitrate should be allowed to
# Value 0.2 as the bitrate should be allowed to increase # increase at least slowly --> avoid locking the rate to
# at least slowly --> avoid locking the rate to # target_bitrate_last_max
# target_bitrate_last_max if (in_fast_increase = true)
increment_t *= max(0.2, min(1.0, (scale_t*4)^2)) increment_t = ramp_up_speed_t*RATE_ADJUST_INTERVAL
increment_t *= scale_t
target_bitrate += increment_t target_bitrate += increment_t
target_bitrate *= (1.0- PRE_CONGESTION_GUARD*qdelay_trend)
else else
current_rate_t = max(rate_transmit, rate_ack) current_rate_t = max(rate_transmit, rate_ack)
pre_congestion_t = min(1.0, max(0.0, qdelay_fraction_avg-0.3)/0.7) # compute a bitrate change
pre_congestion_t += qdelay_trend delta_rate_t = current_rate_t*(1.0-PRE_CONGESTION_GUARD*
target_bitrate = current_rate_t*(1.0-PRE_CONGESTION_GUARD* queue_delay_trend)-TX_QUEUE_SIZE_FACTOR *rtp_queue_size
pre_congestion_t)-TX_QUEUE_SIZE_FACTOR *rtp_queue_size # limit a positive increase if close to target_bitrate_last_max
if (delta_rate_t > 0)
delta_rate_t *= scale_t
delta_rate_t =
min(delta_rate_t,ramp_up_speed_t*RATE_ADJUST_INTERVAL)
end
target_bitrate += delta_rate_t
# force a slight reduction in bitrate if RTP queue
# builds up
rtp_queue_delay_t = rtp_queue_size/current_rate_t
if (rtp_queue_delay_t > 0.02)
target_bitrate *= 0.95
end
end end
rate_media_limit_t = max(current_rate_t, max(rate_media,rtp_rate_median)) rate_media_limit_t = max(current_rate_t, max(rate_media,rtp_rate_median))
rate_media_limit_t *= (2.0-1.0*qdelay_trend_mem) rate_media_limit_t *= (2.0-1.0*qdelay_trend_mem)
target_bitrate = min(target_bitrate, rate_media_limit_t) target_bitrate = min(target_bitrate, rate_media_limit_t)
target_bitrate = min(TARGET_BITRATE_MAX, target_bitrate = min(TARGET_BITRATE_MAX,
max(TARGET_BITRATE_MIN,target_bitrate)) max(TARGET_BITRATE_MIN,target_bitrate))
In case of a loss event the target_bitrate is updated and the rate In case of a loss event the target_bitrate is updated and the rate
change procedure is exited. Otherwise the rate change procedure change procedure is exited. Otherwise the rate change procedure
skipping to change at page 23, line 10 skipping to change at page 23, line 21
warranted. warranted.
The rate update frequency is limited by RATE_ADJUST_INTERVAL, unless The rate update frequency is limited by RATE_ADJUST_INTERVAL, unless
a loss event occurs. The value is based on experimentation with real a loss event occurs. The value is based on experimentation with real
life limitations in video coders taken into account. A too short life limitations in video coders taken into account. A too short
interval has shown to make the video coder internal rate control loop interval has shown to make the video coder internal rate control loop
more unstable, a too long interval makes the overall congestion more unstable, a too long interval makes the overall congestion
control sluggish. control sluggish.
When in fast increase state (in_fast_increase=true), the bitrate When in fast increase state (in_fast_increase=true), the bitrate
increase is given by the desired ramp-up speed (RAMP_UP_SPEED) and is increase is given by the desired ramp-up speed (RAMP_UP_SPEED) . The
limited by the relation between the current bitrate and the last ramp-up speed is limited when the target bitrate is low to avoid rate
known max bitrate. The ramp-up speed is limited when the target oscillation at low bottleneck bitrates. The setting of RAMP_UP_SPEED
bitrate is low to avoid rate oscillation at low bottleneck bitrates. depends on preferences, a high setting such as 1000kbps/s makes it
Furthermore an increased qdelay trend limits the bitrate increase, an possible to quickly get high quality media, this is however at the
allowed increment is computed based on the congestion level (given by expense of a higher risk of jitter, which can manifest itself as e.g.
qdelay_trend) and the relation to target_bitrate_last_max. The choppy video rendering.
target_bitrate is reduced if congestion is detected. The setting of
RAMP_UP_SPEED depends on preferences, a high setting such as
1000kbps/s makes it possible to quickly get high quality media, this
is however at the expense of a higher risk of jitter, which can
manifest itself as e.g. choppy video rendering.
When in_fast_increase is false, the bitrate increase is given by the When in_fast_increase is false, the bitrate increase is given by the
current bitrate and is also controlled by the estimated RTP queue and current bitrate and is also controlled by the estimated RTP queue and
the qdelay trend, thus it is sufficient that an increased congestion the qdelay trend, thus it is sufficient that an increased congestion
level is sensed by the network congestion control to limit the level is sensed by the network congestion control to limit the
bitrate. The target_bitrate_last_max is updated when congestion is bitrate. The target_bitrate_last_max is updated when congestion is
detected. Additionally, a pre-congestion indicator is computed and detected.
the rate is adjusted accordingly.
In cases where input stimuli to the media encoder is static, for In cases where input stimuli to the media encoder is static, for
instance in "talking head" scenarios, the target bitrate is not instance in "talking head" scenarios, the target bitrate is not
always fully utilized. This may cause undesirable oscillations in always fully utilized. This may cause undesirable oscillations in
the target bitrate in the cases where the link throughput is limited the target bitrate in the cases where the link throughput is limited
and the media coder input stimuli changes between static and varying. and the media coder input stimuli changes between static and varying.
To overcome this issue, the target bitrate is capped to be less than To overcome this issue, the target bitrate is capped to be less than
a given multiplier of a median value of the history of media coder a given multiplier of a median value of the history of media coder
output bitrates, rate_media_limit. A multiplier is applied to output bitrates, rate_media_limit. A multiplier is applied to
rate_media_limit, depending on congestion history. The rate_media_limit, depending on congestion history. The
target_bitrate is then limited by this rate_media_limit. target_bitrate is then limited by this rate_media_limit.
Finally the target_bitrate is enforced to be within the defined min Finally the target_bitrate is enforced to be within the defined min
and max values. and max values.
The aware reader may notice the dependency on the qdelay in the The aware reader may notice the dependency on the qdelay in the
computation of the target bitrate, this manifests itself in the use computation of the target bitrate, this manifests itself in the use
of the qdelay_trend and qdelay_fraction_avg. As these parameters are of the qdelay_trend. As these parameters are used also in the
used also in the network congestion control one may suspect some odd network congestion control one may suspect some odd interaction
interaction between the media rate control and the network congestion between the media rate control and the network congestion control,
control, this is in fact the case if the parameter this is in fact the case if the parameter PRE_CONGESTION_GUARD is set
PRE_CONGESTION_GUARD is set to a high value. The use of qdelay_trend to a high value. The use of qdelay_trend in the media rate control
and qdelay_fraction_avg in the media rate control is solely to reduce is solely to reduce jitter, the dependency can be removed by setting
jitter, the dependency can be removed by setting
PRE_CONGESTION_GUARD=0, the effect is a somewhat faster rate increase PRE_CONGESTION_GUARD=0, the effect is a somewhat faster rate increase
at the expense of more jitter. after congestion, at the expense of more jitter.
4.1.3.1. FEC and packet overhead considerations 4.1.3.1. FEC and packet overhead considerations
The target bitrate given by SCReAM depicts the bitrate including RTP The target bitrate given by SCReAM depicts the bitrate including RTP
and FEC overhead. Therefore it is necessary that the media encoder and FEC overhead. Therefore it is necessary that the media encoder
takes this overhead into account when the media bitrate is set. This takes this overhead into account when the media bitrate is set. This
means that the media coder bitrate should be computed as means that the media coder bitrate should be computed as
media_rate = target_bitrate - rtp_plus_fec_overhead_bitrate media_rate = target_bitrate - rtp_plus_fec_overhead_bitrate
It is not strictly necessary to make a 100% perfect compensation for It is not strictly necessary to make a 100% perfect compensation for
the overhead as the SCReAM algorithm will inherently compensate the overhead as the SCReAM algorithm will inherently compensate
moderate errors. Under-compensation for the overhead has the effect moderate errors. Under-compensation of the overhead has the effect
that the jitter will increase somewhat while overcompensation will that the jitter will increase somewhat while overcompensation will
have the effect that the bottleneck link becomes under-utilized. have the effect that the bottleneck link becomes under-utilized.
4.2. SCReAM Receiver 4.2. SCReAM Receiver
The simple task of the SCReAM receiver is to feedback The simple task of the SCReAM receiver is to feedback
acknowledgements of received packets and total ECN count to the acknowledgements of received packets and total ECN count to the
SCReAM sender, in addition, the receive time of the RTP packet with SCReAM sender, in addition, the receive time of the RTP packet with
the highest sequence number is echoed back. Upon reception of each the highest sequence number is echoed back. Upon reception of each
RTP packet the receiver will simply maintain enough information to RTP packet the receiver will simply maintain enough information to
skipping to change at page 26, line 14 skipping to change at page 26, line 21
o Contact : irc://chat.freenode.net/openwebrtc o Contact : irc://chat.freenode.net/openwebrtc
6.2. A C++ Implementation of SCReAM 6.2. A C++ Implementation of SCReAM
o Organization : Ericsson Research, Ericsson. o Organization : Ericsson Research, Ericsson.
o Name : SCReAM. o Name : SCReAM.
o Implementation link : A C++ implementation of SCReAM is also o Implementation link : A C++ implementation of SCReAM is also
available [SCReAM-Cplusplus_Implementation] The code includes full available [SCReAM-Cplusplus_Implementation]The code includes full
support for congestion control, rate control and multi stream support for congestion control, rate control and multi stream
handling, it can be integrated in web clients given the addition handling, it can be integrated in web clients given the addition
of extra code to implement the RTCP feedback and RTP queue(s). of extra code to implement the RTCP feedback and RTP queue(s).
The code also includes a rudimentary implementation of a The code also includes a rudimentary implementation of a
simulator. The current implementation use an n_loss counter for simulator.
lost packets indication, this is subject to change in later
versions to a list of received RTP packets.
o Coverage : The code implements [I-D.ietf-rmcat-scream-cc] o Coverage : The code implements [I-D.ietf-rmcat-scream-cc]
o Contact : ingemar.s.johansson@ericsson.com o Contact : ingemar.s.johansson@ericsson.com
7. Acknowledgements 7. Acknowledgements
We would like to thank the following persons for their comments, We would like to thank the following persons for their comments,
questions and support during the work that led to this memo: Markus questions and support during the work that led to this memo: Markus
Andersson, Bo Burman, Tomas Frankkila, Frederic Gabin, Laurits Hamm, Andersson, Bo Burman, Tomas Frankkila, Frederic Gabin, Laurits Hamm,
Hans Hannu, Nikolas Hermanns, Stefan Haakansson, Erlendur Karlsson, Hans Hannu, Nikolas Hermanns, Stefan Haakansson, Erlendur Karlsson,
Daniel Lindstroem, Mats Nordberg, Jonathan Samuelsson, Rickard Daniel Lindstroem, Mats Nordberg, Jonathan Samuelsson, Rickard
Sjoeberg, Robert Swain, Magnus Westerlund, Stefan Aalund. Many Sjoeberg, Robert Swain, Magnus Westerlund, Stefan Aalund. Many
additional thanks to RMCAT chairs Karen and Mirja for patiently additional thanks to RMCAT chairs Karen and Mirja for patiently
reading, suggesting improvements and also for asking all the reading, suggesting improvements and also for asking all the
difficult but necessary questions. Thanks to Stefan Holmer and difficult but necessary questions. Thanks to Stefan Holmer and
Xiaoqing Zhu for the review. Xiaoqing Zhu for the review. Thanks to Ralf Globisch for taking time
to try out SCReAM in his challenging low bitrate use cases.
8. IANA Considerations 8. IANA Considerations
A new RFC4585 transport layer feedback message needs to be A new RFC4585 transport layer feedback message needs to be
standardized. standardized.
9. Security Considerations 9. Security Considerations
The feedback can be vulnerable to attacks similar to those that can The feedback can be vulnerable to attacks similar to those that can
affect TCP. It is therefore recommended that the RTCP feedback is at affect TCP. It is therefore recommended that the RTCP feedback is at
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. self-clocking in SCReAM to stall.
10. Change history 10. Change history
A list of changes: A list of changes:
o WG-03 to WG-04: Editorial fixes, ready for WGLC? o WG-04 to WG-05: Congestion control and rate control simplified
somewhat
o WG-03 to WG-04: Editorial fixes
o WG-02 to WG-03: Review comments from Stefan Holmer and Xiaoqing o WG-02 to WG-03: Review comments from Stefan Holmer and Xiaoqing
Zhu addressed, owd changed to qdelay for clarity. Added appendix Zhu addressed, owd changed to qdelay for clarity. Added appendix
section with RTCP feedback requirements, including a suggested section with RTCP feedback requirements, including a suggested
basic feedback format based Loss RLE report block and the Packet basic feedback format based Loss RLE report block and the Packet
Receipt Times blocks in [RFC3611]. Loss detection added as a Receipt Times blocks in [RFC3611]. Loss detection added as a
section. Transmission scheduling and packet pacing explained in section. Transmission scheduling and packet pacing explained in
appendix. Source quench semantics added to appendix. appendix. Source quench semantics added to appendix.
o WG-01 to WG-02: Complete restructuring of the document. Moved o WG-01 to WG-02: Complete restructuring of the document. Moved
skipping to change at page 29, line 7 skipping to change at page 29, line 12
Applications", draft-ietf-rmcat-cc-codec-interactions-02 Applications", draft-ietf-rmcat-cc-codec-interactions-02
(work in progress), March 2016. (work in progress), March 2016.
[I-D.ietf-rmcat-coupled-cc] [I-D.ietf-rmcat-coupled-cc]
Islam, S., Welzl, M., and S. Gjessing, "Coupled congestion Islam, S., Welzl, M., and S. Gjessing, "Coupled congestion
control for RTP media", draft-ietf-rmcat-coupled-cc-02 control for RTP media", draft-ietf-rmcat-coupled-cc-02
(work in progress), April 2016. (work in progress), April 2016.
[I-D.ietf-rmcat-scream-cc] [I-D.ietf-rmcat-scream-cc]
Johansson, I. and Z. Sarker, "Self-Clocked Rate Adaptation Johansson, I. and Z. Sarker, "Self-Clocked Rate Adaptation
for Multimedia", draft-ietf-rmcat-scream-cc-03 (work in for Multimedia", draft-ietf-rmcat-scream-cc-04 (work in
progress), February 2016. progress), June 2016.
[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-02 (work in progress), May 2016. wireless-tests-02 (work in progress), May 2016.
[Khademi_alternative_backoff_ECN] [Khademi_alternative_backoff_ECN]
"TCP Alternative Backoff with ECN (ABE)", "TCP Alternative Backoff with ECN (ABE)",
<https://tools.ietf.org/html/draft-khademi- <https://tools.ietf.org/html/draft-khademi-
 End of changes. 46 change blocks. 
106 lines changed or deleted 123 lines changed or added

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