RMCAT WG                                                    I. Johansson
Internet-Draft                                                 Z. Sarker
Intended status: Experimental                                Ericsson AB
Expires: February 16, May 18, 2017                               August 15,                                  November 14, 2016

              Self-Clocked Rate Adaptation for Multimedia


   This memo describes a rate adaptation algorithm for conversational
   media services such as video.  The solution conforms to the packet
   conservation principle and uses a hybrid loss and delay based
   congestion control algorithm.  The algorithm is evaluated over both
   simulated Internet bottleneck scenarios as well as in a LTE (Long Long Term Evolution)
   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 is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents 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 February 16, May 18, 2017.

Copyright Notice

   Copyright (c) 2016 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
   (http://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
     1.1.  Wireless (LTE) access properties  . . . . . . . . . . . .   3
     1.2.  Why is it a self-clocked algorithm? . . . . . . . . . . .   4
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Overview of SCReAM Algorithm  . . . . . . . . . . . . . . . .   4
     3.1.  Network Congestion Control  . . . . . . . . . . . . . . .   7   8
     3.2.  Sender Transmission Control . . . . . . . . . . . . . . .   7   8
     3.3.  Media Rate Control  . . . . . . . . . . . . . . . . . . .   7   8
   4.  Detailed Description of SCReAM  . . . . . . . . . . . . . . .   8   9
     4.1.  SCReAM Sender . . . . . . . . . . . . . . . . . . . . . .   8   9
       4.1.1.  Constants and Parameter values  . . . . . . . . . . .   9  Constants . . . . . . . . . . . . . . . . . . . .   9  10  State variables . . . . . . . . . . . . . . . . .  10  11
       4.1.2.  Network congestion control  . . . . . . . . . . . . .  12  13  Congestion window update  . . . . . . . . . . . .  15  16  Competing flows compensation  . . . . . . . . . .  17  18  Lost packets packet detection . . . . . . . . . . . . .  19 .  20  Send window calculation . . . . . . . . . . . . .  19  20  Resuming fast increase  . . . . . . . . . . . . .  20  21
       4.1.3.  Media rate control  . . . . . . . . . . . . . . . . .  20  21  FEC and packet overhead considerations  . . . . .  23  24
     4.2.  SCReAM Receiver . . . . . . . . . . . . . . . . . . . . .  24  25
   5.  Discussion  . . . . . . . . . . . . . . . . . . . . . . . . .  24  25
   6.  Implementation status . . . . . . . . . . . . . . . . . . . .  24  25
     6.1.  OpenWebRTC  . . . . . . . . . . . . . . . . . . . . . . .  25  26
     6.2.  A C++ Implementation of SCReAM  . . . . . . . . . . . . .  25  27
   7.  Suggested experiments . . . . . . . . . . . . . . . . . . . .  26  27
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  26  28
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  27  28
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  27  28
   11. Change history  . . . . . . . . . . . . . . . . . . . . . . .  27  28
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  28  29
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  28  29
     12.2.  Informative References . . . . . . . . . . . . . . . . .  28  30
   Appendix A.  Additional information . . . . . . . . . . . . . . .  30  32
     A.1.  Stream prioritization . . . . . . . . . . . . . . . . . .  30  32
     A.2.  Computation of autocorrelation function . . . . . . . . .  31  32
     A.3.  Sender transmission control and packet pacing . . . . . .  31  33
     A.4.  RTCP feedback considerations  . . . . . . . . . . . . . .  31  33
       A.4.1.  Requirements on feedback elements . . . . . . . . . .  32  33
       A.4.2.  Requirements on feedback intensity  . . . . . . . . .  34  35
     A.5.  Q-bit semantics (source quench) . . . . . . . . . . . . .  34  36
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  35  37

1.  Introduction

   Congestion in the Internet occurs when the transmitted bitrate is
   higher than the available bandwidth capacity over a given transmission path.
   Applications that are deployed in the Internet must have employ congestion
   control schemes in place not only for the robustness of the service
   that it provides but also
   control, to ensure the function of achieve robust performance and to avoid congestion
   collapse in the currently
   deployed Internet.  Interactive realtime communication imposes
   a lot of requirements on the transport, therefore a robust, efficient
   rate adaptation for all access types is an important part of
   interactive realtime communications as the transmission channel
   bandwidth may 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
   a rate adaptation solution for interactive realtime media, such as
   WebRTC, must be both quick and be able to operate over a large span range
   in available channel bandwidth. capacity.  This memo describes a solution,named SCReAM (Self-Clocked Rate
   Adaptation for Multimedia), a solution that is based on the self-clocking self-
   clocking principle of TCP and uses techniques similar to what is used
   in a new delay the LEDBAT based rate adaptation algorithm, LEDBAT algorithm [RFC6817].  SCReAM is
   not entirely self-clocked as it augments self-clocking with pacing
   and a minimum send rate.

1.1.  Wireless (LTE) access properties

   [I-D.ietf-rmcat-wireless-tests] describes the complications that can
   be observed in wireless environments.  Wireless access such as LTE
   can typically not guarantee a given bandwidth, this is true
   especially for default bearers.  The network throughput may vary
   considerably for instance in cases where the wireless terminal is
   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

   Unlike wireline bottlenecks with large statistical 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 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 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 flow in that bearer needs to reduce
   the sending rate quite quickly (in (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 algorithm provides with algorithms provide a benefit over the
   rate based counterparts in that the former consists of two
   parts; the adaptation

   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 delay variations) and; the variations).

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

   A rate based congestion control 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 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

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC2119 [RFC2119]

3.  Overview of SCReAM Algorithm

   The core SCReAM algorithm has similarities to the concepts of self-
   clocking used in TFWC [TFWC] and follows the packet conservation
   principle.  The packet conservation principle is described as an
   important key-factor behind the protection of networks from
   congestion [PACKET_CONSERVATION]. [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 packets.  The sender keeps a
   list of transmitted packets, their respective sizes and the time they
   were transmitted.  This information is used to determine the amount 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.  All this
   implements a congestion control that follows the packet conservation
   principle.  The fact that SCReAM follows the packet conservation
   principle, makes it as safe to deploy as a congestion control
   algorithm for the Internet as TCP and its most commonly used
   congestion control algorithms are.  No additional circuit breaker
   mechanisms are necessary with SCReAM as the ACK-clocking
   automatically falls back to a very low transmission rate (1 RTP
   packet/200ms) when the acknowledgements no longer arrive at the
   sender.  Furthermore, high packet loss rates reduces the congestion
   value to very low values and thus a low transmission rate.

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

   1.  There is always a certain probability that SCReAM is short of
       data to transmit, which means that the network queue will run
       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 and the capacity is 10Mbps then
       the network queue will run empty.

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

   o  Congestion window validation techniques.  These are similar in
      action as the method described in [RFC7661].  Congestion window
      validation ensures that the congestion window is limited by the
      amount of
      actual number bytes in flight, this is important especially in the
      context of 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], this to avoid excessive delays in the
      cases where e.g. wireless throughput has decreased during a period
      where the output bitrate from the media coder has been low, for
      instance due to inactivity.  Furthermore, this memo allows for
      more relaxed rules for when the congestion window is allowed to
      grow, this is necessary as the variable output bitrate generally
      means that the congestion window is often under-utilized.

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

   o  A delay qdelay trend is computed for earlier detection of incipient
      congestion and as a 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 delay qdelay target for better performance when competing
      with other loss based congestion controlled flows.

   The above mentioned features will be described in more detail in
   sections Section 3.1 to Section 3.3.

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

                  Figure 1: SCReAM sender functional view

   The SCReAM algorithm constitutes mainly consists of three main parts: network congestion
   control, sender transmission 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 algorithm
   is very simple in 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, uses techniques similar to
   LEDBAT [RFC6817] to measure the queuing delay, also termed qdelay in
   this memo for brevity.  Similar to qdelay.  As is the case with LEDBAT,
   it is not necessary to use synchronized clocks in sender and receiver
   in order to compute the
   queuing delay. qdelay.  It is however necessary that they
   use the same clock frequency, or that the clock frequency at the
   receiver can be inferred reliably by the sender.

   The SCReAM sender calculates the congestion window based on the
   feedback from the SCReAM receiver.  The congestion window is allowed
   to increase if the qdelay is below a predefined qdelay target,
   otherwise the congestion window decreases.  The qdelay delay target is
   typically set to 50-100ms.  This ensures that the queuing delay is
   kept low.  The reaction to loss or ECN events leads to an instant
   reduction of CWND.  Note that the source rate limited nature of real
   time media such as video, typically means that the queuing delay will
   mostly be below the given delay target, this is contrary to the case
   where large files are transmitted using LEDBAT congestion control, in
   which case 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, rate
   given by the estimated link throughput, this has the effect that even throughput.  Even if the send window
   allows for the transmission of a number of packets, these packets are
   not transmitted immediately, but 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 up 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 frame queues increase rapidly such as in
   the case of a RAT (Radio Access Type) handover it 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 or simply that stale RTP packets are removed from the
   queue. quickly.  Frame skipping means that results in the frame rate is being
   temporarily reduced.  Which method to use is a design consideration choice and
   outside the scope of this algorithm description.

4.  Detailed Description of SCReAM

4.1.  SCReAM Sender

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

   A SCReAM sender implements media rate control and a 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 (a.k.a (or stream) is used.  Multiple
   media sources are also supported in the design,  A
   transmission scheduler (not shown in that case the
   sender transmission control will include a transmission scheduler. figure) is added to support
   multiple streams.  The transmission scheduler can then enforce the differing
   priorities for between the
   different streams and then 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 controls provides a target rate for the media bitrate encoder (3).  The
   RTP packets are picked from the RTP queue (for multiple flows from
   each RTP queue based on some defined priority order or simply in a
   round robin fashion) (4) by the sender transmission controller.  The
   sender transmission controller (in case of multiple flows a
   transmission scheduler) takes care of sends the transmission of RTP packets, to be
   written packets to the UDP socket (5).
   In the general case all media must go through the sender transmission
   controller and is allowed to be
   transmitted if limited so that the number of bytes in flight is
   less than the congestion window.  RTCP packets are received (6) and
   the information about 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

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

   The recommended values values, within (), for the constants are deduced from

     Target value for the minimum qdelay.

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

     Averaging factor for qdelay_fraction_avg.

     Averaging factor for qdelay_fraction_avg.

     Headroom for the limitation of CWND.

   GAIN (1.0)
     Gain factor for congestion window adjustment.

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

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

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

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

     Interval between media bitrate adjustments.

     Min target bitrate [bps].

     Max target bitrate [bps].

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

     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 media coder
     characteristics, experiments with H264 and VP8 have however given indicate that 0.1 is
     a suitable value.  See [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 media coder characteristics, experiments
     with H264 and VP8 have however given indicate that 1.0 is a suitable value.  See
     [SCReAM-implementation-experience] for evaluation of a real

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

   TARGET_RATE_SCALE_RTP_QDELAY (0.95)  Target rate scale when RTP queue
     qdelay threshold exceeded. exceeds.

   QDELAY_TREND_LO (0.2)  Threshold value for qdelay_trend.

   T_RESUME_FAST_INCREASE  Time span until fast increase can be resumed,
     given that the qdelay_trend is below QDELAY_TREND_LO.  State variables

   The values within () 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.  The qdelay target is allowed to
     vary between QDELAY_TARGET_LO and QDELAY_TARGET_HI.

   qdelay_fraction_avg (0.0)
     EWMA filtered fractional qdelay.

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

   qdelay_trend (0.0)
     qdelay trend, indicates incipient congestion.

   qdelay_trend_mem (0.0)
     Low pass filtered version of qdelay_trend.

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

   min_cwnd (2*MSS)
     Minimum congestion window.

   in_fast_increase (true)
     True if in fast increase state.

   cwnd (min_cwnd)
     Congestion window.

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

   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 point i.e 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.

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

   rtp_queue_size (0 bits)
     Size 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

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

   o  Computation of congestion window at the sender: Gives an upper
      limit to the number of bytes in flight i.e how many bytes that
      have been transmitted but not yet acknowledged. 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.

   Unlike TCP,

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

   The congestion control is however based on
   transmitted and acknowledged bytes.

   SCReAM uses the terminology "Bytes number of bytes in flight" flight (bytes_in_flight) which is computed as the
   sum of the sizes of the RTP packets ranging from the RTP packet most
   recently transmitted down to but not including the acknowledged
   packet with the highest sequence number.  This can be translated to
   the difference between the highest transmitted byte sequence number
   and the highest acknowledged byte sequence number.  As an example: If
   RTP packet with sequence number SN is transmitted and the last
   acknowledgement indicates SN-5 as the highest received sequence
   number then bytes in flight is computed as the sum of the size of RTP
   packets with sequence number SN-4, SN-3, SN-2, SN-1 and SN, it does
   not matter if for instance packet with sequence number SN-3 was lost,
   the size of RTP packet with sequence number SN-3 will still be
   considered in the computation of bytes_in_flight.

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

   The feedback from the receiver is assumed to consist of the following
   elements.  More details are found in Appendix A.4.

   o  A list of received RTP packets.

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

   o  Accumulated number of ECN-CE marked packets (n_ECN).

   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
   some smoothing occurs anyway as the computation of the CWND is in
   itself a low
   pass filter function.  A number of variables are updated 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 encouraged to look
   into the C++ code in [SCReAM-Cplusplus_Implementation] [SCReAM-CPP-implementation] for the details.

       qdelay_fraction_t = qdelay/qdelay_target
       #calculate moving average
       qdelay_fraction_avg = (1-QDELAY_WEIGHT)*qdelay_fraction_avg+
       # R is an autocorrelation function of qdelay_fraction_hist
       #  at lag K
       a = R(qdelay_fraction_hist,1)/R(qdelay_fraction_hist,0)
       #calculate qdelay trend
       qdelay_trend = min(1.0,max(0.0,a*qdelay_fraction_avg))
       #calculate a 'peak-hold' qdelay_trend, this gives a memory
       # of congestion in the past
       qdelay_trend_mem = max(0.99*qdelay_trend_mem, qdelay_trend)

   The qdelay fraction is sampled every 50ms and the last 20 samples are
   stored in a vector (qdelay_fraction_hist).  This vector is used in
   the computation of an qdelay trend that gives a value between 0.0 and
   1.0 depending on the estimated congestion level.  The prediction
   coefficient 'a' has positive values if qdelay shows an increasing
   trend, thus an indication of congestion is obtained before the qdelay
   target is reached.  The autocorrelation function 'R' is defined in
   Appendix A.2.  The prediction coefficient is further multiplied with
   qdelay_fraction_avg to reduce sensitivity to increasing qdelay when
   it is very small.  The 50ms sampling is a simplification and may have
   the effect that the same qdelay is sampled several times, this is does
   however not pose any problem a big issue as the vector is only used for to determine
   if the
   computation of qdelay_trend. 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

   A loss event is indicated if one or more RTP packets are declared
   missing.  The loss detection is described in Section  Once a
   loss event is detected, further detected lost RTP packets are ignored
   for a full smoothed round trip time, the intention of this is to
   limit the congestion window decrease to at most once per round trip.
   The congestion window backoff 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 is generally used to transmit whole files, which can be
   translated to an infinite source bitrate.  SCReAM on the other hand
   has a source which whose rate is limited to a value close to the available
   transmit rate and often below said that value, the effect of this is that
   SCReAM has less opportunity to grab free capacity than a TCP based
   file transfer.  To compensate for this it is necessary to let SCReAM
   reduce the congestion window slightly less 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, the intention of this is to limit the congestion
   window decrease to at most once per round trip.  The congestion
   window backoff back off due to an ECN event is deliberately smaller than if a
   loss event occurs.  This is in line with the idea outlined in
   [Khademi-alternative-backoff-ECN] to enable ECN marking thresholds
   lower than the corresponding packet drop thresholds.

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

     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)
         # No loss, so it is then an ECN mark
         cwnd = max(min_cwnd,cwnd*BETA_ECN)
       adjust_qdelay_target(qdelay) #compensating for competing flows

     # when no congestion event
     on acknowledgement(qdelay):
       adjust_qdelay_target(qdelay) #compensating for competing flows
       calculate_send_window(qdelay, qdelay_target)

   The methods are further described in detail below.  Congestion window update

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

   Pseudo code for the update of the congestion window is found below.


     # in fast increase ?
     if (in_fast_increase)
       if (qdelay_trend >= 0.2) QDELAY_TREND_TH)
         # incipient congestion detected, exit fast increase
         in_fast_increase = false
         # no congestion yet, increase cwnd if it
         #  is sufficiently used
         # an 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 > cwnd)
           cwnd = cwnd+bytes_newly_acked

     # not in fast increase phase
     # 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 <= cwnd)
       # no cwnd increase if window is underutilized
       # an additional slack of bytes_newly_acked is
       #  added to ensure that CWND growth occurs
       #  even when feedback is sparse
       cwnd_delta_t = 0;

     # 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)
     cwnd = max(cwnd, MIN_CWND)

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

   When in fast increase state, 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 additional slack is therefore added, given by the
   number of newly acked acknowledged bytes.

   The congestion window growth when in_fast_increase is false is
   dictated by the relation between qdelay and 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].  There are however a few differences.

   o  [RFC6817] specifies a constant GAIN, this specification however
      limits the gain when CWND is increased dependent on near
      congestion state and the relation to the last known max CWND

   o  [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 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 of the throughput after for example, idle periods.
   An additional MAX_BYTES_IN_FLIGHT_HEAD_ROOM allows for a slack, to
   allow for a certain amount of media coder output rate variability.  Competing flows compensation

   It is likely that a flow using SCReAM algorithm will have to share
   congested bottlenecks with other flows that use a more aggressive
   congestion control algorithm.  SCReAM takes care of such situations
   by adjusting the qdelay_target.

       qdelay_norm_t = qdelay / QDELAY_TARGET_LOW
       # 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
       oh_t = qdelay_norm_avg_t + sqrt(qdelay_norm_var_t)
       oh_t *= QDELAY_TARGET_LO
       if (loss_event_rate > 0.002)
         # Packet losses detected
         qdelay_target = 1.5*oh_t
         if (qdelay_norm_var_t < 0.2)
           # Reasonably safe to set target qdelay
           qdelay_target = oh_t
           # 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)
             # Decrease target delay slowly
             qdelay_target *= 0.9

       # Apply limits
       qdelay_target = min(QDELAY_TARGET_HI, qdelay_target)
       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
   change rapidly.  It is desired to avoid the case that the qdelay
   target is increased due to self-congestion, indicated by a changing
   qdelay and consequently an increased qdelay_norm_var_t.  Still it
   should 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 positives and negatives but negatives.  In the simulated LTE test
   cases it manages competing FTP flows reasonably well at the same time
   as it has proven to avoid generally avoiding accidental increased
   qdelay target relatively well increases in simulated LTE test cases. the qdelay target.  The
   algorithm can however accidentally increase the qdelay target and
   cause self-inflicted congestion in certain cases, cases.  It is therefore it
   recommended that the algorithm described in this section is
   recommended to turn turned
   off the algorithm if it is deemed unlikely that competing flows will occur over the same bottleneck.
   bottleneck  Lost packets packet detection

   Lost packets packet detection is based on the received sequence number list.
   A reordering window should be applied to avoid that packet reordering
   triggering loss events.
   The reordering window is specified as a time unit, similar to the
   ideas behind RACK (Recent ACKnowledgement) [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 higher sequence number was acknowledged.  Send window calculation

   The basic design principle behind packet transmission in SCReAM is to
   allow transmission only if the number of bytes in flight is less than
   the congestion window.  There are however two reasons why this strict
   rule will not work optimally:

   o  Bitrate variations: The media frame size is always varying to a
      larger or smaller extent.  A strict rule as the one given above
      will have the effect can lead to that the
      media bitrate will have difficulties to increase as the congestion
      window puts a too hard restriction on the media frame size
      variation.  This can lead to occasional queuing of RTP packets in
      the RTP packet queue that will further prevent bitrate increase.

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

   The send window is adjusted depending on qdelay and its relation to
   the qdelay 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 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 below.

   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
       send_wnd = cwnd-bytes_in_flight

   The send window is updated whenever an RTP packet is transmitted or
   an RTCP feedback messaged is received.  More details around sender
   transmission control and packet pacing is are found in Appendix A.3.  Resuming fast increase

   Fast increase can resume in order to speed up the bitrate increase in
   case congestion abates.  The condition to resume fast increase
   (in_fast_increase = true) is that qdelay_trend is less than

4.1.3.  Media rate control

   The media rate control algorithm is executed at regular intervals
   RATE_ADJUSTMENT_INTERVAL, with the exception of a prompt reaction to
   loss events.  The media rate control operates based on the size of
   the RTP packet send queue and observed loss events.  In addition,
   qdelay_trend is also considered in the media rate control, this control 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 too
   cautious setting leads to possible under-utilization of network
   capacity and that leading to the flow is being starved out by other, other more
   opportunistic traffic, on traffic.  On the other hand a too aggressive a setting
   leads to extra jitter. 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 to a low enough value to avoid
   RTP packets are being queued up when the network throughput becomes low.
   The sender should also be equipped with a mechanism that discards RTP
   packets in cases where 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
      time unit.

   Both estimates are updated every 200ms.

   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 may itself cause an unnecessary rate reduction.  To overcome
   this 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 the congestion control is in fast increase or not.

   # The target_bitrate is updated at a regular interval according

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

   ramp_up_speed_t = min(RAMP_UP_SPEED, target_bitrate/2.0)
   scale_t = (target_bitrate - target_bitrate_last_max)/
   scale_t = max(0.2, min(1.0, (scale_t*4)^2))
   # min scale_t value 0.2 as the bitrate should be allowed to
   #  increase at least slowly --> avoid locking the rate to
   #  target_bitrate_last_max
   if (in_fast_increase = true)
      increment_t = ramp_up_speed_t*RATE_ADJUST_INTERVAL
      increment_t *= scale_t
      target_bitrate += increment_t
      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
      # limit a positive increase if close to target_bitrate_last_max
      if (delta_rate_t > 0)
        delta_rate_t *= scale_t
        delta_rate_t =
      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
      if (rtp_queue_delay_t > 0.02) RTP_QDELAY_TH)
        target_bitrate *= 0.95 TARGET_RATE_SCALE_RTP_QDELAY

   rate_media_limit_t = max(current_rate_t, max(rate_media,rtp_rate_median))
   rate_media_limit_t *= (2.0-1.0*qdelay_trend_mem) (2.0-qdelay_trend_mem)
   target_bitrate = min(target_bitrate, rate_media_limit_t)
   target_bitrate = min(TARGET_BITRATE_MAX,

   In case of a loss event the target_bitrate is updated and the rate
   change procedure is exited.  Otherwise the rate change procedure
   continues.  The rationale behind the rate reduction due to loss is
   that a congestion window reduction will take effect, a rate reduction
   pro actively avoids that RTP packets are 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 limitations in video coders taken into account. account
   [SCReAM-implementation-experience].  A too short interval has is shown to
   make the video coder internal rate control loop more unstable, a too
   long interval makes the overall congestion control sluggish.

   When in fast increase state (in_fast_increase=true), the bitrate
   increase is given by the desired ramp-up speed (RAMP_UP_SPEED) . The
   ramp-up speed is limited when the target bitrate is low to avoid rate
   oscillation at low bottleneck bitrates.  The setting of RAMP_UP_SPEED
   depends on preferences, a high setting such as 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
   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

   In cases where input stimuli to the media encoder is static, for
   instance in "talking head" scenarios, the target bitrate is not
   always fully utilized.  This may cause undesirable oscillations in
   the target bitrate in the cases where the link throughput is limited
   and the media coder input stimuli changes between static and varying.
   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
   output bitrates, rate_media_limit.  A multiplier is applied to
   rate_media_limit, depending on congestion history.  The
   target_bitrate is then limited by this rate_media_limit.

   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, this manifests itself in the use
   of the qdelay_trend.  As these parameters are used also in the
   network congestion control one may suspect some odd interaction
   between the media rate control and the network congestion 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, the dependency can be removed by setting
   PRE_CONGESTION_GUARD=0, the effect is a somewhat faster rate increase
   after congestion, at the expense of more jitter. jitter in congested
   situations.  FEC and packet overhead considerations

   The target bitrate given by SCReAM depicts the bitrate including RTP
   and FEC overhead.  Therefore it is necessary that the media encoder
   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
   the overhead as the SCReAM algorithm will inherently compensate for
   moderate errors.  Under-compensation of the overhead has the effect
   that the
   of increasing jitter will increase somewhat while overcompensation will have the effect that of
   causing the bottleneck link becomes to become under-utilized.

4.2.  SCReAM Receiver

   The simple task of the SCReAM receiver is to feedback
   acknowledgements of received packets and total ECN count to the
   SCReAM sender, in addition, the receive time of the RTP packet with
   the highest sequence number is echoed back.  Upon reception of each
   RTP packet the receiver will simply must maintain enough information to send the
   aforementioned values to the SCReAM sender via a RTCP transport layer
   feedback message.  The frequency of the feedback message depends on
   the available RTCP bandwidth.  More details of the feedback and the
   frequency is found in Appendix A.4.

5.  Discussion

   This section covers a few discussion points

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

   o  Support for alternate ECN semantics: This specification adopts the
      proposal in [Khademi-alternative-backoff-ECN] to reduce the
      congestion window less when ECN based congestion events are
      detected.  Future work on Low Latency Low Loss for Scalable
      throughput (L4S) may lead to updates in a future RFC that
      describes SCReAM support for L4S.

6.  Implementation status

   [Editor's note: Please remove the whole section before publication,
   as well reference to RFC 6982]

   This section records the status of known implementations of the
   protocol defined by this specification at the time of posting of this
   Internet-Draft, and is based on a proposal described in [RFC6982].
   The description of implementations in this section is intended to
   assist the IETF in its decision processes in progressing drafts to
   RFCs.  Please note that the listing of any individual implementation
   here does not imply endorsement by the IETF.  Furthermore, no effort
   has been spent to verify the information presented here that was
   supplied by IETF contributors.  This is not intended as, and must not
   be construed to be, a catalog of available implementations or their
   features.  Readers are advised to note that other implementations may

   According to [RFC6982], "this will allow reviewers and working groups
   to assign due consideration to documents that have the benefit of
   running code, which may serve as evidence of valuable experimentation
   and feedback that have made the implemented protocols more mature.
   It is up to the individual working groups to use this information as
   they see it".

6.1.  OpenWebRTC

   The SCReAM algorithm has been implemented in the OpenWebRTC project
   [OpenWebRTC], an open source WebRTC implementation from Ericsson
   Research.  This SCReAM implementation is usable with any WebRTC
   endpoint using OpenWebRTC.

   o  Organization : Ericsson Research, Ericsson.

   o  Name : OpenWebRTC gst plug-in.

   o  Implementation link : The GStreamer plug-in code for SCReAM can be
      found at github repository [SCReAM-Implementation] [SCReAM-implementation] The wiki
      (https://github.com/EricssonResearch/openwebrtc/wiki) contains
      required information for building and using OpenWebRTC.

   o  Coverage : The code implements [I-D.ietf-rmcat-scream-cc]. the specification in this memo.
      The current implementation has been tuned and tested to adapt a
      video stream and does not adapt the audio streams.

   o  Implementation experience : The implementation of the algorithm in
      the OpenWebRTC has given great insight into the algorithm itself
      and its interaction with other involved modules such as encoder,
      RTP queue etc.  In fact it proves the usability of a self-clocked
      rate adaptation algorithm in the real WebRTC system.  The
      implementation experience has led to various algorithm
      improvements both in terms of stability and design.  The current
      implementation use an n_loss counter for lost packets indication,
      this is subject to change in later versions to a list of received
      RTP packets.

   o  Contact : irc://chat.freenode.net/openwebrtc

6.2.  A C++ Implementation of SCReAM

   o  Organization : Ericsson Research, Ericsson.

   o  Name : SCReAM.

   o  Implementation link : A C++ implementation of SCReAM is also available [SCReAM-Cplusplus_Implementation].
      at[SCReAM-CPP-implementation].  The code includes full support for
      congestion control, rate control and multi stream handling, it can
      be integrated in web clients given the addition of extra code to
      implement the RTCP feedback and RTP queue(s).  The code also
      includes a rudimentary implementation of a simulator that allows
      for some initial experiments.

   o  Coverage : The code implements [I-D.ietf-rmcat-scream-cc] the specification in this memo.

   o  Contact : ingemar.s.johansson@ericsson.com

7.  Suggested experiments

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

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

   o  Trials with various access technologies: EDGE/3G/4G, WiFi, DSL.

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

   o  Evaluation of functionality of competing flows compensation
      mechanism: Evaluate how SCReAM performs with competing TCP like
      traffic and to what extent the 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 for very low or very high bitrates it may be
      necessary to use different values for instance for the

8.  Acknowledgements

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

9.  IANA Considerations

   A new RFC4585 transport layer feedback message needs may to be
   standardized. standardized
   if the use of the already existing RTCP extensions as described in
   Appendix A.4 is not deemed sufficient.

10.  Security Considerations

   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 attack is however mitigated
   by the minimum send rate maintained by SCReAM when no feedback is

11.  Change history

   A list of changes:

   o  WG-06 to WG-07: Updated based on WGLC review by David Hayes and
      Safiqul Islam

   o  WG-05 to WG-06: Added list of suggested experiments

   o  WG-04 to WG-05: Congestion control and rate control simplified

   o  WG-03 to WG-04: Editorial fixes

   o  WG-02 to WG-03: Review comments from Stefan Holmer and Xiaoqing
      Zhu addressed, owd changed to qdelay for clarity.  Added appendix
      section with RTCP feedback requirements, including a suggested
      basic feedback format based Loss RLE report block and the Packet
      Receipt Times blocks in [RFC3611].  Loss detection added as a
      section.  Transmission scheduling and packet pacing explained in
      appendix.  Source quench semantics added to appendix.

   o  WG-01 to WG-02: Complete restructuring of the document.  Moved
      feedback message to a separate draft.

   o  WG-00 to WG-01 : Changed the Source code section to Implementation
      status section.

   o  -05 to WG-00 : First version of WG doc, moved additional features
      section to Appendix.  Added description of prioritization in
      SCReAM.  Added description of additional cap on target bitrate

   o  -04 to -05 : ACK vector is replaced by a loss counter, PT is
      removed from feedback, references to source code added

   o  -03 to -04 : Extensive changes due to review comments, code
      somewhat modified, frame skipping made optional

   o  -02 to -03 : Added algorithm description with equations, removed
      pseudo code and simulation results

   o  -01 to -02 : Updated GCC simulation results

   o  -00 to -01 : Fixed a few bugs in example code

12.  References

12.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,

   [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, <http://www.rfc-editor.org/info/rfc3550>.

   [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,

   [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, <http://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,

   [RFC6817]  Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind,
              "Low Extra Delay Background Transport (LEDBAT)", RFC 6817,
              DOI 10.17487/RFC6817, December 2012,

12.2.  Informative References

              Zanaty, M., Singh, V., Nandakumar, S., and Z. Sarker, "RTP
              Application Interaction with Congestion Control", draft-
              ietf-rmcat-app-interaction-01 (work in progress), October

              Zanaty, M., Singh, V., Nandakumar, S., and Z. Sarker,
              "Congestion Control and Codec interactions in RTP
              Applications", draft-ietf-rmcat-cc-codec-interactions-02
              (work in progress), March 2016.

              Islam, S., Welzl, M., and S. Gjessing, "Coupled congestion
              control for RTP media", draft-ietf-rmcat-coupled-cc-03 draft-ietf-rmcat-coupled-cc-04
              (work in progress), July October 2016.

              Johansson, I. and Z. Sarker, "Self-Clocked Rate Adaptation
              for Multimedia", draft-ietf-rmcat-scream-cc-05 draft-ietf-rmcat-scream-cc-06 (work in
              progress), June August 2016.

              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-02 (work in progress), May 2016.

              "TCP Alternative Backoff

              "Alternative Backoff: Achieving Low Latency and High
              Throughput with ECN (ABE)", and AQM , CAIA Technical Report",

              "Assessing LEDBAT's Delay Impact, IEEE communications
              letters, vol. 17, no. 5, May 2013", May 2013,

              "Open WebRTC project.", <http://www.openwebrtc.io/>.


              "Congestion Avoidance and Control", Control, ACM SIGCOMM Computer
              Communication Review 1988", 1988.

              TS 23.203, 3GPP., "Policy and charging control
              architecture", June 2011, <http://www.3gpp.org/ftp/specs/

   [RACK]     "RACK: a time-based fast loss detection algorithm for
              TCP", <https://http://tools.ietf.org/id/

   [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,

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

   [RFC6982]  Sheffer, Y. and A. Farrel, "Improving Awareness of Running
              Code: The Implementation Status Section", RFC 6982,
              DOI 10.17487/RFC6982, July 2013,

   [RFC7661]  Fairhurst, G., Sathiaseelan, A., and R. Secchi, "Updating
              TCP to Support Rate-Limited Traffic", RFC 7661,
              DOI 10.17487/RFC7661, October 2015,


              "C++ Implementation of SCReAM",


              "SCReAM Implementation",

              "Updates on SCReAM : An implementation experience",

   [TFWC]     University College London, "Fairer TCP-Friendly Congestion
              Control Protocol for Multimedia Streaming", December 2007,

Appendix A.  Additional information

A.1.  Stream prioritization

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

   The scheduling can be done by means of a few different scheduling
   regimes.  For example the method applied in
   [I-D.ietf-rmcat-coupled-cc] can be used.  The implementation of
   SCReAM [SCReAM-CPP-implementation] use something that is referred to as credit based scheduling.

   Credit  In
   credit based scheduling is for instance implemented in IEEE 802.17.
   The short description is that scheduling, credit is accumulated by queues as they wait
   for service and are spent while the queues are being services. serviced.  For
   instance, if one queue is allowed to transmit 1000bytes, then a
   credit of 1000bytes is allocated to the other unscheduled queues.
   This principle can be extended to weighted scheduling in which case
   the credit allocated to unscheduled queues depends on the weight
   allocation. relative

A.2.  Computation of autocorrelation function

   The autocorrelation function is computed over a vector of values.

   Let x be a vector constituting N values, the biased autocorrelation
   function for a given lag=k for the vector x is given by .

      R(x,k) = SUM x(n)*x(n+k)

A.3.  Sender transmission control and packet pacing

   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
   explained in Section the send window is updated whenever an
   RTP packet is transmitted or RTCP feedback is received, the packet
   transmission rate is however restricted by means of packet pacing.

   Packet pacing is used in order to mitigate coalescing i.e i.e. that
   packets are transmitted in bursts, with the increased risk of more
   jitter and potentially increased packet loss.  The time interval
   between consecutive packet transmissions is enforced to be equal to
   or higher than t_pace where t_pace is given by the equations below :

      pace_bitrate = max (50000, (RATE_PACE_MIN, cwnd* 8 / s_rtt)
      t_pace = rtp_size * 8 / pace_bitrate

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

A.4.  RTCP feedback considerations

   This section describes the requirements on the RTCP feedback to make
   SCReAM function well.  Parts of this section may be moved to a
   separate draft.  First is described the requirements on the
   feedback elements, second is described the requirements on the
   feedback intensity to keep the SCReAM self-clocking and rate control
   loops function properly.

A.4.1.  Requirements on feedback elements

   SCReAM requires the following elements for its basic functionality,
   i.e. only including features that are strictly necessary in order to
   make SCReAM function.  ECN is not included as basic functionality as
   it regarded as an additional feature that is not strictly necessary
   even though it can improve quality of experience quite considerably.

   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 in [RFC3611].

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

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

        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 for SCReAM, based on RFC3611

   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
   from the figure 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 feedback elements that can improve the performance of
   SCReAM are:

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

   o  Source quench bit (Q): Makes it possible to request the sender to
      reduce its congestion window.  This is useful if WebRTC media is
      received from many hosts and it becomes necessary to balance the
      bitrates between the streams.  This can currently not be realized
      with any standardized feedback format, however the ECN counter can
      be artificially incremented, even though no ECN-CE marked packets
      are received to achieve a similar behavior.

A.4.2.  Requirements on feedback intensity

   SCReAM benefits from a relatively frequent feedback.  The feedback
   interval depends on the media bitrate.  At low bitrates it is
   sufficient with a feedback interval of 100 to 200ms, 400ms, while at high
   bitrates a feedback interval of ~20ms roughly 20ms is to prefer.

   The numbers above can be formulated as 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(5,rate_media/10000)) min(50,max(2.5,rate_media/10000))

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

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

   The transmission interval is not critical, this means that in the
   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
   realized feedback interval should however not exceed 2*fb_int in such
   cases meaning that a scheduled feedback transmission event should not
   be delayed more that fb_int.

   SCReAM works with AVPF regular mode, immediate or early mode is not
   required by SCReAM but may 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 RTCP [RFC5506]
   where regular full compound RTCP transmission is controlled by trr-
   int as described in [RFC4585].

A.5.  Q-bit semantics (source quench)

   The Q bit in the feedback is set by a receiver to signal that the
   sender should reduce the bitrate.  The sender will in response to
   this reduce the congestion window with the consequence that the video
   bitrate decreases.  A typical use case for source quench is when a
   receiver receives streams from sources located at different hosts and
   they all share a common bottleneck, typically it is difficult to
   apply any rate distribution signaling between the sending hosts.  The
   solution is then that the receiver sets the Q bit in the feedback to
   the sender that should reduce its rate, if the streams share a common
   bottleneck then the released bandwidth due to the reduction of the
   congestion window for the flow that had the Q bit set in the feedback
   will be grabbed by the other flows that did not have the Q bit set.
   This is ensured by the opportunistic behavior of SCReAM's congestion
   control.  The source quench will have no or little effect if the
   flows do not share the same bottleneck.

   The reduction in congestion window is proportional to the amount of
   SCReAM RTCP feedback with the Q bit set, the below steps outline how
   the sender should react to RTCP feedback with the Q bit set.  The
   reduction is done once per RTT.  Let :

   o  n = Number of received RTCP feedback messages in one RTT

   o  n_q = Number of received RTCP feedback messages in one RTT, with Q
      bit set.

   The new congestion window is then expressed as:

      cwnd = max(MIN_CWND, cwnd*(1.0-0.5*n_q/n))

   Note that CWND is adjusted at most once per RTT.  Furthermore The
   CWND increase should be inhibited for one RTT if CWND has been
   decreased as a result of Q bits set in the feedback.

   The required intensity of the Q-bit set in the feedback in order to
   achieve a given rate distribution depends on many factors such as
   RTT, video source material etc.  The receiver thus need to monitor
   the change in the received video bitrate on the different streams and
   adjust the intensity of the Q-bit accordingly.

Authors' Addresses

   Ingemar Johansson
   Ericsson AB
   Laboratoriegraend 11
   Luleaa  977 53

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

   Zaheduzzaman Sarker
   Ericsson AB
   Laboratoriegraend 11
   Luleaa  977 53

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