[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05                                             
RMCAT WG                                                    I. Johansson
Internet-Draft                                                 Z. Sarker
Intended status: Informational                               Ericsson AB
Expires: April 30, 2015                                 October 27, 2014

              Self-Clocked Rate Adaptation for Multimedia


   This memo describes a rate adaptation framework for conversational
   video services.  The solution conforms to the packet conservation
   principle and uses a hybrid loss and delay based congestion control
   algorithm.  The framework is evaluated over both simulated 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 April 30, 2015.

Copyright Notice

   Copyright (c) 2014 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

Johansson & Sarker       Expires April 30, 2015                 [Page 1]

Internet-Draft                   SCReAM                     October 2014

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Wireless (LTE) access properties  . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  The adaptation framework  . . . . . . . . . . . . . . . . . .   4
     3.1.  Congestion control  . . . . . . . . . . . . . . . . . . .   7
     3.2.  Transmission scheduling . . . . . . . . . . . . . . . . .   8
     3.3.  Media rate control  . . . . . . . . . . . . . . . . . . .   8
   4.  Detailed description  . . . . . . . . . . . . . . . . . . . .   8
     4.1.  Network congestion control  . . . . . . . . . . . . . . .   8
       4.1.1.  Congestion window update  . . . . . . . . . . . . . .   9  Initial steps . . . . . . . . . . . . . . . . . .   9  Loss event is detected  . . . . . . . . . . . . .  11  If in_exponential_start = true and no loss event
                   detected  . . . . . . . . . . . . . . . . . . . .  11  If in_exponential_start = false and no loss event
                   detected  . . . . . . . . . . . . . . . . . . . .  11  Fairness enforcement  . . . . . . . . . . . . . .  11  Final CWND adjustment step  . . . . . . . . . . .  12  Competing flows compensation, adjustment of
                   owd_target  . . . . . . . . . . . . . . . . . . .  12
       4.1.2.  Transmission scheduling . . . . . . . . . . . . . . .  13  Transmission decision . . . . . . . . . . . . . .  13  Next transmission attempt . . . . . . . . . . . .  14
     4.2.  Video rate control  . . . . . . . . . . . . . . . . . . .  14
       4.2.1.  Frame skipping  . . . . . . . . . . . . . . . . . . .  15
       4.2.2.  Rate change . . . . . . . . . . . . . . . . . . . . .  16  Reduce rate . . . . . . . . . . . . . . . . . . .  17  Increase rate . . . . . . . . . . . . . . . . . .  18
   5.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . .  19
   6.  Open issues . . . . . . . . . . . . . . . . . . . . . . . . .  20
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  20
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  20
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  20
   10. Change history  . . . . . . . . . . . . . . . . . . . . . . .  20
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  20
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  21
     11.2.  Informative References . . . . . . . . . . . . . . . . .  21
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  22

Johansson & Sarker       Expires April 30, 2015                 [Page 2]

Internet-Draft                   SCReAM                     October 2014

1.  Introduction

   Rate adaptation is considered as an important part of a interactive
   realtime communication as the transmission channel bandwidth may vary
   over period of time.  Wireless access such as LTE (Long Term
   Evolution), which is an integral part of the current Internet,
   increases the importance of rate adaptation as the channel bandwidth
   of a default LTE bearer [QoS-3GPP] can change considerably in a very
   short time frame.  Thus a rate adaptation solution for interactive
   realtime media, such as WebRTC, in LTE system must be both quick and
   be able to operate over a large span in available channel bandwidth.
   This memo describes a solution that borrows the self-clocking
   principle of TCP and combines it with 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 with in this
   context.  This memo describes these extra features.

1.1.  Wireless (LTE) access properties

   [I-D.draft-sarker-rmcat-cellular-eval-test-cases] introduces 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 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, 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",
   document are to be interpreted as described in RFC2119 [RFC2119]

Johansson & Sarker       Expires April 30, 2015                 [Page 3]

Internet-Draft                   SCReAM                     October 2014

3.  The adaptation framework

   The adaptation framework has similarities to concepts like TFWC
   [TFWC].  One important property is self-clocking and compliance to
   the packet conservation 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 a vector
   of the sequence numbers of received packets in the feedback 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 bytes can be transmitted.  A congestion window
   puts an upper limit on how many bytes can be in flight, i.e.
   transmitted but not yet acknowledged.  The congestion window is
   determined in a way similar to LEDBAT [RFC6817].  This 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.  These will be briefly described in
   sections Section 3.1 to Section 3.3.

   The feedback is over RTCP [RFC3550] and is based on [RFC4585].  It is
   implemented as a transport layer feedback message, see proposed
   example in Figure 1.  The feedback control information part (FCI)
   consists of the following elements.

   o  Timestamp: A timestamp value indicating when the last packet was
      received which makes it possible to compute the one way (extra)
      delay (OWD).

   o  The ACK list (Highest received sequence number + ACK vector):
      Makes it possible to detect lost packets and determine the number
      of bytes in flight.

   o  Source quench bit (Q): Makes it possible to request the sender to
      reduce its congestion window.  This is useful if WebRTC media is
      received from many hosts and it becomes necessary to balance the
      bitrates between the streams.  The exact behavior and use for the
      source quench bit is T.B.D.

   o  ECE (Explicit Congestion Notification) echo: Makes it possible to
      indicate if packets are ECN-CE (ECN Congestion Experienced)
      marked.  The use for the ECN echo bits is T.B.D.

Johansson & Sarker       Expires April 30, 2015                 [Page 4]

Internet-Draft                   SCReAM                     October 2014

       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                         |
      |                    Timestamp (32bits)                         |
      | Highest recv. seq. nr. (16b)  |ECN echo       |Q|R|R|R|R|R|R|R|
      |                    ACK vector (32b)                           |

                Figure 1: 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 base is typically set to the same time base
   as the media source in question but as the protocol described here is
   not dependent on the media it can be set to a fixed value defined in
   this specification.  The ACK vector is here a bit vector that
   indicates the reception of the last 1+32 = 33 RTP packets.

   Section 4 describes the main algorithm details and how the feedback
   is used.

Johansson & Sarker       Expires April 30, 2015                 [Page 5]

Internet-Draft                   SCReAM                     October 2014

        ----------------------------    -----------------------------
        |       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 2: Rate adaptation framework

Johansson & Sarker       Expires April 30, 2015                 [Page 6]

Internet-Draft                   SCReAM                     October 2014

   Figure 2 shows the functional overview of the adaptation framework.
   Each media type or source implements rate control and a queue, where
   RTP packets containing encoded media frames are temporarily stored
   for transmission, the figure shows the details for when two video
   sources are used.  Video frames are encoded and forwarded to the
   queue (2).  The media rate adaptation adapts to the age of the oldest
   RTP frame in the queue and controls the video bitrate (1).  It is
   also possible to make the video encoder skip frames and thus
   temporarily reduce the frame rate if the queue age exceeds a given
   threshold (3).  The RTP packets are picked from each queue based on
   some defined priority order or simply in a round robin fashion (5).
   A transmission scheduler takes care of the transmission of RTP
   packets, to be written to the UDP socket (6).  In the general case
   all media must go through the packet scheduler and is allowed to be
   transmitted if the number of bytes in flight is less than the
   congestion window.  However audio frames can be allowed to be
   transmitted as audio is typically low bitrate and thus contributes
   little to congestion, this is however something that is left as an
   implementation choice.  RTCP packets are received (7) and the
   information about bytes in flight and congestion window is exchanged
   between the network congestion control and the transmission scheduler

   The rate adaptation solution constitutes three parts; congestion
   control, transmission scheduling and media rate adaptation.

3.1.  Congestion control

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

   A congestion control method, similar to LEDBAT [RFC6817], measures
   the OWD (one way delay).  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 is designed with file transfers as main use case which means
   that the algorithm must be modified somewhat to work with rate-
   limited sources such as video.  The modifications are

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

Johansson & Sarker       Expires April 30, 2015                 [Page 7]

Internet-Draft                   SCReAM                     October 2014

   o  Fast start for bitrate increase.  It makes the video bitrate ramp-
      up within 5 to 10 seconds.  The behavior is similar to TCP
      slowstart.  The fast start is exited when congestion is detected.

   o  Adaptive delay target.  This helps the congestion control to
      compete with FTP traffic to some degree.

3.2.  Transmission scheduling

   Transmission scheduling limits the output of data, given by the
   relation between the number of bytes in flight and the congestion
   window similar to TCP.  Packet pacing is used to mitigate issues with
   coalescing that may cause increased jitter 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 prompt in order to avoid
   getting too much data queued up in the sender frame queues.  The
   queuing delay is determined and the media bitrate is decreased if it
   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 necessary to
   implement additional actions, such as discarding of encoded video
   frames or frame skipping in order to ensure that the sender frame
   queues are drained quickly.  Frame skipping means that the frame rate
   is temporarily reduced.  Discarding of old video frames is a more
   efficient way to reduce media latency than frame skipping but it
   comes with a requirement to repair codec state, frame skipping is
   thus to prefer as a first remedy.

4.  Detailed description

   This section describes the algorithm in more detail.  It is split
   between the network congetsion control and the video rate adaptation.

4.1.  Network congestion control

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

   o  Computation of congestion window: Gives an upper limit to the
      number of bytes in flight i.e. how many bytes that have been
      transmitted but not yet acknowledged.

Johansson & Sarker       Expires April 30, 2015                 [Page 8]

Internet-Draft                   SCReAM                     October 2014

   o  Transmission scheduling: RTP packets are transmitted if allowed by
      the relation between the number of bytes in flight and the
      congestion window

   Unlike TCP, SCReAM is not a byte oriented protocol, rather it is an
   RTP packet oriented protocol.  Thus it keeps a list of transmitted
   RTP packets and their respective sending times (wall-clock time).
   The feedback indicates the highest received RTP sequence number and a
   timestamp (wall-clock time) when it was received.  In addition, an
   ACK list is included to make it possible to determine lost packets

4.1.1.  Congestion window update

   Below is described the actions when an acknowledgement is received.  Initial steps

   Bytes in flight (bytes_in_flight) is computed as the sum of the sizes
   of the RTP packets ranging from the RTP packet most recently
   transmitted up to but not including the acknowledged packet with the
   highest sequence number.  As an example: If RTP packet was sequence
   number SN with transmitted and the last ACK indicated SN-5 as the
   highest received sequence number then bytes in flight is computed as
   the sum of the size of RTP packets with sequence number SN-4, SN-3,
   SN-2, SN-1 and SN.

   The congestion window is computed from the one way (extra) delay
   estimates (OWD) that are obtained from the send and received
   timestamp of the RTP packets.  LEDBAT [RFC6817] explains the details
   of the computation of the OWD.  An OWD sample is obtained for each
   received acknowledgement.  No smoothing of the OWD samples occur,
   however some smoothing occurs naturally as the computation of the
   CWND is in itself a low pass filter function.

   A variable bytes_newly_acked depicts the number bytes that was
   acknowledged with the last received acknowledgement.

   owd_mem is an EWMA (Exponential Weighted Moving Average) filtered OWD

   owd_mem = max(owd_mem*0.5 + owd*0.5, owd_mem*0.9 + owd*0.1)

   The OWD fraction is computed as

   owd_fraction = owd/owd_target

   where owd_target is the target (extra) delay, owd_target is typically
   set to owd_target_lo=0.1s but can in certain cases increase to
   owd_target_hi=0.4s.  The OWD fraction is sampled every 50ms and the

Johansson & Sarker       Expires April 30, 2015                 [Page 9]

Internet-Draft                   SCReAM                     October 2014

   last 20 samples are stored in a vector (owd_fraction_hist).  This
   vector is used in the computation of an OWD trend that gives a value
   between 0.0 and 1.0 depending on how close to congestion it gets.
   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 is
   formulated as

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

   The prediction coefficient a has positive values if OWD shows an
   increasing trend, thus one get an indication of congestion before the
   OWD target is reached.  The prediction coefficient is further
   multiplied with owd_fraction to reduce sensitivity to increasing OWD
   when OWD is small.  The OWD trend is thus computed as

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

   The owd_trend is utilized in the media rate control and to determine
   when to exit slow start.

   An EWMA filtered version of owd_trend is computed

   owd_trend_ewma=max(owd_trend, owd_trend_ewma*(1.0-alpha)+
   alpha* owd_trend)

   alpha = (t_now-t_cwnd_update_prev) / 5000.0

   t_now is the current wall clock time.

   owd_fraction_avg is a lowpass filtered version of owd_fraction

   owd_fraction_avg = 0.9* owd_fraction_avg + 0.1* owd_fraction

   An off target value is computed as

   off_target = (owd_target - owd) / owd_target

   CWND is updated differently depending on whether the congestion
   control is in fast start or not and if a loss event is detected.  A
   Boolean variable in_exponential_start (initialized to true) indicates
   if the congestion is in fast start.

   A loss event indicates one or more lost RTP packets within an RTT.
   This is detected by means of inspection for holes in the sequence
   number space in the acknowledgements with some margin for possible
   packet reordering in the network.

Johansson & Sarker       Expires April 30, 2015                [Page 10]

Internet-Draft                   SCReAM                     October 2014  Loss event is detected

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

   cwnd = max(min_cwnd,cwnd*0.8) where min_cwnd = 2*mss

   otherwise the CWND update continues  If in_exponential_start = true and no loss event detected

   in_exponential_start is set to false if owd_trend >= 0.2 and
   otherwise CWND is updated according to

   cwnd = cwnd + bytes_newly_acked  If in_exponential_start = false and no loss event detected

   Values of off_target > 0.0 indicates that the congestion window can
   be increased.  This is done according to the equations below (mss is
   the maximum RTP packet size).

   gain = gain_up*(1.0 + max(0.0, 1.0 - owd_trend/ 0.2))

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

   Values of off_target <= 0.0 indicates congestion, CWND is then
   updated according to the equation

   cwnd += gain_down*off_target*bytes_newly_acked*mss/cwnd  Fairness enforcement

   Fairness enforcement is realized by reducing the congestion window by
   a fraction when a number of conditions are met.  They are

   o  owd_target < owd_target_lo*1.2 i.e no competing flows are
      compensated for

   o  owd_trend > 0.1 i.e. congestion is detected

   o  more than t_delta since the congestion window was reduced the last

   t_delta is computed as

   t_delta = 0.1*min(200.0, max(20.0, 50.0e6/max_paced_bitrate)

Johansson & Sarker       Expires April 30, 2015                [Page 11]

Internet-Draft                   SCReAM                     October 2014

   The bitrate is taken into account in the sense that the lower the
   bitrate, the more sparse the reductions in congestion window get.

   If the above conditions are met then cwnd is adjusted according to

   cwnd *= 0.8  Final CWND adjustment step

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

   cwnd = min(cwnd, max_bytes_in_flight*max_bytes_in_flight_head_room)

   where max_bytes_in_flight_head_room = 1.1.  This 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)  Competing flows compensation, adjustment of owd_target

   In certain cases it becomes necessary to increase owd_target, one
   such case is where SCReAM competes with TCP based file transfer over
   a tail drop bottleneck link and the TCP congestion avoidance is loss
   based (for example Cubic or NewReno).  The technique is to inhibit
   video long enough to make bytes in flight reach zero (no remaining
   RTP packets in flight) and then resume video.  For the unfortunate
   case that the last RTP packet was lost, it is necessary to force
   video to resume after 1.0s as bytes in flight will never reach zero
   in this case.

   This interruption is typically in the order of one RTT.  Once video
   is resumed the average OWD (owd_avg_c_flow) is computed over the
   first 5 acknowledgements after video is resumed.  If no competing
   flows exist then this average should be close to zero, otherwise
   owd_avg_c_flow has a value that corresponds roughly to the queuing
   delay caused by the competing flow.  The owd_target is updated
   according to the value of owd_avg_c_flow.

   The method above is executed if more than a given time since the last
   time video was inhibited (e.g. 20 seconds) and any of the two
   conditions below are fulfilled

   o  owd_mem > owd_target

   o  owd_target > owd_target_lo

Johansson & Sarker       Expires April 30, 2015                [Page 12]

Internet-Draft                   SCReAM                     October 2014

   The first condition indicates that another competing flows is
   possibly driving higher queuing delays in the network.  The second
   condition indicates that the OWD target is increased and it should be
   determined if this can be lowered.  Once owd_avg_c_flow is computed
   the owd_target is adjusted.  The adjustment action depends on the
   value of owd_avg_c_flow

   o  If owd_avg_c_flow > owd_target_lo/2:
      Adjust the owd_target upwards according to
      owd_target = min(owd_target_hi,
      max(owd_target, owd_avg_c_flow *3.0))

   o  If owd_avg_c_flow <= owd_target_lo/2:
      Adjust the owd_target downwards according to
      owd_target = 0.5*owd_target+
      0.5*Math.max(owd_target_lo, owd_avg_c_flow).
      Furhermore owd_target is set to owd_target_lo if it is less than

4.1.2.  Transmission scheduling

   An RTP packet transmission attempt is scheduled at intervals given by
   t_pace that depends on the estimated throughput, the RTT and the size
   of the last transmitted RTP packet.  This provides with packet pacing
   which is in some cases necessary in order to break up coalescing
   tendencies which can otherwise cause unwanted extra jitter or packet
   loss.  Transmission decision

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

   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 as the congestion window puts a too hard restriction on
      the video frame size variation, this further can lead to
      occasional queuing of RTP packets in the RTP packet queue that
      will prevent bitrate increase because of the increased queuing

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

Johansson & Sarker       Expires April 30, 2015                [Page 13]

Internet-Draft                   SCReAM                     October 2014

      clocking is temporarily halted, even though the forward path is
      not congested.

   Transmission of an RTP packet of size rtp_size is thus allowed when
   any of the following conditions is met.

   o  If owd > owd_target:
      Transmission is allowed if
      bytes_in_flight + rtp_size <= cwnd.
      This enforces a strict rule that helps to prevent further queue

   o  If owd <= owd_target:
      A helper variable
      is computed.  Transmission is allowed if
      bytes_in_flight+rtp_size <= max(cwnd*x_cwnd, cwnd+mss) .
      This gives a slack that reduces as congestion increases,
      bytes_in_flight_slack is a maximum allowed slack in percent.
      A large value such as 100% increases the robustness to bitrate
      variations in the source and congested feedback channel issues.
      The possible drawback is increased delay or packet loss when
      forward path congestion occur.  Recommended values are 20 to 50%.  Next transmission attempt

   The interval until the next transmission attempt (t_pace) is set to
   0.001s if no RTP packet was transmitted according to the decision in
   previous section.  Otherwise it is calculated as

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

   t_pace = rtp_size * 8 / max_paced_bitrate

4.2.  Video rate control

   The video rate control is based on the queuing delay in the RTP
   packet queue and loss events.  The video rate control function is
   executed for each video frame.  The actual video rate adjustment may
   however be less frequent.  The main reason is that there is typically
   a lag between the bitrate request and the actual bitrate from the
   video coder and this lag can be as much as 1 second.  This makes it
   less efficient to try to react to congestion with prompt rate
   adjustments.  The solution is to complement the rate reduction with
   frame skipping in order to keep the RTP queuing delay limited.

Johansson & Sarker       Expires April 30, 2015                [Page 14]

Internet-Draft                   SCReAM                     October 2014

   The queuing delay is sampled every frame period and the last N_a
   samples are stored in a vector age_vec.

   An average queuing delay is computed as a weighted sum over the
   samples in age_vec. age_avg at the current time instant n is computed

   age_avg(n) = SUM age_vec(n-k)*w(k)

   The sum is computed over k=[0..N_a-1]

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

   N_a i.e. the number of samples that avg_age is computed over, depends
   on how slow the video encoder is to respond to video rate change
   requests.  With a slow video encoder N_a is suggested to be set to

   N_a = 1.0/frame_period

   where frame_peridod is the video frame interval, 1.0 corresponds
   roughly to the time constant in the video coder rate control loop

   If the video encoder is quicker to react to bitrate changes, N_a can
   be set to a lower value such as N_a = 5.

   avg_age is used for rate adjustment instead of the current value, the
   reason is to avoid bitrate reduction because of temporal delay
   spikes.  Instead the video rate control is a combination of slower
   rate adjustments and adjustments of the temporal frame rate by means
   of raw frame skipping on a shorter time scale.  This is an adaptation
   to SCReAM as it works best when it has data to send because of its
   self-clocking properties.  The concept also avoids very large rate
   reduction due to isolated delay spikes.

   The change in age_avg is computed as

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

4.2.1.  Frame skipping

   Frame skipping is controlled by a flag frame_skip which, if set to 1,
   dictates that the video coder should skip the next video frame.  The
   frame skipping intensity at the current time instant n is computed as

   o  If age_d > 0 and age_avg > frame_period:
      The frame skip intensity is computed as

Johansson & Sarker       Expires April 30, 2015                [Page 15]

Internet-Draft                   SCReAM                     October 2014

      frame_skip_intensity = min(1.0, (age_vec(n)-frame_period)/(2*

   o  Otherwise frame skip intensity is set to zero

   Note that the frame skipping intensity is computed based on the
   current value of the queuing delay.  Furthermore, frame skipping is
   enabled only if the average queue delay increases and is large

   The skip_frame flag is set depending 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 of consecutive frame skips

   The flag skip_frame is set to 1 if any of the conditions below is

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

   o  frame_skip_intensity < 0.5 && since_last_frame_skip >= 1.0/

   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, the rationale is to ensure that the input to the video
   encoder does not change to much, something that may give poor
   prediction gain.

4.2.2.  Rate change

   A variable target_bitrate is adjusted depending on the congestion
   state.  The target bitrate can vary between a minimum value
   (target_bitrate_min) and a maximum value (target_bitrate_max).

   First of all the target_bitrate is updated if a new loss event was
   indicated and the rate change procedure is exited.

   target_bitrate = max(0.9* target_bitrate, target_bitrate_min)

   If no loss event was indicated then the rate change procedure
   continues.  Based on age_avg(n) and the time span since the last rate

Johansson & Sarker       Expires April 30, 2015                [Page 16]

Internet-Draft                   SCReAM                     October 2014

   reduction.  A rate reduction condition is determined.  This is
   evaluated differently depending on whether an ideal video coder is
   simulated for algorithm evaluation purposes or if the algorithm is
   executed in a real implement with a video coder that lags behind in
   the rate adjustment.

   o  Ideal mode: reduce_rate = age_avg(n) > frame_period/2 && t_now-
      t_last_rate_change >= rate_change_interval && t_now-
      t_last_rate_reduction > 0.5

   o  Non-ideal mode: reduce_rate = age_avg(n) > frame_period*2 &&
      t_now-t_last_rate_change >= rate_change_interval && t_now-
      t_last_rate_reduction > video_coder_time_constant

   rate_change_interval is set to 0.1s, video_coder_time_constant is set
   to a value that approximates the lag in the video coder rate change.  Reduce rate

   If reduce_rate evaluates to true then the bitrate is reduced.  First
   an inflection point is determined for later rate increase

   target_bitrate_i = target_bitrate * 0.95

   In addition, a restore point is determined for the case that false
   congestion was detected, for instance as an effect of congestion in
   the feedback path.

   target_bitrate_restore_point = target_bitrate

   A few varibles are updated for future use

   t_last_rate_change = t_now

   max_owd_fraction = max(max_owd_fraction, owd_fraction_avg)

   A rate reduction factor is determined

   alpha = min(0.5, max(0.0, 0.9*age_d))

   The target bitrate and t_last_rate_reduction are updated if
   alpha > 0.0 according to

   target_bitrate = max(target_bitrate_min, target_bitrate*(1.0-alpha))

Johansson & Sarker       Expires April 30, 2015                [Page 17]

Internet-Draft                   SCReAM                     October 2014  Increase rate

   A rate increase is allowed if two conditions are met

   o  t_now-t_last_rate_change >= rate_change_interval

   o  age_avg(n) <= frame_period/2

   First the target bitrate is restored if false congestion was
   detected.  This restoration is allowed if it it is more that 2.0s
   since the last loss event and target_bitrate_restore_point > 0.0.
   Further, if an additional condition

   do_restore = max_owd_fraction < 0.4 && owd_trend_ewma < 0.2

   evaluates to true then the target bitrate is restored as

   target_bitrate = max(target_bitrate, target_bitrate_restore_point)

   Regardless of whether do_restore evaluates to true or false
   target_bitrate_restore_point is set to -1.0 and max_owd_fraction =
   0.0 The target bitrate is increased, the increase rate depends on if
   the algorithm is in slow start or not, indicated by the variable
   in_exponential_start.  If in_exponential_start = true

   The bitrate incremented is computed as

   increment =
   (1.0-min(1.0, owd_trend/0.1))

   target_bitrate = min(target_bitrate_max, target_bitrate+increment))

   The target bitrate is allowed to reach the the highest bitrate within
   ramp_up_time_fast seconds if no congestion is detected.  A
   recommended value for ramp_up_time_fast is 10.0s.  If in_exponential_start = false

   The maximum allowed increment of the target bitrate is computed

   increment_max = target_bitrate*0.2

   A variable gain factor is computed in a number of steps, first the
   gain factor is reduced if the target bitrate is close to the

Johansson & Sarker       Expires April 30, 2015                [Page 18]

Internet-Draft                   SCReAM                     October 2014

   inflection point i.e. the target bitrate when congestion was last

   gain = max(0.2,min(1.0, abs((target_bitrate - target_bitrate_i)/

   Furthermore the gain is reduced if near (or past) congestion is

   gain *= min(1.0, max(0.0,(1.0-owd_trend_ewma)))

   The gain is increased if competing (potentially aggressive) flows are
   detected, this is indicated by that owd_target/owd_target_lo > 1.0

   gain *= owd_target/owd_target_lo

   A ramp-up speed is computed that is adjusted depending on the
   estimated congestion level

   ramp_up_time = ramp_up_time_fast+(ramp_up_time_slow-
   max(0.0,Math.min(1.0, owd_trend_ewma /0.2))

   A recommended value for ramp_up_time_slow is 20.0s.  The increment is
   computed and the target_bitrate is updated

   increment = min(target_bitrate_max*gain*rate_change_interval

   target_bitrate = min(target_bitrate_max, target_bitrate +increment)

5.  Conclusion

   This memo describes a congestion control framework for RMCAT that it
   is particularly good at handling the quickly changing condition in
   wireless network such as LTE.  The solution conforms to the packet
   conservation principle and leverages on novel congestion control
   algorithms and recent TCP research, together with media bitrate
   determined by sender queuing delay and given delay thresholds.  The
   solution has shown potential to meet the goals of high link
   utilization and prompt reaction to congestion.  The solution is
   realized with a new RFC4585 transport layer feedback message.

Johansson & Sarker       Expires April 30, 2015                [Page 19]

Internet-Draft                   SCReAM                     October 2014

6.  Open issues

   A list of open issues.

   o  Describe use of Q bit

   o  Describe how clock drift compensation is done

   o  RTCP AVPF mode.  Determine if AVPF early or immediate mode is to

   o  Determine format and use of ECN echo field

7.  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, Laurits Hamm, Hans Hannu,
   Nikolas Hermanns, Stefan Haekansson, Erlendur Karlsson, Mats
   Nordberg, Jonathan Samuelsson, Rickard Sjoeberg, Magnus Westerlund.

8.  IANA Considerations

   A new RFC4585 transport layer feedback message needs to be

9.  Security Considerations

   The feedback can be vulnerable to attacks similar to those that can
   affect TCP.  It is therefore recommended that the RTCP feedback is at
   least integrity protected.

10.  Change history

   A list of changes:

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

   o  -01 to -02 : Updated GCC simulation results

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

11.  References

Johansson & Sarker       Expires April 30, 2015                [Page 20]

Internet-Draft                   SCReAM                     October 2014

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

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

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

11.2.  Informative References

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

              Holmer, S., Cicco, L., Mascolo, S., and H. Alvestrand, "A
              Google Congestion Control Algorithm for Real-Time
              Communication", draft-alvestrand-rmcat-congestion-02 (work
              in progress), February 2014.

              Sarker, Z., "Evaluation Test Cases for Interactive Real-
              Time Media over Cellular Networks",

              Fairhurst, G., Sathiaseelan, A., and R. Secchi, "Updating
              TCP to support Rate-Limited Traffic", draft-ietf-tcpm-
              newcwv-07 (work in progress), September 2014.

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

Johansson & Sarker       Expires April 30, 2015                [Page 21]

Internet-Draft                   SCReAM                     October 2014

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

Authors' Addresses

   Ingemar Johansson
   Ericsson AB
   Laboratoriegraend 11
   Luleae  977 53

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

   Zaheduzzaman Sarker
   Ericsson AB
   Laboratoriegraend 11
   Luleae  977 53

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

Johansson & Sarker       Expires April 30, 2015                [Page 22]