idnits 2.17.1 draft-ietf-rmcat-video-traffic-model-07.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 531 has weird spacing: '...= R_ref and...' -- The document date (February 19, 2019) is 1445 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 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: August 23, 2019 Z. Sarker 6 Ericsson AB 7 February 19, 2019 9 Video Traffic Models for RTP Congestion Control Evaluations 10 draft-ietf-rmcat-video-traffic-model-07 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 the target video rate. The second 18 model 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 August 23, 2019. 43 Copyright Notice 45 Copyright (c) 2019 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 . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . 14 77 7. Combining The Two Models . . . . . . . . . . . . . . . . . . 14 78 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 16 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. The 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 the performance of the 103 congestion control module and somewhat decouple from peculiarities of 104 any specific video codec. It is also desirable that evaluation tests 105 are 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. The synthetic traffic model should 112 also contain tunable parameters so that it can be flexibly adjusted 113 to reflect the wide variations in real-world live video encoder 114 behaviors. To this end, this draft presents two reference models. 115 The first is based on statistical modeling. The second is driven by 116 frame size and interval traces recorded from a real-world encoder. 117 The draft also discusses the pros and cons of each approach, as well 118 as how both approaches can be combined into a hybrid model. 120 2. Terminology 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 124 "OPTIONAL" in this document are to be interpreted as described in BCP 125 14 [RFC2119] [RFC8174] when, and only when, they appear in all 126 capitals, as shown here. 128 3. Desired Behavior of A Synthetic Video Traffic Model 130 A live video encoder employs encoder rate control to meet a target 131 rate by varying its encoding parameters, such as quantization step 132 size, frame rate, and picture resolution, based on its estimate of 133 the video content (e.g., motion and scene complexity). In practice, 134 however, several factors prevent the output video rate from perfectly 135 conforming to the input target rate. 137 Due to uncertainties in the captured video scene, the output rate 138 typically deviates from the specified target. In the presence of a 139 significant change in target rate, the encoder's output frame sizes 140 sometimes fluctuate for a short, transient period of time before the 141 output rate converges to the new target. Finally, while most of the 142 frames in a live session are encoded in predictive mode (i.e., 143 P-frames in [H264]), the encoder can occasionally generate a large 144 intra-coded frame (i.e., I-frame as defined in [H264]) or a frame 145 partially containing intra-coded blocks in an attempt to recover from 146 losses, to re-sync with the receiver, or during the transient period 147 of responding to target rate or spatial resolution changes. 149 Hence, a synthetic video source should have the following 150 capabilities: 152 o To change bitrate. This includes the ability to change framerate 153 and/or spatial resolution or to skip frames upon request. 155 o To fluctuate around the target bitrate specified by the congestion 156 control module. 158 o To show a delay in convergence to the target bitrate. 160 o To generate intra-coded or repair frames on demand. 162 While there exist many different approaches in developing a synthetic 163 video traffic model, it is desirable that the outcome follows a few 164 common characteristics, as outlined below. 166 o Low computational complexity: The model should be computationally 167 lightweight, otherwise it defeats the whole purpose of serving as 168 a substitute for a live video encoder. 170 o Temporal pattern similarity: The individual traffic trace 171 instances generated by the model should mimic the temporal pattern 172 of those from a real video encoder. 174 o Statistical resemblance: The synthetic traffic source should match 175 the outcome of the real video encoder in terms of statistical 176 characteristics, such as the mean, variance, peak, and 177 autocorrelation coefficients of the bitrate. It is also important 178 that the statistical resemblance should hold across different time 179 scales, ranging from tens of milliseconds to sub-seconds. 181 o A wide range of coverage: The model should be easily configurable 182 to cover a wide range of codec behaviors (e.g., with either fast 183 or slow reaction time in live encoder rate control) and video 184 content variations (e.g., ranging from high to low motion). 186 These distinct behavior features can be characterized via simple 187 statistical modeling or a trace-driven approach. Section 5 and 188 Section 6 provide an example of each approach, respectively. 189 Section 7 discusses how both models can be combined together. 191 4. Interactions Between Synthetic Video Traffic Source and Other 192 Components at the Sender 194 Figure 1 depicts the interactions of the synthetic video traffic 195 source with other components at the sender, such as the application, 196 the congestion control module, the media packet transport module, 197 etc. Both reference models --- as described later in Section 5 and 198 Section 6 --- follow the same set of interactions. 200 The synthetic video source dynamically generates a sequence of dummy 201 video frames with varying size and interval. These dummy frames are 202 processed by other modules in order to transmit the video stream over 203 the network. During the lifetime of a video transmission session, 204 the synthetic video source will typically be required to adapt its 205 encoding bitrate, and sometimes the spatial resolution and frame 206 rate. 208 In this model, the synthetic video source module has a group of 209 incoming and outgoing interface calls that allow for interaction with 210 other modules. The following are some of the possible incoming 211 interface calls --- marked as (a) in Figure 1 --- that the synthetic 212 video traffic source may accept. The list is not exhaustive and can 213 be complemented by other interface calls if necessary. 215 o Target bitrate R_v: target bitrate request measured in bits per 216 second (bps). Typically, the congestion control module calculates 217 the target bitrate and updates it dynamically over time. 218 Depending on the congestion control algorithm in use, the update 219 requests can either be periodic (e.g., once per second), or on- 220 demand (e.g., only when a drastic bandwidth change over the 221 network is observed). 223 o Target frame rate FPS: the instantaneous frame rate measured in 224 frames-per-second at a given time. This depends on the native 225 camera capture frame rate as well as the target/preferred frame 226 rate configured by the application or user. 228 o Target frame resolution XY: the 2-dimensional vector indicating 229 the preferred frame resolution in pixels. Several factors govern 230 the resolution requested to the synthetic video source over time. 231 Examples of such factors include the capturing resolution of the 232 native camera and the display size of the destination screen. The 233 target frame resolution also depends on the current target bitrate 234 R_v, since it does not make sense to pair very low spatial 235 resolutions with very high bitrates, and vice-versa. 237 o Instant frame skipping: the request to skip the encoding of one or 238 several captured video frames, for instance when a drastic 239 decrease in available network bandwidth is detected. 241 o On-demand generation of intra (I) frame: the request to encode 242 another I frame to avoid further error propagation at the receiver 243 when severe packet losses are observed. This request typically 244 comes from the error control module. It can be initiated either 245 by the sender or by the receiver via Full Intra Request (FIR) 246 messages as defined in [RFC5104]. 248 An example of outgoing interface call --- marked as (b) in Figure 1 249 --- is the rate range [R_min, R_max]. Here, R_min and R_max are 250 meant to capture the dynamic rate range and actual live video encoder 251 is capable of generating given the input video content. This 252 typically depends on the video content complexity and/or display type 253 (e.g., higher R_max for video contents with higher motion complexity, 254 or for displays of higher resolution). Therefore, these values will 255 not change with R_v but may change over time if the content is 256 changing. 258 +-------------+ 259 | | dummy encoded 260 | Synthetic | video frames 261 | Video | --------------> 262 | Source | 263 | | 264 +--------+----+ 265 /|\ | 266 | | 267 -------------------+ +--------------------> 268 interface from interface to 269 other modules (a) other modules (b) 271 Figure 1: Interaction between synthetic video encoder and other 272 modules at the sender 274 5. A Statistical Reference Model 276 This section describes one simple statistical model of the live video 277 encoder traffic source. Figure 2 summarizes the list of tunable 278 parameters in this statistical model. A more comprehensive survey of 279 popular methods for modeling video traffic source behavior can be 280 found in [Tanwir2013]. 282 +===========+====================================+================+ 283 | Notation | Parameter Name | Example Value | 284 +===========+====================================+================+ 285 | R_v | Target bitrate request | 1 Mbps | 286 +-----------+------------------------------------+----------------+ 287 | FPS | Target frame rate | 30 Hz | 288 +-----------+------------------------------------+----------------+ 289 | tau_v | Encoder reaction latency | 0.2 s | 290 +-----------+------------------------------------+----------------+ 291 | K_d | Burst duration of the transient | 8 frames | 292 | | period | | 293 +-----------+------------------------------------+----------------+ 294 | K_B | Burst frame size during the | 13.5 KBytes* | 295 | | transient period | | 296 +-----------+------------------------------------+----------------+ 297 | t0 | Reference frame interval 1/FPS | 33 ms | 298 +-----------+------------------------------------+----------------+ 299 | B0 | Reference frame size R_v/8/FPS | 4.17 KBytes | 300 +-----------+------------------------------------+----------------+ 301 | | Scaling parameter of the zero-mean | | 302 | | Laplacian distribution describing | | 303 | SCALE_t | deviations in normalized frame | 0.15 | 304 | | interval (t-t0)/t0 | | 305 +-----------+------------------------------------+----------------+ 306 | | Scaling parameter of the zero-mean | | 307 | | Laplacian distribution describing | | 308 | SCALE_B | deviations in normalized frame | 0.15 | 309 | | size (B-B0)/B0 | | 310 +-----------+------------------------------------+----------------+ 311 | R_min | minimum rate supported by video | 150 Kbps | 312 | | encoder type or content activity | | 313 +-----------+------------------------------------+----------------+ 314 | R_max | maximum rate supported by video | 1.5 Mbps | 315 | | encoder type or content activity | | 316 +===========+====================================+================+ 318 * Example value of K_B for a video stream encoded at 720p and 319 30 frames per second, using H.264/AVC encoder. 321 Figure 2: List of tunable parameters in a statistical video traffic 322 source model. 324 5.1. Time-damped response to target rate update 326 While the congestion control module can update its target bitrate 327 request R_v at any time, the statistical model dictates that the 328 encoder will only react to such changes tau_v seconds after a 329 previous rate transition. In other words, when the encoder has 330 reacted to a rate change request at time t, it will simply ignore all 331 subsequent rate change requests until time t+tau_v. 333 5.2. Temporary burst and oscillation during the transient period 335 The output bitrate R_o during the period [t, t+tau_v] is considered 336 to be in a transient state when reacting to abrupt changes in target 337 rate. Based on observations from video encoder output data, the 338 encoder reaction to a new target bitrate request can be characterized 339 by high variations in output frame sizes. It is assumed in the model 340 that the overall average output bitrate R_o during this transient 341 period matches the target bitrate R_v. Consequently, the occasional 342 burst of large frames is followed by smaller-than-average encoded 343 frames. 345 This temporary burst is characterized by two parameters: 347 o burst duration K_d: number of frames in the burst event; and 349 o burst frame size K_B: size of the initial burst frame which is 350 typically significantly larger than average frame size at steady 351 state. 353 It can be noted that these burst parameters can also be used to mimic 354 the insertion of a large on-demand I frame in the presence of severe 355 packet losses. The values of K_d and K_B typically depend on the 356 type of video codec, spatial and temporal resolution of the encoded 357 stream, as well as the video content activity level. 359 5.3. Output rate fluctuation at steady state 361 The output bitrate R_o during steady state is modeled as randomly 362 fluctuating around the target bitrate R_v. The output traffic can be 363 characterized as the combination of two random processes denoting the 364 frame interval t and output frame size B over time, as the two major 365 sources of variations in the encoder output. For simplicity, the 366 deviations of t and B from their respective reference levels are 367 modeled as independent and identically distributed (i.i.d) random 368 variables following the Laplacian distribution [Papoulis]. More 369 specifically: 371 o Fluctuations in frame interval: the intervals between adjacent 372 frames have been observed to fluctuate around the reference 373 interval of t0 = 1/FPS. Deviations in normalized frame interval 374 DELTA_t = (t-t0)/t0 can be modeled by a zero-mean Laplacian 375 distribution with scaling parameter SCALE_t. The value of SCALE_t 376 dictates the "width" of the Laplacian distribution and therefore 377 the amount of fluctuation in actual frame intervals (t) with 378 respect to the reference frame interval t0. 380 o Fluctuations in frame size: the output encoded frame sizes also 381 tend to fluctuate around the reference frame size B0=R_v/8/FPS. 382 Likewise, deviations in the normalized frame size DELTA_B = 383 (B-B0)/B0 can be modeled by a zero-mean Laplacian distribution 384 with scaling parameter SCALE_B. The value of SCALE_B dictates the 385 "width" of this second Laplacian distribution and correspondingly 386 the amount of fluctuations in output frame sizes (B) with respect 387 to the reference target B0. 389 Both values of SCALE_t and SCALE_B can be obtained via parameter 390 fitting from empirical data captured for a given video encoder. 391 Example values are listed in Figure 2 based on empirical data 392 presented in [IETF-Interim]. 394 5.4. Rate range limit imposed by video content 396 The output bitrate R_o is further clipped within the dynamic range 397 [R_min, R_max], which in reality are dictated by scene and motion 398 complexity of the captured video content. In the proposed 399 statistical model, these parameters are specified by the application. 401 6. A Trace-Driven Model 403 The second approach for modeling a video traffic source is trace- 404 driven. This can be achieved by running an actual live video encoder 405 on a set of chosen raw video sequences and using the encoder's output 406 traces for constructing a synthetic video source. With this 407 approach, the recorded video traces naturally exhibit temporal 408 fluctuations around a given target bitrate request R_v from the 409 congestion control module. 411 The following list summarizes the main steps of this approach: 413 1. Choose one or more representative raw video sequences. 415 2. Encode the sequence(s) using an actual live video encoder. 416 Repeat the process for a number of bitrates. Keep only the 417 sequence of frame sizes for each bitrate. 419 3. Construct a data structure that contains the output of the 420 previous step. The data structure should allow for easy bitrate 421 lookup. 423 4. Upon a target bitrate request R_v from the controller, look up 424 the closest bitrates among those previously stored. Use the 425 frame size sequences stored for those bitrates to approximate the 426 frame sizes to output. 428 5. The output of the synthetic video traffic source contains 429 "encoded" frames with dummy contents but with realistic sizes. 431 In the following, Section 6.1 explains the first three steps (1-3), 432 Section 6.2 elaborates on the remaining two steps (4-5). Finally, 433 Section 6.3 briefly discusses the possibility to extend the trace- 434 driven model for supporting time-varying frame rate and/or time- 435 varying frame resolution. 437 6.1. Choosing the video sequence and generating the traces 439 The first step is a careful choice of a set of video sequences that 440 are representative of the target use cases for the video traffic 441 model. For the example use case of interactive video conferencing, 442 it is recommended to choose a sequence with content that resembles a 443 "talking head", e.g. from a news broadcast or recording of an actual 444 video conferencing call. 446 The length of the chosen video sequence is a tradeoff. If it is too 447 long, it will be difficult to manage the data structures containing 448 the traces. If it is too short, there will be an obvious periodic 449 pattern in the output frame sizes, leading to biased results when 450 evaluating congestion control performance. It has been empirically 451 determined that a sequence 2 to 4 minutes in length sufficiently 452 avoids the periodic pattern. 454 Given the chosen raw video sequence, denoted S, one can use a live 455 encoder, e.g. some implementation of [H264] or [HEVC], to produce a 456 set of encoded sequences. As discussed in Section 3, the output 457 bitrate of the live encoder can be achieved by tuning three input 458 parameters: quantization step size, frame rate, and picture 459 resolution. In order to simplify the choice of these parameters for 460 a given target rate, one can typically assume a fixed frame rate 461 (e.g. 30 fps) and a fixed resolution (e.g., 720p) when configuring 462 the live encoder. See Section 6.3 for a discussion on how to relax 463 these assumptions. 465 Following these simplifications, the chosen encoder can be configured 466 to start at a constant target bitrate, then vary the quantization 467 step size (internally via the video encoder rate controller) to meet 468 various externally specified target rates. It can be further assumed 469 the first frame is encoded as an I-frame and the rest are P-frames 470 (see, e.g., [H264] for definitions of I- and P-frames). For live 471 encoding, the encoder rate control algorithm typically does not use 472 knowledge of frames in the future when encoding a given frame. 474 Given the minimum and maximum bitrates at which the synthetic codec 475 is to operate (denoted as R_min and R_max, see Section 4), the entire 476 range of target bitrates can be divided into n_s steps. This leads 477 to a encoding bitrate ladder of (n_s + 1) choices equally spaced 478 apart by the step length l = (R_max - R_min)/n_s. The following 479 simple algorithm is used to encode the raw video sequence. 481 r = R_min 482 while r <= R_max do 483 Traces[r] = encode_sequence(S, r, e) 484 r = r + l 486 The function encode_sequence takes as input parameters, respectively, 487 a raw video sequence (S), a constant target rate (r), and an encoder 488 rate control algorithm (e); it returns a vector with the sizes of 489 frames in the order they were encoded. The output vector is stored 490 in a map structure called Traces, whose keys are bitrates and whose 491 values are vectors of frame sizes. 493 The choice of a value for the number of bitrate steps n_s is 494 important, since it determines the number of vectors of frame sizes 495 stored in the map Traces. The minimum value one can choose for n_s 496 is 1; the maximum value depends on the amount of memory available for 497 holding the map Traces. A reasonable value for n_s is one that 498 results in steps of length l = 200 kbps. The next section will 499 discuss further the choice of step length l. 501 Finally, note that, as mentioned in previous sections, R_min and 502 R_max may be modified after the initial sequences are encoded. 503 Henceforth, for notational clarity, we refer to the bitrate range of 504 the trace file as [Rf_min, Rf_max]. The algorithm described in the 505 next section also covers the cases when the current target bitrate is 506 less than Rf_min, or greater than Rf_max. 508 6.2. Using the traces in the synthetic codec 510 The main idea behind the trace-driven synthetic codec is that it 511 mimics the rate adaptation behavior of a real live codec upon dynamic 512 updates of the target bitrate request R_v by the congestion control 513 module. It does so by switching to a different frame size vector 514 stored in the map Traces when needed. 516 6.2.1. Main algorithm 518 The main algorithm for rate adaptation in the synthetic codec 519 maintains two variables: r_current and t_current. 521 o The variable r_current points to one of the keys of map Traces. 522 Upon a change in the value of R_v, typically because the 523 congestion controller detects that the network conditions have 524 changed, r_current is updated based on R_v as follows: 526 R_ref = min (Rf_max, max(Rf_min, R_v)) 528 r_current = r 529 such that 530 (r in keys(Traces) and 531 r <= R_ref and 532 (not(exists) r' in keys(Traces) such that r = Rf_max: the output frame size is calculated by scaling 579 with respect to the highest bitrate Rf_max in the trace file, as 580 follows: 582 w = R_v / Rf_max 583 framesize = min(fs_max, w * Traces[Rf_max][t_current]) 585 In cases b) and c), floating-point arithmetic is used for computing 586 the scaling factor w. The resulting value of the instantaneous frame 587 size (framesize) is further clipped within a reasonable range between 588 fs_min (e.g., 10 bytes) and fs_max (e.g., 1MB). 590 6.2.2. Notes to the main algorithm 592 Note that the main algorithm as described above can be further 593 extended to mimic some additional typical behaviors of a live video 594 encoder. Two examples are given below: 596 o I-frames on demand: The synthetic codec can be extended to 597 simulate the sending of I-frames on demand, e.g., as a reaction to 598 losses. To implement this extension, the codec's incoming 599 interface (see (a) in Figure 1) is augmented with a new function 600 to request a new I-frame. Upon calling such function, t_current 601 is reset to 0. 603 o Variable step length l between R_min and R_max: In the main 604 algorithm, the step length l is fixed for ease of explanation. 605 However, if the range [R_min, R_max] is very wide, it is also 606 possible to define a set of intermediate encoding rates with 607 variable step length. The rationale behind this modification is 608 that the difference between 400 kbps and 600 kbps as target 609 bitrate is much more significant than the difference between 4400 610 kbps and 4600 kbps. For example, one could define steps of length 611 200 Kbps under 1 Mbps, then steps of length 300 Kbps between 1 612 Mbps and 2 Mbps; 400 Kbps between 2 Mbps and 3 Mbps, and so on. 614 6.3. Varying frame rate and resolution 616 The trace-driven synthetic codec model explained in this section is 617 relatively simple due to the choice of fixed frame rate and frame 618 resolution. The model can be extended further to accommodate 619 variable frame rate and/or variable spatial resolution. 621 When the encoded picture quality at a given bitrate is low, one can 622 potentially decrease either the frame rate (if the video sequence is 623 currently in low motion) or the spatial resolution in order to 624 improve quality-of-experience (QoE) in the overall encoded video. On 625 the other hand, if target bitrate increases to a point where there is 626 no longer a perceptible improvement in the picture quality of 627 individual frames, then one might afford to increase the spatial 628 resolution or the frame rate (useful if the video is currently in 629 high motion). 631 Many techniques have been proposed to choose over time the best 632 combination of encoder quantization step size, frame rate, and 633 spatial resolution in order to maximize the quality of live video 634 codecs [Ozer2011][Hu2010]. Future work may consider extending the 635 trace-driven codec to accommodate variable frame rate and/or 636 resolution. 638 From the perspective of congestion control, varying the spatial 639 resolution typically requires a new intra-coded frame to be 640 generated, thereby incurring a temporary burst in the output traffic 641 pattern. The impact of frame rate change tends to be more subtle: 642 reducing frame rate from high to low leads to sparsely spaced larger 643 encoded packets instead of many densely spaced smaller packets. Such 644 difference in traffic profiles may still affect the performance of 645 congestion control, especially when outgoing packets are not paced by 646 the media transport module. Investigation of varying frame rate and 647 resolution are left for future work. 649 7. Combining The Two Models 651 It is worthwhile noting that the statistical and trace-driven models 652 each have their own advantages and drawbacks. Both models are fairly 653 simple to implement. It takes significantly greater effort to fit 654 the parameters of a statistical model to actual encoder output data. 655 In contrast, it is straightforward for a trace-driven model to obtain 656 encoded frame size data. Once validated, the statistical model is 657 more flexible in mimicking a wide range of encoder/content behaviors 658 by simply varying the corresponding parameters in the model. In this 659 regard, a trace-driven model relies -- by definition -- on additional 660 data collection efforts for accommodating new codecs or video 661 contents. 663 In general, the trace-driven model is more realistic for mimicking 664 the ongoing, steady-state behavior of a video traffic source with 665 fluctuations around a constant target rate. In contrast, the 666 statistical model is more versatile for simulating the behavior of a 667 video stream in transient, such as when encountering sudden rate 668 changes. It is also possible to combine both methods into a hybrid 669 model. In this case, the steady-state behavior is driven by traces 670 during steady state and the transient-state behavior is driven by the 671 statistical model. 673 transient +---------------+ 674 state | Generate next | 675 +------>| K_d transient | 676 +-----------------+ / | frames | 677 R_v | Compare against | / +---------------+ 678 ------>| previous |/ 679 | target bitrate |\ 680 +-----------------+ \ +---------------+ 681 \ | Generate next | 682 +------>| frame from | 683 steady | trace | 684 state +---------------+ 686 Figure 3: A hybrid video traffic model 688 As shown in Figure 3, the video traffic model operates in a transient 689 state if the requested target rate R_v is substantially different 690 from the previous target, or else it operates in steady state. 691 During the transient state, a total of K_d frames are generated by 692 the statistical model, resulting in one (1) big burst frame with size 693 K_B followed by K_d-1 smaller frames. When operating at steady 694 state, the video traffic model simply generates a frame according to 695 the trace-driven model given the target rate, while modulating the 696 frame interval according to the distribution specified by the 697 statistical model. One example criterion for determining whether the 698 traffic model should operate in a transient state is whether the rate 699 change exceeds 10% of the previous target rate. Finally, as this 700 model follows transient-state behavior dictated by the statistical 701 model, upon a substantial rate change, the model will follow the 702 time-damping mechanism as defined in Section 5.1, which is governed 703 by parameter tau_v. 705 8. Implementation Status 707 The statistical, trace-driven, and hybrid models as described in this 708 draft have been implemented as a stand-alone, platform-independent 709 synthetic traffic source module. It can be easily integrated into 710 network simulation platforms such as [ns-2] and [ns-3], as well as 711 testbeds using a real network. The stand-alone traffic source module 712 is available as an open source implementation at [Syncodecs]. 714 9. IANA Considerations 716 There are no IANA impacts in this memo. 718 10. Security Considerations 720 The synthetic video traffic models as described in this draft do not 721 impose any security threats. They are designed to mimic realistic 722 traffic patterns for evaluating candidate RTP-based congestion 723 control algorithms, so as to ensure stable operations of the network. 724 It is RECOMMENDED that candidate algorithms be tested using the video 725 traffic models presented in this draft before wide deployment over 726 the Internet. If the generated synthetic traffic flows are sent over 727 the Internet, they also need to be congestion controlled. 729 11. References 731 11.1. Normative References 733 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 734 Requirement Levels", BCP 14, RFC 2119, 735 DOI 10.17487/RFC2119, March 1997, 736 . 738 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 739 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 740 May 2017, . 742 11.2. Informative References 744 [H264] ITU-T Recommendation H.264, "Advanced video coding for 745 generic audiovisual services", May 2003, 746 . 748 [HEVC] ITU-T Recommendation H.265, "High efficiency video 749 coding", April 2013, 750 . 752 [Hu2010] Hu, H., Ma, Z., and Y. Wang, "Optimization of Spatial, 753 Temporal and Amplitude Resolution for Rate-Constrained 754 Video Coding and Scalable Video Adaptation", in Proc. 19th 755 IEEE International Conference on Image 756 Processing, (ICIP'12), September 2012. 758 [IETF-Interim] 759 Zhu, X., Mena, S., and Z. Sarker, "Update on RMCAT Video 760 Traffic Model: Trace Analysis and Model Update", April 761 2017, . 765 [ns-2] "The Network Simulator - ns-2", 766 . 768 [ns-3] "The Network Simulator - ns-3", . 770 [Ozer2011] 771 Ozer, J., "Video Compression for Flash, Apple Devices and 772 HTML5", ISBN 13:978-0976259503, 2011. 774 [Papoulis] 775 Papoulis, A., "Probability, Random Variables and 776 Stochastic Processes", 2002. 778 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 779 "Codec Control Messages in the RTP Audio-Visual Profile 780 with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, 781 February 2008, . 783 [Syncodecs] 784 Mena, S., D'Aronco, S., and X. Zhu, "Syncodecs: Synthetic 785 codecs for evaluation of RMCAT work", 786 . 788 [Tanwir2013] 789 Tanwir, S. and H. Perros, "A Survey of VBR Video Traffic 790 Models", IEEE Communications Surveys and Tutorials, vol. 791 15, no. 5, pp. 1778-1802., October 2013. 793 Authors' Addresses 794 Xiaoqing Zhu 795 Cisco Systems 796 12515 Research Blvd., Building 4 797 Austin, TX 78759 798 USA 800 Email: xiaoqzhu@cisco.com 802 Sergio Mena de la Cruz 803 Cisco Systems 804 EPFL, Quartier de l'Innovation, Batiment E 805 Ecublens, Vaud 1015 806 Switzerland 808 Email: semena@cisco.com 810 Zaheduzzaman Sarker 811 Ericsson AB 812 Luleae, SE 977 53 813 Sweden 815 Phone: +46 10 717 37 43 816 Email: zaheduzzaman.sarker@ericsson.com