draft-ietf-rmcat-scream-cc-06.txt   draft-ietf-rmcat-scream-cc-07.txt 
RMCAT WG I. Johansson RMCAT WG I. Johansson
Internet-Draft Z. Sarker Internet-Draft Z. Sarker
Intended status: Experimental Ericsson AB Intended status: Experimental Ericsson AB
Expires: February 16, 2017 August 15, 2016 Expires: May 18, 2017 November 14, 2016
Self-Clocked Rate Adaptation for Multimedia Self-Clocked Rate Adaptation for Multimedia
draft-ietf-rmcat-scream-cc-06 draft-ietf-rmcat-scream-cc-07
Abstract Abstract
This memo describes a rate adaptation algorithm for conversational This memo describes a rate adaptation algorithm for conversational
media services such as video. The solution conforms to the packet media services such as video. The solution conforms to the packet
conservation principle and uses a hybrid loss and delay based conservation principle and uses a hybrid loss and delay based
congestion control algorithm. The algorithm is evaluated over both congestion control algorithm. The algorithm is evaluated over both
simulated Internet bottleneck scenarios as well as in a LTE (Long simulated Internet bottleneck scenarios as well as in a Long Term
Term Evolution) system simulator and is shown to achieve both low Evolution (LTE) system simulator and is shown to achieve both low
latency and high video throughput in these scenarios. latency and high video throughput in these scenarios.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 16, 2017. This Internet-Draft will expire on May 18, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 14 skipping to change at page 2, line 14
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Wireless (LTE) access properties . . . . . . . . . . . . 3 1.1. Wireless (LTE) access properties . . . . . . . . . . . . 3
1.2. Why is it a self-clocked algorithm? . . . . . . . . . . . 4 1.2. Why is it a self-clocked algorithm? . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of SCReAM Algorithm . . . . . . . . . . . . . . . . 4 3. Overview of SCReAM Algorithm . . . . . . . . . . . . . . . . 4
3.1. Network Congestion Control . . . . . . . . . . . . . . . 7 3.1. Network Congestion Control . . . . . . . . . . . . . . . 8
3.2. Sender Transmission Control . . . . . . . . . . . . . . . 7 3.2. Sender Transmission Control . . . . . . . . . . . . . . . 8
3.3. Media Rate Control . . . . . . . . . . . . . . . . . . . 7 3.3. Media Rate Control . . . . . . . . . . . . . . . . . . . 8
4. Detailed Description of SCReAM . . . . . . . . . . . . . . . 8 4. Detailed Description of SCReAM . . . . . . . . . . . . . . . 9
4.1. SCReAM Sender . . . . . . . . . . . . . . . . . . . . . . 8 4.1. SCReAM Sender . . . . . . . . . . . . . . . . . . . . . . 9
4.1.1. Constants and Parameter values . . . . . . . . . . . 9 4.1.1. Constants and Parameter values . . . . . . . . . . . 9
4.1.1.1. Constants . . . . . . . . . . . . . . . . . . . . 9 4.1.1.1. Constants . . . . . . . . . . . . . . . . . . . . 10
4.1.1.2. State variables . . . . . . . . . . . . . . . . . 10 4.1.1.2. State variables . . . . . . . . . . . . . . . . . 11
4.1.2. Network congestion control . . . . . . . . . . . . . 12 4.1.2. Network congestion control . . . . . . . . . . . . . 13
4.1.2.1. Congestion window update . . . . . . . . . . . . 15 4.1.2.1. Congestion window update . . . . . . . . . . . . 16
4.1.2.2. Competing flows compensation . . . . . . . . . . 17 4.1.2.2. Competing flows compensation . . . . . . . . . . 18
4.1.2.3. Lost packets detection . . . . . . . . . . . . . 19 4.1.2.3. Lost packet detection . . . . . . . . . . . . . . 20
4.1.2.4. Send window calculation . . . . . . . . . . . . . 19 4.1.2.4. Send window calculation . . . . . . . . . . . . . 20
4.1.2.5. Resuming fast increase . . . . . . . . . . . . . 20 4.1.2.5. Resuming fast increase . . . . . . . . . . . . . 21
4.1.3. Media rate control . . . . . . . . . . . . . . . . . 20 4.1.3. Media rate control . . . . . . . . . . . . . . . . . 21
4.1.3.1. FEC and packet overhead considerations . . . . . 23 4.1.3.1. FEC and packet overhead considerations . . . . . 24
4.2. SCReAM Receiver . . . . . . . . . . . . . . . . . . . . . 24 4.2. SCReAM Receiver . . . . . . . . . . . . . . . . . . . . . 25
5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 24 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 25
6. Implementation status . . . . . . . . . . . . . . . . . . . . 24 6. Implementation status . . . . . . . . . . . . . . . . . . . . 25
6.1. OpenWebRTC . . . . . . . . . . . . . . . . . . . . . . . 25 6.1. OpenWebRTC . . . . . . . . . . . . . . . . . . . . . . . 26
6.2. A C++ Implementation of SCReAM . . . . . . . . . . . . . 25 6.2. A C++ Implementation of SCReAM . . . . . . . . . . . . . 27
7. Suggested experiments . . . . . . . . . . . . . . . . . . . . 26 7. Suggested experiments . . . . . . . . . . . . . . . . . . . . 27
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
10. Security Considerations . . . . . . . . . . . . . . . . . . . 27 10. Security Considerations . . . . . . . . . . . . . . . . . . . 28
11. Change history . . . . . . . . . . . . . . . . . . . . . . . 27 11. Change history . . . . . . . . . . . . . . . . . . . . . . . 28
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
12.1. Normative References . . . . . . . . . . . . . . . . . . 28 12.1. Normative References . . . . . . . . . . . . . . . . . . 29
12.2. Informative References . . . . . . . . . . . . . . . . . 28 12.2. Informative References . . . . . . . . . . . . . . . . . 30
Appendix A. Additional information . . . . . . . . . . . . . . . 30 Appendix A. Additional information . . . . . . . . . . . . . . . 32
A.1. Stream prioritization . . . . . . . . . . . . . . . . . . 30 A.1. Stream prioritization . . . . . . . . . . . . . . . . . . 32
A.2. Computation of autocorrelation function . . . . . . . . . 31 A.2. Computation of autocorrelation function . . . . . . . . . 32
A.3. Sender transmission control and packet pacing . . . . . . 31 A.3. Sender transmission control and packet pacing . . . . . . 33
A.4. RTCP feedback considerations . . . . . . . . . . . . . . 31 A.4. RTCP feedback considerations . . . . . . . . . . . . . . 33
A.4.1. Requirements on feedback elements . . . . . . . . . . 32 A.4.1. Requirements on feedback elements . . . . . . . . . . 33
A.4.2. Requirements on feedback intensity . . . . . . . . . 34 A.4.2. Requirements on feedback intensity . . . . . . . . . 35
A.5. Q-bit semantics (source quench) . . . . . . . . . . . . . 34 A.5. Q-bit semantics (source quench) . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 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 bandwidth over a given transmission path. higher than the available capacity over a given transmission path.
Applications that are deployed in the Internet must have congestion Applications that are deployed in the Internet must employ congestion
control schemes in place not only for the robustness of the service control, to achieve robust performance and to avoid congestion
that it provides but also to ensure the function of the currently collapse in the Internet. Interactive realtime communication imposes
deployed Internet. Interactive realtime communication imposes a lot a lot of requirements on the transport, therefore a robust, efficient
of requirements on the transport, therefore a robust, efficient rate rate adaptation for all access types is an important part of
adaptation for all access types is an important part of interactive interactive realtime communications as the transmission channel
realtime communications as the transmission channel bandwidth may bandwidth may vary over time. Wireless access such as LTE, which is
vary over time. Wireless access such as LTE, which is an integral an integral part of the current Internet, increases the importance of
part of the current Internet, increases the importance of rate rate adaptation as the channel bandwidth of a default LTE bearer
adaptation as the channel bandwidth of a default LTE bearer
[QoS-3GPP] can change considerably in a very short time frame. Thus [QoS-3GPP] can change considerably in a very short time frame. Thus
a rate adaptation solution for interactive realtime media, such as a rate adaptation solution for interactive realtime media, such as
WebRTC, must be both quick and be able to operate over a large span WebRTC, must be both quick and be able to operate over a large range
in available channel bandwidth. This memo describes a solution,named in channel capacity. This memo describes SCReAM (Self-Clocked Rate
SCReAM (Self-Clocked Rate Adaptation for Multimedia), that is based Adaptation for Multimedia), a solution that is based on the self-
on the self-clocking principle of TCP and uses techniques similar to clocking principle of TCP and uses techniques similar to what is used
what is used in a new delay based rate adaptation algorithm, LEDBAT in the LEDBAT based rate adaptation algorithm [RFC6817]. SCReAM is
[RFC6817]. not entirely self-clocked as it augments self-clocking with pacing
and a minimum send rate.
1.1. Wireless (LTE) access properties 1.1. Wireless (LTE) access properties
[I-D.ietf-rmcat-wireless-tests] describes the complications that can [I-D.ietf-rmcat-wireless-tests] describes the complications that can
be observed in wireless environments. Wireless access such as LTE be observed in wireless environments. Wireless access such as LTE
can typically not guarantee a given bandwidth, this is true can typically not guarantee a given bandwidth, this is true
especially for default bearers. The network throughput may vary especially for default bearers. The network throughput may vary
considerably for instance in cases where the wireless terminal is considerably for instance in cases where the wireless terminal is
moving around. Even though LTE can support bitrates well above moving around. Even though LTE can support bitrates well above
100Mbps, there are cases when the available bitrate can be much 100Mbps, there are cases when the available bitrate can be much
skipping to change at page 3, line 50 skipping to change at page 3, line 50
Unlike wireline bottlenecks with large statistical multiplexing it is Unlike wireline bottlenecks with large statistical multiplexing it is
not possible to try to maintain a given bitrate when congestion 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 needs to reduce allocation for a bearer, an RMCAT flow in that bearer needs to reduce
the sending rate quite quickly (in one RTT) in order to avoid 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 algorithm provides with a benefit Self-clocked congestion control algorithms provide a benefit over the
over the rate based counterparts in that the former consists of two rate based counterparts in that the former consists of two adaptation
parts; the congestion window computation that evolves over a longer mechanisms:
timescale (several RTTs) especially when the congestion window
evolution is dictated by estimated delay (to minimize vulnerability o A congestion window computation that evolves over a longer
to e.g. short term delay variations) and; the fine grained congestion timescale (several RTTs) especially when the congestion window
control given by the self-clocking which operates on a shorter time evolution is dictated by estimated delay (to minimize
scale (1 RTT). The benefits of self-clocking are also elaborated vulnerability to e.g. short term delay variations).
upon in [TFWC].
o A fine grained congestion control given by the self-clocking which
operates on a shorter time scale (1 RTT). The benefits of self-
clocking are also elaborated upon in [TFWC].
A rate based congestion control typically adjusts the rate based on A rate based congestion control typically adjusts the rate based on
delay and loss. The congestion detection needs to be done with a delay and loss. The congestion detection needs to be done with a
certain time lag to avoid over-reaction to spurious congestion events certain time lag to avoid over-reaction to spurious congestion events
such as delay spikes. Despite the fact that there are two or more such as delay spikes. Despite the fact that there are two or more
congestion indications, the outcome is still that there is only one congestion indications, the outcome is still that there is still only
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. Terminology
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", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [RFC2119] document are to be interpreted as described in RFC2119 [RFC2119]
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 TFWC [TFWC] and follows the packet conservation
principle. The packet conservation principle is described as an principle. The packet conservation principle is described as an
important key-factor behind the protection of networks from important key-factor behind the protection of networks from
congestion [PACKET_CONSERVATION]. 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 they
were transmitted. This information is used to determine the amount were transmitted. This information is used to determine the number
of bytes that can be transmitted at any given time instant. A of bytes that can be transmitted at any given time instant. A
congestion window puts an upper limit on how many bytes can be in congestion window puts an upper limit on how many bytes can be in
flight, i.e transmitted but not yet acknowledged. All this flight, i.e. transmitted but not yet acknowledged.
implements a congestion control that follows the packet conservation
principle. The fact that SCReAM follows the packet conservation
principle, makes it as safe to deploy as a congestion control
algorithm for the Internet as TCP and its most commonly used
congestion control algorithms are. No additional circuit breaker
mechanisms are necessary with SCReAM as the ACK-clocking
automatically falls back to a very low transmission rate (1 RTP
packet/200ms) when the acknowledgements no longer arrive at the
sender. Furthermore, high packet loss rates reduces the congestion
value to very low values and thus a low transmission rate.
The congestion window is determined in a way similar to LEDBAT The congestion window is determined in a way similar to LEDBAT
[RFC6817]. [RFC6817]. LEDBAT is a congestion control algorithm that uses send
and receive timestamps to estimate the queuing delay (from now on
denoted qdelay) along the transmission path. This information is
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
LEDBAT has certain inherent issues that makes it counteract its
purpose to achieve low delay. The general problem described in the
paper is that the base delay is offset by LEDBAT's own queue buildup.
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 RTP queue is kept short (preferably empty). In addition the
output from a video encoder is rarely constant bitrate, static
content (talking heads) for instance gives almost zero video rate.
This gives two useful properties when LEDBAT is used with SCReAM that
help to avoid the issues described in [LEDBAT-delay-impact]:
LEDBAT is a congestion control algorithm that uses send and receive 1. There is always a certain probability that SCReAM is short of
timestamps to estimate the queuing delay along the transmission path. data to transmit, which means that the network queue will run
This information is used to adjust the congestion window. The use of empty every once in a while.
LEDBAT ensures that the end-to-end latency is kept low. The basic
functionality is quite simple, there are however a few steps to take 2. The max video bitrate can be lower than the link capacity. If
to make the concept work with conversational media. In a few words the max video bitrate is 5Mbps and the capacity is 10Mbps then
they are: the network queue will run empty.
It is sufficient that any of the two conditions above is fulfilled to
make the base delay update properly. Furthermore
[LEDBAT-delay-impact] describes an issue with short lived competing
flows, the case in SCReAM is that these short lived flows will cause
the self-clocking in SCReAM to slow down with the result that the RTP
queue is built up, which will in turn result in a reduced media video
bitrate. SCReAM will thus yield more to competing short lived flows
than what is the case with traditional use of LEDBAT.
The basic functionality in the use of LEDBAT in SCReAM is quite
simple, there are however a few steps to take to make the concept
work with conversational media:
o Congestion window validation techniques. These are similar in o Congestion window validation techniques. These are similar in
action as the method described in [RFC7661]. Congestion window action as the method described in [RFC7661]. Congestion window
validation ensures that the congestion window is limited by the validation ensures that the congestion window is limited by the
amount of actual bytes in flight, this is important especially in actual number bytes in flight, this is important especially in the
the context of rate limited sources such as video. Lack of context of rate limited sources such as video. Lack of congestion
congestion window validation would lead to a slow reaction to window validation would lead to a slow reaction to congestion as
congestion as the congestion window does not properly reflect the the congestion window does not properly reflect the congestion
congestion state in the network. The allowed idle period in this state in the network. The allowed idle period in this memo is
memo is shorter than in [RFC7661], this to avoid excessive delays shorter than in [RFC7661], this to avoid excessive delays in the
in the cases where e.g. wireless throughput has decreased during a cases where e.g. wireless throughput has decreased during a period
period where the output bitrate from the media coder has been low, where the output bitrate from the media coder has been low, for
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 under-utilized.
o Fast increase for quicker bitrate increase. It makes the media o Fast increase makes the bitrate increase faster when no congestion
bitrate ramp-up within 5 to 10 seconds. The behavior is similar is detected. It makes the media bitrate ramp-up within 5 to 10
to TCP slowstart. The fast increase is exited when congestion is seconds. The behavior is similar to TCP slowstart. The fast
detected. The fast increase state can however resume if the increase is exited when congestion is detected. The fast increase
congestion level is low, this to enable a reasonably quick rate state can however resume if the congestion level is low, this
increase in case link throughput increases. enables a reasonably quick rate increase in case link throughput
increases.
o A delay 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 and as a result it reduces jitter.
o Addition of a media rate control function. o Addition of a media rate control function.
o Use of inflection points 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 delay 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. sections Section 3.1 to Section 3.3.
+---------------------------+ +---------------------------+
| Media encoder | | Media encoder |
+---------------------------+ +---------------------------+
^ | ^ |
(3)| (1)| (3)| (1)|
skipping to change at page 6, line 48 skipping to change at page 7, line 42
|-------------RTCP----------| RTP |-------------RTCP----------| RTP
| | | |
| v | v
+------------+ +------------+
| UDP | | UDP |
| socket | | socket |
+------------+ +------------+
Figure 1: SCReAM sender functional view Figure 1: SCReAM sender functional view
The SCReAM algorithm constitutes mainly three parts: network The SCReAM algorithm consists of three main parts: network congestion
congestion control, sender transmission control and media rate control, sender transmission control and media rate control. All of
control. All these three parts reside at the sender side. Figure 1 these three parts reside at the sender side. Figure 1 shows the
shows the functional overview of a SCReAM sender. The receiver side functional overview of a SCReAM sender. The receiver side algorithm
algorithm is very simple in comparison as it only generates feedback is very simple in comparison as it only generates feedback containing
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 queuing delay, also termed qdelay in LEDBAT [RFC6817] to measure the qdelay. As is the case with LEDBAT,
this memo for brevity. Similar to LEDBAT, it is not necessary to use it is not necessary to use synchronized clocks in sender and receiver
synchronized clocks in sender and receiver in order to compute the in order to compute the qdelay. It is however necessary that they
queuing delay. It is however necessary that they use the same clock use the same clock frequency, or that the clock frequency at the
frequency, or that the clock frequency at the receiver can be receiver can be inferred reliably by the sender.
inferred reliably by the sender.
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 delay target otherwise the congestion window decreases. The qdelay target is
is typically set to 50-100ms. This ensures that the queuing delay is typically set to 50-100ms. This ensures that the queuing delay is
kept low. The reaction to loss or ECN events leads to an instant kept low. The reaction to loss or ECN events leads to an instant
reduction of CWND. Note that the source rate limited nature of real reduction of CWND. Note that the source rate limited nature of real
time media such as video, typically means that the queuing delay will time media such as video, typically means that the queuing delay will
mostly be below the given delay target, this is contrary to the case mostly be below the given delay target, this is contrary to the case
where large files are transmitted using LEDBAT congestion control, in where large files are transmitted using LEDBAT congestion control, in
which case the queuing delay will stay close to the delay target. which case 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, this has the effect that even given by the estimated link throughput. Even if the send window
if the send window allows for the transmission of a number of allows for the transmission of a number of packets, these packets are
packets, these packets are not transmitted immediately, but rather not transmitted immediately, but rather they are transmitted in
they are transmitted in intervals given by the packet size and the intervals given by the packet size and the estimated link throughput.
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 up 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 the In cases where the sender frame queues increase rapidly such as in
case of a RAT (Radio Access Type) handover it may be necessary to the case of a RAT (Radio Access Type) handover it may be necessary to
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 or simply that stale RTP packets are removed from the drained quickly. Frame skipping results in the frame rate being
queue. Frame skipping means that the frame rate is temporarily temporarily reduced. Which method to use is a design choice and
reduced. Which method to use is a design consideration and outside outside the scope of this algorithm description.
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 a split between the network congestion control, sender is split between the network congestion control, sender transmission
transmission control and the media rate control. control and the media rate control.
A SCReAM sender implements media rate control and a queue for each A SCReAM sender implements media rate control and an RTP queue for
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 (a.k.a stream) is used. Multiple details when a single media source (or stream) is used. A
media sources are also supported in the design, in that case the transmission scheduler (not shown in the figure) is added to support
sender transmission control will include a transmission scheduler. multiple streams. The transmission scheduler can enforce differing
The transmission scheduler can then enforce the priorities for the priorities between the streams and act like a coupled congestion
different streams and then act like a coupled congestion controller controller for multiple flows. Support for multiple streams is
for multiple flows. 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 controls the media bitrate (3). The RTP packets are queue (2) and provides a target rate for the media encoder (3). The
picked from the RTP queue (for multiple flows from each RTP queue RTP packets are picked from the RTP queue (for multiple flows from
based on some defined priority order or simply in a round robin each RTP queue based on some defined priority order or simply in a
fashion) (4) by the sender transmission controller. The sender round robin fashion) (4) by the sender transmission controller. The
transmission controller (in case of multiple flows a transmission sender transmission controller (in case of multiple flows a
scheduler) takes care of the transmission of RTP packets, to be transmission scheduler) sends the RTP packets to the UDP socket (5).
written to the UDP socket (5). In the general case all media must go In the general case all media must go through the sender transmission
through the sender transmission controller and is allowed to be controller and is limited so that the number of bytes in flight is
transmitted if the number of bytes in flight is less than the less than the congestion window. RTCP packets are received (6) and
congestion window. RTCP packets are received (6) and the information the information about bytes in flight and congestion window is
about bytes in flight and congestion window is exchanged between the exchanged between the network congestion control and the sender
network congestion control and the sender transmission control (7). 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. pseudo code to indicate their local scope.
4.1.1.1. Constants 4.1.1.1. Constants
The recommended values for the constants are deduced from The recommended values, within (), for the constants are deduced from
experiments. experiments.
QDELAY_TARGET_LO (0.1s) QDELAY_TARGET_LO (0.1s)
Target value for the minimum qdelay. Target value for the minimum qdelay.
QDELAY_TARGET_HI (0.4s) QDELAY_TARGET_HI (0.4s)
Target value for the maximum qdelay. Target value for the maximum qdelay. This parameter provides an
upper limit to how much the target qdelay (qdelay_target) can be
increased in order to cope with competing loss based flows. The
target qdelay should not be initialized to this high value however
as it would increase e2e delay and also make the rate control and
congestion control loop sluggish.
QDELAY_WEIGHT (0.1) QDELAY_WEIGHT (0.1)
Averaging factor for qdelay_fraction_avg. Averaging factor for qdelay_fraction_avg.
QDELAY_TREND_TH (0.2)
Averaging factor for qdelay_fraction_avg.
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.6) BETA_LOSS (0.6)
CWND scale factor due to loss event. CWND scale factor due to loss event.
BETA_ECN (0.8) BETA_ECN (0.8)
skipping to change at page 10, line 10 skipping to change at page 11, line 12
TARGET_BITRATE_MAX TARGET_BITRATE_MAX
Max target bitrate [bps]. Max target bitrate [bps].
RAMP_UP_SPEED (200000bps/s) RAMP_UP_SPEED (200000bps/s)
Maximum allowed rate increase speed. Maximum allowed rate increase speed.
PRE_CONGESTION_GUARD (0.0..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 have however given characteristics, experiments with H264 and VP8 indicate that 0.1 is
that 0.1 is a suitable value. a suitable value. See [SCReAM-implementation-experience] for
evaluation of a real 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, experiments
with H264 and VP8 have however given that 1.0 is a suitable value. with H264 and VP8 indicate that 1.0 is a suitable value. See
[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.02s) RTP queue delay threshold for a target rate
reduction. reduction.
TARGET_RATE_SCALE_RTP_QDELAY (0.95) Target rate scale when RTP queue TARGET_RATE_SCALE_RTP_QDELAY (0.95) Target rate scale when RTP
delay threshold exceeded. qdelay threshold exceeds.
QDELAY_TREND_LO (0.2) Threshold value for qdelay_trend. QDELAY_TREND_LO (0.2) Threshold value for qdelay_trend.
T_RESUME_FAST_INCREASE Time span until fast increase can be resumed, T_RESUME_FAST_INCREASE Time span until fast increase can be resumed,
given that the qdelay_trend is below QDELAY_TREND_LO. given that the qdelay_trend is below QDELAY_TREND_LO.
4.1.1.2. State variables 4.1.1.2. State variables
The values within () indicate initial values.
qdelay_target (QDELAY_TARGET_LO) qdelay_target (QDELAY_TARGET_LO)
qdelay target, a variable qdelay target is introduced to manage qdelay target, a variable qdelay target is introduced to manage
cases where e.g. FTP competes for the bandwidth over the same cases where e.g. FTP competes for the bandwidth over the same
bottleneck, a fixed qdelay target would otherwise starve the RMCAT bottleneck, a fixed qdelay target would otherwise starve the RMCAT
flow under such circumstances. The qdelay target is allowed to flow under such circumstances. The qdelay target is allowed to
vary between QDELAY_TARGET_LO and QDELAY_TARGET_HI. vary between QDELAY_TARGET_LO and QDELAY_TARGET_HI.
qdelay_fraction_avg (0.0) qdelay_fraction_avg (0.0)
EWMA filtered fractional qdelay. EWMA filtered fractional qdelay.
skipping to change at page 11, line 16 skipping to change at page 12, line 22
Minimum congestion window. Minimum congestion window.
in_fast_increase (true) in_fast_increase (true)
True if in fast increase state. True if in fast increase state.
cwnd (min_cwnd) cwnd (min_cwnd)
Congestion window. Congestion window.
bytes_newly_acked (0) bytes_newly_acked (0)
The number of bytes that was acknowledged with the last received The number of bytes that was acknowledged with the last received
acknowledgement i.e bytes acknowledged since the last CWND update. acknowledgement i.e. bytes acknowledged since the last CWND update.
send_wnd (0) send_wnd (0)
Upper limit to how many bytes that can currently be transmitted. Upper limit to how many bytes that can currently be transmitted.
Updated when cwnd is updated and when RTP packet is transmitted. Updated when cwnd is updated and when RTP packet is transmitted.
target_bitrate (0 bps) target_bitrate (0 bps)
Media target bitrate. Media target bitrate.
target_bitrate_last_max (1 bps) target_bitrate_last_max (1 bps)
Media target bitrate inflection point i.e the last known highest Media target bitrate inflection point i.e. the last known highest
target_bitrate. Used to limit bitrate increase speed close to the target_bitrate. Used to limit bitrate increase speed close to the
last known congestion point. 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 10s.
s_rtt (0.0s) s_rtt (0.0s)
Smoothed RTT [s], computed similar to method depicted in [RFC6298] Smoothed RTT [s], computed with a similar method to that described
in [RFC6298].
rtp_queue_size (0 bits) rtp_queue_size (0 bits)
Size of RTP packets in queue. Size of RTP packets in queue.
rtp_size (0 byte) rtp_size (0 byte)
Size of the last transmitted RTP packet. Size of the last transmitted RTP packet.
loss_event_rate (0.0) loss_event_rate (0.0)
The estimated fraction of RTTs with lost packets detected. The estimated fraction of RTTs with lost packets detected.
4.1.2. Network congestion control 4.1.2. Network congestion control
This section explains the network congestion control, it contains two This section explains the network congestion control, it contains two
main functions main functions:
o Computation of congestion window at the sender: Gives an upper o Computation of congestion window at the sender: Gives an upper
limit to the number of bytes in flight i.e how many bytes that limit to the number of bytes in flight.
have been transmitted but not yet acknowledged.
o Calculation of send window at the sender: RTP packets are o Calculation of send window at the sender: RTP packets are
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.
Unlike TCP, SCReAM is not a byte oriented protocol, rather it is an SCReAM is a window based and byte oriented congestion control
RTP packet oriented protocol. Thus a list of transmitted RTP packets protocol, where the number of bytes transmitted is inferred from the
and their respective transmission times (wall-clock time) is kept for size of the transmitted RTP packets. Thus a list of transmitted RTP
further calculation. The congestion control is however based on packets and their respective transmission times (wall-clock time) is
transmitted and acknowledged bytes. kept for further calculation.
SCReAM uses the terminology "Bytes in flight" (bytes_in_flight) which The number of bytes in flight (bytes_in_flight) is computed as the
is computed as the sum of the sizes of the RTP packets ranging from sum of the sizes of the RTP packets ranging from the RTP packet most
the RTP packet most recently transmitted down to but not including recently transmitted down to but not including the acknowledged
the acknowledged packet with the highest sequence number. This can packet with the highest sequence number. This can be translated to
be translated to the difference between the highest transmitted byte the difference between the highest transmitted byte sequence number
sequence number and the highest acknowledged byte sequence number. and the highest acknowledged byte sequence number. As an example: If
As an example: If RTP packet with sequence number SN is transmitted RTP packet with sequence number SN is transmitted and the last
and the last acknowledgement indicates SN-5 as the highest received acknowledgement indicates SN-5 as the highest received sequence
sequence number then bytes in flight is computed as the sum of the number then bytes in flight is computed as the sum of the size of RTP
size of RTP packets with sequence number SN-4, SN-3, SN-2, SN-1 and packets with sequence number SN-4, SN-3, SN-2, SN-1 and SN, it does
SN, it does not matter if for instance packet with sequence number not matter if for instance packet with sequence number SN-3 was lost,
SN-3 was lost, the size of RTP packet with sequence number SN-3 will the size of RTP packet with sequence number SN-3 will still be
still be considered in the computation of bytes_in_flight. 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 is reset after a CWND update. bytes_newly_acked variable is reset 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. More details are found in Appendix A.4. elements. More details are found in Appendix A.4.
o A list of received RTP packets. o A list of received RTP packets.
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 Accumulated number of ECN-CE marked packets (n_ECN).
When the sender receives RTCP feedback, the qdelay is calculated as When the sender receives RTCP feedback, the qdelay is calculated as
outlined in [RFC6817]. A qdelay sample is obtained for each received outlined in [RFC6817]. A qdelay sample is obtained for each received
acknowledgement. No smoothing of the qdelay samples occur, however acknowledgement. No smoothing of the qdelay samples occur, however
some smoothing occurs anyway as the computation of the CWND is in some smoothing occurs anyway as the computation of the CWND is a low
itself a low pass filter function. A number of variables are updated pass filter function. A number of variables are updated as
as illustrated by the pseudo code below, temporary variables are illustrated by the pseudo code below, temporary variables are
appended with '_t'. Note that the pseudo code does not show all appended with '_t'. Note that the pseudo code does not show all
details for reasons of readability, the reader is referred to the C++ details for reasons of readability, the reader is encouraged to look
code in [SCReAM-Cplusplus_Implementation] for the details. into the C++ code in [SCReAM-CPP-implementation] for the details.
update_variables(qdelay): update_variables(qdelay):
qdelay_fraction_t = qdelay/qdelay_target qdelay_fraction_t = qdelay/qdelay_target
#calculate moving average #calculate moving average
qdelay_fraction_avg = (1-QDELAY_WEIGHT)*qdelay_fraction_avg+ qdelay_fraction_avg = (1-QDELAY_WEIGHT)*qdelay_fraction_avg+
QDELAY_WEIGHT*qdelay_fraction_t QDELAY_WEIGHT*qdelay_fraction_t
update_qdelay_fraction_hist(qdelay_fraction_t) update_qdelay_fraction_hist(qdelay_fraction_t)
# R is an autocorrelation function of qdelay_fraction_hist # R is an autocorrelation function of qdelay_fraction_hist
# at lag K # at lag K
a = R(qdelay_fraction_hist,1)/R(qdelay_fraction_hist,0) a = R(qdelay_fraction_hist,1)/R(qdelay_fraction_hist,0)
skipping to change at page 13, line 47 skipping to change at page 15, line 5
The qdelay fraction is sampled every 50ms and the last 20 samples are The qdelay fraction is sampled every 50ms and the last 20 samples are
stored in a vector (qdelay_fraction_hist). This vector is used in stored in a vector (qdelay_fraction_hist). This vector is used in
the computation of an qdelay trend that gives a value between 0.0 and the computation of an qdelay trend that gives a value between 0.0 and
1.0 depending on the estimated congestion level. The prediction 1.0 depending on the estimated congestion level. The prediction
coefficient 'a' has positive values if qdelay shows an increasing coefficient 'a' has positive values if qdelay shows an increasing
trend, thus an indication of congestion is obtained before the qdelay trend, thus an indication of congestion is obtained before the qdelay
target is reached. The autocorrelation function 'R' is defined in target is reached. The autocorrelation function 'R' is defined in
Appendix A.2. The prediction coefficient is further multiplied with Appendix A.2. The prediction coefficient is further multiplied with
qdelay_fraction_avg to reduce sensitivity to increasing qdelay when qdelay_fraction_avg to reduce sensitivity to increasing qdelay when
it is very small. The 50ms sampling is a simplification and may have it is very small. The 50ms sampling is a simplification and may have
the effect that the same qdelay is sampled several times, this is the effect that the same qdelay is sampled several times, this does
however not a big issue as the vector is only used for the however not pose any problem a the vector is only used to determine
computation of qdelay_trend. The qdelay_trend is utilized in the if the qdelay is increasing or decreasing. The qdelay_trend is
media rate control to indicate incipient congestion and to determine utilized in the media rate control to indicate incipient congestion
when to exit from fast increase mode. qdelay_trend_mem is used to and to determine when to exit from fast increase mode.
enforce a less aggressive rate increase after congestion events. The qdelay_trend_mem is used to enforce a less aggressive rate increase
function update_qdelay_fraction_hist(..) removes the oldest element after congestion events. The function
and adds the latest qdelay_fraction element to the update_qdelay_fraction_hist(..) removes the oldest element and adds
qdelay_fraction_hist vector. the latest qdelay_fraction element to the qdelay_fraction_hist
vector.
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.3. Once a missing. The loss detection is described in Section 4.1.2.3. Once a
loss event is detected, further detected lost RTP packets are ignored loss event is detected, further detected lost RTP packets are ignored
for a full smoothed round trip time, the intention of this is to for a full smoothed round trip time, the intention of this is to
limit the congestion window decrease to at most once per round trip. limit the congestion window decrease to at most once per round trip.
The congestion window backoff 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 e.g. TCP Reno. The reason is that
TCP is generally used to transmit whole files, which can be TCP is generally used to transmit whole files, which can be
translated to an infinite source bitrate. SCReAM on the other hand translated to an infinite source bitrate. SCReAM on the other hand
has a source which rate is limited to a value close to the available has a source whose rate is limited to a value close to the available
transmit rate and often below said value, the effect of this is that transmit rate and often below that value, the effect of this is that
SCReAM has less opportunity to grab free capacity than a TCP based SCReAM has less opportunity to grab free capacity than a TCP based
file transfer. To compensate for this it is necessary to let SCReAM file transfer. To compensate for this it is necessary to let SCReAM
reduce the congestion window slightly less than what is the case with reduce the congestion window slightly less than what is the case with
TCP when loss events occur. TCP when loss events occur.
An ECN event is detected if the n_ECN counter in the feedback report An ECN event is detected if the n_ECN counter in the feedback report
has increased since the previous received feedback. Once an ECN has increased since the previous received feedback. Once an ECN
event is detected, the n_ECN counter is ignored for a full smoothed event is detected, the n_ECN counter is ignored for a full smoothed
round trip time, the intention of this is to limit the congestion round trip time, the intention of this is to limit the congestion
window decrease to at most once per round trip. The congestion window decrease to at most once per round trip. The congestion
window backoff due to an ECN event is deliberately smaller than if a window back off due to an ECN event is deliberately smaller than if a
loss event occurs. This is in line with the idea outlined in loss event occurs. This is in line with the idea outlined in
[Khademi_alternative_backoff_ECN] to enable ECN marking thresholds [Khademi-alternative-backoff-ECN] to enable ECN marking thresholds
lower than the corresponding packet drop thresholds. lower than the corresponding packet drop thresholds.
The update of the congestion window depends on whether loss or ECN- The update of the congestion window depends on whether loss or ECN-
marking or neither occurs. The pseudo code below describes actions marking or neither occurs. The pseudo code below describes actions
taken in case of the different events. taken in case of the different events.
on congestion event(qdelay): on congestion event(qdelay):
# Either loss or ECN mark is detected # Either loss or ECN mark is detected
in_fast_increase = false in_fast_increase = false
if (is loss) if (is loss)
skipping to change at page 16, line 9 skipping to change at page 17, line 9
The congestion window update is based on qdelay, except for the The congestion window update is based on qdelay, except for the
occurrence of loss events (one or more lost RTP packets in one RTT), occurrence of loss events (one or more lost RTP packets in one RTT),
or ECN events, which was described earlier. or ECN events, which was described earlier.
Pseudo code for the update of the congestion window is found below. Pseudo code for the update of the congestion window is found below.
update_cwnd(bytes_newly_acked): update_cwnd(bytes_newly_acked):
# in fast increase ? # in fast increase ?
if (in_fast_increase) if (in_fast_increase)
if (qdelay_trend >= 0.2) if (qdelay_trend >= QDELAY_TREND_TH)
# incipient congestion detected, exit fast increase # incipient congestion detected, exit fast increase
in_fast_increase = false in_fast_increase = false
else else
# no congestion yet, increase cwnd if it # no congestion yet, increase cwnd if it
# is sufficiently used # is sufficiently used
# an additional slack of bytes_newly_acked is # an additional slack of bytes_newly_acked is
# added to ensure that CWND growth occurs # added to ensure that CWND growth occurs
# even when feedback is sparse # even when feedback is sparse
if (bytes_in_flight*1.5+bytes_newly_acked > cwnd) if (bytes_in_flight*1.5+bytes_newly_acked > cwnd)
cwnd = cwnd+bytes_newly_acked cwnd = cwnd+bytes_newly_acked
skipping to change at page 17, line 9 skipping to change at page 18, line 9
cwnd = max(cwnd, MIN_CWND) cwnd = max(cwnd, MIN_CWND)
CWND is updated differently depending on whether the congestion CWND is updated differently depending on whether the congestion
control is in fast increase state or not, as controlled by the control is in fast increase state or not, as controlled by the
variable in_fast_increase. variable in_fast_increase.
When in fast increase state, the congestion window is increased with When in fast increase state, the congestion window is increased with
the number of newly acknowledged bytes as long as the window is the number of newly acknowledged bytes as long as the window is
sufficiently used. Sparse feedback can potentially limit congestion sufficiently used. Sparse feedback can potentially limit congestion
window growth, an additional slack is therefore added, given by the window growth, an additional slack is therefore added, given by the
number of newly acked 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]. There are however a few differences. [RFC6817]. There are however a few differences.
o [RFC6817] specifies a constant GAIN, this specification however o [RFC6817] specifies a constant GAIN, this specification however
limits the gain when CWND is increased dependent on near limits the gain when CWND is increased dependent on near
skipping to change at page 18, line 44 skipping to change at page 19, line 44
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)
The qdelay_target is adjusted differently, depending on if The qdelay_target is adjusted differently, depending on if
qdelay_norm_var_t is above or below a given value. qdelay_norm_var_t is above or below a given value.
A low qdelay_norm_avg_t value indicates that the qdelay does not A low qdelay_norm_avg_t value indicates that the qdelay does not
change rapidly. It is desired avoid the case that the qdelay target change rapidly. It is desired to avoid the case that the qdelay
is increased due to self-congestion, indicated by a changing qdelay target is increased due to self-congestion, indicated by a changing
and consequently an increased qdelay_norm_var_t. Still it should be qdelay and consequently an increased qdelay_norm_var_t. Still it
possible to increase the qdelay target if the qdelay continues to be should be possible to increase the qdelay target if the qdelay
high. This is a simple function with a certain risk of both false continues to be high. This is a simple function with a certain risk
positives and negatives but it manages competing FTP flows reasonably of both false positives and negatives. In the simulated LTE test
well at the same time as it has proven to avoid accidental increased cases it manages competing FTP flows reasonably well at the same time
qdelay target relatively well in simulated LTE test cases. The as generally avoiding accidental increases in the qdelay target. The
algorithm can however accidentally increase the qdelay target and algorithm can however accidentally increase the qdelay target and
cause self-inflicted congestion in certain cases, therefore it is cause self-inflicted congestion in certain cases. It is therefore
recommended to turn off the algorithm if is unlikely that competing recommended that the algorithm described in this section is turned
flows will occur over the same bottleneck. off it is deemed unlikely that competing flows occur over the same
bottleneck
4.1.2.3. Lost packets detection 4.1.2.3. Lost packet detection
Lost packets detection is based on the received sequence number list. Lost packet detection is based on the received sequence number list.
A reordering window should be applied to avoid that packet reordering A reordering window should be applied to avoid packet reordering
triggers loss events. triggering loss events.
The reordering window is specified as a time unit, similar to the The reordering window is specified as a time unit, similar to the
ideas behind RACK (Recent ACKnowledgement) [RACK]. The computation ideas behind RACK (Recent ACKnowledgement) [RACK]. The computation
of the reordering window is made possible by means of a lost flag in of the reordering window is made possible by means of a lost flag in
the list of transmitted RTP packets. This flag is set if the the list of transmitted RTP packets. This flag is set if the
received sequence number list indicates that the given RTP packet is received sequence number list indicates that the given RTP packet is
missing. If a later feedback indicates that a previously lost marked missing. If a later feedback indicates that a previously lost marked
packet was indeed received, then the reordering window is updated to packet was indeed received, then the reordering window is updated to
reflect the reordering delay. The reordering window is given by the reflect the reordering delay. The reordering window is given by the
difference in time between the event that the packet was marked as difference in time between the event that the packet was marked as
lost and the event that it was indicated as successfully received. lost and the event that it was indicated as successfully received.
skipping to change at page 19, line 35 skipping to change at page 20, line 36
with higher sequence number was acknowledged. with higher sequence number was acknowledged.
4.1.2.4. Send window calculation 4.1.2.4. Send window calculation
The basic design principle behind packet transmission in SCReAM is to The basic design principle behind packet transmission in SCReAM is to
allow transmission only if the number of bytes in flight is less than allow transmission only if the number of bytes in flight is less than
the congestion window. There are however two reasons why this strict the congestion window. There are however two reasons why this strict
rule will not work optimally: rule will not work optimally:
o Bitrate variations: The media frame size is always varying to a o Bitrate variations: The media frame size is always varying to a
larger or smaller extent. A strict rule as the one given above larger or smaller extent. A strict rule can lead to that the
will have the effect that the media bitrate will have difficulties media bitrate will have difficulties to increase as the congestion
to increase as the congestion window puts a too hard restriction window puts a too hard restriction on the media frame size
on the media frame size variation. This can lead to occasional variation. This can lead to occasional queuing of RTP packets in
queuing of RTP packets in the RTP packet queue that will further the RTP packet queue that will prevent bitrate increase.
prevent bitrate increase.
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 may jump due to congestion. The effect of this is that direction may jump due to congestion. The effect of this is that
the acknowledgements are delayed with the result that the self- the acknowledgements are delayed with the result that the self-
clocking is temporarily halted, even though the forward path is clocking is temporarily halted, even though the forward path is
not congested. not congested.
The send window is adjusted depending on qdelay and its relation to The send window is adjusted depending on qdelay and its relation to
the qdelay target and the relation between the congestion window and the qdelay target and the relation between the congestion window and
the number of bytes in flight. A strict rule is applied when qdelay the number of bytes in flight. A strict rule is applied when qdelay
is higher than qdelay_target, to avoid further queue buildup in the is 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
fast when no congestion is detected while still being able to give a quickly when no congestion is detected while still being able to give
stable behavior in congested situations. a 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. pseudo code below.
calculate_send_window(qdelay, qdelay_target) calculate_send_window(qdelay, qdelay_target)
# send window is computed differently depending on congestion level # send window is computed differently depending on congestion level
if (qdelay <= qdelay_target) if (qdelay <= qdelay_target)
send_wnd = cwnd+MSS-bytes_in_flight send_wnd = cwnd+MSS-bytes_in_flight
else else
send_wnd = cwnd-bytes_in_flight send_wnd = cwnd-bytes_in_flight
end end
The send window is updated whenever an RTP packet is transmitted or The send window is updated whenever an RTP packet is transmitted or
an RTCP feedback messaged is received. More details around sender an RTCP feedback messaged is received. More details around sender
transmission control and packet pacing is found in Appendix A.3. transmission control and packet pacing are found in Appendix A.3.
4.1.2.5. Resuming fast increase 4.1.2.5. Resuming fast increase
Fast increase can resume in order to speed up the bitrate increase in Fast increase can resume in order to speed up the bitrate increase in
case congestion abates. The condition to resume fast increase case congestion abates. The condition to resume fast increase
(in_fast_increase = true) is that qdelay_trend is less than (in_fast_increase = true) is that qdelay_trend is less than
QDELAY_TREND_LO for T_RESUME_FAST_INCREASE seconds or more. QDELAY_TREND_LO for T_RESUME_FAST_INCREASE seconds or more.
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 RATE_ADJUSTMENT_INTERVAL, with the exception of a prompt reaction to
loss events. The media rate control operates based on the size of loss events. The media rate control operates based on the size of
the RTP packet send queue and observed loss events. In addition, the RTP packet send queue and observed loss events. In addition,
qdelay_trend is also considered in the media rate control, this to qdelay_trend is also considered in the media rate control to reduce
reduce the amount of induced network jitter. 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. A too
cautious setting leads to possible under-utilization of network cautious setting leads to possible under-utilization of network
capacity and that the flow is starved out by other, more capacity leading to the flow being starved out by other more
opportunistic traffic, on the other hand a too aggressive setting opportunistic traffic. On the other hand too aggressive a setting
leads to extra jitter. leads to extra 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 chosen to a low enough value to avoid
that RTP packets are queued up when the network throughput becomes RTP packets being queued up when the network throughput becomes low.
low. The sender should also be equipped with a mechanism that The sender should also be equipped with a mechanism that discards RTP
discards RTP packets in cases the network throughput becomes very low packets in cases where the network throughput becomes very low and
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 time o rate_ack: The ACKed bitrate, i.e. the volume of ACKed bits per
unit. time unit.
Both estimates are updated every 200ms. Both estimates are updated every 200ms.
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 may itself cause an unnecessary rate reduction. To overcome that may itself cause an unnecessary rate reduction. To overcome
this shortcoming; rate_ack is used as well. This gives a more stable this shortcoming; rate_ack is used as well. This gives a more stable
skipping to change at page 22, line 23 skipping to change at page 23, line 23
# 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 > 0.02) if (rtp_queue_delay_t > RTP_QDELAY_TH)
target_bitrate *= 0.95 target_bitrate *= TARGET_RATE_SCALE_RTP_QDELAY
end end
end end
rate_media_limit_t = max(current_rate_t, max(rate_media,rtp_rate_median)) rate_media_limit_t = max(current_rate_t, max(rate_media,rtp_rate_median))
rate_media_limit_t *= (2.0-1.0*qdelay_trend_mem) rate_media_limit_t *= (2.0-qdelay_trend_mem)
target_bitrate = min(target_bitrate, rate_media_limit_t) target_bitrate = min(target_bitrate, rate_media_limit_t)
target_bitrate = min(TARGET_BITRATE_MAX, target_bitrate = min(TARGET_BITRATE_MAX,
max(TARGET_BITRATE_MIN,target_bitrate)) max(TARGET_BITRATE_MIN,target_bitrate))
In case of a loss event the target_bitrate is updated and the rate In case of a loss event the target_bitrate is updated and the rate
change procedure is exited. Otherwise the rate change procedure change procedure is exited. Otherwise the rate change procedure
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, a rate reduction
pro actively avoids that RTP packets are queued up when the transmit pro actively avoids RTP packets being queued up when the transmit
rate decreases due to the reduced congestion window. A similar rate rate decreases due to the reduced congestion window. A similar rate
reduction happens when ECN events are detected. 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 real
life limitations in video coders taken into account. A too short life limitations in video coders taken into account
interval has shown to make the video coder internal rate control loop [SCReAM-implementation-experience]. A too short interval is shown to
more unstable, a too long interval makes the overall congestion make the video coder internal rate control loop more unstable, a too
control sluggish. long interval makes the overall congestion control sluggish.
When in fast increase state (in_fast_increase=true), the bitrate When in fast increase state (in_fast_increase=true), the bitrate
increase is given by the desired ramp-up speed (RAMP_UP_SPEED) . 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 1000kbps/s makes it
possible to quickly get high quality media, this is however at the possible to quickly get high quality media, this is however at the
expense of a higher risk of jitter, which can manifest itself as e.g. expense of a higher risk of jitter, which can manifest itself as e.g.
choppy video rendering. choppy video rendering.
skipping to change at page 23, line 41 skipping to change at page 24, line 41
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 faster rate increase
after congestion, at the expense of more jitter. after congestion, at the expense of more jitter in congested
situations.
4.1.3.1. FEC and packet overhead considerations 4.1.3.1. FEC and packet overhead considerations
The target bitrate given by SCReAM depicts the bitrate including RTP The target bitrate given by SCReAM depicts the bitrate including RTP
and FEC overhead. Therefore it is necessary that the media encoder and FEC overhead. Therefore it is necessary that the media encoder
takes this overhead into account when the media bitrate is set. This takes this overhead into account when the media bitrate is set. This
means that the media coder bitrate should be computed as means that the media coder bitrate should be computed as
media_rate = target_bitrate - rtp_plus_fec_overhead_bitrate media_rate = target_bitrate - rtp_plus_fec_overhead_bitrate
It is not strictly necessary to make a 100% perfect compensation for It is not strictly necessary to make a 100% perfect compensation for
the overhead as the SCReAM algorithm will inherently compensate the overhead as the SCReAM algorithm will inherently compensate for
moderate errors. Under-compensation of the overhead has the effect moderate errors. Under-compensation of the overhead has the effect
that the jitter will increase somewhat while overcompensation will of increasing jitter while overcompensation will have the effect of
have the effect that the bottleneck link becomes under-utilized. causing the bottleneck link to become under-utilized.
4.2. SCReAM Receiver 4.2. SCReAM Receiver
The simple task of the SCReAM receiver is to feedback The simple task of the SCReAM receiver is to feedback
acknowledgements of received packets and total ECN count to the acknowledgements of received packets and total ECN count to the
SCReAM sender, in addition, the receive time of the RTP packet with SCReAM sender, in addition, the receive time of the RTP packet with
the highest sequence number is echoed back. Upon reception of each the highest sequence number is echoed back. Upon reception of each
RTP packet the receiver will simply maintain enough information to RTP packet the receiver must maintain enough information to send the
send the aforementioned values to the SCReAM sender via RTCP aforementioned values to the SCReAM sender via a RTCP transport layer
transport layer feedback message. The frequency of the feedback feedback message. The frequency of the feedback message depends on
message depends on the available RTCP bandwidth. More details of the the available RTCP bandwidth. More details of the feedback and the
feedback and the frequency is found in Appendix A.4. frequency is found in Appendix A.4.
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 said drift as is the case with LEDBAT [RFC6817]. Section A.2 in
RFC however describes ways to mitigate issues with clock drift. [RFC6817] however describes ways to mitigate issues with clock
drift.
o Support for alternate ECN semantics: This specification adopts the
proposal in [Khademi-alternative-backoff-ECN] to reduce the
congestion window less when ECN based congestion events are
detected. Future work on Low Latency Low Loss for Scalable
throughput (L4S) may lead to updates in a future RFC that
describes SCReAM support for L4S.
6. Implementation status 6. Implementation status
[Editor's note: Please remove the whole section before publication, [Editor's note: Please remove the whole section before publication,
as well reference to RFC 6982] as well reference to RFC 6982]
This section records the status of known implementations of the This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC6982]. Internet-Draft, and is based on a proposal described in [RFC6982].
The description of implementations in this section is intended to The description of implementations in this section is intended to
skipping to change at page 25, line 20 skipping to change at page 26, line 29
The SCReAM algorithm has been implemented in the OpenWebRTC project The SCReAM algorithm has been implemented in the OpenWebRTC project
[OpenWebRTC], an open source WebRTC implementation from Ericsson [OpenWebRTC], an open source WebRTC implementation from Ericsson
Research. This SCReAM implementation is usable with any WebRTC Research. This SCReAM implementation is usable with any WebRTC
endpoint using OpenWebRTC. endpoint using OpenWebRTC.
o Organization : Ericsson Research, Ericsson. o Organization : Ericsson Research, Ericsson.
o Name : OpenWebRTC gst plug-in. o Name : OpenWebRTC gst plug-in.
o Implementation link : The GStreamer plug-in code for SCReAM can be o Implementation link : The GStreamer plug-in code for SCReAM can be
found at github repository [SCReAM-Implementation] The wiki found at github repository [SCReAM-implementation] The wiki
(https://github.com/EricssonResearch/openwebrtc/wiki) contains (https://github.com/EricssonResearch/openwebrtc/wiki) contains
required information for building and using OpenWebRTC. required information for building and using OpenWebRTC.
o Coverage : The code implements [I-D.ietf-rmcat-scream-cc]. The o Coverage : The code implements the specification in this memo.
current implementation has been tuned and tested to adapt a video The current implementation has been tuned and tested to adapt a
stream and does not adapt the audio streams. video stream and does not adapt the audio streams.
o Implementation experience : The implementation of the algorithm in o Implementation experience : The implementation of the algorithm in
the OpenWebRTC has given great insight into the algorithm itself the OpenWebRTC has given great insight into the algorithm itself
and its interaction with other involved modules such as encoder, and its interaction with other involved modules such as encoder,
RTP queue etc. In fact it proves the usability of a self-clocked RTP queue etc. In fact it proves the usability of a self-clocked
rate adaptation algorithm in the real WebRTC system. The rate adaptation algorithm in the real WebRTC system. The
implementation experience has led to various algorithm implementation experience has led to various algorithm
improvements both in terms of stability and design. The current improvements both in terms of stability and design. The current
implementation use an n_loss counter for lost packets indication, implementation use an n_loss counter for lost packets indication,
this is subject to change in later versions to a list of received this is subject to change in later versions to a list of received
RTP packets. RTP packets.
o Contact : irc://chat.freenode.net/openwebrtc o Contact : irc://chat.freenode.net/openwebrtc
6.2. A C++ Implementation of SCReAM 6.2. A C++ Implementation of SCReAM
o Organization : Ericsson Research, Ericsson. o Organization : Ericsson Research, Ericsson.
o Name : SCReAM. o Name : SCReAM.
o Implementation link : A C++ implementation of SCReAM is also o Implementation link : A C++ implementation of SCReAM is available
available [SCReAM-Cplusplus_Implementation]. The code includes at[SCReAM-CPP-implementation]. The code includes full support for
full support for congestion control, rate control and multi stream congestion control, rate control and multi stream handling, it can
handling, it can be integrated in web clients given the addition be integrated in web clients given the addition of extra code to
of extra code to implement the RTCP feedback and RTP queue(s). implement the RTCP feedback and RTP queue(s). The code also
includes a rudimentary implementation of a simulator that allows
The code also includes a rudimentary implementation of a simulator for some initial experiments.
that allows for some initial experiments.
o Coverage : The code implements [I-D.ietf-rmcat-scream-cc] o Coverage : The code implements the specification in this memo.
o Contact : ingemar.s.johansson@ericsson.com o Contact : ingemar.s.johansson@ericsson.com
7. Suggested experiments 7. 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, most of the
evaluation has been in simulator. The OpenWebRTC implementation work evaluation has been in simulator. The OpenWebRTC implementation work
involved extensive testing with artificial bottlenecks with varying involved extensive testing with artificial bottlenecks with varying
bandwidths and using two different video coders (OpenH264 and VP9), bandwidths and using two different video coders (OpenH264 and VP9),
the experience of this lead to further improvements of the media rate the experience of this lead to further improvements of the media rate
skipping to change at page 26, line 37 skipping to change at page 27, line 48
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 competing flows compensation
mechanism: Evaluate how SCReAM performs with competing TCP like mechanism: Evaluate how SCReAM performs with competing TCP like
traffic and to what extent the competing flows compensation causes traffic and to what extent the competing flows compensation causes
self-inflicted congestion. self-inflicted congestion.
o Determine proper parameters: A set of default parameters are given o Determine proper parameters: A set of default parameters are given
that makes SCReAM work over a reasonably large operation range, that makes SCReAM work over a reasonably large operation range,
however for instance for very low or very high bitrates it may be however for instance for very low or very high bitrates it may be
necessary to use different values for instance for RAMP_UP_SPEED. necessary to use different values for instance for the
RAMP_UP_SPEED.
8. Acknowledgements 8. Acknowledgements
We would like to thank the following persons for their comments, We would like to thank the following persons for their comments,
questions and support during the work that led to this memo: Markus questions and support during the work that led to this memo: Markus
Andersson, Bo Burman, Tomas Frankkila, Frederic Gabin, Laurits Hamm, Andersson, Bo Burman, Tomas Frankkila, Frederic Gabin, Laurits Hamm,
Hans Hannu, Nikolas Hermanns, Stefan Haakansson, Erlendur Karlsson, Hans Hannu, Nikolas Hermanns, Stefan Haakansson, Erlendur Karlsson,
Daniel Lindstroem, Mats Nordberg, Jonathan Samuelsson, Rickard Daniel Lindstroem, Mats Nordberg, Jonathan Samuelsson, Rickard
Sjoeberg, Robert Swain, Magnus Westerlund, Stefan Aalund. Many Sjoeberg, Robert Swain, Magnus Westerlund, Stefan Aalund. Many
additional thanks to RMCAT chairs Karen and Mirja for patiently additional thanks to RMCAT chairs Karen E. E. Nielsen and Mirja
reading, suggesting improvements and also for asking all the Kuehlewind for patiently reading, suggesting improvements and also
difficult but necessary questions. Thanks to Stefan Holmer and for asking all the difficult but necessary questions. Thanks to
Xiaoqing Zhu for the review. Thanks to Ralf Globisch for taking time Stefan Holmer, Xiaoqing Zhu, Safiqul Islam and David Hayes for the
to try out SCReAM in his challenging low bitrate use cases. additional review of this document. Thanks to Ralf Globisch for
taking time to try out SCReAM in his challenging low bitrate use
cases.
9. IANA Considerations 9. IANA Considerations
A new RFC4585 transport layer feedback message needs to be A new RFC4585 transport layer feedback message may to be standardized
standardized. if the use of the already existing RTCP extensions as described in
Appendix A.4 is not deemed sufficient.
10. Security Considerations 10. Security Considerations
The feedback can be vulnerable to attacks similar to those that can The feedback can be vulnerable to attacks similar to those that can
affect TCP. It is therefore recommended that the RTCP feedback is at affect TCP. It is therefore recommended that the RTCP feedback is at
least integrity protected. Furthermore, as SCReAM is self-clocked, a least integrity protected. Furthermore, as SCReAM is self-clocked, a
malicious middlebox can drop RTCP feedback packets and thus cause the malicious middlebox can drop RTCP feedback packets and thus cause the
self-clocking in SCReAM to stall. self-clocking in SCReAM to stall. This attack is however mitigated
by the minimum send rate maintained by SCReAM when no feedback is
received.
11. Change history 11. Change history
A list of changes: A list of changes:
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-05 to WG-06: Added list of suggested experiments
o WG-04 to WG-05: Congestion control and rate control simplified o WG-04 to WG-05: Congestion control and rate control simplified
somewhat somewhat
o WG-03 to WG-04: Editorial fixes o WG-03 to WG-04: Editorial fixes
o WG-02 to WG-03: Review comments from Stefan Holmer and Xiaoqing o WG-02 to WG-03: Review comments from Stefan Holmer and Xiaoqing
Zhu addressed, owd changed to qdelay for clarity. Added appendix Zhu addressed, owd changed to qdelay for clarity. Added appendix
section with RTCP feedback requirements, including a suggested section with RTCP feedback requirements, including a suggested
skipping to change at page 29, line 19 skipping to change at page 30, line 36
2014. 2014.
[I-D.ietf-rmcat-cc-codec-interactions] [I-D.ietf-rmcat-cc-codec-interactions]
Zanaty, M., Singh, V., Nandakumar, S., and Z. Sarker, Zanaty, M., Singh, V., Nandakumar, S., and Z. Sarker,
"Congestion Control and Codec interactions in RTP "Congestion Control and Codec interactions in RTP
Applications", draft-ietf-rmcat-cc-codec-interactions-02 Applications", draft-ietf-rmcat-cc-codec-interactions-02
(work in progress), March 2016. (work in progress), March 2016.
[I-D.ietf-rmcat-coupled-cc] [I-D.ietf-rmcat-coupled-cc]
Islam, S., Welzl, M., and S. Gjessing, "Coupled congestion Islam, S., Welzl, M., and S. Gjessing, "Coupled congestion
control for RTP media", draft-ietf-rmcat-coupled-cc-03 control for RTP media", draft-ietf-rmcat-coupled-cc-04
(work in progress), July 2016. (work in progress), October 2016.
[I-D.ietf-rmcat-scream-cc] [I-D.ietf-rmcat-scream-cc]
Johansson, I. and Z. Sarker, "Self-Clocked Rate Adaptation Johansson, I. and Z. Sarker, "Self-Clocked Rate Adaptation
for Multimedia", draft-ietf-rmcat-scream-cc-05 (work in for Multimedia", draft-ietf-rmcat-scream-cc-06 (work in
progress), June 2016. progress), August 2016.
[I-D.ietf-rmcat-wireless-tests] [I-D.ietf-rmcat-wireless-tests]
Sarker, Z., Johansson, I., Zhu, X., Fu, J., Tan, W., and Sarker, Z., Johansson, I., Zhu, X., Fu, J., Tan, W., and
D. Ramalho, "Evaluation Test Cases for Interactive Real- M. Ramalho, "Evaluation Test Cases for Interactive Real-
Time Media over Wireless Networks", draft-ietf-rmcat- Time Media over Wireless Networks", draft-ietf-rmcat-
wireless-tests-02 (work in progress), May 2016. wireless-tests-02 (work in progress), May 2016.
[Khademi_alternative_backoff_ECN] [Khademi-alternative-backoff-ECN]
"TCP Alternative Backoff with ECN (ABE)", "Alternative Backoff: Achieving Low Latency and High
Throughput with ECN and AQM , CAIA Technical Report",
<https://tools.ietf.org/html/draft-khademi- <https://tools.ietf.org/html/draft-khademi-
alternativebackoff-ecn-00>. alternativebackoff-ecn-00>.
[LEDBAT-delay-impact]
"Assessing LEDBAT's Delay Impact, IEEE communications
letters, vol. 17, no. 5, May 2013", May 2013,
<http://home.ifi.uio.no/michawe/research/publications/
ledbat-impact-letters.pdf>.
[OpenWebRTC] [OpenWebRTC]
"Open WebRTC project.", <http://www.openwebrtc.io/>. "Open WebRTC project.", <http://www.openwebrtc.io/>.
[PACKET_CONSERVATION] [Packet-conservation]
"Congestion Avoidance and Control", 1988. "Congestion Avoidance and Control, ACM SIGCOMM Computer
Communication Review 1988", 1988.
[QoS-3GPP] [QoS-3GPP]
TS 23.203, 3GPP., "Policy and charging control TS 23.203, 3GPP., "Policy and charging control
architecture", June 2011, <http://www.3gpp.org/ftp/specs/ architecture", June 2011, <http://www.3gpp.org/ftp/specs/
archive/23_series/23.203/23203-990.zip>. archive/23_series/23.203/23203-990.zip>.
[RACK] "RACK: a time-based fast loss detection algorithm for [RACK] "RACK: a time-based fast loss detection algorithm for
TCP", <https://http://tools.ietf.org/id/ TCP", <https://http://tools.ietf.org/id/
draft-cheng-tcpm-rack-00.txt>. draft-cheng-tcpm-rack-00.txt>.
skipping to change at page 30, line 25 skipping to change at page 32, line 5
[RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", RFC 6982, Code: The Implementation Status Section", RFC 6982,
DOI 10.17487/RFC6982, July 2013, DOI 10.17487/RFC6982, July 2013,
<http://www.rfc-editor.org/info/rfc6982>. <http://www.rfc-editor.org/info/rfc6982>.
[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,
<http://www.rfc-editor.org/info/rfc7661>. <http://www.rfc-editor.org/info/rfc7661>.
[SCReAM-Cplusplus_Implementation] [SCReAM-CPP-implementation]
"C++ Implementation of SCReAM", "C++ Implementation of SCReAM",
<https://github.com/EricssonResearch/scream>. <https://github.com/EricssonResearch/scream>.
[SCReAM-Implementation] [SCReAM-implementation]
"SCReAM Implementation", "SCReAM Implementation",
<https://github.com/EricssonResearch/openwebrtc-gst- <https://github.com/EricssonResearch/openwebrtc-gst-
plugins>. plugins>.
[SCReAM-implementation-experience]
"Updates on SCReAM : An implementation experience",
<https://www.ietf.org/proceedings/94/slides/slides-94-
rmcat-8.pdf>.
[TFWC] University College London, "Fairer TCP-Friendly Congestion [TFWC] University College London, "Fairer TCP-Friendly Congestion
Control Protocol for Multimedia Streaming", December 2007, Control Protocol for Multimedia Streaming", 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>.
Appendix A. Additional information Appendix A. Additional information
A.1. Stream prioritization A.1. 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, an RTP queue queues up congestion control and the media rate control. This is easily
RTP packets pending transmission. This is easily extended to many extended to many streams, in which case RTP packets from two or more
streams, in which case 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 applied in
[I-D.ietf-rmcat-coupled-cc] can be used. The implementation of [I-D.ietf-rmcat-coupled-cc] can be used. The implementation of
SCReAM use something that is referred to as credit based scheduling. SCReAM [SCReAM-CPP-implementation] use credit based scheduling. In
credit based scheduling, credit is accumulated by queues as they wait
Credit based scheduling is for instance implemented in IEEE 802.17. for service and are spent while the queues are being serviced. For
The short description is that credit is accumulated by queues as they instance, if one queue is allowed to transmit 1000bytes, then a
wait for service and are spent while the queues are being services.
For instance, if one queue is allowed to transmit 1000bytes, then a
credit of 1000bytes 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 in which case This principle can be extended to weighted scheduling in which case
the credit allocated to unscheduled queues depends on the weight the credit allocated to unscheduled queues depends on the relative
allocation. weights.
A.2. Computation of autocorrelation function A.2. Computation of autocorrelation function
The autocorrelation function is computed over a vector of values. The autocorrelation function is computed over a vector of values.
Let x be a vector constituting N values, the biased autocorrelation Let x be a vector constituting N values, the biased autocorrelation
function for a given lag=k for the vector x is given by . function for 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
A.3. Sender transmission control and packet pacing A.3. Sender transmission control and packet pacing
RTP packet transmission is allowed whenever the size of the next RTP RTP packet transmission is allowed whenever the size of the next RTP
packet in the sender queue is less than or equal to send window. As packet in the sender queue is less than or equal to send window. As
explained in Section 4.1.2.4 the send window is updated whenever an explained in Section 4.1.2.4 the send window is updated whenever an
RTP packet is transmitted or RTCP feedback is received, the packet RTP packet is transmitted or RTCP feedback is received, the packet
transmission rate is however restricted by means of packet pacing. transmission rate is however restricted by means of 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. that
packets are transmitted in bursts, with the increased risk of more packets are transmitted in bursts, with the increased risk of more
jitter and potentially increased packet loss. The time interval jitter and potentially increased packet loss. The time interval
between consecutive packet transmissions enforced to equal or higher between consecutive packet transmissions is enforced to be equal to
than t_pace where t_pace is given by the equations below : or higher than t_pace where t_pace is given by the equations below :
pace_bitrate = max (50000, 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
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, s_rtt is the
smoothed round trip time. smoothed round trip time. RATE_PACE_MIN=50000 is the minimum pacing
rate.
A.4. RTCP feedback considerations A.4. RTCP feedback considerations
This section describes the requirements on the RTCP feedback to make This section describes the requirements on the RTCP feedback to make
SCReAM function well. Parts of this section may be moved to a SCReAM function well. First is described the requirements on the
separate draft. First is described the requirements on the feedback feedback elements, second is described the requirements on the
elements, second is described the requirements on the feedback feedback intensity to keep the SCReAM self-clocking and rate control
intensity to keep SCReAM self-clocking and rate control loops loops function properly.
function properly.
A.4.1. Requirements on feedback elements A.4.1. Requirements on feedback elements
SCReAM requires the following elements for its basic functionality, SCReAM requires the following elements for its basic functionality,
i.e only including features that are strictly necessary in order to i.e. only including features that are strictly necessary in order to
make SCReAM function. ECN is not included as basic functionality as make SCReAM function. ECN is not included as basic functionality as
it regarded as an additional feature that is not strictly necessary it regarded as an additional feature that is not strictly necessary
even though it can improve quality of experience quite considerably. even though it can improve quality of experience quite considerably.
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 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 queueing delay. This can be realized by means of the Packet the qdelay. This can be realized by means of the Packet Receipt
Receipt Times Report Block in [RFC3611]. begin_seq should be set Times Report Block in [RFC3611]. begin_seq should be set to the
to the highest received (possibly wrapped around) sequence number, highest received (possibly wrapped around) sequence number,
end_seq should be set to begin_seq+1 % 65536. The timestamp clock end_seq should be set to begin_seq+1 % 65536. The timestamp clock
may be set according to the specification i.e equal to the RTP may be set according to [RFC3611] i.e. equal to the RTP timestamp
timestamp clock. Detailed individual packet receive times is not clock. Detailed individual packet receive times is not necessary
necessary as SCReAM does currently not describe how this can be as SCReAM does currently not describe how this can be used.
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 block defined 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 |
skipping to change at page 33, line 49 skipping to change at page 35, line 12
additional feedback elements listed below, could reduce the feedback additional feedback elements listed below, could reduce the feedback
message size a bit. message size a bit.
Additional feedback elements that can improve the performance of Additional feedback elements that can improve the performance of
SCReAM are: SCReAM are:
o Accumulated number of ECN-CE marked packets (n_ECN). This can for o Accumulated number of ECN-CE marked packets (n_ECN). This can for
instance be realized with the ECN Feedback Report Format in instance be realized with the ECN Feedback Report Format in
[RFC6679]. The given feedback report format is actually a slight [RFC6679]. The given feedback report format is actually a slight
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 ECE-CE code increments by one for each received packet with the ECN-CE code
point set. The more bulky format may be nevertheless be useful point set. The more bulky format may be nevertheless be useful
for e.g ECN black-hole detection. for e.g ECN black-hole detection.
o Source quench bit (Q): Makes it possible to request the sender to o Source quench bit (Q): Makes it possible to request the sender to
reduce its congestion window. This is useful if WebRTC media is reduce its congestion window. This is useful if WebRTC media is
received from many hosts and it becomes necessary to balance the received from many hosts and it becomes necessary to balance the
bitrates between the streams. This can currently not be realized bitrates between the streams. This can currently not be realized
with any standardized feedback format, however the ECN counter can with any standardized feedback format, however the ECN counter can
be artificially incremented, even though no ECN-CE marked packets be artificially incremented, even though no ECN-CE marked packets
are received to achieve a similar behavior. are received to achieve a similar behavior.
A.4.2. Requirements on feedback intensity A.4.2. Requirements on feedback intensity
SCReAM benefits from a relatively frequent feedback. The feedback SCReAM benefits from a relatively frequent feedback. The feedback
interval depends on the media bitrate. At low bitrates it is interval depends on the media bitrate. At low bitrates it is
sufficient with a feedback interval of 100 to 200ms, while at high sufficient with a feedback interval of 100 to 400ms, while at high
bitrates a feedback interval of ~20ms is to prefer. bitrates a feedback interval of roughly 20ms is to prefer.
The numbers above can be formulated as feedback interval function The numbers above can be formulated as feedback interval function
that can be useful for the computation of the desired RTCP bandwidth. that can be useful for the computation of the desired RTCP bandwidth.
The following equation expresses the feedback rate: The following equation expresses the feedback rate:
rate_fb = min(50,max(5,rate_media/10000)) rate_fb = min(50,max(2.5,rate_media/10000))
rate_media is the RTP media bitrate expressed in [bits/s], rate_fb is rate_media is the RTP media bitrate expressed in [bits/s], rate_fb is
the feedback rate expressed in [packets/s]. Converted to feedback the feedback rate expressed in [packets/s]. Converted to feedback
interval we get: interval we get:
fb_int = 1.0/min(50,max(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, this means that in the
case of multi-stream handling between two hosts, the feedback for two case of multi-stream handling between two hosts, the feedback for two
or more SSRCs can be bundled to save UDP/IP overhead, the final or more SSRCs can be bundled to save UDP/IP overhead, the final
realized feedback interval should however not exceed 2*fb_int in such realized feedback interval should however not exceed 2*fb_int in such
cases meaning that a scheduled feedback transmission event should not cases meaning that a scheduled feedback transmission event should not
be delayed more that fb_int. be delayed more that 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 may nonetheless be useful for e.g RTCP required by SCReAM but may nonetheless be useful for e.g RTCP
 End of changes. 112 change blocks. 
338 lines changed or deleted 394 lines changed or added

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