draft-ietf-rmcat-scream-cc-12.txt   draft-ietf-rmcat-scream-cc-13.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 26, 2018 October 23, 2017 Expires: April 29, 2018 October 26, 2017
Self-Clocked Rate Adaptation for Multimedia Self-Clocked Rate Adaptation for Multimedia
draft-ietf-rmcat-scream-cc-12 draft-ietf-rmcat-scream-cc-13
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 interactive video. The solution conforms to
conservation principle and uses a hybrid loss and delay based the packet conservation principle and uses a hybrid loss and delay
congestion control algorithm. The algorithm is evaluated over both based congestion control algorithm. The algorithm is evaluated over
simulated Internet bottleneck scenarios as well as in a Long Term both simulated Internet bottleneck scenarios as well as in a Long
Evolution (LTE) system simulator and is shown to achieve both low Term Evolution (LTE) system simulator and is shown to achieve both
latency and high video throughput in these scenarios. low latency and high video throughput in these scenarios.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 26, 2018. This Internet-Draft will expire on April 29, 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 27 skipping to change at page 2, line 27
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 . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . 16 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 . . . . . . . . . . 19 4.1.2.3. Competing flows compensation . . . . . . . . . . 19
4.1.2.4. Lost packet detection . . . . . . . . . . . . . . 21 4.1.2.4. Lost packet detection . . . . . . . . . . . . . . 21
4.1.2.5. Send window calculation . . . . . . . . . . . . . 21 4.1.2.5. Send window calculation . . . . . . . . . . . . . 22
4.1.2.6. Packet pacing . . . . . . . . . . . . . . . . . . 22 4.1.2.6. Packet pacing . . . . . . . . . . . . . . . . . . 23
4.1.2.7. Resuming fast increase . . . . . . . . . . . . . 23 4.1.2.7. Resuming fast increase . . . . . . . . . . . . . 23
4.1.2.8. Stream prioritization . . . . . . . . . . . . . . 23 4.1.2.8. Stream prioritization . . . . . . . . . . . . . . 23
4.1.3. Media rate control . . . . . . . . . . . . . . . . . 23 4.1.3. Media rate control . . . . . . . . . . . . . . . . . 24
4.2. SCReAM Receiver . . . . . . . . . . . . . . . . . . . . . 26 4.2. SCReAM Receiver . . . . . . . . . . . . . . . . . . . . . 27
4.2.1. Requirements on feedback elements . . . . . . . . . . 26 4.2.1. Requirements on feedback elements . . . . . . . . . . 27
4.2.2. Requirements on feedback intensity . . . . . . . . . 28 4.2.2. Requirements on feedback intensity . . . . . . . . . 29
5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 29 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 29
6. Implementation status . . . . . . . . . . . . . . . . . . . . 30 6. Implementation status . . . . . . . . . . . . . . . . . . . . 30
6.1. OpenWebRTC . . . . . . . . . . . . . . . . . . . . . . . 30 6.1. OpenWebRTC . . . . . . . . . . . . . . . . . . . . . . . 31
6.2. A C++ Implementation of SCReAM . . . . . . . . . . . . . 31 6.2. A C++ Implementation of SCReAM . . . . . . . . . . . . . 31
7. Suggested experiments . . . . . . . . . . . . . . . . . . . . 31 7. Suggested experiments . . . . . . . . . . . . . . . . . . . . 32
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
10. Security Considerations . . . . . . . . . . . . . . . . . . . 32 10. Security Considerations . . . . . . . . . . . . . . . . . . . 33
11. Change history . . . . . . . . . . . . . . . . . . . . . . . 32 11. Change history . . . . . . . . . . . . . . . . . . . . . . . 33
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
12.1. Normative References . . . . . . . . . . . . . . . . . . 34 12.1. Normative References . . . . . . . . . . . . . . . . . . 35
12.2. Informative References . . . . . . . . . . . . . . . . . 34 12.2. Informative References . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
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 3, line 31 skipping to change at page 3, line 31
operate over a large range in channel capacity. This memo describes operate over a large range in channel capacity. This memo describes
SCReAM (Self-Clocked Rate Adaptation for Multimedia), a solution that SCReAM (Self-Clocked Rate Adaptation for Multimedia), a solution that
implements congestion control for RTP streams [RFC3550]. While implements congestion control for RTP streams [RFC3550]. While
SCReAM was originally devised for WebRTC (Web Real-Time SCReAM was originally devised for WebRTC (Web Real-Time
Communication) [RFC7478], it can also be used for other applications Communication) [RFC7478], it can also be used for other applications
where congestion control of RTP streams is necessary. SCReAM is where congestion control of RTP streams is necessary. SCReAM is
based on the self-clocking principle of TCP and uses techniques based on the self-clocking principle of TCP and uses techniques
similar to what is used in the LEDBAT based rate adaptation algorithm similar to what is used in the LEDBAT based rate adaptation algorithm
[RFC6817]. SCReAM is not entirely self-clocked as it augments self- [RFC6817]. SCReAM is not entirely self-clocked as it augments self-
clocking with pacing and a minimum send rate. clocking with pacing and a minimum send rate.
SCReAM can take advantage of ECN (Explicit Congestion Notification)
in cases where ECN is supported by the network and the hosts. ECN is
however not required for the basic congestion control functionality
in SCReAM.
1.1. Wireless (LTE) access properties 1.1. Wireless (LTE) access properties
[I-D.ietf-rmcat-wireless-tests] describes the complications that can [I-D.ietf-rmcat-wireless-tests] describes the complications that can
be observed in wireless environments. Wireless access such as LTE be observed in wireless environments. Wireless access such as LTE
can typically not guarantee a given bandwidth, this is true can typically not guarantee a given bandwidth, this is true
especially for default bearers. The network throughput can vary especially for default bearers. The network throughput can vary
considerably for instance in cases where the wireless terminal is considerably for instance in cases where the wireless terminal is
moving around. Even though LTE can support bitrates well above moving around. Even though LTE can support bitrates well above
100Mbps, there are cases when the available bitrate can be much 100Mbps, there are cases when the available bitrate can be much
skipping to change at page 5, line 22 skipping to change at page 5, line 27
denoted qdelay) along the transmission path. This information is denoted qdelay) along the transmission path. This information is
used to adjust the congestion window. The use of LEDBAT ensures that used to adjust the congestion window. The use of LEDBAT ensures that
the end-to-end latency is kept low. [LEDBAT-delay-impact] shows that the end-to-end latency is kept low. [LEDBAT-delay-impact] shows that
LEDBAT has certain inherent issues that makes it counteract its LEDBAT has certain inherent issues that makes it counteract its
purpose to achieve low delay. The general problem described in the purpose to achieve low delay. The general problem described in the
paper is that the base delay is offset by LEDBAT's own queue buildup. paper is that the base delay is offset by LEDBAT's own queue buildup.
The big difference with using LEDBAT in the SCReAM context lies in The big difference with using LEDBAT in the SCReAM context lies in
the fact that the source is rate limited and that it is required that the fact that the source is rate limited and that it is required that
the RTP queue is kept short (preferably empty). In addition the the RTP queue is kept short (preferably empty). In addition the
output from a video encoder is rarely constant bitrate, static output from a video encoder is rarely constant bitrate, static
content (talking heads) for instance gives almost zero video rate. content (talking heads) for instance gives almost zero video bitrate.
This gives two useful properties when LEDBAT is used with SCReAM that This gives two useful properties when LEDBAT is used with SCReAM that
help to avoid the issues described in [LEDBAT-delay-impact]: help to avoid the issues described in [LEDBAT-delay-impact]:
1. There is always a certain probability that SCReAM is short of 1. There is always a certain probability that SCReAM is short of
data to transmit, which means that the network queue will run data to transmit, which means that the network queue will run
empty every once in a while. empty every once in a while.
2. The max video bitrate can be lower than the link capacity. If 2. The max video bitrate can be lower than the link capacity. If
the max video bitrate is 5Mbps and the capacity is 10Mbps then the max video bitrate is 5Mbps and the capacity is 10Mbps then
the network queue will run empty. the network queue will run empty.
skipping to change at page 10, line 25 skipping to change at page 10, line 25
upper limit to how much the target qdelay (qdelay_target) can be upper limit to how much the target qdelay (qdelay_target) can be
increased in order to cope with competing loss based flows. The increased in order to cope with competing loss based flows. The
target qdelay does not have to be initialized to this high value target qdelay does not have to be initialized to this high value
however as it would increase e2e delay and also make the rate however as it would increase e2e delay and also make the rate
control and congestion control loop sluggish. control and congestion control loop sluggish.
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. Threshold for the detection of incipient congestion.
QDELAY_TREND_TH (0.2)
Averaging factor for qdelay_fraction_avg.
MIN_CWND (3000byte) MIN_CWND (3000byte)
Minimum congestion window. 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.
BETA_ECN (0.8) BETA_ECN (0.9)
CWND scale factor due to ECN event. CWND scale factor due to ECN event.
BETA_R (0.9) BETA_R (0.9)
Target rate scale factor due to loss event. Target rate scale factor due to loss event.
MSS (1000 byte) MSS (1000 byte)
Maximum segment size = Max RTP packet size. Maximum segment size = Max RTP packet size.
RATE_ADJUST_INTERVAL (0.2s) RATE_ADJUST_INTERVAL (0.2s)
Interval between media bitrate adjustments. Interval between media bitrate adjustments.
skipping to change at page 12, line 6 skipping to change at page 12, line 4
The values within () indicate initial values. The values within () indicate initial values.
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
bottleneck, a fixed qdelay target would otherwise starve the RMCAT bottleneck, a fixed qdelay target would otherwise starve the RMCAT
flow under such circumstances. The qdelay target is allowed to flow under such circumstances. The qdelay target is allowed to
vary between QDELAY_TARGET_LO and QDELAY_TARGET_HI. vary between QDELAY_TARGET_LO and QDELAY_TARGET_HI.
qdelay_fraction_avg (0.0) qdelay_fraction_avg (0.0)
EWMA filtered fractional qdelay. EWMA (Exponentially Weighted Moving Average) filtered fractional
qdelay.
qdelay_fraction_hist[20] ({0,..,0}) qdelay_fraction_hist[20] ({0,..,0})
Vector of the last 20 fractional qdelay samples. Vector of the last 20 fractional qdelay samples.
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.
skipping to change at page 13, line 14 skipping to change at page 13, line 14
Measured bitrate from the media encoder. Measured bitrate from the media encoder.
rate_media_median (0.0 bps) rate_media_median (0.0 bps)
Median value of rate_media, computed over more than 10s. Median value of rate_media, computed over more than 10s.
s_rtt (0.0s) s_rtt (0.0s)
Smoothed RTT [s], computed with a similar method to that described Smoothed RTT [s], computed with a similar method to that described
in [RFC6298]. in [RFC6298].
rtp_queue_size (0 bits) rtp_queue_size (0 bits)
Size of RTP packets in queue. Sum of the sizes 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) loss_event_rate (0.0)
The estimated fraction of RTTs with lost packets detected. 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
skipping to change at page 14, line 34 skipping to change at page 14, line 34
with the highest sequence number. with the highest sequence number.
o Accumulated number of ECN-CE marked packets (n_ECN). o Accumulated number of ECN-CE marked packets (n_ECN).
When the sender receives RTCP feedback, the qdelay is calculated as When the sender receives RTCP feedback, the qdelay is calculated as
outlined in [RFC6817]. A qdelay sample is obtained for each received outlined in [RFC6817]. A qdelay sample is obtained for each received
acknowledgement. No smoothing of the qdelay samples occur, however acknowledgement. No smoothing of the qdelay samples occur, however
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'. As mentioned in Section 7 , calculation of the
details for reasons of readability, the reader is encouraged to look proper congestion window and media bitrate may benefit from
into the C++ code in [SCReAM-CPP-implementation] for the details. additional optimizations for handling of very high and very low
bitrates, and from additional damping to handle periodic packet
bursts. Some such optimizations are implemented in
[SCReAM-CPP-implementation], but they do not form part of the
specification of SCReAM at this time.
<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)
# Compute the average of the values in qdelay_fraction_hist # Compute the average of the values in qdelay_fraction_hist
avg_t = average(qdelay_fraction_hist) avg_t = average(qdelay_fraction_hist)
skipping to change at page 15, line 49 skipping to change at page 15, line 49
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
qdelay_fraction_avg to reduce sensitivity to increasing qdelay when qdelay_fraction_avg to reduce sensitivity to increasing qdelay when
it is very small. The 50ms sampling is a simplification and MAY have it is very small. The 50ms sampling is a simplification that could
the effect that the same qdelay is sampled several times, this does have the effect that the same qdelay is sampled several times, this
however not pose any problem as the vector is only used to determine does however not pose any problem as the vector is only used to
if the qdelay is increasing or decreasing. The qdelay_trend is determine if the qdelay is increasing or decreasing. The
utilized in the media rate control to indicate incipient congestion qdelay_trend is utilized in the media rate control to indicate
and to determine when to exit from fast increase mode. incipient congestion and to determine when to exit from fast increase
qdelay_trend_mem is used to enforce a less aggressive rate increase mode. qdelay_trend_mem is used to enforce a less aggressive rate
after congestion events. The function increase after congestion events. The function
update_qdelay_fraction_hist(..) removes the oldest element and adds update_qdelay_fraction_hist(..) removes the oldest element and adds
the latest qdelay_fraction element to the qdelay_fraction_hist the latest qdelay_fraction element to the qdelay_fraction_hist
vector. vector.
4.1.2.1. Reaction to packets loss and ECN 4.1.2.1. Reaction to packets loss and ECN
A loss event is indicated if one or more RTP packets are declared A loss event is indicated if one or more RTP packets are declared
missing. The loss detection is described in Section 4.1.2.4. Once a missing. The loss detection is described in Section 4.1.2.4. Once a
loss event is detected, further detected lost RTP packets SHOULD be loss event is detected, further detected lost RTP packets SHOULD be
ignored for a full smoothed round trip time, the intention of this is ignored for a full smoothed round trip time, the intention of this is
skipping to change at page 19, line 32 skipping to change at page 19, line 32
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
congestion control algorithm. SCReAM takes care of such situations congestion control algorithm, examples are large FTP flows using loss
by adjusting the qdelay_target. based congestion control. The worst condition occurs when the
bottleneck queues are of tail-drop type with a large buffer size.
SCReAM takes care of such situations by adjusting the qdelay_target
when loss based flows are detected, as given by the pseudo code
below.
<CODE BEGINS> <CODE BEGINS>
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(200)) 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))
skipping to change at page 20, line 43 skipping to change at page 20, line 43
qdelay_target *= 0.9 qdelay_target *= 0.9
end end
end 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)
<CODE ENDS> <CODE ENDS>
The qdelay_target is adjusted differently, depending on if Two temporary variables are calculated. qdelay_norm_avg_t is the long
qdelay_norm_var_t is above or below a given value. term average queue delay, qdelay_norm_var_t is the long term variance
A low qdelay_norm_avg_t value indicates that the qdelay does not of the queue delay. A high qdelay_norm_var_t indicates that the
change rapidly. It is desired to avoid the case that the qdelay queue delay changes, this can be an indication of reduced bottleneck
target is increased due to self-congestion, indicated by a changing bandwidth or that a competing flow has just entered. Thus, it
qdelay and consequently an increased qdelay_norm_var_t. Still it indicates that it is not safe to adjust the queue delay target.
SHOULD be possible to increase the qdelay target if the qdelay
continues to be high. This is a simple function with a certain risk A low qdelay_norm_var_t indicates that the queue delay is relatively
of both false positives and negatives. In the simulated LTE test stable, the reason can be that the queue delay is low but it can also
cases it manages competing FTP flows reasonably well at the same time be an indication that a competing flow is filling up the bottleneck
as generally avoiding accidental increases in the qdelay target. The to the limit where packet losses may start to occur, in which case
algorithm can however accidentally increase the qdelay target and the queue delay will stay relatively high for a longer time.
cause self-inflicted congestion in certain cases. If it is deemed
unlikely that competing flows occur over the same bottleneck, the The queue delay target is allowed to be increased if, either the loss
algorithm described in this section MAY be turned off. However, when event rate is above a given threshold or that qdelay_norm_var_t is
sending over the Internet, often the network conditions are not known low. Both these conditions indicate that a competing flow may be
for sure. Therefore turning this algorithm off must be considered present. In all other cases the queue delay target is decreased.
with caution as that can lead to basically zero throughput if
competing with other, loss based, traffic. The function that adjusts the qdelay_target is simple and has a
certain risk to produce both false positive and negatives, The case
that self-inflicted congestion by the SCReAM algorithm may be falsely
interpreted as the presence of competing loss based FTP flows is a
false positive. The opposite case where the algorithm fails to
detect the presence of a competing FTP flow is a false negative.
Extensive simulations have shown that the algorithm performs well in
LTE test cases and that it also performs well in simple bandwidth
limited bottleneck test cases with competing FTP flows. It can
however not be completely ruled out that this algorithm can fail.
Especially the false positives can be problematic as the end to end
delay can increase dramatically if the target queue delay is
increased by accident as a result of self-inflicted congestion.
If it is deemed unlikely that competing flows occur over the same
bottleneck, the algorithm described in this section MAY be turned
off. One such case can be QoS enabled bearers in 3GPP based access
such as LTE. However, when sending over the Internet, often the
network conditions are not known for sure and it is in general not
possible to make safe assumptions on how a network is used and
whether or not competing flows share the same bottleneck. Therefore
turning this algorithm off must be considered with caution as that
can lead to basically zero throughput if competing with other, loss
based, traffic.
4.1.2.4. Lost packet detection 4.1.2.4. Lost packet detection
Lost packet detection is based on the received sequence number list. Lost packet 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) [I-D.ietf-tcpm-rack]. The ideas behind RACK (Recent ACKnowledgement) [I-D.ietf-tcpm-rack]. The
computation of the reordering window is made possible by means of a computation of the reordering window is made possible by means of a
lost flag in the list of transmitted RTP packets. This flag is set lost flag in the list of transmitted RTP packets. This flag is set
skipping to change at page 21, line 41 skipping to change at page 22, line 17
time window (indicated by the reordering window) after an RTP packet time window (indicated by the reordering window) after an RTP packet
with higher sequence number was acknowledged. with higher sequence number was acknowledged.
4.1.2.5. Send window calculation 4.1.2.5. Send window calculation
The basic design principle behind packet transmission in SCReAM is to The basic design principle behind packet transmission in SCReAM is to
allow transmission only if the number of bytes in flight is less than allow transmission only if the number of bytes in flight is less than
the congestion window. There are however two reasons why this strict the congestion window. There are however two reasons why this strict
rule will not work optimally: rule will not work optimally:
o Bitrate variations: The media frame size is always varying to a o Bitrate variations: Media sources such as video encoders generally
larger or smaller extent. A strict rule can lead to that the produce frames whose size always vary to a larger or smaller
media bitrate will have difficulties to increase as the congestion extent. The RTP queue absorbs the natural variations in frame
window puts a too hard restriction on the media frame size sizes. The RTP queue should however be as short as possible, to
variation. This can lead to occasional queuing of RTP packets in avoid that the end to end delay increases. To achieve that, the
the RTP packet queue that will prevent bitrate increase. media rate control takes the RTP queue size into account when the
target bitrate for the media is computed. A strict 'send only
when bytes in flight is less than the congestion window' rule can
lead to that the RTP queue grows simply because the send window is
limited, the effect of which would be that the target bitrate is
pushed down. The consequence of this is that the congestion
window will not increase, or will increase very slowly, because
the congestion window is only allowed to increase when there is a
sufficient amount of data in flight. The end effect is then that
the media bitrate increases very slowly or not at all.
o Reverse (feedback) path congestion: Especially in transport over o Reverse (feedback) path congestion: Especially in transport over
buffer-bloated networks, the one way delay in the reverse buffer-bloated networks, the one way delay in the reverse
direction can jump due to congestion. The effect of this is that direction can jump due to congestion. The effect of this is that
the acknowledgements are delayed with the result that the self- the acknowledgements are delayed with the result that the self-
clocking is temporarily halted, even though the forward path is clocking is temporarily halted, even though the forward path is
not congested. not congested.
The send window is adjusted depending on qdelay and its relation to The send window is adjusted depending on qdelay and its relation to
the qdelay target and the relation between the congestion window and the qdelay target and the relation between the congestion window and
skipping to change at page 32, line 16 skipping to change at page 32, line 46
mechanism: Evaluate how SCReAM performs with competing TCP like mechanism: Evaluate how SCReAM performs with competing TCP like
traffic and to what extent the competing flows compensation causes traffic and to what extent the competing flows compensation causes
self-inflicted congestion. self-inflicted congestion.
o Determine proper parameters: A set of default parameters are given o Determine proper parameters: A set of default parameters are given
that makes SCReAM work over a reasonably large operation range, that makes SCReAM work over a reasonably large operation range,
however for instance for very low or very high bitrates it may be however for instance for very low or very high bitrates it may be
necessary to use different values for instance for the necessary to use different values for instance for the
RAMP_UP_SPEED. RAMP_UP_SPEED.
o Experimentation with further improvements to the congestion window
and media bitrate calculation. [SCReAM-CPP-implementation]
implements some optimizations, not described in this memo, that
improve performance slightly. Further experiments are likely to
lead to more optimizations of the algorithm.
8. Acknowledgements 8. 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 E. E. Nielsen and Mirja additional thanks to RMCAT chairs Karen E. E. Nielsen and Mirja
Kuehlewind for patiently reading, suggesting improvements and also Kuehlewind for patiently reading, suggesting improvements and also
skipping to change at page 32, line 51 skipping to change at page 33, line 40
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-12 to WG-13: IESG comments addressed
o WG-11 to WG-12: Review comments from Joel Halpern 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
skipping to change at page 34, line 10 skipping to change at page 35, line 4
somewhat modified, frame skipping made optional somewhat modified, frame skipping made optional
o -02 to -03 : Added algorithm description with equations, removed o -02 to -03 : Added algorithm description with equations, removed
pseudo code and simulation results pseudo code and simulation results
o -01 to -02 : Updated GCC simulation results o -01 to -02 : Updated GCC simulation results
o -00 to -01 : Fixed a few bugs in example code o -00 to -01 : Fixed a few bugs in example code
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed.,
"RTP Control Protocol Extended Reports (RTCP XR)",
RFC 3611, DOI 10.17487/RFC3611, November 2003,
<https://www.rfc-editor.org/info/rfc3611>.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control "Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
DOI 10.17487/RFC4585, July 2006, DOI 10.17487/RFC4585, July 2006,
<https://www.rfc-editor.org/info/rfc4585>. <https://www.rfc-editor.org/info/rfc4585>.
[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size
Real-Time Transport Control Protocol (RTCP): Opportunities Real-Time Transport Control Protocol (RTCP): Opportunities
and Consequences", RFC 5506, DOI 10.17487/RFC5506, April and Consequences", RFC 5506, DOI 10.17487/RFC5506, April
2009, <https://www.rfc-editor.org/info/rfc5506>. 2009, <https://www.rfc-editor.org/info/rfc5506>.
skipping to change at page 35, line 34 skipping to change at page 36, line 40
[Packet-conservation] [Packet-conservation]
"Congestion Avoidance and Control, ACM SIGCOMM Computer "Congestion Avoidance and Control, ACM SIGCOMM Computer
Communication Review 1988", 1988. Communication Review 1988", 1988.
[QoS-3GPP] [QoS-3GPP]
TS 23.203, 3GPP., "Policy and charging control TS 23.203, 3GPP., "Policy and charging control
architecture", June 2011, <http://www.3gpp.org/ftp/specs/ architecture", June 2011, <http://www.3gpp.org/ftp/specs/
archive/23_series/23.203/23203-990.zip>. archive/23_series/23.203/23203-990.zip>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed.,
"RTP Control Protocol Extended Reports (RTCP XR)",
RFC 3611, DOI 10.17487/RFC3611, November 2003,
<https://www.rfc-editor.org/info/rfc3611>.
[RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P.,
and K. Carlberg, "Explicit Congestion Notification (ECN) and K. Carlberg, "Explicit Congestion Notification (ECN)
for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August
2012, <https://www.rfc-editor.org/info/rfc6679>. 2012, <https://www.rfc-editor.org/info/rfc6679>.
[RFC7478] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- [RFC7478] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real-
Time Communication Use Cases and Requirements", RFC 7478, Time Communication Use Cases and Requirements", RFC 7478,
DOI 10.17487/RFC7478, March 2015, DOI 10.17487/RFC7478, March 2015,
<https://www.rfc-editor.org/info/rfc7478>. <https://www.rfc-editor.org/info/rfc7478>.
 End of changes. 25 change blocks. 
82 lines changed or deleted 133 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/