idnits 2.17.1 draft-ietf-rmcat-video-traffic-model-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 3, 2018) is 1993 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group X. Zhu 3 Internet-Draft S. Mena 4 Intended status: Informational Cisco Systems 5 Expires: May 7, 2019 Z. Sarker 6 Ericsson AB 7 November 3, 2018 9 Video Traffic Models for RTP Congestion Control Evaluations 10 draft-ietf-rmcat-video-traffic-model-06 12 Abstract 14 This document describes two reference video traffic models for 15 evaluating RTP congestion control algorithms. The first model 16 statistically characterizes the behavior of a live video encoder in 17 response to changing requests on target video rate. The second model 18 is trace-driven, and emulates the output of actual encoded video 19 frame sizes from a high-resolution test sequence. Both models are 20 designed to strike a balance between simplicity, repeatability, and 21 authenticity in modeling the interactions between a live video 22 traffic source and the congestion control module. Finally, the 23 document describes how both approaches can be combined into a hybrid 24 model. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on May 7, 2019. 43 Copyright Notice 45 Copyright (c) 2018 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Desired Behavior of A Synthetic Video Traffic Model . . . . . 3 63 4. Interactions Between Synthetic Video Traffic Source and 64 Other Components at the Sender . . . . . . . . . . . . . . . 4 65 5. A Statistical Reference Model . . . . . . . . . . . . . . . . 6 66 5.1. Time-damped response to target rate update . . . . . . . 7 67 5.2. Temporary burst and oscillation during the transient 68 period . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 5.3. Output rate fluctuation at steady state . . . . . . . . . 8 70 5.4. Rate range limit imposed by video content . . . . . . . . 9 71 6. A Trace-Driven Model . . . . . . . . . . . . . . . . . . . . 9 72 6.1. Choosing the video sequence and generating the traces . . 10 73 6.2. Using the traces in the synthetic codec . . . . . . . . . 11 74 6.2.1. Main algorithm . . . . . . . . . . . . . . . . . . . 11 75 6.2.2. Notes to the main algorithm . . . . . . . . . . . . . 13 76 6.3. Varying frame rate and resolution . . . . . . . . . . . . 13 77 7. Combining The Two Models . . . . . . . . . . . . . . . . . . 14 78 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 15 79 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 80 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 81 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 82 11.1. Normative References . . . . . . . . . . . . . . . . . . 16 83 11.2. Informative References . . . . . . . . . . . . . . . . . 16 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 86 1. Introduction 88 When evaluating candidate congestion control algorithms designed for 89 real-time interactive media, it is important to account for the 90 characteristics of traffic patterns generated from a live video 91 encoder. Unlike synthetic traffic sources that can conform perfectly 92 to the rate changing requests from the congestion control module, a 93 live video encoder can be sluggish in reacting to such changes. 94 Output rate of a live video encoder also typically deviates from the 95 target rate due to uncertainties in the encoder rate control process. 97 Consequently, end-to-end delay and loss performance of a real-time 98 media flow can be further impacted by rate variations introduced by 99 the live encoder. 101 On the other hand, evaluation results of a candidate RTP congestion 102 control algorithm should mostly reflect performance of the congestion 103 control module, and somewhat decouple from peculiarities of any 104 specific video codec. It is also desirable that evaluation tests are 105 repeatable, and be easily duplicated across different candidate 106 algorithms. 108 One way to strike a balance between the above considerations is to 109 evaluate congestion control algorithms using a synthetic video 110 traffic source model that captures key characteristics of the 111 behavior of a live video encoder. To this end, this draft presents 112 two reference models. The first is based on statistical modeling; 113 the second is trace-driven. The draft also discusses the pros and 114 cons of each approach, as well as how both approaches can be combined 115 into a hybrid model. 117 2. Terminology 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 121 "OPTIONAL" in this document are to be interpreted as described in BCP 122 14 [RFC2119] [RFC8174] when, and only when, they appear in all 123 capitals, as shown here. 125 3. Desired Behavior of A Synthetic Video Traffic Model 127 A live video encoder employs encoder rate control to meet a target 128 rate by varying its encoding parameters, such as quantization step 129 size, frame rate, and picture resolution, based on its estimate of 130 the video content (e.g., motion and scene complexity). In practice, 131 however, several factors prevent the output video rate from perfectly 132 conforming to the input target rate. 134 Due to uncertainties in the captured video scene, the output rate 135 typically deviates from the specified target. In the presence of a 136 significant change in target rate, the encoder output frame sizes 137 sometimes fluctuates for a short, transient period of time before the 138 output rate converges to the new target. Finally, while most of the 139 frames in a live session are encoded in predictive mode, the encoder 140 can occasionally generate a large intra-coded frame (or a frame 141 partially containing intra-coded blocks) in an attempt to recover 142 from losses, to re-sync with the receiver, or during the transient 143 period of responding to target rate or spatial resolution changes. 145 Hence, a synthetic video source should have the following 146 capabilities: 148 o To change bitrate. This includes ability to change framerate and/ 149 or spatial resolution, or to skip frames when required. 151 o To fluctuate around the target bitrate specified by the congestion 152 control module. 154 o To show a delay in convergence to the target bitrate. 156 o To generate intra-coded or repair frames on demand. 158 While there exist many different approaches in developing a synthetic 159 video traffic model, it is desirable that the outcome follows a few 160 common characteristics, as outlined below. 162 o Low computational complexity: The model should be computationally 163 lightweight, otherwise it defeats the whole purpose of serving as 164 a substitute for a live video encoder. 166 o Temporal pattern similarity: The individual traffic trace 167 instances generated by the model should mimic the temporal pattern 168 of those from a real video encoder. 170 o Statistical resemblance: The synthetic traffic source should match 171 the outcome of the real video encoder in terms of statistical 172 characteristics, such as the mean, variance, peak, and 173 autocorrelation coefficients of the bitrate. It is also important 174 that the statistical resemblance should hold across different time 175 scales, ranging from tens of milliseconds to sub-seconds. 177 o Wide range of coverage: The model should be easily configurable to 178 cover a wide range of codec behaviors (e.g., with either fast or 179 slow reaction time in live encoder rate control) and video content 180 variations (e.g., ranging from high-motion to low-motion). 182 These distinct behavior features can be characterized via simple 183 statistical modelling, or a trace-driven approach. Section 5 and 184 Section 6 provide an example of each approach, respectively. 185 Section 7 discusses how both models can be combined together. 187 4. Interactions Between Synthetic Video Traffic Source and Other 188 Components at the Sender 190 Figure 1 depicts the interactions of the synthetic video traffic 191 source with other components at the sender, such as the application, 192 the congestion control module, the media packet transport module, 193 etc. Both reference models --- as described later in Section 5 and 194 Section 6 --- follow the same set of interactions. 196 The synthetic video source dynamically generates a sequence of dummy 197 video frames with varying size and interval. These dummy frames are 198 processed by other modules in order to transmit the video stream over 199 the network. During the lifetime of a video transmission session, 200 the synthetic video source will typically be required to adapt its 201 encoding bitrate, and sometimes the spatial resolution and frame 202 rate. 204 In this model, the synthetic video source module has a group of 205 incoming and outgoing interface calls that allow for interaction with 206 other modules. The following are some of the possible incoming 207 interface calls --- marked as (a) in Figure 1 --- that the synthetic 208 video traffic source may accept. The list is not exhaustive and can 209 be complemented by other interface calls if deemed necessary. 211 o Target rate R_v: target rate request, typically calculated by the 212 congestion control module and updated dynamically over time. 213 Depending on the congestion control algorithm in use, the update 214 requests can either be periodic (e.g., once per second), or on- 215 demand (e.g., only when a drastic bandwidth change over the 216 network is observed). 218 o Target frame rate FPS: the instantaneous frame rate measured in 219 frames-per-second at a given time. This depends on the native 220 camera capture frame rate as well as the target/preferred frame 221 rate configured by the application or user. 223 o Target frame resolution XY: the 2-dimensional vector indicating 224 the preferred frame resolution in pixels. Several factors govern 225 the resolution requested to the synthetic video source over time. 226 Examples of such factors include the capturing resolution of the 227 native camera and the display size of the destination screen. The 228 target frame resolution also depends on the current target rate 229 R_v, since very small resolutions do not make sense with very high 230 bitrates, and vice-versa. 232 o Instant frame skipping: the request to skip the encoding of one or 233 several captured video frames, for instance when a drastic 234 decrease in available network bandwidth is detected. 236 o On-demand generation of intra (I) frame: the request to encode 237 another I frame to avoid further error propagation at the 238 receiver, if severe packet losses are observed. This request 239 typically comes from the error control module. 241 An example of outgoing interface call --- marked as (b) in Figure 1 242 --- is the rate range [R_min, R_max]. Here, R_min and R_max are 243 meant to capture the dynamic rate range and actual live video encoder 244 is capable of generating given the input video content. This 245 typically depends on the video content complexity and/or display type 246 (e.g., higher R_max for video contents with higher motion complexity, 247 or for displays of higher resolution). Therefore, these values will 248 not change with R_v, but may change over time if the content is 249 changing. 251 +-------------+ 252 | | encoded video 253 | Synthetic | frames 254 | Video | --------------> 255 | Source | 256 | | 257 +--------+----+ 258 /|\ | 259 | | 260 -------------------+ +--------------------> 261 interface from interface to 262 other modules (a) other modules (b) 264 Figure 1: Interaction between synthetic video encoder and other 265 modules at the sender 267 5. A Statistical Reference Model 269 This section describes one simple statistical model of the live video 270 encoder traffic source. Figure 2 summarizes the list of tunable 271 parameters in this statistical model. A more comprehensive survey of 272 popular methods for modeling video traffic source behavior can be 273 found in [Tanwir2013]. 275 +===========+====================================+================+ 276 | Notation | Parameter Name | Example Value | 277 +===========+====================================+================+ 278 | R_v | Target rate request | 1 Mbps | 279 +-----------+------------------------------------+----------------+ 280 | FPS | Target frame rate | 30 Hz | 281 +-----------+------------------------------------+----------------+ 282 | tau_v | Encoder reaction latency | 0.2 s | 283 +-----------+------------------------------------+----------------+ 284 | K_d | Burst duration of the transient | 8 frames | 285 | | period | | 286 +-----------+------------------------------------+----------------+ 287 | K_B | Burst frame size during the | 13.5 KBytes* | 288 | | transient period | | 289 +-----------+------------------------------------+----------------+ 290 | t0 | Reference frame interval 1/FPS | 33 ms | 291 +-----------+------------------------------------+----------------+ 292 | B0 | Reference frame size R_v/8/FPS | 4.17 KBytes | 293 +-----------+------------------------------------+----------------+ 294 | | Scaling parameter of the zero-mean | | 295 | | Laplacian distribution describing | | 296 | SCALE_t | deviations in normalized frame | 0.15 | 297 | | interval (t-t0)/t0 | | 298 +-----------+------------------------------------+----------------+ 299 | | Scaling parameter of the zero-mean | | 300 | | Laplacian distribution describing | | 301 | SCALE_B | deviations in normalized frame | 0.15 | 302 | | size (B-B0)/B0 | | 303 +-----------+------------------------------------+----------------+ 304 | R_min | minimum rate supported by video | 150 Kbps | 305 | | encoder type or content activity | | 306 +-----------+------------------------------------+----------------+ 307 | R_max | maximum rate supported by video | 1.5 Mbps | 308 | | encoder type or content activity | | 309 +===========+====================================+================+ 311 * Example value of K_B for a video stream encoded at 720p and 312 30 frames per second, using H.264/AVC encoder. 314 Figure 2: List of tunable parameters in a statistical video traffic 315 source model. 317 5.1. Time-damped response to target rate update 319 While the congestion control module can update its target rate 320 request R_v at any time, the statistical model dictates that the 321 encoder will only react to such changes tau_v seconds after a 322 previous rate transition. In other words, when the encoder has 323 reacted to a rate change request at time t, it will simply ignore all 324 subsequent rate change requests until time t+tau_v. 326 5.2. Temporary burst and oscillation during the transient period 328 The output rate R_o during the period [t, t+tau_v] is considered to 329 be in a transient state. Based on observations from video encoder 330 output data, the encoder reaction to a new target rate request can be 331 characterized by high variation in output frame sizes. It is assumed 332 in the model that the overall average output rate R_o during this 333 transient period matches the target rate R_v. Consequently, the 334 occasional burst of large frames are followed by smaller-than-average 335 encoded frames. 337 This temporary burst is characterized by two parameters: 339 o burst duration K_d: number of frames in the burst event; and 341 o burst frame size K_B: size of the initial burst frame which is 342 typically significantly larger than average frame size at steady 343 state. 345 It can be noted that these burst parameters can also be used to mimic 346 the insertion of a large on-demand I frame in the presence of severe 347 packet losses. The values of K_d and K_B typically depend on the 348 type of video codec, spatial and temporal resolution of the encoded 349 stream, as well as the video content activity level. 351 5.3. Output rate fluctuation at steady state 353 The output rate R_o during steady state is modelled as randomly 354 fluctuating around the target rate R_v. The output traffic can be 355 characterized as the combination of two random processes denoting the 356 frame interval t and output frame size B over time. These two random 357 processes capture two sources of variations in the encoder output: 359 o Fluctuations in frame interval: the intervals between adjacent 360 frames have been observed to fluctuate around the reference 361 interval of t0 = 1/FPS. Deviations in normalized frame interval 362 DELTA_t = (t-t0)/t0 can be modelled by a zero-mean Laplacian 363 distribution with scaling parameter SCALE_t. The value of SCALE_t 364 dictates the "width" of the Laplacian distribution and therefore 365 the amount of fluctuations in actual frame intervals (t) with 366 respect to the reference frame interval t0. 368 o Fluctuations in frame size: size of the output encoded frames also 369 tend to fluctuate around the reference frame size B0=R_v/8/FPS. 371 Likewise, deviations in the normalized frame size DELTA_B = 372 (B-B0)/B0 can be modelled by a zero-mean Laplacian distribution 373 with scaling parameter SCALE_B. The value of SCALE_B dictates the 374 "width" of this second Laplacian distribution and correspondingly 375 the amount of fluctuations in output frame sizes (B) with respect 376 to the reference target B0. 378 Both values of SCALE_t and SCALE_B can be obtained via parameter 379 fitting from empirical data captured for a given video encoder. 380 Example values are listed in Figure 2 based on empirical data 381 presented in [IETF-Interim]. 383 5.4. Rate range limit imposed by video content 385 The output rate R_o is further clipped within the dynamic range 386 [R_min, R_max], which in reality are dictated by scene and motion 387 complexity of the captured video content. In the proposed 388 statistical model, these parameters are specified by the application. 390 6. A Trace-Driven Model 392 The second approach for modelling a video traffic source is trace- 393 driven. This can be achieved by running an actual live video encoder 394 on a set of chosen raw video sequences and using the encoder's output 395 traces for constructing a synthetic video source. With this 396 approach, the recorded video traces naturally exhibit temporal 397 fluctuations around a given target rate request R_v from the 398 congestion control module. 400 The following list summarizes the main steps of this approach: 402 1. Choose one or more representative raw video sequences. 404 2. Encode the sequence(s) using an actual live video encoder. 405 Repeat the process for a number of bitrates. Keep only the 406 sequence of frame sizes for each bitrate. 408 3. Construct a data structure that contains the output of the 409 previous step. The data structure should allow for easy bitrate 410 lookup. 412 4. Upon a target bitrate request R_v from the controller, look up 413 the closest bitrates among those previously stored. Use the 414 frame size sequences stored for those bitrates to approximate the 415 frame sizes to output. 417 5. The output of the synthetic video traffic source contains 418 "encoded" frames with dummy contents but with realistic sizes. 420 In the following, Section 6.1 explains the first three steps (1-3), 421 Section 6.2 elaborates on the remaining two steps (4-5). Finally, 422 Section 6.3 briefly discusses the possibility to extend the trace- 423 driven model for supporting time-varying frame rate and/or time- 424 varying frame resolution. 426 6.1. Choosing the video sequence and generating the traces 428 The first step is a careful choice of a set of video sequences that 429 are representative of the target use cases for the video traffic 430 model. For the example use case of interactive video conferencing, 431 it is recommended to choose a low-motion sequence that resembles a 432 "talking head", e.g. from a news broadcast or recording of an actual 433 video conferencing call. 435 The length of the chosen video sequence is a tradeoff. If it is too 436 long, it will be difficult to manage the data structures containing 437 the traces. If it is too short, there will be an obvious periodic 438 pattern in the output frame sizes, leading to biased results when 439 evaluating congestion control performance. It has been empirically 440 determined that a sequence with a length between 2 and 4 minutes 441 strikes a fair tradeoff. 443 Given the chosen raw video sequence, denoted S, one can use a live 444 encoder, e.g. some implementation of [H264] or [HEVC], to produce a 445 set of encoded sequences. As discussed in Section 3, the output 446 bitrate of the live encoder can be achieved by tuning three input 447 parameters: quantization step size, frame rate, and picture 448 resolution. In order to simplify the choice of these parameters for 449 a given target rate, one can typically assume a fixed frame rate 450 (e.g. 30 fps) and a fixed resolution (e.g., 720p) when configuring 451 the live encoder. See Section 6.3 for a discussion on how to relax 452 these assumptions. 454 Following these simplifications, the chosen encoder can be configured 455 to start at a constant target bitrate, then vary the quantization 456 step size (internally via the video encoder rate controller) to meet 457 various externally specified target rates. It can be further assumed 458 the first frame is encoded as an I-frame and the rest are P-frames. 459 For live encoding, the encoder rate control algorithm typically does 460 not use knowledge of frames in the future when encoding a given 461 frame. 463 Given the minimum and maximum bitrates at which the synthetic codec 464 is to operate (denoted as R_min and R_max, see Section 4), the entire 465 range of target bitrates can be divided into n_s + 1 bitrate steps of 466 length l = (R_max - R_min) / n_s. The following simple algorithm is 467 used to encode the raw video sequence. 469 r = R_min 470 while r <= R_max do 471 Traces[r] = encode_sequence(S, r, e) 472 r = r + l 474 The function encode_sequence takes as input parameters, respectively, 475 a raw video sequence (S), a constant target rate (r), and an encoder 476 rate control algorithm (e); it returns a vector with the sizes of 477 frames in the order they were encoded. The output vector is stored 478 in a map structure called Traces, whose keys are bitrates and whose 479 values are vectors of frame sizes. 481 The choice of a value for n_s is important, as it determines the 482 number of vectors of frame sizes stored in the map Traces. The 483 minimum value one can choose for n_s is 1, and the maximum value 484 depends on the amount of memory available for holding the map Traces. 485 A reasonable value for n_s is one that results in steps of length l = 486 200 kbps. The next section will discuss further the choice of the 487 step length l. 489 Finally, note that, as mentioned in previous sections, R_min and 490 R_max may be modified after the initial sequences are encoded. 491 Hence, the algorithm described in the next section also covers the 492 cases when the current target bitrate is less than R_min, or greater 493 than R_max. 495 6.2. Using the traces in the synthetic codec 497 The main idea behind the trace-driven synthetic codec is that it 498 mimics the rate adaptation behavior of a real live codec upon dynamic 499 updates of the target rate R_v by the congestion control module. It 500 does so by switching to a different frame size vector stored in the 501 map Traces when needed. 503 6.2.1. Main algorithm 505 The main algorithm for rate adaptation in the synthetic codec 506 maintains two variables: r_current and t_current. 508 o The variable r_current points to one of the keys of map Traces. 509 Upon a change in the value of R_v, typically because the 510 congestion controller detects that the network conditions have 511 changed, r_current is updated to the greatest key in Traces that 512 is less than or equal to the new value of R_v. It is assumed that 513 the value of R_v is clipped within the range [R_min, R_max]. 515 r_current = r 516 such that 517 (r in keys(Traces) and 518 r <= R_v and 519 (not(exists) r' in keys(Traces) such that r = R_max: the output frame size is calculated by scaling with 566 respect to the highest bitrate R_max: 568 factor = R_v / R_max 569 framesize = factor * Traces[R_max][t_current] 571 In case b), the minimum output size is set to 1 byte, since the value 572 of factor can be arbitrarily close to 0. 574 6.2.2. Notes to the main algorithm 576 Note that main algorithm as described above can be further extended 577 to mimic some additional typical behaviors of a live video encoder. 578 Two examples are given below: 580 o I-frames on demand: The synthetic codec can be extended to 581 simulate the sending of I-frames on demand, e.g., as a reaction to 582 losses. To implement this extension, the codec's incoming 583 interface (see (a) in Figure 1) is augmented with a new function 584 to request a new I-frame. Upon calling such function, t_current 585 is reset to 0. 587 o Variable step length l between R_min and R_max: In the main 588 algorithm, the step length l is fixed for ease of explanation. 589 However, if the range [R_min, R_max] is very wide, it is also 590 possible to define a set of intermediate encoding rates with 591 variable step length. The rationale behind this modification is 592 that the difference between 400 kbps and 600 kbps as target 593 bitrate is much more significant than the difference between 4400 594 kbps and 4600 kbps. For example, one could define steps of length 595 200 Kbps under 1 Mbps, then steps of length 300 Kbps between 1 596 Mbps and 2 Mbps; 400 Kbps between 2 Mbps and 3 Mbps, and so on. 598 6.3. Varying frame rate and resolution 600 The trace-driven synthetic codec model explained in this section is 601 relatively simple due to fixed frame rate and frame resolution. The 602 model can extended further to accommodate variable frame rate and/or 603 variable spatial resolution. 605 When the encoded picture quality at a given bitrate is low, one can 606 potentially decrease either the frame rate (if the video sequence is 607 currently in low motion) or the spatial resolution in order to 608 improve quality-of-experince (QoE) in the overall encoded video. On 609 the other hand, if target bitrate increases to a point where there is 610 no longer a perceptible improvement in the picture quality of 611 individual frames, then one might afford to increase the spatial 612 resolution or the frame rate (useful if the video is currently in 613 high motion). 615 Many techniques have been proposed to choose over time the best 616 combination of encoder quatization step size, frame rate, and spatial 617 resolution in order to maximize the quality of live video codecs 618 [Ozer2011][Hu2010]. Future work may consider extending the trace- 619 driven codec to accommodate variable frame rate and/or resolution. 621 From the perspective of congestion control, varying the spatial 622 resolution typically requires a new intra-coded frame to be 623 generated, thereby incurring a temporary burst in the output traffic 624 pattern. The impact of frame rate change tends to be more subtle: 625 reducing frame rate from high to low leads to sparsely spaced larger 626 encoded packets instead of many densely spaced smaller packets. Such 627 difference in traffic profiles may still affect the performance of 628 congestion control, especially when outgoing packets are not paced by 629 the media transport module. Investigation of varying frame rate and 630 resolution are left for future work. 632 7. Combining The Two Models 634 It is worthwhile noting that the statistical and trace-driven models 635 each has its own advantages and drawbacks. Both models are fairly 636 simple to implement. It takes significantly greater effort to fit 637 the parameters of a statistical model to actual encoder output data 638 whereas it is straightforward for a trace-driven model to obtain 639 encoded frame size data. On the other hand, once validated, the 640 statistical model is more flexible in mimicking a wide range of 641 encoder/content behaviors by simply varying the correponding 642 parameters in the model. In this regard, a trace-driven model relies 643 -- by definition -- on additional data collection efforts for 644 accommodating new codecs or video contents. 646 In general, the trace-driven model is more realistic for mimicking 647 ongoing, steady-state behavior of a video traffic source whereas the 648 statistical model is more versatile for simulating its transient- 649 state behavior such as a sudden rate change. It is also possible to 650 combine both methods into a hybrid model, so that the steady-state 651 behavior is driven by traces during steady-state and the transient- 652 state behavior is driven by the statistical model. 654 transient +---------------+ 655 state | Generate next | 656 +------>| K_d transient | 657 +-------------+ / | frames | 658 R_v | Compare | / +---------------+ 659 ------->| against |/ 660 | previous | 661 | target rate |\ 662 +-------------+ \ +---------------+ 663 \ | Generate next | 664 +------>| frame from | 665 steady | trace | 666 state +---------------+ 668 Figure 3: A hybrid video traffic model 670 As shown in Figure 3, the video traffic model operates in transient 671 state if the requested target rate R_v is substantially higher than 672 the previous target, or else it operates in steady state. During the 673 transient state, a total of K_d frames are generated by the 674 statistical model, resulting in one (1) big burst frame with size K_B 675 followed by K_d-1 smaller frames. When operating at steady-state, 676 the video traffic model simply generates a frame according to the 677 trace-driven model given the target rate, while modulating the frame 678 interval according to the distribution specified by the statistical 679 model. One example criterion for determining whether the traffic 680 model should operate in transient state is whether the rate increase 681 exceeds 10% of previous target rate. Finally, as this model follows 682 transient state behavior dictated by the statistical model, upon a 683 substantial rate change, the model will follow the time-damping 684 mechanism defined in Section 5.1, which is governed by parameter 685 tau_v. 687 8. Implementation Status 689 The statistical model has been implemented as a traffic generator 690 module within the [ns-2] network simulation platform. 692 More recently, the statistical, trace-driven, and hybrid models have 693 been implemented as a stand-alone, platform-independent traffic 694 source module. This can be easily integrated into network simulation 695 platforms such as [ns-2] and [ns-3], as well as testbeds using a real 696 network. The stand-alone traffic source module is available as an 697 open source implementation at [Syncodecs]. 699 9. IANA Considerations 701 There are no IANA impacts in this memo. 703 10. Security Considerations 705 It is important to evaluate RTP-based congestion control schemes 706 using realistic traffic patterns, so as to ensure stable operations 707 of the network. Therefore, it is RECOMMENDED that candidate RTP- 708 based congestion control algorithms be tested using the video traffic 709 models presented in this draft before wide deployment over the 710 Internet. 712 11. References 714 11.1. Normative References 716 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 717 Requirement Levels", BCP 14, RFC 2119, 718 DOI 10.17487/RFC2119, March 1997, 719 . 721 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 722 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 723 May 2017, . 725 11.2. Informative References 727 [H264] ITU-T Recommendation H.264, "Advanced video coding for 728 generic audiovisual services", May 2003, 729 . 731 [HEVC] ITU-T Recommendation H.265, "High efficiency video 732 coding", April 2013, 733 . 735 [Hu2010] Hu, H., Ma, Z., and Y. Wang, "Optimization of Spatial, 736 Temporal and Amplitude Resolution for Rate-Constrained 737 Video Coding and Scalable Video Adaptation", in Proc. 19th 738 IEEE International Conference on Image 739 Processing, (ICIP'12), September 2012. 741 [IETF-Interim] 742 Zhu, X., Mena, S., and Z. Sarker, "Update on RMCAT Video 743 Traffic Model: Trace Analysis and Model Update", April 744 2017, . 748 [ns-2] "The Network Simulator - ns-2", 749 . 751 [ns-3] "The Network Simulator - ns-3", . 753 [Ozer2011] 754 Ozer, J., "Video Compression for Flash, Apple Devices and 755 HTML5", ISBN 13:978-0976259503, 2011. 757 [Syncodecs] 758 Mena, S., D'Aronco, S., and X. Zhu, "Syncodecs: Synthetic 759 codecs for evaluation of RMCAT work", 760 . 762 [Tanwir2013] 763 Tanwir, S. and H. Perros, "A Survey of VBR Video Traffic 764 Models", IEEE Communications Surveys and Tutorials, vol. 765 15, no. 5, pp. 1778-1802., October 2013. 767 Authors' Addresses 769 Xiaoqing Zhu 770 Cisco Systems 771 12515 Research Blvd., Building 4 772 Austin, TX 78759 773 USA 775 Email: xiaoqzhu@cisco.com 777 Sergio Mena de la Cruz 778 Cisco Systems 779 EPFL, Quartier de l'Innovation, Batiment E 780 Ecublens, Vaud 1015 781 Switzerland 783 Email: semena@cisco.com 785 Zaheduzzaman Sarker 786 Ericsson AB 787 Luleae, SE 977 53 788 Sweden 790 Phone: +46 10 717 37 43 791 Email: zaheduzzaman.sarker@ericsson.com