RMCAT WG                                                    I. Johansson
Internet-Draft                                                 Z. Sarker
Intended status: Experimental                                Ericsson AB
Expires: January 7, April 21, 2016                                    July 6,                                 October 19, 2015

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

Abstract

   This memo describes a rate adaptation algorithm for conversational
   video services.
   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
   Term Evolution) 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 January 7, April 21, 2016.

Copyright Notice

   Copyright (c) 2015 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  . . . . . . . . . . . . . . . . . . . . . . . .   2   3
     1.1.  Wireless (LTE) access properties  . . . . . . . . . . . .   3
     1.2.  Why is it a self-clocked algorithm? . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3   4
   3.  Overview of SCReAM Algorithm  . . . . . . . . . . . . . . . .   4
     3.1.  Network Congestion Control  . . . . . . . . . . . . . . . . . . .   4   7
     3.2.  Sender Transmission Scheduling . . Control . . . . . . . . . . . . . . .   5   7
     3.3.  Media Rate Control  . . . . . . . . . . . . . . . . . . .   5   7
   4.  Detailed Description of SCReAM  . . . . . . . . . . . . . . .   5   8
     4.1.  SCReAM Sender . . . . . . . . . . . . . . . . . . . . . .   5   8
       4.1.1.  Constants and Parameter values  . . . . . . . . . . .   7
       4.1.2.  Network congestion control  .   8
         4.1.1.1.  Constants . . . . . . . . . . . .  11
         4.1.2.1.  Congestion window update . . . . . . . .   8
         4.1.1.2.  State variables . . . .  12
         4.1.2.2.  Transmission scheduling . . . . . . . . . . . . .  16
       4.1.3.  Video rate  10
       4.1.2.  Network congestion control  . . . . . . . . . . . . .  11
         4.1.2.1.  Updating bytes_newly_acked  . . . .  17
     4.2.  SCReAM Receiver . . . . . . .  14
         4.1.2.2.  Updating congestion window  . . . . . . . . . . .  14
         4.1.2.3.  Compensation for competing flows  . . .  19
   5.  Feedback Message . . . . .  16
         4.1.2.4.  Send window calculation . . . . . . . . . . . . .  17
         4.1.2.5.  Resuming fast increase  . . . .  20
   6.  Discussion . . . . . . . . .  18
       4.1.3.  Media rate control  . . . . . . . . . . . . . . . .  22
   7.  Conclusion .  18
         4.1.3.1.  FEC and packet overhead considerations  . . . . .  22
     4.2.  SCReAM Receiver . . . . . . . . . . . . . . . . . . . . .  22
   8.  Open issues
   5.  Discussion  . . . . . . . . . . . . . . . . . . . . . . . . .  22
   9.
   6.  Implementation status . . . . . . . . . . . . . . . . . . . .  23
     9.1.
     6.1.  OpenWebRTC  . . . . . . . . . . . . . . . . . . . . . . .  23
     9.2.
     6.2.  A C++ Implementation of SCReAM  . . . . . . . . . . . . .  24
   10.
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  24
   11.
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  25
   12.
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  25
   13.
   10. Change history  . . . . . . . . . . . . . . . . . . . . . . .  25
   14.
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  25
     14.1.
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  25
     14.2.
     11.2.  Informative References . . . . . . . . . . . . . . . . .  26
   Appendix A.  Additional features  . . . . . . . . . . . . . . . .  27  28
     A.1.  Packet pacing . . . . . . . . . . . . . . . . . . . . . .  27
     A.2.  Stream prioritization . . . . . . . . . . . . . . . . . .  28
     A.3.  Q-bit semantics (source quench) . . . . . . . . . . . . .  30
     A.4.  Frame skipping  . . . . . . . . . . . .
     A.2.  Computation of autocorrelation function . . . . . . . . .  31  28
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  32  29

1.  Introduction

   Congestion in the internet Internet is a reality and applications that are
   deployed in the internet Internet must have congestion control schemes in
   place not only for the robustness of the service that it provides but
   also to ensure the function of the currently deployed internet. Internet.  As
   the interactive realtime communication imposes a great deal of
   requirements on the transport, a robust, efficient rate adaptation
   for all access types is considered as 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, 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
   in available channel bandwidth.  This memo describes a solution,named
   SCReAM, that is based on the self-clocking principle of TCP and uses
   techniques similar to what is used in a new delay based rate
   adaptation algorithm, LEDBAT [RFC6817].  Because neither TCP nor
   LEDBAT was designed for interactive realtime media, a few extra
   features are needed to make the concept work well within this
   context.  This memo describes these extra features.

1.1.  Wireless (LTE) access properties

   [I-D.ietf-rmcat-wireless-tests] introduces 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.

   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.  In addition, the grace time, i.e. allowed reaction time
   from the time that the congestion is detected until a reaction in
   terms of a rate reduction is effected, is generally very short, in
   the order of one RTT (Round Trip Time).

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"

1.2.  Why is it a self-clocked algorithm?

   Self-clocked congestion control algorithm provides with a benefit
   over the rate based counterparts in this
   document are to be that the former consists of two
   parts; the congestion window computation that evolves over a longer
   timescale (several RTTs) especially when the congestion window
   evolution is dictated by estimated delay and; the fine grained
   congestion control given by the self-clocking which operates on a
   shorter time scale (1 RTT).
   A rate based congestion control has only one mechanism to adjust the
   sending rate and that makes it more problematic to reach the goal of
   prompt reaction to congestion and also high throughput when channel
   conditions are good.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC2119 [RFC2119]

3.  Overview of SCReAM Algorithm

   The core SCReAM algorithm has similarities to the concepts like of self-
   clocking used in TFWC [TFWC] and follows the packet conservation
   principles.
   principle.  The packet conservation principle is described as an
   important key-factor behind the protection of networks from
   congestion [FACK].

   The packet conservation principle is realized by including an
   indication [PACKET_CONSERVATION].

   In case of SCReAM, the receiver of the media sends the highest
   received sequence number in the feedback,
   see Section 5, from the receiver back to the sender, the sender keeps a list
   of transmitted packets and their respective sizes.  This information
   is then used to determine how many the amount of bytes can be
   transmitted. transmitted at
   any given time instant.  A congestion window puts an upper limit on
   how many bytes can be in flight, i.e. transmitted but not yet
   acknowledged.  This is how the packet conservation principle is
   realized.  The congestion window is determined in a way similar to
   LEDBAT [RFC6817].  This

   LEDBAT is a congestion control algorithm that uses send and receive
   timestamps to estimate the queuing delay along the transmission path.
   The use of LEDBAT ensures that the e2e latency is kept low.  The
   basic functionality 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:

   o  Congestion window validation techniques.  These will be
   briefly described are similar in sections Section 3.1 to Section 3.3.

   The rate adaptation solution constitutes three parts- congestion
   control, transmission scheduling and media rate adaptation.  All
   these three parts reside at
      action as the sender side. method described in [I-D.ietf-tcpm-newcwv].  The receiver side
   algorithm
      allowed idle period in this draft is very simple shorter than in comparison as it only generates
   acknowledgements the
      reference, this to received RTP packets.

3.1.  Congestion Control

   The congestion control sets an upper limit on how much data can be avoid excessive delays in the network (bytes in flight); this limit is called CWND (congestion
   window) and is used in the transmission scheduling.

   The SCReAM congestion control method, uses LEDBAT [RFC6817] to
   measure the OWD (one way delay).  The SCReAM sender calculates cases where e.g.
      wireless throughput has decreased during a period where the
   congestion window based on output
      bitrate has been low.  Furthermore, this draft allows for more
      relaxed rules when the feedback from SCReAM receiver.  The congestion window is allowed to increase if the OWD is below a
   predefined target, otherwise the congestion window decreases.  The
   delay target is typically set to 50-100ms.  This ensures that the OWD
   is kept low on the average.  The reaction to loss events is similar
   to that of loss based TCP, i.e. an instant reduction of CWND.

   LEDBAT grow, this
      is designed with file transfers necessary as main use case which the variable output bitrate generally means that
      the algorithm must be modified somewhat to work with rate-
   limited sources such as video.  The modifications are

   o  Congestion congestion window validation techniques.  These are similar in
      action as the method described in [I-D.ietf-tcpm-newcwv]. is often under-utilized.

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

   o  Adaptive  A delay target.  This helps the trend is computed for earlier detection of incipient
      congestion control to
      compete with FTP traffic to some degree.

3.2.  Transmission Scheduling

   Transmission scheduling limits the output and as a result it reduces jitter.

   o  Addition of data, given by the
   relation between the number media a rate control function.

   o  Use of bytes in flight and the inflection points to calculate congestion window similar to TCP.  Packet pacing is used to mitigate issues with
   coalescing that may cause increased jitter and/or packet loss in the
   media traffic.

3.3.  Media Rate Control

   The and media
      rate control serves to adjust the media bitrate to ramp up
   quickly enough to get a fair share achieve reduced jitter.

   o  Adjustment of the system resources delay target for better performance when link
   throughput increases. competing
      with other loss based congestion controlled flows

   The reaction to reduced throughput must above mentioned features will be prompt described in order to avoid
   getting too much data queued up more detail in the
   sections Section 3.1 to Section 3.3.

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

                  Figure 1: SCReAM sender functional view

   The SCReAM algorithm constitutes mainly of three parts: network
   congestion control, sender transmission control and media
   bitrate is decreased if the RTP queue size exceeds a threshold.

   In cases where rate
   adaptation.  All these three parts reside at the sender frame queues increase rapidly such as side.
   Figure 1 shows the
   case functional overview of a RAT (Radio Access Type) handover SCReAM sender.  The
   receiver side algorithm is very simple in comparison as it may be necessary only
   generates feedback containing acknowledgements to
   implement additional actions, such as discarding of encoded video
   frames or frame skipping received RTP
   packets, loss count and ECN [RFC6679] count.

3.1.  Network Congestion Control

   The congestion control sets an upper limit on how much data can be in order to ensure that
   the RTP queues are
   drained quickly.  Frame skipping means that the frame rate is
   temporarily reduced.  Discarding of old video frames network (bytes in flight); this limit is a more
   efficient way to reduce media latency than frame skipping but it
   comes with a requirement to repair codec state, frame skipping called CWND (congestion
   window) and is
   thus used in the sender transmission control.

   The SCReAM congestion control method, uses LEDBAT [RFC6817] to prefer
   measure the one-way delay (OWD).  The OWD can be expressed as a first remedy.  Frame skipping the
   estimated queuing delay.  Similar to LEDBAT, it is described as an
   optional not necessary to implement feature
   use synchronized clocks in this specification.

4.  Detailed Description of SCReAM

4.1.  SCReAM Sender

   This section describes the sender side algorithm and receiver in more detail. order to compute
   the one way delay.  It is split between 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 network
   congestion control and window based on the video rate
   adaptation.

   Figure 1 shows feedback from the functional overview of a SCReAM sender. receiver.
   The RTP
   application interaction with congestion control window is described in
   [I-D.ietf-rmcat-app-interaction].  Here we use a more decomposed
   version of allowed to increase if the implementation model in OWD is below a
   predefined target, otherwise the sense congestion window decreases.  The
   delay target is typically set to 50-100ms.  This ensures that the RTP packets
   may be queued up in the sender, OWD
   is kept low on the transmission average.  The reaction to loss events leads to an
   instant reduction of these RTP packets
   is controlled by a transmission scheduler.  A SCReAM sender
   implements CWND.  Note that the source rate control and a queue for each limited nature
   of real time media type or source,
   where RTP packets containing encoded media frames are temporarily
   stored for transmission, the figure shows such as video, typically means that the details for when two
   video sources (a.k.a streams) are used.

        ----------------------------    -----------------------------
        |       Video encoder      |    |        Video encoder      |
        ----------------------------    -----------------------------
         ^                |       ^      ^                 |       ^
      (1)|             (2)|    (3)|   (1)|              (2)|    (3)|
         |               RTP      |      |                RTP      |
         |                V       |      |                 V       |
         |          ------------- |      |           ------------- |
    -----------     |           |--  -----------     |           |--
    | Rate    | (4) |   Queue   |    | Rate    | (4) |   Queue   |
    | control |<----|           |    | control |<----|           |
    |         |     |RTP packets|    |         |     |RTP packets|
    -----------     |           |    -----------     |           |
                    -------------                    -------------
                          |                                |
                          ---------------     --------------
                                     (5)|     |(5)
                                       RTP   RTP
                                        |     |
                                        v     v
           --------------          ----------------
           |  Network   |    (8)   | Transmission |
           | congestion |<-------->|   scheduler  |
           |  control   |          |              |
           --------------          ----------------
                ^                         |
                |         (7)             |(6)
                ---------RTCP----------  RTP
                                      |   |
                                      |   v
                                  -------------
                                  |    UDP    |
                                  |  socket   |
                                  -------------

                  Figure 1: SCReAM sender functional view

   Video frames are encoded and forwarded to queuing
   delay will mostly be below the queue (2).  The media
   rate adaptation adapts given delay target, this is contrary
   to the size of the RTP queue and controls the
   video bitrate (1).  The RTP packets case where large files are picked from each queue based
   on some defined priority order or simply transmitted using LEDBAT congestion
   control, in a round robin fashion
   (5).  A transmission scheduler takes care of which case the transmission of RTP
   packets, to be written queuing delay will stay close to the UDP socket (6).  In delay
   target.

3.2.  Sender Transmission Control

   Sender Transmission Control limits the general case
   all media must go through output of data, given by the transmission scheduler and is allowed
   to be transmitted if
   relation between the number of bytes in flight is less than and the congestion
   window.  Audio frames can however  Packet pacing is used to mitigate issues with ACK
   compression that may cause increased jitter and/or packet loss in the
   media traffic.

3.3.  Media Rate Control

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

   The reaction to reduced throughput must be allowed prompt in order to avoid
   getting too much data queued up in the RTP packet queues at 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 the
   case of a RAT (Radio Access Type) handover it may be
   transmitted immediately necessary to
   implement additional actions, such as audio is typically low bitrate and thus
   contributes little discarding of encoded media
   frames or frame skipping in order to congestion, this is something ensure that is left as
   an implementation choice.  RTCP packets the RTP queues are received (7)
   drained quickly.  Frame skipping means that the frame rate is
   temporarily reduced.  Which method to use is a design consideration
   and outside the
   information about bytes scope of this algorithm description.

4.  Detailed Description of SCReAM

4.1.  SCReAM Sender

   This section describes the sender side algorithm in flight and congestion window more detail.  It
   is exchanged a split between the network congestion control and the transmission scheduler
   (8).

4.1.1.  Constants and Parameter values media rate
   adaptation.

   A set of constants SCReAM sender implements media rate control and a queue for each
   media type or source, where RTP packets containing encoded media
   frames are defined in Table 1, state variables temporarily stored for transmission.  Figure 1 shows the
   details when single media sources (a.k.a streams) are
   defined used.  However,
   multiple media sources are also supported in Table 2.  And finally, local the design, in that case
   the sender transmission control will include a transmission
   scheduler.  The transmission scheduler can then enforce the
   priorities for the different streams and act like a coupled
   congestion controller for multiple flows.

   Media frames are encoded and forwarded to the RTP queue (1).  The
   media rate adaptation adapts to the size of the RTP queue (2) and
   controls the media bitrate (3).  The RTP packets are picked from the
   RTP queue (for multiple flows from each queue based on some defined
   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 the
   transmission of RTP packets, to be written to the UDP socket (5).  In
   the general case all media must go through the sender transmission
   controller and is allowed to be transmitted if 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 described listed in
   Table 3.

   An init value [] indicates an empty array.

   +-------------------------------+------------------------+----------+
   | Constant                      | Explanation            | Value    |
   +-------------------------------+------------------------+----------+
   | this section.

4.1.1.1.  Constants

   The recommended values for the constants are deduced from
   experimental results.

   OWD_TARGET_LO                 | Min (0.1s)
     Target value for the minimum OWD target         | 0.1s     |
   |

   OWD_TARGET_HI                 | Max (0.4s)
     Target value for the maximum OWD target         | 0.4s     |
   |

   OWD_WEIGHT (0.1)
     Averaging factor for owd_fraction_avg

   MAX_BYTES_IN_FLIGHT_HEAD_ROOM | (1.1)
     Headroom for           | 1.1      |
   |                               | the limitation of CWND     |          |
   |

   GAIN                          | (1.0)
     Gain factor for        | 1.0      |
   |                               | congestion window      |          |
   |                               | adjustment             |          |
   | BETA                          |

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

   BETA_ECN (0.8)
     CWND scale factor due to ECN event

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

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

   BYTES_IN_FLIGHT_SLACK         | (10%)
     Additional slack [%]   | 10%      |
   |                               | to the congestion      |          |
   |                               | window                 |          |
   |

   RATE_ADJUST_INTERVAL          | (0.2s)
     Interval between video | 0.1s     |
   |                               | media bitrate adjustments    |          |
   | FRAME_PERIOD                  | Video coder frame      |          |
   |                               | period [s]             |          |
   |

   TARGET_BITRATE_MIN            |
     Min target_bitrate     |          |
   |                               | target bitrate [bps]                  |          |
   |

   TARGET_BITRATE_MAX            |
     Max target_bitrate     |          |
   |                               | [bps]                  |          |
   | RAMP_UP_TIME                  | Timespan [s] from      | 10s      |
   |                               | lowest to highest      |          |
   |                               | target bitrate                |          |
   | [bps]

   RAMP_UP_SPEED (200kbps/s)
     Maximum allowed rate increase speed

   PRE_CONGESTION_GUARD          |  (0.0..0.2)
     Guard factor against   | 0.0..0.2 |
   |                               | early congestion       |          |
   |                               | onset.  A higher value  |          |
   |                               | gives
     less jitter      |          |
   |                               | jitter, possibly at the        |          |
   |                               | expense of a lower     |          |
   |                               | video bitrate.         |          |
   | link utilization.

   TX_QUEUE_SIZE_FACTOR          | (0.0..0.2)
     Guard factor against   | 0.0..2.0 |
   |                               | RTP queue buildup      |          |
   +-------------------------------+------------------------+----------+

                            Table 1: Constants

   +-------------------------+--------------------+--------------------+
   | Variable                | Explanation        | Init

   OWD_TREND_LO (0.2)  Threshold value         |
   +-------------------------+--------------------+--------------------+
   | for owd_trend
   T_RESUME_FAST_INCREASE  Time span until fast increase can be resumed,
     given that the owd_trend is below OWD_TREND_LO

4.1.1.2.  State variables

   owd_target              | (OWD_TARGET_LO)
     OWD target         | OWD_TARGET_LO      |
   |

   owd_fraction_avg        | (0.0)
     EWMA filtered      | 0.0                |
   |                         | owd_fraction       |                    |
   | owd_fraction_hist       |

   owd_fraction_hist[20] ({0,..,0})
     Vector of the last | []                 |
   |                         | 20 owd_fraction    |                    |
   |

   owd_trend               | (0.0)
     OWD trend,         | 0.0                |
   |                         | indicates          |                    |
   |                         | incipient          |                    |
   |                         | congestion         |                    |
   |

   owd_trend_mem           | (0.0)
     Low pass filtered  | 0.0                |
   |                         | version of         |                    |
   |                         | owd_trend          |                    |
   | owd_norm_hist           |

   owd_norm_hist[100] ({0,..,0})
     Vector of the last | []                 |
   |                         | 100 owd_norm       |                    |
   | mss                     | Maximum segment    | 1000               |
   |                         | size = Max RTP     |                    |
   |                         | packet size [byte] |                    |
   |

   min_cwnd                | (2*MSS)
     Minimum congestion | 2*MSS              |
   |                         | window [byte]      |                    |
   | in_fast_start           |

   in_fast_increase (true)
     True if in fast    | true               |
   |                         | start increase state        |                    |
   |

   cwnd                    | (min_cwnd)
     Congestion window  | min_cwnd           |
   |                         | [byte]             |                    |
   | cwnd_i                  |

   cwnd_last_max (1 byte)
     Congestion window  | 1                  |
   |                         | inflection point   |                    |
   | point, i.e. the last known highest
     cwnd.  Used to limit cwnd increase close to the last known
     congestion point.

   bytes_newly_acked       | (0)
     The number of      | 0                  |
   |                         | bytes that was     |                    |
   |                         | acknowledged with  |                    |
   |                         | the last received  |                    |
   |                         |
     acknowledgement    |                    |
   |                         | i.e. bytes         |                    |
   |                         | acknowledged since |                    |
   |                         | the last CWND      |                    |
   |                         | update [byte].     |                    |
   |                         | update.
     Reset after a CWND |                    |
   |                         | update             |                    |
   |

   send_wnd                | (0)
     Upper limit of how | 0                  |
   |                         | many bytes that    |                    |
   |                         | can be transmitted |                    |
   |                         | [byte]. transmitted.  Updated   |                    |
   |                         |
     when CWND is       |                    |
   |                         | updated and when   |                    |
   |                         | RTP packet is      |                    |
   |                         | transmitted        |                    |
   | t_pace                  | Approximate        | 0.001              |
   |                         | estimate

   target_bitrate (0 bps)
     Media target bitrate

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

   rate_transmit (0.0 bps)
     Measured transmit bitrate

   rate_ack (0.0 bps)
     Measured throughput based on received acknowledgements

   rate_rtp (0.0 bps)
     Measured bitrate from the media encoder

   rate_rtp_median (0.0 bps)
     Median value of inter- |                    |
   |                         | packet             |                    |
   |                         | transmission       |                    |
   |                         | interval rate_rtp, computed over more than 10s

   s_rtt (0.0s)
     Smoothed RTT [s],      |                    |
   |                         | updated when computed similar to method depicted in [RFC6298]

   rtp_queue_size (0 bits)
     Size of RTP   |                    |
   |                         | packet transmitted |                    |
   | age_vec                 | A vector packets in queue

   rtp_size (0 byte)
     Size of the    | []                 |
   |                         | last 20 transmitted RTP packet |                    |
   |                         | queue delay        |                    |
   |                         | samples            |                    |
   | frame_skip_intensity    | Indicates

4.1.2.  Network congestion control

   This section explains the      | 0.0                |
   |                         | intensity network congestion control, it contains two
   main functions

   o  Computation of congestion window at the   |                    |
   |                         | frame skips        |                    |
   | since_last_frame_skip   | Number of video    | 0                  |
   |                         | frames since sender: Gives an upper
      limit to the   |                    |
   |                         | last skip          |                    |
   | consecutive_frame_skips | Number number of          | 0                  |
   |                         | consecutive frame  |                    |
   |                         | skips              |                    |
   | target_bitrate          | Video target       | TARGET_BITRATE_MIN |
   |                         | bitrate [bps]      |                    |
   | target_bitrate_i        | Video target       | 1                  |
   |                         | bitrate inflection |                    |
   |                         | point bytes in flight i.e. how many bytes that
      have been transmitted but not yet acknowledged.

   o  Calculation of send window at the     |                    |
   |                         | last known highest |                    |
   |                         | target_bitrate     |                    |
   |                         | during fast start. |                    |
   |                         | Used to limit      |                    |
   |                         | bitrate increase   |                    |
   |                         | close to sender: RTP packets are
      transmitted if allowed by the last  |                    |
   |                         | know congestion    |                    |
   |                         | point              |                    |
   | rate_transmit           | Measured transmit  | 0.0                |
   |                         | bitrate [bps]      |                    |
   | rate_acked              | Measured           | 0.0                |
   |                         | throughput based   |                    |
   |                         | on received        |                    |
   |                         | acknowledgements   |                    |
   |                         | [bps]              |                    |
   | rate_rtp                | Measured bitrate   | 0.0                |
   |                         | from relation between the media     |                    |
   |                         | encoder [bps]      |                    |
   | rate_rtp_median         | Median value number of    | 0.0                |
   |                         | rate_rtp, computed |                    |
   |                         | over more than 10s |                    |
   |                         | [bps]              |                    |
   | s_rtt                   | Smoothed RTT [s],  | 0.0                |
   |                         | computed similar   |                    |
   |                         | to method depicted |                    |
   |                         | bytes
      in [RFC6298]       |                    |
   | rtp_queue_size          | Size of flight and the congestion window.  This is controlled by the
      send window.

   Unlike TCP, SCReAM is not a byte oriented protocol, rather it is an
   RTP        | 0                  |
   |                         | packets in queue   |                    |
   |                         | [bits]             |                    |
   | rtp_size                | Size packet oriented protocol.  Thus a list of the last   | 0                  |
   |                         | transmitted RTP    |                    |
   |                         | packets [byte]     |                    |
   | frame_skip              | Skip encoding
   and their respective transmission times (wall-clock time) is kept for
   further calculation.

   The feedback from the receiver is assumed to consist of   | false              |
   |                         | video frame if     |                    |
   |                         | true               |                    |
   +-------------------------+--------------------+--------------------+

                         Table 2: State variables

   +------------------+------------------------------------------------+
   | Variable         | Explanation                                    |
   +------------------+------------------------------------------------+
   | owd              | OWD = One way delay the following
   elements.

   o  The highest received RTP sequence number.

   o  The wall clock timestamp corresponding to the received RTP packet
      with base delay subtracted |
   |                  | [s]. This is an estimate he highest sequence number.

   o  Accumulated number of lost RTP packets (n_loss).

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

   When the sender receives RTCP feedback, the network        |
   |                  | queueing delay.                                |
   | owd_fraction     | OWD is calculated as
   outlined in [RFC6817] and a fraction number of variables are updated as
   illustrated by the pseudo code below.

     update_variables(owd):
       owd_fraction = owd/owd_target
       #calculate moving average
       owd_fraction_avg = (1-OWD_WEIGHT)*owd_fraction_avg+
          OWD_WEIGHT*owd_fraction
       update_owd_fraction_hist(owd_fraction)
       # R is an autocorrelation function of owd_fraction_hist
       #  at lag K
       a = R(owd_fraction_hist,1)/R(owd_fraction_hist,0)
       #calculate OWD target            |
   | owd_norm         | OWD normalized to OWD_TARGET_LO                |
   | owd_norm_mean    | Average OWD norm over the last 100 samples     |
   | owd_norm_mean_sh | Average trend
       owd_trend = a*owd_fraction_avg
       owd_trend_mem = max(0.99*owd_trend_mem, owd_trend)

   The OWD norm over fraction is sampled every 50ms and the last 20 samples      |
   | owd_norm_var     | OWD norm variance over are
   stored in a vector (owd_fraction_hist).  This vector is used in the last 100 samples    |
   | off_target       | Relation between
   computation of an OWD trend that gives a value between 0.0 and 1.0
   depending on the estimated congestion level.  The prediction
   coefficient 'a' has positive values if OWD shows an increasing trend,
   thus an indication of congestion is obtained before the OWD target            |
   | scl_i            | A general scalefactor that is applied
   reached.  The prediction coefficient is further multiplied with
   owd_fraction_avg to the   |
   |                  | CWND or target_bitrate increase                |
   | x_cwnd           | Additional increase of CWND, used reduce sensitivity to increasing OWD when         |
   |                  | send_wnd OWD is computed                           |
   | pace_bitrate     |
   very small.  The allowed RTP packet transmission rate, used |
   |                  | owd_trend is utilized in the computation of t_pace [bps]             |
   | age_avg          | Average RTP queue delay [s]                    |
   | increment        | Allowed target_bitrate increase                |
   | current_rate     | Max of rate_transmit and rate_acked            |
   +------------------+------------------------------------------------+

                    Table 3: Local temporary variables

4.1.2.  Network congestion media rate control

   This section explains the network to
   indicate incipient congestion control, it contains two
   main functions

   o  Computation of and to determine when to exit from fast
   increase mode. owd_trend_mem is used to enforce a less aggressive
   rate increase after congestion window at events.  The function
   update_owd_fraction_hist(..) removes the sender: Gives an upper
      limit oldest element and adds the
   latest owd_fraction element to the number of bytes owd_fraction_hist vector.

   A loss event is detected if the n_loss counter in flight i.e. how many bytes that
      have been transmitted but not yet acknowledged.

   o  Transmission scheduling at the sender: RTP packets are transmitted
      if allowed by feedback has
   increased since the relation between previous received feedback.  Once a loss event is
   detected, the number n_loss counter is ignored for a full smoothed round
   trip time, the intention of bytes in flight
      and this is to limit the congestion window.  This window
   decrease to at most once per round trip.
   The congestion window backoff due to loss events is deliberately a
   bit less than is controlled by the send window.

   Unlike TCP, SCReAM case with e.g TCP NewReno.  The reason is not a byte oriented protocol, rather it that
   TCP is generally used to transmit whole files, which can be
   translated to an
   RTP packet oriented protocol.  Thus it keeps infinite source bitrate.  SCReAM on the other hand
   has a list of transmitted
   RTP packets and their respective sending times (wall-clock time).
   The feedback indicates source which rate is limited to a value close to the highest received RTP sequence number available
   transmit rate and a
   timestamp (wall-clock time) when it was received.  In addition, an
   ACK list often below said value, the effect of this is included that
   SCReAM has less opportunity to make grab free capacity than a TCP based
   file transfer.  To compensate for this it possible is necessary to determine lost packets.

4.1.2.1.  Congestion window update

   The let SCReAM
   reduce the congestion window slightly less when loss events occur.

   An ECN event is computed from the one way (extra) delay
   estimates (OWD) that are obtained from the send and received
   timestamp of detected if the RTP packets.  LEDBAT [RFC6817] explains n_ECN counter in the details
   of feedback report
   has increased since the computation of previous received feedback.  Once an ECN
   event is detected, the OWD.  An OWD sample n_ECN counter is obtained ignored for each
   received acknowledgement.  No smoothing of a full smoothed
   round trip time, the OWD samples occur,
   however some smoothing occurs anyway as the computation intention of this is to limit the CWND congestion
   window decrease to at most once per round trip.  The congestion
   window backoff due to an ECN event is in itself deliberately smaller than if a low pass filter function.

   SCReAM uses the terminology "Bytes in flight (bytes_in_flight)" which
   loss event occurs.  This is computed as the sum of the sizes of the RTP packets ranging from inline with the RTP packet most recently transmitted down idea outlined in
   [Khademi_alternative_backoff_ECN] to but not including enable ECN marking thresholds
   lower than the acknowledged corresponding packet drop thresholds.

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

     on loss(owd):
       in_fast_increase = false
       cwnd_last_max = cwnd
       cwnd = max(min_cwnd,cwnd*BETA_LOSS)
       adjust_owd_target(owd)#compensating for competing flows
       calculate_send_window(owd,owd_target)

     on ECN(owd):
       in_fast_increase = false
       cwnd_last_max = cwnd
       cwnd = max(min_cwnd,cwnd*BETA_ECN)
       adjust_owd_target(owd)#compensating for competing flows
       calculate_send_window(owd, owd_target)

     # when no loss or ECN event is detected
     on acknowledgement(owd):
       update_bytes_newly_acked()
       update_cwnd(bytes_newly_acked)
       adjust_owd_target(owd) #compensating for competing flows
       calculate_send_window(owd, owd_target)
       check_to_resume_fast_increase()

   The methods are further described in detail below.

4.1.2.1.  Updating bytes_newly_acked

   The bytes_newly_acked is incremented with a value corresponding to
   how much the highest sequence number. number has increased since the last
   feedback.  As an example: If RTP packet was sequence number SN with transmitted and the last ACK previous acknowledgement indicated SN-5 as
   the highest received sequence number N and the new acknowledgement indicated
   N+3, then bytes in flight bytes_newly_acked is computed as incremented by a value equal to the
   sum of the size sizes of RTP packets with sequence number SN-4, SN-3, SN-2, SN-1 N+1, N+2 and SN.

   CWND
   N+3.  Packets that are lost are also included, which means that even
   though e.g packet N+2 was lost, its size is updated differently depending on whether still included in the
   update of bytes_newly_acked.

4.1.2.2.  Updating congestion
   control window

   The congestion window update is in fast start or not and if a based on OWD, except for the
   occurrence of loss event or ECN events, which was described earlier.  OWD
   is detected.  A
   Boolean variable in_fast_start indicates if obtained from the congestion is in fast
   start state.

   A loss event indicates one or more lost RTP packets within an RTT.
   This is detected by means send and received timestamp of inspection for holes in the sequence
   number space in the acknowledgements with some margin for possible
   packet reordering in the network.  As an alternative, a timer for
   loss detection similar to TCP RACK may be used.

   Below is described RTP packets.
   LEDBAT [RFC6817] explains the actions when an acknowledgement from details of the
   receiver is received.

   bytes_newly_acked is updated.

   The OWD fraction and an average computation of it are computed as
   owd_fraction = owd/owd_target

   owd_fraction_avg = 0.9* owd_fraction_avg + 0.1* owd_fraction

   The the OWD.
   An OWD fraction sample is sampled every 50ms and obtained for each received acknowledgement.  No
   smoothing of the last 20 OWD samples are
   stored in a vector (owd_fraction_hist).  This vector is used in occur, however some smoothing occurs
   anyway as the computation of an OWD trend that gives a value between 0.0 and 1.0
   depending on how close to congestion it is.  The OWD trend is
   calculated as follows

   Let R(owd_fraction_hist,K) be the autocorrelation function of
   owd_fraction_hist at lag K.  The 1st order prediction coefficient CWND is
   formulated as

   a = R(owd_fraction_hist,1)/R(owd_fraction_hist,0)

   The prediction coefficient in itself a has positive values if OWD shows an
   increasing trend, thus an indication low pass filter
   function.

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

   update_cwnd(bytes_newly_acked):
     # additional scaling factor to slow down closer to target is reached.
     # The prediction coefficient min scale factor is further
   multiplied with owd_fraction_avg to reduce sensitivity 0.2 to increasing
   OWD when OWD is very small.  The OWD trend avoid that the congestion window
     #  growth is thus computed as

   owd_trend = max(0.0,min(1.0,a*owd_fraction_avg))

   owd_trend_mem stalled
     scale = max(0.99*owd_trend_mem, owd_trend)

   The owd_trend is utilized in the media rate control and to determine
   when to exit slow start. owd_trend_mem max(0.2,min(1.0,(abs(cwnd-cwnd_last_max)/cwnd_i*4)^2))

     # action depends on whether algorithm is used to enforce a less
   aggressive rate in fast increase after congestion events.

   An off target value is computed
     if (in_fast_increase)
       if(owd_trend >= 0.2)
         in_fast_increase=false
         cwnd_i=cwnd
       else
         cwnd = cwnd + bytes_newly_acked*scale
         return

     # not in fast increase phase
     # off_target calculated as with LEDBAT
     off_target = (owd_target - owd) / owd_target

   A temporal variable is scl_i is computed as

   scl_i

     gain = max(0.2, min(1.0, (abs(cwnd-cwnd_i)/cwnd_i*4)^2))

   scl_i is used to limit the CWND GAIN
     # adapt only increase when close to the last known
   max value, before congestion was last detected.

   The congestion window update depends based on whether a loss event has
   occurred, and if the congestion control is if fast start or not.

   ____________________________________________________________________

   On loss event:

   If a loss event is detected then in_fast_start is set to false and
   CWND is updated according to

   cwnd_i = cwnd

   cwnd = max(min_cwnd,cwnd*BETA)

   otherwise the CWND update continues

   ____________________________________________________________________

   in_fast_start = true:

   in_fast_start is set to false and cwnd_i=cwnd scale
     if owd_trend >= 0.2 and
   otherwise CWND is updated according to

   cwnd = cwnd + bytes_newly_acked*scl_i

   ____________________________________________________________________

   in_fast_start = false:

   Values of off_target (off_target > 0.0 indicates that the congestion window can
   be increased.  This is done according to the equations below. 0)
       gain = GAIN*(1.0 + max(0.0, 1.0 *= (1 - owd_trend/ 0.2))

   The equation above limits 0.2) * scale

     # increase/decrease the gain when near congestion is detected

   gain *= scl_i

   This equation limits the gain when CWND is close to its last known
   max value window
     # off_target can be positive or negative
     cwnd += gain * off_target * bytes_newly_acked * mss MSS / cwnd

   Values
     # Limit cwnd to the maximum number of off_target <= 0.0 indicates congestion, bytes in flight
     cwnd = min(cwnd, max_bytes_in_flight*MAX_BYTES_IN_FLIGHT_HEAD_ROOM)
     cwnd = max(cwnd, MIN_CWND)

   CWND is then updated according to differently depending on whether the equation

   cwnd += GAIN*off_target*bytes_newly_acked*mss/cwnd

   The equations above are very similar to what congestion
   control is specified in
   [RFC6817].  There are however a few fast increase or not.  A Boolean variable
   in_fast_increase indicates if the congestion is in fast increase
   state.

   In fast increase state the congestion window is increased with the
   number of newly acknowledged bytes scaled by a scale factor that
   depends on the relation between CWND and the last known maximum value
   of CWND (cwnd_last_max).  The congestion window growth when
   in_fast_increase is false is dictated by the relation between owd and
   owd_target, also here the scale factor scale factor is applied to
   limit the congestion window growth when cwnd gets close to
   cwnd_last_max.

   The scale factor as applied above makes the congestion window grow in
   a similar way as is the case with the Cubic congestion control
   algorithm.

   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
      value.

   o  [RFC6817] specifies that the CWND increased is limited by an
      additional function controlled by a constant ALLOWED_INCREASE.
      This additional limitation is removed in this specification.

   ____________________________________________________________________

   A number of final steps in the congestion window update procedure are
   outlined below

   ____________________________________________________________________

   Resume fast start:

   Fast start can be resumed in order to speed up

   Further the bitrate increase
   in case congestion abates.  The condition to resume fast start
   (in_fast_start = true) is that owd_trend is less than 0.2 for 1.0
   seconds or more.

   ____________________________________________________________________

   Competing flows compensation, adjustment of owd_target:

   Competing flows compensation CWND is needed to avoid that flows congestion
   controlled by SCReAM are starved out limited by flows that are more
   aggressive in their nature.  The owd_target is adjusted according to
   the owd_norm_mean_sh whenever owd_norm_var is below a given value. max_bytes_in_flight and min_cwnd.  The condition to update owd_target is fulfilled if owd_norm_var <
   0.16 (indicating that
   limitation of the standard deviation is less than 0.4).
   owd_target is then update as:

   owd_target = min(OWD_TARGET_HI,max(OWD_TARGET_LO, owd_norm_mean_sh*
   OWD_TARGET_LO*1.1))

   ____________________________________________________________________

   Final CWND adjustment step:

   The congestion window is limited by the maximum number of bytes in
   flight over the last 1.0 5 seconds according to

   cwnd = min(cwnd, max_bytes_in_flight*MAX_BYTES_IN_FLIGHT_HEAD_ROOM)
   This (max_bytes_in_flight) avoids possible
   over-estimation of the throughput after for example, idle periods.

   Finally cwnd is set to ensure that it is at least min_cwnd

   cwnd = max(cwnd, MIN_CWND)

4.1.2.2.  Transmission scheduling

   The principle is
   An additional MAX_BYTES_IN_FLIGHT_HEAD_ROOM allows for a slack, to
   allow packet transmission for a certain amount of an RTP packet only
   if media coder output rate variability.

   SCReAM uses the number of bytes terminology "Bytes in flight (bytes_in_flight)" which
   is less than the congestion window.
   There are however two reasons why this strict rule will not work
   optimally:

   o  Bitrate variations: The video frame size is always varying to a
      larger or smaller extent, a strict rule as the one given above
      will have the effect that the video bitrate have difficulties to
      increase computed as the congestion window puts a too hard restriction on sum of the video frame size variation, this further can lead to
      occasional queuing sizes of the RTP packets in ranging from
   the RTP packet queue that
      will prevent bitrate increase because of the increased RTP queue
      size.

   o  Reverse (feedback) path congestion: Especially in transport over
      buffer-bloated networks, the one way delay in the reverse
      direction may jump due most recently transmitted down to congestion.  The effect of this is that but not including
   the acknowledgements are delayed acknowledged packet with the result that highest sequence number.  This can
   be translated to the self-
      clocking is temporarily halted, even though difference between the forward path is
      not congested.

   Packets are highest transmitted at a pace given by the send window, computed
   below

   The send window is computed differently depending on OWD byte
   sequence number and its
   relation to the OWD target.

   o highest acknowledged byte sequence number.
   As an example: If owd > owd_target:
      The send window RTP packet with sequence number SN is computed as
      send_wnd = cwnd-bytes_in_flight
      This enforces a strict rule that helps to prevent further queue
      buildup.

   o  If owd <= owd_target:
      A helper variable
      x_cwnd=1.0+BYTES_IN_FLIGHT_SLACK*max(0.0,
      min(1.0,1.0-owd_trend/0.5))/100.0
      is computed.  The send window transmitted
   and the last acknowledgement indicates SN-5 as the highest received
   sequence number then bytes in flight is computed as
      send_wnd = max(cwnd*x_cwnd, cwnd+mss)-bytes_in_flight
      This gives a slack that reduces as congestion increases,
      BYTES_IN_FLIGHT_SLACK is a maximum allowed slack in percent.  A
      large value increases the robustness to bitrate variations in sum of the
      source
   size of RTP packets with sequence number SN-4, SN-3, SN-2, SN-1 and congested feedback channel issues.  The possible
      drawback is increased delay or
   SN, it does not matter if for instance packet loss when forward path
      congestion occur.

4.1.3.  Video rate control

   The video rate control is operated based on with sequence number
   SN-3 was lost, the size of the RTP packet send queue and observed loss events.  In addition, owd_trend
   is also with sequence number SN-3 will
   still be considered in the rate control, this to reduce the amount computation of
   induced network jitter.

   A variable target_bitrate bytes_in_flight.

4.1.2.3.  Compensation for competing flows

   It is adjusted depending on the congestion
   state.  The target bitrate can vary between likely that a minimum value
   (target_bitrate_min) and flow using SCReAM algorithm will have to share
   congested bottlenecks with other flows that use a maximum value (target_bitrate_max).

   For more aggressive
   congestion control algorithm.  SCReAM takes care of such situations
   by adjusting the overall bitrate adjustment, two network throughput estimates
   are computed :

   o  rate_transmit: The measured transmit bitrate

   o  rate_acked: owr_target.

     adjust_owd_target(owd)
       owd_norm = owd / OWD_TARGET_LOW
       update_owd_norm_history(owd_norm)
       # Compute variance
       owd_norm_var = VARIATION(owd_norm_history(100))
       # Compensation for competing traffic
       if (owd_norm_var < 0.16)
         # Compute average
         owd_norm_avg = AVERAGE(owd_norm_history(20))
         # Update target OWD
         owd_target = owd_norm_avg*OWD_TARGET_LO*1.1
         owd_target = min(OWD_TARGET_HI, owd_target)
         owd_target = max(OWD_TARGET_LO, owd_target)

   The ACKed bitrate, i.e. owd_target is adjusted according to the volume of ACKed bits per
      time unit.

   Both estimates are updated every 200ms.

   The current throughput current_rate owd_norm_mean_sh whenever
   owd_norm_var is computed as the maximum value
   of rate_transmit and rate_acked. below a given value.  The rationale behind the use of
   rate_acked in addition condition to rate_transmit update
   owd_target is fulfilled if owd_norm_var < 0.16 (indicating that rate_transmit the
   standard deviation is
   affected also less than 0.4).

   owd_norm is the OWD divided by OWD_TARGET_LO. owd_norm_mean_sh is the amount
   short term (last 20 samples) average of data that owd_norm.  owd_norm_var is available to transmit,
   thus a lack
   the variance of data to transmit can be seen as reduced throughput
   that may itself cause an unnecessary rate reduction.  To overcome
   this shortcoming; rate_acked is used as well.  This gives a more
   stable throughput estimate.

   The bitrate is updated at regular intervals, given by
   RATE_ADJUST_INTERVAL and differently depending owd_norm over the fast start state last 100 samples.

4.1.2.4.  Send window calculation

   The rate change behavior depends on whether a loss event has
   occurred, and if the congestion control basic design principle behind packet transmission in SCReAM is to
   allow transmission only if fast start or not.

   ____________________________________________________________________

   On loss event:

   First of all the target_bitrate number of bytes in flight is updated if a new loss event was
   indicated and less than
   the rate change procedure congestion window.  There are however two reasons why this strict
   rule will not work optimally:

   o  Bitrate variations: The media frame size is exited.

   target_bitrate_i = target_bitrate

   target_bitrate = max(BETA_R* target_bitrate, TARGET_BITRATE_MIN)

   If no loss event was indicated then always varying to a
      larger or smaller extent.  A strict rule as the rate change procedure
   continues.

   ____________________________________________________________________

   in_fast_start = true:

   An allowed increment is computed based on one given above
      will have the congestion level and effect that the relation media bitrate will have difficulties
      to target_bitrate_i

   scl_i = (target_bitrate - target_bitrate_i)/ target_bitrate_i

   increment = TARGET_BITRATE_MAX* RATE_ADJUST_INTERVAL/RAMP_UP_TIME*
   (1.0- min(1.0, owd_trend/0.1))

   increment *= max(0.2, min(1.0, (scl_i*4)^2))

   target_bitrate += increment

   target_bitrate is reduced further if increase as the congestion is detected.

   target_bitrate *= (1.0- PRE_CONGESTION_GUARD*owd_trend)

   ____________________________________________________________________

   in_fast_start = false:

   target_bitrate_i is updated window puts a too hard restriction
      on the media frame size variation.  This can lead to occasional
      queuing of RTP packets in the current value 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 target_bitrate if
   in_fast_start was true this is that
      the last time acknowledgements are delayed with the bitrate was updated.

   A pre-congestion indicator result that the self-
      clocking is computed as

   pre_congestion = min(1.0, max(0.0, owd_fraction_avg-0.3)/0.7)

   pre_congestion += owd_trend temporarily halted, even though the forward path is
      not congested.

   The target bitrate congestion window is computed as
   target_bitrate=current_rate*(1.0-
   PRE_CONGESTION_GUARD*pre_congestion)-TX_QUEUE_SIZE_FACTOR
   *rtp_queue_size

   ____________________________________________________________________

   Final step:

   As a final step, adjusted depending on OWD and its relation
   to the target bitrate OWD target.  When OWD is limited such greater than OWD target the
   congestion window enforces a strict rule that it helps to prevent
   further queue buildup.  When OWD is kept
   within reasonable bounds.

   In cases where input stimuli less than or equal to the media encoder OWD target
   then an additional slack is static, for
   instance in "talking head" scenarios, added to the target bitrate congestion window that
   reduces as congestion increases, BYTES_IN_FLIGHT_SLACK is not
   always fully utilized.  This may cause undesirable oscillations a maximum
   allowed slack in percent.  A large value increases the target robustness to
   bitrate variations in the cases where the link throughput is limited
   and the media coder input stimuli changes between static source and varying.

   To overcome this issue, congested feedback channel
   issues.  The possible drawback is increased delay or packet loss when
   forward path congestion occurs.  The adjusted congestion window
   (cwnd_s) is used in the target bitrate send window calculation.

   The send window is capped to be less than
   a given multiplier of a median value of by the history relation between the adjusted
   congestion window and the amount of media coder
   output bitrates.  A rate_rtp_limit is computed as

   rate_rtp_limit bytes in flight according to the
   pseudo code below.

     calculate_send_window(owd, owd_target)
        # compensate for backward congestion and bitrate variations
        if (owd <= owd_target)
          x_cwnd=1.0+BYTES_IN_FLIGHT_SLACK*(1.0-owd_trend/0.5)/100.0
          cwnd_s = max(br, max(rate_rtp,rtp_rate_median))

   A multiplier is applied max(cwnd*x_cwnd, cwnd+MSS)

        send_wnd = cwnd_s-bytes_in_flight

4.1.2.5.  Resuming fast increase

   Fast increase can be resumed in order to rate_rtp_limit, depending on speed up the bitrate
   increase in case congestion
   history

   rate_rtp_limit *= (2.0-1.0*owd_trend_mem) abates.  The target_bitrate is then limited by rate_rtp_limit

   target_bitrate condition to resume fast
   increase (in_fast_increase = min(target_bitrate, rate_rtp_limit)

   Finally the target_bitrate true) is enforced that owd_trend is less than
   OWD_TREND_LO for T_RESUME_FAST_INCREASE seconds or more.

4.1.3.  Media rate control

   The media rate control algorithm is executed at regular intervals
   RATE_ADJUSTMENT_INTERVAL, with the exception of a prompt reaction to be within
   loss events.  The media rate control operates based on the defined min size of
   the RTP packet send queue and max values

   target_bitrate =
   min(TARGET_BITRATE_MAX,max(TARGET_BITRATE_MIN,target_bitrate))

4.2.  SCReAM Receiver

   The SCReAM receiver observed loss events.  In addition,
   owd_trend is very simple also considered in its implementation. the media rate control, this to
   reduce the amount of induced network jitter.

   The task role of the media rate control is to feedback acknowledgements of received packets.  For that
   purpose strike a set reasonable balance
   between a low amount of state variables are needed, these are explained queuing in
   Table 4.

   One set the RTP queue and a sufficient
   amount of state variables are maintained per stream.

   +-----------------------------+-----------------------------+-------+
   | Variable                    | Explanation                 | Init  |
   |                             |                             | value |
   +-----------------------------+-----------------------------+-------+
   | rx_timestamp                | The wall clock timestamp    | 0     |
   |                             | when data to send in order to keep the latest RTP packet  |       |
   |                             | was received                |       |
   | highest_rtp_sequence_number | The highest received        | 0     |
   |                             | sequence number             |       |
   | ack_vector                  | data path busy.  A 16 bit vector too
   cautious setting leads to possible under-utilization of network
   capacity and that        | 0     |
   |                             | indicates received RTP      |       |
   |                             | packets with the flow is starved out by other, more
   opportunistic traffic, on the other hand a sequence     |       |
   |                             | number lower than           |       |
   |                             | highest_rtp_sequence_number |       |
   | n_loss                      | An 8 bit counter for too aggressive setting
   leads to extra jitter.

   A variable target_bitrate is adjusted depending on the    | 0     |
   |                             | number of lost RTP packets, |       |
   |                             | separate counters congestion
   state.  The target bitrate can vary between a minimum value
   (target_bitrate_min) and a maximum value (target_bitrate_max).

   For the overall bitrate adjustment, two network throughput estimates
   are       |       |
   |                             | maintained for each SSRC    |       |
   | n_ECN                       | An 8 bit counter for computed :

   o  rate_transmit: The measured transmit bitrate

   o  rate_ack: The ACKed bitrate, i.e. the    | 0     |
   |                             | number volume of ECN-CE marked RTP |       |
   |                             | packets, separate counters  |       |
   |                             | ACKed bits per
      time unit.

   Both estimates are maintained for each     |       |
   |                             | SSRC                        |       |
   | pending_feedback            | Indicates that an RTP       | false |
   |                             | packet was received updated every 200ms.

   The current throughput, current_rate, is computed as the maximum
   value of rate_transmit and     |       |
   |                             | that an RTCP packet can 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  |       |
   |                             | generated when RTCP timing  |       |
   |                             | rules permit                |       |
   | last_transmit_t             | Last time seen as reduced throughput
   that may itself cause an RTCP packet    | -1.0  |
   |                             | was transmitted, unnecessary rate reduction.  To overcome
   this shortcoming; rate_ack is    |       |
   |                             | used to ensure as well.  This gives a more stable
   throughput estimate.

   Note that RTCP    |       |
   |                             | feedback rate_ack is generated       |       |
   |                             | fairly for all streams.     |       |
   +-----------------------------+-----------------------------+-------+

                         Table 4: State variables

   Upon reception of an RTP packet, the state variables in Table 4
   should be updated and the RTCP processing function should be
   notified.  An RTCP packet is later generated based on the state
   variables, how often this is done by bytes_newly_acked, which means that
   even lost packets are regarded as acknowledged.

   The rate change behavior depends on whether a loss event has
   occurred, and if the RTCP bandwidth.

5.  Feedback Message

   The feedback congestion control is over RTCP [RFC3550] and in fast increase or not.

     # The target_bitrate is based updated at a regular interval according
     # to RATE_ADJUST_INTERVAL

     on [RFC4585].  It is
   implemented loss:
        target_bitrate_last_max = target_bitrate
        target_bitrate = max(BETA_R* target_bitrate, TARGET_BITRATE_MIN)
        exit

     if (in_fast_increase = true)
        scl_i = (target_bitrate - target_bitrate_last_max)/
          target_bitrate_last_max
        increment = RAMP_UP_SPEED*RATE_ADJUST_INTERVAL*
                   (1.0-min(1.0, owd_trend/0.2))
        # Value 0.2 as a transport layer feedback message (RTPFB), see
   proposed example in Figure 2.  The feedback control information part
   (FCI) consists of the following elements.

   o  Highest received RTP sequence number: The highest received RTP
      sequence number for bitrate should be allowed to increase
        #  at least slowly --> avoid locking the given SSRC

   o  n_lost: Ackumulated number of lost RTP packets for rate to
        #  target_bitrate_last_max
        increment *= max(0.2, min(1.0, (scl_i*4)^2))
        target_bitrate += increment
        target_bitrate *= (1.0- PRE_CONGESTION_GUARD*owd_trend)
     else
        pre_congestion = min(1.0, max(0.0, owd_fraction_avg-0.3)/0.7)
        pre_congestion += owd_trend
        target_bitrate=current_rate*(1.0-PRE_CONGESTION_GUARD*
             pre_congestion)-TX_QUEUE_SIZE_FACTOR *rtp_queue_size
     end

     rate_rtp_limit = max(br, max(rate_rtp,rtp_rate_median))
     rate_rtp_limit *= (2.0-1.0*owd_trend_mem)
     target_bitrate = min(target_bitrate, rate_rtp_limit)
     target_bitrate = min(TARGET_BITRATE_MAX,
        max(TARGET_BITRATE_MIN,target_bitrate))

   In case of a loss event the target_bitrate is updated and the rate
   change procedure is exited.  Otherwise the rate change procedure
   continues.  An ECN event does not cause any action, the reason to
   this is that the congestion window is reduced less due to ECN events
   than loss events, the effect is thus that the expected additional RTP
   queuing delay due to ECN events is so small that an additional
   decrease in media rate is not warranted.

   When in fast increase state, the bitrate increase is given SSRC

   o  Timestamp: A timestamp value indicating when by the
   desired ramp-up speed (RAMP_UP_SPEED) and is limited by the relation
   between the current bitrate and the last packet was
      received which known max bitrate.
   Furthermore an increased OWD trend limits the bitrate increase.  The
   setting of RAMP_UP_SPEED depends on preferences, a high setting such
   as 1000kbps/s makes it possible to compute quickly gain high quality media,
   this is however at the one way (extra)
      delay (OWD).

   o  n_ECN: Ackumulated number expense of ECN-CE marked RTP packets for 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 SSRC

   o  Source quench bit (Q): Makes it possible to request by the sender to
      reduce its congestion window.  This is useful if WebRTC media
   current bitrate and is
      received from many hosts also controlled by the estimated RTP queue and
   the OWD trend, thus it becomes necessary is sufficient that an increased congestion
   level is sensed by the network congestion control to balance limit the
      bitrates between
   bitrate.

   In the streams.

        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|   FMT   |       PT      |          length               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  SSRC of packet sender                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  SSRC of media source                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Highest recv. seq. nr. (16b)  |    n_lost     |   n_ECN       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    Timestamp (32bits)                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Q|               Reserved for future use                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 2: Transport layer feedback message

   To make the feedback as frequent as possible, the feedback packets
   are transmitted as reduced size RTCP according to [RFC5506].

   The timestamp clock time fast increase phase an allowed increment is recommended to be set to a fixed value
   such as 1000Hz, defined in this specification.  The n_lost and n_ECN
   makes it possible to take necessary actions computed based on
   the detection of lost congestion level and ECN marked packets.

   Section 4 describes the main algorithm details relation to target_bitrate_last_max and how
   the feedback target_bitrate is used.

6.  Discussion

   This section covers a few open discussion points

   o  RTCP feedback overhead: SCReAM benefits from a relatively frequent
      feedback.  Experiments have shown that a feedback rate roughly
      equal reduced further if congestion is detected.

   If in_fast_increase is false then the target_bitrate_last_max is
   updated to the frame rate gives a stable self-clocking and
      robustness against loss current value of feedback.  With a maximum target_bitrate if in_fast_increase
   was true the last time the bitrate of
      1500kbps was updated.  Additionally, a pre-
   congestion indicator is computed and the RTCP feedback overhead rate is in adjusted
   accordingly.

   In cases where input stimuli to the range 10-15kbps with
      reduced size RTCP, including IP and UDP framing, media encoder is static, for
   instance in other words "talking head" scenarios, the RTCP overhead target bitrate is quite modest and should not pose a problem
   always fully utilized.  This may cause undesirable oscillations in
   the general case.  Other solutions may be required target bitrate in highly
      asymmetrical the cases where the link capacity cases.  Worth notice throughput is that SCReAM can
      work with as low feedback rates as once every 200ms, limited
   and the media coder input stimuli changes between static and varying.
   To overcome this however
      comes with a higher sensitivity issue, the target bitrate is capped to loss be less than
   a given multiplier of feedback and also a
      potential reduction in throughput.

   o  AVPF mode: The RTCP feedback median value of the history of media coder
   output bitrates, rate_rtp_limit.  A multiplier is based applied to
   rate_rtp_limit, depending on AVPF regular mode. congestion history.  The
      SCReAM feedback is transmitted as reduced size RTCP so save
      overhead, it target_bitrate
   is however required to transmit full compound RTCP at
      regular intervals, this interval can be controlled then limited by trr-int
      depicted in [RFC4585].

   o  BETA, CWND scale factor due to loss: The BETA value this rate_rtp_limit.

   Finally the target_bitrate is recommended enforced to be higher than 0.5. within the defined min
   and max values.

   The reason behind vary reader may notice the dependency on the OWD in the
   computation of the target bitrate, this is that manifests itself in the use
   of the owd_trend and owd_fraction_avg.  As these parameters are used
   also in the network congestion control for multimedia has to deal with a source one may suspect that is some odd
   interaction between the media rate
      limited.  A file transfer has "unlimited" source bitrate in
      comparison.  The outcome control and the network congestion
   control, this is that SCReAM must be a little more
      aggressive than a file transfer in order fact the case if the parameter
   PRE_CONGESTION_GUARD is set to not be out competed.

7.  Conclusion

   This memo describes a congestion high value.  The use of owd_trend
   and owd_fraction_avg in the media rate control algorithm for RMCAT that it is particularly good at handling solely to reduce
   jitter, the quickly changing condition in
   wireless network such as LTE.  The solution conforms to dependency can be removed by setting
   PRE_CONGESTION_GUARD=0, the packet
   conservation principle and leverages on novel congestion control
   algorithms effect is a somewhat faster rate increase
   at the expense of more jitter.

4.1.3.1.  FEC and recent TCP research, together with media packet overhead considerations

   The target bitrate
   determined by sender queuing delay and given delay thresholds.  The
   solution has shown potential to meet by SCReAM depicts the goals of high link
   utilization bitrate including RTP
   and prompt reaction to congestion.  The solution is
   realized with a new RFC4585 transport layer feedback message.

8.  Open issues

   A list of open issues.

   o  Describe how clock drift compensation is done
   o  Describe how FEC overhead.  Therefore it is necessary that the media encoder
   takes this overhead into account when the media bitrate is accounted set.
   It is not strictly necessary to make a 100% perfect compensation for in target_bitrate
      computation

   o  Investigate
   the impact of more sparse RTCP feedback, overhead as the SCReAM algorithm will inherently compensate
   moderate errors.  Under-compensation for instance
      once per RTT

   o  Describe ECN behavior

9.  Implementation status

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

   This section records overhead has the status of known implementations of effect
   that the
   protocol defined by this specification at jitter will increase somewhat while overcompensation will
   have the time of posting of this
   Internet-Draft, and is based on a proposal described in [RFC6982]. effect that the bottleneck link becomes under-utilized.

4.2.  SCReAM Receiver

   The description simple task of implementations in this section the SCReAM receiver is intended to
   assist the IETF in its decision processes in progressing drafts feedback
   acknowledgements of received packets, total loss count and total ECN
   count to
   RFCs.  Please note that the listing SCReAM sender.  Upon reception of any individual implementation
   here does not imply endorsement by each RTP packet 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
   exist.

   According to [RFC6982], "this
   receiver will allow reviewers and working groups simply maintain enough information to assign due consideration send the
   aforementioned values to documents that have the benefit of
   running code, which may serve as evidence of valuable experimentation
   and SCReAM sender via RTCP transport layer
   feedback that have made message.  The frequency of the implemented protocols more mature.
   It is up to feedback message depends on
   the individual working groups to use this information as
   they see it".

9.1.  OpenWebRTC available RTCP bandwidth.  The SCReAM algorithm has been implemented details of this feedback is given
   in the OpenWebRTC project
   [OpenWebRTC], an open source WebRTC implementation from Ericsson
   Research. another document.

5.  Discussion

   This SCReAM implementation is usable with any WebRTC
   endpoint using OpenWebRTC.

   o  Organization : Ericsson Research, Ericsson.

   o  Name : OpenWebRTC gst plug-in. section covers a few discussion points

   o  Implementation link : The GStreamer plug-in code for  RTCP feedback overhead: SCReAM can be
      found at github repository [SCReAM-Implementation] and is waiting
      to be merged with the master branch of OpebWebRTC repository
      (https://github.com/EricssonResearch/openwebrtc/pull/413).

      However, people are encouraged to have look at it and send benefits from a relatively frequent
      feedback.  This wiki
      (https://github.com/EricssonResearch/openwebrtc/wiki) contains
      required information for building and using OpenWebRTC.  Note  Experiments have shown that a feedback rate roughly
      equal to get all the SCReAM related code frame rate gives a stable self-clocking and build them, one has to use
      the cerbero fork from DanielLindstrm' s repository
      (https://github.com/DanielLindstrm/cerbero/tree/scream) instead of
      EricssonResearch fork
      robustness against loss of cerbero.

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

   o  Implementation experience : The implementation feedback.  With a maximum bitrate of
      1500kbps the algorithm RTCP feedback overhead is in the OpenWebRTC has given great insight into the algorithm itself
      and its interaction range 10-15kbps with
      reduced size RTCP [RFC5506], including IP and UDP framing, in
      other involved modules such as encoder,
      RTP queue etc.  In fact it proves words the usability of RTCP overhead is quite modest and should not pose
      a self-clocked
      rate adaptation algorithm problem in the real WebRTC system.  The
      implementation experience has led to various algorithm
      improvements both general case.  Other solutions may be required in terms of stability and design.  For example,
      improved rate increase behavior and removal of the ACK vector from
      the feedback message.

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

9.2.  A C++ Implementation of SCReAM

   o  Organization : Ericsson Research, Ericsson.

   o  Name : SCReAM.

   o  Implementation
      highly asymmetrical link : A C++ implementation of SCreAM is also
      available which capacity cases.  Worth notice is aimed for doing quick
      experiments[SCReAM-Cplusplus_Implementation].  This repository
      also includes that
      SCReAM can work with as low feedback rates as once every 200ms,
      this however comes with a rudimentary implementation higher sensitivity to loss of feedback
      and also a simulator.  This
      code can be included potential reduction in other simulators like NS-3. throughput.

   o  Coverage :  AVPF mode: The code implements [I-D.ietf-rmcat-scream-cc]

   o  Contact : ingemar.s.johansson@ericsson.com,
      zaheduzzaman.sarker@ericsson.com

10.  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.

11.  IANA Considerations

   A new RFC4585 transport layer RTCP feedback message needs to be
   standardized.

12.  Security Considerations is based on AVPF regular mode.  The
      SCReAM feedback can be vulnerable to attacks similar to those that can
   affect TCP.  It is therefore recommended that the transmitted as reduced size RTCP feedback so save
      overhead, it is however required to transmit full compound RTCP at
   least integrity protected.

13.  Change history

   A list of changes:
      regular intervals, this interval can be controlled by trr-int
      depicted in [RFC4585].

   o  WG-00 to WG-01 : Changed  Clock drift: SCReAM can suffer from the Source code section same issues with clock
      drift as is the case with LEDBAT [RFC6817].  Section A.2 in said
      RFC however describes ways to mitigate issues with clock drift.

6.  Implementation status section.

   o  -05 to WG-00 : First version of WG doc, moved additional features

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

   This section records the status of prioritization in
      SCReAM.  Added description known implementations of additional cap on target bitrate

   o  -04 to -05 : ACK vector is replaced the
   protocol defined by this specification at the time of posting of this
   Internet-Draft, and is based on a loss counter, PT proposal described in [RFC6982].
   The description of implementations in this section is
      removed from feedback, references intended to source code added

   o  -03
   assist the IETF in its decision processes in progressing drafts to -04 : Extensive changes
   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
   exist.

   According to [RFC6982], "this will allow reviewers and working groups
   to assign due consideration to review comments, code
      somewhat modified, frame skipping documents that have the benefit of
   running code, which may serve as evidence of valuable experimentation
   and feedback that have made optional

   o  -02 the implemented protocols more mature.
   It is up to -03 : Added the individual working groups to use this information as
   they see it".

6.1.  OpenWebRTC

   The SCReAM algorithm description has been implemented in the OpenWebRTC project
   [OpenWebRTC], an open source WebRTC implementation from Ericsson
   Research.  This SCReAM implementation is usable with equations, removed
      pseudo code and simulation results any WebRTC
   endpoint using OpenWebRTC.

   o  -01 to -02  Organization : Updated GCC simulation results Ericsson Research, Ericsson.

   o  -00 to -01  Name : Fixed a few bugs in example OpenWebRTC gst plug-in.

   o  Implementation link : The GStreamer plug-in code

14.  References

14.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., SCReAM can be
      found at github repository [SCReAM-Implementation] and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, July 2003.

   [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, July
              2006.

   [RFC5506]  Johansson, I. and M. Westerlund, "Support for Reduced-Size
              Real-Time Transport Control Protocol (RTCP): Opportunities
              and Consequences", RFC 5506, April 2009.

   [RFC6298]  Paxson, V., Allman, M., Chu, J., and M. Sargent,
              "Computing TCP's Retransmission Timer", RFC 6298, June
              2011.

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

14.2.  Informative References

   [FACK]     "Forward Acknowledgement: Refining TCP Congestion
              Control", 2006.

   [I-D.ietf-rmcat-app-interaction]
              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
              2014.

   [I-D.ietf-rmcat-scream-cc]
              Johansson, I. and Z. Sarker, "Self-Clocked Rate Adaptation
              for Multimedia", draft-ietf-rmcat-scream-cc-00 (work in
              progress), May 2015.

   [I-D.ietf-rmcat-wireless-tests]
              Sarker, Z. and I. Johansson, "Evaluation Test Cases for
              Interactive Real-Time Media over Wireless Networks",
              draft-ietf-rmcat-wireless-tests-00 (work in progress),
              June 2015.

   [I-D.ietf-tcpm-newcwv]
              Fairhurst, G., Sathiaseelan, A., and R. Secchi, "Updating
              TCP to support Rate-Limited Traffic", draft-ietf-tcpm-
              newcwv-13 (work in progress), June 2015.

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

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

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

   [SCReAM-Cplusplus_Implementation]
              "C++ Implementation of SCReAM",
              <https://github.com/EricssonResearch/scream>.

   [SCReAM-Implementation]
              "SCReAM Implementation",
              <https://github.com/DanielLindstrm/openwebrtc-gst-
              plugins/tree/scream>.

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

Appendix A.  Additional features

   This section describes additional features.  They are not required
   for the basic functionality of SCReAM but can improve performance in
   certain scenarios and topologies.

A.1.  Packet pacing

   Packet pacing is used in order to mitigate coalescing i.e. that
   packets are transmitted in bursts.

   Packet pacing is enforced when owd_fraction_avg is greater than 0.1.
   The time interval between consecutive packet transmissions is then
   enforced to equal or higher than t_pace where t_pace is given by the
   equations below.

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

   t_pace = rtp_size * 8 / pace_bitrate

   rtp_size is the size of the last transmitted RTP packet

A.2.  Stream prioritization

   As mentioned in Section 4, the prioritization between several streams
   can be managed in many different ways.  The most simple way is to
   pick RTP packets from the RTP queues in a round-robin fashion.  For
   more advanced scheduling, more advanced algorithms are required.
   Below is described the algorithm that is implemented in the SCReAM
   code Section 9.

   Suppose that we have two video streams, where stream 1 has priority
   1.0 and stream 2 has priority 0.5.  Each stream starts with a credit
   of 0 bytes, credit is given to streams that are not given permission
   to transmit at a given scheduling instant, the credit is considered
   in later transmission instants.

   The steps below outline how transmission and scheduling of the two
   RTP streams can evolve.  For simplicily it is assumed that the stream
   RTP queues contain 1200 byte packets.

   1.  SCReAMs send window allows transmission of 1200 bytes.

       *  The stream waiting
      to be merged with the highest priority is picked, in this case
          it is stream 1.  Stream 1 thus transmit 1200 bytes.

       *  Stream 2 gets its credit increased by 1200*0.5/1.0 = 600 byte
          and thus has a credit of 600 bytes.

   2.  SCReAMs send window allows transmission master branch of another 1200 bytes.

       *  Stream 2 has too little credit (600 bytes) OpebWebRTC repository
      (https://github.com/EricssonResearch/openwebrtc/pull/413).
      However, people are encouraged to transmit a 1200
          byte packet.

       *  Stream 1 is therefore picked again as have look at it has the highest
          priority and thus gets send
      feedback.  This wiki
      (https://github.com/EricssonResearch/openwebrtc/wiki) contains
      required information for building and using OpenWebRTC.  Note that
      to transmit yet another 1200 byte
          packet.

       *  Stream 2 gets its credit increased by 1200*0.5/1.0 = 600 byte get all the SCReAM related code and thus build them, one has a credit to use
      the cerbero fork from DanielLindstrm' s repository
      (https://github.com/DanielLindstrm/cerbero/tree/scream) instead of 1200 bytes.

   3.  SCReAMs send window allows transmission
      EricssonResearch fork of another 1200bytes.

       *  Stream 2 now cerbero.

   o  Coverage : The code implements [I-D.ietf-rmcat-scream-cc].  The
      current implementation has enough credit (1200 bytes) been tuned and tested to transmit a 1200
          byte packet.

       *  Stream 2 thus transmits adapt a 1200 byte packet video
      stream and does not adapt the audio streams.

   o  Implementation experience : The implementation of the algorithm in
      the process
          gets its credit reduced by 1200 byte OpenWebRTC has given great insight into the algorithm itself
      and is then down to a
          credit of 0.

       *  Stream 1 gets its credit increased by 1200*1.0/0.5 = 2400 byte
          and thus has a credit of 2400 bytes.

   4.  SCReAMs send window allows transmission of another 1200 bytes.

       1.  Stream 1 now has interaction with other involved modules such as encoder,
      RTP queue etc.  In fact it proves the highest credit (2400bytes).

       2.  Stream 1 thus transmits usability of a 1200 byte packet and self-clocked
      rate adaptation algorithm in the process
           gets its credit reduced by 1200 byte and is then down real WebRTC system.  The
      implementation experience has led to a
           credit various algorithm
      improvements both in terms of 1200 bytes.

       3.  Stream 2 gets its credit increased by 1200*0.5/1.0 = 600 byte stability and thus has a credit of 600 bytes.

   5.  SCReAMs send window allows transmission design.  For example,
      improved rate increase behavior and removal of another 1200 bytes.

       1.  Stream 1 still has the highest credit (1200 bytes).

       2.  Stream 1 thus transmits a 1200 byte packet and in ACK vector from
      the process
           gets its credit reduced by 1200 byte and feedback message.

   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 then down to also
      available which is aimed for doing quick
      experiments[SCReAM-Cplusplus_Implementation].  This repository
      also includes a
           credit rudimentary implementation of 0.

       3.  Stream 2 gets its credit increased by 1200*0.5/1.0 = 600 byte
           and thus has a credit of 1200bytes.

   6.  SCReAMs send window allows transmission of another 1200 bytes.

       1.  Stream 2 now has simulator.  This
      code can be included in other simulators like NS-3.

   o  Coverage : The code implements [I-D.ietf-rmcat-scream-cc]

   o  Contact : ingemar.s.johansson@ericsson.com,
      zaheduzzaman.sarker@ericsson.com

7.  Acknowledgements

   We would like to thank the highest credit (1200 bytes).

       2.  Stream 2 thus transmits a 1200 byte packet 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 Karen and in the process
           gets its credit reduced by 1200 byte Mirja for patiently reading,
   suggesting improvements and is then down also for asking all the difficult but
   necessary questions.

8.  IANA Considerations

   A new RFC4585 transport layer feedback message needs to a
           credit of 0.

       3.  Stream 1 gets its credit increased by 1200*1.0/0.5 = 2400
           byte and thus has a credit of 2400 bytes. be
   standardized.

9.  Security Considerations

   The procedure above repeats it self.  In the above example it is
   quite easy feedback can be vulnerable to see that stream 1 gets attacks similar to transmit 2 RTP packets for
   every 1 RTP packets those that stream 2 gets to transmit.  The very detais
   of the algoritm can
   affect TCP.  It is found in the C++ code (see Section 9) in the
   module ScreamTx and therefore recommended that the functions getPrioritizedStream(..),
   addCredit(..) and subtractCredit(..).

   The above functionality works relatively well and operates with RTCP feedback is at
   least integrity protected.

10.  Change history

   A list of changes:

   o  WG-01 to WG-02: Complete restructuring of the same speed as RTP packet transmission.  There are however cases
   where rate limited video or very large IR frames makes 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 less efficient.  The adjustPriorities(..) function in
   ScreamTx solves this issue on a longer time scale by means
      SCReAM.  Added description of an additional compensation for deviations in the measured transmit cap on target bitrate of the individual streams.

   Prioritization mechanisms of sources that may be highly variant

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

   o  -03 to -04 : Extensive changes due to achieve.  The above outlined algorithm
   manages it review comments, code
      somewhat modified, frame skipping made optional

   o  -02 to some degree but it is quite likely that the -03 : Added algorithm
   needs description with equations, removed
      pseudo code and simulation results

   o  -01 to be refined further.

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

   The Q bit in the feedback is set by a receiver -02 : Updated GCC simulation results

   o  -00 to signal that the
   sender should reduce the bitrate.  The sender will -01 : Fixed a few bugs in example code

11.  References

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in response RFCs to
   this reduce the congestion window with the consequence that the video
   bitrate decreases. Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A typical use case Transport Protocol for source quench is when a
   receiver receives streams from sources located at different hosts 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,
              <http://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, <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,
              <http://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,
              <http://www.rfc-editor.org/info/rfc6817>.

11.2.  Informative References

   [I-D.ietf-rmcat-app-interaction]
              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
              2014.

   [I-D.ietf-rmcat-cc-codec-interactions]
              Zanaty, M., Singh, V., Nandakumar, S., 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 Z. Sarker,
              "Congestion Control and Codec interactions 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 RTP
              Applications", draft-ietf-rmcat-cc-codec-interactions-01
              (work in progress), October 2015.

   [I-D.ietf-rmcat-coupled-cc]
              Islam, S., Welzl, M., and S. Gjessing, "Coupled congestion window
              control for the flow that had the Q bit set RTP media", draft-ietf-rmcat-coupled-cc-00
              (work 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 progress), September 2015.

   [I-D.ietf-rmcat-scream-cc]
              Johansson, I. and Z. Sarker, "Self-Clocked Rate Adaptation
              for Multimedia", draft-ietf-rmcat-scream-cc-01 (work 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
              progress), July 2015.

   [I-D.ietf-rmcat-wireless-tests]
              Sarker, Z. and I. Johansson, "Evaluation Test Cases for
              Interactive Real-Time Media over Wireless Networks",
              draft-ietf-rmcat-wireless-tests-00 (work in one RTT

   o  n_q = Number of received RTCP feedback messages progress),
              June 2015.

   [I-D.ietf-tcpm-newcwv]
              Fairhurst, G., Sathiaseelan, A., and R. Secchi, "Updating
              TCP to support Rate-Limited Traffic", draft-ietf-tcpm-
              newcwv-13 (work in one RTT, progress), June 2015.

   [Khademi_alternative_backoff_ECN]
              "TCP Alternative Backoff 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 ECN (ABE)",
              <https://tools.ietf.org/html/draft-khademi-
              alternativebackoff-ecn-00>.

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

   [PACKET_CONSERVATION]
              "Congestion Avoidance and Control", 1988.

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

   [RFC6679]  Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P.,
              and K. Carlberg, "Explicit Congestion Notification (ECN)
              for one RTT if CWND has been
   decreased as a result 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 Q bits set in the feedback. Running
              Code: The required intensity Implementation Status Section", RFC 6982,
              DOI 10.17487/RFC6982, July 2013,
              <http://www.rfc-editor.org/info/rfc6982>.

   [SCReAM-Cplusplus_Implementation]
              "C++ Implementation of SCReAM",
              <https://github.com/EricssonResearch/scream>.

   [SCReAM-Implementation]
              "SCReAM Implementation",
              <https://github.com/DanielLindstrm/openwebrtc-gst-
              plugins/tree/scream>.

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

Appendix A.  Additional features

   This section describes additional features.  They are not required
   for 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 basic functionality of SCReAM but can improve performance in the received video bitrate on the different streams
   certain scenarios and
   adjust the intensity of the Q-bit accordingly.

A.4.  Frame skipping

   Frame skipping is a feature that topologies.

A.1.  Stream prioritization

   The SCReAM algorithm makes it possible to reduce the size
   of a good distinction between network
   congestion control and the media rate control, an RTP queue queues up
   RTP packets pending transmission.  This is easily extended to many
   streams, in the cases that e.g. the channel throughput drops
   dramatically which case RTP packets from two or even goes below more RTP queues are
   scheduled at the lowest possible video coder rate.
   Frame skipping is optional to implement as it can sometimes be
   difficult to realize e.g. due to lack of API function to support
   this.

   Frame skipping is controlled rate permitted by a flag frame_skip which, if set to 1
   dictates that the video coder should skip network congestion control.

   The scheduling can be done by means of a few different scheduling
   regimes.  For example the next video frame. method applied in
   [I-D.ietf-rmcat-coupled-cc] can be used.  The
   frame skipping intensity at the current time instant implementation of
   SCReAM use something that is computed
   according referred to the steps below as credit based scheduling.
   Credit based scheduling is for instance implemented in IEEE 802.17.
   The queuing delay short description is sampled every frame period that credit is accumulated by queues as they
   wait for service and are spent while the last 20
   samples queues are stored in a vector age_vec

   An average queuing delay being services.

   For instance, if one queue is computed as allowed to transmit 1000bytes, then a weighted sum over the
   samples in age_vec. age_avg at the current time instant
   credit of 1000bytes is computed
   as

   age_avg(n) = SUM age_vec(n-k)*w(k) k = [0..20[

   w(n) are weight factors arranged allocated to give the most recent samples a
   higher weight.

   The change other unscheduled queues.
   This principle can be extended to weighted scheduling in age_avg is computed as

   age_d = age_avg(n) - age_avg(n-1)

   The frame skipping intensity at which case
   the current time instant n is
   computed as

   o  If age_d > 0 and age_avg > 2*FRAME_PERIOD:
      frame_skip_intensity = min(1.0, (age_vec(n)-2*FRAME_PERIOD)/(4*
      FRAME_PERIOD)

   o  Otherwise frame skip intensity is set credit allocated to zero

   The skip_frame flag is set depending unscheduled queues depends on three variables

   o  frame_skip_intensity

   o  since_last_frame_skip, i.e the number of consecutive frames
      without frame skipping

   o  consecutive_frame_skips, i.e the number weight
   allocation.

A.2.  Computation of consecutive frame skips autocorrelation function

   The flag skip_frame autocorrelation function is set to 1 if any computed over a vector of values.

   Let x be a vector constituting N values, the conditions below is
   met, otherwise it is set to 0.

   o  age_vec(n) > 0.2 && consecutive_frame_skips < 5

   o  frame_skip_intensity < 0.5 && since_last_frame_skip >= 1.0/
      frame_skip_intensity

   o  frame_skip_intensity >= 0.5 && consecutive_frame_skips <
      (frame_skip_intensity -0.5)*10

   The arrangement makes sure that no more than 4 frames are skipped in
   sequence, autocorrelation function
   for a given lag=k for the rationale vector x is to ensure that the input to the video
   encoder does not change to much, something that may give poor
   prediction gain. given by .

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

                    Figure 2: Autocorrelation function

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