[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 draft-ietf-rmcat-video-traffic-model

Network Working Group                                             X. Zhu
Internet-Draft                                                   S. Mena
Intended status: Informational                             Cisco Systems
Expires: April 29, 2015                                        Z. Sarker
                                                             Ericsson AB
                                                        October 26, 2014


          Modeling Video Traffic Sources for RMCAT Evaluations
                  draft-zhu-rmcat-video-traffic-source-00

Abstract

   This document describes two reference video traffic source models for
   evaluating RMCAT candidate algorithms.  The first model statistically
   characterizes the behavior of a live video encoder in response to
   changing requests on target video rate.  The second model is trace-
   driven, and emulates the encoder output by scaling the pre-encoded
   video frame sizes from a widely used video test sequence.  Both
   models are designed to strike a balance between simplicity,
   repeatability, and authenticity in modeling the interactions between
   a video traffic source and the congestion control module.

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



Zhu, et al.              Expires April 29, 2015                 [Page 1]


Internet-Draft  Modelling Video Traffic Sources for RMCAT   October 2014


   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
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Desired Behavior of Synthetic Video Traffic Model . . . . . .   3
   4.  Interactions Between Synthetic Video Traffic Source and
       Congestion Control  . . . . . . . . . . . . . . . . . . . . .   4
   5.  A Statistical Reference Model . . . . . . . . . . . . . . . .   6
     5.1.  Time-damped response to target rate update  . . . . . . .   6
     5.2.  Temporary burst/oscillation during transient  . . . . . .   6
     5.3.  Output rate fluctuation at steady state . . . . . . . . .   7
     5.4.  Rate range limit imposed by video content . . . . . . . .   7
   6.  A Trace-Based Model . . . . . . . . . . . . . . . . . . . . .   7
     6.1.  Choosing the video sequence and generating the traces . .   8
     6.2.  Using the traces in the syntethic codec . . . . . . . . .   9
       6.2.1.  Main algorithm  . . . . . . . . . . . . . . . . . . .   9
       6.2.2.  Notes to the main algorithm . . . . . . . . . . . . .  11
     6.3.  Varying frame rate and resolution . . . . . . . . . . . .  11
   7.  Combining The Two Models  . . . . . . . . . . . . . . . . . .  12
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

   When evaluating candidate congestion control algorithms designed for
   real-time interactive media -- as chartered by the RMCAT Working
   Group -- it is important to account for the characteristics of
   traffic patterns generated from a live video encoder.  Unlike
   synthetic traffic sources that can conform perfectly to the rate
   changing requests from the congestion control module, a live video
   encoder can be sluggish in reacting to such changes.  Output rate of
   a live video encoder also typically deviates from the target rate due
   to uncertainties in the encoder rate control process.  Consequently,
   end-to-end delay and loss performance of a RMCAT flow can be further
   impacted by such rate variations introduced by the live encoder.

   On the other hand, evaluation results of a candidate RMCAT algorithm
   should mostly reflect performance of the congestion control module,



Zhu, et al.              Expires April 29, 2015                 [Page 2]


Internet-Draft  Modelling Video Traffic Sources for RMCAT   October 2014


   and be somewhat decoupled from the choice of a specific video codec.
   It is also desirable that the evaluation tests are repeatable, and be
   easily duplicated across different candidate algorithms.

   One way to strike a balance between the above considerations is to
   evaluate RMCAT algorithms using a video traffic source model that is
   slightly more sophisticated than perfectly conforming CBR traffic,
   but rather captures the key characteristics of the behavior of a live
   video encoder.  To this purpose, this draft presents two reference
   models based on two different approaches: statistical modelling or
   trace driven, respectively.

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

   The terminology defined in RTP [RFC3550], RTP Profile for Audio and
   Video Conferences with Minimal Control [RFC3551], RTCP Extended
   Report (XR) [RFC3611], Extended RTP Profile for RTCP-based Feedback
   (RTP/AVPF) [RFC4585], Support for Reduced-Size RTCP [RFC5506], and
   RTP Circuit Breaker Algorithm [I-D.ietf-avtcore-rtp-circuit-breakers]
   apply.

3.  Desired Behavior of Synthetic Video Traffic Model

   A live video encoder employs encoder rate control to meet a target
   rate by varying its encoding parameters, such as quantization step
   size, frame rate, and picture resolution, based on its estimate of
   the video content (e.g., motion and scene complexity).  In practice,
   however, several factors prevent the output video rate from perfectly
   conforming to the input target rate.

   Due to uncertainties in the captured video scene, the output rate
   typically deviates from the specified target.  In the presence of a
   significant change in target rate, it sometimes takes several frames
   before the encoder output rate converges to the new target.  Finally,
   while most of the frames in a live session are encoded in predictive
   mode, the encoder can occasionally generate a large intra-coded frame
   (or a frame partially containing intra-coded blocks) in an attempt to
   recover from losses or re-sync with the receiver, or during the
   transient period of responding to target rate changes.

   Hence, a synthetic video source should have -

   o  ability to change bitrate.  This includes ability to change the
      framerate and/or the resolution, skip frames when required.



Zhu, et al.              Expires April 29, 2015                 [Page 3]


Internet-Draft  Modelling Video Traffic Sources for RMCAT   October 2014


   o  ability to fluctuate around the target bitrate set by the
      congestion control module.

   o  ability to add delay in convergence to the target bitrate.

   o  ability to produce Intra-coded frames on demand.

   While there exists many different approaches in developing a
   synthetic video traffic model, it is desirable that the outcome
   follows a few common characteristics, as outlined below.

   * Low Computational Complexity:   The model should be computationally
         lightweight, otherwise it defeats the whole purpose of serving
         as a substitute for a live video encoder.

   * Temporal Pattern Similarity:   The individual traffic trace
         instances generated by the model should mimic the temporal
         pattern of those from a real video encoder.

   * Statistical Accuracy:   The synthetic traffic should match the
         outcome of the real video encoder in terms of statistical
         characteristics, such as the mean, variance, peak, and
         autocorrelation coefficients of the bitrate.  It is also
         important that the statistical resemblance should hold across
         different time scales, ranging from tens of milliseconds to
         sub-seconds.

   * Wide Range of Coverage:   The model should be easily configurable
         to cover a wide range of codec behaviors (e.g., with either
         fast or slow reaction time in live encoder rate control) and
         video content variations (e.g, ranging from high-motion to low-
         motion).

   These distinct behavior features can be characterized via simple
   statistical models, or a trace-driven approach.  In the next three
   sections, we present an example of each.

4.  Interactions Between Synthetic Video Traffic Source and Congestion
    Control

   Figure 1 illustrates how the synthetic video traffic source module
   interacts with the congestion control module at the sender.  Both
   reference models described later in Sections 5. and 6. assume the
   same set of interactions between encoder rate control and congestion
   control, as well as the underlying packet transport module.

   We model the synthetic video encoder to take in raw video frames
   captured by the camera along with a set of requests from the



Zhu, et al.              Expires April 29, 2015                 [Page 4]


Internet-Draft  Modelling Video Traffic Sources for RMCAT   October 2014


   congestion control module.  It then dynamically generates a sequence
   of encoded video frames with varying size and interval.  These
   encoded frames are segmented and packetized into RTP packets by the
   RTP stack, and encapsulated over UDP/IP before they are transmitted
   to the network interface.  Upon the receipt of an updated RTCP report
   from the receiver, the congestion control module may further revise
   its request to the synthetic video encoder, which in turn updates the
   size and interval of encoded video frames at its output.

   In our model, the key notion of "congestion control requests" ---
   marked as (a) in the figure --- comprises several options:

   o  Target rate R_v(t): requested at time t from the congestion
      control module to the encoder.  Depending on the congestion
      control algorithm in use, the update requests can either be
      periodic (e.g., once per 1 second), or on-demand (e.g., only when
      drastic bandwidth change over the network is observed).


   o  Target frame rate FPS(t): the instantaneous frame rate measured in
      frames-per-second at time t.  This depends on the native camera
      capture frame rate as well as the target/preferred frame rate
      configured by the application or user.


   o  Instant frame skipping: the request from the congestion control
      module to skip the encoding of one or several captured video
      frames, typically when a drastic decrease in available network
      bandwidth is detected.


   o  On-demand generation of intra (I) frame: the request to encode
      another I frame to avoid further error propagation at the
      receiver, if severe packet losses are observed.  Strictly
      speaking, this request should come from the error control module,
      not the congestion control module in the sender.


   Optionally, the syntethic video encoder can inform the congestion
   control module of the dynamic range of its output rate for the
   current video contents: [R_min, R_max].  Here, R_min and R_max are
   meant to capture the dynamic rate range the encoder is capable of
   outputting.  This typically depends on the video content complexity
   and/or display type (e.g., higher R_max for video contents with
   higher motion complexity, or for displays of higher resolution).
   Therefore, these values will not change with R_v, but may change over
   time if the content is changing.




Zhu, et al.              Expires April 29, 2015                 [Page 5]


Internet-Draft  Modelling Video Traffic Sources for RMCAT   October 2014


                ---------------   CC requests   ---------------
      raw video |             |       (a)      |             |   RTCP
       frames   |  Synthetic  | <------------- |  RMCAT      |  report
       -------> |  Video      |                |  Congestion | <-------
                |  Encoder    | -------------> |  Control    |
                |             |  rate range    |             |
                --------------- [R_min, R_max] ---------------
                       |
               encoded |
               video   |
               frames  |
                     \ | /
               -------------------------------------------------
               |            RTP stack                          | ------->
           -------------------------------------------------    RTP
                                                                  packets


     Figure 1: Interaction between synthetic video encoder, congestion
                   control, and packet transport module.

5.  A Statistical Reference Model

   In this section, we describe one simple statistical model of the live
   video encoder traffic source.  A more complete survey of popular
   methods can be found in [Tanwir2013].

5.1.  Time-damped response to target rate update

   While the congestion control module can update its target rate
   request R_v(t) at any time, our model dictates that the encoder will
   only react to such changes after tau_v seconds from a previous rate
   transition.  In other words, when the encoder has reacted to a rate
   change request at time t, it will simply ignore all subsequent rate
   change requests until time t+tau_v.

5.2.  Temporary burst/oscillation during transient

   The output rate R_o during the period [t, t+tau_v] is considered to
   be in transient.  Based on observations from video encoder output
   data, we model the transient behavior of an encoder upon reacting to
   a new target rate request in the form of largely varying output
   sizes.  It is assumed that the overall average output rate R_o during
   this period matches the target rate R_v.  Consequently, the
   occasional burst of large frames are followed by smaller-than average
   encoded frames.

   This temporary burst is characterized by two parameters:



Zhu, et al.              Expires April 29, 2015                 [Page 6]


Internet-Draft  Modelling Video Traffic Sources for RMCAT   October 2014


   o  burst duration K_d: number frames in the burst event; and

   o  burst size K_r: ratio of a burst frame and average frame size at
      steady state.

   It can be noted that these burst parameters can also be used to mimic
   the insersion of a large on-demand I frame in the presence of severe
   packet losses.  The values of K_d and K_r are fitted to reflect the
   typical ratio between I and P frames for a given video content.

5.3.  Output rate fluctuation at steady state

   We model output rate R_o as randomly fluctuating around the target
   rate R_v after convergence.  There are two variants in modeling the
   random fluctuation R_e = R_o - R_v:

   o  As normal distribution: with a mean of zero and a standard
      deviation SIGMA specified in terms of percentage of the target
      rate.  A typical value of SIGMA is 10 percent of target rate.

   o  As uniform distribution bounded between -DELTA and DELTA.  A
      typical value of DELTA is 10 percent of target rate.

   The distribution type (normal or uniform) and model parameters (SIGMA
   or DELTA) can be learned from data samples gathered from a live
   encoder output.

5.4.  Rate range limit imposed by video content

   The output rate R_o is further clipped within the dynamic range
   [R_min,R_max], which in reality are dictated by scene and motion
   complexity of the captured video content.  In our model, these
   parameters are specified by the user.

6.  A Trace-Based Model

   We now present the second approach to model a video traffic source.
   This approach is based on running an actual live video encoder
   offline on a set of chosen raw video sequences and using the
   encoder's output traces for constructing a synthetic live encoder.
   With this approach, the recorded video traces naturally exhibit
   temporal fluctuations around a given target rate request R_v(t) from
   the congestion control module.

   The following list summarizes this approach's main steps:

   1) Choose one or more representative raw video sequences.




Zhu, et al.              Expires April 29, 2015                 [Page 7]


Internet-Draft  Modelling Video Traffic Sources for RMCAT   October 2014


   2) Using an actual live video encoder, encode the sequences at
   various bitrates.  Keep just the sequences of frame sizes for each
   bitrate.

   3) Construct a data structure that contains the output of the
   previous step.  The data structure should allow for easy bitrate
   lookup.

   4) Upon a target bitrate request R_v(t) from the controller, look up
   the closest bitrates among those previously stored.  Use the frame
   size sequences stored for those bitrates to approximate the frame
   sizes to output.

   5) The output of the synthetic encoder contains "encoded" frames with
   random contents but with realistic sizes.

   Section 6.1 explains steps 1), 2), and 3), Section 6.2 elaborates on
   steps 4) and 5).  Finally, Section 6.3 briefly discusses the
   possibility to extend the model for supporting variable frame rate
   and/or variable frame resolution.

6.1.  Choosing the video sequence and generating the traces

   The first step we need to perform is a careful choice of a set of
   video sequences that are representative of the use cases we want to
   model.  Our use case here is video conferencing, so we must choose a
   low-motion sequence that resembles a "talking head", for instance a
   news broadcast or a video capture of an actual conference call.

   The length of the chosen video sequence is a tradeoff.  If it is too
   long, it will be difficult to manage the data structures containing
   the traces we will produce in the next steps.  If it is too short,
   there will be an obvious periodic pattern in the output frame sizes,
   leading to biased results when evaluating congestion controller
   performance.  In our experience, a one-minute-long sequence is a fair
   tradeoff.

   Once we have chosen the raw video sequence, denoted S, we use a live
   encoder, e.g.  [H264] or [HEVC] to produce a set of encoded
   sequences.  As discussed in Section 3, a live encoder's output
   bitrate can be tuned by varying three input parameters, namely,
   quantization step size, frame rate, and picture resolution.  In order
   to simplify the choice of these parameters for a given target rate,
   we assume a fixed frame rate (e.g. 25 fps) and a fixed resolution
   (e.g., 480p).  See section 6.3 for a discussion on how to relax these
   assumptions.





Zhu, et al.              Expires April 29, 2015                 [Page 8]


Internet-Draft  Modelling Video Traffic Sources for RMCAT   October 2014


   Following these simplifications, we run the chosen encoder by setting
   a constant target bitrate at the beginning, then letting the encoder
   vary the quantization step size internally while encoding the input
   video sequence.  Besides, we assume that the first frame is encoded
   as an I-frame and the rest are P-frames.  We further assume that the
   encoder algorithm does not use knowledge of frames in the future so
   as to encode a given frame.

   We define R_min and R_max as the minimum and maximum bitrate at which
   the synthetic codec is to operate.  We divide the bitrate range
   between R_min and R_max in n_s + 1 bitrate steps of length l = (R_max
   - R_min) / n_s.  We then use the following simple algorithm to encode
   the raw video sequence.

       r = R_min
       while r <= R_max do
           Traces[r] = encode_sequence(S, r, e)
           r = r + l

   where function encode_sequence takes as parameters, respectively, a
   raw video sequence, a constant target rate, and an encoder algorithm;
   it returns a vector with the sizes of frames in the order they were
   encoded.  The output vector is stored in a map structure called
   Traces, whose keys are bitrates and values are frame size vectors.

   The choice of a value for n_s is important, as it determines the
   number of frame size vectors stored in map Traces.  The minimum value
   one can choose for n_s is 1, and its maximum value depends on the
   amount of memory available for holding map Traces.  A reasonable
   value for n_s is one that makes the steps' length l = 200 kbps.  We
   will further discuss step length l in the next section.

6.2.  Using the traces in the syntethic codec

   The main idea behind the trace-based synthetic codec is that it
   mimics a real live codec's rate adaptation when the congestion
   controller updates the target rate R_v(t).  It does so by switching
   to a different frame size vector stored in the map Traces when
   needed.

6.2.1.  Main algorithm

   We maintain two variables r_current and t_current:

   * r_current points to one of the keys of the map Traces.  Upon a
   change in the value of R_v(t), typically because the congestion
   controller detects that the network conditions have changed,
   r_current is updated to the greatest key in Traces that is less than



Zhu, et al.              Expires April 29, 2015                 [Page 9]


Internet-Draft  Modelling Video Traffic Sources for RMCAT   October 2014


   or equal to the new value of R_v(t).  For the moment, we assume the
   value of R_v(t) to be clipped in the range [R_min, R_max].

        r_current = r
        such that
           ( r in keys(Traces)  and
           r <= R_v(t)  and
        (not(exists) r' in keys(Traces) such that r < r' $lt;= R_v(t)) )


   * t_current is an index to the frame size vector stored in
   Traces[r_current].  It is updated every time a new frame is due.  We
   assume all vectors stored in Traces to have the same size, denoted
   size_traces.  The following equation governs the update of t_current:

        if t_current < SkipFrames then
            t_current = t_current + 1
            else
            t_current = ((t_current+1-SkipFrames ) % (size_traces- SkipFrames) )
                + SkipFrames

   where operator % denotes modulo, and SkipFrames is a predefined
   constant that denotes the number of frames to be skipped at the
   beginning of frame size vectors after t_current has wrapped around.
   The point of constant SkipFrames is avoiding the effect of
   periodically sending a (big) I-frame followed by several smaller-
   than-normal P-frames.  We typically set SkipFrames to 20, although it
   could be set to 0 if we are interested in studying the effect of
   sending I-frames periodically.

   We initialize r_current to R_min, and t_current to 0.

   When a new frame is due, we need to calculate its size.  There are
   three cases:

   a) R_min <= R_v(t) < Rmax:  In this case we use linear interpolation
      of the frame sizes appearing in Traces[r_current] and
      Traces[r_current + l].  The interpolation is done as follows:

     size_lo = Traces[r_current][t_current]
         size_hi = Traces[r_current + l][t_current]
         distance_lo = ( R_v(t) - r_current ) / l
         framesize = size_hi * distance_lo + size_lo * (1 - distance_lo)

   b) R_v(t) < R_min:  In this case, we scale the trace sequence with
      the lowest bitrate, in the following way:





Zhu, et al.              Expires April 29, 2015                [Page 10]


Internet-Draft  Modelling Video Traffic Sources for RMCAT   October 2014


       factor = R_v(t) / R_min
           framesize = max(1, factor * Traces[R_min][t_current])

   c) R_v(t) >= R_max:  We also use scaling for this case.  We use the
      trace sequence with the greatest bitrate:

       factor = R_v(t) / R_max
           framesize = factor * Traces[R_max][t_current]

   In case b), we set the minimum to 1 byte, since the value of factor
   can be arbitrarily close to 0.

6.2.2.  Notes to the main algorithm

   * Reacting to changes in target bitrate.  Similarly to the
   statistical model presented in Section 5, the trace-based synthetic
   codec has a time bound, tau_v, to reacting to target bitrate changes.
   If the codec has reacted to an update in R_v(t) at time t, it will
   delay any further update to R_v(t) to time t + tau_v.  Note that, in
   any case, the value of tau_v cannot be chosen shorter than the time
   between frames, i.e. the inverse of the frame rate.

   * I-frames on demand.  The synthetic codec could be extended to
   simulate the sending of I-frames on demand, e.g., as a reaction to
   losses.  To implement this extension, the codec's API is augmented
   with a new function to request a new I-frame.  Upon calling such
   function, t_current is reset to 0.

   * Variable length l of steps defined between R_min and R_max.  In the
   main algorithm's description, the step length l is fixed.  However,
   if the range [R_min, R_max] is very wide, it is also possible to
   define a set of steps with a non-constant length.  The idea behind
   this modification is that the difference between 400 kbps and 600
   kbps as bitrate is much more important than the difference between
   4400 kbps and 4600 kbps.  For example, one could define steps of
   length 200 Kbps under 1 Mbps, then length 300 kbps between 1 Mbps and
   2 Mbps, 400 kbps between 2 Mbps and 3 Mbps, and so on.

6.3.  Varying frame rate and resolution

   The trace-based synthetic codec model explained in this section is
   relatively simple because we have fixed the frame rate and the frame
   resolution.  The model could be extended to have variable frame rate,
   variable frame resolution, or both.

   When the video quality for a given bitrate is low, one can decrease
   the frame rate (if the video sequence is currently low motion) or the
   frame resolution in order to attempt an improvement in the quality-



Zhu, et al.              Expires April 29, 2015                [Page 11]


Internet-Draft  Modelling Video Traffic Sources for RMCAT   October 2014


   of-experince (QoE).  On the other hand, if the bitrate increases to a
   point where there is no longer a perceptible improvement in the QoE,
   then we might afford to increase the frame resolution or the frame
   rate (useful if the video is currently high motion).

   Many techniques have been proposed to choose over time the best
   values for these two parameters, together with the quatization step
   size, in order to maximize the quality of live video codecs
   [Ozer2011], [Hu2010].  In the future, we will consider extending the
   trace-based codec to be able to use variable frame rate and/or
   resolution.

   From the perspective of congestion control performance, varying the
   frame resolution will not impact the outcome of a synthetic video
   codec: the resulting encoded video frames bear the same data size
   regardless of resolution choice.  On the other hand, different
   choices of frame rates lead to different levels of burstiness in the
   encoded video traffic trace: e.g., many small packets at a high frame
   rate vs.  sparsely spaced large packets at a low frame rate.  Such
   difference in traffic profiles may affect the performance of
   congestion control differently, especially when outgoing packets are
   not paced at the transport module.  We leave the investigation of
   varying frame rate to future work.

7.  Combining The Two Models

   This section discusses the pros and cons of the two reference models,
   as well as how one may combine them for evaluation of RMCAT
   candidates.

   [EDITOR'S NOTE: Will add more details after solicitating initial
   feedback on the draft from mailing list and in-meeting presentation.
   ]

8.  IANA Considerations

   There are no IANA impacts in this memo.

9.  References

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



Zhu, et al.              Expires April 29, 2015                [Page 12]


Internet-Draft  Modelling Video Traffic Sources for RMCAT   October 2014


   [RFC3551]  Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
              Video Conferences with Minimal Control", STD 65, RFC 3551,
              July 2003.

   [RFC3611]  Friedman, T., Caceres, R., and A. Clark, "RTP Control
              Protocol Extended Reports (RTCP XR)", RFC 3611, November
              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.

   [I-D.ietf-avtcore-rtp-circuit-breakers]
              Perkins, C. and V. Singh, "Multimedia Congestion Control:
              Circuit Breakers for Unicast RTP Sessions", draft-ietf-
              avtcore-rtp-circuit-breakers-05 (work in progress),
              February 2014.

   [I-D.ietf-rmcat-eval-criteria]
              Singh, V. and J. Ott, "Evaluating Congestion Control for
              Interactive Real-time Media", draft-ietf-rmcat-eval-
              criteria-01 (work in progress), March 2014.

   [I-D.ietf-rmcat-cc-requirements]
              Jesup, R., "Congestion Control Requirements For RMCAT",
              draft-ietf-rmcat-cc-requirements-04 (work in progress),
              April 2014.

   [H264]     ITU-T Recommendation H.264, "Advanced video coding for
              generic audiovisual services",
              <http://www.itu.int/rec/T-REC-H.264-201304-I>.

   [HEVC]     ITU-T Recommendation H.265, "High efficiency video
              coding", .

9.2.  Informative References

   [I-D.ietf-rtcweb-use-cases-and-requirements]
              Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real-
              Time Communication Use-cases and Requirements", draft-
              ietf-rtcweb-use-cases-and-requirements-14 (work in
              progress), February 2014.




Zhu, et al.              Expires April 29, 2015                [Page 13]


Internet-Draft  Modelling Video Traffic Sources for RMCAT   October 2014


   [RFC5033]  Floyd, S. and M. Allman, "Specifying New Congestion
              Control Algorithms", BCP 133, RFC 5033, August 2007.

   [Hu2010]   Hu, H., Ma, Z., and Y. Wang, "Optimization of Spatial,
              Temporal and Amplitude Resolution for Rate-Constrained
              Video Coding and Scalable Video Adaptation", inproceedings
              in Proc. 19th IEEE International Conference on Image
              Processing (ICIP'12), September 2012.

   [Ozer2011]
              Ozer, J., "Video Compression for Flash, Apple Devices and
              HTML5", ISBN ISBN-13:978-0976259503, 2011.

   [Tanwir2013]
              Tanwir, S. and H. Perros, "A Survey of VBR Video Traffic
              Models", journal IEEE Communications Surveys and
              Tutorials, vol. 15, no. 5, pp. 1778-1802., October 2013.

Authors' Addresses

    Xiaoqing Zhu
   Cisco Systems
   12515 Research Blvd., Building 4
   Austin, TX  78759
   USA

   Email: xiaoqzhu@cisco.com


   Sergio Mena de la Cruz
   Cisco Systems
   EPFL, Quartier de l'Innovation, Batiment E
   Ecublens, Vaud  1015
   Switzerland

   Email: semena@cisco.com


   Zaheduzzaman Sarker
   Ericsson AB
   Luleae, SE  977 53
   Sweden

   Phone: +46 10 717 37 43
   Email: zaheduzzaman.sarker@ericsson.com






Zhu, et al.              Expires April 29, 2015                [Page 14]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/