[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: December 20, 2014                                 June 18, 2014


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

Abstract

   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 December 20, 2014.

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 December 20, 2014               [Page 1]


Internet-Draft                   SCReAM                        June 2014


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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Wireless (LTE) access properties  . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  The adaptation framework  . . . . . . . . . . . . . . . . . .   3
     3.1.  Congestion control  . . . . . . . . . . . . . . . . . . .   7
     3.2.  Transmission scheduling . . . . . . . . . . . . . . . . .   8
     3.3.  Media rate control  . . . . . . . . . . . . . . . . . . .   8
   4.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . .   8
   5.  Open issues . . . . . . . . . . . . . . . . . . . . . . . . .   9
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   9.  Change history  . . . . . . . . . . . . . . . . . . . . . . .   9
   10. Algorithm details . . . . . . . . . . . . . . . . . . . . . .  10
     10.1.  Sender side functions  . . . . . . . . . . . . . . . . .  10
       10.1.1.  RTP packet queue handling (a.k.a Sender queue) . . .  10
       10.1.2.  Transmission scheduler . . . . . . . . . . . . . . .  11
       10.1.3.  Reception of RTCP feedback in sender . . . . . . . .  13
       10.1.4.  Congestion window adjustment . . . . . . . . . . . .  15
       10.1.5.  Video encoder  . . . . . . . . . . . . . . . . . . .  16
       10.1.6.  Video encoder rate adaptation  . . . . . . . . . . .  17
     10.2.  Receiver side functions  . . . . . . . . . . . . . . . .  19
       10.2.1.  Reception of RTP packet  . . . . . . . . . . . . . .  19
   11. Simulations . . . . . . . . . . . . . . . . . . . . . . . . .  19
     11.1.  DL . . . . . . . . . . . . . . . . . . . . . . . . . . .  21
       11.1.1.  RTT 40ms 3km/h . . . . . . . . . . . . . . . . . . .  21
       11.1.2.  RTT 40ms 30km/h  . . . . . . . . . . . . . . . . . .  22
     11.2.  UL . . . . . . . . . . . . . . . . . . . . . . . . . . .  22
       11.2.1.  RTT 40ms 3km/h . . . . . . . . . . . . . . . . . . .  23
       11.2.2.  RTT 40ms 30km/h  . . . . . . . . . . . . . . . . . .  23
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  24
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  24
     12.2.  Informative References . . . . . . . . . . . . . . . . .  24
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  25

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



Johansson & Sarker      Expires December 20, 2014               [Page 2]


Internet-Draft                   SCReAM                        June 2014


   short time frame.  Thus a rate adaptation solution for interactive
   realtime media, such as WebRTC, in LTE must be both quick and also
   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 holds for 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 thus, 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" in this
   document are to be interpreted as described in RFC2119 [RFC2119]

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



Johansson & Sarker      Expires December 20, 2014               [Page 3]


Internet-Draft                   SCReAM                        June 2014


   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.  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  ECN (Explicit Congestion Notification) echo: Makes it possible to
      indicate if packets are ECN-CE (ECN Congestion Experienced)
      marked.  The use for the 8 ECN echo bits is T.B.D.

   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.


















Johansson & Sarker      Expires December 20, 2014               [Page 4]


Internet-Draft                   SCReAM                        June 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.  The ACK
   vector may also be RLE coded.

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





















Johansson & Sarker      Expires December 20, 2014               [Page 5]


Internet-Draft                   SCReAM                        June 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 December 20, 2014               [Page 6]


Internet-Draft                   SCReAM                        June 2014


   Figure 2 shows the functional overview of the adaptation framework.
   Each media type or source implements rate control and a queue, where
   encoded media frames are temporarily stored for transmission, the
   figure shows the details for one two video sources.  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
   (8).

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

   o  Fast start for bitrate increase.  It makes the video bitrate ramp-
      up within 3 to 5 seconds.  The behavior is similar to TCP



Johansson & Sarker      Expires December 20, 2014               [Page 7]


Internet-Draft                   SCReAM                        June 2014


      slowstart.  The fast start is exited when the OWD exceeds a given
      threshold.

   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 latency than frame skipping but it comes with
   a requirement to repair codec state.

4.  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 December 20, 2014               [Page 8]


Internet-Draft                   SCReAM                        June 2014


5.  Open issues

   A list of open issues.

   o  Describe how the RTCP feedback described in this memo is handled
      by mixers in various scenarios

   o  Describe how clock drift compensation is done

   o  RTCP AVPF mode.  Determine if AVPF immediate mode is to prefer,
      see discussion in Section 11

   o  Determine use of Q bit

   o  Determine format and use of ECN echo field

   o  The example code in Section 10 assumes a video source where the
      sizes of the video frames are scaled according to a scale-factor
      to produce the desired bitrate.  This may not be implementable in
      a real-life encoder, hence the code in said section is tightly
      connected to mentioned synthetic video source model.

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

7.  IANA Considerations

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

8.  Security Considerations

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

9.  Change history

   A list of changes:

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





Johansson & Sarker      Expires December 20, 2014               [Page 9]


Internet-Draft                   SCReAM                        June 2014


10.  Algorithm details

   This section describes the algorithm in a Java syntax.  The code is
   not complete however and wont compile, for instance Java class
   constructors are omitted for brevity.  Algorithm details that are
   missing are:

   o  Fast start

   o  Congestion Window Validation

   o  Adjustment to competing flows

   o  Discard old video frames in sender queue

10.1.  Sender side functions

10.1.1.  RTP packet queue handling (a.k.a Sender queue)

   The RTP packets produced by the video encoder are inserted in a FIFO
   queue.  The FIFO order may be overridden for instance if
   retransmission of RTP packets is needed, in which case the RTP packet
   to be retransmitted is put first in queue.




























Johansson & Sarker      Expires December 20, 2014              [Page 10]


Internet-Draft                   SCReAM                        June 2014


   /*
    * RtpPacket contains the RTP packet
    * Details are omitted
    */
   class RtpPacket {

   };

   /*
    * The SenderQItem is a container for SSRC, timestamp when
    * item is added to the queue and the RTP packet itself
    */
   class SenderQItem {
     int SSRC;
     int TS;
     RtpPacket rtpPacket;
   };

   /*
    * The list implements functions like
    * add(..)  : add a SenderQItem
    * get()    : get the oldest Item
    * remove() : remove the oldest item
    * age()    : get the queuing delay of the oldest packet
    */
   ArrayList<SenderQItem> senderQ = new list ArrayList<SenderQItem>;

   /*
    * Add an RTP packet to the sender queue
    */
   function addRtpPacket(int SSRC, RtpPacket rtpPacket) {
      senderQ.add(new SenderQItem(SSRC,now,rtpPacket));
   }

10.1.2.  Transmission scheduler

   The RTP packet transmission procedure is executed every tp interval
   where tp is computed according to the equation further down.

   /*
    * The TransmitItem is a container for SSRC, timestamp when
    * item is transmitted to the queue and the RTP packet itself
    */
   class TransmitItem {
     int SSRC;
     int TS_Tx;
     int SN;
     int size;



Johansson & Sarker      Expires December 20, 2014              [Page 11]


Internet-Draft                   SCReAM                        June 2014


   };

   /*
    * The list implements functions like
    * add(..)  : add a SenderQItem
    * get()    : get the oldest Item
    * remove() : remove the oldest item
    * age()    : get the queuing delay of the oldest packet
    * find(..) : find and return the item that matches....
    */
   ArrayList<TransmitItem> transmitted = new ArrayList<TransmitItem>;

   /*
    * Constants
    */
   int MSS_INIT = 1200;

   /*
    * Global variables
    */
   int bytesInFlight = 0;
   double tp = 0.001;
   int mss = MSS_INIT;
   int cwndMin = 2*mss;

   /*
    * Function that is called every tp interval
    */
   function tryTransmit() {
     RtpPacket rtpPacket = senderQ.get();
     if (bytesInFlight+rtpPacket.size < cwnd && rtpPacket != null) {
       /*
        * OK to transmit
        * Transmit next RTP packet in the sender queue and remove
        * the RTP packet from the sender queue
        */
       sendRtp(rtpPacket);
       senderQ.remove();

       /*
        * Add info about transmitted RTP packet to transmitted list
        * The RTP packet itself may be stored too to support
        * retransmission
        */
       transmitted.add(
          new TransmitItem(rtpPacket.SSRC,now,rtpPacket.SN,
                           rtpPacket.size));




Johansson & Sarker      Expires December 20, 2014              [Page 12]


Internet-Draft                   SCReAM                        June 2014


       /*
        * update bytesInFlight
        */
       bytesInFlight += rtpPacket.size;

       /*
        * compute tp, we assume a min bw of 50kbps and a min tp of 1ms
        * for stable operation
        * this function implements the packet pacing
        */
       bw = cwnd*8/rtt;
       tp = max(0.001,max(rtpPacket.size*8/max(50000,bw)));

       /*
        * Update MSS and cwndMin
        */
       mss = max(mss,rtpPacket.size);
       cwndMin = 2*mss;
     } else {
       /*
        * Not OK to transmit
        */
       tp = 0.001;
     }
   }

10.1.3.  Reception of RTCP feedback in sender

   From the RTCP feedback, the following information is used to adjust
   the number of bytesInFlight and to update the bytesNewlyAcked, the
   ackVector is also used to determine loss events.  Furthermore TX_Rx
   is used to determine owd.

   /*
    * RtcpPacket contains the feedback RTCP packet
    * Details are omitted
    */
   class RtcpPacket {

   };

   /*
    * Global variables
    */
   double lastLossEvent = -1;
   boolean lossEvent = false;
   int bytesNewlyAcked = 0;
   double owd = 0.0;



Johansson & Sarker      Expires December 20, 2014              [Page 13]


Internet-Draft                   SCReAM                        June 2014


   function rtcpFeedbackReceived(RtcpPacket rtcp) {
     item = transmitted.find(rtcp.SSRC, rtcp.SN)
     /*
      * Update OWD according to RFC6817
      * based on item.TS_Tx and rtcp.TS_Rx
      */
     updatedOwd(); // Function not specified in this memo

     /*
      * Update the number of bytesInFlight and bytesNewlyAcked
      * Remove items with sequence number lower than or equal to
      * rtcp.SN.
      * Sequence number wrap around is not considered in this code
      */
     for (TransmitItem item : transmitted) {
         if (item.SSRC == rtcp.SSRC && item.SN <= rtcp.SN) {
            bytesInFlight -= item.size;
            bytesNewlyAcked += item.size;
            /*
             * Remove item from transmitted list
             */
            transmitted.remove(item);
         }
      }
      /*
       * Determine if a loss event has occurred
       */
      if (now - lastLostEvent > rtt) {
        /*
         * A loss event is determined by a hole in the sequence
         * number space in the ACK vector, a guard time of the
         * last ACKed RTP SN is used to avoid false loss event
         * detection in the presence of packet reordering in the
         * network.
         */
        /*
         * Function loss event not specified in this memo
         */
         lossEvent = isLossEvent(rtcp.SN, rtcp.ackVector);

         if (lossEvent)
           lastLostEvent = now;
      }

      /*
       * Update the congestion window
       */
      updateCwnd();



Johansson & Sarker      Expires December 20, 2014              [Page 14]


Internet-Draft                   SCReAM                        June 2014


   }

10.1.4.  Congestion window adjustment

   The congestion window is adjusted for every received RTCP feedback.

   /*
    * Constants
    */
   double cwndHeadroomMin = 1.0;
   double cwndHeadroomMax = 2.0;
   double gainUp = 1.0;
   double gainDown = 1.0;
   double beta = 0.8;
   double OWD_TARGET = 0.08;

   /*
    * Global variables
    */
   double owdTarget = OWD_TARGET;
   double lastOwd = 0.0;

   function updateCwnd() {
     /*
      * offTarget is a normalized deviation from the owdTarget
      */
     offTarget = (owdTarget-owd)/owdTarget;

     /*
      * cwndHeadRoom gives indicates how much lower bytesInFlight
      * can be compared to cwnd to allow a cwnd increase
      */
     cwndHeadroom = cwndHeadroomMin+
       max(0.0,offTarget)*(cwndHeadroomMax-cwndHeadroomMin);

     if (lossEvent) {
       /*
        * loss event detected, decrease congestion window
        */
       cwnd = max(cwndMin, beta*cwnd);
       lossEvent = false;
     }

     if (offTarget > 0) {
       /*
        * owd is lower that owdTarget,
        * possible to increase cwnd
        */



Johansson & Sarker      Expires December 20, 2014              [Page 15]


Internet-Draft                   SCReAM                        June 2014


        if bytesInFlight*cwndHeadroom > cwnd {
          /*
           * Pipe is sufficiently filled with data,
           * increase cwnd
           */
          cwnd += gainUp * offTarget *
            bytesNewlyAcked * mss / cwnd;
        }
     } else {
       if (owd-lastOwd >= 0.0) {
         /*
          * Decrease cwnd quickly if owd is constant high or
          * increasing
          */
         rttFactor = Math.min(2.0,Math.max(0.1, getRtt())/0.1);
         cwnd += gainDown * rttFactor * max(-3.0,offTarget) *
           bytesNewlyAcked * mss / cwnd;
       } else {
         /*
          * Decrease cwnd slowly if owd is declining
          */
         cwnd += gainDown * max(-3.0,offTarget) *
           bytesNewlyAcked * mss / cwnd;
       }
     }
     cwnd = max(cwndMin,cwnd);
     lastOwd = owd;
     bytesNewlyAcked = 0;
   }

10.1.5.  Video encoder

   NOT_SPECIFIED means that the values need to be specifed based on
   video codec properties.

















Johansson & Sarker      Expires December 20, 2014              [Page 16]


Internet-Draft                   SCReAM                        June 2014


   /*
    * Constants
    */
   double scaleFactorMin = NOT_SPECIFIED_1;
   double scaleFactorMax = NOT_SPECIFIED_2;
   double framePeriod = NOT_SPECIFIED_3;

   /*
    * Global varaibles
    */
   boolean skipFrame = false;
   double scaleFactor = scaleFactorMin;

   /*
    * Function called for every grabbed video frame
    */
   function encodeVideoFrame() {
     if (!skipFrame) {
      /*
       * Details of encode function call depends on
       * video encoder properties
       */
       rtpPacket = encode(..., scaleFactor);
       addRtpPacket(SSRC,rtpPacket);
     }
     adjustVideoBitrate();
   }

10.1.6.  Video encoder rate adaptation

   The video encoder rate is adjusted every RTT.  The bitrate is
   controlled by a scale factor that is bounded by [minScaleFactor
   maxScaleFactor].  A history of the age of the oldest RTP packet in
   the sender queue over the 5 latest RTTs is maintained (ageHist).

   /*
    * Constants
    */
   int ageHistSizeMax = 5;

   /*
    * Global variables
    */
   double lastTimeAdjustVideoBitrate = 0.0;
   ArrayList<double> ageHist = new ArrayList<double>;

   /*
    * Function called every videoframe interval



Johansson & Sarker      Expires December 20, 2014              [Page 17]


Internet-Draft                   SCReAM                        June 2014


    */
   function adjustVideoBitrate() {
     if (senderQ.age > skipFrameTh)
       skipFrame = true;
     else
       skipFrame = false;
     if (now-lastTimeAdjustVideoBitrate < framePeriod)
       return;
     ageHist.add(senderQ.age());
     if (ageHist.size >= ageHistSizeMax) {
       age = ageHist.average(); // Compute average
       owdFraction = owd/owdTarget;
       if (age > framePeriod/2) {
          /*
          * Decrease the scale factor proportional to the age
         */
         scaleFactor = max(scaleFactorMin, scaleFactor*(1.0-age));
       } else {
         /*
          * Increase the scale factor
          */
         /*
          * Put an upper limit on how fast the scalefactor can
          * increase
          */
         scaleLimit = max(scaleFactor, scaleFactorMax*0.1)*0.2;
         /*
          * Increment is slowed down
          *  if owd shows a tendency to increase
          */
         rampUpSlowDown = min(5.0, max(rampUpSlowDown*0.9,
           1.0+5.0*max(0.0,owdFraction-0.2)));

         increment =
           min(framePeriod*maxScaleFactor/
             (rampUpTime*rampUpSlowDown), scaleLimit);
         scaleFactor = min(maxScaleFactor, scaleFactor+increment);
       }

       /*
        * Remove oldest element in age history
        */
       ageHist.remove();
     }
   }






Johansson & Sarker      Expires December 20, 2014              [Page 18]


Internet-Draft                   SCReAM                        June 2014


10.2.  Receiver side functions

10.2.1.  Reception of RTP packet

   An RTCP packet is created and scheduled for transmission.  If an RTCP
   packet is already present and waiting for transmission, the new RTCP
   packet will replace the older RTCP feedback packet.

   /*
    * Global variables
    */
   RtcpPacket rtcpFeedbackPacket = null;
   ArrayList<integer> rtpSn = new ArrayList<integer>;

   /*
    * New RTP packet received
    */
   function rtpReceived(rtp) {
     rtpSn.add(rtp.SN);

     /*
      * A new RTCP feedback is prepared for transmission,
      * due to RTCP bandwidth and timing rules it may happen that
      * an RTCP feedback has not been transmitted when a new
      * feedback packet is generated. To make feedback as timely
      * as possible, older unsent feedback packets should be replaced
      * by new feedback packets.
      */
     rtcpFeedbackPacket = RtcpFeedbackPacket(SSRC,now,rtp.SN,rtpSn)

     /*
      * Decode RTP packet and render media
      */
   }

11.  Simulations

   A state of the art dynamic LTE simulation with settings according to
   Table 1 , derived from
   [I-D.draft-sarker-rmcat-cellular-eval-test-cases] was used to assess
   the performance of the algorithm.  The simulator models the whole
   protocol chain including handover, radio propagation etc.









Johansson & Sarker      Expires December 20, 2014              [Page 19]


Internet-Draft                   SCReAM                        June 2014


                       LTE simulation configuration

   +-------------+-----------------------------------------------------+
   | Cellular    | 21 cells (7 sites); 3GPP case 1 settings            |
   | layout      |                                                     |
   | System      | 10MHz bandwidth, 2GHz carrier frequency, eNB        |
   | setup       | transmission power 40W, MIMO transmission mode      |
   | Channel     | Typical Urban                                       |
   | Propagation | Okumura-Hata model                                  |
   | model       |                                                     |
   | Scheduler   | DL scheduler: Proportional fair. UL scheduler:      |
   |             | Proportional fair                                   |
   | User        | Poisson arrival based user arrival                  |
   | generation  |                                                     |
   | Mobility    | UE moves straight in a randomly selected direction, |
   |             | at a speed 3km/h or 30km/h, ideal handover model    |
   |             | (no user plane interruption, no handover signaling) |
   | Traffic     | Video: Rate adaptive video, codec : H.264, bitrate  |
   | scenario    | 150-1500kbps.  RTCP BW: 75kbps. Audio: Frame size   |
   |             | 20ms, bitrate 20kbps, frame skip feature enabled.   |
   |             | FTP: 500kB objects corresponding to an average of   |
   |             | 4Mbps load per cell for the DL test case and 2Mbps  |
   |             | load per cell for the UL test case.                 |
   +-------------+-----------------------------------------------------+

                                  Table 1

   The self-clocked algorithm is compared against the Google congestion
   control algorithm [I-D.alvestrand-rmcat-congestion].  The load level
   i.e. the intensity of new video users and the FTP load is:

   o  DL simulations: Video users: 2 to 16 users/cell, FTP load: 4Mbps

   o  UL simulations: Video users: 1 to 10 users/cell, FTP load: 2Mbps

   The latency is expressed as "packet 98%ile, user 95%ile delay",
   meaning that the "98%ile delay" is determined for all users, i.e 98%
   of the video frames or IP packets have a delay less than the "packet
   98%ile delay" value.  Based on this the "user 95%ile delay" is
   determined, meaning that 95% of the users have a "packet 98%ile
   delay" less than said "user 95%ile value", this is a relatively
   strict metric but it gives a fairly good idea of how stable the video
   (and audio playback) is.

   The users/cell indications and the associated performance metrics
   should not be treated as exact values as there is a lot of
   dependencies in propagation models, antenna configurations, scheduler
   implementations, other cross traffic involved.  Therefore the tables



Johansson & Sarker      Expires December 20, 2014              [Page 20]


Internet-Draft                   SCReAM                        June 2014


   should be read as a comparison between congestion control algorithms
   at the same given network conditions.  Only the results with AQM
   enabled are shown in the tables below.

   In general the results indicate that SCReAM is more stable in terms
   of latency and packet loss than GCC.  Furthermore, SCReAM achieves
   good throughput at low load levels in both uplink and downlink.
   SCReAM implements the frame skipping mechansism in these simulations,
   which means that the frame rate is reduced if the queuing delay in
   the sender queue exceeds 100ms.  The 30km/h test cases are more
   challenging as the channel conditions vary more quickly, also in this
   case SCReAM performs better than GCC.  The performance can be further
   improved if frames in the sender queue are discarded if they are too
   old to be rendered in a meaningful way in the receiver.

   The SCReAM simulations was done in AVPF early mode with an RTCP
   feedback overhead of ~12kbps (including IP and UDP).  The effect of
   the AVPF early mode is however that the RTCP feedpack is not
   transmitted for each received IP packet but rather for each video
   frame and this can potentially cause a less stable self-clocking.
   AVPF immediate mode should be tried out to see if it gives an
   improvement.

11.1.  DL

11.1.1.  RTT 40ms 3km/h

                                    GCC

   +-----------------------------+-----+-----+-----+-----+------+------+
   |          Users/cell         |   2 |   4 |   6 |   8 |   12 |   16 |
   +-----------------------------+-----+-----+-----+-----+------+------+
   |   Video tail latency [ms]   |  35 |  65 | 168 | 828 | 1028 | 1071 |
   | IP packet tail latency [ms] |  35 |  65 | 168 | 826 | 1028 | 1073 |
   |       Average PLR [%]       | 0.0 | 0.0 | 0.0 | 0.5 |  3.8 |  9.4 |
   |    Average bitrate [kbps]   | 423 | 371 | 358 | 332 |  247 |  177 |
   +-----------------------------+-----+-----+-----+-----+------+------+

                                  Table 2












Johansson & Sarker      Expires December 20, 2014              [Page 21]


Internet-Draft                   SCReAM                        June 2014


                                  SCReAM

   +-----------------------------+------+-----+-----+-----+-----+-----+
   |          Users/cell         |    2 |   4 |   6 |   8 |  12 |  16 |
   +-----------------------------+------+-----+-----+-----+-----+-----+
   |   Video tail latency [ms]   |  126 | 192 | 192 | 258 | 412 | 559 |
   | IP packet tail latency [ms] |   92 | 126 | 139 | 171 | 233 | 293 |
   |       Average PLR [%]       |  0.0 | 0.0 | 0.0 | 0.1 | 0.2 | 0.9 |
   |    Average bitrate [kbps]   | 1202 | 812 | 575 | 461 | 328 | 232 |
   +-----------------------------+------+-----+-----+-----+-----+-----+

                                  Table 3

11.1.2.  RTT 40ms 30km/h

                                    GCC

   +----------------------------+-----+-----+-----+------+------+------+
   |         Users/cell         |   2 |   4 |   6 |    8 |   12 |   16 |
   +----------------------------+-----+-----+-----+------+------+------+
   |  Video tail latency [ms]   |  64 | 237 | 847 | 1304 | 2023 | 2195 |
   |   IP packet tail latency   |  63 | 237 | 823 | 1281 | 2023 | 2192 |
   |            [ms]            |     |     |     |      |      |      |
   |      Average PLR [%]       | 0.0 | 0.0 | 0.6 |  2.1 | 15.2 | 50.5 |
   |   Average bitrate [kbps]   | 342 | 332 | 261 |  201 |  105 |   61 |
   +----------------------------+-----+-----+-----+------+------+------+

                                  Table 4

                                  SCReAM

   +-----------------------------+-----+-----+-----+-----+-----+------+
   |          Users/cell         |   2 |   4 |   6 |   8 |  12 |   16 |
   +-----------------------------+-----+-----+-----+-----+-----+------+
   |   Video tail latency [ms]   | 229 | 263 | 350 | 414 | 748 | 1470 |
   | IP packet tail latency [ms] | 134 | 164 | 197 | 224 | 438 |  920 |
   |       Average PLR [%]       | 0.0 | 0.1 | 0.1 | 0.2 | 1.6 | 11.3 |
   |    Average bitrate [kbps]   | 878 | 512 | 351 | 277 | 184 |  131 |
   +-----------------------------+-----+-----+-----+-----+-----+------+

                                  Table 5

11.2.  UL








Johansson & Sarker      Expires December 20, 2014              [Page 22]


Internet-Draft                   SCReAM                        June 2014


11.2.1.  RTT 40ms 3km/h

                                    GCC

   +-----------------------------+-----+-----+-----+-----+------+------+
   |          Users/cell         |   1 |   2 |   3 |   5 |    8 |   10 |
   +-----------------------------+-----+-----+-----+-----+------+------+
   |   Video tail latency [ms]   |  93 | 103 | 183 | 261 |  607 |  494 |
   | IP packet tail latency [ms] |  94 | 106 | 195 | 237 |  608 |  497 |
   |       Average PLR [%]       | 0.4 | 0.3 | 2.0 | 1.9 | 19.2 | 27.2 |
   |    Average bitrate [kbps]   | 770 | 757 | 655 | 612 |  381 |  361 |
   +-----------------------------+-----+-----+-----+-----+------+------+

                                  Table 6

                                  SCReAM

   +-----------------------------+------+------+-----+-----+-----+-----+
   |          Users/cell         |    1 |    2 |   3 |   5 |   8 |  10 |
   +-----------------------------+------+------+-----+-----+-----+-----+
   |   Video tail latency [ms]   |  111 |  124 | 174 | 182 | 209 | 268 |
   | IP packet tail latency [ms] |   95 |  101 | 118 | 128 | 154 | 170 |
   |       Average PLR [%]       |  0.0 |  0.0 | 0.4 | 0.4 | 1.2 | 2.6 |
   |    Average bitrate [kbps]   | 1286 | 1123 | 856 | 663 | 451 | 362 |
   +-----------------------------+------+------+-----+-----+-----+-----+

                                  Table 7

11.2.2.  RTT 40ms 30km/h

                                    GCC

   +---------------------------+-----+-----+------+------+------+------+
   |         Users/cell        |   1 |   2 |    3 |    5 |    8 |   10 |
   +---------------------------+-----+-----+------+------+------+------+
   |  Video tail latency [ms]  | 200 | 340 |  757 |  845 | 1020 | 1017 |
   |   IP packet tail latency  | 225 | 374 |  747 |  829 | 1020 | 1017 |
   |            [ms]           |     |     |      |      |      |      |
   |      Average PLR [%]      | 4.8 | 4.0 | 21.7 | 14.7 | 80.0 | 91.1 |
   |   Average bitrate [kbps]  | 718 | 681 |  557 |  456 |  266 |  230 |
   +---------------------------+-----+-----+------+------+------+------+

                                  Table 8








Johansson & Sarker      Expires December 20, 2014              [Page 23]


Internet-Draft                   SCReAM                        June 2014


                                  SCReAM

   +-----------------------------+-----+-----+-----+-----+-----+------+
   |          Users/cell         |   1 |   2 |   3 |   5 |   8 |   10 |
   +-----------------------------+-----+-----+-----+-----+-----+------+
   |   Video tail latency [ms]   | 144 | 174 | 232 | 263 | 276 |  357 |
   | IP packet tail latency [ms] | 109 | 113 | 134 | 141 | 167 |  215 |
   |       Average PLR [%]       | 1.1 | 0.9 | 2.4 | 2.2 | 3.5 | 11.2 |
   |    Average bitrate [kbps]   | 848 | 698 | 572 | 456 | 302 |  240 |
   +-----------------------------+-----+-----+-----+-----+-----+------+

                                  Table 9

12.  References

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

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

12.2.  Informative References

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

   [I-D.alvestrand-rmcat-congestion]
              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.




Johansson & Sarker      Expires December 20, 2014              [Page 24]


Internet-Draft                   SCReAM                        June 2014


   [I-D.draft-sarker-rmcat-cellular-eval-test-cases]
              Sarker, Z., "Evaluation Test Cases for Interactive Real-
              Time Media over Cellular Networks",
              <http://www.ietf.org/id/
              draft-sarker-rmcat-cellular-eval-test-cases-00.txt>.

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

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

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

Authors' Addresses

   Ingemar Johansson
   Ericsson AB
   Laboratoriegraend 11
   Luleae  977 53
   Sweden

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


   Zaheduzzaman Sarker
   Ericsson AB
   Laboratoriegraend 11
   Luleae  977 53
   Sweden

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










Johansson & Sarker      Expires December 20, 2014              [Page 25]