draft-ietf-rmcat-scream-cc-13.txt   rfc8298.txt 
RMCAT WG I. Johansson Internet Engineering Task Force (IETF) I. Johansson
Internet-Draft Z. Sarker Request for Comments: 8298 Z. Sarker
Intended status: Experimental Ericsson AB Category: Experimental Ericsson AB
Expires: April 29, 2018 October 26, 2017 ISSN: 2070-1721 December 2017
Self-Clocked Rate Adaptation for Multimedia Self-Clocked Rate Adaptation for Multimedia
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 interactive video. The solution conforms to media services such as interactive video. The solution conforms to
the packet conservation principle and uses a hybrid loss and delay the packet conservation principle and uses a hybrid loss-and-delay-
based congestion control algorithm. The algorithm is evaluated over based congestion control algorithm. The algorithm is evaluated over
both simulated Internet bottleneck scenarios as well as in a Long both simulated Internet bottleneck scenarios as well as in a Long
Term Evolution (LTE) system simulator and is shown to achieve both Term Evolution (LTE) system simulator and is shown to achieve both
low 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 document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for examination, experimental implementation, and
evaluation.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document defines an Experimental Protocol for the Internet
and may be updated, replaced, or obsoleted by other documents at any community. This document is a product of the Internet Engineering
time. It is inappropriate to use Internet-Drafts as reference Task Force (IETF). It represents the consensus of the IETF
material or to cite them other than as "work in progress." community. It has received public review and has been approved for
publication by the Internet Engineering Steering Group (IESG). Not
all documents approved by the IESG are a candidate for any level of
Internet Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on April 29, 2018. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8298.
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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Wireless (LTE) access properties . . . . . . . . . . . . 3 1.1. Wireless (LTE) Access Properties . . . . . . . . . . . . 4
1.2. Why is it a self-clocked algorithm? . . . . . . . . . . . 4 1.2. Why is it a self-clocked algorithm? . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
3. Overview of SCReAM Algorithm . . . . . . . . . . . . . . . . 4 3. Overview of SCReAM Algorithm . . . . . . . . . . . . . . . . 6
3.1. Network Congestion Control . . . . . . . . . . . . . . . 7 3.1. Network Congestion Control . . . . . . . . . . . . . . . 8
3.2. Sender Transmission Control . . . . . . . . . . . . . . . 8 3.2. Sender Transmission Control . . . . . . . . . . . . . . . 9
3.3. Media Rate Control . . . . . . . . . . . . . . . . . . . 8 3.3. Media Rate Control . . . . . . . . . . . . . . . . . . . 9
4. Detailed Description of SCReAM . . . . . . . . . . . . . . . 9 4. Detailed Description of SCReAM . . . . . . . . . . . . . . . 10
4.1. SCReAM Sender . . . . . . . . . . . . . . . . . . . . . . 9 4.1. SCReAM Sender . . . . . . . . . . . . . . . . . . . . . . 10
4.1.1. Constants and Parameter values . . . . . . . . . . . 9 4.1.1. Constants and Parameter Values . . . . . . . . . . . 10
4.1.1.1. Constants . . . . . . . . . . . . . . . . . . . . 10 4.1.1.1. Constants . . . . . . . . . . . . . . . . . . . . 11
4.1.1.2. State variables . . . . . . . . . . . . . . . . . 11 4.1.1.2. State Variables . . . . . . . . . . . . . . . . . 12
4.1.2. Network congestion control . . . . . . . . . . . . . 13 4.1.2. Network Congestion Control . . . . . . . . . . . . . 14
4.1.2.1. Reaction to packets loss and ECN . . . . . . . . 16 4.1.2.1. Reaction to Packet Loss and ECN . . . . . . . . . 17
4.1.2.2. Congestion window update . . . . . . . . . . . . 16 4.1.2.2. Congestion Window Update . . . . . . . . . . . . 17
4.1.2.3. Competing flows compensation . . . . . . . . . . 19 4.1.2.3. Competing Flows Compensation . . . . . . . . . . 20
4.1.2.4. Lost packet detection . . . . . . . . . . . . . . 21 4.1.2.4. Lost Packet Detection . . . . . . . . . . . . . . 22
4.1.2.5. Send window calculation . . . . . . . . . . . . . 22 4.1.2.5. Send Window Calculation . . . . . . . . . . . . . 23
4.1.2.6. Packet pacing . . . . . . . . . . . . . . . . . . 23 4.1.2.6. Packet Pacing . . . . . . . . . . . . . . . . . . 24
4.1.2.7. Resuming fast increase . . . . . . . . . . . . . 23 4.1.2.7. Resuming Fast Increase Mode . . . . . . . . . . . 24
4.1.2.8. Stream prioritization . . . . . . . . . . . . . . 23 4.1.2.8. Stream Prioritization . . . . . . . . . . . . . . 24
4.1.3. Media rate control . . . . . . . . . . . . . . . . . 24 4.1.3. Media Rate Control . . . . . . . . . . . . . . . . . 25
4.2. SCReAM Receiver . . . . . . . . . . . . . . . . . . . . . 27 4.2. SCReAM Receiver . . . . . . . . . . . . . . . . . . . . . 28
4.2.1. Requirements on feedback elements . . . . . . . . . . 27 4.2.1. Requirements on Feedback Elements . . . . . . . . . . 28
4.2.2. Requirements on feedback intensity . . . . . . . . . 29 4.2.2. Requirements on Feedback Intensity . . . . . . . . . 30
5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 29 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 31
6. Implementation status . . . . . . . . . . . . . . . . . . . . 30 6. Suggested Experiments . . . . . . . . . . . . . . . . . . . . 31
6.1. OpenWebRTC . . . . . . . . . . . . . . . . . . . . . . . 31 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
6.2. A C++ Implementation of SCReAM . . . . . . . . . . . . . 31 8. Security Considerations . . . . . . . . . . . . . . . . . . . 32
7. Suggested experiments . . . . . . . . . . . . . . . . . . . . 32 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33 9.1. Normative References . . . . . . . . . . . . . . . . . . 33
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 9.2. Informative References . . . . . . . . . . . . . . . . . 34
10. Security Considerations . . . . . . . . . . . . . . . . . . . 33 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 36
11. Change history . . . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
12.1. Normative References . . . . . . . . . . . . . . . . . . 35
12.2. Informative References . . . . . . . . . . . . . . . . . 35
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 real-time
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
an important part of interactive realtime communications as the is an important part of interactive real-time communications, as the
transmission channel bandwidth can vary over time. Wireless access transmission channel bandwidth can vary over time. Wireless access
such as LTE, which is an integral part of the current Internet, such as LTE, which is an integral part of the current Internet,
increases the importance of rate adaptation as the channel bandwidth increases the importance of rate adaptation as the channel bandwidth
of a default LTE bearer [QoS-3GPP] can change considerably in a very of a default LTE bearer [QoS-3GPP] can change considerably in a very
short time frame. Thus a rate adaptation solution for interactive short time frame. Thus, a rate adaptation solution for interactive
realtime media, such as WebRTC, should be both quick and be able to real-time media, such as WebRTC [RFC7478], should be both quick and
operate over a large range in channel capacity. This memo describes be able to operate over a large range in channel capacity. This memo
SCReAM (Self-Clocked Rate Adaptation for Multimedia), a solution that describes Self-Clocked Rate Adaptation for Multimedia (SCReAM), a
implements congestion control for RTP streams [RFC3550]. While solution that implements congestion control for RTP streams
SCReAM was originally devised for WebRTC (Web Real-Time [RFC3550]. While SCReAM was originally devised for WebRTC, it can
Communication) [RFC7478], it can also be used for other applications also be used for other applications where congestion control of RTP
where congestion control of RTP streams is necessary. SCReAM is streams is necessary. SCReAM is based on the self-clocking principle
based on the self-clocking principle of TCP and uses techniques of TCP and uses techniques similar to what is used in the rate
similar to what is used in the LEDBAT based rate adaptation algorithm adaptation algorithm based on Low Extra Delay Background Transport
[RFC6817]. SCReAM is not entirely self-clocked as it augments self- (LEDBAT) [RFC6817]. SCReAM is not entirely self-clocked as it
clocking with pacing and a minimum send rate. augments self-clocking with pacing and a minimum send rate. SCReAM
SCReAM can take advantage of ECN (Explicit Congestion Notification) can take advantage of Explicit Congestion Notification (ECN) in cases
in cases where ECN is supported by the network and the hosts. ECN is where ECN is supported by the network and the hosts. However, ECN is
however not required for the basic congestion control functionality not required for the basic congestion control functionality in
in SCReAM. SCReAM.
1.1. Wireless (LTE) access properties 1.1. Wireless (LTE) Access Properties
[I-D.ietf-rmcat-wireless-tests] describes the complications that can [WIRELESS-TESTS] describes the complications that can be observed in
be observed in wireless environments. Wireless access such as LTE wireless environments. Wireless access such as LTE typically cannot
can typically not guarantee a given bandwidth, this is true guarantee a given bandwidth; this is true especially for default
especially for default bearers. The network throughput can vary bearers. The network throughput can vary considerably, for instance,
considerably for instance in cases where the wireless terminal is in cases where the wireless terminal is moving around. Even though
moving around. Even though LTE can support bitrates well above LTE can support bitrates well above 100 Mbps, there are cases when
100Mbps, there are cases when the available bitrate can be much the available bitrate can be much lower; examples are situations with
lower, examples are situations with high network load and poor high network load and poor coverage. An additional complication is
coverage. An additional complication is that the network throughput that the network throughput can drop for short time intervals (e.g.,
can drop for short time intervals at e.g. handover, these short at handover); these short glitches are initially very difficult to
glitches are initially very difficult to distinguish from more distinguish from more permanent reductions in throughput.
permanent reductions in throughput.
Unlike wireline bottlenecks with large statistical multiplexing it is Unlike wireline bottlenecks with large statistical multiplexing, it
not possible to try to maintain a given bitrate when congestion is is not possible to try to maintain a given bitrate when congestion is
detected with the hope that other flows will yield, this is because detected with the hope that other flows will yield. This is because
there are generally few other flows competing for the same there are generally few other flows competing for the same
bottleneck. Each user gets its own variable throughput bottleneck, bottleneck. Each user gets its own variable throughput bottleneck,
where the throughput depends on factors like channel quality, network where the throughput depends on factors like channel quality, network
load and historical throughput. The bottom line is, if the load, and historical throughput. The bottom line is, if the
throughput drops, the sender has no other option than to reduce the throughput drops, the sender has no other option than to reduce the
bitrate. Once the radio scheduler has reduced the resource bitrate. Once the radio scheduler has reduced the resource
allocation for a bearer, an RMCAT flow in that bearer aims to reduce allocation for a bearer, a flow (which is using RTP Media Congestion
the sending rate quite quickly (within one RTT) in order to avoid Avoidance Techniques (RMCAT)) in that bearer aims to reduce the
sending rate quite quickly (within one RTT) in order to avoid
excessive queuing delay or packet loss. excessive queuing delay or packet loss.
1.2. Why is it a self-clocked algorithm? 1.2. Why is it a self-clocked algorithm?
Self-clocked congestion control algorithms provide a benefit over the Self-clocked congestion control algorithms provide a benefit over
rate based counterparts in that the former consists of two adaptation their rate-based counterparts in that the former consists of two
mechanisms: adaptation mechanisms:
o A congestion window computation that evolves over a longer o A congestion window computation that evolves over a longer
timescale (several RTTs) especially when the congestion window timescale (several RTTs) especially when the congestion window
evolution is dictated by estimated delay (to minimize evolution is dictated by estimated delay (to minimize
vulnerability to e.g. short term delay variations). vulnerability to, e.g., short-term delay variations).
o A fine grained congestion control given by the self-clocking which o A fine-grained congestion control given by the self-clocking; it
operates on a shorter time scale (1 RTT). The benefits of self- operates on a shorter time scale (1 RTT). The benefits of self-
clocking are also elaborated upon in [TFWC]. clocking are also elaborated upon in [TFWC].
A rate based congestion control typically adjusts the rate based on A rate-based congestion control algorithm typically adjusts the rate
delay and loss. The congestion detection needs to be done with a based on delay and loss. The congestion detection needs to be done
certain time lag to avoid over-reaction to spurious congestion events with a certain time lag to avoid overreaction to spurious congestion
such as delay spikes. Despite the fact that there are two or more events such as delay spikes. Despite the fact that there are two or
congestion indications, the outcome is still that there is still only more congestion indications, the outcome is that there is still only
one mechanism to adjust the sending rate. This makes it difficult to one mechanism to adjust the sending rate. This makes it difficult to
reach the goals of high throughput and prompt reaction to congestion. reach the goals of high throughput and prompt reaction to congestion.
2. Terminology 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Overview of SCReAM Algorithm 3. Overview of SCReAM Algorithm
The core SCReAM algorithm has similarities to the concepts of self- The core SCReAM algorithm has similarities to the concepts of self-
clocking used in TFWC [TFWC] and follows the packet conservation clocking used in TCP-friendly window-based congestion control [TFWC]
principle. The packet conservation principle is described as an and follows the packet conservation principle. The packet
important key-factor behind the protection of networks from conservation principle is described as a key factor behind the
congestion [Packet-conservation]. protection of networks from congestion [Packet-conservation].
In SCReAM, the receiver of the media echoes a list of received RTP In SCReAM, the receiver of the media echoes a list of received RTP
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
were transmitted. This information is used to determine the number they were transmitted. This information is used to determine the
of bytes that can be transmitted at any given time instant. A number 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. flight, i.e., transmitted but not yet acknowledged.
The congestion window is determined in a way similar to LEDBAT The congestion window is determined in a way similar to LEDBAT
[RFC6817]. LEDBAT is a congestion control algorithm that uses send [RFC6817]. LEDBAT is a congestion control algorithm that uses send
and receive timestamps to estimate the queuing delay (from now on and receive timestamps to estimate the queuing delay (from now on
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 make it counteract its
purpose to achieve low delay. The general problem described in the purpose of achieving 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 facts that the source is rate limited and that the RTP queue must
the RTP queue is kept short (preferably empty). In addition the be kept short (preferably empty). In addition, the output from a
output from a video encoder is rarely constant bitrate, static video encoder is rarely constant bitrate; static content (talking
content (talking heads) for instance gives almost zero video bitrate. heads, for instance) gives almost zero video bitrate. This yields
This gives two useful properties when LEDBAT is used with SCReAM that two useful properties when LEDBAT is used with SCReAM; they help to
help to avoid the issues described in [LEDBAT-delay-impact]: 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; this means that the network queue will become
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 5 Mbps and the capacity is 10 Mbps, then
the network queue will run empty. the network queue will become empty.
It is sufficient that any of the two conditions above is fulfilled to It is sufficient that any of the two conditions above is fulfilled to
make the base delay update properly. Furthermore make the base delay update properly. Furthermore,
[LEDBAT-delay-impact] describes an issue with short lived competing [LEDBAT-delay-impact] describes an issue with short-lived competing
flows, the case in SCReAM is that these short lived flows will cause flows. In SCReAM, these short-lived flows will cause the self-
the self-clocking in SCReAM to slow down with the result that the RTP clocking to slow down, thereby building up the RTP queue; in turn,
queue is built up, which will in turn result in a reduced media video this results in a reduced media video bitrate. Thus, SCReAM slows
bitrate. SCReAM will thus yield more to competing short lived flows the bitrate more when there are competing short-lived flows than the
than what is the case with traditional use of LEDBAT. traditional use of LEDBAT does. The basic functionality in the use
The basic functionality in the use of LEDBAT in SCReAM is quite of LEDBAT in SCReAM is quite simple; however, there are a few steps
simple, there are however a few steps to take to make the concept in order to make the concept work with conversational media:
work with conversational media:
o Congestion window validation techniques. These are similar in o Congestion window validation techniques. These are similar to the
action as the method described in [RFC7661]. Congestion window method described in [RFC7661]. Congestion window validation
validation ensures that the congestion window is limited by the ensures that the congestion window is limited by the actual number
actual number bytes in flight, this is important especially in the bytes in flight; this is important especially in the context of
context of rate limited sources such as video. Lack of congestion rate-limited sources such as video. Lack of congestion window
window validation would lead to a slow reaction to congestion as validation would lead to a slow reaction to congestion as the
the congestion window does not properly reflect the congestion congestion window does not properly reflect the congestion state
state in the network. The allowed idle period in this memo is in the network. The allowed idle period in this memo is shorter
shorter than in [RFC7661], this to avoid excessive delays in the than in [RFC7661]; this to avoid excessive delays in the cases
cases where e.g. wireless throughput has decreased during a period where, e.g., wireless throughput has decreased during a period
where the output bitrate from the media coder has been low, for where the output bitrate from the media coder has been low (for
instance due to inactivity. Furthermore, this memo allows for instance, due to inactivity). Furthermore, this memo allows for
more relaxed rules for when the congestion window is allowed to more relaxed rules for when the congestion window is allowed to
grow, this is necessary as the variable output bitrate generally grow; this is necessary as the variable output bitrate generally
means that the congestion window is often under-utilized. means that the congestion window is often underutilized.
o Fast increase makes the bitrate increase faster when no congestion o Fast increase mode makes the bitrate increase faster when no
is detected. It makes the media bitrate ramp-up within 5 to 10 congestion is detected. It makes the media bitrate ramp up within
seconds. The behavior is similar to TCP slowstart. The fast 5 to 10 seconds. The behavior is similar to TCP slowstart. Fast
increase is exited when congestion is detected. The fast increase increase mode is exited when congestion is detected. However,
state can however resume if the congestion level is low, this fast increase mode can resume if the congestion level is low; this
enables a reasonably quick rate increase in case link throughput enables a reasonably quick rate increase in case link throughput
increases. increases.
o A qdelay trend is computed for earlier detection of incipient o A qdelay trend is computed for earlier detection of incipient
congestion and as a result it reduces jitter. congestion; 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 in the media rate calculation to achieve o Use of inflection points in the media rate calculation to achieve
reduced jitter. reduced jitter.
o Adjustment of qdelay target for better performance when competing o Adjustment of qdelay 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. The full details are described Sections 3.1 to 3.3. The full details are described in Section 4.
in Section 4.
+---------------------------+ +---------------------------+
| Media encoder | | Media encoder |
+---------------------------+ +---------------------------+
^ | ^ |
| |(1) | |(1)
|(3) RTP |(3) RTP
| V | V
| +-----------+ | +-----------+
+---------+ | | +---------+ | |
skipping to change at page 7, line 38 skipping to change at page 8, line 38
| +------------+ +--------------+ | +------------+ +--------------+
| | | |
|-------------RTCP----------| |(5) |-------------RTCP----------| |(5)
(6) | RTP (6) | RTP
| v | v
+------------+ +------------+
| UDP | | UDP |
| socket | | socket |
+------------+ +------------+
Figure 1: SCReAM sender functional view Figure 1: SCReAM Sender Functional View
The SCReAM algorithm consists of three main parts: network congestion The SCReAM algorithm consists of three main parts: network congestion
control, sender transmission control and media rate control. All of control, sender transmission control, and media rate control. All of
these three parts reside at the sender side. Figure 1 shows the these parts reside at the sender side. Figure 1 shows the functional
functional overview of a SCReAM sender. The receiver side algorithm overview of a SCReAM sender. The receiver-side algorithm is very
is very simple in comparison as it only generates feedback containing simple in comparison, as it only generates feedback containing
acknowledgements of received RTP packets and an ECN count. acknowledgements of received RTP packets and an ECN count.
3.1. Network Congestion Control 3.1. Network Congestion Control
The network congestion control sets an upper limit on how much data The network congestion control sets an upper limit on how much data
can be in the network (bytes in flight); this limit is called CWND can be in the network (bytes in flight); this limit is called CWND
(congestion window) and is used in the sender transmission control. (congestion window) and is used in the sender transmission control.
The SCReAM congestion control method, uses techniques similar to The SCReAM congestion control method uses techniques similar to
LEDBAT [RFC6817] to measure the qdelay. As is the case with LEDBAT, LEDBAT [RFC6817] to measure the qdelay. As is the case with LEDBAT,
it is not necessary to use synchronized clocks in sender and receiver it is not necessary to use synchronized clocks in the sender and
in order to compute the qdelay. It is however necessary that they receiver in order to compute the qdelay. However, it is necessary
use the same clock frequency, or that the clock frequency at the that they use the same clock frequency, or that the clock frequency
receiver can be inferred reliably by the sender. Failure to meet at the receiver can be inferred reliably by the sender. Failure to
this requirement leads to malfunction in the SCReAM congestion meet this requirement leads to malfunction in the SCReAM congestion
control algorithm due to incorrect estimation of the network queue control algorithm due to incorrect estimation of the network queue
delay. delay.
The SCReAM sender calculates the congestion window based on the The SCReAM sender calculates the congestion window based on the
feedback from the SCReAM receiver. The congestion window is allowed feedback from the SCReAM receiver. The congestion window is allowed
to increase if the qdelay is below a predefined qdelay target, to increase if the qdelay is below a predefined qdelay target;
otherwise the congestion window decreases. The qdelay target is otherwise, the congestion window decreases. The qdelay target is
typically set to 50-100ms. This ensures that the queuing delay is typically set to 50-100 ms. This ensures that the queuing delay is
kept low. The reaction to loss or ECN events leads to an instant kept low. The reaction to loss or ECN events leads to an instant
reduction of CWND. Note that the source rate limited nature of real reduction of CWND. Note that the source rate-limited nature of real-
time media such as video, typically means that the queuing delay will time media, such as video, typically means that the queuing delay
mostly be below the given delay target, this is contrary to the case will mostly be below the given delay target. This is contrary to the
where large files are transmitted using LEDBAT congestion control, in case where large files are transmitted using LEDBAT congestion
which case the queuing delay will stay close to the delay target. control and the queuing delay will stay close to the delay target.
3.2. Sender Transmission Control 3.2. Sender Transmission Control
The sender transmission control limits the output of data, given by The sender transmission control limits the output of data, given by
the relation between the number of bytes in flight and the congestion the relation between the number of bytes in flight and the congestion
window. Packet pacing is used to mitigate issues with ACK window. Packet pacing is used to mitigate issues with ACK
compression that MAY cause increased jitter and/or packet loss in the compression that MAY cause increased jitter and/or packet loss in the
media traffic. Packet pacing limits the packet transmission rate media traffic. Packet pacing limits the packet transmission rate
given by the estimated link throughput. Even if the send window given by the estimated link throughput. Even if the send window
allows for the transmission of a number of packets, these packets are allows for the transmission of a number of packets, these packets are
not transmitted immediately, but rather they are transmitted in not transmitted immediately; rather, they are transmitted in
intervals given by the packet size and the estimated link throughput. intervals given by the packet size and the estimated link throughput.
3.3. Media Rate Control 3.3. Media Rate Control
The media rate control serves to adjust the media bitrate to ramp-up The media rate control serves to adjust the media bitrate to ramp up
quickly enough to get a fair share of the system resources when link quickly enough to get a fair share of the system resources when link
throughput increases. throughput increases.
The reaction to reduced throughput MUST be prompt in order to avoid The reaction to reduced throughput MUST be prompt in order to avoid
getting too much data queued in the RTP packet queue(s) in the getting too much data queued in the RTP packet queue(s) in the
sender. The media bitrate is decreased if the RTP queue size exceeds sender. The media bitrate is decreased if the RTP queue size exceeds
a threshold. a threshold.
In cases where the sender frame queues increase rapidly such as in In cases where the sender's frame queues increase rapidly, such as in
the case of a RAT (Radio Access Type) handover it MAY be necessary to the case of a Radio Access Type (RAT) handover, the SCReAM sender MAY
implement additional actions, such as discarding of encoded media implement additional actions, such as discarding of encoded media
frames or frame skipping in order to ensure that the RTP queues are frames or frame skipping in order to ensure that the RTP queues are
drained quickly. Frame skipping results in the frame rate being drained quickly. Frame skipping results in the frame rate being
temporarily reduced. Which method to use is a design choice and temporarily reduced. Which method to use is a design choice and is
outside the scope of this algorithm description. outside the scope of this algorithm description.
4. Detailed Description of SCReAM 4. Detailed Description of SCReAM
4.1. SCReAM Sender 4.1. SCReAM Sender
This section describes the sender side algorithm in more detail. It This section describes the sender-side algorithm in more detail. It
is split between the network congestion control, sender transmission is split between the network congestion control, sender transmission
control and the media rate control. control, and media rate control.
A SCReAM sender implements media rate control and an RTP queue for A SCReAM sender implements media rate control and an RTP queue for
each media type or source, where RTP packets containing encoded media each media type or source, where RTP packets containing encoded media
frames are temporarily stored for transmission. Figure 1 shows the frames are temporarily stored for transmission. Figure 1 shows the
details when a single media source (or stream) is used. A details when a single media source (or stream) is used. A
transmission scheduler (not shown in the figure) is added to support transmission scheduler (not shown in the figure) is added to support
multiple streams. The transmission scheduler can enforce differing multiple streams. The transmission scheduler can enforce differing
priorities between the streams and act like a coupled congestion priorities between the streams and act like a coupled congestion
controller for multiple flows. Support for multiple streams is controller for multiple flows. Support for multiple streams is
implemented in [SCReAM-CPP-implementation]. implemented in [SCReAM-CPP-implementation].
Media frames are encoded and forwarded to the RTP queue (1) in Media frames are encoded and forwarded to the RTP queue (1) in
Figure 1. The media rate adaptation adapts to the size of the RTP Figure 1. The media rate adaptation adapts to the size of the RTP
queue (2) and provides a target rate for the media encoder (3). The queue (2) and provides a target rate for the media encoder (3). The
RTP packets are picked from the RTP queue (for multiple flows from RTP packets are picked from the RTP queue (4), for multiple flows
each RTP queue based on some defined priority order or simply in a from each RTP queue based on some defined priority order or simply in
round robin fashion) (4) by the sender transmission controller. The a round-robin fashion, by the sender transmission controller. The
sender transmission controller (in case of multiple flows a sender transmission controller (in case of multiple flows a
transmission scheduler) sends the RTP packets to the UDP socket (5). transmission scheduler) sends the RTP packets to the UDP socket (5).
In the general case all media SHOULD go through the sender In the general case, all media SHOULD go through the sender
transmission controller and is limited so that the number of bytes in transmission controller and is limited so that the number of bytes in
flight is less than the congestion window. RTCP packets are received flight is less than the congestion window. RTCP packets are received
(6) and the information about bytes in flight and congestion window (6) and the information about the bytes in flight and congestion
is exchanged between the network congestion control and the sender window is exchanged between the network congestion control and the
transmission control (7). sender transmission control (7).
4.1.1. Constants and Parameter values 4.1.1. Constants and Parameter Values
Constants and state variables are listed in this section. Temporary Constants and state variables are listed in this section. Temporary
variables are not listed, instead they are appended with '_t' in the variables are not listed; instead, they are appended with '_t' in the
pseudo code to indicate their local scope. pseudocode to indicate their local scope.
4.1.1.1. Constants 4.1.1.1. Constants
The RECOMMENDED values, within (), for the constants are deduced from The RECOMMENDED values, within parentheses "()", for the constants
experiments. The units are enclosed in square brackets [ ]. are deduced from experiments.
QDELAY_TARGET_LO (0.1s) QDELAY_TARGET_LO (0.1 s)
Target value for the minimum qdelay. Target value for the minimum qdelay.
QDELAY_TARGET_HI (0.4s) QDELAY_TARGET_HI (0.4 s)
Target value for the maximum qdelay. This parameter provides an Target value for the maximum qdelay. This parameter provides an
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.
target qdelay does not have to be initialized to this high value However, the target qdelay does not have to be initialized to this
however as it would increase e2e delay and also make the rate high value, as it would increase end-to-end delay and also make the
control and congestion control loop sluggish. rate control and congestion control loops 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)
Threshold for the detection of incipient congestion. Threshold for the detection of incipient congestion.
MIN_CWND (3000byte) MIN_CWND (3000 bytes)
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.9) 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. Scale factor for target rate 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.2 s)
Interval between media bitrate adjustments. Interval between media bitrate adjustments.
TARGET_BITRATE_MIN TARGET_BITRATE_MIN
Min target bitrate [bps], bps is bits per second. Minimum target bitrate in bps (bits per second).
TARGET_BITRATE_MAX TARGET_BITRATE_MAX
Max target bitrate [bps]. Maximum target bitrate in bps.
RAMP_UP_SPEED (200000bps/s) RAMP_UP_SPEED (200000 bps/s)
Maximum allowed rate increase speed. Maximum allowed rate increase speed.
PRE_CONGESTION_GUARD (0.0..1.0) 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 indicate that 0.1 is characteristics. Experiments with H264 and VP8 indicate that 0.1
a suitable value. See [SCReAM-CPP-implementation] and is a suitable value. See [SCReAM-CPP-implementation] and
[SCReAM-implementation-experience] for evaluation of a real [SCReAM-implementation-experience] for evaluation of a real
implementation. implementation.
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.
with H264 and VP8 indicate that 1.0 is a suitable value. See Experiments with H264 and VP8 indicate that 1.0 is a suitable
[SCReAM-CPP-implementation] and [SCReAM-implementation-experience] value. See [SCReAM-CPP-implementation] and
for evaluation of a real implementation. [SCReAM-implementation-experience] for evaluation of a real
implementation.
RTP_QDELAY_TH (0.02s) RTP queue delay threshold for a target rate RTP_QDELAY_TH (0.02 s) RTP queue delay threshold for a target rate
reduction. reduction.
TARGET_RATE_SCALE_RTP_QDELAY (0.95) Target rate scale when RTP TARGET_RATE_SCALE_RTP_QDELAY (0.95) Scale factor for target rate
qdelay threshold exceeds RTP_QDELAY_TH. when RTP qdelay threshold exceeds RTP_QDELAY_TH.
QDELAY_TREND_LO (0.2) Threshold value for qdelay_trend. QDELAY_TREND_LO (0.2) Threshold value for qdelay_trend.
T_RESUME_FAST_INCREASE (5s) Time span until fast increase can be T_RESUME_FAST_INCREASE (5 s) Time span until fast increase mode can
resumed, given that the qdelay_trend is below QDELAY_TREND_LO. be resumed, given that the qdelay_trend is below QDELAY_TREND_LO.
RATE_PACE_MIN (50000bps) Minimum pacing rate. RATE_PACE_MIN (50000 bps) Minimum pacing rate.
4.1.1.2. State variables 4.1.1.2. State Variables
The values within () indicate initial values. The values within parentheses "()" 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 a fixed qdelay target would otherwise starve the RMCAT
bottleneck, a fixed qdelay target would otherwise starve the RMCAT flow under such circumstances (e.g., FTP competes for the bandwidth
flow under such circumstances. The qdelay target is allowed to over the same bottleneck). The qdelay target is allowed to vary
vary between QDELAY_TARGET_LO and QDELAY_TARGET_HI. between QDELAY_TARGET_LO and QDELAY_TARGET_HI.
qdelay_fraction_avg (0.0) qdelay_fraction_avg (0.0)
EWMA (Exponentially Weighted Moving Average) filtered fractional Fractional qdelay filtered by the Exponentially Weighted Moving
qdelay. Average (EWMA).
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.
qdelay_norm_hist[100] ({0,..,0}) qdelay_norm_hist[100] ({0,..,0})
Vector of the last 100 normalized qdelay samples. Vector of the last 100 normalized qdelay samples.
in_fast_increase (true) in_fast_increase (true)
True if in fast increase state. True if in fast increase mode.
cwnd (MIN_CWND) cwnd (MIN_CWND)
Congestion window. Congestion window.
bytes_newly_acked (0) bytes_newly_acked (0)
The number of bytes that was acknowledged with the last received The number of bytes that was acknowledged with the last received
acknowledgement i.e. bytes acknowledged since the last CWND update. acknowledgement, i.e., bytes acknowledged since the last CWND
update.
max_bytes_in_flight (0) max_bytes_in_flight (0)
The maximum number of bytes in flight over a sliding time window, The maximum number of bytes in flight over a sliding time window,
i.e. transmitted but not yet acknowledged bytes. i.e., transmitted but not yet acknowledged bytes.
send_wnd (0) send_wnd (0)
Upper limit to how many bytes that can currently be transmitted. Upper limit to how many bytes can currently be transmitted.
Updated when cwnd is updated and when RTP packet is transmitted. Updated when cwnd is updated and when RTP packet is transmitted.
target_bitrate (0 bps) target_bitrate (0 bps)
Media target bitrate. Media target bitrate.
target_bitrate_last_max (1 bps) target_bitrate_last_max (1 bps)
Media target bitrate inflection point i.e. the last known highest Inflection point of the media target bitrate, i.e., the last known
target_bitrate. Used to limit bitrate increase speed close to the highest target_bitrate. Used to limit bitrate increase speed close
last known congestion point. to the last known congestion point.
rate_transmit (0.0 bps) rate_transmit (0.0 bps)
Measured transmit bitrate. Measured transmit bitrate.
rate_ack (0.0 bps) rate_ack (0.0 bps)
Measured throughput based on received acknowledgements. Measured throughput based on received acknowledgements.
rate_media (0.0 bps) rate_media (0.0 bps)
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 10 s.
s_rtt (0.0s) s_rtt (0.0s)
Smoothed RTT [s], computed with a similar method to that described Smoothed RTT (in seconds), computed with a similar method to that
in [RFC6298]. described in [RFC6298].
rtp_queue_size (0 bits) rtp_queue_size (0 bits)
Sum of the sizes 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, which performs
main functions: two main functions:
o Computation of congestion window at the sender: Gives an upper o Computation of congestion window at the sender: This gives an
limit to the number of bytes in flight. upper limit to the number of bytes in flight.
o Calculation of send window at the sender: RTP packets are o Calculation of send window at the sender: RTP packets are
transmitted if allowed by the relation between the number of bytes transmitted if allowed by the relation between the number of bytes
in flight and the congestion window. This is controlled by the in flight and the congestion window. This is controlled by the
send window. send window.
SCReAM is a window based and byte oriented congestion control SCReAM is a window-based and byte-oriented congestion control
protocol, where the number of bytes transmitted is inferred from the protocol, where the number of bytes transmitted is inferred from the
size of the transmitted RTP packets. Thus a list of transmitted RTP size of the transmitted RTP packets. Thus, a list of transmitted RTP
packets and their respective transmission times (wall-clock time) packets and their respective transmission times (wall-clock time)
MUST be kept for further calculation. MUST be kept for further calculation.
The number of bytes in flight (bytes_in_flight) is computed as the The number of bytes in flight (bytes_in_flight) is computed as the
sum of the sizes of the RTP packets ranging from the RTP packet most sum of the sizes of the RTP packets ranging from the RTP packet most
recently transmitted down to but not including the acknowledged recently transmitted, down to but not including the acknowledged
packet with the highest sequence number. This can be translated to packet with the highest sequence number. This can be translated to
the difference between the highest transmitted byte sequence number the difference between the highest transmitted byte sequence number
and the highest acknowledged byte sequence number. As an example: If and the highest acknowledged byte sequence number. As an example: If
RTP packet with sequence number SN is transmitted and the last an RTP packet with sequence number SN is transmitted and the last
acknowledgement indicates SN-5 as the highest received sequence acknowledgement indicates SN-5 as the highest received sequence
number then bytes in flight is computed as the sum of the size of RTP number, then bytes_in_flight is computed as the sum of the size of
packets with sequence number SN-4, SN-3, SN-2, SN-1 and SN, it does RTP packets with sequence number SN-4, SN-3, SN-2, SN-1, and SN. It
not matter if for instance packet with sequence number SN-3 was lost, does not matter if, for instance, the packet with sequence number
the size of RTP packet with sequence number SN-3 will still be SN-3 was lost -- the size of RTP packet with sequence number SN-3
considered in the computation of bytes_in_flight. will still be considered in the computation of bytes_in_flight.
Furthermore, a variable bytes_newly_acked is incremented with a value Furthermore, a variable bytes_newly_acked is incremented with a value
corresponding to how much the highest sequence number has increased corresponding to how much the highest sequence number has increased
since the last feedback. As an example: If the previous since the last feedback. As an example: If the previous
acknowledgement indicated the highest sequence number N and the new acknowledgement indicated the highest sequence number N and the new
acknowledgement indicated N+3, then bytes_newly_acked is incremented acknowledgement indicated N+3, then bytes_newly_acked is incremented
by a value equal to the sum of the sizes of RTP packets with sequence by a value equal to the sum of the sizes of RTP packets with sequence
number N+1, N+2 and N+3. Packets that are lost are also included, number N+1, N+2, and N+3. Packets that are lost are also included,
which means that even though e.g packet N+2 was lost, its size is which means that even though, e.g., packet N+2 was lost, its size is
still included in the update of bytes_newly_acked. The still included in the update of bytes_newly_acked. The
bytes_newly_acked variable is reset to zero after a CWND update. bytes_newly_acked variable is reset to zero after a CWND update.
The feedback from the receiver is assumed to consist of the following The feedback from the receiver is assumed to consist of the following
elements. elements.
o A list of received RTP packets' sequence numbers. o A list of received RTP packets' sequence numbers.
o The wall clock timestamp corresponding to the received RTP packet o The wall-clock timestamp corresponding to the received RTP packet
with the highest sequence number. with the highest sequence number.
o Accumulated number of ECN-CE marked packets (n_ECN). o The accumulated number of ECN-CE-marked packets (n_ECN). Here,
"CE" refers to "Congestion Experienced".
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 is performed; however,
some smoothing occurs anyway as the computation of the CWND is a low some smoothing occurs anyway because the CWND computation 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 pseudocode below; temporary variables are appended
appended with '_t'. As mentioned in Section 7 , calculation of the with '_t'. As mentioned in Section 6, calculation of the proper
proper congestion window and media bitrate may benefit from congestion window and media bitrate may benefit from additional
additional optimizations for handling of very high and very low optimizations to handle very high and very low bitrates, and from
bitrates, and from additional damping to handle periodic packet additional damping to handle periodic packet bursts. Some such
bursts. Some such optimizations are implemented in optimizations are implemented in [SCReAM-CPP-implementation], but
[SCReAM-CPP-implementation], but they do not form part of the they do not form part of the specification of SCReAM at this time.
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)
# R is an autocorrelation function of qdelay_fraction_hist, # R is an autocorrelation function of qdelay_fraction_hist,
# with the mean (DC component) removed, at lag K # with the mean (DC component) removed, at lag K
# The subtraction of the scalar avg_t from # The subtraction of the scalar avg_t from
# qdelay_fraction_hist is performed element-wise # qdelay_fraction_hist is performed element-wise
a_t = R(qdelay_fraction_hist-avg_t,1)/ a_t = R(qdelay_fraction_hist-avg_t, 1) /
R(qdelay_fraction_hist-avg_t,0) R(qdelay_fraction_hist-avg_t, 0)
# Calculate qdelay trend # Calculate qdelay trend
qdelay_trend = min(1.0,max(0.0,a_t*qdelay_fraction_avg)) qdelay_trend = min(1.0, max(0.0, a_t * qdelay_fraction_avg))
# Calculate a 'peak-hold' qdelay_trend, this gives a memory # Calculate a 'peak-hold' qdelay_trend; this gives a memory
# of congestion in the past # of congestion in the past
qdelay_trend_mem = max(0.99*qdelay_trend_mem, qdelay_trend) qdelay_trend_mem = max(0.99 * qdelay_trend_mem, qdelay_trend)
<CODE ENDS> <CODE ENDS>
The qdelay fraction is sampled every 50ms and the last 20 samples are The qdelay fraction is sampled every 50 ms, and the last 20 samples
stored in a vector (qdelay_fraction_hist). This vector is used in are stored in a vector (qdelay_fraction_hist). This vector is used
the computation of an qdelay trend that gives a value between 0.0 and in the computation of a qdelay trend that gives a value between 0.0
1.0 depending on the estimated congestion level. The prediction and 1.0 depending on the estimated congestion level. The prediction
coefficient 'a_t' has positive values if qdelay shows an increasing coefficient 'a_t' has positive values if qdelay shows an increasing
or decreasing trend, thus an indication of congestion is obtained or decreasing trend; thus, an indication of congestion is obtained
before the qdelay target is reached. As a side effect, also the case before the qdelay target is reached. As a side effect, if qdelay
that qdelay decreases is taken as a sign of congestion, experiments decreases, it's taken as a sign of congestion; however, experiments
have however shown that this is beneficial as varying queue delay up have shown that this is beneficial, as increasing or decreasing queue
or down is an indication that the transmit rate is very close to the delay is an indication that the transmit rate is very close to the
path capacity. path capacity.
The autocorrelation function 'R' is defined as follows. Let x be a The autocorrelation function 'R' is defined as follows. Let x be a
vector constituting N values, the biased autocorrelation function for vector constituting N values, the biased autocorrelation function for
a given lag=k for the vector x is given by. a given lag=k for the vector x is given by.
n=N-k n=N-k
R(x,k) = SUM x(n)*x(n+k) R(x,k) = SUM x(n) * x(n + k)
n=1 n=1
The prediction coefficient is further multiplied with The prediction coefficient is further multiplied with
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 that could it is very small. The 50 ms sampling is a simplification that could
have the effect that the same qdelay is sampled several times, this have the effect that the same qdelay is sampled several times;
does however not pose any problem as the vector is only used to however, this does not pose any problem, as the vector is only used
determine if the qdelay is increasing or decreasing. The to determine if the qdelay is increasing or decreasing. The
qdelay_trend is utilized in the media rate control to indicate qdelay_trend is utilized in the media rate control to indicate
incipient congestion and to determine when to exit from fast increase incipient congestion and to determine when to exit from fast increase
mode. qdelay_trend_mem is used to enforce a less aggressive rate mode. qdelay_trend_mem is used to enforce a less aggressive rate
increase 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 Packet 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 is to
to limit the congestion window decrease to at most once per round limit the congestion window decrease to at most once per round trip.
trip.
The congestion window back off due to loss events is deliberately a The congestion window back-off due to loss events is deliberately a
bit less than is the case with e.g. TCP Reno. The reason is that bit less than is the case with TCP Reno, for example. TCP is
TCP is generally used to transmit whole files, which can be generally used to transmit whole files; the file is then like a
translated to an infinite source bitrate. SCReAM on the other hand source with an infinite bitrate until the whole file has been
has a source whose rate is limited to a value close to the available transmitted. SCReAM, on the other hand, has a source whose rate is
transmit rate and often below that value, the effect of this is that limited to a value close to the available transmit rate and often
SCReAM has less opportunity to grab free capacity than a TCP based below that value; the effect is that SCReAM has less opportunity to
file transfer. To compensate for this it is RECOMMENDED to let grab free capacity than a TCP-based file transfer. To compensate for
SCReAM reduce the congestion window less than what is the case with this, it is RECOMMENDED to let SCReAM reduce the congestion window
TCP when loss events occur. less than what is the case with 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 is to limit the congestion window
window decrease to at most once per round trip. The congestion decrease to at most once per round trip. The congestion window back-
window back off due to an ECN event MAY be smaller than if a loss off due to an ECN event MAY be smaller than if a loss event occurs.
event occurs. This is in line with the idea outlined in This is in line with the idea outlined in [ALT-BACKOFF] to enable ECN
[I-D.ietf-tcpm-alternativebackoff-ecn] to enable ECN marking marking thresholds lower than the corresponding packet drop
thresholds lower than the corresponding packet drop thresholds. thresholds.
4.1.2.2. Congestion window update 4.1.2.2. Congestion Window Update
The update of the congestion window depends on whether loss or ECN- The update of the congestion window depends on if loss, ECN-marking,
marking or neither occurs. The pseudo code below describes actions or neither of the two occurs. The pseudocode below describes the
taken in case of the different events. actions for each case.
<CODE BEGINS> <CODE BEGINS>
on congestion event(qdelay): on congestion event(qdelay):
# Either loss or ECN mark is detected # Either loss or ECN mark is detected
in_fast_increase = false in_fast_increase = false
if (is loss) if (is loss)
# Loss is detected # Loss is detected
cwnd = max(MIN_CWND,cwnd*BETA_LOSS) cwnd = max(MIN_CWND, cwnd * BETA_LOSS)
else else
# No loss, so it is then an ECN mark # No loss, so it is then an ECN mark
cwnd = max(MIN_CWND,cwnd*BETA_ECN) cwnd = max(MIN_CWND, cwnd * BETA_ECN)
end end
adjust_qdelay_target(qdelay) #compensating for competing flows adjust_qdelay_target(qdelay) #compensating for competing flows
calculate_send_window(qdelay,qdelay_target) calculate_send_window(qdelay, qdelay_target)
# When no congestion event # When no congestion event
on acknowledgement(qdelay): on acknowledgement(qdelay):
update_bytes_newly_acked() update_bytes_newly_acked()
update_cwnd(bytes_newly_acked) update_cwnd(bytes_newly_acked)
adjust_qdelay_target(qdelay) #compensating for competing flows adjust_qdelay_target(qdelay) # compensating for competing flows
calculate_send_window(qdelay, qdelay_target) calculate_send_window(qdelay, qdelay_target)
check_to_resume_fast_increase() check_to_resume_fast_increase()
<CODE ENDS> <CODE ENDS>
The methods are further described in detail below. The methods are described in detail below.
The congestion window update is based on qdelay, except for the The congestion window update is based on qdelay, except for the
occurrence of loss events (one or more lost RTP packets in one RTT), occurrence of loss events (one or more lost RTP packets in one RTT)
or ECN events, which was described earlier. or ECN events, which were described earlier.
Pseudo code for the update of the congestion window is found below. Pseudocode for the update of the congestion window is found below.
<CODE BEGINS> <CODE BEGINS>
update_cwnd(bytes_newly_acked): update_cwnd(bytes_newly_acked):
# In fast increase ? # In fast increase mode?
if (in_fast_increase) if (in_fast_increase)
if (qdelay_trend >= QDELAY_TREND_TH) if (qdelay_trend >= QDELAY_TREND_TH)
# Incipient congestion detected, exit fast increase # Incipient congestion detected; exit fast increase mode
in_fast_increase = false in_fast_increase = false
else else
# No congestion yet, increase cwnd if it # No congestion yet; increase cwnd if it
# is sufficiently used # is sufficiently used
# An additional slack of bytes_newly_acked is # Additional slack of bytes_newly_acked is
# added to ensure that CWND growth occurs # added to ensure that CWND growth occurs
# even when feedback is sparse # even when feedback is sparse
if (bytes_in_flight*1.5+bytes_newly_acked > cwnd) if (bytes_in_flight * 1.5 + bytes_newly_acked > cwnd)
cwnd = cwnd+bytes_newly_acked cwnd = cwnd + bytes_newly_acked
end end
return return
end end
end end
# Not in fast increase phase # Not in fast increase mode
# off_target calculated as with LEDBAT # off_target calculated as with LEDBAT
off_target_t = (qdelay_target - qdelay) / qdelay_target off_target_t = (qdelay_target - qdelay) / qdelay_target
gain_t = GAIN gain_t = GAIN
# Adjust congestion window # Adjust congestion window
cwnd_delta_t = cwnd_delta_t =
gain_t * off_target_t * bytes_newly_acked * MSS / cwnd gain_t * off_target_t * bytes_newly_acked * MSS / cwnd
if (off_target_t > 0 && if (off_target_t > 0 &&
bytes_in_flight*1.25+bytes_newly_acked <= cwnd) bytes_in_flight * 1.25 + bytes_newly_acked <= cwnd)
# No cwnd increase if window is underutilized # No cwnd increase if window is underutilized
# An additional slack of bytes_newly_acked is # Additional slack of bytes_newly_acked is
# added to ensure that CWND growth occurs # added to ensure that CWND growth occurs
# even when feedback is sparse # even when feedback is sparse
cwnd_delta_t = 0; cwnd_delta_t = 0;
end end
# Apply delta # Apply delta
cwnd += cwnd_delta_t cwnd += cwnd_delta_t
# limit cwnd to the maximum number of bytes in flight # limit cwnd to the maximum number of bytes in flight
cwnd = min(cwnd, max_bytes_in_flight*MAX_BYTES_IN_FLIGHT_HEAD_ROOM) cwnd = min(cwnd, max_bytes_in_flight *
MAX_BYTES_IN_FLIGHT_HEAD_ROOM)
cwnd = max(cwnd, MIN_CWND) cwnd = max(cwnd, MIN_CWND)
<CODE ENDS> <CODE ENDS>
CWND is updated differently depending on whether or not the
CWND is updated differently depending on whether the congestion congestion control is in fast increase mode, 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 mode, the congestion window is increased with
the number of newly acknowledged bytes as long as the window is the number of newly acknowledged bytes as long as the window is
sufficiently used. Sparse feedback can potentially limit congestion sufficiently used. Sparse feedback can potentially limit congestion
window growth, an additional slack is therefore added, given by the window growth; therefore, additional slack is added, given by the
number of newly acknowledged bytes. number of newly acknowledged bytes.
The congestion window growth when in_fast_increase is false is The congestion window growth when in_fast_increase is false is
dictated by the relation between qdelay and qdelay_target, congestion dictated by the relation between qdelay and qdelay_target; congestion
window growth is limited if the window is not used sufficiently. window growth is limited if the window is not used sufficiently.
SCReAM calculates the GAIN in a similar way to what is specified in SCReAM calculates the GAIN in a similar way to what is specified in
[RFC6817]. However, [RFC6817] specifies that the CWND increase is [RFC6817]. However, [RFC6817] specifies that the CWND increase is
limited by an additional function controlled by a constant limited by an additional function controlled by a constant
ALLOWED_INCREASE. This additional limitation is removed in this ALLOWED_INCREASE. This additional limitation is removed in this
specification. specification.
Further the CWND is limited by max_bytes_in_flight and MIN_CWND. The Further, the CWND is limited by max_bytes_in_flight and MIN_CWND.
limitation of the congestion window by the maximum number of bytes in The limitation of the congestion window by the maximum number of
flight over the last 5 seconds (max_bytes_in_flight) avoids possible bytes in flight over the last 5 seconds (max_bytes_in_flight) avoids
over-estimation of the throughput after for example, idle periods. possible overestimation of the throughput after, for example, idle
An additional MAX_BYTES_IN_FLIGHT_HEAD_ROOM allows for a slack, to periods. An additional MAX_BYTES_IN_FLIGHT_HEAD_ROOM provides slack
allow for a certain amount of media coder output rate variability. to allow for a certain amount of variability in the media coder
output rate.
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 the SCReAM algorithm will have to
congested bottlenecks with other flows that use a more aggressive share congested bottlenecks with other flows that use a more
congestion control algorithm, examples are large FTP flows using loss aggressive congestion control algorithm (for example, large FTP flows
based congestion control. The worst condition occurs when the using loss-based congestion control). The worst condition occurs
bottleneck queues are of tail-drop type with a large buffer size. when the bottleneck queues are of tail-drop type with a large buffer
SCReAM takes care of such situations by adjusting the qdelay_target size. SCReAM takes care of such situations by adjusting the
when loss based flows are detected, as given by the pseudo code qdelay_target when loss-based flows are detected, as shown in the
below. pseudocode 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))
# Compute upper limit to target delay # Compute upper limit to target delay
new_target_t = qdelay_norm_avg_t + sqrt(qdelay_norm_var_t) new_target_t = qdelay_norm_avg_t + sqrt(qdelay_norm_var_t)
new_target_t *= QDELAY_TARGET_LO new_target_t *= QDELAY_TARGET_LO
if (loss_event_rate > 0.002) if (loss_event_rate > 0.002)
# Packet losses detected # Packet losses detected
qdelay_target = 1.5*new_target_t qdelay_target = 1.5 * new_target_t
else else
if (qdelay_norm_var_t < 0.2) if (qdelay_norm_var_t < 0.2)
# Reasonably safe to set target qdelay # Reasonably safe to set target qdelay
qdelay_target = new_target_t qdelay_target = new_target_t
else else
# Check if target delay can be reduced, this helps to avoid # Check if target delay can be reduced; this helps prevent
# that the target delay is locked to high values for ever # the target delay from being locked to high values forever
if (new_target_t < QDELAY_TARGET_LO) if (new_target_t < QDELAY_TARGET_LO)
# Decrease target delay quickly as measured queueing # Decrease target delay quickly, as measured queuing
# delay is lower than target # delay is lower than target
qdelay_target = max(qdelay_target*0.5,new_target_t) qdelay_target = max(qdelay_target * 0.5, new_target_t)
else else
# Decrease target delay slowly # Decrease target delay slowly
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>
Two temporary variables are calculated. qdelay_norm_avg_t is the long Two temporary variables are calculated. qdelay_norm_avg_t is the
term average queue delay, qdelay_norm_var_t is the long term variance long-term average queue delay, qdelay_norm_var_t is the long-term
of the queue delay. A high qdelay_norm_var_t indicates that the variance of the queue delay. A high qdelay_norm_var_t indicates that
queue delay changes, this can be an indication of reduced bottleneck the queue delay changes; this can be an indication that bottleneck
bandwidth or that a competing flow has just entered. Thus, it bandwidth is reduced or that a competing flow has just entered.
indicates that it is not safe to adjust the queue delay target. Thus, it indicates that it is not safe to adjust the queue delay
target.
A low qdelay_norm_var_t indicates that the queue delay is relatively A low qdelay_norm_var_t indicates that the queue delay is relatively
stable, the reason can be that the queue delay is low but it can also stable. The reason could be that the queue delay is low, but it
be an indication that a competing flow is filling up the bottleneck could also be that a competing flow is causing the bottleneck to
to the limit where packet losses may start to occur, in which case reach the point that packet losses start to occur, in which case the
the queue delay will stay relatively high for a longer time. queue delay will stay relatively high for a longer time.
The queue delay target is allowed to be increased if, either the loss The queue delay target is allowed to be increased if either the loss
event rate is above a given threshold or that qdelay_norm_var_t is event rate is above a given threshold or qdelay_norm_var_t is low.
low. Both these conditions indicate that a competing flow may be Both these conditions indicate that a competing flow may be present.
present. In all other cases the queue delay target is decreased. In all other cases, the queue delay target is decreased.
The function that adjusts the qdelay_target is simple and has a The function that adjusts the qdelay_target is simple and could
certain risk to produce both false positive and negatives, The case produce false positives and false negatives. The case that self-
that self-inflicted congestion by the SCReAM algorithm may be falsely inflicted congestion by the SCReAM algorithm may be falsely
interpreted as the presence of competing loss based FTP flows is a interpreted as the presence of competing loss-based FTP flows is a
false positive. The opposite case where the algorithm fails to false positive. The opposite case -- where the algorithm fails to
detect the presence of a competing FTP flow is a false negative. detect the presence of a competing FTP flow -- is a false negative.
Extensive simulations have shown that the algorithm performs well in Extensive simulations have shown that the algorithm performs well in
LTE test cases and that it also performs well in simple bandwidth LTE test cases and that it also performs well in simple bandwidth-
limited bottleneck test cases with competing FTP flows. It can limited bottleneck test cases with competing FTP flows. However, the
however not be completely ruled out that this algorithm can fail. potential failure of the algorithm cannot be completely ruled out. A
Especially the false positives can be problematic as the end to end false positive (i.e., when self-inflicted congestion is mistakenly
delay can increase dramatically if the target queue delay is identified as competing flows) is especially problematic when it
increased by accident as a result of self-inflicted congestion. leads to increasing the target queue delay, which can cause the end-
to-end delay to increase dramatically.
If it is deemed unlikely that competing flows occur over the same If it is deemed unlikely that competing flows occur over the same
bottleneck, the algorithm described in this section MAY be turned bottleneck, the algorithm described in this section MAY be turned
off. One such case can be QoS enabled bearers in 3GPP based access off. One such case is QoS-enabled bearers in 3GPP-based access such
such as LTE. However, when sending over the Internet, often the as LTE. However, when sending over the Internet, often the network
network conditions are not known for sure and it is in general not conditions are not known for sure, so in general it is not possible
possible to make safe assumptions on how a network is used and to make safe assumptions on how a network is used and whether or not
whether or not competing flows share the same bottleneck. Therefore competing flows share the same bottleneck. Therefore, turning this
turning this algorithm off must be considered with caution as that algorithm off must be considered with caution, as it can lead to
can lead to basically zero throughput if competing with other, loss basically zero throughput if competing with loss-based traffic.
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 prevent packet reordering
triggers loss events. from triggering loss events. The reordering window is specified as a
The reordering window is specified as a time unit, similar to the time unit, similar to the ideas behind Recent ACKnowledgement (RACK)
ideas behind RACK (Recent ACKnowledgement) [I-D.ietf-tcpm-rack]. The [RACK]. The computation of the reordering window is made possible by
computation of the reordering window is made possible by means of a means of a lost flag in the list of transmitted RTP packets. This
lost flag in the list of transmitted RTP packets. This flag is set flag is set if the received sequence number list indicates that the
if the received sequence number list indicates that the given RTP given RTP packet is missing. If later feedback indicates that a
packet is missing. If a later feedback indicates that a previously previously lost marked packet was indeed received, then the
lost marked packet was indeed received, then the reordering window is reordering window is updated to reflect the reordering delay. The
updated to reflect the reordering delay. The reordering window is reordering window is given by the difference in time between the
given by the difference in time between the event that the packet was event that the packet was marked as lost and the event that it was
marked as lost and the event that it was indicated as successfully indicated as successfully received. Loss is detected if a given RTP
received. packet is not acknowledged within a time window (indicated by the
Loss is detected if a given RTP packet is not acknowledged within a reordering window) after an RTP packet with a higher sequence number
time window (indicated by the reordering window) after an RTP packet 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
rule will not work optimally: strict rule will not work optimally:
o Bitrate variations: Media sources such as video encoders generally o Bitrate variations: Media sources such as video encoders generally
produce frames whose size always vary to a larger or smaller produce frames whose size always vary to a larger or smaller
extent. The RTP queue absorbs the natural variations in frame extent. The RTP queue absorbs the natural variations in frame
sizes. The RTP queue should however be as short as possible, to sizes. However, the RTP queue should be as short as possible to
avoid that the end to end delay increases. To achieve that, the prevent the end-to-end delay from increasing. To achieve that,
media rate control takes the RTP queue size into account when the the media rate control takes the RTP queue size into account when
target bitrate for the media is computed. A strict 'send only the target bitrate for the media is computed. A strict 'send only
when bytes in flight is less than the congestion window' rule can 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 cause the RTP queue to grow simply because the send window is
limited, the effect of which would be that the target bitrate is limited; in turn, this can cause the target bitrate to be pushed
pushed down. The consequence of this is that the congestion down. The consequence is that the congestion window will not
window will not increase, or will increase very slowly, because increase, or will increase very slowly, because the congestion
the congestion window is only allowed to increase when there is a window is only allowed to increase when there is a sufficient
sufficient amount of data in flight. The end effect is then that amount of data in flight. The final effect is that the media
the media bitrate increases very slowly or not at all. 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 is that the
the acknowledgements are delayed with the result that the self- acknowledgements are delayed, and the self-clocking is temporarily
clocking is temporarily halted, even though the forward path is 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, its relation to the
the qdelay target and the relation between the congestion window and qdelay target, and the relation between the congestion window and the
the number of bytes in flight. A strict rule is applied when qdelay number of bytes in flight. A strict rule is applied when qdelay is
is higher than qdelay_target, to avoid further queue buildup in the higher than qdelay_target, to avoid further queue buildup in the
network. For cases when qdelay is lower than the qdelay_target, a network. For cases when qdelay is lower than the qdelay_target, a
more relaxed rule is applied. This allows the bitrate to increase more relaxed rule is applied. This allows the bitrate to increase
quickly when no congestion is detected while still being able to give quickly when no congestion is detected while still being able to
a stable behavior in congested situations. exhibit stable behavior in congested situations.
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. pseudocode below.
<CODE BEGINS> <CODE BEGINS>
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 end
<CODE ENDS> <CODE ENDS>
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. an RTCP feedback messaged is received.
4.1.2.6. Packet pacing 4.1.2.6. Packet Pacing
Packet pacing is used in order to mitigate coalescing i.e. that Packet pacing is used in order to mitigate coalescing, i.e., when
packets are transmitted in bursts, with the increased risk of more packets are transmitted in bursts, with the risks of increased jitter
jitter and potentially increased packet loss. Packet pacing also and potentially increased packet loss. Packet pacing also mitigates
mitigates possible issues with queue overflow due to key-frame possible issues with queue overflow due to key-frame generation in
generation in video coders. The time interval between consecutive video coders. The time interval between consecutive packet
packet transmissions is enforced to be equal to or higher than t_pace transmissions is greater than or equal to t_pace, where t_pace is
where t_pace is given by the equations below : given by the equations below :
<CODE BEGINS> <CODE BEGINS>
pace_bitrate = max (RATE_PACE_MIN, cwnd* 8 / s_rtt) pace_bitrate = max (RATE_PACE_MIN, cwnd * 8 / s_rtt)
t_pace = rtp_size * 8 / pace_bitrate t_pace = rtp_size * 8 / pace_bitrate
<CODE ENDS> <CODE ENDS>
rtp_size is the size of the last transmitted RTP packet, s_rtt is the rtp_size is the size of the last transmitted RTP packet, and s_rtt is
smoothed round trip time. RATE_PACE_MIN is the minimum pacing rate. the smoothed round trip time. RATE_PACE_MIN is the minimum pacing
rate.
4.1.2.7. Resuming fast increase 4.1.2.7. Resuming Fast Increase Mode
Fast increase can resume in order to speed up the bitrate increase in Fast increase mode can resume in order to speed up the bitrate
case congestion abates. The condition to resume fast increase increase if congestion abates. The condition to resume fast increase
(in_fast_increase = true) is that qdelay_trend is less than mode (in_fast_increase = true) is that qdelay_trend is less than
QDELAY_TREND_LO for T_RESUME_FAST_INCREASE seconds or more. QDELAY_TREND_LO for T_RESUME_FAST_INCREASE seconds or more.
4.1.2.8. Stream prioritization 4.1.2.8. Stream Prioritization
The SCReAM algorithm makes a good distinction between network The SCReAM algorithm makes a good distinction between network
congestion control and the media rate control. This is easily congestion control and media rate control. This is easily extended
extended to many streams, in which case RTP packets from two or more to many streams -- RTP packets from two or more RTP queues are
RTP queues are scheduled at the rate permitted by the network scheduled at the rate permitted by the network congestion control.
congestion control.
The scheduling can be done by means of a few different scheduling The scheduling can be done by means of a few different scheduling
regimes. For example the method applied in regimes. For example, the method for coupled congestion control
specified in [COUPLED-CC] can be used. One implementation of SCReAM
[I-D.ietf-rmcat-coupled-cc] can be used. The implementation of [SCReAM-CPP-implementation] uses credit-based scheduling. In credit-
SCReAM [SCReAM-CPP-implementation] use credit based scheduling. In based scheduling, credit is accumulated by queues as they wait for
credit based scheduling, credit is accumulated by queues as they wait service and is spent while the queues are being serviced. For
for service and are spent while the queues are being serviced. For instance, if one queue is allowed to transmit 1000 bytes, then a
instance, if one queue is allowed to transmit 1000bytes, then a credit of 1000 bytes is allocated to the other unscheduled queues.
credit of 1000bytes is allocated to the other unscheduled queues. This principle can be extended to weighted scheduling, where the
This principle can be extended to weighted scheduling in which case credit allocated to unscheduled queues depends on the relative
the credit allocated to unscheduled queues depends on the relative
weights. The latter is also implemented in weights. The latter is also implemented in
[SCReAM-CPP-implementation]. [SCReAM-CPP-implementation].
4.1.3. Media rate control 4.1.3. Media Rate Control
The media rate control algorithm is executed at regular intervals The media rate control algorithm is executed at regular intervals,
RATE_ADJUSTMENT_INTERVAL, with the exception of a prompt reaction to indicated by RATE_ADJUSTMENT_INTERVAL, with the exception of a prompt
loss events. The media rate control operates based on the size of reaction to loss events. The media rate control operates based on
the RTP packet send queue and observed loss events. In addition, the size of the RTP packet send queue and observed loss events. In
qdelay_trend is also considered in the media rate control to reduce addition, qdelay_trend is also considered in the media rate control
the amount of induced network jitter. in order to reduce the amount of induced network jitter.
The role of the media rate control is to strike a reasonable balance The role of the media rate control is to strike a reasonable balance
between a low amount of queuing in the RTP queue(s) and a sufficient between a low amount of queuing in the RTP queue(s) and a sufficient
amount of data to send in order to keep the data path busy. A too amount of data to send in order to keep the data path busy. Setting
cautious setting leads to possible under-utilization of network the media rate control too cautiously leads to possible
capacity leading to that the flow can become starved out by other underutilization of network capacity; this can cause the flow to
more opportunistic traffic. On the other hand, a too aggressive become starved out by other more opportunistic traffic. On the other
setting leads to increased jitter. hand, setting it too aggressively leads to increased jitter.
The target_bitrate is adjusted depending on the congestion state. The target_bitrate is adjusted depending on the congestion state.
The target bitrate can vary between a minimum value The target bitrate can vary between a minimum value
(TARGET_BITRATE_MIN) and a maximum value (TARGET_BITRATE_MAX). (TARGET_BITRATE_MIN) and a maximum value (TARGET_BITRATE_MAX).
TARGET_BITRATE_MIN SHOULD be chosen to a low enough value to avoid TARGET_BITRATE_MIN SHOULD be set to a low enough value to prevent RTP
that RTP packets become queued up when the network throughput is packets from becoming queued up when the network throughput is
reduced. The sender SHOULD also be equipped with a mechanism that reduced. The sender SHOULD also be equipped with a mechanism that
discards RTP packets in cases where the network throughput becomes discards RTP packets when the network throughput becomes very low and
very low and RTP packets are excessively delayed. RTP packets are excessively delayed.
For the overall bitrate adjustment, two network throughput estimates For the overall bitrate adjustment, two network throughput estimates
are computed : are computed :
o rate_transmit: The measured transmit bitrate. o rate_transmit: The measured transmit bitrate.
o rate_ack: The ACKed bitrate, i.e. the volume of ACKed bits per o rate_ack: The ACKed bitrate, i.e., the volume of ACKed bits per
second. second.
Both estimates are updated every 200ms. Both estimates are updated every 200 ms.
The current throughput, current_rate, is computed as the maximum The current throughput, current_rate, is computed as the maximum
value of rate_transmit and rate_ack. The rationale behind the use of value of rate_transmit and rate_ack. The rationale behind the use of
rate_ack in addition to rate_transmit is that rate_transmit is rate_ack in addition to rate_transmit is that rate_transmit is
affected also by the amount of data that is available to transmit, affected also by the amount of data that is available to transmit,
thus a lack of data to transmit can be seen as reduced throughput thus a lack of data to transmit can be seen as reduced throughput
that can itself cause an unnecessary rate reduction. To overcome that can cause an unnecessary rate reduction. To overcome this
this shortcoming; rate_ack is used as well. This gives a more stable shortcoming, rate_ack is used as well. This gives a more stable
throughput estimate. throughput estimate.
The rate change behavior depends on whether a loss or ECN event has The rate change behavior depends on whether a loss or ECN event has
occurred and if the congestion control is in fast increase or not. occurred and whether the congestion control is in fast increase mode.
<CODE BEGINS> <CODE BEGINS>
# 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:
# Loss event detected # Loss event detected
target_bitrate = max(BETA_R* target_bitrate, TARGET_BITRATE_MIN) target_bitrate = max(BETA_R * target_bitrate,
TARGET_BITRATE_MIN)
exit exit
on ecn_mark: on ecn_mark:
# ECN event detected # ECN event detected
target_bitrate = max(BETA_ECN* target_bitrate, TARGET_BITRATE_MIN) target_bitrate = max(BETA_ECN * target_bitrate,
TARGET_BITRATE_MIN)
exit exit
ramp_up_speed_t = min(RAMP_UP_SPEED, target_bitrate/2.0) ramp_up_speed_t = min(RAMP_UP_SPEED, target_bitrate / 2.0)
scale_t = (target_bitrate - target_bitrate_last_max)/ scale_t = (target_bitrate - target_bitrate_last_max) /
target_bitrate_last_max target_bitrate_last_max
scale_t = max(0.2, min(1.0, (scale_t*4)^2)) scale_t = max(0.2, min(1.0, (scale_t * 4)^2))
# min scale_t value 0.2 as the bitrate should be allowed to # min scale_t value 0.2, as the bitrate should be allowed to
# increase at least slowly --> avoid locking the rate to # increase slowly. This prevents locking the rate to
# target_bitrate_last_max # target_bitrate_last_max
if (in_fast_increase = true) if (in_fast_increase = true)
increment_t = ramp_up_speed_t*RATE_ADJUST_INTERVAL increment_t = ramp_up_speed_t * RATE_ADJUST_INTERVAL
increment_t *= scale_t increment_t *= scale_t
target_bitrate += increment_t target_bitrate += increment_t
else else
current_rate_t = max(rate_transmit, rate_ack) current_rate_t = max(rate_transmit, rate_ack)
# Compute a bitrate change # Compute a bitrate change
delta_rate_t = current_rate_t*(1.0-PRE_CONGESTION_GUARD* delta_rate_t = current_rate_t * (1.0 - PRE_CONGESTION_GUARD *
queue_delay_trend)-TX_QUEUE_SIZE_FACTOR *rtp_queue_size queue_delay_trend) - TX_QUEUE_SIZE_FACTOR * rtp_queue_size
# Limit a positive increase if close to target_bitrate_last_max # Limit a positive increase if close to target_bitrate_last_max
if (delta_rate_t > 0) if (delta_rate_t > 0)
delta_rate_t *= scale_t delta_rate_t *= scale_t
delta_rate_t = delta_rate_t =
min(delta_rate_t,ramp_up_speed_t*RATE_ADJUST_INTERVAL) min(delta_rate_t, ramp_up_speed_t * RATE_ADJUST_INTERVAL)
end end
target_bitrate += delta_rate_t target_bitrate += delta_rate_t
# Force a slight reduction in bitrate if RTP queue # Force a slight reduction in bitrate if RTP queue
# builds up # builds up
rtp_queue_delay_t = rtp_queue_size/current_rate_t rtp_queue_delay_t = rtp_queue_size / current_rate_t
if (rtp_queue_delay_t > RTP_QDELAY_TH) if (rtp_queue_delay_t > RTP_QDELAY_TH)
target_bitrate *= TARGET_RATE_SCALE_RTP_QDELAY target_bitrate *= TARGET_RATE_SCALE_RTP_QDELAY
end end
end end
rate_media_limit_t = rate_media_limit_t =
max(current_rate_t, max(rate_media,rtp_rate_median)) max(current_rate_t, max(rate_media, rtp_rate_median))
rate_media_limit_t *= (2.0-qdelay_trend_mem) rate_media_limit_t *= (2.0 - qdelay_trend_mem)
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))
<CODE ENDS> <CODE ENDS>
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
continues. The rationale behind the rate reduction due to loss is continues. The rationale behind the rate reduction due to loss is
that a congestion window reduction will take effect, a rate reduction that a congestion window reduction will take effect, and a rate
pro actively avoids RTP packets being queued up when the transmit reduction proactively prevents RTP packets from being queued up when
rate decreases due to the reduced congestion window. A similar rate the transmit rate decreases due to the reduced congestion window. A
reduction happens when ECN events are detected. similar rate reduction happens when ECN events are detected.
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
life limitations in video coders taken into account real-life limitations in video coders taken into account
[SCReAM-CPP-implementation]. A too short interval is shown to make [SCReAM-CPP-implementation]. A too short interval is shown to make
the rate control loop in video coders more unstable, a too long the rate control loop in video coders more unstable; a too long
interval makes the overall congestion control sluggish. interval makes the overall congestion control sluggish.
When in fast increase state (in_fast_increase=true), the bitrate When in fast increase mode (in_fast_increase = true), the bitrate
increase is given by the desired ramp-up speed (RAMP_UP_SPEED) . The increase is given by the desired ramp-up speed (RAMP_UP_SPEED). The
ramp-up speed is limited when the target bitrate is low to avoid rate ramp-up speed is limited when the target bitrate is low to avoid rate
oscillation at low bottleneck bitrates. The setting of RAMP_UP_SPEED oscillation at low bottleneck bitrates. The setting of RAMP_UP_SPEED
depends on preferences, a high setting such as 1000kbps/s makes it depends on preferences. A high setting such as 1000 kbps/s makes it
possible to quickly get high quality media, this is however at the possible to quickly get high-quality media; however, this is at the
expense of a increased jitter, which can manifest itself as e.g. expense of increased jitter, which can manifest itself as choppy
choppy video rendering. video rendering, for example.
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. detected.
Finally the target_bitrate is enforced to be within the defined min Finally, the target_bitrate is 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. As these parameters are used also in the of the qdelay_trend. As these parameters are used also in the
network congestion control one may suspect some odd interaction network congestion control, one may suspect some odd interaction
between the media rate control and the network congestion control, between the media rate control and the network congestion control.
this is in fact the case if the parameter PRE_CONGESTION_GUARD is set This is in fact the case if the parameter PRE_CONGESTION_GUARD is set
to a high value. The use of qdelay_trend in the media rate control to a high value. The use of qdelay_trend in the media rate control
is solely to reduce jitter, the dependency can be removed by setting is solely to reduce 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 larger rate
after congestion, at the expense of increased jitter in congested increase after congestion, at the expense of increased jitter in
situations. congested situations.
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 feed back
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 MUST maintain enough information to send the RTP packet, the receiver MUST maintain enough information to send the
aforementioned values to the SCReAM sender via a RTCP transport layer aforementioned values to the SCReAM sender via an RTCP transport-
feedback message. The frequency of the feedback message depends on layer feedback message. The frequency of the feedback message
the available RTCP bandwidth. The requirements on the feedback depends on the available RTCP bandwidth. The requirements on the
elements and the feedback interval is described. feedback elements and the feedback interval are described below.
4.2.1. Requirements on feedback elements 4.2.1. Requirements on Feedback Elements
The following feedback elements are REQUIRED for the basic The following feedback elements are REQUIRED for basic functionality
functionality in SCReAM. in SCReAM.
o A list of received RTP packets. This list SHOULD be sufficiently o A list of received RTP packets. This list SHOULD be sufficiently
long to cover all received RTP packets. This list can be realized long to cover all received RTP packets. This list can be realized
with the Loss RLE report block in [RFC3611]. with the Loss RLE (Run Length Encoding) Report Block in [RFC3611].
o A wall clock timestamp corresponding to the received RTP packet o A wall-clock timestamp corresponding to the received RTP packet
with the highest sequence number is required in order to compute with the highest sequence number is required in order to compute
the qdelay. This can be realized by means of the Packet Receipt the qdelay. This can be realized by means of the Packet Receipt
Times Report Block in [RFC3611]. begin_seq MUST be set to the Times Report Block in [RFC3611]. begin_seq MUST be set to the
highest received (possibly wrapped around) sequence number, highest received sequence number (which has possibly wrapped
end_seq MUST be set to begin_seq+1 % 65536. The timestamp clock around); end_seq MUST be set to begin_seq+1 modulo 65536. The
MAY be set according to [RFC3611] i.e. equal to the RTP timestamp timestamp clock MAY be set according to [RFC3611], i.e., equal to
clock. Detailed individual packet receive times is not necessary the RTP timestamp clock. Detailed individual packet receive times
as SCReAM does currently not describe how this can be used. are not necessary, as SCReAM does currently not describe how they
can be used.
The basic feedback needed for SCReAM involves the use of the Loss RLE The basic feedback needed for SCReAM involves the use of the Loss RLE
report block and the Packet Receipt Times block defined in Figure 2. Report Block and the Packet Receipt Times Report Block as shown in
Figure 2.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|reserved | PT=XR=207 | length | |V=2|P|reserved | PT=XR=207 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC | | SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=2 | rsvd. | T=0 | block length | | BT=2 | rsvd. | T=0 | block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 28, line 33 skipping to change at page 29, line 37
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=3 | rsvd. | T=0 | block length | | BT=3 | rsvd. | T=0 | block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source | | SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | end_seq | | begin_seq | end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receipt time of packet begin_seq | | Receipt time of packet begin_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Basic feedback message for SCReAM, based on RFC3611 Figure 2: Basic Feedback Message for SCReAM, Based on RFC 3611
In a typical use case, no more than four Loss RLE chunks are needed, In a typical use case, no more than four Loss RLE chunks are needed,
thus the feedback message will be 44bytes. It is obvious from the thus the feedback message will be 44 bytes. It is obvious from
figure that there is a lot of redundant information in the feedback Figure 2 that there is a lot of redundant information in the feedback
message. A more optimized feedback format, including the additional message. A more optimized feedback format, including the additional
feedback elements listed below, could reduce the feedback message feedback elements listed below, could reduce the feedback message
size a bit. size a bit.
Additional feedback elements that can improve the performance of An additional feedback element that can improve the performance of
SCReAM are: SCReAM is:
o Accumulated number of ECN-CE marked packets (n_ECN). This can for o Accumulated number of ECN-CE-marked packets (n_ECN). For
instance be realized with the ECN Feedback Report Format in instance, this can be realized with the ECN Feedback Report Format
[RFC6679]. The given feedback report format is actually a slight in [RFC6679]. The given feedback report format is slightly
overkill as SCReAM would do quite well with only a counter that overkill, as SCReAM would do quite well with only a counter that
increments by one for each received packet with the ECN-CE code increments by one for each received packet with the ECN-CE
point set. The more bulky format could nevertheless be useful for codepoint set. The more bulky format could nevertheless be useful
e.g ECN black-hole detection. for, e.g., ECN black-hole detection.
4.2.2. Requirements on feedback intensity 4.2.2. Requirements on Feedback Intensity
SCReAM benefits from a relatively frequent feedback. It is SCReAM benefits from relatively frequent feedback. It is RECOMMENDED
RECOMMENDED that a SCReAM implementation follows the guidelines that a SCReAM implementation follows the guidelines below.
below.
The feedback interval depends on the media bitrate. At low bitrates The feedback interval depends on the media bitrate. At low bitrates,
it is sufficient with a feedback interval of 100 to 400ms, while at it is sufficient with a feedback interval of 100 to 400 ms; while at
high bitrates a feedback interval of roughly 20ms is to prefer, at high bitrates, a feedback interval of roughly 20 ms is preferred. At
very high bitrates, even shorter feedback intervals MAY be needed in very high bitrates, even shorter feedback intervals MAY be needed in
order to keep the self-clocking in SCReAM working well. One piece of order to keep the self-clocking in SCReAM working well. One
evidence of a too sparse feedback is that the SCReAM implementation indication that feedback is too sparse is that the SCReAM
cannot reach high bitrates, even in uncongested links. A more implementation cannot reach high bitrates, even in uncongested links.
frequent feedback might solve this issue. More frequent feedback might solve this issue.
The numbers above can be formulated as feedback interval function The numbers above can be formulated as a feedback interval function
that can be useful for the computation of the desired RTCP bandwidth. that can be useful for the computation of the desired RTCP bandwidth.
The following equation expresses the feedback rate: The following equation expresses the feedback rate:
rate_fb = min(50,max(2.5,rate_media/10000)) rate_fb = min(50, max(2.5, rate_media / 10000))
rate_media is the RTP media bitrate expressed in [bits/s], rate_fb is rate_media is the RTP media bitrate expressed in bps; rate_fb is the
the feedback rate expressed in [packets/s]. Converted to feedback feedback rate expressed in packets/s. Converting to feedback
interval we get: interval, we get:
fb_int = 1.0/min(50,max(2.5,rate_media/10000)) fb_int = 1.0 / min(50, max(2.5, rate_media / 10000))
The transmission interval is not critical, this means that in the The transmission interval is not critical. So, in the case of multi-
case of multi-stream handling between two hosts, the feedback for two stream handling between two hosts, the feedback for two or more
or more SSRCs can be bundled to save UDP/IP overhead, the final synchronization sources (SSRCs) can be bundled to save UDP/IP
realized feedback interval SHOULD however not exceed 2*fb_int in such overhead. However, the final realized feedback interval SHOULD not
cases meaning that a scheduled feedback transmission event should not exceed 2*fb_int in such cases, meaning that a scheduled feedback
be delayed more that fb_int. transmission event should not be delayed more than fb_int.
SCReAM works with AVPF regular mode, immediate or early mode is not SCReAM works with AVPF regular mode; immediate or early mode is not
required by SCReAM but can nonetheless be useful for e.g RTCP required by SCReAM but can nonetheless be useful for RTCP messages
messages not directly related to SCReAM, such as those specified in not directly related to SCReAM, such as those specified in [RFC4585].
[RFC4585]. It is RECOMMENDED to use reduced size RTCP [RFC5506] It is RECOMMENDED to use reduced-size RTCP [RFC5506], where regular
where regular full compound RTCP transmission is controlled by trr- full compound RTCP transmission is controlled by trr-int as described
int as described in [RFC4585]. in [RFC4585].
5. Discussion 5. Discussion
This section covers a few discussion points This section covers a few discussion points.
o Clock drift: SCReAM can suffer from the same issues with clock o Clock drift: SCReAM can suffer from the same issues with clock
drift as is the case with LEDBAT [RFC6817]. Section A.2 in drift as is the case with LEDBAT [RFC6817]. However, Appendix A.2
[RFC6817] however describes ways to mitigate issues with clock in [RFC6817] describes ways to mitigate issues with clock drift.
drift.
o Support for alternate ECN semantics: This specification adopts the o Support for alternate ECN semantics: This specification adopts the
proposal in [I-D.ietf-tcpm-alternativebackoff-ecn] to reduce the proposal in [ALT-BACKOFF] to reduce the congestion window less
congestion window less when ECN based congestion events are when ECN-based congestion events are detected. Future work on Low
detected. Future work on Low Loss Low Latency for Scalable Loss, Low Latency for Scalable throughput (L4S) may lead to
throughput (L4S) may lead to updates in a future RFC that updates in a future document that describes SCReAM support for
describes SCReAM support for L4S. L4S.
o A new RFC4585 transport layer feedback message could to be o A new transport-layer feedback message (as specified in RFC 4585)
standardized if the use of the already existing RTCP extensions as could be standardized if the use of the already existing RTCP
described in Section 4.2 is not deemed sufficient. extensions as described in Section 4.2 is not deemed sufficient.
o The target bitrate given by SCReAM depicts the bitrate including o The target bitrate given by SCReAM is the bitrate including the
RTP and FEC overhead. The media encoder SHOULD take this overhead RTP and Forward Error Correction (FEC) overhead. The media
into account when the media bitrate is set. This means that the encoder SHOULD take this overhead into account when the media
media coder bitrate SHOULD be computed as bitrate is set. This 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 It is not necessary to make a 100% perfect compensation for the
for the overhead as the SCReAM algorithm will inherently overhead, as the SCReAM algorithm will inherently compensate for
compensate for moderate errors. Under-compensation of the moderate errors. Under-compensating for the overhead has the
overhead has the effect of increasing jitter while effect of increasing jitter, while overcompensating will cause the
overcompensation will have the effect of causing the bottleneck bottleneck link to become underutilized.
link to become under-utilized.
6. Implementation status
[Editor's note: Please remove the whole section before publication,
as well reference to RFC 7942]
This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC7942].
The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort
has been spent to verify the information presented here that was
supplied by IETF contributors. This is not intended as, and MUST NOT
be construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations MAY
exist.
According to [RFC7942], "this will allow reviewers and working groups
to assign due consideration to documents that have the benefit of
running code, which may serve as evidence of valuable experimentation
and feedback that have made the implemented protocols more mature.
It is up to the individual working groups to use this information as
they see it".
6.1. OpenWebRTC
The SCReAM algorithm has been implemented in the OpenWebRTC project
[OpenWebRTC], an open source WebRTC implementation from Ericsson
Research. This SCReAM implementation is usable with any WebRTC
endpoint using OpenWebRTC.
o Organization : Ericsson Research, Ericsson.
o Name : OpenWebRTC gst plug-in.
o Implementation link : The GStreamer plug-in code for SCReAM can be
found at github repository [SCReAM-implementation] The wiki
(https://github.com/EricssonResearch/openwebrtc/wiki) contains
required information for building and using OpenWebRTC.
o Coverage : The code implements the specification in this memo.
The current implementation has been tuned and tested to adapt a
video stream and does not adapt the audio streams.
o Implementation experience : The implementation of the algorithm in
the OpenWebRTC has given great insight into the algorithm itself
and its interaction with other involved modules such as encoder,
RTP queue etc. In fact it proves the usability of a self-clocked
rate adaptation algorithm in the real WebRTC system. The
implementation experience has led to various algorithm
improvements both in terms of stability and design. The current
implementation use an n_loss counter for lost packets indication,
this is subject to change in later versions to a list of received
RTP packets.
o Contact : irc://chat.freenode.net/openwebrtc
6.2. A C++ Implementation of SCReAM
o Organization : Ericsson Research, Ericsson.
o Name : SCReAM.
o Implementation link : A C++ implementation of SCReAM is available
at[SCReAM-CPP-implementation]. The code includes full support for
congestion control, rate control and multi stream handling, it can
be integrated in web clients given the addition of extra code to
implement the RTCP feedback and RTP queue(s). The code also
includes a rudimentary implementation of a simulator that allows
for some initial experiments. An additional experiment with
SCReAM in a remote control arrangement is also documented.
o Coverage : The code implements the specification in this memo.
o Contact : ingemar.s.johansson@ericsson.com
7. Suggested experiments 6. Suggested Experiments
SCReAM has been evaluated in a number of different ways, most of the SCReAM has been evaluated in a number of different ways, mostly in a
evaluation has been in simulator. The OpenWebRTC implementation work simulator. The OpenWebRTC implementation work ([OpenWebRTC] and
involved extensive testing with artificial bottlenecks with varying [SCReAM-implementation]) involved extensive testing with artificial
bandwidths and using two different video coders (OpenH264 and VP9), bottlenecks with varying bandwidths and using two different video
the experience of this lead to further improvements of the media rate coders (OpenH264 and VP9).
control logic.
Further experiments are preferably done by means of implementation in Preferably, further experiments will be done by means of
real clients and web browsers. RECOMMENDED experiments are: implementation in real clients and web browsers. RECOMMENDED
experiments are:
o Trials with various access technologies: EDGE/3G/4G, WiFi, DSL. o Trials with various access technologies: EDGE/3G/4G, Wi-Fi, DSL.
Some experiments have already been carried out with LTE access, Some experiments have already been carried out with LTE access;
see e.g. [SCReAM-CPP-implementation] and see [SCReAM-CPP-implementation] and
[SCReAM-implementation-experience] [SCReAM-implementation-experience].
o Trials with different kinds of media: Audio, Video, slide show o Trials with different kinds of media: Audio, video, slideshow
content. Evaluation of multi stream handling in SCReAM. content. Evaluation of multi-stream handling in SCReAM.
o Evaluation of functionality of competing flows compensation o Evaluation of functionality of the compensation mechanism when
mechanism: Evaluate how SCReAM performs with competing TCP like there are competing flows: Evaluate how SCReAM performs with
traffic and to what extent the competing flows compensation causes competing TCP-like traffic and to what extent the compensation for
self-inflicted congestion. competing flows causes 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 very low or very high bitrates, it may be necessary
necessary to use different values for instance for the to use different values for the RAMP_UP_SPEED, for instance.
RAMP_UP_SPEED.
o Experimentation with further improvements to the congestion window o Experimentation with further improvements to the congestion window
and media bitrate calculation. [SCReAM-CPP-implementation] and media bitrate calculation. [SCReAM-CPP-implementation]
implements some optimizations, not described in this memo, that implements some optimizations, not described in this memo, that
improve performance slightly. Further experiments are likely to improve performance slightly. Further experiments are likely to
lead to more optimizations of the algorithm. lead to more optimizations of the algorithm.
8. Acknowledgements 7. IANA Considerations
We would like to thank the following persons for their comments,
questions and support during the work that led to this memo: Markus
Andersson, Bo Burman, Tomas Frankkila, Frederic Gabin, Laurits Hamm,
Hans Hannu, Nikolas Hermanns, Stefan Haakansson, Erlendur Karlsson,
Daniel Lindstroem, Mats Nordberg, Jonathan Samuelsson, Rickard
Sjoeberg, Robert Swain, Magnus Westerlund, Stefan Aalund. Many
additional thanks to RMCAT chairs Karen E. E. Nielsen and Mirja
Kuehlewind for patiently reading, suggesting improvements and also
for asking all the difficult but necessary questions. Thanks to
Stefan Holmer, Xiaoqing Zhu, Safiqul Islam and David Hayes for the
additional review of this document. Thanks to Ralf Globisch for
taking time to try out SCReAM in his challenging low bitrate use
cases, Robert Hedman for finding a few additional flaws in the
running code, and Gustavo Garcia and 'miseri' for code contributions.
9. IANA Considerations
There is currently no request to IANA This document does not require any IANA actions.
10. Security Considerations 8. 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. This attack is however mitigated self-clocking in SCReAM to stall. However, this attack is 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 9. References
A list of changes:
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-9 to WG-10: Minor edits
o WG-08 to WG-09: Updated based shepherd review by Martin
Stiemerling, Q-bit semantics are removed as this is superfluous
for the moment. Pacing and RTCP considerations are moved up from
the appendix, FEC discussion moved to discussion section.
o WG-07 to WG-08: Avoid draft expiry
o WG-06 to WG-07: Updated based on WGLC review by David Hayes and
Safiqul Islam
o WG-05 to WG-06: Added list of suggested experiments
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
Zhu addressed, owd changed to qdelay for clarity. Added appendix
section with RTCP feedback requirements, including a suggested
basic feedback format based Loss RLE report block and the Packet
Receipt Times blocks in [RFC3611]. Loss detection added as a
section. Transmission scheduling and packet pacing explained in
appendix. Source quench semantics added to appendix.
o WG-01 to WG-02: Complete restructuring of the document. Moved
feedback message to a separate draft.
o WG-00 to WG-01 : Changed the Source code section to Implementation
status section.
o -05 to WG-00 : First version of WG doc, moved additional features
section to Appendix. Added description of prioritization in
SCReAM. Added description of additional cap on target bitrate
o -04 to -05 : ACK vector is replaced by a loss counter, PT is
removed from feedback, references to source code added
o -03 to -04 : Extensive changes due to review comments, code
somewhat modified, frame skipping made optional
o -02 to -03 : Added algorithm description with equations, removed
pseudo code and simulation results
o -01 to -02 : Updated GCC simulation results
o -00 to -01 : Fixed a few bugs in example code
12. References 9.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. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <https://www.rfc-editor.org/info/rfc3550>. July 2003, <https://www.rfc-editor.org/info/rfc3550>.
skipping to change at page 35, line 42 skipping to change at page 33, line 45
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent,
"Computing TCP's Retransmission Timer", RFC 6298, "Computing TCP's Retransmission Timer", RFC 6298,
DOI 10.17487/RFC6298, June 2011, DOI 10.17487/RFC6298, June 2011,
<https://www.rfc-editor.org/info/rfc6298>. <https://www.rfc-editor.org/info/rfc6298>.
[RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, [RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind,
"Low Extra Delay Background Transport (LEDBAT)", RFC 6817, "Low Extra Delay Background Transport (LEDBAT)", RFC 6817,
DOI 10.17487/RFC6817, December 2012, DOI 10.17487/RFC6817, December 2012,
<https://www.rfc-editor.org/info/rfc6817>. <https://www.rfc-editor.org/info/rfc6817>.
12.2. Informative References [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
[I-D.ietf-rmcat-coupled-cc] May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Islam, S., Welzl, M., and S. Gjessing, "Coupled congestion
control for RTP media", draft-ietf-rmcat-coupled-cc-07
(work in progress), September 2017.
[I-D.ietf-rmcat-wireless-tests] 9.2. Informative References
Sarker, Z., Johansson, I., Zhu, X., Fu, J., Tan, W., and
M. Ramalho, "Evaluation Test Cases for Interactive Real-
Time Media over Wireless Networks", draft-ietf-rmcat-
wireless-tests-04 (work in progress), May 2017.
[I-D.ietf-tcpm-alternativebackoff-ecn] [ALT-BACKOFF]
Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst, Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst,
"TCP Alternative Backoff with ECN (ABE)", draft-ietf-tcpm- "TCP Alternative Backoff with ECN (ABE)", Work in
alternativebackoff-ecn-02 (work in progress), October Progress, draft-ietf-tcpm-alternativebackoff-ecn-04,
2017. November 2017.
[I-D.ietf-tcpm-rack] [COUPLED-CC]
Cheng, Y., Cardwell, N., and N. Dukkipati, "RACK: a time- Islam, S., Welzl, M., and S. Gjessing, "Coupled congestion
based fast loss detection algorithm for TCP", draft-ietf- control for RTP media", Work in Progress, draft-ietf-
tcpm-rack-02 (work in progress), March 2017. rmcat-coupled-cc-07, September 2017.
[LEDBAT-delay-impact] [LEDBAT-delay-impact]
"Assessing LEDBAT's Delay Impact, IEEE communications Ros, D. and M. Welzl, "Assessing LEDBAT's Delay Impact",
letters, vol. 17, no. 5, May 2013", May 2013, IEEE Communications Letters, Vol. 17, No. 5,
DOI 10.1109/LCOMM.2013.040213.130137, May 2013,
<http://home.ifi.uio.no/michawe/research/publications/ <http://home.ifi.uio.no/michawe/research/publications/
ledbat-impact-letters.pdf>. ledbat-impact-letters.pdf>.
[OpenWebRTC] [OpenWebRTC]
"Open WebRTC project.", <http://www.openwebrtc.io/>. Ericsson Research, "OpenWebRTC",
<http://www.openwebrtc.org>.
[Packet-conservation] [Packet-conservation]
"Congestion Avoidance and Control, ACM SIGCOMM Computer Jacobson, V., "Congestion Avoidance and Control", ACM
Communication Review 1988", 1988. SIGCOMM Computer Communication Review,
DOI 10.1145/52325.52356, August 1988.
[QoS-3GPP] [QoS-3GPP] 3GPP, "Policy and charging control architecture", 3GPP TS
TS 23.203, 3GPP., "Policy and charging control 23.203, July 2017,
architecture", June 2011, <http://www.3gpp.org/ftp/specs/ <http://www.3gpp.org/ftp/specs/archive/23_series/23.203/>.
archive/23_series/23.203/23203-990.zip>.
[RACK] Cheng, Y., Cardwell, N., and N. Dukkipati, "RACK: a time-
based fast loss detection algorithm for TCP", Work in
Progress, draft-ietf-tcpm-rack-02, March 2017.
[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>.
[RFC7661] Fairhurst, G., Sathiaseelan, A., and R. Secchi, "Updating [RFC7661] Fairhurst, G., Sathiaseelan, A., and R. Secchi, "Updating
TCP to Support Rate-Limited Traffic", RFC 7661, TCP to Support Rate-Limited Traffic", RFC 7661,
DOI 10.17487/RFC7661, October 2015, DOI 10.17487/RFC7661, October 2015,
<https://www.rfc-editor.org/info/rfc7661>. <https://www.rfc-editor.org/info/rfc7661>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>.
[SCReAM-CPP-implementation] [SCReAM-CPP-implementation]
"C++ Implementation of SCReAM", Ericsson Research, "SCReAM - Mobile optimised congestion
control algorithm",
<https://github.com/EricssonResearch/scream>. <https://github.com/EricssonResearch/scream>.
[SCReAM-implementation] [SCReAM-implementation]
"SCReAM Implementation", Ericsson Research, "OpenWebRTC specific GStreamer
<https://github.com/EricssonResearch/ plugins", <https://github.com/EricssonResearch/
openwebrtc-gst-plugins>. openwebrtc-gst-plugins>.
[SCReAM-implementation-experience] [SCReAM-implementation-experience]
"Updates on SCReAM : An implementation experience", Sarker, Z. and I. Johansson, "Updates on SCReAM: An
implementation experience", November 2015,
<https://www.ietf.org/proceedings/94/slides/ <https://www.ietf.org/proceedings/94/slides/
slides-94-rmcat-8.pdf>. slides-94-rmcat-8.pdf>.
[TFWC] University College London, "Fairer TCP-Friendly Congestion [TFWC] Choi, S. and M. Handley, "Fairer TCP-Friendly Congestion
Control Protocol for Multimedia Streaming", December 2007, Control Protocol for Multimedia Streaming Applications",
DOI 10.1145/1364654.1364717, December 2007,
<http://www-dept.cs.ucl.ac.uk/staff/M.Handley/papers/ <http://www-dept.cs.ucl.ac.uk/staff/M.Handley/papers/
tfwc-conext.pdf>. tfwc-conext.pdf>.
[WIRELESS-TESTS]
Sarker, Z., Johansson, I., Zhu, X., Fu, J., Tan, W., and
M. Ramalho, "Evaluation Test Cases for Interactive Real-
Time Media over Wireless Networks", Work in Progress,
draft-ietf-rmcat-wireless-tests-04, May 2017.
Acknowledgements
We would like to thank the following people for their comments,
questions, and support during the work that led to this memo: Markus
Andersson, Bo Burman, Tomas Frankkila, Frederic Gabin, Laurits Hamm,
Hans Hannu, Nikolas Hermanns, Stefan Haakansson, Erlendur Karlsson,
Daniel Lindstroem, Mats Nordberg, Jonathan Samuelsson, Rickard
Sjoeberg, Robert Swain, Magnus Westerlund, and Stefan Aalund. Many
additional thanks to RMCAT chairs Karen E. E. Nielsen and Mirja
Kuehlewind for patiently reading, suggesting improvements and also
for asking all the difficult but necessary questions. Thanks to
Stefan Holmer, Xiaoqing Zhu, Safiqul Islam, and David Hayes for the
additional review of this document. Thanks to Ralf Globisch for
taking time to try out SCReAM in his challenging low-bitrate use
cases, Robert Hedman for finding a few additional flaws in the
running code, and Gustavo Garcia and 'miseri' for code contributions.
Authors' Addresses Authors' Addresses
Ingemar Johansson Ingemar Johansson
Ericsson AB Ericsson AB
Laboratoriegraend 11 Laboratoriegraend 11
Luleaa 977 53 Luleaa 977 53
Sweden Sweden
Phone: +46 730783289 Phone: +46 730783289
Email: ingemar.s.johansson@ericsson.com Email: ingemar.s.johansson@ericsson.com
 End of changes. 248 change blocks. 
841 lines changed or deleted 707 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/