--- 1/draft-ietf-rmcat-video-traffic-model-00.txt 2016-07-08 10:16:32.335664608 -0700 +++ 2/draft-ietf-rmcat-video-traffic-model-01.txt 2016-07-08 10:16:32.527669419 -0700 @@ -1,20 +1,20 @@ Network Working Group X. Zhu Internet-Draft S. Mena Intended status: Informational Cisco Systems -Expires: July 18, 2016 Z. Sarker +Expires: January 9, 2017 Z. Sarker Ericsson AB - January 15, 2016 + July 8, 2016 Modeling Video Traffic Sources for RMCAT Evaluations - draft-ietf-rmcat-video-traffic-model-00 + draft-ietf-rmcat-video-traffic-model-01 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, @@ -29,21 +29,21 @@ 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 July 18, 2016. + This Internet-Draft will expire on January 9, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -64,55 +64,55 @@ 5.1. Time-damped response to target rate update . . . . . . . 7 5.2. Temporary burst/oscillation during transient . . . . . . 7 5.3. Output rate fluctuation at steady state . . . . . . . . . 8 5.4. Rate range limit imposed by video content . . . . . . . . 8 6. A Trace-Driven Model . . . . . . . . . . . . . . . . . . . . 8 6.1. Choosing the video sequence and generating the traces . . 9 6.2. Using the traces in the syntethic codec . . . . . . . . . 10 6.2.1. Main algorithm . . . . . . . . . . . . . . . . . . . 10 6.2.2. Notes to the main algorithm . . . . . . . . . . . . . 12 6.3. Varying frame rate and resolution . . . . . . . . . . . . 12 - 7. Comparing and Combining The Two Models . . . . . . . . . . . 13 + 7. Combining The Two Models . . . . . . . . . . . . . . . . . . 13 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 14 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 - 10.2. Informative References . . . . . . . . . . . . . . . . . 14 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 + 10.2. Informative References . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction When evaluating candidate congestion control algorithms designed for real-time interactive media, 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 real-time media flow can be further impacted by 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, - and somewhat decouple from pecularities of any specific video codec. + and somewhat decouple from peculiarities of any specific video codec. It is also desirable that 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 synthetic video traffic source model that captures key characteristics of the behavior of a live video encoder. To this end, this draft presents two reference models. The first is based on statistical modelling; the second is trace-driven. The draft also discusses the pros and cons of each - approach, as well as the possibility to combine both. + approach, as well as the how both approaches can be combined. 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]. 3. Desired Behavior of A Synthetic Video Traffic Model A live video encoder employs encoder rate control to meet a target @@ -139,23 +139,23 @@ o To change bitrate. This includes ability to change framerate and/ or spatial resolution, or to skip frames when required. o To fluctuate around the target bitrate specified by the congestion control module. o To delay in convergence to the target bitrate. o To generate intra-coded or repair 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. + While there exist many different approaches in developing a synthetic + video traffic model, it is desirable that the outcome follows a few + common characteristics, as outlined below. o 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. o Temporal pattern similarity: The individual traffic trace instances generated by the model should mimic the temporal pattern of those from a real video encoder. o Statistical resemblance: The synthetic traffic should match the @@ -185,21 +185,21 @@ The synthetic video encoder takes in raw video frames captured by the camera and then dynamically generates a sequence of encoded video frames with varying size and interval. These encoded frames are processed by other modules in order to transmit the video stream over the network. During the lifetime of a video transmission session, the synthetic video encoder will typically be required to adapt its encoding bitrate, and sometimes the spatial resolution and frame rate. - In our model, the synthetic video encoder module has group of + In our model, the synthetic video encoder module has a group of incoming and outgoing interface calls that allow for interaction with other modules. The following are some of the possible incoming interface calls --- marked as (a) in Figure 1 --- that the synthetic video encoder may accept. The list is not exhaustive and can be complemented by other interface calls if deemed necessary. o Target rate R_v(t): requested at time t, typically from the congestion control module. Depending on the congestion control algorithm in use, the update requests can either be periodic (e.g., once per second), or on-demand (e.g., only when a drastic @@ -249,24 +249,24 @@ -------------------+ +--------------------> interface from interface to other modules (a) other modules (b) Figure 1: Interaction between synthetic video encoder and other modules at the sender 5. A Statistical Reference Model In this section, we describe one simple statistical model of the live - video encoder traffic source. Figure 2 summarizes the list of tuable - parameters in this statistical model. A more comprehensive survey of - popular methods for modelling video traffic source behavior can be - found in [Tanwir2013]. + video encoder traffic source. Figure 2 summarizes the list of + tunable parameters in this statistical model. A more comprehensive + survey of popular methods for modelling video traffic source behavior + can be found in [Tanwir2013]. +---------------+--------------------------------+----------------+ | Notation | Parameter Name | Example Value | +--------------+---------------------------------+----------------+ | R_v(t) | Target rate request at time t | 1 Mbps | | R_o(t) | Output rate at time t | 1.2 Mbps | | tau_v | Encoder reaction latency | 0.2 s | | K_d | Burst duration during transient | 5 frames | | K_r | Burst size during transient | 5:1 | | R_e(t) | Error in output rate at time t | 0.2 Mbps | @@ -304,21 +304,21 @@ occasional burst of large frames are followed by smaller-than average encoded frames. This temporary burst is characterized by two parameters: 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 + the insertion 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 @@ -377,25 +377,24 @@ 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. + the traces. 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. @@ -427,21 +426,21 @@ 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 the 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 + The main idea behind the trace-driven 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 @@ -502,21 +501,21 @@ 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 + statistical model presented in Section 5, the trace-driven synthetic codec can have 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 @@ -527,73 +526,101 @@ 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 + The trace-driven 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 spatial resolution, or both. When the encoded picture quality at a given bitrate is low, one can potentially decrease the frame rate (if the video sequence is currently in low motion) or the spatial resolution in order to improve quality-of-experince (QoE) in the overall encoded video. On the other hand, if target bitrate increases to a point where there is no longer a perceptible improvement in the picture quality of individual frames, then one might afford to increase the spatial resolution or the frame rate (useful if the video is currently in high motion). Many techniques have been proposed to choose over time the best combination of encoder quatization step size, frame rate, and spatial resolution in order to maximize the quality of live video codecs [Ozer2011][Hu2010]. Future work may consider extending the trace- - based codec to accommodate variable frame rate and/or resolution. + driven codec to accommodate variable frame rate and/or resolution. From the perspective of congestion control, varying the spatial resolution typically requires a new intra-coded frame to be generated, thereby incurring a temporary burst in the output traffic pattern. The impact of frame rate change tends to be more subtle: reducing frame rate from high to low leads to sparsely spaced larger encoded packets instead of many densely spaced smaller packets. Such difference in traffic profiles may still affect the performance of congestion control, especially when outgoing packets are not paced at the transport module. We leave the investigation of varying frame rate to future work. -7. Comparing and Combining The Two Models +7. Combining The Two Models - It is worthwhile noting that the statistical and trace-based models - each has its own advantages and drawbacks. Both models are fairly - simple to implement. However, it takes significantly more effort to + It is worthwhile noting that the statistical and trace-driven models + each has its own advantages and drawbacks. While both models are + fairly simple to implement, it takes significantly greater effort to fit the parameters of a statistical model to actual encoder output - data whereas a trace-based model does not require such fitting. On - the other hand, once validated, the statistical model is more - flexible in mimicking a wide range of encoder/content behavior by - simply varying the correponding parameters in the model. In - contrast, a trace-driven model relies, by definition, on additional - data collection efforts for accommodating new codecs or video - contents. + data whereas it is straightforward for a trace-driven model to obtain + encoded frame size data. On the other hand, once validated, the + statistical model is more flexible in mimicking a wide range of + encoder/content behaviors by simply varying the correponding + parameters in the model. In this regard, a trace-driven model relies + -- by definition -- on additional data collection efforts for + accommodating new codecs or video contents. - In general, trace-based model is more realistic for mimicking + In general, trace-driven model is more realistic for mimicking ongoing, steady-state behavior of a video traffic source whereas statistical model is more versatile for simulating transient events (e.g., when target rate changes from A to B with temporary bursts - during the transition). Therefore, it may be desirable to combine - both approaches into a hybrid model, using traces for steady-state - and statistical model for transients. + during the transition). It is also possible to combine both models + into a hybrid approach, using traces during steady-state and + statistical model during transients. + + +---------------+ + transient | Generate next | + +------>| K_d transient | + +-------------+ / | frames | + R_v(t) | Compare | / +---------------+ + ------->| against |/ + | previous | + | target rate |\ + +-------------+ \ +---------------+ + \ | Generate next | + +------>| frame from | + steady-state | trace | + +---------------+ + + Figure 3: Hybrid approach for modeling video traffic + + As shown in Figure 3, the video traffic model operates in transient + state if the requested target rate R_v(t) is substantially higher + than the previous target, or else it operates in steady state. + During transient state, a total of K_d frames are generated by the + statistical model, resulting in 1 big burst frame (on average K_r + times larger than average frame size at the target rate) followed by + K_d-1 small frames. When operating in steady-state, the video + traffic model simply generates a frame according to the trace-driven + model given the target rate. One example criteria for determining + whether the traffic model should operate in transient state is + whether the rate increase exceeds 20% of previous target rate. 8. Implementation Status The statistical model has been implemented as a traffic generator module within the [ns-2] network simulation platform. More recently, both the statistical and trace-driven models have been implemented as a stand-alone traffic source module. This can be easily integrated into network simulation platforms such as [ns-2] and [ns-3], as well as testbeds using a real network. The stand-