draft-ietf-rmcat-scream-cc-01.txt   draft-ietf-rmcat-scream-cc-02.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: January 7, 2016 July 6, 2015 Expires: April 21, 2016 October 19, 2015
Self-Clocked Rate Adaptation for Multimedia Self-Clocked Rate Adaptation for Multimedia
draft-ietf-rmcat-scream-cc-01 draft-ietf-rmcat-scream-cc-02
Abstract Abstract
This memo describes a rate adaptation algorithm for conversational This memo describes a rate adaptation algorithm for conversational
video services. The solution conforms to the packet conservation media services such as video. The solution conforms to the packet
principle and uses a hybrid loss and delay based congestion control conservation principle and uses a hybrid loss and delay based
algorithm. The algorithm is evaluated over both simulated Internet congestion control algorithm. The algorithm is evaluated over both
bottleneck scenarios as well as in a LTE (Long Term Evolution) system simulated Internet bottleneck scenarios as well as in a LTE (Long
simulator and is shown to achieve both low latency and high video Term Evolution) system simulator and is shown to achieve both low
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 January 7, 2016. This Internet-Draft will expire on April 21, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Wireless (LTE) access properties . . . . . . . . . . . . 3 1.1. Wireless (LTE) access properties . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Why is it a self-clocked algorithm? . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of SCReAM Algorithm . . . . . . . . . . . . . . . . 4 3. Overview of SCReAM Algorithm . . . . . . . . . . . . . . . . 4
3.1. Congestion Control . . . . . . . . . . . . . . . . . . . 4 3.1. Network Congestion Control . . . . . . . . . . . . . . . 7
3.2. Transmission Scheduling . . . . . . . . . . . . . . . . . 5 3.2. Sender Transmission Control . . . . . . . . . . . . . . . 7
3.3. Media Rate Control . . . . . . . . . . . . . . . . . . . 5 3.3. Media Rate Control . . . . . . . . . . . . . . . . . . . 7
4. Detailed Description of SCReAM . . . . . . . . . . . . . . . 5 4. Detailed Description of SCReAM . . . . . . . . . . . . . . . 8
4.1. SCReAM Sender . . . . . . . . . . . . . . . . . . . . . . 5 4.1. SCReAM Sender . . . . . . . . . . . . . . . . . . . . . . 8
4.1.1. Constants and Parameter values . . . . . . . . . . . 7 4.1.1. Constants and Parameter values . . . . . . . . . . . 8
4.1.1.1. Constants . . . . . . . . . . . . . . . . . . . . 8
4.1.1.2. State variables . . . . . . . . . . . . . . . . . 10
4.1.2. Network congestion control . . . . . . . . . . . . . 11 4.1.2. Network congestion control . . . . . . . . . . . . . 11
4.1.2.1. Congestion window update . . . . . . . . . . . . 12 4.1.2.1. Updating bytes_newly_acked . . . . . . . . . . . 14
4.1.2.2. Transmission scheduling . . . . . . . . . . . . . 16 4.1.2.2. Updating congestion window . . . . . . . . . . . 14
4.1.3. Video rate control . . . . . . . . . . . . . . . . . 17 4.1.2.3. Compensation for competing flows . . . . . . . . 16
4.2. SCReAM Receiver . . . . . . . . . . . . . . . . . . . . . 19 4.1.2.4. Send window calculation . . . . . . . . . . . . . 17
5. Feedback Message . . . . . . . . . . . . . . . . . . . . . . 20 4.1.2.5. Resuming fast increase . . . . . . . . . . . . . 18
6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 22 4.1.3. Media rate control . . . . . . . . . . . . . . . . . 18
7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 22 4.1.3.1. FEC and packet overhead considerations . . . . . 22
8. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 22 4.2. SCReAM Receiver . . . . . . . . . . . . . . . . . . . . . 22
9. Implementation status . . . . . . . . . . . . . . . . . . . . 23 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1. OpenWebRTC . . . . . . . . . . . . . . . . . . . . . . . 23 6. Implementation status . . . . . . . . . . . . . . . . . . . . 23
9.2. A C++ Implementation of SCReAM . . . . . . . . . . . . . 24 6.1. OpenWebRTC . . . . . . . . . . . . . . . . . . . . . . . 23
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 6.2. A C++ Implementation of SCReAM . . . . . . . . . . . . . 24
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
12. Security Considerations . . . . . . . . . . . . . . . . . . . 25 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
13. Change history . . . . . . . . . . . . . . . . . . . . . . . 25 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 10. Change history . . . . . . . . . . . . . . . . . . . . . . . 25
14.1. Normative References . . . . . . . . . . . . . . . . . . 25 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
14.2. Informative References . . . . . . . . . . . . . . . . . 26 11.1. Normative References . . . . . . . . . . . . . . . . . . 25
Appendix A. Additional features . . . . . . . . . . . . . . . . 27 11.2. Informative References . . . . . . . . . . . . . . . . . 26
A.1. Packet pacing . . . . . . . . . . . . . . . . . . . . . . 27 Appendix A. Additional features . . . . . . . . . . . . . . . . 28
A.2. Stream prioritization . . . . . . . . . . . . . . . . . . 28 A.1. Stream prioritization . . . . . . . . . . . . . . . . . . 28
A.3. Q-bit semantics (source quench) . . . . . . . . . . . . . 30 A.2. Computation of autocorrelation function . . . . . . . . . 28
A.4. Frame skipping . . . . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
Congestion in the internet is a reality and applications that are Congestion in the Internet is a reality and applications that are
deployed in the internet must have congestion control schemes in deployed in the Internet must have congestion control schemes in
place not only for the robustness of the service that it provides but place not only for the robustness of the service that it provides but
also to ensure the function of the currently deployed internet. As also to ensure the function of the currently deployed Internet. As
the interactive realtime communication imposes a great deal of the interactive realtime communication imposes a great deal of
requirements on the transport, a robust, efficient rate adaptation requirements on the transport, a robust, efficient rate adaptation
for all access types is considered as an important part of for all access types is considered as an important part of
interactive realtime communications as the transmission channel interactive realtime communications as the transmission channel
bandwidth may vary over time. Wireless access such as LTE, which is bandwidth may vary over time. Wireless access such as LTE, which is
an integral part of the current internet, increases the importance of an integral part of the current Internet, increases the importance of
rate adaptation as the channel bandwidth of a default LTE bearer rate 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 span
in available channel bandwidth. This memo describes a solution,named in available channel bandwidth. This memo describes a solution,named
SCReAM, that is based on the self-clocking principle of TCP and uses SCReAM, that is based on the self-clocking principle of TCP and uses
techniques similar to what is used in a new delay based rate techniques similar to what is used in a new delay based rate
adaptation algorithm, LEDBAT [RFC6817]. Because neither TCP nor adaptation algorithm, LEDBAT [RFC6817].
LEDBAT was designed for interactive realtime media, a few extra
features are needed to make the concept work well within this
context. This memo describes these extra features.
1.1. Wireless (LTE) access properties 1.1. Wireless (LTE) access properties
[I-D.ietf-rmcat-wireless-tests] introduces 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. moving around.
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 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. In addition, the grace time, i.e. allowed reaction time bitrate. In addition, the grace time, i.e. allowed reaction time
from the time that the congestion is detected until a reaction in from the time that the congestion is detected until a reaction in
terms of a rate reduction is effected, is generally very short, in terms of a rate reduction is effected, is generally very short, in
the order of one RTT (Round Trip Time). the order of one RTT (Round Trip Time).
1.2. Why is it a self-clocked algorithm?
Self-clocked congestion control algorithm provides with a benefit
over the rate based counterparts in that the former consists of two
parts; the congestion window computation that evolves over a longer
timescale (several RTTs) especially when the congestion window
evolution is dictated by estimated delay and; the fine grained
congestion control given by the self-clocking which operates on a
shorter time scale (1 RTT).
A rate based congestion control has only one mechanism to adjust the
sending rate and that makes it more problematic to reach the goal of
prompt reaction to congestion and also high throughput when channel
conditions are good.
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 concepts like self- The core SCReAM algorithm has similarities to the concepts of self-
clocking used in TFWC [TFWC] and follows packet conservation clocking used in TFWC [TFWC] and follows the packet conservation
principles. 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 [FACK]. congestion [PACKET_CONSERVATION].
The packet conservation principle is realized by including an In case of SCReAM, the receiver of the media sends the highest
indication of the highest received sequence number in the feedback, received sequence number back to the sender, the sender keeps a list
see Section 5, from the receiver back to the sender, the sender keeps of transmitted packets and their respective sizes. This information
a list of transmitted packets and their respective sizes. This is then used to determine the amount of bytes can be transmitted at
information is then used to determine how many bytes can be any given time instant. A congestion window puts an upper limit on
transmitted. A congestion window puts an upper limit on how many how many bytes can be in flight, i.e. transmitted but not yet
bytes can be in flight, i.e. transmitted but not yet acknowledged. acknowledged. This is how the packet conservation principle is
The congestion window is determined in a way similar to LEDBAT realized. The congestion window is determined in a way similar to
[RFC6817]. This ensures that the e2e latency is kept low. The basic LEDBAT [RFC6817].
functionality is quite simple, there are however a few steps to take
to make the concept work with conversational media. These will be
briefly described in sections Section 3.1 to Section 3.3.
The rate adaptation solution constitutes three parts- congestion LEDBAT is a congestion control algorithm that uses send and receive
control, transmission scheduling and media rate adaptation. All timestamps to estimate the queuing delay along the transmission path.
these three parts reside at the sender side. The receiver side The use of LEDBAT ensures that the e2e latency is kept low. The
algorithm is very simple in comparison as it only generates basic functionality is quite simple, there are however a few steps to
acknowledgements to received RTP packets. take to make the concept work with conversational media. In a few
words they are:
3.1. Congestion Control o Congestion window validation techniques. These are similar in
action as the method described in [I-D.ietf-tcpm-newcwv]. The
allowed idle period in this draft is shorter than in the
reference, this to avoid excessive delays in the cases where e.g.
wireless throughput has decreased during a period where the output
bitrate has been low. Furthermore, this draft allows for more
relaxed rules when the congestion window is allowed to grow, this
is necessary as the variable output bitrate generally means that
the congestion window is often under-utilized.
o Fast increase for quicker bitrate increase. It makes the media
bitrate ramp-up within 5 to 10 seconds. The behavior is similar
to TCP slowstart. The fast increase is exited when congestion is
detected. The fast increase state can be however be resumed if
the congestion level is low, this to enable a reasonably quick
rate increase in case link throughput increases.
o A delay trend is computed for earlier detection of incipient
congestion and as a result it reduces jitter.
o Addition of media a rate control function.
o Use of inflection points to calculate congestion window and media
rate to achieve reduced jitter.
o Adjustment of delay target for better performance when competing
with other loss based congestion controlled flows
The above mentioned features will be described in more detail in
sections Section 3.1 to Section 3.3.
+---------------------------+
| Media encoder |
+---------------------------+
^ |
(3)| (1)|
| RTP
| V
| +-----------+
+---------+ | |
| Media | (2) | Queue |
| rate |<------| |
| control | |RTP packets|
+---------+ | |
+-----------+
|
|
(4)|
RTP
|
v
+------------+ +--------------+
| Network | (7) | Sender |
+-->| congestion |------>| Transmission |
| | control | | Control |
| +------------+ +--------------+
| |
| (6) |(5)
|-------------RTCP----------| RTP
| |
| v
+------------+
| UDP |
| socket |
+------------+
Figure 1: SCReAM sender functional view
The SCReAM algorithm constitutes mainly of three parts: network
congestion control, sender transmission control and media rate
adaptation. All these three parts reside at the sender side.
Figure 1 shows the functional overview of a SCReAM sender. The
receiver side algorithm is very simple in comparison as it only
generates feedback containing acknowledgements to received RTP
packets, loss count and ECN [RFC6679] count.
3.1. Network Congestion Control
The congestion control sets an upper limit on how much data can be in The congestion control sets an upper limit on how much data can be in
the network (bytes in flight); this limit is called CWND (congestion the network (bytes in flight); this limit is called CWND (congestion
window) and is used in the transmission scheduling. window) and is used in the sender transmission control.
The SCReAM congestion control method, uses LEDBAT [RFC6817] to The SCReAM congestion control method, uses LEDBAT [RFC6817] to
measure the OWD (one way delay). The SCReAM sender calculates the measure the one-way delay (OWD). The OWD can be expressed as the
congestion window based on the feedback from SCReAM receiver. The estimated queuing delay. Similar to LEDBAT, it is not necessary to
congestion window is allowed to increase if the OWD is below a use synchronized clocks in sender and receiver in order to compute
the one way delay. It is however necessary that they use the same
clock frequency, or that the clock frequency at the receiver can be
inferred reliably by the sender. The SCReAM sender calculates the
congestion window based on the feedback from the SCReAM receiver.
The congestion window is allowed to increase if the OWD is below a
predefined target, otherwise the congestion window decreases. The predefined target, otherwise the congestion window decreases. The
delay target is typically set to 50-100ms. This ensures that the OWD delay target is typically set to 50-100ms. This ensures that the OWD
is kept low on the average. The reaction to loss events is similar is kept low on the average. The reaction to loss events leads to an
to that of loss based TCP, i.e. an instant reduction of CWND. instant reduction of CWND. Note that the source rate limited nature
of real time media such as video, typically means that the queuing
LEDBAT is designed with file transfers as main use case which means delay will mostly be below the given delay target, this is contrary
that the algorithm must be modified somewhat to work with rate- to the case where large files are transmitted using LEDBAT congestion
limited sources such as video. The modifications are control, in which case the queuing delay will stay close to the delay
target.
o Congestion window validation techniques. These are similar in
action as the method described in [I-D.ietf-tcpm-newcwv].
o Fast start for bitrate increase. It makes the video bitrate ramp-
up within 5 to 10 seconds. The behavior is similar to TCP
slowstart. The fast start is exited when congestion is detected.
The fast start state can be resumed if the congestion level is
low, this to enable a reasonably quick rate increase in case link
throughput increases.
o Adaptive delay target. This helps the congestion control to
compete with FTP traffic to some degree.
3.2. Transmission Scheduling 3.2. Sender Transmission Control
Transmission scheduling 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 relation between the number of bytes in flight and the congestion
window similar to TCP. Packet pacing is used to mitigate issues with window. Packet pacing is used to mitigate issues with ACK
coalescing 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. media traffic.
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 queues. The media getting too much data queued up in the RTP packet queues at the
bitrate is decreased if the RTP queue size exceeds a threshold. sender. The media bitrate is decreased if the RTP queue size exceeds
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 the
case of a RAT (Radio Access Type) handover it may be necessary to case of a RAT (Radio Access Type) handover it may be necessary to
implement additional actions, such as discarding of encoded video implement additional actions, such as discarding of encoded media
frames or frame skipping in order to ensure that the RTP queues are frames or frame skipping in order to ensure that the RTP queues are
drained quickly. Frame skipping means that the frame rate is drained quickly. Frame skipping means that the frame rate is
temporarily reduced. Discarding of old video frames is a more temporarily reduced. Which method to use is a design consideration
efficient way to reduce media latency than frame skipping but it and outside the scope of this algorithm description.
comes with a requirement to repair codec state, frame skipping is
thus to prefer as a first remedy. Frame skipping is described as an
optional to implement feature in this specification.
4. Detailed Description of SCReAM 4. Detailed Description of SCReAM
4.1. SCReAM Sender 4.1. SCReAM Sender
This section describes the sender side algorithm in more detail. It This section describes the sender side algorithm in more detail. It
is split between the network congestion control and the video rate is a split between the network congestion control and the media rate
adaptation. adaptation.
Figure 1 shows the functional overview of a SCReAM sender. The RTP A SCReAM sender implements media rate control and a queue for each
application interaction with congestion control is described in media type or source, where RTP packets containing encoded media
[I-D.ietf-rmcat-app-interaction]. Here we use a more decomposed frames are temporarily stored for transmission. Figure 1 shows the
version of the implementation model in the sense that the RTP packets details when single media sources (a.k.a streams) are used. However,
may be queued up in the sender, the transmission of these RTP packets multiple media sources are also supported in the design, in that case
is controlled by a transmission scheduler. A SCReAM sender the sender transmission control will include a transmission
implements rate control and a queue for each media type or source, scheduler. The transmission scheduler can then enforce the
where RTP packets containing encoded media frames are temporarily priorities for the different streams and act like a coupled
stored for transmission, the figure shows the details for when two congestion controller for multiple flows.
video sources (a.k.a streams) are used.
---------------------------- ----------------------------- Media frames are encoded and forwarded to the RTP queue (1). The
| Video encoder | | Video encoder | media rate adaptation adapts to the size of the RTP queue (2) and
---------------------------- ----------------------------- controls the media bitrate (3). The RTP packets are picked from the
^ | ^ ^ | ^ RTP queue (for multiple flows from each queue based on some defined
(1)| (2)| (3)| (1)| (2)| (3)| priority order or simply in a round robin fashion) (4) by the sender
| RTP | | RTP | transmission controller. The sender transmission controller (in case
| V | | V | of multiple flows a transmission scheduler) takes care of the
| ------------- | | ------------- | transmission of RTP packets, to be written to the UDP socket (5). In
----------- | |-- ----------- | |-- the general case all media must go through the sender transmission
| Rate | (4) | Queue | | Rate | (4) | Queue | controller and is allowed to be transmitted if the number of bytes in
| control |<----| | | control |<----| | flight is less than the congestion window. RTCP packets are received
| | |RTP packets| | | |RTP packets| (6) and the information about bytes in flight and congestion window
----------- | | ----------- | | is exchanged between the network congestion control and the sender
------------- ------------- transmission control (7).
| |
--------------- --------------
(5)| |(5)
RTP RTP
| |
v v
-------------- ----------------
| Network | (8) | Transmission |
| congestion |<-------->| scheduler |
| control | | |
-------------- ----------------
^ |
| (7) |(6)
---------RTCP---------- RTP
| |
| v
-------------
| UDP |
| socket |
-------------
Figure 1: SCReAM sender functional view 4.1.1. Constants and Parameter values
Video frames are encoded and forwarded to the queue (2). The media Constants and state variables are listed in this section.
rate adaptation adapts to the size of the RTP queue and controls the
video bitrate (1). The RTP packets are picked from each queue based
on some defined priority order or simply in a round robin fashion
(5). A transmission scheduler takes care of the transmission of RTP
packets, to be written to the UDP socket (6). In the general case
all media must go through the transmission scheduler and is allowed
to be transmitted if the number of bytes in flight is less than the
congestion window. Audio frames can however be allowed to be
transmitted immediately as audio is typically low bitrate and thus
contributes little to congestion, this is something that is left as
an implementation choice. RTCP packets are received (7) and the
information about bytes in flight and congestion window is exchanged
between the network congestion control and the transmission scheduler
(8).
4.1.1. Constants and Parameter values 4.1.1.1. Constants
A set of constants are defined in Table 1, state variables are The recommended values for the constants are deduced from
defined in Table 2. And finally, local variables are described in experimental results.
Table 3.
An init value [] indicates an empty array. OWD_TARGET_LO (0.1s)
Target value for the minimum OWD
+-------------------------------+------------------------+----------+ OWD_TARGET_HI (0.4s)
| Constant | Explanation | Value | Target value for the maximum OWD
+-------------------------------+------------------------+----------+
| OWD_TARGET_LO | Min OWD target | 0.1s |
| OWD_TARGET_HI | Max OWD target | 0.4s |
| MAX_BYTES_IN_FLIGHT_HEAD_ROOM | Headroom for | 1.1 |
| | limitation of CWND | |
| GAIN | Gain factor for | 1.0 |
| | congestion window | |
| | adjustment | |
| BETA | CWND scale factor due | 0.6 |
| | to loss event | |
| BETA_R | Target rate scale | 0.8 |
| | factor due to loss | |
| | event | |
| BYTES_IN_FLIGHT_SLACK | Additional slack [%] | 10% |
| | to the congestion | |
| | window | |
| RATE_ADJUST_INTERVAL | Interval between video | 0.1s |
| | bitrate adjustments | |
| FRAME_PERIOD | Video coder frame | |
| | period [s] | |
| TARGET_BITRATE_MIN | Min target_bitrate | |
| | [bps] | |
| TARGET_BITRATE_MAX | Max target_bitrate | |
| | [bps] | |
| RAMP_UP_TIME | Timespan [s] from | 10s |
| | lowest to highest | |
| | bitrate | |
| PRE_CONGESTION_GUARD | Guard factor against | 0.0..0.2 |
| | early congestion | |
| | onset. A higher value | |
| | gives less jitter | |
| | possibly at the | |
| | expense of a lower | |
| | video bitrate. | |
| TX_QUEUE_SIZE_FACTOR | Guard factor against | 0.0..2.0 |
| | RTP queue buildup | |
+-------------------------------+------------------------+----------+
Table 1: Constants OWD_WEIGHT (0.1)
Averaging factor for owd_fraction_avg
+-------------------------+--------------------+--------------------+ MAX_BYTES_IN_FLIGHT_HEAD_ROOM (1.1)
| Variable | Explanation | Init value | Headroom for the limitation of CWND
+-------------------------+--------------------+--------------------+
| owd_target | OWD target | OWD_TARGET_LO |
| owd_fraction_avg | EWMA filtered | 0.0 |
| | owd_fraction | |
| owd_fraction_hist | Vector of the last | [] |
| | 20 owd_fraction | |
| owd_trend | OWD trend, | 0.0 |
| | indicates | |
| | incipient | |
| | congestion | |
| owd_trend_mem | Low pass filtered | 0.0 |
| | version of | |
| | owd_trend | |
| owd_norm_hist | Vector of the last | [] |
| | 100 owd_norm | |
| mss | Maximum segment | 1000 |
| | size = Max RTP | |
| | packet size [byte] | |
| min_cwnd | Minimum congestion | 2*MSS |
| | window [byte] | |
| in_fast_start | True if in fast | true |
| | start state | |
| cwnd | Congestion window | min_cwnd |
| | [byte] | |
| cwnd_i | Congestion window | 1 |
| | inflection point | |
| bytes_newly_acked | The number of | 0 |
| | bytes that was | |
| | acknowledged with | |
| | the last received | |
| | acknowledgement | |
| | i.e. bytes | |
| | acknowledged since | |
| | the last CWND | |
| | update [byte]. | |
| | Reset after a CWND | |
| | update | |
| send_wnd | Upper limit of how | 0 |
| | many bytes that | |
| | can be transmitted | |
| | [byte]. Updated | |
| | when CWND is | |
| | updated and when | |
| | RTP packet is | |
| | transmitted | |
| t_pace | Approximate | 0.001 |
| | estimate of inter- | |
| | packet | |
| | transmission | |
| | interval [s], | |
| | updated when RTP | |
| | packet transmitted | |
| age_vec | A vector of the | [] |
| | last 20 RTP packet | |
| | queue delay | |
| | samples | |
| frame_skip_intensity | Indicates the | 0.0 |
| | intensity of the | |
| | frame skips | |
| since_last_frame_skip | Number of video | 0 |
| | frames since the | |
| | last skip | |
| consecutive_frame_skips | Number of | 0 |
| | consecutive frame | |
| | skips | |
| target_bitrate | Video target | TARGET_BITRATE_MIN |
| | bitrate [bps] | |
| target_bitrate_i | Video target | 1 |
| | bitrate inflection | |
| | point i.e. the | |
| | last known highest | |
| | target_bitrate | |
| | during fast start. | |
| | Used to limit | |
| | bitrate increase | |
| | close to the last | |
| | know congestion | |
| | point | |
| rate_transmit | Measured transmit | 0.0 |
| | bitrate [bps] | |
| rate_acked | Measured | 0.0 |
| | throughput based | |
| | on received | |
| | acknowledgements | |
| | [bps] | |
| rate_rtp | Measured bitrate | 0.0 |
| | from the media | |
| | encoder [bps] | |
| rate_rtp_median | Median value of | 0.0 |
| | rate_rtp, computed | |
| | over more than 10s | |
| | [bps] | |
| s_rtt | Smoothed RTT [s], | 0.0 |
| | computed similar | |
| | to method depicted | |
| | in [RFC6298] | |
| rtp_queue_size | Size of RTP | 0 |
| | packets in queue | |
| | [bits] | |
| rtp_size | Size of the last | 0 |
| | transmitted RTP | |
| | packets [byte] | |
| frame_skip | Skip encoding of | false |
| | video frame if | |
| | true | |
+-------------------------+--------------------+--------------------+
Table 2: State variables GAIN (1.0)
Gain factor for congestion window adjustment
+------------------+------------------------------------------------+ BETA_LOSS (0.6)
| Variable | Explanation | CWND scale factor due to loss event
+------------------+------------------------------------------------+
| owd | OWD = One way delay with base delay subtracted |
| | [s]. This is an estimate of the network |
| | queueing delay. |
| owd_fraction | OWD as a fraction of the OWD target |
| owd_norm | OWD normalized to OWD_TARGET_LO |
| owd_norm_mean | Average OWD norm over the last 100 samples |
| owd_norm_mean_sh | Average OWD norm over the last 20 samples |
| owd_norm_var | OWD norm variance over the last 100 samples |
| off_target | Relation between OWD and OWD target |
| scl_i | A general scalefactor that is applied to the |
| | CWND or target_bitrate increase |
| x_cwnd | Additional increase of CWND, used when |
| | send_wnd is computed |
| pace_bitrate | The allowed RTP packet transmission rate, used |
| | in the computation of t_pace [bps] |
| age_avg | Average RTP queue delay [s] |
| increment | Allowed target_bitrate increase |
| current_rate | Max of rate_transmit and rate_acked |
+------------------+------------------------------------------------+
Table 3: Local temporary variables BETA_ECN (0.8)
CWND scale factor due to ECN event
4.1.2. Network congestion control BETA_R (0.9)
Target rate scale factor due to loss event
This section explains the network congestion control, it contains two MSS (1000 byte)
main functions Maximum segment size = Max RTP packet size
o Computation of congestion window at the sender: Gives an upper BYTES_IN_FLIGHT_SLACK (10%)
limit to the number of bytes in flight i.e. how many bytes that Additional slack to the congestion window
have been transmitted but not yet acknowledged.
o Transmission scheduling at the sender: RTP packets are transmitted RATE_ADJUST_INTERVAL (0.2s)
if allowed by the relation between the number of bytes in flight Interval between media bitrate adjustments
and the congestion window. This is controlled by the send window.
Unlike TCP, SCReAM is not a byte oriented protocol, rather it is an TARGET_BITRATE_MIN
RTP packet oriented protocol. Thus it keeps a list of transmitted Min target bitrate [bps]
RTP packets and their respective sending times (wall-clock time).
The feedback indicates the highest received RTP sequence number and a
timestamp (wall-clock time) when it was received. In addition, an
ACK list is included to make it possible to determine lost packets.
4.1.2.1. Congestion window update TARGET_BITRATE_MAX
Max target bitrate [bps]
The congestion window is computed from the one way (extra) delay RAMP_UP_SPEED (200kbps/s)
estimates (OWD) that are obtained from the send and received Maximum allowed rate increase speed
timestamp of the RTP packets. LEDBAT [RFC6817] explains the details
of the computation of the OWD. An OWD sample is obtained for each
received acknowledgement. No smoothing of the OWD samples occur,
however some smoothing occurs anyway as the computation of the CWND
is in itself a low pass filter function.
SCReAM uses the terminology "Bytes in flight (bytes_in_flight)" which PRE_CONGESTION_GUARD (0.0..0.2)
is computed as the sum of the sizes of the RTP packets ranging from Guard factor against early congestion onset. A higher value gives
the RTP packet most recently transmitted down to but not including less jitter, possibly at the expense of a lower link utilization.
the acknowledged packet with the highest sequence number. As an
example: If RTP packet was sequence number SN with transmitted and
the last ACK indicated SN-5 as the highest received sequence number
then bytes in flight is computed as the sum of the size of RTP
packets with sequence number SN-4, SN-3, SN-2, SN-1 and SN.
CWND is updated differently depending on whether the congestion TX_QUEUE_SIZE_FACTOR (0.0..0.2)
control is in fast start or not and if a loss event is detected. A Guard factor against RTP queue buildup
Boolean variable in_fast_start indicates if the congestion is in fast
start state.
A loss event indicates one or more lost RTP packets within an RTT. OWD_TREND_LO (0.2) Threshold value for owd_trend
This is detected by means of inspection for holes in the sequence T_RESUME_FAST_INCREASE Time span until fast increase can be resumed,
number space in the acknowledgements with some margin for possible given that the owd_trend is below OWD_TREND_LO
packet reordering in the network. As an alternative, a timer for
loss detection similar to TCP RACK may be used.
Below is described the actions when an acknowledgement from the 4.1.1.2. State variables
receiver is received.
bytes_newly_acked is updated. owd_target (OWD_TARGET_LO)
OWD target
The OWD fraction and an average of it are computed as owd_fraction_avg (0.0)
owd_fraction = owd/owd_target EWMA filtered owd_fraction
owd_fraction_avg = 0.9* owd_fraction_avg + 0.1* owd_fraction owd_fraction_hist[20] ({0,..,0})
Vector of the last 20 owd_fraction
The OWD fraction is sampled every 50ms and the last 20 samples are owd_trend (0.0)
stored in a vector (owd_fraction_hist). This vector is used in the OWD trend, indicates incipient congestion
computation of an OWD trend that gives a value between 0.0 and 1.0
depending on how close to congestion it is. The OWD trend is
calculated as follows
Let R(owd_fraction_hist,K) be the autocorrelation function of owd_trend_mem (0.0)
owd_fraction_hist at lag K. The 1st order prediction coefficient is Low pass filtered version of owd_trend
formulated as
a = R(owd_fraction_hist,1)/R(owd_fraction_hist,0) owd_norm_hist[100] ({0,..,0})
Vector of the last 100 owd_norm
The prediction coefficient a has positive values if OWD shows an min_cwnd (2*MSS)
increasing trend, thus an indication of congestion is obtained before Minimum congestion window
the OWD target is reached. The prediction coefficient is further
multiplied with owd_fraction_avg to reduce sensitivity to increasing
OWD when OWD is very small. The OWD trend is thus computed as
owd_trend = max(0.0,min(1.0,a*owd_fraction_avg)) in_fast_increase (true)
True if in fast increase state
owd_trend_mem = max(0.99*owd_trend_mem, owd_trend) cwnd (min_cwnd)
Congestion window
The owd_trend is utilized in the media rate control and to determine cwnd_last_max (1 byte)
when to exit slow start. owd_trend_mem is used to enforce a less Congestion window inflection point, i.e. the last known highest
aggressive rate increase after congestion events. cwnd. Used to limit cwnd increase close to the last known
congestion point.
An off target value is computed as bytes_newly_acked (0)
The number of bytes that was acknowledged with the last received
acknowledgement i.e. bytes acknowledged since the last CWND update.
Reset after a CWND update
off_target = (owd_target - owd) / owd_target send_wnd (0)
Upper limit of how many bytes that can be transmitted. Updated
when CWND is updated and when RTP packet is transmitted
A temporal variable is scl_i is computed as target_bitrate (0 bps)
Media target bitrate
scl_i = max(0.2, min(1.0, (abs(cwnd-cwnd_i)/cwnd_i*4)^2)) target_bitrate_last_max (1 bps)
Media target bitrate inflection point i.e. the last known highest
target_bitrate. Used to limit bitrate increase close to the last
known congestion point
scl_i is used to limit the CWND increase when close to the last known rate_transmit (0.0 bps)
max value, before congestion was last detected. Measured transmit bitrate
The congestion window update depends on whether a loss event has rate_ack (0.0 bps)
occurred, and if the congestion control is if fast start or not. Measured throughput based on received acknowledgements
____________________________________________________________________ rate_rtp (0.0 bps)
Measured bitrate from the media encoder
On loss event: rate_rtp_median (0.0 bps)
Median value of rate_rtp, computed over more than 10s
If a loss event is detected then in_fast_start is set to false and s_rtt (0.0s)
CWND is updated according to Smoothed RTT [s], computed similar to method depicted in [RFC6298]
cwnd_i = cwnd rtp_queue_size (0 bits)
Size of RTP packets in queue
cwnd = max(min_cwnd,cwnd*BETA) rtp_size (0 byte)
Size of the last transmitted RTP packet
otherwise the CWND update continues 4.1.2. Network congestion control
____________________________________________________________________ This section explains the network congestion control, it contains two
main functions
in_fast_start = true: 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
have been transmitted but not yet acknowledged.
in_fast_start is set to false and cwnd_i=cwnd if owd_trend >= 0.2 and o Calculation of send window at the sender: RTP packets are
otherwise CWND is updated according to transmitted if allowed by the relation between the number of bytes
in flight and the congestion window. This is controlled by the
send window.
cwnd = cwnd + bytes_newly_acked*scl_i Unlike TCP, SCReAM is not a byte oriented protocol, rather it is an
RTP packet oriented protocol. Thus a list of transmitted RTP packets
and their respective transmission times (wall-clock time) is kept for
further calculation.
____________________________________________________________________ The feedback from the receiver is assumed to consist of the following
elements.
in_fast_start = false: o The highest received RTP sequence number.
Values of off_target > 0.0 indicates that the congestion window can o The wall clock timestamp corresponding to the received RTP packet
be increased. This is done according to the equations below. with he highest sequence number.
gain = GAIN*(1.0 + max(0.0, 1.0 - owd_trend/ 0.2)) o Accumulated number of lost RTP packets (n_loss).
The equation above limits the gain when near congestion is detected o Accumulated number of ECN-CE marked packets (n_ECN).
gain *= scl_i When the sender receives RTCP feedback, the OWD is calculated as
outlined in [RFC6817] and a number of variables are updated as
illustrated by the pseudo code below.
This equation limits the gain when CWND is close to its last known update_variables(owd):
max value owd_fraction = owd/owd_target
#calculate moving average
owd_fraction_avg = (1-OWD_WEIGHT)*owd_fraction_avg+
OWD_WEIGHT*owd_fraction
update_owd_fraction_hist(owd_fraction)
# R is an autocorrelation function of owd_fraction_hist
# at lag K
a = R(owd_fraction_hist,1)/R(owd_fraction_hist,0)
#calculate OWD trend
owd_trend = a*owd_fraction_avg
owd_trend_mem = max(0.99*owd_trend_mem, owd_trend)
cwnd += gain * off_target * bytes_newly_acked * mss / cwnd The OWD fraction is sampled every 50ms and the last 20 samples are
stored in a vector (owd_fraction_hist). This vector is used in the
computation of an OWD trend that gives a value between 0.0 and 1.0
depending on the estimated congestion level. The prediction
coefficient 'a' has positive values if OWD shows an increasing trend,
thus an indication of congestion is obtained before the OWD target is
reached. The prediction coefficient is further multiplied with
owd_fraction_avg to reduce sensitivity to increasing OWD when OWD is
very small. The owd_trend is utilized in the media rate control to
indicate incipient congestion and to determine when to exit from fast
increase mode. owd_trend_mem is used to enforce a less aggressive
rate increase after congestion events. The function
update_owd_fraction_hist(..) removes the oldest element and adds the
latest owd_fraction element to the owd_fraction_hist vector.
Values of off_target <= 0.0 indicates congestion, CWND is then A loss event is detected if the n_loss counter in the feedback has
updated according to the equation increased since the previous received feedback. Once a loss event is
detected, the n_loss counter is ignored 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.
The congestion window backoff due to loss events is deliberately a
bit less than is the case with e.g TCP NewReno. The reason is that
TCP is generally used to transmit whole files, which can be
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
transmit rate and often below said value, the effect of this is that
SCReAM has less opportunity to grab free capacity than a TCP based
file transfer. To compensate for this it is necessary to let SCReAM
reduce the congestion window slightly less when loss events occur.
cwnd += GAIN*off_target*bytes_newly_acked*mss/cwnd An ECN event is detected if the n_ECN counter in the feedback report
has increased since the previous received feedback. Once an ECN
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
window decrease to at most once per round trip. The congestion
window backoff due to an ECN event is deliberately smaller than if a
loss event occurs. This is inline with the idea outlined in
[Khademi_alternative_backoff_ECN] to enable ECN marking thresholds
lower than the corresponding packet drop thresholds.
The equations above are very similar to what is specified in The update of congestion window depends on whether a loss or ECN or
[RFC6817]. There are however a few differences. neither occurs. The pseudo code below describes actions taken in
case of different events.
o [RFC6817] specifies a constant GAIN, this specification however on loss(owd):
limits the gain when CWND is increased dependent on near in_fast_increase = false
congestion state and the relation to the last known max CWND cwnd_last_max = cwnd
value. cwnd = max(min_cwnd,cwnd*BETA_LOSS)
adjust_owd_target(owd)#compensating for competing flows
calculate_send_window(owd,owd_target)
o [RFC6817] specifies that the CWND increased is limited by an on ECN(owd):
additional function controlled by a constant ALLOWED_INCREASE. in_fast_increase = false
This additional limitation is removed in this specification. cwnd_last_max = cwnd
cwnd = max(min_cwnd,cwnd*BETA_ECN)
adjust_owd_target(owd)#compensating for competing flows
calculate_send_window(owd, owd_target)
____________________________________________________________________ # when no loss or ECN event is detected
on acknowledgement(owd):
update_bytes_newly_acked()
update_cwnd(bytes_newly_acked)
adjust_owd_target(owd) #compensating for competing flows
calculate_send_window(owd, owd_target)
check_to_resume_fast_increase()
A number of final steps in the congestion window update procedure are The methods are further described in detail below.
outlined below
____________________________________________________________________ 4.1.2.1. Updating bytes_newly_acked
Resume fast start: The bytes_newly_acked is incremented with a value corresponding to
how much the highest sequence number has increased since the last
feedback. As an example: If the previous acknowledgement indicated
the highest sequence number N and the new 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 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 still included in the
update of bytes_newly_acked.
Fast start can be resumed in order to speed up the bitrate increase 4.1.2.2. Updating congestion window
in case congestion abates. The condition to resume fast start
(in_fast_start = true) is that owd_trend is less than 0.2 for 1.0
seconds or more.
____________________________________________________________________ The congestion window update is based on OWD, except for the
occurrence of loss or ECN events, which was described earlier. OWD
is obtained from the send and received timestamp of the RTP packets.
LEDBAT [RFC6817] explains the details of the computation of the OWD.
An OWD sample is obtained for each received acknowledgement. No
smoothing of the OWD samples occur, however some smoothing occurs
anyway as the computation of the CWND is in itself a low pass filter
function.
Competing flows compensation, adjustment of owd_target: Pseudo code for the update of the congestion window is found below.
Competing flows compensation is needed to avoid that flows congestion update_cwnd(bytes_newly_acked):
controlled by SCReAM are starved out by flows that are more # additional scaling factor to slow down closer to target
aggressive in their nature. The owd_target is adjusted according to # The min scale factor is 0.2 to avoid that the congestion window
the owd_norm_mean_sh whenever owd_norm_var is below a given value. # growth is stalled
The condition to update owd_target is fulfilled if owd_norm_var < scale = max(0.2,min(1.0,(abs(cwnd-cwnd_last_max)/cwnd_i*4)^2))
0.16 (indicating that the standard deviation is less than 0.4).
owd_target is then update as:
owd_target = min(OWD_TARGET_HI,max(OWD_TARGET_LO, owd_norm_mean_sh* # action depends on whether algorithm is in fast increase
OWD_TARGET_LO*1.1)) if (in_fast_increase)
if(owd_trend >= 0.2)
in_fast_increase=false
cwnd_i=cwnd
else
cwnd = cwnd + bytes_newly_acked*scale
return
____________________________________________________________________ # not in fast increase phase
# off_target calculated as with LEDBAT
off_target = (owd_target - owd) / owd_target
Final CWND adjustment step: gain = GAIN
# adapt only increase based on scale
if (off_target > 0)
gain *= (1 - owd_trend/ 0.2) * scale
The congestion window is limited by the maximum number of bytes in # increase/decrease the congestion window
flight over the last 1.0 seconds according to # off_target can be positive or negative
cwnd += gain * off_target * bytes_newly_acked * MSS / cwnd
# Limit cwnd to the maximum number of bytes in flight
cwnd = min(cwnd, max_bytes_in_flight*MAX_BYTES_IN_FLIGHT_HEAD_ROOM)
cwnd = max(cwnd, MIN_CWND)
cwnd = min(cwnd, max_bytes_in_flight*MAX_BYTES_IN_FLIGHT_HEAD_ROOM) CWND is updated differently depending on whether the congestion
This avoids possible over-estimation of the throughput after for control is in fast increase or not. A Boolean variable
example, idle periods. in_fast_increase indicates if the congestion is in fast increase
state.
Finally cwnd is set to ensure that it is at least min_cwnd In fast increase state the congestion window is increased with the
number of newly acknowledged bytes scaled by a scale factor that
depends on the relation between CWND and the last known maximum value
of CWND (cwnd_last_max). The congestion window growth when
in_fast_increase is false is dictated by the relation between owd and
owd_target, also here the scale factor scale factor is applied to
limit the congestion window growth when cwnd gets close to
cwnd_last_max.
cwnd = max(cwnd, MIN_CWND) The scale factor as applied above makes the congestion window grow in
a similar way as is the case with the Cubic congestion control
algorithm.
4.1.2.2. Transmission scheduling SCReAM calculates the GAIN in a similar way to what is specified in
[RFC6817]. There are however a few differences.
The principle is to allow packet transmission of an RTP packet only o [RFC6817] specifies a constant GAIN, this specification however
if the number of bytes in flight is less than the congestion window. limits the gain when CWND is increased dependent on near
There are however two reasons why this strict rule will not work congestion state and the relation to the last known max CWND
optimally: value.
o Bitrate variations: The video frame size is always varying to a o [RFC6817] specifies that the CWND increased is limited by an
larger or smaller extent, a strict rule as the one given above additional function controlled by a constant ALLOWED_INCREASE.
will have the effect that the video bitrate have difficulties to This additional limitation is removed in this specification.
increase as the congestion window puts a too hard restriction on
the video frame size variation, this further can lead to Further the CWND is limited by max_bytes_in_flight and min_cwnd. The
occasional queuing of RTP packets in the RTP packet queue that limitation of the congestion window by the maximum number of bytes in
will prevent bitrate increase because of the increased RTP queue flight over the last 5 seconds (max_bytes_in_flight) avoids possible
size. over-estimation of the throughput after for example, idle periods.
An additional MAX_BYTES_IN_FLIGHT_HEAD_ROOM allows for a slack, to
allow for a certain amount of media coder output rate variability.
SCReAM uses the terminology "Bytes in flight (bytes_in_flight)" which
is computed as the sum of the sizes of the RTP packets ranging from
the RTP packet most recently transmitted down to but not including
the acknowledged packet with the highest sequence number. This can
be translated to the difference between the highest transmitted byte
sequence number and the highest acknowledged byte sequence number.
As an example: If RTP packet with sequence number SN is transmitted
and the last acknowledgement indicates SN-5 as the highest received
sequence number then bytes in flight is computed as the sum of the
size of RTP packets with sequence number SN-4, SN-3, SN-2, SN-1 and
SN, it does not matter if for instance packet with sequence number
SN-3 was lost, the size of RTP packet with sequence number SN-3 will
still be considered in the computation of bytes_in_flight.
4.1.2.3. Compensation for competing flows
It is likely that a flow using SCReAM algorithm will have to share
congested bottlenecks with other flows that use a more aggressive
congestion control algorithm. SCReAM takes care of such situations
by adjusting the owr_target.
adjust_owd_target(owd)
owd_norm = owd / OWD_TARGET_LOW
update_owd_norm_history(owd_norm)
# Compute variance
owd_norm_var = VARIATION(owd_norm_history(100))
# Compensation for competing traffic
if (owd_norm_var < 0.16)
# Compute average
owd_norm_avg = AVERAGE(owd_norm_history(20))
# Update target OWD
owd_target = owd_norm_avg*OWD_TARGET_LO*1.1
owd_target = min(OWD_TARGET_HI, owd_target)
owd_target = max(OWD_TARGET_LO, owd_target)
The owd_target is adjusted according to the owd_norm_mean_sh whenever
owd_norm_var is below a given value. The condition to update
owd_target is fulfilled if owd_norm_var < 0.16 (indicating that the
standard deviation is less than 0.4).
owd_norm is the OWD divided by OWD_TARGET_LO. owd_norm_mean_sh is the
short term (last 20 samples) average of owd_norm. owd_norm_var is
the variance of owd_norm over the last 100 samples.
4.1.2.4. Send window calculation
The basic design principle behind packet transmission in SCReAM is to
allow transmission only if the number of bytes in flight is less than
the congestion window. There are however two reasons why this strict
rule will not work optimally:
o Bitrate variations: The media frame size is always varying to a
larger or smaller extent. A strict rule as the one given above
will have the effect that the media bitrate will have difficulties
to increase as the congestion window puts a too hard restriction
on the media frame size variation. This can lead to occasional
queuing of RTP packets in the RTP packet queue that will further
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.
Packets are transmitted at a pace given by the send window, computed The congestion window is adjusted depending on OWD and its relation
below to the OWD target. When OWD is greater than OWD target the
congestion window enforces a strict rule that helps to prevent
further queue buildup. When OWD is less than or equal to OWD target
then an additional slack is added to the congestion window that
reduces as congestion increases, BYTES_IN_FLIGHT_SLACK is a maximum
allowed slack in percent. A large value increases the robustness to
bitrate variations in the source and congested feedback channel
issues. The possible drawback is increased delay or packet loss when
forward path congestion occurs. The adjusted congestion window
(cwnd_s) is used in the send window calculation.
The send window is computed differently depending on OWD and its The send window is given by the relation between the adjusted
relation to the OWD target. congestion window and the amount of bytes in flight according to the
pseudo code below.
o If owd > owd_target: calculate_send_window(owd, owd_target)
The send window is computed as # compensate for backward congestion and bitrate variations
send_wnd = cwnd-bytes_in_flight if (owd <= owd_target)
This enforces a strict rule that helps to prevent further queue x_cwnd=1.0+BYTES_IN_FLIGHT_SLACK*(1.0-owd_trend/0.5)/100.0
buildup. cwnd_s = max(cwnd*x_cwnd, cwnd+MSS)
o If owd <= owd_target: send_wnd = cwnd_s-bytes_in_flight
A helper variable
x_cwnd=1.0+BYTES_IN_FLIGHT_SLACK*max(0.0,
min(1.0,1.0-owd_trend/0.5))/100.0
is computed. The send window is computed as
send_wnd = max(cwnd*x_cwnd, cwnd+mss)-bytes_in_flight
This gives a slack that reduces as congestion increases,
BYTES_IN_FLIGHT_SLACK is a maximum allowed slack in percent. A
large value increases the robustness to bitrate variations in the
source and congested feedback channel issues. The possible
drawback is increased delay or packet loss when forward path
congestion occur.
4.1.3. Video rate control 4.1.2.5. Resuming fast increase
The video rate control is operated based on the size of the RTP Fast increase can be resumed in order to speed up the bitrate
packet send queue and observed loss events. In addition, owd_trend increase in case congestion abates. The condition to resume fast
is also considered in the rate control, this to reduce the amount of increase (in_fast_increase = true) is that owd_trend is less than
induced network jitter. OWD_TREND_LO for T_RESUME_FAST_INCREASE seconds or more.
4.1.3. Media rate control
The media rate control algorithm is executed at regular intervals
RATE_ADJUSTMENT_INTERVAL, with the exception of a prompt reaction to
loss events. The media rate control operates based on the size of
the RTP packet send queue and observed loss events. In addition,
owd_trend is also considered in the media rate control, this to
reduce the amount of induced network jitter.
The role of the media rate control is to strike a reasonable balance
between a low amount of queuing in the RTP queue and a sufficient
amount of data to send in order to keep the data path busy. A too
cautious setting leads to possible under-utilization of network
capacity and that the flow is starved out by other, more
opportunistic traffic, on the other hand a too aggressive setting
leads to extra jitter.
A variable target_bitrate is adjusted depending on the congestion A variable target_bitrate is adjusted depending on the congestion
state. The target bitrate can vary between a minimum value state. 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).
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_acked: The ACKed bitrate, i.e. the volume of ACKed bits per o rate_ack: The ACKed bitrate, i.e. the volume of ACKed bits per
time 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 value The current throughput, current_rate, is computed as the maximum
of rate_transmit and rate_acked. The rationale behind the use of value of rate_transmit and rate_ack. The rationale behind the use of
rate_acked 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_acked is used as well. This gives a more this shortcoming; rate_ack is used as well. This gives a more stable
stable throughput estimate. throughput estimate.
The bitrate is updated at regular intervals, given by Note that rate_ack is updated by bytes_newly_acked, which means that
RATE_ADJUST_INTERVAL and differently depending the fast start state even lost packets are regarded as acknowledged.
The rate change behavior depends on whether a loss event has The rate change behavior depends on whether a loss event has
occurred, and if the congestion control is if fast start or not. occurred, and if the congestion control is in fast increase or not.
____________________________________________________________________
On loss event:
First of all the target_bitrate is updated if a new loss event was
indicated and the rate change procedure is exited.
target_bitrate_i = target_bitrate
target_bitrate = max(BETA_R* target_bitrate, TARGET_BITRATE_MIN)
If no loss event was indicated then the rate change procedure
continues.
____________________________________________________________________
in_fast_start = true:
An allowed increment is computed based on the congestion level and
the relation to target_bitrate_i
scl_i = (target_bitrate - target_bitrate_i)/ target_bitrate_i
increment = TARGET_BITRATE_MAX* RATE_ADJUST_INTERVAL/RAMP_UP_TIME*
(1.0- min(1.0, owd_trend/0.1))
increment *= max(0.2, min(1.0, (scl_i*4)^2))
target_bitrate += increment
target_bitrate is reduced further if congestion is detected.
target_bitrate *= (1.0- PRE_CONGESTION_GUARD*owd_trend)
____________________________________________________________________
in_fast_start = false: # The target_bitrate is updated at a regular interval according
# to RATE_ADJUST_INTERVAL
target_bitrate_i is updated to the current value of target_bitrate if on loss:
in_fast_start was true the last time the bitrate was updated. target_bitrate_last_max = target_bitrate
target_bitrate = max(BETA_R* target_bitrate, TARGET_BITRATE_MIN)
exit
A pre-congestion indicator is computed as if (in_fast_increase = true)
scl_i = (target_bitrate - target_bitrate_last_max)/
target_bitrate_last_max
increment = RAMP_UP_SPEED*RATE_ADJUST_INTERVAL*
(1.0-min(1.0, owd_trend/0.2))
# Value 0.2 as the bitrate should be allowed to increase
# at least slowly --> avoid locking the rate to
# target_bitrate_last_max
increment *= max(0.2, min(1.0, (scl_i*4)^2))
target_bitrate += increment
target_bitrate *= (1.0- PRE_CONGESTION_GUARD*owd_trend)
else
pre_congestion = min(1.0, max(0.0, owd_fraction_avg-0.3)/0.7)
pre_congestion += owd_trend
target_bitrate=current_rate*(1.0-PRE_CONGESTION_GUARD*
pre_congestion)-TX_QUEUE_SIZE_FACTOR *rtp_queue_size
end
pre_congestion = min(1.0, max(0.0, owd_fraction_avg-0.3)/0.7) rate_rtp_limit = max(br, max(rate_rtp,rtp_rate_median))
rate_rtp_limit *= (2.0-1.0*owd_trend_mem)
target_bitrate = min(target_bitrate, rate_rtp_limit)
target_bitrate = min(TARGET_BITRATE_MAX,
max(TARGET_BITRATE_MIN,target_bitrate))
pre_congestion += owd_trend In case of a loss event the target_bitrate is updated and the rate
change procedure is exited. Otherwise the rate change procedure
continues. An ECN event does not cause any action, the reason to
this is that the congestion window is reduced less due to ECN events
than loss events, the effect is thus that the expected additional RTP
queuing delay due to ECN events is so small that an additional
decrease in media rate is not warranted.
The target bitrate is computed as When in fast increase state, the bitrate increase is given by the
target_bitrate=current_rate*(1.0- desired ramp-up speed (RAMP_UP_SPEED) and is limited by the relation
PRE_CONGESTION_GUARD*pre_congestion)-TX_QUEUE_SIZE_FACTOR between the current bitrate and the last known max bitrate.
*rtp_queue_size Furthermore an increased OWD trend limits the bitrate increase. The
setting of RAMP_UP_SPEED depends on preferences, a high setting such
as 1000kbps/s makes it possible to quickly gain high quality media,
this is however at the expense of a higher risk of jitter, which can
manifest itself as e.g. choppy video rendering.
____________________________________________________________________ When in_fast_increase is false, the bitrate increase is given by the
current bitrate and is also controlled by the estimated RTP queue and
the OWD trend, thus it is sufficient that an increased congestion
level is sensed by the network congestion control to limit the
bitrate.
Final step: In the fast increase phase an allowed increment is computed based on
the congestion level and the relation to target_bitrate_last_max and
the target_bitrate is reduced further if congestion is detected.
As a final step, the target bitrate is limited such that it is kept If in_fast_increase is false then the target_bitrate_last_max is
within reasonable bounds. updated to the current value of target_bitrate if in_fast_increase
was true the last time the bitrate was updated. Additionally, a pre-
congestion indicator is computed and the rate is adjusted
accordingly.
In cases where input stimuli to the media encoder is static, for In cases where input stimuli to the media encoder is static, for
instance in "talking head" scenarios, the target bitrate is not instance in "talking head" scenarios, the target bitrate is not
always fully utilized. This may cause undesirable oscillations in always fully utilized. This may cause undesirable oscillations in
the target bitrate in the cases where the link throughput is limited the target bitrate in the cases where the link throughput is limited
and the media coder input stimuli changes between static and varying. and the media coder input stimuli changes between static and varying.
To overcome this issue, the target bitrate is capped to be less than To overcome this issue, the target bitrate is capped to be less than
a given multiplier of a median value of the history of media coder a given multiplier of a median value of the history of media coder
output bitrates. A rate_rtp_limit is computed as output bitrates, rate_rtp_limit. A multiplier is applied to
rate_rtp_limit, depending on congestion history. The target_bitrate
rate_rtp_limit = max(br, max(rate_rtp,rtp_rate_median)) is then limited by this rate_rtp_limit.
A multiplier is applied to rate_rtp_limit, depending on congestion
history
rate_rtp_limit *= (2.0-1.0*owd_trend_mem)
The target_bitrate is then limited by rate_rtp_limit
target_bitrate = min(target_bitrate, rate_rtp_limit)
Finally the target_bitrate is enforced to be within the defined min Finally the target_bitrate is enforced to be within the defined min
and max values and max values.
target_bitrate =
min(TARGET_BITRATE_MAX,max(TARGET_BITRATE_MIN,target_bitrate))
4.2. SCReAM Receiver
The SCReAM receiver is very simple in its implementation. The task
is to feedback acknowledgements of received packets. For that
purpose a set of state variables are needed, these are explained in
Table 4.
One set of state variables are maintained per stream.
+-----------------------------+-----------------------------+-------+
| Variable | Explanation | Init |
| | | value |
+-----------------------------+-----------------------------+-------+
| rx_timestamp | The wall clock timestamp | 0 |
| | when the latest RTP packet | |
| | was received | |
| highest_rtp_sequence_number | The highest received | 0 |
| | sequence number | |
| ack_vector | A 16 bit vector that | 0 |
| | indicates received RTP | |
| | packets with a sequence | |
| | number lower than | |
| | highest_rtp_sequence_number | |
| n_loss | An 8 bit counter for the | 0 |
| | number of lost RTP packets, | |
| | separate counters are | |
| | maintained for each SSRC | |
| n_ECN | An 8 bit counter for the | 0 |
| | number of ECN-CE marked RTP | |
| | packets, separate counters | |
| | are maintained for each | |
| | SSRC | |
| pending_feedback | Indicates that an RTP | false |
| | packet was received and | |
| | that an RTCP packet can be | |
| | generated when RTCP timing | |
| | rules permit | |
| last_transmit_t | Last time an RTCP packet | -1.0 |
| | was transmitted, this is | |
| | used to ensure that RTCP | |
| | feedback is generated | |
| | fairly for all streams. | |
+-----------------------------+-----------------------------+-------+
Table 4: State variables
Upon reception of an RTP packet, the state variables in Table 4
should be updated and the RTCP processing function should be
notified. An RTCP packet is later generated based on the state
variables, how often this is done depends on the RTCP bandwidth.
5. Feedback Message
The feedback is over RTCP [RFC3550] and is based on [RFC4585]. It is
implemented as a transport layer feedback message (RTPFB), see
proposed example in Figure 2. The feedback control information part
(FCI) consists of the following elements.
o Highest received RTP sequence number: The highest received RTP
sequence number for the given SSRC
o n_lost: Ackumulated number of lost RTP packets for the given SSRC
o Timestamp: A timestamp value indicating when the last packet was
received which makes it possible to compute the one way (extra)
delay (OWD).
o n_ECN: Ackumulated number of ECN-CE marked RTP packets for the
given SSRC
o Source quench bit (Q): Makes it possible to request the sender to
reduce its congestion window. This is useful if WebRTC media is
received from many hosts and it becomes necessary to balance the
bitrates between the streams.
0 1 2 3 The vary reader may notice the dependency on the OWD in the
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 computation of the target bitrate, this manifests itself in the use
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ of the owd_trend and owd_fraction_avg. As these parameters are used
|V=2|P| FMT | PT | length | also in the network congestion control one may suspect that some odd
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ interaction between the media rate control and the network congestion
| SSRC of packet sender | control, this is in fact the case if the parameter
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PRE_CONGESTION_GUARD is set to a high value. The use of owd_trend
| SSRC of media source | and owd_fraction_avg in the media rate control is solely to reduce
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ jitter, the dependency can be removed by setting
| Highest recv. seq. nr. (16b) | n_lost | n_ECN | PRE_CONGESTION_GUARD=0, the effect is a somewhat faster rate increase
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ at the expense of more jitter.
| Timestamp (32bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Q| Reserved for future use |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Transport layer feedback message 4.1.3.1. FEC and packet overhead considerations
To make the feedback as frequent as possible, the feedback packets The target bitrate given by SCReAM depicts the bitrate including RTP
are transmitted as reduced size RTCP according to [RFC5506]. and FEC overhead. Therefore it is necessary that the media encoder
takes this overhead into account when the media bitrate is set.
It is not strictly necessary to make a 100% perfect compensation for
the overhead as the SCReAM algorithm will inherently compensate
moderate errors. Under-compensation for the overhead has the effect
that the jitter will increase somewhat while overcompensation will
have the effect that the bottleneck link becomes under-utilized.
The timestamp clock time is recommended to be set to a fixed value 4.2. SCReAM Receiver
such as 1000Hz, defined in this specification. The n_lost and n_ECN
makes it possible to take necessary actions on the detection of lost
and ECN marked packets.
Section 4 describes the main algorithm details and how the feedback The simple task of the SCReAM receiver is to feedback
is used. acknowledgements of received packets, total loss count and total ECN
count to the SCReAM sender. Upon reception of each RTP packet the
receiver will simply maintain enough information to send the
aforementioned values to the SCReAM sender via RTCP transport layer
feedback message. The frequency of the feedback message depends on
the available RTCP bandwidth. The details of this feedback is given
in another document.
6. Discussion 5. Discussion
This section covers a few open discussion points This section covers a few discussion points
o RTCP feedback overhead: SCReAM benefits from a relatively frequent o RTCP feedback overhead: SCReAM benefits from a relatively frequent
feedback. Experiments have shown that a feedback rate roughly feedback. Experiments have shown that a feedback rate roughly
equal to the frame rate gives a stable self-clocking and equal to the frame rate gives a stable self-clocking and
robustness against loss of feedback. With a maximum bitrate of robustness against loss of feedback. With a maximum bitrate of
1500kbps the RTCP feedback overhead is in the range 10-15kbps with 1500kbps the RTCP feedback overhead is in the range 10-15kbps with
reduced size RTCP, including IP and UDP framing, in other words reduced size RTCP [RFC5506], including IP and UDP framing, in
the RTCP overhead is quite modest and should not pose a problem in other words the RTCP overhead is quite modest and should not pose
the general case. Other solutions may be required in highly a problem in the general case. Other solutions may be required in
asymmetrical link capacity cases. Worth notice is that SCReAM can highly asymmetrical link capacity cases. Worth notice is that
work with as low feedback rates as once every 200ms, this however SCReAM can work with as low feedback rates as once every 200ms,
comes with a higher sensitivity to loss of feedback and also a this however comes with a higher sensitivity to loss of feedback
potential reduction in throughput. and also a potential reduction in throughput.
o AVPF mode: The RTCP feedback is based on AVPF regular mode. The o AVPF mode: The RTCP feedback is based on AVPF regular mode. The
SCReAM feedback is transmitted as reduced size RTCP so save SCReAM feedback is transmitted as reduced size RTCP so save
overhead, it is however required to transmit full compound RTCP at overhead, it is however required to transmit full compound RTCP at
regular intervals, this interval can be controlled by trr-int regular intervals, this interval can be controlled by trr-int
depicted in [RFC4585]. depicted in [RFC4585].
o BETA, CWND scale factor due to loss: The BETA value is recommended o Clock drift: SCReAM can suffer from the same issues with clock
to be higher than 0.5. The reason behind this is that congestion drift as is the case with LEDBAT [RFC6817]. Section A.2 in said
control for multimedia has to deal with a source that is rate RFC however describes ways to mitigate issues with clock drift.
limited. A file transfer has "unlimited" source bitrate in
comparison. The outcome is that SCReAM must be a little more
aggressive than a file transfer in order to not be out competed.
7. Conclusion
This memo describes a congestion control algorithm for RMCAT that it
is particularly good at handling the quickly changing condition in
wireless network such as LTE. The solution conforms to the packet
conservation principle and leverages on novel congestion control
algorithms and recent TCP research, together with media bitrate
determined by sender queuing delay and given delay thresholds. The
solution has shown potential to meet the goals of high link
utilization and prompt reaction to congestion. The solution is
realized with a new RFC4585 transport layer feedback message.
8. Open issues
A list of open issues.
o Describe how clock drift compensation is done
o Describe how FEC overhead is accounted for in target_bitrate
computation
o Investigate the impact of more sparse RTCP feedback, for instance
once per RTT
o Describe ECN behavior
9. 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
assist the IETF in its decision processes in progressing drafts to assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation RFCs. Please note that the listing of any individual implementation
skipping to change at page 23, line 37 skipping to change at page 23, line 30
features. Readers are advised to note that other implementations may features. Readers are advised to note that other implementations may
exist. exist.
According to [RFC6982], "this will allow reviewers and working groups According to [RFC6982], "this will allow reviewers and working groups
to assign due consideration to documents that have the benefit of to assign due consideration to documents that have the benefit of
running code, which may serve as evidence of valuable experimentation running code, which may serve as evidence of valuable experimentation
and feedback that have made the implemented protocols more mature. and feedback that have made the implemented protocols more mature.
It is up to the individual working groups to use this information as It is up to the individual working groups to use this information as
they see it". they see it".
9.1. OpenWebRTC 6.1. OpenWebRTC
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.
skipping to change at page 24, line 15 skipping to change at page 24, line 6
However, people are encouraged to have look at it and send However, people are encouraged to have look at it and send
feedback. This wiki feedback. This wiki
(https://github.com/EricssonResearch/openwebrtc/wiki) contains (https://github.com/EricssonResearch/openwebrtc/wiki) contains
required information for building and using OpenWebRTC. Note that required information for building and using OpenWebRTC. Note that
to get all the SCReAM related code and build them, one has to use to get all the SCReAM related code and build them, one has to use
the cerbero fork from DanielLindstrm' s repository the cerbero fork from DanielLindstrm' s repository
(https://github.com/DanielLindstrm/cerbero/tree/scream) instead of (https://github.com/DanielLindstrm/cerbero/tree/scream) instead of
EricssonResearch fork of cerbero. EricssonResearch fork of cerbero.
o Coverage : The code implements [I-D.ietf-rmcat-scream-cc]. The o Coverage : The code implements [I-D.ietf-rmcat-scream-cc]. The
current implementation has been tuned and tested to adapt video current implementation has been tuned and tested to adapt a video
stream and does not adapt the audio streams. 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. For example, improvements both in terms of stability and design. For example,
improved rate increase behavior and removal of the ACK vector from improved rate increase behavior and removal of the ACK vector from
the feedback message. the feedback message.
o Contact : irc://chat.freenode.net/openwebrtc o Contact : irc://chat.freenode.net/openwebrtc
9.2. A C++ Implementation of SCReAM 6.2. A C++ Implementation of SCReAM
o Organization : Ericsson Research, Ericsson. o Organization : Ericsson Research, Ericsson.
o Name : SCReAM. o Name : SCReAM.
o Implementation link : A C++ implementation of SCreAM is also o Implementation link : A C++ implementation of SCreAM is also
available which is aimed for doing quick available which is aimed for doing quick
experiments[SCReAM-Cplusplus_Implementation]. This repository experiments[SCReAM-Cplusplus_Implementation]. This repository
also includes a rudimentary implementation of a simulator. This also includes a rudimentary implementation of a simulator. This
code can be included in other simulators like NS-3. code can be included in other simulators like NS-3.
o Coverage : The code implements [I-D.ietf-rmcat-scream-cc] o Coverage : The code implements [I-D.ietf-rmcat-scream-cc]
o Contact : ingemar.s.johansson@ericsson.com, o Contact : ingemar.s.johansson@ericsson.com,
zaheduzzaman.sarker@ericsson.com zaheduzzaman.sarker@ericsson.com
10. Acknowledgements 7. Acknowledgements
We would like to thank the following persons for their comments, We would like to thank the following persons for their comments,
questions and support during the work that led to this memo: Markus questions and support during the work that led to this memo: Markus
Andersson, Bo Burman, Tomas Frankkila, Frederic Gabin, Laurits Hamm, Andersson, Bo Burman, Tomas Frankkila, Frederic Gabin, Laurits Hamm,
Hans Hannu, Nikolas Hermanns, Stefan Haakansson, Erlendur Karlsson, Hans Hannu, Nikolas Hermanns, Stefan Haakansson, Erlendur Karlsson,
Daniel Lindstroem, Mats Nordberg, Jonathan Samuelsson, Rickard Daniel Lindstroem, Mats Nordberg, Jonathan Samuelsson, Rickard
Sjoeberg, Robert Swain, Magnus Westerlund, Stefan Aalund. Sjoeberg, Robert Swain, Magnus Westerlund, Stefan Aalund. Many
additional thanks to Karen and Mirja for patiently reading,
suggesting improvements and also for asking all the difficult but
necessary questions.
11. IANA Considerations 8. IANA Considerations
A new RFC4585 transport layer feedback message needs to be A new RFC4585 transport layer feedback message needs to be
standardized. standardized.
12. Security Considerations 9. Security Considerations
The feedback can be vulnerable to attacks similar to those that can The feedback can be vulnerable to attacks similar to those that can
affect TCP. It is therefore recommended that the RTCP feedback is at affect TCP. It is therefore recommended that the RTCP feedback is at
least integrity protected. least integrity protected.
13. Change history 10. Change history
A list of changes: A list of changes:
o WG-01 to WG-02: Complete restructuring of the document. Moved
feedback message to a separate draft.
o WG-00 to WG-01 : Changed the Source code section to Implementation o WG-00 to WG-01 : Changed the Source code section to Implementation
status section. status section.
o -05 to WG-00 : First version of WG doc, moved additional features o -05 to WG-00 : First version of WG doc, moved additional features
section to Appendix. Added description of prioritization in section to Appendix. Added description of prioritization in
SCReAM. Added description of additional cap on target bitrate SCReAM. Added description of additional cap on target bitrate
o -04 to -05 : ACK vector is replaced by a loss counter, PT is o -04 to -05 : ACK vector is replaced by a loss counter, PT is
removed from feedback, references to source code added removed from feedback, references to source code added
o -03 to -04 : Extensive changes due to review comments, code o -03 to -04 : Extensive changes due to review comments, code
somewhat modified, frame skipping made optional somewhat modified, frame skipping made optional
o -02 to -03 : Added algorithm description with equations, removed o -02 to -03 : Added algorithm description with equations, removed
pseudo code and simulation results pseudo code and simulation results
o -01 to -02 : Updated GCC simulation results o -01 to -02 : Updated GCC simulation results
o -00 to -01 : Fixed a few bugs in example code o -00 to -01 : Fixed a few bugs in example code
14. References 11. References
14.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <http://www.rfc-editor.org/info/rfc3550>.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control "Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
2006. DOI 10.17487/RFC4585, July 2006,
<http://www.rfc-editor.org/info/rfc4585>.
[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size
Real-Time Transport Control Protocol (RTCP): Opportunities Real-Time Transport Control Protocol (RTCP): Opportunities
and Consequences", RFC 5506, April 2009. and Consequences", RFC 5506, DOI 10.17487/RFC5506, April
2009, <http://www.rfc-editor.org/info/rfc5506>.
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent,
"Computing TCP's Retransmission Timer", RFC 6298, June "Computing TCP's Retransmission Timer", RFC 6298,
2011. DOI 10.17487/RFC6298, June 2011,
<http://www.rfc-editor.org/info/rfc6298>.
[RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, [RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind,
"Low Extra Delay Background Transport (LEDBAT)", RFC 6817, "Low Extra Delay Background Transport (LEDBAT)", RFC 6817,
December 2012. DOI 10.17487/RFC6817, December 2012,
<http://www.rfc-editor.org/info/rfc6817>.
14.2. Informative References
[FACK] "Forward Acknowledgement: Refining TCP Congestion 11.2. Informative References
Control", 2006.
[I-D.ietf-rmcat-app-interaction] [I-D.ietf-rmcat-app-interaction]
Zanaty, M., Singh, V., Nandakumar, S., and Z. Sarker, "RTP Zanaty, M., Singh, V., Nandakumar, S., and Z. Sarker, "RTP
Application Interaction with Congestion Control", draft- Application Interaction with Congestion Control", draft-
ietf-rmcat-app-interaction-01 (work in progress), October ietf-rmcat-app-interaction-01 (work in progress), October
2014. 2014.
[I-D.ietf-rmcat-cc-codec-interactions]
Zanaty, M., Singh, V., Nandakumar, S., and Z. Sarker,
"Congestion Control and Codec interactions in RTP
Applications", draft-ietf-rmcat-cc-codec-interactions-01
(work in progress), October 2015.
[I-D.ietf-rmcat-coupled-cc]
Islam, S., Welzl, M., and S. Gjessing, "Coupled congestion
control for RTP media", draft-ietf-rmcat-coupled-cc-00
(work in progress), September 2015.
[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-00 (work in for Multimedia", draft-ietf-rmcat-scream-cc-01 (work in
progress), May 2015. progress), July 2015.
[I-D.ietf-rmcat-wireless-tests] [I-D.ietf-rmcat-wireless-tests]
Sarker, Z. and I. Johansson, "Evaluation Test Cases for Sarker, Z. and I. Johansson, "Evaluation Test Cases for
Interactive Real-Time Media over Wireless Networks", Interactive Real-Time Media over Wireless Networks",
draft-ietf-rmcat-wireless-tests-00 (work in progress), draft-ietf-rmcat-wireless-tests-00 (work in progress),
June 2015. June 2015.
[I-D.ietf-tcpm-newcwv] [I-D.ietf-tcpm-newcwv]
Fairhurst, G., Sathiaseelan, A., and R. Secchi, "Updating Fairhurst, G., Sathiaseelan, A., and R. Secchi, "Updating
TCP to support Rate-Limited Traffic", draft-ietf-tcpm- TCP to support Rate-Limited Traffic", draft-ietf-tcpm-
newcwv-13 (work in progress), June 2015. newcwv-13 (work in progress), June 2015.
[Khademi_alternative_backoff_ECN]
"TCP Alternative Backoff with ECN (ABE)",
<https://tools.ietf.org/html/draft-khademi-
alternativebackoff-ecn-00>.
[OpenWebRTC] [OpenWebRTC]
"Open WebRTC project.", <http://www.openwebrtc.io/>. "Open WebRTC project.", <http://www.openwebrtc.io/>.
[PACKET_CONSERVATION]
"Congestion Avoidance and Control", 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>.
[RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P.,
and K. Carlberg, "Explicit Congestion Notification (ECN)
for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August
2012, <http://www.rfc-editor.org/info/rfc6679>.
[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, July Code: The Implementation Status Section", RFC 6982,
2013. DOI 10.17487/RFC6982, July 2013,
<http://www.rfc-editor.org/info/rfc6982>.
[SCReAM-Cplusplus_Implementation] [SCReAM-Cplusplus_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/DanielLindstrm/openwebrtc-gst- <https://github.com/DanielLindstrm/openwebrtc-gst-
plugins/tree/scream>. plugins/tree/scream>.
skipping to change at page 27, line 34 skipping to change at page 28, line 21
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 features Appendix A. Additional features
This section describes additional features. They are not required This section describes additional features. They are not required
for the basic functionality of SCReAM but can improve performance in for the basic functionality of SCReAM but can improve performance in
certain scenarios and topologies. certain scenarios and topologies.
A.1. Packet pacing A.1. Stream prioritization
Packet pacing is used in order to mitigate coalescing i.e. that
packets are transmitted in bursts.
Packet pacing is enforced when owd_fraction_avg is greater than 0.1.
The time interval between consecutive packet transmissions is then
enforced to equal or higher than t_pace where t_pace is given by the
equations below.
pace_bitrate = max (50000, cwnd* 8 / s_rtt)
t_pace = rtp_size * 8 / pace_bitrate
rtp_size is the size of the last transmitted RTP packet
A.2. Stream prioritization
As mentioned in Section 4, the prioritization between several streams
can be managed in many different ways. The most simple way is to
pick RTP packets from the RTP queues in a round-robin fashion. For
more advanced scheduling, more advanced algorithms are required.
Below is described the algorithm that is implemented in the SCReAM
code Section 9.
Suppose that we have two video streams, where stream 1 has priority
1.0 and stream 2 has priority 0.5. Each stream starts with a credit
of 0 bytes, credit is given to streams that are not given permission
to transmit at a given scheduling instant, the credit is considered
in later transmission instants.
The steps below outline how transmission and scheduling of the two
RTP streams can evolve. For simplicily it is assumed that the stream
RTP queues contain 1200 byte packets.
1. SCReAMs send window allows transmission of 1200 bytes.
* The stream with the highest priority is picked, in this case
it is stream 1. Stream 1 thus transmit 1200 bytes.
* Stream 2 gets its credit increased by 1200*0.5/1.0 = 600 byte
and thus has a credit of 600 bytes.
2. SCReAMs send window allows transmission of another 1200 bytes.
* Stream 2 has too little credit (600 bytes) to transmit a 1200
byte packet.
* Stream 1 is therefore picked again as it has the highest
priority and thus gets to transmit yet another 1200 byte
packet.
* Stream 2 gets its credit increased by 1200*0.5/1.0 = 600 byte
and thus has a credit of 1200 bytes.
3. SCReAMs send window allows transmission of another 1200bytes.
* Stream 2 now has enough credit (1200 bytes) to transmit a 1200
byte packet.
* Stream 2 thus transmits a 1200 byte packet and in the process
gets its credit reduced by 1200 byte and is then down to a
credit of 0.
* Stream 1 gets its credit increased by 1200*1.0/0.5 = 2400 byte
and thus has a credit of 2400 bytes.
4. SCReAMs send window allows transmission of another 1200 bytes.
1. Stream 1 now has the highest credit (2400bytes).
2. Stream 1 thus transmits a 1200 byte packet and in the process
gets its credit reduced by 1200 byte and is then down to a
credit of 1200 bytes.
3. Stream 2 gets its credit increased by 1200*0.5/1.0 = 600 byte
and thus has a credit of 600 bytes.
5. SCReAMs send window allows transmission of another 1200 bytes.
1. Stream 1 still has the highest credit (1200 bytes).
2. Stream 1 thus transmits a 1200 byte packet and in the process
gets its credit reduced by 1200 byte and is then down to a
credit of 0.
3. Stream 2 gets its credit increased by 1200*0.5/1.0 = 600 byte
and thus has a credit of 1200bytes.
6. SCReAMs send window allows transmission of another 1200 bytes.
1. Stream 2 now has the highest credit (1200 bytes).
2. Stream 2 thus transmits a 1200 byte packet and in the process
gets its credit reduced by 1200 byte and is then down to a
credit of 0.
3. Stream 1 gets its credit increased by 1200*1.0/0.5 = 2400
byte and thus has a credit of 2400 bytes.
The procedure above repeats it self. In the above example it is
quite easy to see that stream 1 gets to transmit 2 RTP packets for
every 1 RTP packets that stream 2 gets to transmit. The very detais
of the algoritm is found in the C++ code (see Section 9) in the
module ScreamTx and the functions getPrioritizedStream(..),
addCredit(..) and subtractCredit(..).
The above functionality works relatively well and operates with at
the same speed as RTP packet transmission. There are however cases
where rate limited video or very large IR frames makes the
prioritization less efficient. The adjustPriorities(..) function in
ScreamTx solves this issue on a longer time scale by means of an
additional compensation for deviations in the measured transmit
bitrate of the individual streams.
Prioritization mechanisms of sources that may be highly variant is a
relatively complicated task to achieve. The above outlined algorithm
manages it to some degree but it is quite likely that the algorithm
needs to be refined further.
A.3. Q-bit semantics (source quench)
The Q bit in the feedback is set by a receiver to signal that the
sender should reduce the bitrate. The sender will in response to
this reduce the congestion window with the consequence that the video
bitrate decreases. A typical use case for source quench is when a
receiver receives streams from sources located at different hosts and
they all share a common bottleneck, typically it is difficult to
apply any rate distribution signaling between the sending hosts. The
solution is then that the receiver sets the Q bit in the feedback to
the sender that should reduce its rate, if the streams share a common
bottleneck then the released bandwidth due to the reduction of the
congestion window for the flow that had the Q bit set in the feedback
will be grabbed by the other flows that did not have the Q bit set.
This is ensured by the opportunistic behavior of SCReAM's congestion
control. The source quench will have no or little effect if the
flows do not share the same bottleneck.
The reduction in congestion window is proportional to the amount of
SCReAM RTCP feedback with the Q bit set, the below steps outline how
the sender should react to RTCP feedback with the Q bit set. The
reduction is done once per RTT. Let :
o n = Number of received RTCP feedback messages in one RTT
o n_q = Number of received RTCP feedback messages in one RTT, with Q
bit set.
The new congestion window is then expressed as:
cwnd = max(MIN_CWND, cwnd*(1.0-0.5* n_q /n))
Note that CWND is adjusted at most once per RTT. Furthermore The
CWND increase should be inhibited for one RTT if CWND has been
decreased as a result of Q bits set in the feedback.
The required intensity of the Q-bit set in the feedback in order to
achieve a given rate distribution depends on many factors such as
RTT, video source material etc. The receiver thus need to monitor
the change in the received video bitrate on the different streams and
adjust the intensity of the Q-bit accordingly.
A.4. Frame skipping
Frame skipping is a feature that makes it possible to reduce the size
of the RTP queue in the cases that e.g. the channel throughput drops
dramatically or even goes below the lowest possible video coder rate.
Frame skipping is optional to implement as it can sometimes be
difficult to realize e.g. due to lack of API function to support
this.
Frame skipping is controlled by a flag frame_skip which, if set to 1
dictates that the video coder should skip the next video frame. The
frame skipping intensity at the current time instant is computed
according to the steps below
The queuing delay is sampled every frame period and the last 20
samples are stored in a vector age_vec
An average queuing delay is computed as a weighted sum over the
samples in age_vec. age_avg at the current time instant is computed
as
age_avg(n) = SUM age_vec(n-k)*w(k) k = [0..20[
w(n) are weight factors arranged to give the most recent samples a
higher weight.
The change in age_avg is computed as
age_d = age_avg(n) - age_avg(n-1)
The frame skipping intensity at the current time instant n is
computed as
o If age_d > 0 and age_avg > 2*FRAME_PERIOD:
frame_skip_intensity = min(1.0, (age_vec(n)-2*FRAME_PERIOD)/(4*
FRAME_PERIOD)
o Otherwise frame skip intensity is set to zero
The skip_frame flag is set depending on three variables
o frame_skip_intensity The SCReAM algorithm makes a good distinction between network
congestion control and the media rate control, an RTP queue queues up
RTP packets pending transmission. This is easily extended to many
streams, in which case RTP packets from two or more RTP queues are
scheduled at the rate permitted by the network congestion control.
o since_last_frame_skip, i.e the number of consecutive frames The scheduling can be done by means of a few different scheduling
without frame skipping regimes. For example the method applied in
[I-D.ietf-rmcat-coupled-cc] can be used. The implementation of
SCReAM use something that is referred to as credit based scheduling.
Credit based scheduling is for instance implemented in IEEE 802.17.
The short description is that credit is accumulated by queues as they
wait for service and are spent while the queues are being services.
o consecutive_frame_skips, i.e the number of consecutive frame skips For instance, if one queue is allowed to transmit 1000bytes, then a
credit of 1000bytes is allocated to the other unscheduled queues.
This principle can be extended to weighted scheduling in which case
the credit allocated to unscheduled queues depends on the weight
allocation.
The flag skip_frame is set to 1 if any of the conditions below is A.2. Computation of autocorrelation function
met, otherwise it is set to 0.
o age_vec(n) > 0.2 && consecutive_frame_skips < 5 The autocorrelation function is computed over a vector of values.
o frame_skip_intensity < 0.5 && since_last_frame_skip >= 1.0/ Let x be a vector constituting N values, the autocorrelation function
frame_skip_intensity for a given lag=k for the vector x is given by .
o frame_skip_intensity >= 0.5 && consecutive_frame_skips < n=N-k
(frame_skip_intensity -0.5)*10 R(x,k) = SUM x(n)*x(n+k)
n=1
The arrangement makes sure that no more than 4 frames are skipped in Figure 2: Autocorrelation function
sequence, the rationale is to ensure that the input to the video
encoder does not change to much, something that may give poor
prediction gain.
Authors' Addresses Authors' Addresses
Ingemar Johansson Ingemar Johansson
Ericsson AB Ericsson AB
Laboratoriegraend 11 Laboratoriegraend 11
Luleaa 977 53 Luleaa 977 53
Sweden Sweden
Phone: +46 730783289 Phone: +46 730783289
 End of changes. 177 change blocks. 
980 lines changed or deleted 773 lines changed or added

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