RMCAT WG
Internet Engineering Task Force (IETF)                      I. Johansson
Internet-Draft
Request for Comments: 8298                                     Z. Sarker
Intended status:
Category: Experimental                                       Ericsson AB
Expires: April 29, 2018                                 October 26,
ISSN: 2070-1721                                            December 2017

              Self-Clocked Rate Adaptation for Multimedia
                     draft-ietf-rmcat-scream-cc-13

Abstract

   This memo describes a rate adaptation algorithm for conversational
   media services such as interactive video.  The solution conforms to
   the packet conservation principle and uses a hybrid loss and delay loss-and-delay-
   based congestion control algorithm.  The algorithm is evaluated over
   both simulated Internet bottleneck scenarios as well as in a Long
   Term Evolution (LTE) system simulator and is shown to achieve both
   low latency and high video throughput in these scenarios.

Status of This Memo

   This Internet-Draft document is submitted in full conformance with the
   provisions of BCP 78 not an Internet Standards Track specification; it is
   published for examination, experimental implementation, and BCP 79.

   Internet-Drafts are working documents
   evaluation.

   This document defines an Experimental Protocol for the Internet
   community.  This document is a product of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list  It represents the consensus of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid the IETF
   community.  It has received public review and has been approved for
   publication by the Internet Engineering Steering Group (IESG).  Not
   all documents approved by the IESG are a maximum candidate for any level of
   Internet Standard; see Section 2 of six months RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 29, 2018.
   https://www.rfc-editor.org/info/rfc8298.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3   4
     1.1.  Wireless (LTE) access properties Access Properties  . . . . . . . . . . . .   3   4
     1.2.  Why is it a self-clocked algorithm? . . . . . . . . . . .   4   5
   2.  Terminology . . . . .  Requirements Language . . . . . . . . . . . . . . . . . . . .   4   5
   3.  Overview of SCReAM Algorithm  . . . . . . . . . . . . . . . .   4   6
     3.1.  Network Congestion Control  . . . . . . . . . . . . . . .   7   8
     3.2.  Sender Transmission Control . . . . . . . . . . . . . . .   8   9
     3.3.  Media Rate Control  . . . . . . . . . . . . . . . . . . .   8   9
   4.  Detailed Description of SCReAM  . . . . . . . . . . . . . . .   9  10
     4.1.  SCReAM Sender . . . . . . . . . . . . . . . . . . . . . .   9  10
       4.1.1.  Constants and Parameter values Values  . . . . . . . . . . .   9  10
         4.1.1.1.  Constants . . . . . . . . . . . . . . . . . . . .  10  11
         4.1.1.2.  State variables Variables . . . . . . . . . . . . . . . . .  11  12
       4.1.2.  Network congestion control Congestion Control  . . . . . . . . . . . . .  13  14
         4.1.2.1.  Reaction to packets loss Packet Loss and ECN . . . . . . . .  16 .  17
         4.1.2.2.  Congestion window update Window Update  . . . . . . . . . . . .  16  17
         4.1.2.3.  Competing flows compensation Flows Compensation  . . . . . . . . . .  19  20
         4.1.2.4.  Lost packet detection Packet Detection . . . . . . . . . . . . . .  21  22
         4.1.2.5.  Send window calculation Window Calculation . . . . . . . . . . . . .  22
         4.1.2.6.  Packet pacing Pacing . . . . . . . . . . . . . . . . . .  23
         4.1.2.7.  Resuming fast increase  . . Fast Increase Mode . . . . . . . . . . .  23  24
         4.1.2.8.  Stream prioritization Prioritization . . . . . . . . . . . . . .  23  24
       4.1.3.  Media rate control Rate Control  . . . . . . . . . . . . . . . . .  24  25
     4.2.  SCReAM Receiver . . . . . . . . . . . . . . . . . . . . .  27  28
       4.2.1.  Requirements on feedback elements Feedback Elements . . . . . . . . . .  27  28
       4.2.2.  Requirements on feedback intensity Feedback Intensity  . . . . . . . . .  29  30
   5.  Discussion  . . . . . . . . . . . . . . . . . . . . . . . . .  29  31
   6.  Implementation status . . . . . .  Suggested Experiments . . . . . . . . . . . . . .  30
     6.1.  OpenWebRTC . . . . . .  31
   7.  IANA Considerations . . . . . . . . . . . . . . . . .  31
     6.2.  A C++ Implementation of SCReAM . . . .  32
   8.  Security Considerations . . . . . . . . .  31
   7.  Suggested experiments . . . . . . . . . .  32
   9.  References  . . . . . . . . . .  32
   8.  Acknowledgements . . . . . . . . . . . . . . .  33
     9.1.  Normative References  . . . . . . .  33
   9.  IANA Considerations . . . . . . . . . . .  33
     9.2.  Informative References  . . . . . . . . . .  33
   10. Security Considerations . . . . . . .  34
   Acknowledgements  . . . . . . . . . . . .  33
   11. Change history . . . . . . . . . . . .  36
   Authors' Addresses  . . . . . . . . . . .  33
   12. References . . . . . . . . . . . . . . . . . . . . . . . . .  34
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  35
     12.2.  Informative References . . . . . . . . . . . . . . . . .  35
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  37  36

1.  Introduction

   Congestion in the Internet occurs when the transmitted bitrate is
   higher than the available capacity over a given transmission path.
   Applications that are deployed in the Internet have to employ
   congestion control, control to achieve robust performance and to avoid
   congestion collapse in the Internet.  Interactive realtime real-time
   communication imposes a lot of requirements on the transport,
   therefore transport;
   therefore, a robust, efficient rate adaptation for all access types
   is an important part of interactive realtime communications real-time communications, as the
   transmission channel bandwidth can vary over time.  Wireless access
   such as LTE, which is an integral 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  Thus, a rate adaptation solution for interactive
   realtime
   real-time media, such as WebRTC, WebRTC [RFC7478], should be both quick and
   be able to operate over a large range in channel capacity.  This memo
   describes
   SCReAM (Self-Clocked Self-Clocked Rate Adaptation for Multimedia), Multimedia (SCReAM), a
   solution that implements congestion control for RTP streams
   [RFC3550].  While SCReAM was originally devised for WebRTC (Web Real-Time
   Communication) [RFC7478], WebRTC, it can
   also be used for other applications where congestion control of RTP
   streams is necessary.  SCReAM is based on the self-clocking principle
   of TCP and uses techniques similar to what is used in the LEDBAT based rate
   adaptation algorithm based on Low Extra Delay Background Transport
   (LEDBAT) [RFC6817].  SCReAM is not entirely self-clocked as it
   augments self-
   clocking self-clocking with pacing and a minimum send rate.  SCReAM
   can take advantage of ECN (Explicit Explicit Congestion Notification) Notification (ECN) in cases
   where ECN is supported by the network and the hosts.  However, ECN is
   however
   not required for the basic congestion control functionality in
   SCReAM.

1.1.  Wireless (LTE) access properties

   [I-D.ietf-rmcat-wireless-tests] Access Properties

   [WIRELESS-TESTS] describes the complications that can be observed in
   wireless environments.  Wireless access such as LTE
   can typically not cannot
   guarantee a given bandwidth, bandwidth; this is true especially for default
   bearers.  The network throughput can vary
   considerably considerably, for instance instance,
   in cases where the wireless terminal is moving around.  Even though
   LTE can support bitrates well above
   100Mbps, 100 Mbps, there are cases when
   the available bitrate can be much
   lower, lower; examples are situations with
   high network load and poor coverage.  An additional complication is
   that the network throughput can drop for short time intervals (e.g.,
   at e.g. handover, handover); these short glitches are initially very difficult to
   distinguish from more permanent reductions in throughput.

   Unlike wireline bottlenecks with large statistical multiplexing multiplexing, it
   is not possible to try to maintain a given bitrate when congestion is
   detected with the hope that other flows will yield, this yield.  This is because
   there are generally few other flows competing for the same
   bottleneck.  Each user gets its own variable throughput bottleneck,
   where the throughput depends on factors like channel quality, network
   load
   load, and historical throughput.  The bottom line is, if the
   throughput drops, the sender has no other option than to reduce the
   bitrate.  Once the radio scheduler has reduced the resource
   allocation for a bearer, an RMCAT a flow (which is using RTP Media Congestion
   Avoidance Techniques (RMCAT)) in that bearer aims to reduce the
   sending rate quite quickly (within one RTT) in order to avoid
   excessive queuing delay or packet loss.

1.2.  Why is it a self-clocked algorithm?

   Self-clocked congestion control algorithms provide a benefit over the
   rate based
   their rate-based counterparts in that the former consists of two
   adaptation mechanisms:

   o  A congestion window computation that evolves over a longer
      timescale (several RTTs) especially when the congestion window
      evolution is dictated by estimated delay (to minimize
      vulnerability to e.g. short term to, e.g., short-term delay variations).

   o  A fine grained fine-grained congestion control given by the self-clocking which self-clocking; it
      operates on a shorter time scale (1 RTT).  The benefits of self-
      clocking are also elaborated upon in [TFWC].

   A rate based rate-based congestion control algorithm typically adjusts the rate
   based on delay and loss.  The congestion detection needs to be done
   with a certain time lag to avoid over-reaction overreaction to spurious congestion
   events such as delay spikes.  Despite the fact that there are two or
   more congestion indications, the outcome is still that there is still only
   one mechanism to adjust the sending rate.  This makes it difficult to
   reach the goals of high throughput and prompt reaction to congestion.

2.  Terminology  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  Overview of SCReAM Algorithm

   The core SCReAM algorithm has similarities to the concepts of self-
   clocking used in TFWC TCP-friendly window-based congestion control [TFWC]
   and follows the packet conservation principle.  The packet
   conservation principle is described as an
   important key-factor a key factor behind the
   protection of networks from congestion [Packet-conservation].

   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
   number back to the sender in feedback packets.  The sender keeps a
   list of transmitted packets, their respective sizes sizes, and the time
   they were transmitted.  This information is used to determine the
   number of bytes that can be transmitted at any given time instant.  A
   congestion window puts an upper limit on how many bytes can be in
   flight, i.e. i.e., transmitted but not yet acknowledged.

   The congestion window is determined in a way similar to LEDBAT
   [RFC6817].  LEDBAT is a congestion control algorithm that uses send
   and receive timestamps to estimate the queuing delay (from now on
   denoted qdelay) "qdelay") along the transmission path.  This information is
   used to adjust the congestion window.  The use of LEDBAT ensures that
   the end-to-end latency is kept low.  [LEDBAT-delay-impact] shows that
   LEDBAT has certain inherent issues that makes make it counteract its
   purpose to achieve of achieving low delay.  The general problem described in the
   paper is that the base delay is offset by LEDBAT's own queue buildup.
   The big difference with using LEDBAT in the SCReAM context lies in
   the fact facts that the source is rate limited and that it is required that the RTP queue is must
   be kept short (preferably empty).  In addition addition, the output from a
   video encoder is rarely constant bitrate, bitrate; static content (talking heads)
   heads, for instance instance) gives almost zero video bitrate.  This gives yields
   two useful properties when LEDBAT is used with SCReAM that SCReAM; they help to
   avoid the issues described in [LEDBAT-delay-impact]:

   1.  There is always a certain probability that SCReAM is short of
       data to transmit, which transmit; this means that the network queue will run become
       empty every once in a while.

   2.  The max video bitrate can be lower than the link capacity.  If
       the max video bitrate is 5Mbps 5 Mbps and the capacity is 10Mbps 10 Mbps, then
       the network queue will run become empty.

   It is sufficient that any of the two conditions above is fulfilled to
   make the base delay update properly.  Furthermore  Furthermore,
   [LEDBAT-delay-impact] describes an issue with short lived short-lived competing
   flows, the case in SCReAM is that
   flows.  In SCReAM, these short lived short-lived flows will cause the self-clocking in SCReAM self-
   clocking to slow down with the result that down, thereby building up the RTP
   queue is built up, which will queue; in turn result turn,
   this results in a reduced media video bitrate.  Thus, SCReAM will thus yield slows
   the bitrate more to when there are competing short lived short-lived flows than what is the case with
   traditional use of LEDBAT. LEDBAT does.  The basic functionality in the use
   of LEDBAT in SCReAM is quite
   simple, simple; however, there are however a few steps to take
   in order to make the concept work with conversational media:

   o  Congestion window validation techniques.  These are similar in
      action as to the
      method described in [RFC7661].  Congestion window validation
      ensures that the congestion window is limited by the actual number
      bytes in flight, flight; this is important especially in the context of rate limited
      rate-limited sources such as video.  Lack of congestion window
      validation would lead to a slow reaction to congestion as the
      congestion window does not properly reflect the congestion state
      in the network.  The allowed idle period in this memo is shorter
      than in [RFC7661], [RFC7661]; this to avoid excessive delays in the cases where e.g.
      where, e.g., wireless throughput has decreased during a period
      where the output bitrate from the media coder has been low, for
      instance low (for
      instance, due to inactivity. inactivity).  Furthermore, this memo allows for
      more relaxed rules for when the congestion window is allowed to
      grow,
      grow; this is necessary as the variable output bitrate generally
      means that the congestion window is often under-utilized. underutilized.

   o  Fast increase mode makes the bitrate increase faster when no
      congestion is detected.  It makes the media bitrate ramp-up ramp up within
      5 to 10 seconds.  The behavior is similar to TCP slowstart.  The fast  Fast
      increase mode is exited when congestion is detected.  The  However,
      fast increase
      state mode can however resume if the congestion level is low, low; this
      enables a reasonably quick rate increase in case link throughput
      increases.

   o  A qdelay trend is computed for earlier detection of incipient
      congestion and
      congestion; as a result result, it reduces jitter.

   o  Addition of a media rate control function.

   o  Use of inflection points in the media rate calculation to achieve
      reduced jitter.

   o  Adjustment of qdelay target for better performance when competing
      with other loss based congestion controlled loss-based congestion-controlled flows.

   The above mentioned above-mentioned features will be described in more detail in
   sections Section
   Sections 3.1 to Section 3.3.  The full details are described in Section 4.

                    +---------------------------+
                    |        Media encoder      |
                    +---------------------------+
                        ^                  |
                        |                  |(1)
                        |(3)              RTP
                        |                  V
                        |            +-----------+
                   +---------+       |           |
                   | Media   |  (2)  |   Queue   |
                   | rate    |<------|           |
                   | control |       |RTP packets|
                   +---------+       |           |
                                     +-----------+
                                           |
                                           |(4)
                                          RTP
                                           |
                                           v
              +------------+       +--------------+
              |  Network   |  (7)  |    Sender    |
          +-->| congestion |------>| Transmission |
          |   |  control   |       |   Control    |
          |   +------------+       +--------------+
          |                                |
          |-------------RTCP----------|    |(5)
              (6)                     |   RTP
                                      |    v
                                  +------------+
                                  |     UDP    |
                                  |   socket   |
                                  +------------+

                  Figure 1: SCReAM sender functional view Sender Functional View

   The SCReAM algorithm consists of three main parts: network congestion
   control, sender transmission control control, and media rate control.  All of
   these three parts reside at the sender side.  Figure 1 shows the functional
   overview of a SCReAM sender.  The receiver side receiver-side algorithm is very
   simple in comparison comparison, as it only generates feedback containing
   acknowledgements of received RTP packets and an ECN count.

3.1.  Network Congestion Control

   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
   (congestion window) and is used in the sender transmission control.

   The SCReAM congestion control method, method uses techniques similar to
   LEDBAT [RFC6817] to measure the qdelay.  As is the case with LEDBAT,
   it is not necessary to use synchronized clocks in the sender and
   receiver in order to compute the qdelay.  It  However, 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.  Failure to
   meet this requirement leads to malfunction in the SCReAM congestion
   control algorithm due to incorrect estimation of the network queue
   delay.

   The SCReAM sender calculates the congestion window based on the
   feedback from the SCReAM receiver.  The congestion window is allowed
   to increase if the qdelay is below a predefined qdelay target,
   otherwise target;
   otherwise, the congestion window decreases.  The qdelay target is
   typically set to 50-100ms. 50-100 ms.  This ensures that the queuing delay is
   kept low.  The reaction to loss or ECN events leads to an instant
   reduction of CWND.  Note that the source rate limited rate-limited nature of real real-
   time media media, such as video, typically means that the queuing delay
   will mostly be below the given delay target, this target.  This is contrary to the
   case where large files are transmitted using LEDBAT congestion control, in
   which case
   control and the queuing delay will stay close to the delay target.

3.2.  Sender Transmission Control

   The sender transmission control limits the output of data, given by
   the relation between the number of bytes in flight and the congestion
   window.  Packet pacing is used to mitigate issues with ACK
   compression that MAY cause increased jitter and/or packet loss in the
   media traffic.  Packet pacing limits the packet transmission rate
   given by the estimated link throughput.  Even if the send window
   allows for the transmission of a number of packets, these packets are
   not transmitted immediately, but rather immediately; rather, they are transmitted in
   intervals given by the packet size and the estimated link throughput.

3.3.  Media Rate Control

   The media rate control serves to adjust the media bitrate to ramp-up ramp up
   quickly enough to get a fair share of the system resources when link
   throughput increases.

   The reaction to reduced throughput MUST be prompt in order to avoid
   getting too much data queued in the RTP packet queue(s) in the
   sender.  The media bitrate is decreased if the RTP queue size exceeds
   a threshold.

   In cases where the sender sender's frame queues increase rapidly rapidly, such as in
   the case of a RAT (Radio Radio Access Type) handover it Type (RAT) handover, the SCReAM sender MAY be necessary to
   implement additional actions, such as discarding of encoded media
   frames or frame skipping in order to ensure that the RTP queues are
   drained quickly.  Frame skipping results in the frame rate being
   temporarily reduced.  Which method to use is a design choice and is
   outside the scope of this algorithm description.

4.  Detailed Description of SCReAM

4.1.  SCReAM Sender

   This section describes the sender side sender-side algorithm in more detail.  It
   is split between the network congestion control, sender transmission
   control
   control, and the media rate control.

   A SCReAM sender implements media rate control and an RTP queue for
   each media type or source, where RTP packets containing encoded media
   frames are temporarily stored for transmission.  Figure 1 shows the
   details when a single media source (or stream) is used.  A
   transmission scheduler (not shown in the figure) is added to support
   multiple streams.  The transmission scheduler can enforce differing
   priorities between the streams and act like a coupled congestion
   controller for multiple flows.  Support for multiple streams is
   implemented in [SCReAM-CPP-implementation].

   Media frames are encoded and forwarded to the RTP queue (1) in
   Figure 1.  The media rate adaptation adapts to the size of the RTP
   queue (2) and provides a target rate for the media encoder (3).  The
   RTP packets are picked from the RTP queue (for (4), for multiple flows
   from each RTP queue based on some defined priority order or simply in
   a
   round robin fashion) (4) round-robin fashion, by the sender transmission controller.  The
   sender transmission controller (in case of multiple flows a
   transmission scheduler) sends the RTP packets to the UDP socket (5).
   In the general case case, all media SHOULD go through the sender
   transmission controller and is limited so that the number of bytes in
   flight is less than the congestion window.  RTCP packets are received
   (6) and the information about the bytes in flight and congestion
   window is exchanged between the network congestion control and the
   sender transmission control (7).

4.1.1.  Constants and Parameter values Values

   Constants and state variables are listed in this section.  Temporary
   variables are not listed, instead listed; instead, they are appended with '_t' in the
   pseudo code
   pseudocode to indicate their local scope.

4.1.1.1.  Constants

   The RECOMMENDED values, within (), parentheses "()", for the constants
   are deduced from experiments.  The units are enclosed in square brackets [ ].

   QDELAY_TARGET_LO (0.1s) (0.1 s)
     Target value for the minimum qdelay.

   QDELAY_TARGET_HI (0.4s) (0.4 s)
     Target value for the maximum qdelay.  This parameter provides an
     upper limit to how much the target qdelay (qdelay_target) can be
     increased in order to cope with competing loss based loss-based flows.  The
     However, the target qdelay does not have to be initialized to this
     high value
     however value, as it would increase e2e end-to-end delay and also make the
     rate control and congestion control loop loops sluggish.

   QDELAY_WEIGHT (0.1)
     Averaging factor for qdelay_fraction_avg.

   QDELAY_TREND_TH (0.2)
     Threshold for the detection of incipient congestion.

   MIN_CWND (3000byte) (3000 bytes)
     Minimum congestion window.

   MAX_BYTES_IN_FLIGHT_HEAD_ROOM (1.1)
     Headroom for the limitation of CWND.

   GAIN (1.0)
     Gain factor for congestion window adjustment.

   BETA_LOSS (0.8)
     CWND scale factor due to loss event.

   BETA_ECN (0.9)
     CWND scale factor due to ECN event.

   BETA_R (0.9)
     Target rate scale
     Scale factor for target rate due to loss event.

   MSS (1000 byte)
     Maximum segment size = Max RTP packet size.

   RATE_ADJUST_INTERVAL (0.2s) (0.2 s)
     Interval between media bitrate adjustments.

   TARGET_BITRATE_MIN
     Min
     Minimum target bitrate [bps], in bps is bits (bits per second. second).

   TARGET_BITRATE_MAX
     Max
     Maximum target bitrate [bps]. in bps.

   RAMP_UP_SPEED (200000bps/s) (200000 bps/s)
     Maximum allowed rate increase speed.

   PRE_CONGESTION_GUARD  (0.0..1.0)
     Guard factor against early congestion onset.  A higher value gives
     less jitter, possibly at the expense of a lower link utilization.
     This value MAY be subject to tuning depending on e.g e.g., media coder
     characteristics, experiments
     characteristics.  Experiments with H264 and VP8 indicate that 0.1
     is a suitable value.  See [SCReAM-CPP-implementation] and
     [SCReAM-implementation-experience] for evaluation of a real
     implementation.

   TX_QUEUE_SIZE_FACTOR (0.0..2.0)
     Guard factor against RTP queue buildup.  This value MAY be subject
     to tuning depending on e.g on, e.g., media coder characteristics, experiments characteristics.
     Experiments with H264 and VP8 indicate that 1.0 is a suitable
     value.  See [SCReAM-CPP-implementation] and
     [SCReAM-implementation-experience] for evaluation of a real
     implementation.

   RTP_QDELAY_TH (0.02s) (0.02 s)  RTP queue delay threshold for a target rate
     reduction.

   TARGET_RATE_SCALE_RTP_QDELAY (0.95)  Target  Scale factor for target rate scale
     when RTP qdelay threshold exceeds RTP_QDELAY_TH.

   QDELAY_TREND_LO (0.2)  Threshold value for qdelay_trend.

   T_RESUME_FAST_INCREASE (5s) (5 s)  Time span until fast increase mode can
     be resumed, given that the qdelay_trend is below QDELAY_TREND_LO.

   RATE_PACE_MIN (50000bps) (50000 bps)  Minimum pacing rate.

4.1.1.2.  State variables Variables

   The values within () parentheses "()" indicate initial values.

   qdelay_target (QDELAY_TARGET_LO)
     qdelay target, a variable qdelay target is introduced to manage
     cases where e.g.  FTP competes for the bandwidth over the same
     bottleneck, a fixed qdelay target would otherwise starve the RMCAT
     flow under such circumstances. circumstances (e.g., FTP competes for the bandwidth
     over the same bottleneck).  The qdelay target is allowed to vary
     between QDELAY_TARGET_LO and QDELAY_TARGET_HI.

   qdelay_fraction_avg (0.0)
     EWMA (Exponentially
     Fractional qdelay filtered by the Exponentially Weighted Moving Average) filtered fractional
     qdelay.
     Average (EWMA).

   qdelay_fraction_hist[20] ({0,..,0})
     Vector of the last 20 fractional qdelay samples.

   qdelay_trend (0.0)
     qdelay trend, trend; indicates incipient congestion.

   qdelay_trend_mem (0.0)
     Low pass
     Low-pass filtered version of qdelay_trend.

   qdelay_norm_hist[100] ({0,..,0})
     Vector of the last 100 normalized qdelay samples.

   in_fast_increase (true)
     True if in fast increase state. mode.

   cwnd (MIN_CWND)
     Congestion window.

   bytes_newly_acked (0)
     The number of bytes that was acknowledged with the last received
     acknowledgement i.e.
     acknowledgement, i.e., bytes acknowledged since the last CWND
     update.

   max_bytes_in_flight (0)
     The maximum number of bytes in flight over a sliding time window,
     i.e.
     i.e., transmitted but not yet acknowledged bytes.

   send_wnd (0)
     Upper limit to how many bytes that can currently be transmitted.
     Updated when cwnd is updated and when RTP packet is transmitted.

   target_bitrate (0 bps)
     Media target bitrate.

   target_bitrate_last_max (1 bps)
     Media target bitrate inflection
     Inflection point i.e. of the media target bitrate, i.e., the last known
     highest target_bitrate.  Used to limit bitrate increase speed close
     to the last known congestion point.

   rate_transmit (0.0 bps)
     Measured transmit bitrate.

   rate_ack (0.0 bps)
     Measured throughput based on received acknowledgements.

   rate_media (0.0 bps)
     Measured bitrate from the media encoder.

   rate_media_median (0.0 bps)
     Median value of rate_media, computed over more than 10s. 10 s.

   s_rtt (0.0s)
     Smoothed RTT [s], (in seconds), computed with a similar method to that
     described in [RFC6298].

   rtp_queue_size (0 bits)
     Sum of the sizes of RTP packets in queue.

   rtp_size (0 byte)
     Size of the last transmitted RTP packet.

   loss_event_rate (0.0)
     The estimated fraction of RTTs with lost packets detected.

4.1.2.  Network congestion control Congestion Control

   This section explains the network congestion control, it contains which performs
   two main functions:

   o  Computation of congestion window at the sender: Gives This gives an
      upper limit to the number of bytes in flight.

   o  Calculation of send window at the sender: RTP packets are
      transmitted if allowed by the relation between the number of bytes
      in flight and the congestion window.  This is controlled by the
      send window.

   SCReAM is a window based window-based and byte oriented byte-oriented congestion control
   protocol, where the number of bytes transmitted is inferred from the
   size of the transmitted RTP packets.  Thus  Thus, a list of transmitted RTP
   packets and their respective transmission times (wall-clock time)
   MUST be kept for further calculation.

   The number of bytes in flight (bytes_in_flight) is computed as the
   sum of the sizes of the RTP packets ranging from the RTP packet most
   recently transmitted 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
   an RTP packet with sequence number SN is transmitted and the last
   acknowledgement indicates SN-5 as the highest received sequence
   number
   number, then bytes in flight 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 SN-1, and SN, it SN.  It
   does not matter if if, for instance instance, the packet with sequence number
   SN-3 was lost, lost -- the size of RTP packet with sequence number SN-3
   will still be considered in the computation of bytes_in_flight.

   Furthermore, a variable 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 N+2, and N+3.  Packets that are lost are also included,
   which means that even though e.g though, e.g., packet N+2 was lost, its size is
   still included in the update of bytes_newly_acked.  The
   bytes_newly_acked variable is reset to zero after a CWND update.

   The feedback from the receiver is assumed to consist of the following
   elements.

   o  A list of received RTP packets' sequence numbers.

   o  The wall clock wall-clock timestamp corresponding to the received RTP packet
      with the highest sequence number.

   o  Accumulated  The accumulated number of ECN-CE marked ECN-CE-marked packets (n_ECN).  Here,
      "CE" refers to "Congestion Experienced".

   When the sender receives RTCP feedback, the qdelay is calculated as
   outlined in [RFC6817].  A qdelay sample is obtained for each received
   acknowledgement.  No smoothing of the qdelay samples occur, however is performed; however,
   some smoothing occurs anyway as the computation of because the CWND computation is a low low-
   pass filter function.  A number of variables are updated as
   illustrated by the pseudo code below, pseudocode below; temporary variables are appended
   with '_t'.  As mentioned in Section 7 , 6, calculation of the proper
   congestion window and media bitrate may benefit from additional
   optimizations for handling of to handle very high and very low bitrates, and from
   additional damping to handle periodic packet bursts.  Some such
   optimizations are implemented in [SCReAM-CPP-implementation], but
   they do not form part of the specification of SCReAM at this time.

     <CODE BEGINS>
     update_variables(qdelay):
       qdelay_fraction_t = qdelay/qdelay_target qdelay / qdelay_target
       # Calculate moving average
       qdelay_fraction_avg = (1-QDELAY_WEIGHT)*qdelay_fraction_avg+
          QDELAY_WEIGHT*qdelay_fraction_t (1 - QDELAY_WEIGHT) * qdelay_fraction_avg +
          QDELAY_WEIGHT * qdelay_fraction_t
       update_qdelay_fraction_hist(qdelay_fraction_t)
       # Compute the average of the values in qdelay_fraction_hist
       avg_t = average(qdelay_fraction_hist)
       # R is an autocorrelation function of qdelay_fraction_hist,
       #  with the mean (DC component) removed, at lag K
       # The subtraction of the scalar avg_t from
       #  qdelay_fraction_hist is performed element-wise
       a_t = R(qdelay_fraction_hist-avg_t,1)/
             R(qdelay_fraction_hist-avg_t,0) R(qdelay_fraction_hist-avg_t, 1) /
             R(qdelay_fraction_hist-avg_t, 0)
       # Calculate qdelay trend
       qdelay_trend = min(1.0,max(0.0,a_t*qdelay_fraction_avg)) min(1.0, max(0.0, a_t * qdelay_fraction_avg))
       # Calculate a 'peak-hold' qdelay_trend, qdelay_trend; this gives a memory
       #  of congestion in the past
       qdelay_trend_mem = max(0.99*qdelay_trend_mem, max(0.99 * qdelay_trend_mem, qdelay_trend)
      <CODE ENDS>

   The qdelay fraction is sampled every 50ms 50 ms, and the last 20 samples
   are stored in a vector (qdelay_fraction_hist).  This vector is used
   in the computation of an a qdelay trend that gives a value between 0.0
   and 1.0 depending on the estimated congestion level.  The prediction
   coefficient 'a_t' has positive values if qdelay shows an increasing
   or decreasing trend, thus trend; thus, an indication of congestion is obtained
   before the qdelay target is reached.  As a side effect, also the case
   that if qdelay decreases is
   decreases, it's taken as a sign of congestion, congestion; however, experiments
   have however shown that this is beneficial beneficial, as varying increasing or decreasing queue
   delay up
   or down is an indication that the transmit rate is very close to the
   path capacity.

   The autocorrelation function 'R' is defined as follows.  Let x be a
   vector constituting N values, the biased autocorrelation function for
   a given lag=k for the vector x is given by.

                 n=N-k
         R(x,k) = SUM x(n)*x(n+k) x(n) * x(n + k)
                 n=1

   The prediction coefficient is further multiplied with
   qdelay_fraction_avg to reduce sensitivity to increasing qdelay when
   it is very small.  The 50ms 50 ms sampling is a simplification that could
   have the effect that the same qdelay is sampled several times, times;
   however, this does however not pose any problem problem, as the vector is only used
   to determine if the qdelay is increasing or decreasing.  The
   qdelay_trend is utilized in the media rate control to indicate
   incipient congestion and to determine when to exit from fast increase
   mode. qdelay_trend_mem is used to enforce a less aggressive rate
   increase after congestion events.  The function
   update_qdelay_fraction_hist(..) removes the oldest element and adds
   the latest qdelay_fraction element to the qdelay_fraction_hist
   vector.

4.1.2.1.  Reaction to packets loss Packet Loss and ECN

   A loss event is indicated if one or more RTP packets are declared
   missing.  The loss detection is described in Section 4.1.2.4.  Once a
   loss event is detected, further detected lost RTP packets SHOULD be
   ignored for a full smoothed round trip time, round-trip time; the intention of this is to
   limit the congestion window decrease to at most once per round trip.

   The congestion window back off back-off due to loss events is deliberately a
   bit less than is the case with e.g.  TCP Reno.  The reason is that TCP Reno, for example.  TCP is
   generally used to transmit whole files, which can be
   translated to files; the file is then like a
   source with an infinite source bitrate.  SCReAM bitrate until the whole file has been
   transmitted.  SCReAM, on the other hand hand, has a source whose rate is
   limited to a value close to the available transmit rate and often
   below that value, value; the effect of this is that SCReAM has less opportunity to
   grab free capacity than a TCP based TCP-based file transfer.  To compensate for this
   this, it is RECOMMENDED to let SCReAM reduce the congestion window
   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
   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,
   round-trip time; the intention of this is to limit the congestion window
   decrease to at most once per round trip.  The congestion window back back-
   off due to an ECN event MAY be smaller than if a loss event occurs.
   This is in line with the idea outlined in
   [I-D.ietf-tcpm-alternativebackoff-ecn] [ALT-BACKOFF] to enable ECN
   marking thresholds lower than the corresponding packet drop
   thresholds.

4.1.2.2.  Congestion window update Window Update

   The update of the congestion window depends on whether loss or ECN-
   marking if loss, ECN-marking,
   or neither of the two occurs.  The pseudo code pseudocode below describes actions
   taken in case of the different events.
   actions for each case.

     <CODE BEGINS>
     on congestion event(qdelay):
       # Either loss or ECN mark is detected
       in_fast_increase = false
       if (is loss)
         # Loss is detected
         cwnd = max(MIN_CWND,cwnd*BETA_LOSS) max(MIN_CWND, cwnd * BETA_LOSS)
       else
         # No loss, so it is then an ECN mark
         cwnd = max(MIN_CWND,cwnd*BETA_ECN) max(MIN_CWND, cwnd * BETA_ECN)
       end
       adjust_qdelay_target(qdelay) #compensating for competing flows
       calculate_send_window(qdelay,qdelay_target)
       calculate_send_window(qdelay, qdelay_target)

     # When no congestion event
     on acknowledgement(qdelay):
       update_bytes_newly_acked()
       update_cwnd(bytes_newly_acked)
       adjust_qdelay_target(qdelay) #compensating # compensating for competing flows
       calculate_send_window(qdelay, qdelay_target)
       check_to_resume_fast_increase()
     <CODE ENDS>

   The methods are further described in detail below.

   The congestion window update is based on qdelay, except for the
   occurrence of loss events (one or more lost RTP packets in one RTT), RTT)
   or ECN events, which was were described earlier.

   Pseudo code

   Pseudocode for the update of the congestion window is found below.

   <CODE BEGINS>
   update_cwnd(bytes_newly_acked):
     # In fast increase ? mode?
     if (in_fast_increase)
       if (qdelay_trend >= QDELAY_TREND_TH)
         # Incipient congestion detected, detected; exit fast increase mode
         in_fast_increase = false
       else
         # No congestion yet, yet; increase cwnd if it
         #  is sufficiently used
         # An additional Additional slack of bytes_newly_acked is
         #  added to ensure that CWND growth occurs
         #  even when feedback is sparse
         if (bytes_in_flight*1.5+bytes_newly_acked (bytes_in_flight * 1.5 + bytes_newly_acked > cwnd)
           cwnd = cwnd+bytes_newly_acked cwnd + bytes_newly_acked
         end
         return
       end
     end

     # Not in fast increase phase mode
     # off_target calculated as with LEDBAT
     off_target_t = (qdelay_target - qdelay) / qdelay_target

     gain_t = GAIN
     # Adjust congestion window
     cwnd_delta_t =
       gain_t * off_target_t * bytes_newly_acked * MSS / cwnd
     if (off_target_t > 0 &&
         bytes_in_flight*1.25+bytes_newly_acked
         bytes_in_flight * 1.25 + bytes_newly_acked <= cwnd)
       # No cwnd increase if window is underutilized
       # An additional Additional slack of bytes_newly_acked is
       #  added to ensure that CWND growth occurs
       #  even when feedback is sparse
       cwnd_delta_t = 0;
     end

     # Apply delta
     cwnd += cwnd_delta_t
     # limit cwnd to the maximum number of bytes in flight
     cwnd = min(cwnd, max_bytes_in_flight*MAX_BYTES_IN_FLIGHT_HEAD_ROOM) max_bytes_in_flight *
                MAX_BYTES_IN_FLIGHT_HEAD_ROOM)
     cwnd = max(cwnd, MIN_CWND)

   <CODE ENDS>
   CWND is updated differently depending on whether or not the
   congestion control is in fast increase state or not, mode, as controlled by the
   variable in_fast_increase.

   When in fast increase state, mode, the congestion window is increased with
   the number of newly acknowledged bytes as long as the window is
   sufficiently used.  Sparse feedback can potentially limit congestion
   window growth, an growth; therefore, additional slack is therefore added, given by the
   number of newly acknowledged bytes.

   The congestion window growth when in_fast_increase is false is
   dictated by the relation between qdelay and qdelay_target, qdelay_target; congestion
   window growth is limited if the window is not used sufficiently.

   SCReAM calculates the GAIN in a similar way to what is specified in
   [RFC6817].  However, [RFC6817] specifies that the CWND increase is
   limited by an additional function controlled by a constant
   ALLOWED_INCREASE.  This additional limitation is removed in this
   specification.

   Further

   Further, the CWND is limited by max_bytes_in_flight and MIN_CWND.
   The limitation of the congestion window by the maximum number of
   bytes in flight over the last 5 seconds (max_bytes_in_flight) avoids
   possible
   over-estimation overestimation of the throughput after after, for example, idle
   periods.  An additional MAX_BYTES_IN_FLIGHT_HEAD_ROOM allows for a slack, provides slack
   to allow for a certain amount of variability in the media coder
   output rate variability. rate.

4.1.2.3.  Competing flows compensation Flows Compensation

   It is likely that a flow using the SCReAM algorithm will have to
   share congested bottlenecks with other flows that use a more
   aggressive congestion control algorithm, examples are algorithm (for example, large FTP flows
   using loss
   based loss-based congestion control. control).  The worst condition occurs
   when the bottleneck queues are of tail-drop type with a large buffer
   size.  SCReAM takes care of such situations by adjusting the
   qdelay_target when loss based loss-based flows are detected, as given by shown in the pseudo code
   pseudocode below.

     <CODE BEGINS>
     adjust_qdelay_target(qdelay)
       qdelay_norm_t = qdelay / QDELAY_TARGET_LOW
       update_qdelay_norm_history(qdelay_norm_t)
       # Compute variance
       qdelay_norm_var_t = VARIANCE(qdelay_norm_history(200))
       # Compensation for competing traffic
       # Compute average
       qdelay_norm_avg_t = AVERAGE(qdelay_norm_history(50))
       # Compute upper limit to target delay
       new_target_t = qdelay_norm_avg_t + sqrt(qdelay_norm_var_t)
       new_target_t *= QDELAY_TARGET_LO
       if (loss_event_rate > 0.002)
         # Packet losses detected
         qdelay_target = 1.5*new_target_t 1.5 * new_target_t
       else
         if (qdelay_norm_var_t < 0.2)
           # Reasonably safe to set target qdelay
           qdelay_target = new_target_t
         else
           # Check if target delay can be reduced, reduced; this helps to avoid prevent
           #  that  the target delay is from being locked to high values for ever forever
           if (new_target_t < QDELAY_TARGET_LO)
             # Decrease target delay quickly quickly, as measured queueing queuing
             #  delay is lower than target
             qdelay_target = max(qdelay_target*0.5,new_target_t) max(qdelay_target * 0.5, new_target_t)
           else
             # Decrease target delay slowly
             qdelay_target *= 0.9
           end
         end
       end

       # Apply limits
       qdelay_target = min(QDELAY_TARGET_HI, qdelay_target)
       qdelay_target = max(QDELAY_TARGET_LO, qdelay_target)
     <CODE ENDS>

   Two temporary variables are calculated. qdelay_norm_avg_t is the long
   term
   long-term average queue delay, qdelay_norm_var_t is the long term long-term
   variance of the queue delay.  A high qdelay_norm_var_t indicates that
   the queue delay changes, changes; this can be an indication of reduced that bottleneck
   bandwidth is reduced or that a competing flow has just entered.
   Thus, it indicates that it is not safe to adjust the queue delay
   target.

   A low qdelay_norm_var_t indicates that the queue delay is relatively
   stable, the
   stable.  The reason can could be that the queue delay is low low, but it can
   could also be an indication that a competing flow is filling up causing the bottleneck to
   reach the limit where point that packet losses may start to occur, in which case the
   queue delay will stay relatively high for a longer time.

   The queue delay target is allowed to be increased if, if either the loss
   event rate is above a given threshold or that qdelay_norm_var_t is low.
   Both these conditions indicate that a competing flow may be present.
   In all other cases cases, the queue delay target is decreased.

   The function that adjusts the qdelay_target is simple and has a
   certain risk to could
   produce both false positive positives and negatives, false negatives.  The case that self-inflicted self-
   inflicted congestion by the SCReAM algorithm may be falsely
   interpreted as the presence of competing loss based loss-based FTP flows is a
   false positive.  The opposite case -- where the algorithm fails to
   detect the presence of a competing FTP flow -- is a false negative.

   Extensive simulations have shown that the algorithm performs well in
   LTE test cases and that it also performs well in simple bandwidth bandwidth-
   limited bottleneck test cases with competing FTP flows.  It can
   however not  However, the
   potential failure of the algorithm cannot be completely ruled out that this algorithm can fail.
   Especially the out.  A
   false positives can be problematic positive (i.e., when self-inflicted congestion is mistakenly
   identified as the end competing flows) is especially problematic when it
   leads to end
   delay can increase dramatically if increasing the target queue delay, which can cause the end-
   to-end delay is
   increased by accident as a result of self-inflicted congestion. to increase dramatically.

   If it is deemed unlikely that competing flows occur over the same
   bottleneck, the algorithm described in this section MAY be turned
   off.  One such case can be QoS enabled is QoS-enabled bearers in 3GPP based 3GPP-based access such
   as LTE.  However, when sending over the Internet, often the network
   conditions are not known for sure and it is sure, so in general it is not possible
   to make safe assumptions on how a network is used and whether or not
   competing flows share the same bottleneck.  Therefore  Therefore, turning this
   algorithm off must be considered with caution caution, as that it can lead to
   basically zero throughput if competing with other, loss
   based, loss-based traffic.

4.1.2.4.  Lost packet detection Packet Detection

   Lost packet detection is based on the received sequence number list.
   A reordering window SHOULD be applied to avoid that prevent packet reordering
   triggers
   from triggering loss events.  The reordering window is specified as a
   time unit, similar to the ideas behind RACK (Recent ACKnowledgement) [I-D.ietf-tcpm-rack]. Recent ACKnowledgement (RACK)
   [RACK].  The computation of the reordering window is made possible by
   means of a lost flag in the list of transmitted RTP packets.  This
   flag is set if the received sequence number list indicates that the
   given RTP packet is missing.  If a later feedback indicates that a
   previously lost marked packet was indeed received, then the
   reordering window is updated to reflect the reordering delay.  The
   reordering window is given by the difference in time between the
   event that the packet was marked as lost and the event that it was
   indicated as successfully received.  Loss is detected if a given RTP
   packet is not acknowledged within a time window (indicated by the
   reordering window) after an RTP packet with a higher sequence number
   was acknowledged.

4.1.2.5.  Send window calculation 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 are, however, two reasons why this
   strict rule will not work optimally:

   o  Bitrate variations: Media sources such as video encoders generally
      produce frames whose size always vary to a larger or smaller
      extent.  The RTP queue absorbs the natural variations in frame
      sizes.  The  However, the RTP queue should however be as short as possible, possible to
      avoid that
      prevent the end to end end-to-end delay increases. from increasing.  To achieve that,
      the media rate control takes the RTP queue size into account when
      the target bitrate for the media is computed.  A strict 'send only
      when bytes in flight is less than the congestion window' rule can
      lead to that
      cause the RTP queue grows to grow simply because the send window is
      limited, the effect of which would be that
      limited; in turn, this can cause the target bitrate is to be pushed
      down.  The consequence of this is that the congestion window will not
      increase, or will increase very slowly, because the congestion
      window is only allowed to increase when there is a sufficient
      amount of data in flight.  The end final effect is then that the media
      bitrate increases very slowly or not at all.

   o  Reverse (feedback) path congestion: Especially in transport over
      buffer-bloated networks, the one way one-way delay in the reverse
      direction can jump due to congestion.  The effect of this is that the
      acknowledgements are delayed with the result that delayed, and the self-
      clocking self-clocking is temporarily
      halted, even though the forward path is not congested.

   The send window is adjusted depending on qdelay and qdelay, its relation to the
   qdelay target target, and the relation between the congestion window and 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
   network.  For cases when qdelay is lower than the qdelay_target, a
   more relaxed rule is applied.  This allows the bitrate to increase
   quickly when no congestion is detected while still being able to give
   a
   exhibit stable behavior in congested situations.

   The send window is given by the relation between the adjusted
   congestion window and the amount of bytes in flight according to the
   pseudo code
   pseudocode below.

   <CODE BEGINS>
   calculate_send_window(qdelay, qdelay_target)
     # send window is computed differently depending on congestion level
     if (qdelay <= qdelay_target)
       send_wnd = cwnd+MSS-bytes_in_flight cwnd + MSS - bytes_in_flight
     else
       send_wnd = cwnd-bytes_in_flight cwnd - bytes_in_flight
     end
   <CODE ENDS>

   The send window is updated whenever an RTP packet is transmitted or
   an RTCP feedback messaged is received.

4.1.2.6.  Packet pacing Pacing

   Packet pacing is used in order to mitigate coalescing i.e. that coalescing, i.e., when
   packets are transmitted in bursts, with the increased risk risks of more increased jitter
   and potentially increased packet loss.  Packet pacing also mitigates
   possible issues with queue overflow due to key-frame generation in
   video coders.  The time interval between consecutive packet
   transmissions is enforced to be greater than or equal to or higher than t_pace t_pace, where t_pace is
   given by the equations below :

      <CODE BEGINS>
      pace_bitrate = max (RATE_PACE_MIN, cwnd* cwnd * 8 / s_rtt)
      t_pace = rtp_size * 8 / pace_bitrate
      <CODE ENDS>

   rtp_size is the size of the last transmitted RTP packet, and s_rtt is
   the smoothed round trip time.  RATE_PACE_MIN is the minimum pacing
   rate.

4.1.2.7.  Resuming fast increase Fast Increase Mode

   Fast increase mode can resume in order to speed up the bitrate
   increase in
   case if congestion abates.  The condition to resume fast increase
   mode (in_fast_increase = true) is that qdelay_trend is less than
   QDELAY_TREND_LO for T_RESUME_FAST_INCREASE seconds or more.

4.1.2.8.  Stream prioritization Prioritization

   The SCReAM algorithm makes a good distinction between network
   congestion control and the media rate control.  This is easily extended
   to many streams, in which case streams -- RTP packets from two or more RTP queues are
   scheduled at the rate permitted by the network congestion control.

   The scheduling can be done by means of a few different scheduling
   regimes.  For example example, the method applied for coupled congestion control
   specified in
   [I-D.ietf-rmcat-coupled-cc] [COUPLED-CC] can be used.  The  One implementation of SCReAM
   [SCReAM-CPP-implementation] use credit based uses credit-based scheduling.  In
   credit credit-
   based scheduling, credit is accumulated by queues as they wait for
   service and are is spent while the queues are being serviced.  For
   instance, if one queue is allowed to transmit 1000bytes, 1000 bytes, then a
   credit of 1000bytes 1000 bytes is allocated to the other unscheduled queues.
   This principle can be extended to weighted scheduling in which case scheduling, where the
   credit allocated to unscheduled queues depends on the relative
   weights.  The latter is also implemented in
   [SCReAM-CPP-implementation].

4.1.3.  Media rate control Rate Control

   The media rate control algorithm is executed at regular intervals intervals,
   indicated by 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, qdelay_trend is also considered in the media rate control
   in order 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(s) and a sufficient
   amount of data to send in order to keep the data path busy.  A  Setting
   the media rate control too
   cautious setting cautiously leads to possible under-utilization
   underutilization of network
   capacity leading to that capacity; this can cause the flow can to
   become starved out by other more opportunistic traffic.  On the other
   hand, a too aggressive setting it too aggressively leads to increased jitter.

   The target_bitrate is adjusted depending on the congestion state.
   The target bitrate can vary between a minimum value
   (TARGET_BITRATE_MIN) and a maximum value (TARGET_BITRATE_MAX).
   TARGET_BITRATE_MIN SHOULD be chosen set to a low enough value to avoid
   that prevent RTP
   packets become from becoming queued up when the network throughput is
   reduced.  The sender SHOULD also be equipped with a mechanism that
   discards RTP packets in cases where when the network throughput becomes very low and
   RTP packets are excessively delayed.

   For the overall bitrate adjustment, two network throughput estimates
   are computed :

   o  rate_transmit: The measured transmit bitrate.

   o  rate_ack: The ACKed bitrate, i.e. i.e., the volume of ACKed bits per
      second.

   Both estimates are updated every 200ms. 200 ms.

   The current throughput, current_rate, is computed as the maximum
   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
   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
   that can itself cause an unnecessary rate reduction.  To overcome this shortcoming;
   shortcoming, rate_ack is used as well.  This gives a more stable
   throughput estimate.

   The rate change behavior depends on whether a loss or ECN event has
   occurred and if whether the congestion control is in fast increase or not. mode.

   <CODE BEGINS>
   # The target_bitrate is updated at a regular interval according
   # to RATE_ADJUST_INTERVAL

   on loss:
      # Loss event detected
      target_bitrate = max(BETA_R* max(BETA_R * target_bitrate,
                           TARGET_BITRATE_MIN)
      exit
   on ecn_mark:
      # ECN event detected
      target_bitrate = max(BETA_ECN* max(BETA_ECN * target_bitrate,
                           TARGET_BITRATE_MIN)
      exit

   ramp_up_speed_t = min(RAMP_UP_SPEED, target_bitrate/2.0) target_bitrate / 2.0)
   scale_t = (target_bitrate - target_bitrate_last_max)/ target_bitrate_last_max) /
        target_bitrate_last_max
   scale_t = max(0.2, min(1.0, (scale_t*4)^2)) (scale_t * 4)^2))
   # min scale_t value 0.2 0.2, as the bitrate should be allowed to
   #  increase at least slowly --> avoid slowly. This prevents locking the rate to
   #  target_bitrate_last_max
   if (in_fast_increase = true)
      increment_t = ramp_up_speed_t*RATE_ADJUST_INTERVAL ramp_up_speed_t * RATE_ADJUST_INTERVAL
      increment_t *= scale_t
      target_bitrate += increment_t
   else
      current_rate_t = max(rate_transmit, rate_ack)
      # Compute a bitrate change
      delta_rate_t = current_rate_t*(1.0-PRE_CONGESTION_GUARD*
           queue_delay_trend)-TX_QUEUE_SIZE_FACTOR *rtp_queue_size current_rate_t * (1.0 - PRE_CONGESTION_GUARD *
           queue_delay_trend) - TX_QUEUE_SIZE_FACTOR * rtp_queue_size
      # Limit a positive increase if close to target_bitrate_last_max
      if (delta_rate_t > 0)
        delta_rate_t *= scale_t
        delta_rate_t =
          min(delta_rate_t,ramp_up_speed_t*RATE_ADJUST_INTERVAL)
          min(delta_rate_t, ramp_up_speed_t * RATE_ADJUST_INTERVAL)
      end
      target_bitrate += delta_rate_t
      # Force a slight reduction in bitrate if RTP queue
      #  builds up
      rtp_queue_delay_t = rtp_queue_size/current_rate_t rtp_queue_size / current_rate_t
      if (rtp_queue_delay_t > RTP_QDELAY_TH)
        target_bitrate *= TARGET_RATE_SCALE_RTP_QDELAY
      end
   end

   rate_media_limit_t =
      max(current_rate_t, max(rate_media,rtp_rate_median)) max(rate_media, rtp_rate_median))
   rate_media_limit_t *= (2.0-qdelay_trend_mem) (2.0 - qdelay_trend_mem)
   target_bitrate = min(target_bitrate, rate_media_limit_t)
   target_bitrate = min(TARGET_BITRATE_MAX,
      max(TARGET_BITRATE_MIN,target_bitrate))
      max(TARGET_BITRATE_MIN, target_bitrate))
   <CODE ENDS>

   In case of a loss event event, the target_bitrate is updated and the rate
   change procedure is exited.  Otherwise  Otherwise, the rate change procedure
   continues.  The rationale behind the rate reduction due to loss is
   that a congestion window reduction will take effect, and a rate
   reduction
   pro actively avoids proactively prevents RTP packets from being queued up when
   the transmit rate decreases due to the reduced congestion window.  A
   similar rate reduction happens when ECN events are detected.

   The rate update frequency is limited by RATE_ADJUST_INTERVAL, unless
   a loss event occurs.  The value is based on experimentation with real
   life
   real-life limitations in video coders taken into account
   [SCReAM-CPP-implementation].  A too short interval is shown to make
   the rate control loop in video coders more unstable, unstable; a too long
   interval makes the overall congestion control sluggish.

   When in fast increase state (in_fast_increase=true), mode (in_fast_increase = true), the bitrate
   increase is given by the desired ramp-up speed (RAMP_UP_SPEED) . (RAMP_UP_SPEED).  The
   ramp-up speed is limited when the target bitrate is low to avoid rate
   oscillation at low bottleneck bitrates.  The setting of RAMP_UP_SPEED
   depends on preferences, a preferences.  A high setting such as 1000kbps/s 1000 kbps/s makes it
   possible to quickly get high quality media, high-quality media; however, this is however at the
   expense of a increased jitter, which can manifest itself as e.g. choppy
   video rendering. rendering, for example.

   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 qdelay trend, thus it is sufficient that an increased congestion
   level is sensed by the network congestion control to limit the
   bitrate.  The target_bitrate_last_max is updated when congestion is
   detected.

   Finally

   Finally, the target_bitrate is enforced to be within the defined min and max values.

   The aware reader may notice the dependency on the qdelay in the
   computation of the target bitrate, bitrate; this manifests itself in the use
   of the qdelay_trend.  As these parameters are used also in the
   network congestion control control, one may suspect some odd interaction
   between the media rate control and the network congestion control,
   this control.
   This is in fact the case if the parameter PRE_CONGESTION_GUARD is set
   to a high value.  The use of qdelay_trend in the media rate control
   is solely to reduce jitter, jitter; the dependency can be removed by setting
   PRE_CONGESTION_GUARD=0, the
   PRE_CONGESTION_GUARD=0.  The effect is a somewhat faster larger rate
   increase after congestion, at the expense of increased jitter in
   congested situations.

4.2.  SCReAM Receiver

   The simple task of the SCReAM receiver is to feedback feed back
   acknowledgements of received packets and total ECN count to the
   SCReAM sender, in sender.  In addition, the receive time of the RTP packet with
   the highest sequence number is echoed back.  Upon reception of each
   RTP packet packet, the receiver MUST maintain enough information to send the
   aforementioned values to the SCReAM sender via a an RTCP transport transport-
   layer feedback message.  The frequency of the feedback message
   depends on the available RTCP bandwidth.  The requirements on the
   feedback elements and the feedback interval is described. are described below.

4.2.1.  Requirements on feedback elements Feedback Elements

   The following feedback elements are REQUIRED for the basic functionality
   in SCReAM.

   o  A list of received RTP packets.  This list SHOULD be sufficiently
      long to cover all received RTP packets.  This list can be realized
      with the Loss RLE report block (Run Length Encoding) Report Block in [RFC3611].

   o  A wall clock wall-clock timestamp corresponding to the received RTP packet
      with the highest sequence number is required in order to compute
      the qdelay.  This can be realized by means of the Packet Receipt
      Times Report Block in [RFC3611].  begin_seq MUST be set to the
      highest received (possibly wrapped around) sequence number, number (which has possibly wrapped
      around); end_seq MUST be set to begin_seq+1 % modulo 65536.  The
      timestamp clock MAY be set according to [RFC3611] i.e. [RFC3611], i.e., equal to
      the RTP timestamp clock.  Detailed individual packet receive times is
      are not necessary necessary, as SCReAM does currently not describe how this they
      can be used.

   The basic feedback needed for SCReAM involves the use of the Loss RLE
   report block
   Report Block and the Packet Receipt Times block defined Report Block as shown in
   Figure 2.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |V=2|P|reserved |   PT=XR=207   |             length            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              SSRC                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     BT=2      | rsvd. |  T=0  |         block length          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        SSRC of source                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          begin_seq            |             end_seq           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          chunk 1              |             chunk 2           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :                              ...                              :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          chunk n-1            |             chunk n           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     BT=3      | rsvd. |  T=0  |         block length          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        SSRC of source                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          begin_seq            |             end_seq           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |       Receipt time of packet begin_seq                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 2: Basic feedback message Feedback Message for SCReAM, based Based on RFC3611 RFC 3611

   In a typical use case, no more than four Loss RLE chunks are needed,
   thus the feedback message will be 44bytes. 44 bytes.  It is obvious from the
   figure
   Figure 2 that there is a lot of redundant information in the feedback
   message.  A more optimized feedback format, including the additional
   feedback elements listed below, could reduce the feedback message
   size a bit.

   Additional

   An additional feedback elements element that can improve the performance of
   SCReAM are: is:

   o  Accumulated number of ECN-CE marked ECN-CE-marked packets (n_ECN).  This  For
      instance, this can for
      instance be realized with the ECN Feedback Report Format
      in [RFC6679].  The given feedback report format is actually a slight
      overkill slightly
      overkill, as SCReAM would do quite well with only a counter that
      increments by one for each received packet with the ECN-CE code
      point
      codepoint set.  The more bulky format could nevertheless be useful for
      e.g
      for, e.g., ECN black-hole detection.

4.2.2.  Requirements on feedback intensity Feedback Intensity

   SCReAM benefits from a relatively frequent feedback.  It is RECOMMENDED
   that a SCReAM implementation follows the guidelines below.

   The feedback interval depends on the media bitrate.  At low bitrates bitrates,
   it is sufficient with a feedback interval of 100 to 400ms, 400 ms; while at
   high bitrates bitrates, a feedback interval of roughly 20ms 20 ms is to prefer, at preferred.  At
   very high bitrates, even shorter feedback intervals MAY be needed in
   order to keep the self-clocking in SCReAM working well.  One piece of
   evidence of a
   indication that feedback is too sparse feedback is that the SCReAM
   implementation cannot reach high bitrates, even in uncongested links.  A more
   More frequent feedback might solve this issue.

   The numbers above can be formulated as a feedback interval function
   that can be useful for the computation of the desired RTCP bandwidth.
   The following equation expresses the feedback rate:

      rate_fb = min(50,max(2.5,rate_media/10000)) min(50, max(2.5, rate_media / 10000))

   rate_media is the RTP media bitrate expressed in [bits/s], bps; rate_fb is the
   feedback rate expressed in [packets/s].  Converted packets/s.  Converting to feedback
   interval
   interval, we get:

      fb_int = 1.0/min(50,max(2.5,rate_media/10000)) 1.0 / min(50, max(2.5, rate_media / 10000))

   The transmission interval is not critical, this means that critical.  So, in the case of multi-stream multi-
   stream handling between two hosts, the feedback for two or more SSRCs
   synchronization sources (SSRCs) can be bundled to save UDP/IP overhead,
   overhead.  However, the final realized feedback interval SHOULD however not
   exceed 2*fb_int in such
   cases cases, meaning that a scheduled feedback
   transmission event should not be delayed more that than fb_int.

   SCReAM works with AVPF regular mode, mode; immediate or early mode is not
   required by SCReAM but can nonetheless be useful for e.g RTCP messages
   not directly related to SCReAM, such as those specified in [RFC4585].
   It is RECOMMENDED to use reduced size reduced-size RTCP [RFC5506] [RFC5506], where regular
   full compound RTCP transmission is controlled by trr-
   int trr-int as described
   in [RFC4585].

5.  Discussion

   This section covers a few discussion points points.

   o  Clock drift: SCReAM can suffer from the same issues with clock
      drift as is the case with LEDBAT [RFC6817].  Section  However, Appendix A.2
      in [RFC6817] however describes ways to mitigate issues with clock drift.

   o  Support for alternate ECN semantics: This specification adopts the
      proposal in [I-D.ietf-tcpm-alternativebackoff-ecn] [ALT-BACKOFF] to reduce the congestion window less
      when ECN based ECN-based congestion events are detected.  Future work on Low Loss
      Loss, Low Latency for Scalable throughput (L4S) may lead to
      updates in a future RFC document that describes SCReAM support for
      L4S.

   o  A new RFC4585 transport layer transport-layer feedback message (as specified in RFC 4585)
      could to be standardized if the use of the already existing RTCP
      extensions as described in Section 4.2 is not deemed sufficient.

   o  The target bitrate given by SCReAM depicts is the bitrate including the
      RTP and FEC Forward Error Correction (FEC) overhead.  The media
      encoder SHOULD take 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 the overhead
      overhead, as the SCReAM algorithm will inherently compensate for
      moderate errors.  Under-compensation of  Under-compensating for the overhead has the
      effect of increasing jitter jitter, while
      overcompensation overcompensating will have the effect of causing cause the
      bottleneck link to become under-utilized.

7. underutilized.

6.  Suggested experiments Experiments

   SCReAM has been evaluated in a number of different ways, most of the
   evaluation has been mostly in a
   simulator.  The OpenWebRTC implementation work ([OpenWebRTC] and
   [SCReAM-implementation]) involved extensive testing with artificial
   bottlenecks with varying bandwidths and using two different video
   coders (OpenH264 and VP9),
   the experience of this lead to VP9).

   Preferably, further improvements of the media rate
   control logic.

   Further experiments are preferably will be done by means of
   implementation in real clients and web browsers.  RECOMMENDED
   experiments are:

   o  Trials with various access technologies: EDGE/3G/4G, WiFi, Wi-Fi, DSL.
      Some experiments have already been carried out with LTE access, access;
      see e.g. [SCReAM-CPP-implementation] and
      [SCReAM-implementation-experience]
      [SCReAM-implementation-experience].

   o  Trials with different kinds of media: Audio, Video, slide show video, slideshow
      content.  Evaluation of multi stream multi-stream handling in SCReAM.

   o  Evaluation of functionality of competing flows the compensation
      mechanism: mechanism when
      there are competing flows: Evaluate how SCReAM performs with
      competing TCP like TCP-like traffic and to what extent the compensation for
      competing flows compensation causes self-inflicted congestion.

   o  Determine proper parameters: A set of default parameters are given
      that makes SCReAM work over a reasonably large operation range,
      however for instance range.
      However, for very low or very high bitrates bitrates, it may be necessary
      to use different values for instance for the
      RAMP_UP_SPEED. RAMP_UP_SPEED, for instance.

   o  Experimentation with further improvements to the congestion window
      and media bitrate calculation.  [SCReAM-CPP-implementation]
      implements some optimizations, not described in this memo, that
      improve performance slightly.  Further experiments are likely to
      lead to more optimizations of the algorithm.

9.

7.  IANA Considerations

   There is currently no request to

   This document does not require any IANA

10. actions.

8.  Security Considerations

   The feedback can be vulnerable to attacks similar to those that can
   affect TCP.  It is therefore RECOMMENDED that the RTCP feedback is at
   least integrity protected.  Furthermore, as SCReAM is self-clocked, a
   malicious middlebox can drop RTCP feedback packets and thus cause the
   self-clocking in SCReAM to stall.  This  However, this attack is however mitigated
   by the minimum send rate maintained by SCReAM when no feedback is
   received.

12.

9.  References

12.1.

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
              July 2003, <https://www.rfc-editor.org/info/rfc3550>.

   [RFC3611]  Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed.,
              "RTP Control Protocol Extended Reports (RTCP XR)",
              RFC 3611, DOI 10.17487/RFC3611, November 2003,
              <https://www.rfc-editor.org/info/rfc3611>.

   [RFC4585]  Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
              "Extended RTP Profile for Real-time Transport Control
              Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
              DOI 10.17487/RFC4585, July 2006,
              <https://www.rfc-editor.org/info/rfc4585>.

   [RFC5506]  Johansson, I. and M. Westerlund, "Support for Reduced-Size
              Real-Time Transport Control Protocol (RTCP): Opportunities
              and Consequences", RFC 5506, DOI 10.17487/RFC5506, April
              2009, <https://www.rfc-editor.org/info/rfc5506>.

   [RFC6298]  Paxson, V., Allman, M., Chu, J., and M. Sargent,
              "Computing TCP's Retransmission Timer", RFC 6298,
              DOI 10.17487/RFC6298, June 2011,
              <https://www.rfc-editor.org/info/rfc6298>.

   [RFC6817]  Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind,
              "Low Extra Delay Background Transport (LEDBAT)", RFC 6817,
              DOI 10.17487/RFC6817, December 2012,
              <https://www.rfc-editor.org/info/rfc6817>.

12.2.  Informative References

   [I-D.ietf-rmcat-coupled-cc]
              Islam, S., Welzl, M., and S. Gjessing, "Coupled congestion
              control for RTP media", draft-ietf-rmcat-coupled-cc-07
              (work in progress), September 2017.

   [I-D.ietf-rmcat-wireless-tests]
              Sarker, Z., Johansson, I., Zhu, X., Fu, J., Tan, W., and
              M. Ramalho, "Evaluation Test Cases for Interactive Real-
              Time Media over Wireless Networks", draft-ietf-rmcat-
              wireless-tests-04 (work

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in progress), RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017.

   [I-D.ietf-tcpm-alternativebackoff-ecn] 2017, <https://www.rfc-editor.org/info/rfc8174>.

9.2.  Informative References

   [ALT-BACKOFF]
              Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst,
              "TCP Alternative Backoff with ECN (ABE)", draft-ietf-tcpm-
              alternativebackoff-ecn-02 (work Work in progress), October
              Progress, draft-ietf-tcpm-alternativebackoff-ecn-04,
              November 2017.

   [I-D.ietf-tcpm-rack]
              Cheng, Y., Cardwell, N.,

   [COUPLED-CC]
              Islam, S., Welzl, M., and N. Dukkipati, "RACK: a time-
              based fast loss detection algorithm S. Gjessing, "Coupled congestion
              control for TCP", draft-ietf-
              tcpm-rack-02 (work RTP media", Work in progress), March Progress, draft-ietf-
              rmcat-coupled-cc-07, September 2017.

   [LEDBAT-delay-impact]
              Ros, D. and M. Welzl, "Assessing LEDBAT's Delay Impact, Impact",
              IEEE communications
              letters, vol. Communications Letters, Vol. 17, no. No. 5, May 2013",
              DOI 10.1109/LCOMM.2013.040213.130137, May 2013,
              <http://home.ifi.uio.no/michawe/research/publications/
              ledbat-impact-letters.pdf>.

   [OpenWebRTC]
              "Open WebRTC project.", <http://www.openwebrtc.io/>.
              Ericsson Research, "OpenWebRTC",
              <http://www.openwebrtc.org>.

   [Packet-conservation]
              Jacobson, V., "Congestion Avoidance and Control, Control", ACM
              SIGCOMM Computer Communication Review 1988", Review,
              DOI 10.1145/52325.52356, August 1988.

   [QoS-3GPP]
              TS 23.203, 3GPP., 3GPP, "Policy and charging control architecture", June 2011, <http://www.3gpp.org/ftp/specs/
              archive/23_series/23.203/23203-990.zip>. 3GPP TS
              23.203, July 2017,
              <http://www.3gpp.org/ftp/specs/archive/23_series/23.203/>.

   [RACK]     Cheng, Y., Cardwell, N., and N. Dukkipati, "RACK: a time-
              based fast loss detection algorithm for TCP", Work in
              Progress, draft-ietf-tcpm-rack-02, March 2017.

   [RFC6679]  Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P.,
              and K. Carlberg, "Explicit Congestion Notification (ECN)
              for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August
              2012, <https://www.rfc-editor.org/info/rfc6679>.

   [RFC7478]  Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real-
              Time Communication Use Cases and Requirements", RFC 7478,
              DOI 10.17487/RFC7478, March 2015,
              <https://www.rfc-editor.org/info/rfc7478>.

   [RFC7661]  Fairhurst, G., Sathiaseelan, A., and R. Secchi, "Updating
              TCP to Support Rate-Limited Traffic", RFC 7661,
              DOI 10.17487/RFC7661, October 2015,
              <https://www.rfc-editor.org/info/rfc7661>.

   [RFC7942]  Sheffer, Y. and A. Farrel, "Improving Awareness of Running
              Code: The Implementation Status Section", BCP 205,
              RFC 7942, DOI 10.17487/RFC7942, July 2016,
              <https://www.rfc-editor.org/info/rfc7942>.

   [SCReAM-CPP-implementation]
              "C++ Implementation of SCReAM",
              Ericsson Research, "SCReAM - Mobile optimised congestion
              control algorithm",
              <https://github.com/EricssonResearch/scream>.

   [SCReAM-implementation]
              "SCReAM Implementation",
              Ericsson Research, "OpenWebRTC specific GStreamer
              plugins", <https://github.com/EricssonResearch/
              openwebrtc-gst-plugins>.

   [SCReAM-implementation-experience]
              Sarker, Z. and I. Johansson, "Updates on SCReAM : SCReAM: An
              implementation experience", November 2015,
              <https://www.ietf.org/proceedings/94/slides/
              slides-94-rmcat-8.pdf>.

   [TFWC]     University College London,     Choi, S. and M. Handley, "Fairer TCP-Friendly Congestion
              Control Protocol for Multimedia Streaming", Streaming Applications",
              DOI 10.1145/1364654.1364717, December 2007,
              <http://www-dept.cs.ucl.ac.uk/staff/M.Handley/papers/
              tfwc-conext.pdf>.

8.

   [WIRELESS-TESTS]
              Sarker, Z., Johansson, I., Zhu, X., Fu, J., Tan, W., and
              M. Ramalho, "Evaluation Test Cases for Interactive Real-
              Time Media over Wireless Networks", Work in Progress,
              draft-ietf-rmcat-wireless-tests-04, May 2017.

Acknowledgements

   We would like to thank the following persons people for their comments,
   questions
   questions, and support during the work that led to this memo: Markus
   Andersson, Bo Burman, Tomas Frankkila, Frederic Gabin, Laurits Hamm,
   Hans Hannu, Nikolas Hermanns, Stefan Haakansson, Erlendur Karlsson,
   Daniel Lindstroem, Mats Nordberg, Jonathan Samuelsson, Rickard
   Sjoeberg, Robert Swain, Magnus Westerlund, and Stefan Aalund.  Many
   additional thanks to RMCAT chairs Karen E. E. Nielsen and Mirja
   Kuehlewind for patiently reading, suggesting improvements and also
   for asking all the difficult but necessary questions.  Thanks to
   Stefan Holmer, Xiaoqing Zhu, Safiqul Islam Islam, and David Hayes for the
   additional review of this document.  Thanks to Ralf Globisch for
   taking time to try out SCReAM in his challenging low bitrate low-bitrate use
   cases, Robert Hedman for finding a few additional flaws in the
   running code, and Gustavo Garcia and 'miseri' for code contributions.

Authors' Addresses

   Ingemar Johansson
   Ericsson AB
   Laboratoriegraend 11
   Luleaa  977 53
   Sweden

   Phone: +46 730783289
   Email: ingemar.s.johansson@ericsson.com

   Zaheduzzaman Sarker
   Ericsson AB
   Laboratoriegraend 11
   Luleaa  977 53
   Sweden

   Phone: +46 761153743
   Email: zaheduzzaman.sarker@ericsson.com