draft-ietf-rmcat-scream-cc-03.txt   draft-ietf-rmcat-scream-cc-04.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: August 11, 2016 February 8, 2016 Expires: December 11, 2016 June 9, 2016
Self-Clocked Rate Adaptation for Multimedia Self-Clocked Rate Adaptation for Multimedia
draft-ietf-rmcat-scream-cc-03 draft-ietf-rmcat-scream-cc-04
Abstract Abstract
This memo describes a rate adaptation algorithm for conversational This memo describes a rate adaptation algorithm for conversational
media services such as video. The solution conforms to the packet media services such as video. The solution conforms to the packet
conservation principle and uses a hybrid loss and delay based conservation principle and uses a hybrid loss and delay based
congestion control algorithm. The algorithm is evaluated over both congestion control algorithm. The algorithm is evaluated over both
simulated Internet bottleneck scenarios as well as in a LTE (Long simulated Internet bottleneck scenarios as well as in a LTE (Long
Term Evolution) system simulator and is shown to achieve both low Term Evolution) system simulator and is shown to achieve both low
latency and high video throughput in these scenarios. latency and high video throughput in these scenarios.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 11, 2016. This Internet-Draft will expire on December 11, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Wireless (LTE) access properties . . . . . . . . . . . . 3 1.1. Wireless (LTE) access properties . . . . . . . . . . . . 3
1.2. Why is it a self-clocked algorithm? . . . . . . . . . . . 3 1.2. Why is it a self-clocked algorithm? . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of SCReAM Algorithm . . . . . . . . . . . . . . . . 4 3. Overview of SCReAM Algorithm . . . . . . . . . . . . . . . . 4
3.1. Network Congestion Control . . . . . . . . . . . . . . . 7 3.1. Network Congestion Control . . . . . . . . . . . . . . . 7
3.2. Sender Transmission Control . . . . . . . . . . . . . . . 7 3.2. Sender Transmission Control . . . . . . . . . . . . . . . 7
3.3. Media Rate Control . . . . . . . . . . . . . . . . . . . 7 3.3. Media Rate Control . . . . . . . . . . . . . . . . . . . 7
4. Detailed Description of SCReAM . . . . . . . . . . . . . . . 8 4. Detailed Description of SCReAM . . . . . . . . . . . . . . . 8
4.1. SCReAM Sender . . . . . . . . . . . . . . . . . . . . . . 8 4.1. SCReAM Sender . . . . . . . . . . . . . . . . . . . . . . 8
4.1.1. Constants and Parameter values . . . . . . . . . . . 9 4.1.1. Constants and Parameter values . . . . . . . . . . . 9
4.1.1.1. Constants . . . . . . . . . . . . . . . . . . . . 9 4.1.1.1. Constants . . . . . . . . . . . . . . . . . . . . 9
4.1.1.2. State variables . . . . . . . . . . . . . . . . . 10 4.1.1.2. State variables . . . . . . . . . . . . . . . . . 10
4.1.2. Network congestion control . . . . . . . . . . . . . 12 4.1.2. Network congestion control . . . . . . . . . . . . . 12
4.1.2.1. Congestion window update . . . . . . . . . . . . 15 4.1.2.1. Congestion window update . . . . . . . . . . . . 15
4.1.2.2. Competing flows compensation . . . . . . . . . . 17 4.1.2.2. Competing flows compensation . . . . . . . . . . 17
4.1.2.3. Lost packets detection . . . . . . . . . . . . . 18 4.1.2.3. Lost packets detection . . . . . . . . . . . . . 18
4.1.2.4. Send window calculation . . . . . . . . . . . . . 18 4.1.2.4. Send window calculation . . . . . . . . . . . . . 19
4.1.2.5. Resuming fast increase . . . . . . . . . . . . . 19 4.1.2.5. Resuming fast increase . . . . . . . . . . . . . 20
4.1.3. Media rate control . . . . . . . . . . . . . . . . . 19 4.1.3. Media rate control . . . . . . . . . . . . . . . . . 20
4.1.3.1. FEC and packet overhead considerations . . . . . 23 4.1.3.1. FEC and packet overhead considerations . . . . . 24
4.2. SCReAM Receiver . . . . . . . . . . . . . . . . . . . . . 23 4.2. SCReAM Receiver . . . . . . . . . . . . . . . . . . . . . 24
5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 23 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 24
6. Implementation status . . . . . . . . . . . . . . . . . . . . 23 6. Implementation status . . . . . . . . . . . . . . . . . . . . 24
6.1. OpenWebRTC . . . . . . . . . . . . . . . . . . . . . . . 24 6.1. OpenWebRTC . . . . . . . . . . . . . . . . . . . . . . . 25
6.2. A C++ Implementation of SCReAM . . . . . . . . . . . . . 25 6.2. A C++ Implementation of SCReAM . . . . . . . . . . . . . 26
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 9. Security Considerations . . . . . . . . . . . . . . . . . . . 26
10. Change history . . . . . . . . . . . . . . . . . . . . . . . 26 10. Change history . . . . . . . . . . . . . . . . . . . . . . . 27
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
11.1. Normative References . . . . . . . . . . . . . . . . . . 26 11.1. Normative References . . . . . . . . . . . . . . . . . . 27
11.2. Informative References . . . . . . . . . . . . . . . . . 27 11.2. Informative References . . . . . . . . . . . . . . . . . 28
Appendix A. Additional information . . . . . . . . . . . . . . . 29 Appendix A. Additional information . . . . . . . . . . . . . . . 30
A.1. Stream prioritization . . . . . . . . . . . . . . . . . . 29 A.1. Stream prioritization . . . . . . . . . . . . . . . . . . 30
A.2. Computation of autocorrelation function . . . . . . . . . 29 A.2. Computation of autocorrelation function . . . . . . . . . 30
A.3. Sender transmission control and packet pacing . . . . . . 30 A.3. Sender transmission control and packet pacing . . . . . . 31
A.4. RTCP feedback considerations . . . . . . . . . . . . . . 30 A.4. RTCP feedback considerations . . . . . . . . . . . . . . 31
A.4.1. Requirements on feedback elements . . . . . . . . . . 30 A.4.1. Requirements on feedback elements . . . . . . . . . . 31
A.4.2. Requirements on feedback intensity . . . . . . . . . 32 A.4.2. Requirements on feedback intensity . . . . . . . . . 33
A.5. Q-bit semantics (source quench) . . . . . . . . . . . . . 33 A.5. Q-bit semantics (source quench) . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
1. Introduction 1. Introduction
Congestion in the Internet is a reality and applications that are Congestion in the Internet occurs when the transmitted bitrate is
deployed in the Internet must have congestion control schemes in higher than the available bandwidth over a given transmission path.
place not only for the robustness of the service that it provides but Applications that are deployed in the Internet must have congestion
also to ensure the function of the currently deployed Internet. As control schemes in place not only for the robustness of the service
the interactive realtime communication imposes a great deal of that it provides but also to ensure the function of the currently
requirements on the transport, a robust, efficient rate adaptation deployed Internet. Interactive realtime communication imposes a lot
for all access types is considered as an important part of of requirements on the transport, therefore a robust, efficient rate
interactive realtime communications as the transmission channel adaptation for all access types is an important part of interactive
bandwidth may vary over time. Wireless access such as LTE, which is realtime communications as the transmission channel bandwidth may
an integral part of the current Internet, increases the importance of vary over time. Wireless access such as LTE, which is an integral
rate adaptation as the channel bandwidth of a default LTE bearer part of the current Internet, increases the importance of 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 (Self-Clocked Rate Adaptation for Multimedia), that is based
techniques similar to what is used in a new delay based rate on the self-clocking principle of TCP and uses techniques similar to
adaptation algorithm, LEDBAT [RFC6817]. what is used in a new delay based rate adaptation algorithm, LEDBAT
[RFC6817].
1.1. Wireless (LTE) access properties 1.1. Wireless (LTE) access properties
[I-D.ietf-rmcat-wireless-tests] describes the complications that can [I-D.ietf-rmcat-wireless-tests] describes the complications that can
be observed in wireless environments. Wireless access such as LTE be observed in wireless environments. Wireless access such as LTE
can typically not guarantee a given bandwidth, this is true can typically not guarantee a given bandwidth, this is true
especially for default bearers. The network throughput may vary especially for default bearers. The network throughput may vary
considerably for instance in cases where the wireless terminal is considerably for instance in cases where the wireless terminal is
moving around. moving around. Even though LTE can support bitrates well above
100Mbps, there are cases when the available bitrate can be much
lower, examples are situations with high network load and poor
coverage.
Unlike wireline bottlenecks with large statistical multiplexing it is Unlike wireline bottlenecks with large statistical multiplexing it is
not possible to try to maintain a given bitrate when congestion is not possible to try to maintain a given bitrate when congestion is
detected with the hope that other flows will yield, this is because detected with the hope that other flows will yield, this is because
there are generally few other flows competing for the same there are generally few other flows competing for the same
bottleneck. Each user gets its own variable throughput bottleneck, bottleneck. Each user gets its own variable throughput bottleneck,
where the throughput depends on factors like channel quality, network where the throughput depends on factors like channel quality, network
load and historical throughput. The bottom line is, if the load and historical throughput. The bottom line is, if the
throughput drops, the sender has no other option than to reduce the throughput drops, the sender has no other option than to reduce the
bitrate. Once the radio scheduler has reduced the resource bitrate. Once the radio scheduler has reduced the resource
skipping to change at page 4, line 40 skipping to change at page 4, line 46
important key-factor behind the protection of networks from important key-factor behind the protection of networks from
congestion [PACKET_CONSERVATION]. congestion [PACKET_CONSERVATION].
In SCReAM, the receiver of the media echoes a list of received RTP In SCReAM, the receiver of the media echoes a list of received RTP
packets and the timestamp of the RTP packet with the highest sequence packets and the timestamp of the RTP packet with the highest sequence
number back to the sender in feedback packets, the sender keeps a number back to the sender in feedback packets, the sender keeps a
list of transmitted packets, their respective sizes and the time they list of transmitted packets, their respective sizes and the time they
were transmitted. This information is used to determine the amount were transmitted. This information is used to determine the amount
of bytes that can be transmitted at any given time instant. A of bytes that can be transmitted at any given time instant. A
congestion window puts an upper limit on how many bytes can be in congestion window puts an upper limit on how many bytes can be in
flight, i.e. transmitted but not yet acknowledged. This realizes the flight, i.e transmitted but not yet acknowledged. All this
packet conservation principle. The congestion window is determined implements a congestion control that follows the packet conservation
in a way similar to LEDBAT [RFC6817]. principle. The fact that SCReAM follows the packet conservation
principle, makes it as safe to deploy as a congestion control
algorithm for the internet as TCP and its most commonly used
congestion control algorithms is. No additional circuit breaker
mechanisms are necessary with SCReAM as the ACK-clocking
automatically stops transmission when the acknowledgements no longer
arrive at the sender.
The congestion window is determined in a way similar to LEDBAT
[RFC6817].
LEDBAT is a congestion control algorithm that uses send and receive LEDBAT is a congestion control algorithm that uses send and receive
timestamps to estimate the queuing delay along the transmission path. timestamps to estimate the queuing delay along the transmission path.
This information is used to adjust the congestion window. The use of This information is used to adjust the congestion window. The use of
LEDBAT ensures that the end-to-end latency is kept low. The basic LEDBAT ensures that the end-to-end latency is kept low. The basic
functionality is quite simple, there are however a few steps to take functionality is quite simple, there are however a few steps to take
to make the concept work with conversational media. In a few words to make the concept work with conversational media. In a few words
they are: they are:
o Congestion window validation techniques. These are similar in o Congestion window validation techniques. These are similar in
action as the method described in [RFC7661]. Congestion window action as the method described in [RFC7661]. Congestion window
validation ensures that the congestion window is limited by the validation ensures that the congestion window is limited by the
amount of actual bytes in flight, this is important especially in amount of actual bytes in flight, this is important especially in
the context of rate limited sources which is the case when video the context of rate limited sources such as video. Lack of
is transmitted. Lack of congestion window validation would lead congestion window validation would lead to a slow reaction to
to a slow reaction to congestion as the congestion window does not congestion as the congestion window does not properly reflect the
properly reflect the congestion state in the network. The allowed congestion state in the network. The allowed idle period in this
idle period in this memo is shorter than in the reference, this to memo is shorter than in [RFC7661], this to avoid excessive delays
avoid excessive delays in the cases where e.g. wireless throughput in the cases where e.g. wireless throughput has decreased during a
has decreased during a period where the output bitrate has been period where the output bitrate from the media coder has been low,
low. Furthermore, this memo allows for more relaxed rules for for instance due to inactivity. Furthermore, this memo allows for
when the congestion window is allowed to grow, this is necessary more relaxed rules for when the congestion window is allowed to
as the variable output bitrate generally means that the congestion grow, this is necessary as the variable output bitrate generally
window is often under-utilized. means that the congestion window is often under-utilized.
o Fast increase for quicker bitrate increase. It makes the media o Fast increase for quicker bitrate increase. It makes the media
bitrate ramp-up within 5 to 10 seconds. The behavior is similar bitrate ramp-up within 5 to 10 seconds. The behavior is similar
to TCP slowstart. The fast increase is exited when congestion is to TCP slowstart. The fast increase is exited when congestion is
detected. The fast increase state can however resume if the detected. The fast increase state can however resume if the
congestion level is low, this to enable a reasonably quick rate congestion level is low, this to enable a reasonably quick rate
increase in case link throughput increases. increase in case link throughput increases.
o A delay trend is computed for earlier detection of incipient o A delay trend is computed for earlier detection of incipient
congestion and as a result it reduces jitter. congestion and as a result it reduces jitter.
skipping to change at page 6, line 44 skipping to change at page 6, line 47
| v | v
+------------+ +------------+
| UDP | | UDP |
| socket | | socket |
+------------+ +------------+
Figure 1: SCReAM sender functional view Figure 1: SCReAM sender functional view
The SCReAM algorithm constitutes mainly three parts: network The SCReAM algorithm constitutes mainly three parts: network
congestion control, sender transmission control and media rate congestion control, sender transmission control and media rate
control. All these three parts reside at the sender side. Figure 2 control. All these three parts reside at the sender side. Figure 1
shows the functional overview of a SCReAM sender. The receiver side shows the functional overview of a SCReAM sender. The receiver side
algorithm is very simple in comparison as it only generates feedback algorithm is very simple in comparison as it only generates feedback
containing acknowledgements to received RTP packets and ECN count. containing acknowledgements of received RTP packets and an ECN count.
3.1. Network Congestion Control 3.1. Network Congestion Control
The network congestion control sets an upper limit on how much data The network congestion control sets an upper limit on how much data
can be in the network (bytes in flight); this limit is called CWND can be in the network (bytes in flight); this limit is called CWND
(congestion window) and is used in the sender transmission control. (congestion window) and is used in the sender transmission control.
The SCReAM congestion control method, uses techniques similar to The SCReAM congestion control method, uses techniques similar to
LEDBAT [RFC6817] to measure the queuing delay, also termed qdelay in LEDBAT [RFC6817] to measure the queuing delay, also termed qdelay in
this memo for brevity. Similar to LEDBAT, it is not necessary to use this memo for brevity. Similar to LEDBAT, it is not necessary to use
skipping to change at page 8, line 34 skipping to change at page 8, line 34
A SCReAM sender implements media rate control and a queue for each A SCReAM sender implements media rate control and a queue for each
media type or source, where RTP packets containing encoded media media type or source, where RTP packets containing encoded media
frames are temporarily stored for transmission. Figure 1 shows the frames are temporarily stored for transmission. Figure 1 shows the
details when a single media source (a.k.a stream) is used. Multiple details when a single media source (a.k.a stream) is used. Multiple
media sources are also supported in the design, in that case the media sources are also supported in the design, in that case the
sender transmission control will include a transmission scheduler. sender transmission control will include a transmission scheduler.
The transmission scheduler can then enforce the priorities for the The transmission scheduler can then enforce the priorities for the
different streams and then act like a coupled congestion controller different streams and then act like a coupled congestion controller
for multiple flows. for multiple flows.
Media frames are encoded and forwarded to the RTP queue (1). The Media frames are encoded and forwarded to the RTP queue (1) in
media rate adaptation adapts to the size of the RTP queue (2) and Figure 1. The media rate adaptation adapts to the size of the RTP
controls the media bitrate (3). The RTP packets are picked from the queue (2) and controls the media bitrate (3). The RTP packets are
RTP queue (for multiple flows from each RTP queue based on some picked from the RTP queue (for multiple flows from each RTP queue
defined priority order or simply in a round robin fashion) (4) by the based on some defined priority order or simply in a round robin
sender transmission controller. The sender transmission controller fashion) (4) by the sender transmission controller. The sender
(in case of multiple flows a transmission scheduler) takes care of transmission controller (in case of multiple flows a transmission
the transmission of RTP packets, to be written to the UDP socket (5). scheduler) takes care of the transmission of RTP packets, to be
In the general case all media must go through the sender transmission written to the UDP socket (5). In the general case all media must go
controller and is allowed to be transmitted if the number of bytes in through the sender transmission controller and is allowed to be
flight is less than the congestion window. RTCP packets are received transmitted if the number of bytes in flight is less than the
(6) and the information about bytes in flight and congestion window congestion window. RTCP packets are received (6) and the information
is exchanged between the network congestion control and the sender about bytes in flight and congestion window is exchanged between the
transmission control (7). network congestion control and the sender transmission control (7).
4.1.1. Constants and Parameter values 4.1.1. Constants and Parameter values
Constants and state variables are listed in this section. Temporary Constants and state variables are listed in this section. Temporary
variables are not listed, instead they are appended with '_t' in the variables are not listed, instead they are appended with '_t' in the
pseudo code to indicate their local scope. pseudo code to indicate their local scope.
4.1.1.1. Constants 4.1.1.1. Constants
The recommended values for the constants are deduced from The recommended values for the constants are deduced from
experimentals. experiments.
QDELAY_TARGET_LO (0.1s) QDELAY_TARGET_LO (0.1s)
Target value for the minimum qdelay. Target value for the minimum qdelay.
QDELAY_TARGET_HI (0.4s) QDELAY_TARGET_HI (0.4s)
Target value for the maximum qdelay. Target value for the maximum qdelay.
QDELAY_WEIGHT (0.1) QDELAY_WEIGHT (0.1)
Averaging factor for qdelay_fraction_avg. Averaging factor for qdelay_fraction_avg.
skipping to change at page 11, line 9 skipping to change at page 11, line 9
min_cwnd (2*MSS) min_cwnd (2*MSS)
Minimum congestion window. Minimum congestion window.
in_fast_increase (true) in_fast_increase (true)
True if in fast increase state. True if in fast increase state.
cwnd (min_cwnd) cwnd (min_cwnd)
Congestion window. Congestion window.
cwnd_last_max (1 byte) cwnd_last_max (1 byte)
Congestion window inflection point, i.e. the last known highest Congestion window inflection point, i.e the last known highest
cwnd. Used to limit cwnd increase speed close to the last known cwnd. Used to limit cwnd increase speed close to the last known
congestion point. congestion point.
bytes_newly_acked (0) bytes_newly_acked (0)
The number of bytes that was acknowledged with the last received The number of bytes that was acknowledged with the last received
acknowledgement i.e. bytes acknowledged since the last CWND update. acknowledgement i.e bytes acknowledged since the last CWND update.
send_wnd (0) send_wnd (0)
Upper limit to how many bytes that can currently be transmitted. Upper limit to how many bytes that can currently be transmitted.
Updated when cwnd is updated and when RTP packet is transmitted. Updated when cwnd is updated and when RTP packet is transmitted.
target_bitrate (0 bps) target_bitrate (0 bps)
Media target bitrate. Media target bitrate.
target_bitrate_last_max (1 bps) target_bitrate_last_max (1 bps)
Media target bitrate inflection point i.e. the last known highest Media target bitrate inflection point i.e the last known highest
target_bitrate. Used to limit bitrate increase speed close to the target_bitrate. Used to limit bitrate increase speed close to the
last known congestion point. last known congestion point.
rate_transmit (0.0 bps) rate_transmit (0.0 bps)
Measured transmit bitrate. Measured transmit bitrate.
rate_ack (0.0 bps) rate_ack (0.0 bps)
Measured throughput based on received acknowledgements. Measured throughput based on received acknowledgements.
rate_media (0.0 bps) rate_media (0.0 bps)
skipping to change at page 12, line 11 skipping to change at page 12, line 11
rtp_size (0 byte) rtp_size (0 byte)
Size of the last transmitted RTP packet. Size of the last transmitted RTP packet.
4.1.2. Network congestion control 4.1.2. Network congestion control
This section explains the network congestion control, it contains two This section explains the network congestion control, it contains two
main functions main functions
o Computation of congestion window at the sender: Gives an upper o Computation of congestion window at the sender: Gives an upper
limit to the number of bytes in flight i.e. how many bytes that limit to the number of bytes in flight i.e how many bytes that
have been transmitted but not yet acknowledged. have been transmitted but not yet acknowledged.
o Calculation of send window at the sender: RTP packets are o Calculation of send window at the sender: RTP packets are
transmitted if allowed by the relation between the number of bytes transmitted if allowed by the relation between the number of bytes
in flight and the congestion window. This is controlled by the in flight and the congestion window. This is controlled by the
send window. send window.
Unlike TCP, SCReAM is not a byte oriented protocol, rather it is an Unlike TCP, SCReAM is not a byte oriented protocol, rather it is an
RTP packet oriented protocol. Thus a list of transmitted RTP packets RTP packet oriented protocol. Thus a list of transmitted RTP packets
and their respective transmission times (wall-clock time) is kept for and their respective transmission times (wall-clock time) is kept for
skipping to change at page 13, line 17 skipping to change at page 13, line 17
o The wall clock timestamp corresponding to the received RTP packet o The wall clock timestamp corresponding to the received RTP packet
with the highest sequence number. with the highest sequence number.
o Accumulated number of ECN-CE marked packets (n_ECN). o Accumulated number of ECN-CE marked packets (n_ECN).
When the sender receives RTCP feedback, the qdelay is calculated as When the sender receives RTCP feedback, the qdelay is calculated as
outlined in [RFC6817]. A qdelay sample is obtained for each received outlined in [RFC6817]. A qdelay sample is obtained for each received
acknowledgement. No smoothing of the qdelay samples occur, however acknowledgement. No smoothing of the qdelay samples occur, however
some smoothing occurs anyway as the computation of the CWND is in some smoothing occurs anyway as the computation of the CWND is in
itself a low pass filter function. A number of variables are updated itself a low pass filter function. A number of variables are updated
as illustrated by the pseudo code below. as illustrated by the pseudo code below, temporary variables are
appended with '_t'. Note that the pseudo code does not show all
details for reasons of readability, the reader is referred to the C++
code in [SCReAM-Cplusplus_Implementation] for the details.
update_variables(qdelay): update_variables(qdelay):
qdelay_fraction_t = qdelay/qdelay_target qdelay_fraction_t = qdelay/qdelay_target
#calculate moving average #calculate moving average
qdelay_fraction_avg = (1-QDELAY_WEIGHT)*qdelay_fraction_avg+ qdelay_fraction_avg = (1-QDELAY_WEIGHT)*qdelay_fraction_avg+
QDELAY_WEIGHT*qdelay_fraction_t QDELAY_WEIGHT*qdelay_fraction_t
update_qdelay_fraction_hist(qdelay_fraction) update_qdelay_fraction_hist(qdelay_fraction_t)
# R is an autocorrelation function of qdelay_fraction_hist # R is an autocorrelation function of qdelay_fraction_hist
# at lag K # at lag K
a = R(qdelay_fraction_hist,1)/R(qdelay_fraction_hist,0) a = R(qdelay_fraction_hist,1)/R(qdelay_fraction_hist,0)
#calculate qdelay trend #calculate qdelay trend
qdelay_trend = min(1.0,max(0.0,a*qdelay_fraction_avg)) qdelay_trend = min(1.0,max(0.0,a*qdelay_fraction_avg))
#calculate a 'peak-hold' qdelay_trend, this gives a memory #calculate a 'peak-hold' qdelay_trend, this gives a memory
# of congestion in the past # of congestion in the past
qdelay_trend_mem = max(0.99*qdelay_trend_mem, qdelay_trend) qdelay_trend_mem = max(0.99*qdelay_trend_mem, qdelay_trend)
The qdelay fraction is sampled every 50ms and the last 20 samples are The qdelay fraction is sampled every 50ms and the last 20 samples are
skipping to change at page 14, line 11 skipping to change at page 14, line 14
function update_qdelay_fraction_hist(..) removes the oldest element function update_qdelay_fraction_hist(..) removes the oldest element
and adds the latest qdelay_fraction element to the and adds the latest qdelay_fraction element to the
qdelay_fraction_hist vector. qdelay_fraction_hist vector.
A loss event is indicated if one or more RTP packets are declared A loss event is indicated if one or more RTP packets are declared
missing. The loss detection is described in Section 4.1.2.3. Once a missing. The loss detection is described in Section 4.1.2.3. Once a
loss event is detected, further detected lost RTP packets are ignored loss event is detected, further detected lost RTP packets are ignored
for a full smoothed round trip time, the intention of this is to for a full smoothed round trip time, the intention of this is to
limit the congestion window decrease to at most once per round trip. limit the congestion window decrease to at most once per round trip.
The congestion window backoff due to loss events is deliberately a The congestion window backoff due to loss events is deliberately a
bit less than is the case with e.g TCP NewReno. The reason is that bit less than is the case with e.g. TCP Reno. The reason is that
TCP is generally used to transmit whole files, which can be TCP is generally used to transmit whole files, which can be
translated to an infinite source bitrate. SCReAM on the other hand translated to an infinite source bitrate. SCReAM on the other hand
has a source which rate is limited to a value close to the available has a source which rate is limited to a value close to the available
transmit rate and often below said value, the effect of this is that transmit rate and often below said value, the effect of this is that
SCReAM has less opportunity to grab free capacity than a TCP based SCReAM has less opportunity to grab free capacity than a TCP based
file transfer. To compensate for this it is necessary to let SCReAM file transfer. To compensate for this it is necessary to let SCReAM
reduce the congestion window slightly less when loss events occur. reduce the congestion window slightly less than what is the case with
TCP when loss events occur.
An ECN event is detected if the n_ECN counter in the feedback report An ECN event is detected if the n_ECN counter in the feedback report
has increased since the previous received feedback. Once an ECN has increased since the previous received feedback. Once an ECN
event is detected, the n_ECN counter is ignored for a full smoothed event is detected, the n_ECN counter is ignored for a full smoothed
round trip time, the intention of this is to limit the congestion round trip time, the intention of this is to limit the congestion
window decrease to at most once per round trip. The congestion window decrease to at most once per round trip. The congestion
window backoff due to an ECN event is deliberately smaller than if a window backoff due to an ECN event is deliberately smaller than if a
loss event occurs. This is inline with the idea outlined in loss event occurs. This is inline with the idea outlined in
[Khademi_alternative_backoff_ECN] to enable ECN marking thresholds [Khademi_alternative_backoff_ECN] to enable ECN marking thresholds
lower than the corresponding packet drop thresholds. lower than the corresponding packet drop thresholds.
The update of the congestion window depends on whether a loss or ECN The update of the congestion window depends on whether loss or ECN-
or neither occurs. The pseudo code below describes actions taken in marking or neither occurs. The pseudo code below describes actions
case of the different events. taken in case of the different events.
on congestion event(qdelay): on congestion event(qdelay):
# Either loss or ECN mark is detected # Either loss or ECN mark is detected
in_fast_increase = false in_fast_increase = false
cwnd_last_max = cwnd
if (is loss) if (is loss)
# loss is detected # loss is detected
cwnd = max(min_cwnd,cwnd*BETA_LOSS) cwnd = max(min_cwnd,cwnd*BETA_LOSS)
else else
# No loss, so it is then an ECN mark # No loss, so it is then an ECN mark
cwnd = max(min_cwnd,cwnd*BETA_ECN) cwnd = max(min_cwnd,cwnd*BETA_ECN)
adjust_qdelay_target(qdelay) #compensating for competing flows adjust_qdelay_target(qdelay) #compensating for competing flows
calculate_send_window(qdelay,qdelay_target) calculate_send_window(qdelay,qdelay_target)
# when no congestion event # when no congestion event
skipping to change at page 16, line 9 skipping to change at page 16, line 9
The congestion window update is based on qdelay, except for the The congestion window update is based on qdelay, except for the
occurrence of loss events (one or more lost RTP packets in one RTT), occurrence of loss events (one or more lost RTP packets in one RTT),
or ECN events, which was described earlier. or ECN events, which was described earlier.
Pseudo code for the update of the congestion window is found below. Pseudo code for the update of the congestion window is found below.
update_cwnd(bytes_newly_acked): update_cwnd(bytes_newly_acked):
# additional scaling factor to slow down closer to target # additional scaling factor to slow down closer to target
# The min scale factor is 0.2 to avoid that the congestion window # The min scale factor is 0.2 to avoid that the congestion window
# growth is stalled when cwnd is close to cwnd_last_max # growth is stalled when cwnd is close to cwnd_last_max
scale_t = max(0.2,min(1.0,(4*(cwnd-cwnd_last_max)/cwnd_i)^2)) scale_t = max(0.2,min(1.0,(4*(cwnd-cwnd_last_max)/cwnd_last_max)^2))
# in fast increase ? # in fast increase ?
if (in_fast_increase) if (in_fast_increase)
if (qdelay_trend >= 0.2) if (qdelay_trend >= 0.2)
# incipient congestion detected, exit fast increase # incipient congestion detected, exit fast increase
in_fast_increase = false in_fast_increase = false
cwnd_last_max = cwnd
else else
# no congestion yet, increase cwnd # no congestion yet, increase cwnd
cwnd = cwnd+bytes_newly_acked*scale_t cwnd = cwnd+bytes_newly_acked*scale_t
return return
# not in fast increase phase # not in fast increase phase
# off_target calculated as with LEDBAT # off_target calculated as with LEDBAT
off_target_t = (qdelay_target - qdelay) / qdelay_target off_target_t = (qdelay_target - qdelay) / qdelay_target
gain_t = GAIN gain_t = GAIN
# adapt only increase based on scale # adjust increase based on scale and qdelay_trend
if (off_target_t > 0) if (off_target_t > 0)
gain_t *= max(0.0, (1 - qdelay_trend/ 0.2)) * scale_t gain_t *= max(0.0, (1 - qdelay_trend/ 0.2)) * scale_t
# increase/decrease the congestion window # increase/decrease the congestion window
# off_target can be positive or negative # off_target can be positive or negative
cwnd += gain_t * off_target_t * bytes_newly_acked * MSS / cwnd cwnd += gain_t * off_target_t * bytes_newly_acked * MSS / cwnd
# Limit cwnd to the maximum number of bytes in flight # Limit cwnd to the maximum number of bytes in flight
cwnd = min(cwnd, max_bytes_in_flight*MAX_BYTES_IN_FLIGHT_HEAD_ROOM) cwnd = min(cwnd, max_bytes_in_flight*MAX_BYTES_IN_FLIGHT_HEAD_ROOM)
cwnd = max(cwnd, MIN_CWND) cwnd = max(cwnd, MIN_CWND)
CWND is updated differently depending on whether the congestion CWND is updated differently depending on whether the congestion
control is in fast increase state or not, as indicated by the control is in fast increase state or not, as controlled by the
variable in_fast_increase. variable in_fast_increase.
In fast increase state the congestion window is increased with the When in fast increase state, the congestion window is increased with
number of newly acknowledged bytes scaled by a scale factor that the number of newly acknowledged bytes scaled by a scale factor that
depends on the relation between CWND and the last known maximum value depends on the relation between CWND and the last known maximum value
of CWND (cwnd_last_max). of CWND (cwnd_last_max).
The congestion window growth when in_fast_increase is false is The congestion window growth when in_fast_increase is false is
dictated by the relation between qdelay and qdelay_target, also here dictated by the relation between qdelay and qdelay_target, also here
a scale factor is applied to limit the congestion window growth when a scale factor is applied to limit the congestion window growth when
cwnd gets close to cwnd_last_max. The scale factor makes the cwnd gets close to cwnd_last_max, cwnd_last_max is updated when
congestion window grow in a similar way as is the case with the Cubic congestion is detected. The scale factor makes the congestion window
congestion control algorithm i.e. a slow increase around the last grow in a similar way as is the case with the Cubic congestion
known maximum value. control algorithm i.e a slow increase around the last known maximum
value.
SCReAM calculates the GAIN in a similar way to what is specified in SCReAM calculates the GAIN in a similar way to what is specified in
[RFC6817]. There are however a few differences. [RFC6817]. There are however a few differences.
o [RFC6817] specifies a constant GAIN, this specification however o [RFC6817] specifies a constant GAIN, this specification however
limits the gain when CWND is increased dependent on near limits the gain when CWND is increased dependent on near
congestion state and the relation to the last known max CWND congestion state and the relation to the last known max CWND
value. value.
o [RFC6817] specifies that the CWND increase is limited by an o [RFC6817] specifies that the CWND increase is limited by an
skipping to change at page 17, line 40 skipping to change at page 18, line 11
congested bottlenecks with other flows that use a more aggressive congested bottlenecks with other flows that use a more aggressive
congestion control algorithm. SCReAM takes care of such situations congestion control algorithm. SCReAM takes care of such situations
by adjusting the qdelay_target. by adjusting the qdelay_target.
adjust_qdelay_target(qdelay) adjust_qdelay_target(qdelay)
qdelay_norm_t = qdelay / QDELAY_TARGET_LOW qdelay_norm_t = qdelay / QDELAY_TARGET_LOW
update_qdelay_norm_history(qdelay_norm_t) update_qdelay_norm_history(qdelay_norm_t)
# Compute variance # Compute variance
qdelay_norm_var_t = VARIANCE(qdelay_norm_history(100)) qdelay_norm_var_t = VARIANCE(qdelay_norm_history(100))
# Compensation for competing traffic # Compensation for competing traffic
if (qdelay_norm_var_t < 0.16) # Compute average
# Compute average qdelay_norm_avg_t = AVERAGE(qdelay_norm_history(50))
qdelay_norm_avg_t = AVERAGE(qdelay_norm_history(20)) # Compute upper limit to target delay
# Update target qdelay oh_t = qdelay_norm_avg_t +
qdelay_target = qdelay_norm_avg_t*QDELAY_TARGET_LO*1.1 min(qdelay_norm_avg_t/2,sqrt(qdelay_norm_var_t))*2.0
qdelay_target = min(QDELAY_TARGET_HI, qdelay_target) oh_t *= QDELAY_TARGET_LO
qdelay_target = max(QDELAY_TARGET_LO, qdelay_target) if (qdelay_norm_var_t < 0.2)
# Reasonably safe to set target qdelay
qdelay_target = oh_t
else
# Check if target delay can be reduced, this helps to avoid
# that the target delay is locked to high values for ever
if (oh_t < QDELAY_TARGET_LO)
# Decrease target delay quickly as measured queueing
# delay is lower than target
qdelay_target = max(qdelay_target*0.5,oh_t)
else
# Decrease target delay slowly
qdelay_target *= 0.9
The qdelay_target is adjusted according to the qdelay_norm_avg_t # Apply limits
whenever qdelay_norm_var_t is below a given value. The condition to qdelay_target = min(QDELAY_TARGET_HI, qdelay_target)
update qdelay_target is fulfilled if qdelay_norm_var_t < 0.16. qdelay_target = max(QDELAY_TARGET_LO, qdelay_target)
The qdelay_target is adjusted differently, depending on if
qdelay_norm_var_t is above or below a given value.
A low qdelay_norm_avg_t value indicates that the qdelay does not A low qdelay_norm_avg_t value indicates that the qdelay does not
change rapidly. It is desired avoid the case that the qdelay target change rapidly. It is desired avoid the case that the qdelay target
is increased due to self-congestion, indicated by a changing qdelay is increased due to self-congestion, indicated by a changing qdelay
and consequently an increased qdelay_norm_var_t. Still it should be and consequently an increased qdelay_norm_var_t. Still it should be
possible to increase the qdelay target if the qdelay continues to be possible to increase the qdelay target if the qdelay continues to be
high. This is a simple function with a certain risk of both false high. This is a simple function with a certain risk of both false
positives and negatives but it manages competing FTP flows reasonably positives and negatives but it manages competing FTP flows reasonably
well at the same time as it has proven to avoid accidental increased well at the same time as it has proven to avoid accidental increased
qdelay target in simulated LTE test cases. qdelay target in simulated LTE test cases.
4.1.2.3. Lost packets detection 4.1.2.3. Lost packets detection
Lost packets dectection is based on the received sequence number Lost packets detection is based on the received sequence number list.
list. A reordering window should be applied to avoid that packet A reordering window should be applied to avoid that packet reordering
reordering triggers loss events. triggers loss events.
The reordering window is specified as a time unit, similar to the The reordering window is specified as a time unit, similar to the
ideas behind RACK (Recent ACKnowledgement) [RACK]. The computation ideas behind RACK (Recent ACKnowledgement) [RACK]. The computation
of the reordering window is made possible by means of a lost flag in of the reordering window is made possible by means of a lost flag in
the list of transmitted RTP packets. This flag is set if the the list of transmitted RTP packets. This flag is set if the
received sequence number list indicates that the given RTP packet is received sequence number list indicates that the given RTP packet is
missing. If a later feedback indicates that a previously lost marked missing. If a later feedback indicates that a previously lost marked
packet was indeed received, then the reordering window is updated to packet was indeed received, then the reordering window is updated to
reflect the reordering delay. The reordering window is given by the reflect the reordering delay. The reordering window is given by the
difference in time between the event that the packet was marked as difference in time between the event that the packet was marked as
lost and the event that it was indicated as successfully received. lost and the event that it was indicated as successfully received.
Loss is detected if a given RTP packet is not acknowledged within a Loss is detected if a given RTP packet is not acknowledged within a
time window (indicated by the reordering window) after an RTP packet time window (indicated by the reordering window) after an RTP packet
with higher sequence number was ackelowledged. with higher sequence number was acknowledged.
4.1.2.4. Send window calculation 4.1.2.4. Send window calculation
The basic design principle behind packet transmission in SCReAM is to The basic design principle behind packet transmission in SCReAM is to
allow transmission only if the number of bytes in flight is less than allow transmission only if the number of bytes in flight is less than
the congestion window. There are however two reasons why this strict the congestion window. There are however two reasons why this strict
rule will not work optimally: rule will not work optimally:
o Bitrate variations: The media frame size is always varying to a o Bitrate variations: The media frame size is always varying to a
larger or smaller extent. A strict rule as the one given above larger or smaller extent. A strict rule as the one given above
skipping to change at page 19, line 8 skipping to change at page 19, line 42
prevent bitrate increase. prevent bitrate increase.
o Reverse (feedback) path congestion: Especially in transport over o Reverse (feedback) path congestion: Especially in transport over
buffer-bloated networks, the one way delay in the reverse buffer-bloated networks, the one way delay in the reverse
direction may jump due to congestion. The effect of this is that direction may jump due to congestion. The effect of this is that
the acknowledgements are delayed with the result that the self- the acknowledgements are delayed with the result that the self-
clocking is temporarily halted, even though the forward path is clocking is temporarily halted, even though the forward path is
not congested. not congested.
The send window is adjusted depending on qdelay and its relation to The send window is adjusted depending on qdelay and its relation to
the qdelay target and the relation between the congetsion window and the qdelay target and the relation between the congestion window and
the number of bytes in flight. A strict rule is applied when qdelay the number of bytes in flight. A strict rule is applied when qdelay
is higher than qdelay_target, to avoid further queue buildup in the is higher than qdelay_target, to avoid further queue buildup in the
network. For cases when qdelay is lower than the qdelay_target, a network. For cases when qdelay is lower than the qdelay_target, a
more relaxed rule is applied. This allows the bitrate to increase more relaxed rule is applied. This allows the bitrate to increase
fast when no congestion is detected while still being able to give a fast when no congestion is detected while still being able to give a
stable behavior in congested situations. stable behavior in congested situations.
The send window is given by the relation between the adjusted The send window is given by the relation between the adjusted
congestion window and the amount of bytes in flight according to the congestion window and the amount of bytes in flight according to the
pseudo code below. pseudo code below.
skipping to change at page 19, line 48 skipping to change at page 20, line 33
4.1.3. Media rate control 4.1.3. Media rate control
The media rate control algorithm is executed at regular intervals The media rate control algorithm is executed at regular intervals
RATE_ADJUSTMENT_INTERVAL, with the exception of a prompt reaction to RATE_ADJUSTMENT_INTERVAL, with the exception of a prompt reaction to
loss events. The media rate control operates based on the size of loss events. The media rate control operates based on the size of
the RTP packet send queue and observed loss events. In addition, the RTP packet send queue and observed loss events. In addition,
qdelay_trend is also considered in the media rate control, this to qdelay_trend is also considered in the media rate control, this to
reduce the amount of induced network jitter. reduce the amount of induced network jitter.
The role of the media rate control is to strike a reasonable balance The role of the media rate control is to strike a reasonable balance
between a low amount of queuing in the RTP queue and a sufficient between a low amount of queuing in the RTP queue(s) and a sufficient
amount of data to send in order to keep the data path busy. A too amount of data to send in order to keep the data path busy. A too
cautious setting leads to possible under-utilization of network cautious setting leads to possible under-utilization of network
capacity and that the flow is starved out by other, more capacity and that the flow is starved out by other, more
opportunistic traffic, on the other hand a too aggressive setting opportunistic traffic, on the other hand a too aggressive setting
leads to extra jitter. leads to extra jitter.
A variable target_bitrate is adjusted depending on the congestion The target_bitrate is adjusted depending on the congestion state.
state. The target bitrate can vary between a minimum value The target bitrate can vary between a minimum value
(TARGET_BITRATE_MIN) and a maximum value (TARGET_BITRATE_MAX). The (TARGET_BITRATE_MIN) and a maximum value (TARGET_BITRATE_MAX).
target_bitrate_min should be chosen to a low enough value to avoid TARGET_BITRATE_MIN should be chosen to a low enough value to avoid
that RTP packets are queued up when the network throughput becomes that RTP packets are queued up when the network throughput becomes
low. The sender should be equipped with a mechanism that discards low. The sender should also be equipped with a mechanism that
RTP packets in cases the network throughput becomes very low and RTP discards RTP packets in cases the network throughput becomes very low
packets are excessively delayed. and RTP packets are excessively delayed.
For the overall bitrate adjustment, two network throughput estimates For the overall bitrate adjustment, two network throughput estimates
are computed : are computed :
o rate_transmit: The measured transmit bitrate. o rate_transmit: The measured transmit bitrate.
o rate_ack: The ACKed bitrate, i.e. the volume of ACKed bits per o rate_ack: The ACKed bitrate, i.e the volume of ACKed bits per time
time unit. unit.
Both estimates are updated every 200ms. Both estimates are updated every 200ms.
The current throughput, current_rate, is computed as the maximum The current throughput, current_rate, is computed as the maximum
value of rate_transmit and rate_ack. The rationale behind the use of value of rate_transmit and rate_ack. The rationale behind the use of
rate_ack in addition to rate_transmit is that rate_transmit is rate_ack in addition to rate_transmit is that rate_transmit is
affected also by the amount of data that is available to transmit, affected also by the amount of data that is available to transmit,
thus a lack of data to transmit can be seen as reduced throughput thus a lack of data to transmit can be seen as reduced throughput
that may itself cause an unnecessary rate reduction. To overcome that may itself cause an unnecessary rate reduction. To overcome
this shortcoming; rate_ack is used as well. This gives a more stable this shortcoming; rate_ack is used as well. This gives a more stable
throughput estimate. throughput estimate.
The rate change behavior depends on whether a loss event has occurred The rate change behavior depends on whether a loss event has occurred
and if the congestion control is in fast increase or not. and if the congestion control is in fast increase or not.
# The target_bitrate is updated at a regular interval according # The target_bitrate is updated at a regular interval according
# to RATE_ADJUST_INTERVAL # to RATE_ADJUST_INTERVAL
on loss: on loss:
target_bitrate_last_max = target_bitrate target_bitrate = max(BETA_R* target_bitrate, TARGET_BITRATE_MIN)
target_bitrate = max(BETA_R* target_bitrate, TARGET_BITRATE_MIN) exit
exit
if (in_fast_increase = true) ramp_up_speed_t = min(RAMP_UP_SPEED, target_bitrate)
scale_t = (target_bitrate - target_bitrate_last_max)/ if (in_fast_increase = true)
target_bitrate_last_max scale_t = (target_bitrate - target_bitrate_last_max)/
increment_t = RAMP_UP_SPEED*RATE_ADJUST_INTERVAL* target_bitrate_last_max
(1.0-min(1.0, qdelay_trend/0.2)) increment_t = ramp_up_speed_t*RATE_ADJUST_INTERVAL*
# Value 0.2 as the bitrate should be allowed to increase (1.0-min(1.0, qdelay_trend/0.2))
# at least slowly --> avoid locking the rate to # Value 0.2 as the bitrate should be allowed to increase
# target_bitrate_last_max # at least slowly --> avoid locking the rate to
increment_t *= max(0.2, min(1.0, (scale_t*4)^2)) # target_bitrate_last_max
target_bitrate += increment_t increment_t *= max(0.2, min(1.0, (scale_t*4)^2))
target_bitrate *= (1.0- PRE_CONGESTION_GUARD*qdelay_trend) target_bitrate += increment_t
else target_bitrate *= (1.0- PRE_CONGESTION_GUARD*qdelay_trend)
current_rate_t = max(rate_transmit, rate_ack) else
pre_congestion = min(1.0, max(0.0, qdelay_fraction_avg-0.3)/0.7) current_rate_t = max(rate_transmit, rate_ack)
pre_congestion += qdelay_trend pre_congestion_t = min(1.0, max(0.0, qdelay_fraction_avg-0.3)/0.7)
target_bitrate=current_rate_t*(1.0-PRE_CONGESTION_GUARD* pre_congestion_t += qdelay_trend
pre_congestion)-TX_QUEUE_SIZE_FACTOR *rtp_queue_size target_bitrate = current_rate_t*(1.0-PRE_CONGESTION_GUARD*
end pre_congestion_t)-TX_QUEUE_SIZE_FACTOR *rtp_queue_size
end
rate_media_limit = max(br, max(rate_media,rtp_rate_median)) rate_media_limit_t = max(current_rate_t, max(rate_media,rtp_rate_median))
rate_media_limit *= (2.0-1.0*qdelay_trend_mem) rate_media_limit_t *= (2.0-1.0*qdelay_trend_mem)
target_bitrate = min(target_bitrate, rate_media_limit) target_bitrate = min(target_bitrate, rate_media_limit_t)
target_bitrate = min(TARGET_BITRATE_MAX, target_bitrate = min(TARGET_BITRATE_MAX,
max(TARGET_BITRATE_MIN,target_bitrate)) max(TARGET_BITRATE_MIN,target_bitrate))
In case of a loss event the target_bitrate is updated and the rate In case of a loss event the target_bitrate is updated and the rate
change procedure is exited. Otherwise the rate change procedure change procedure is exited. Otherwise the rate change procedure
continues. The rationale behind the rate reduction due to loss is continues. The rationale behind the rate reduction due to loss is
that a congestion window reduction will take effect, a rate reduction that a congestion window reduction will take effect, a rate reduction
pro actively avoids that RTP packets are queued up when the transmit pro actively avoids that RTP packets are queued up when the transmit
rate decreases due to the reduced congestion window. An ECN event rate decreases due to the reduced congestion window. An ECN event
does not cause any action, the reason to this is that the congestion 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 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 is thus that the expected additional RTP queuing delay due to ECN
skipping to change at page 22, line 12 skipping to change at page 23, line 12
The rate update frequency is limited by RATE_ADJUST_INTERVAL, unless The rate update frequency is limited by RATE_ADJUST_INTERVAL, unless
a loss event occurs. The value is based on experimentation with real a loss event occurs. The value is based on experimentation with real
life limitations in video coders taken into account. A too short life limitations in video coders taken into account. A too short
interval has shown to make the video coder internal rate control loop interval has shown to make the video coder internal rate control loop
more unstable, a too long interval makes the overall congestion more unstable, a too long interval makes the overall congestion
control sluggish. control sluggish.
When in fast increase state (in_fast_increase=true), the bitrate When in fast increase state (in_fast_increase=true), the bitrate
increase is given by the desired ramp-up speed (RAMP_UP_SPEED) and is increase is given by the desired ramp-up speed (RAMP_UP_SPEED) and is
limited by the relation between the current bitrate and the last limited by the relation between the current bitrate and the last
known max bitrate. Furthermore an increased qdelay trend limits the known max bitrate. The ramp-up speed is limited when the target
bitrate increase, an allowed increment is computed based on the bitrate is low to avoid rate oscillation at low bottleneck bitrates.
congestion level (given by qdelay_trend) and the relation to Furthermore an increased qdelay trend limits the bitrate increase, an
target_bitrate_last_max. The target_bitrate is reduced if congestion allowed increment is computed based on the congestion level (given by
is detected. The setting of RAMP_UP_SPEED depends on preferences, a qdelay_trend) and the relation to target_bitrate_last_max. The
high setting such as 1000kbps/s makes it possible to quickly get high target_bitrate is reduced if congestion is detected. The setting of
quality media, this is however at the expense of a higher risk of RAMP_UP_SPEED depends on preferences, a high setting such as
jitter, which can manifest itself as e.g. choppy video rendering. 1000kbps/s makes it possible to quickly get high quality media, this
is however at the expense of a higher risk of jitter, which can
manifest itself as e.g. choppy video rendering.
When in_fast_increase is false, the bitrate increase is given by the When in_fast_increase is false, the bitrate increase is given by the
current bitrate and is also controlled by the estimated RTP queue and current bitrate and is also controlled by the estimated RTP queue and
the qdelay trend, thus it is sufficient that an increased congestion the qdelay trend, thus it is sufficient that an increased congestion
level is sensed by the network congestion control to limit the level is sensed by the network congestion control to limit the
bitrate. The target_bitrate_last_max is updated to the current value bitrate. The target_bitrate_last_max is updated when congestion is
of target_bitrate if in_fast_increase was true the last time the detected. Additionally, a pre-congestion indicator is computed and
bitrate was updated. Additionally, a pre-congestion indicator is the rate is adjusted accordingly.
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, rate_media_limit. A multiplier is applied to output bitrates, rate_media_limit. A multiplier is applied to
rate_media_limit, depending on congestion history. The rate_media_limit, depending on congestion history. The
target_bitrate is then limited by this rate_media_limit. target_bitrate is then limited by this rate_media_limit.
Finally the target_bitrate is enforced to be within the defined min Finally the target_bitrate is enforced to be within the defined min
and max values. and max values.
The aware reader may notice the dependency on the qdelay in the The aware reader may notice the dependency on the qdelay in the
computation of the target bitrate, this manifests itself in the use computation of the target bitrate, this manifests itself in the use
of the qdelay_trend and qdelay_fraction_avg. As these parameters are of the qdelay_trend and qdelay_fraction_avg. As these parameters are
used also in the network congestion control one may suspect that some used also in the network congestion control one may suspect some odd
odd interaction between the media rate control and the network interaction between the media rate control and the network congestion
congestion control, this is in fact the case if the parameter control, this is in fact the case if the parameter
PRE_CONGESTION_GUARD is set to a high value. The use of qdelay_trend PRE_CONGESTION_GUARD is set to a high value. The use of qdelay_trend
and qdelay_fraction_avg in the media rate control is solely to reduce and qdelay_fraction_avg in the media rate control is solely to reduce
jitter, the dependency can be removed by setting jitter, the dependency can be removed by setting
PRE_CONGESTION_GUARD=0, the effect is a somewhat faster rate increase PRE_CONGESTION_GUARD=0, the effect is a somewhat faster rate increase
at the expense of more jitter. at the expense of more jitter.
4.1.3.1. FEC and packet overhead considerations 4.1.3.1. FEC and packet overhead considerations
The target bitrate given by SCReAM depicts the bitrate including RTP The target bitrate given by SCReAM depicts the bitrate including RTP
and FEC overhead. Therefore it is necessary that the media encoder and FEC overhead. Therefore it is necessary that the media encoder
takes this overhead into account when the media bitrate is set. takes this overhead into account when the media bitrate is set. This
means that the media coder bitrate should be computed as
media_rate = target_bitrate - rtp_plus_fec_overhead_bitrate
It is not strictly necessary to make a 100% perfect compensation for It is not strictly necessary to make a 100% perfect compensation for
the overhead as the SCReAM algorithm will inherently compensate the overhead as the SCReAM algorithm will inherently compensate
moderate errors. Under-compensation for the overhead has the effect moderate errors. Under-compensation for the overhead has the effect
that the jitter will increase somewhat while overcompensation will that the jitter will increase somewhat while overcompensation will
have the effect that the bottleneck link becomes under-utilized. have the effect that the bottleneck link becomes under-utilized.
4.2. SCReAM Receiver 4.2. SCReAM Receiver
The simple task of the SCReAM receiver is to feedback The simple task of the SCReAM receiver is to feedback
acknowledgements of received packets and total ECN count to the acknowledgements of received packets and total ECN count to the
SCReAM sender, in addition, the reveive time of the RTP packet with SCReAM sender, in addition, the receive time of the RTP packet with
the highest sequence number is echoed back. Upon reception of each the highest sequence number is echoed back. Upon reception of each
RTP packet the receiver will simply maintain enough information to RTP packet the receiver will simply maintain enough information to
send the aforementioned values to the SCReAM sender via RTCP send the aforementioned values to the SCReAM sender via RTCP
transport layer feedback message. The frequency of the feedback transport layer feedback message. The frequency of the feedback
message depends on the available RTCP bandwidth. More details of the message depends on the available RTCP bandwidth. More details of the
feedback and the frequency is found in Appendix A.4. feedback and the frequency is found in Appendix A.4.
5. Discussion 5. Discussion
This section covers a few discussion points This section covers a few discussion points
skipping to change at page 25, line 33 skipping to change at page 26, line 35
o Contact : ingemar.s.johansson@ericsson.com o Contact : ingemar.s.johansson@ericsson.com
7. Acknowledgements 7. Acknowledgements
We would like to thank the following persons for their comments, We would like to thank the following persons for their comments,
questions and support during the work that led to this memo: Markus questions and support during the work that led to this memo: Markus
Andersson, Bo Burman, Tomas Frankkila, Frederic Gabin, Laurits Hamm, Andersson, Bo Burman, Tomas Frankkila, Frederic Gabin, Laurits Hamm,
Hans Hannu, Nikolas Hermanns, Stefan Haakansson, Erlendur Karlsson, Hans Hannu, Nikolas Hermanns, Stefan Haakansson, Erlendur Karlsson,
Daniel Lindstroem, Mats Nordberg, Jonathan Samuelsson, Rickard Daniel Lindstroem, Mats Nordberg, Jonathan Samuelsson, Rickard
Sjoeberg, Robert Swain, Magnus Westerlund, Stefan Aalund. Many Sjoeberg, Robert Swain, Magnus Westerlund, Stefan Aalund. Many
additional thanks to chairs Karen and Mirja for patiently reading, additional thanks to RMCAT chairs Karen and Mirja for patiently
suggesting improvements and also for asking all the difficult but reading, suggesting improvements and also for asking all the
necessary questions. Thanks to Stefan Holmer and Xiaoqing Zhu for difficult but necessary questions. Thanks to Stefan Holmer and
the review. Xiaoqing Zhu for the review.
8. IANA Considerations 8. IANA Considerations
A new RFC4585 transport layer feedback message needs to be A new RFC4585 transport layer feedback message needs to be
standardized. standardized.
9. Security Considerations 9. Security Considerations
The feedback can be vulnerable to attacks similar to those that can The feedback can be vulnerable to attacks similar to those that can
affect TCP. It is therefore recommended that the RTCP feedback is at affect TCP. It is therefore recommended that the RTCP feedback is at
least integrity protected. Furthermore, as SCReAM is self-clocked, a least integrity protected. Furthermore, as SCReAM is self-clocked, a
malicious middlebox can drop RTCP feedback packets and thus cause the malicious middlebox can drop RTCP feedback packets and thus cause the
self-clocking in SCReAM to stall. self-clocking in SCReAM to stall.
10. Change history 10. Change history
A list of changes: A list of changes:
o WG-03 to WG-04: Editorial fixes, ready for WGLC?
o WG-02 to WG-03: Review comments from Stefan Holmer and Xiaoqing o WG-02 to WG-03: Review comments from Stefan Holmer and Xiaoqing
Zhu addressed, owd changed to qdelay for clarity. Added appendix Zhu addressed, owd changed to qdelay for clarity. Added appendix
section with RTCP feedback requirements, including a suggested section with RTCP feedback requirements, including a suggested
basic feedback format based Loss RLE report block and the Packet basic feedback format based Loss RLE report block and the Packet
Receipt Times blocks in [RFC3611]. Loss detection added as a Receipt Times blocks in [RFC3611]. Loss detection added as a
section. Transmission scheduling and packet pacing explained in section. Transmission scheduling and packet pacing explained in
appendix. Source quench semantics added to appendix. appendix. Source quench semantics added to appendix.
o WG-01 to WG-02: Complete restructuring of the document. Moved o WG-01 to WG-02: Complete restructuring of the document. Moved
feedback message to a separate draft. feedback message to a separate draft.
skipping to change at page 27, line 37 skipping to change at page 28, line 42
[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] [I-D.ietf-rmcat-cc-codec-interactions]
Zanaty, M., Singh, V., Nandakumar, S., and Z. Sarker, Zanaty, M., Singh, V., Nandakumar, S., and Z. Sarker,
"Congestion Control and Codec interactions in RTP "Congestion Control and Codec interactions in RTP
Applications", draft-ietf-rmcat-cc-codec-interactions-01 Applications", draft-ietf-rmcat-cc-codec-interactions-02
(work in progress), October 2015. (work in progress), March 2016.
[I-D.ietf-rmcat-coupled-cc] [I-D.ietf-rmcat-coupled-cc]
Islam, S., Welzl, M., and S. Gjessing, "Coupled congestion Islam, S., Welzl, M., and S. Gjessing, "Coupled congestion
control for RTP media", draft-ietf-rmcat-coupled-cc-00 control for RTP media", draft-ietf-rmcat-coupled-cc-02
(work in progress), September 2015. (work in progress), April 2016.
[I-D.ietf-rmcat-scream-cc] [I-D.ietf-rmcat-scream-cc]
Johansson, I. and Z. Sarker, "Self-Clocked Rate Adaptation Johansson, I. and Z. Sarker, "Self-Clocked Rate Adaptation
for Multimedia", draft-ietf-rmcat-scream-cc-02 (work in for Multimedia", draft-ietf-rmcat-scream-cc-03 (work in
progress), October 2015. progress), February 2016.
[I-D.ietf-rmcat-wireless-tests] [I-D.ietf-rmcat-wireless-tests]
Sarker, Z., Johansson, I., Zhu, X., Fu, J., Tan, W., and Sarker, Z., Johansson, I., Zhu, X., Fu, J., Tan, W., and
M. Ramalho, "Evaluation Test Cases for Interactive Real- M. Ramalho, "Evaluation Test Cases for Interactive Real-
Time Media over Wireless Networks", draft-ietf-rmcat- Time Media over Wireless Networks", draft-ietf-rmcat-
wireless-tests-01 (work in progress), November 2015. wireless-tests-02 (work in progress), May 2016.
[Khademi_alternative_backoff_ECN] [Khademi_alternative_backoff_ECN]
"TCP Alternative Backoff with ECN (ABE)", "TCP Alternative Backoff with ECN (ABE)",
<https://tools.ietf.org/html/draft-khademi- <https://tools.ietf.org/html/draft-khademi-
alternativebackoff-ecn-00>. alternativebackoff-ecn-00>.
[OpenWebRTC] [OpenWebRTC]
"Open WebRTC project.", <http://www.openwebrtc.io/>. "Open WebRTC project.", <http://www.openwebrtc.io/>.
[PACKET_CONSERVATION] [PACKET_CONSERVATION]
skipping to change at page 30, line 13 skipping to change at page 31, line 20
n=1 n=1
A.3. Sender transmission control and packet pacing A.3. Sender transmission control and packet pacing
RTP packet transmission is allowed whenever the size of the next RTP RTP packet transmission is allowed whenever the size of the next RTP
packet in the sender queue is less than or equal to send window. As packet in the sender queue is less than or equal to send window. As
explained in Section 4.1.2.4 the send window is updated whenever an explained in Section 4.1.2.4 the send window is updated whenever an
RTP packet is transmitted or RTCP feedback is received, the packet RTP packet is transmitted or RTCP feedback is received, the packet
transmission rate is however restricted by means of packet pacing. transmission rate is however restricted by means of packet pacing.
Packet pacing is used in order to mitigate coalescing i.e. that Packet pacing is used in order to mitigate coalescing i.e that
packets are transmitted in bursts, with the increased risk of more packets are transmitted in bursts, with the increased risk of more
jitter and potentially increased packet loss. jitter and potentially increased packet loss. The time interval
between consecutive packet transmissions enforced to equal or higher
Packet pacing is enforced when qdelay_fraction_avg is greater than than t_pace where t_pace is given by the equations below :
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 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 rtp_size is the size of the last transmitted RTP packet, s_rtt is the
smoothed round trip time.
A.4. RTCP feedback considerations A.4. RTCP feedback considerations
This section describes the requrements on the RTCP feedback to make This section describes the requirements on the RTCP feedback to make
SCReAM function well. Parts of this section may be moved to a SCReAM function well. Parts of this section may be moved to a
separate draft. First is described the requrements on the feedback separate draft. First is described the requirements on the feedback
elements, second is decribed the requirements on the feedback elements, second is described the requirements on the feedback
intensity to keep SCReAM self-clocking and rate control loops intensity to keep SCReAM self-clocking and rate control loops
function properly. function properly.
A.4.1. Requirements on feedback elements A.4.1. Requirements on feedback elements
SCReAM requires the following elements for its basic functionality, SCReAM requires the following elements for its basic functionality,
i.e only including features that are sctrictly necessary in order to i.e only including features that are strictly necessary in order to
make SCReAM function. ECN is not included as basic functionality as make SCReAM function. ECN is not included as basic functionality as
it regarded as an additional feature that is not strickly necessary it regarded as an additional feature that is not strictly necessary
even though it can improve quality of experience quite considerably. even though it can improve quality of experience quite considerably.
o A list of received RTP packets. This list should be suffciently o A list of received RTP packets. This list should be sufficiently
long to cover all received RTP packets. This list may be realized long to cover all received RTP packets. This list can be realized
with the Loss RLE report block in [RFC3611]. with the Loss RLE report block in [RFC3611].
o A wall clock timestamp corresponding to the received RTP packet o A wall clock timestamp corresponding to the received RTP packet
with the highest sequence number is required in order to compute with the highest sequence number is required in order to compute
the queueing delay. This can be realized by means of the Packet the queueing delay. This can be realized by means of the Packet
Receipt Times Report Block in [RFC3611]. begin_seq should be set Receipt Times Report Block in [RFC3611]. begin_seq should be set
to the highest received (possibly wrapped around) sequence number, to the highest received (possibly wrapped around) sequence number,
end_seq should be set to begin_seq+1 % 65536. The timestamp clock end_seq should be set to begin_seq+1 % 65536. The timestamp clock
may be set according to the specification i.e equal to the RTP may be set according to the specification i.e equal to the RTP
timestamp clock. Detailed individual packet receive times is not timestamp clock. Detailed individual packet receive times is not
skipping to change at page 31, line 42 skipping to change at page 32, line 47
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=3 | rsvd. | T=0 | block length | | BT=3 | rsvd. | T=0 | block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source | | SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | end_seq | | begin_seq | end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receipt time of packet begin_seq | | Receipt time of packet begin_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Basic feedback message for SCReAM Figure 2: Basic feedback message for SCReAM, based on RFC3611
In a typical use case, no more than four Loss RLE chunks should be In a typical use case, no more than four Loss RLE chunks should be
needed, thus the feedback message will be 44bytes. It is obvious needed, thus the feedback message will be 44bytes. It is obvious
from the figure that there is a lot of redundant information in the from the figure that there is a lot of redundant information in the
feedback message. A more optimized feedback format, including the feedback message. A more optimized feedback format, including the
additional feedback elements listed below, should reduce the feedback additional feedback elements listed below, could reduce the feedback
message size a bit. message size a bit.
Additional feedback elements that can improve the performance of Additional feedback elements that can improve the performance of
SCReAM are: SCReAM are:
o Accumulated number of ECN-CE marked packets (n_ECN). This can for o Accumulated number of ECN-CE marked packets (n_ECN). This can for
instance be realized with the ECN Feedback Report Format in instance be realized with the ECN Feedback Report Format in
[RFC6679]. The given feedback report format is actually a slight [RFC6679]. The given feedback report format is actually a slight
overkill as SCReAM would do quite well with only an 8 bit counter overkill as SCReAM would do quite well with only a counter that
that increments by one for each received packet with the ECE-CE increments by one for each received packet with the ECE-CE code
code point set. The more bulky format may be nevertheless be point set. The more bulky format may be nevertheless be useful
useful for e.g ECN black-hole detection. for e.g ECN black-hole detection.
o Source quench bit (Q): Makes it possible to request the sender to o Source quench bit (Q): Makes it possible to request the sender to
reduce its congestion window. This is useful if WebRTC media is reduce its congestion window. This is useful if WebRTC media is
received from many hosts and it becomes necessary to balance the received from many hosts and it becomes necessary to balance the
bitrates between the streams. This can currently not be realized bitrates between the streams. This can currently not be realized
with any standardized feedback format. with any standardized feedback format.
A.4.2. Requirements on feedback intensity A.4.2. Requirements on feedback intensity
SCReAM benefits from a relatively frequent feedback. Experiments SCReAM benefits from a relatively frequent feedback. Experiments
have shown that a feedback rate roughly equal to the frame rate gives have shown that a feedback rate roughly equal to the frame rate gives
a stable self-clocking and robustness against loss of feedback. With a stable self-clocking and robustness against loss of feedback. With
a maximum bitrate of 1500kbps the RTCP feedback overhead is in the a maximum bitrate of 1500kbps the RTCP feedback overhead is in the
range 10-15kbps with reduced size RTCP [RFC5506], including IP and range 10-15kbps with reduced size RTCP [RFC5506], including IP and
UDP framing and a reasonable compact RTCP feedback format. In other UDP framing and a reasonable compact RTCP feedback format. In other
words the RTCP overhead is quite modest and should not pose a problem words the RTCP overhead is quite modest and should not pose a problem
in the general case. Other solutions may be required in highly in the general case. Worth notice is that SCReAM can work with as
asymmetrical link capacity cases. Worth notice is that SCReAM can low feedback rates as once every 200ms at low media rates (e.g
work with as low feedback rates as once every 200ms, this however 50kbps) , a low feedback rate when media rate is high comes at the
comes with a higher sensitivity to loss of feedback and also a cost of a higher sensitivity to loss of feedback and also a potential
potential reduction in throughput. reduction in throughput due to degraded ACK-clocking performance.
SCReAM works with AVPF regular mode, immediate or early mode is not SCReAM works with AVPF regular mode, immediate or early mode is not
required by SCReAM but may nontheless be useful for e.g CCM messages required by SCReAM but may nonetheless be useful for e.g RTCP
specified in [RFC4585]. It is recommended to use reduced size RTCP messages not directly related to SCReAM, such as those specified in
[RFC5506]where regular full compound RTCP transmission is controlled [RFC4585]. It is recommended to use reduced size RTCP [RFC5506]where
by trr-int as described in [RFC4585]. regular full compound RTCP transmission is controlled by trr-int as
described in [RFC4585].
The feedback interval is somewhat depending on the media bitrate. At The feedback interval depends on the media bitrate. At low bitrates
low bitrates it is sufficient with a feedback interval of 100 to it is sufficient with a feedback interval of 100 to 200ms, while at
200ms, while at high bitrates a feedback interval of ~20ms is to high bitrates a feedback interval of ~20ms is to prefer.
prefer.
This leads to a feedback rate according to the following equation This leads to a feedback rate according to the following equation:
rate_fb = min(50,max(10,rate_media/20000))
rate_fb = min(50,max(10,rate_media/20000))
rate_media is the RTP media bitrate expressed in [bits/s], rate_fb is rate_media is the RTP media bitrate expressed in [bits/s], rate_fb is
the feedback rate expressed in [packets/s]. Converted to feedback the feedback rate expressed in [packets/s]. Converted to feedback
interval we get interval we get:
fb_int = 1.0/min(50,max(10,rate_media/20000)) fb_int = 1.0/min(50,max(10,rate_media/20000))
The transmission interval is not critical, this means that in the The transmission interval is not critical, this means that in the
case of multi-stream handling between two hosts, the feedback for two case of multi-stream handling between two hosts, the feedback for two
or more SSRCs can be bundled to save UDP/IP overhead, the final or more SSRCs can be bundled to save UDP/IP overhead, the final
realized feedback interval should however not exceed 2*fb_int in such realized feedback interval should however not exceed 2*fb_int in such
cases meaning that a scheduled feedback transmission event should not cases meaning that a scheduled feedback transmission event should not
be delayed more that fb_int. be delayed more that fb_int.
A.5. Q-bit semantics (source quench) A.5. Q-bit semantics (source quench)
skipping to change at page 33, line 47 skipping to change at page 35, line 5
the sender should react to RTCP feedback with the Q bit set. The the sender should react to RTCP feedback with the Q bit set. The
reduction is done once per RTT. Let : reduction is done once per RTT. Let :
o n = Number of received RTCP feedback messages in one RTT 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 o n_q = Number of received RTCP feedback messages in one RTT, with Q
bit set. bit set.
The new congestion window is then expressed as: The new congestion window is then expressed as:
cwnd = max(MIN_CWND, cwnd*(1.0-0.5* n_q /n)) cwnd = max(MIN_CWND, cwnd*(1.0-0.5* n_q /n))
Note that CWND is adjusted at most once per RTT. Furthermore The Note that CWND is adjusted at most once per RTT. Furthermore The
CWND increase should be inhibited for one RTT if CWND has been CWND increase should be inhibited for one RTT if CWND has been
decreased as a result of Q bits set in the feedback. 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 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 achieve a given rate distribution depends on many factors such as
RTT, video source material etc. The receiver thus need to monitor RTT, video source material etc. The receiver thus need to monitor
the change in the received video bitrate on the different streams and the change in the received video bitrate on the different streams and
adjust the intensity of the Q-bit accordingly. adjust the intensity of the Q-bit accordingly.
 End of changes. 75 change blocks. 
221 lines changed or deleted 258 lines changed or added

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