draft-ietf-rmcat-video-traffic-model-00.txt		draft-ietf-rmcat-video-traffic-model-01.txt
	Network Working Group X. Zhu		Network Working Group X. Zhu
	Internet-Draft S. Mena		Internet-Draft S. Mena
	Intended status: Informational Cisco Systems		Intended status: Informational Cisco Systems
	Expires: July 18, 2016 Z. Sarker		Expires: January 9, 2017 Z. Sarker
	Ericsson AB		Ericsson AB
	January 15, 2016		July 8, 2016
	Modeling Video Traffic Sources for RMCAT Evaluations		Modeling Video Traffic Sources for RMCAT Evaluations
	draft-ietf-rmcat-video-traffic-model-00		draft-ietf-rmcat-video-traffic-model-01
	Abstract		Abstract
	This document describes two reference video traffic source models for		This document describes two reference video traffic source models for
	evaluating RMCAT candidate algorithms. The first model statistically		evaluating RMCAT candidate algorithms. The first model statistically
	characterizes the behavior of a live video encoder in response to		characterizes the behavior of a live video encoder in response to
	changing requests on target video rate. The second model is trace-		changing requests on target video rate. The second model is trace-
	driven, and emulates the encoder output by scaling the pre-encoded		driven, and emulates the encoder output by scaling the pre-encoded
	video frame sizes from a widely used video test sequence. Both		video frame sizes from a widely used video test sequence. Both
	models are designed to strike a balance between simplicity,		models are designed to strike a balance between simplicity,
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 40 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		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 Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 29 ¶		skipping to change at page 2, line 29 ¶
	5.1. Time-damped response to target rate update . . . . . . . 7		5.1. Time-damped response to target rate update . . . . . . . 7
	5.2. Temporary burst/oscillation during transient . . . . . . 7		5.2. Temporary burst/oscillation during transient . . . . . . 7
	5.3. Output rate fluctuation at steady state . . . . . . . . . 8		5.3. Output rate fluctuation at steady state . . . . . . . . . 8
	5.4. Rate range limit imposed by video content . . . . . . . . 8		5.4. Rate range limit imposed by video content . . . . . . . . 8
	6. A Trace-Driven Model . . . . . . . . . . . . . . . . . . . . 8		6. A Trace-Driven Model . . . . . . . . . . . . . . . . . . . . 8
	6.1. Choosing the video sequence and generating the traces . . 9		6.1. Choosing the video sequence and generating the traces . . 9
	6.2. Using the traces in the syntethic codec . . . . . . . . . 10		6.2. Using the traces in the syntethic codec . . . . . . . . . 10
	6.2.1. Main algorithm . . . . . . . . . . . . . . . . . . . 10		6.2.1. Main algorithm . . . . . . . . . . . . . . . . . . . 10
	6.2.2. Notes to the main algorithm . . . . . . . . . . . . . 12		6.2.2. Notes to the main algorithm . . . . . . . . . . . . . 12
	6.3. Varying frame rate and resolution . . . . . . . . . . . . 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		8. Implementation Status . . . . . . . . . . . . . . . . . . . . 14
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
	10.1. Normative References . . . . . . . . . . . . . . . . . . 14		10.1. Normative References . . . . . . . . . . . . . . . . . . 15
	10.2. Informative References . . . . . . . . . . . . . . . . . 14		10.2. Informative References . . . . . . . . . . . . . . . . . 15
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
	1. Introduction		1. Introduction
	When evaluating candidate congestion control algorithms designed for		When evaluating candidate congestion control algorithms designed for
	real-time interactive media, it is important to account for the		real-time interactive media, it is important to account for the
	characteristics of traffic patterns generated from a live video		characteristics of traffic patterns generated from a live video
	encoder. Unlike synthetic traffic sources that can conform perfectly		encoder. Unlike synthetic traffic sources that can conform perfectly
	to the rate changing requests from the congestion control module, a		to the rate changing requests from the congestion control module, a
	live video encoder can be sluggish in reacting to such changes.		live video encoder can be sluggish in reacting to such changes.
	Output rate of a live video encoder also typically deviates from the		Output rate of a live video encoder also typically deviates from the
	target rate due to uncertainties in the encoder rate control process.		target rate due to uncertainties in the encoder rate control process.
	Consequently, end-to-end delay and loss performance of a real-time		Consequently, end-to-end delay and loss performance of a real-time
	media flow can be further impacted by rate variations introduced by		media flow can be further impacted by rate variations introduced by
	the live encoder.		the live encoder.
	On the other hand, evaluation results of a candidate RMCAT algorithm		On the other hand, evaluation results of a candidate RMCAT algorithm
	should mostly reflect performance of the congestion control module,		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		It is also desirable that evaluation tests are repeatable, and be
	easily duplicated across different candidate algorithms.		easily duplicated across different candidate algorithms.
	One way to strike a balance between the above considerations is to		One way to strike a balance between the above considerations is to
	evaluate RMCAT algorithms using a synthetic video traffic source		evaluate RMCAT algorithms using a synthetic video traffic source
	model that captures key characteristics of the behavior of a live		model that captures key characteristics of the behavior of a live
	video encoder. To this end, this draft presents two reference		video encoder. To this end, this draft presents two reference
	models. The first is based on statistical modelling; the second is		models. The first is based on statistical modelling; the second is
	trace-driven. The draft also discusses the pros and cons of each		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		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described RFC2119 [RFC2119].		document are to be interpreted as described RFC2119 [RFC2119].
	3. Desired Behavior of A Synthetic Video Traffic Model		3. Desired Behavior of A Synthetic Video Traffic Model
	A live video encoder employs encoder rate control to meet a target		A live video encoder employs encoder rate control to meet a target
	skipping to change at page 4, line 9 ¶		skipping to change at page 4, line 9 ¶
	o To change bitrate. This includes ability to change framerate and/		o To change bitrate. This includes ability to change framerate and/
	or spatial resolution, or to skip frames when required.		or spatial resolution, or to skip frames when required.
	o To fluctuate around the target bitrate specified by the congestion		o To fluctuate around the target bitrate specified by the congestion
	control module.		control module.
	o To delay in convergence to the target bitrate.		o To delay in convergence to the target bitrate.
	o To generate intra-coded or repair frames on demand.		o To generate intra-coded or repair frames on demand.
	While there exists many different approaches in developing a		While there exist many different approaches in developing a synthetic
	synthetic video traffic model, it is desirable that the outcome		video traffic model, it is desirable that the outcome follows a few
	follows a few common characteristics, as outlined below.		common characteristics, as outlined below.
	o Low computational complexity: The model should be computationally		o Low computational complexity: The model should be computationally
	lightweight, otherwise it defeats the whole purpose of serving as		lightweight, otherwise it defeats the whole purpose of serving as
	a substitute for a live video encoder.		a substitute for a live video encoder.
	o Temporal pattern similarity: The individual traffic trace		o Temporal pattern similarity: The individual traffic trace
	instances generated by the model should mimic the temporal pattern		instances generated by the model should mimic the temporal pattern
	of those from a real video encoder.		of those from a real video encoder.
	o Statistical resemblance: The synthetic traffic should match the		o Statistical resemblance: The synthetic traffic should match the
	skipping to change at page 5, line 7 ¶		skipping to change at page 5, line 7 ¶
	The synthetic video encoder takes in raw video frames captured by the		The synthetic video encoder takes in raw video frames captured by the
	camera and then dynamically generates a sequence of encoded video		camera and then dynamically generates a sequence of encoded video
	frames with varying size and interval. These encoded frames are		frames with varying size and interval. These encoded frames are
	processed by other modules in order to transmit the video stream over		processed by other modules in order to transmit the video stream over
	the network. During the lifetime of a video transmission session,		the network. During the lifetime of a video transmission session,
	the synthetic video encoder will typically be required to adapt its		the synthetic video encoder will typically be required to adapt its
	encoding bitrate, and sometimes the spatial resolution and frame		encoding bitrate, and sometimes the spatial resolution and frame
	rate.		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		incoming and outgoing interface calls that allow for interaction with
	other modules. The following are some of the possible incoming		other modules. The following are some of the possible incoming
	interface calls --- marked as (a) in Figure 1 --- that the synthetic		interface calls --- marked as (a) in Figure 1 --- that the synthetic
	video encoder may accept. The list is not exhaustive and can be		video encoder may accept. The list is not exhaustive and can be
	complemented by other interface calls if deemed necessary.		complemented by other interface calls if deemed necessary.
	o Target rate R_v(t): requested at time t, typically from the		o Target rate R_v(t): requested at time t, typically from the
	congestion control module. Depending on the congestion control		congestion control module. Depending on the congestion control
	algorithm in use, the update requests can either be periodic		algorithm in use, the update requests can either be periodic
	(e.g., once per second), or on-demand (e.g., only when a drastic		(e.g., once per second), or on-demand (e.g., only when a drastic
	skipping to change at page 6, line 28 ¶		skipping to change at page 6, line 28 ¶
	-------------------+ +-------------------->		-------------------+ +-------------------->
	interface from interface to		interface from interface to
	other modules (a) other modules (b)		other modules (a) other modules (b)
	Figure 1: Interaction between synthetic video encoder and other		Figure 1: Interaction between synthetic video encoder and other
	modules at the sender		modules at the sender
	5. A Statistical Reference Model		5. A Statistical Reference Model
	In this section, we describe one simple statistical model of the live		In this section, we describe one simple statistical model of the live
	video encoder traffic source. Figure 2 summarizes the list of tuable		video encoder traffic source. Figure 2 summarizes the list of
	parameters in this statistical model. A more comprehensive survey of		tunable parameters in this statistical model. A more comprehensive
	popular methods for modelling video traffic source behavior can be		survey of popular methods for modelling video traffic source behavior
	found in [Tanwir2013].		can be found in [Tanwir2013].
	+---------------+--------------------------------+----------------+		+---------------+--------------------------------+----------------+
	| Notation | Parameter Name | Example Value |		| Notation | Parameter Name | Example Value |
	+--------------+---------------------------------+----------------+		+--------------+---------------------------------+----------------+
	| R_v(t) | Target rate request at time t | 1 Mbps |		| R_v(t) | Target rate request at time t | 1 Mbps |
	| R_o(t) | Output rate at time t | 1.2 Mbps |		| R_o(t) | Output rate at time t | 1.2 Mbps |
	| tau_v | Encoder reaction latency | 0.2 s |		| tau_v | Encoder reaction latency | 0.2 s |
	| K_d | Burst duration during transient | 5 frames |		| K_d | Burst duration during transient | 5 frames |
	| K_r | Burst size during transient | 5:1 |		| K_r | Burst size during transient | 5:1 |
	| R_e(t) | Error in output rate at time t | 0.2 Mbps |		| R_e(t) | Error in output rate at time t | 0.2 Mbps |
	skipping to change at page 8, line 8 ¶		skipping to change at page 8, line 8 ¶
	occasional burst of large frames are followed by smaller-than average		occasional burst of large frames are followed by smaller-than average
	encoded frames.		encoded frames.
	This temporary burst is characterized by two parameters:		This temporary burst is characterized by two parameters:
	o burst duration K_d: number frames in the burst event; and		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		o burst size K_r: ratio of a burst frame and average frame size at
	steady state.		steady state.
	It can be noted that these burst parameters can also be used to mimic		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		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.		typical ratio between I and P frames for a given video content.
	5.3. Output rate fluctuation at steady state		5.3. Output rate fluctuation at steady state
	We model output rate R_o as randomly fluctuating around the target		We model output rate R_o as randomly fluctuating around the target
	rate R_v after convergence. There are two variants in modeling the		rate R_v after convergence. There are two variants in modeling the
	random fluctuation R_e = R_o - R_v:		random fluctuation R_e = R_o - R_v:
	o As normal distribution: with a mean of zero and a standard		o As normal distribution: with a mean of zero and a standard
	skipping to change at page 9, line 36 ¶		skipping to change at page 9, line 36 ¶
	6.1. Choosing the video sequence and generating the traces		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		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		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		model. Our use case here is video conferencing, so we must choose a
	low-motion sequence that resembles a "talking head", for instance a		low-motion sequence that resembles a "talking head", for instance a
	news broadcast or a video capture of an actual conference call.		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		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		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,		the traces. If it is too short, there will be an obvious periodic
	there will be an obvious periodic pattern in the output frame sizes,		pattern in the output frame sizes, leading to biased results when
	leading to biased results when evaluating congestion controller		evaluating congestion controller performance. In our experience, a
	performance. In our experience, a one-minute-long sequence is a fair		one-minute-long sequence is a fair tradeoff.
	tradeoff.
	Once we have chosen the raw video sequence, denoted S, we use a live		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		encoder, e.g. [H264] or [HEVC] to produce a set of encoded
	sequences. As discussed in Section 3, a live encoder's output		sequences. As discussed in Section 3, a live encoder's output
	bitrate can be tuned by varying three input parameters, namely,		bitrate can be tuned by varying three input parameters, namely,
	quantization step size, frame rate, and picture resolution. In order		quantization step size, frame rate, and picture resolution. In order
	to simplify the choice of these parameters for a given target rate,		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		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		(e.g., 480p). See section 6.3 for a discussion on how to relax these
	assumptions.		assumptions.
	skipping to change at page 10, line 39 ¶		skipping to change at page 10, line 36 ¶
	The choice of a value for n_s is important, as it determines the		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		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		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		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		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.		will further discuss step length l in the next section.
	6.2. Using the traces in the syntethic codec		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		mimics a real live codec's rate adaptation when the congestion
	controller updates the target rate R_v(t). It does so by switching		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		to a different frame size vector stored in the map Traces when
	needed.		needed.
	6.2.1. Main algorithm		6.2.1. Main algorithm
	We maintain two variables r_current and t_current:		We maintain two variables r_current and t_current:
	* r_current points to one of the keys of the map Traces. Upon a		* r_current points to one of the keys of the map Traces. Upon a
	skipping to change at page 12, line 20 ¶		skipping to change at page 12, line 17 ¶
	factor = R_v(t) / R_max		factor = R_v(t) / R_max
	framesize = factor * Traces[R_max][t_current]		framesize = factor * Traces[R_max][t_current]
	In case b), we set the minimum to 1 byte, since the value of factor		In case b), we set the minimum to 1 byte, since the value of factor
	can be arbitrarily close to 0.		can be arbitrarily close to 0.
	6.2.2. Notes to the main algorithm		6.2.2. Notes to the main algorithm
	* Reacting to changes in target bitrate. Similarly to the		* 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		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,		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		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		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.		the time between frames, i.e. the inverse of the frame rate.
	* I-frames on demand. The synthetic codec could be extended to		* 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		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		losses. To implement this extension, the codec's API is augmented
	with a new function to request a new I-frame. Upon calling such		with a new function to request a new I-frame. Upon calling such
	skipping to change at page 12, line 45 ¶		skipping to change at page 12, line 42 ¶
	if the range [R_min, R_max] is very wide, it is also possible to		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		define a set of steps with a non-constant length. The idea behind
	this modification is that the difference between 400 kbps and 600		this modification is that the difference between 400 kbps and 600
	kbps as bitrate is much more important than the difference between		kbps as bitrate is much more important than the difference between
	4400 kbps and 4600 kbps. For example, one could define steps of		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		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.		2 Mbps, 400 kbps between 2 Mbps and 3 Mbps, and so on.
	6.3. Varying frame rate and resolution		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		relatively simple because we have fixed the frame rate and the frame
	resolution. The model could be extended to have variable frame rate,		resolution. The model could be extended to have variable frame rate,
	variable spatial resolution, or both.		variable spatial resolution, or both.
	When the encoded picture quality at a given bitrate is low, one can		When the encoded picture quality at a given bitrate is low, one can
	potentially decrease the frame rate (if the video sequence is		potentially decrease the frame rate (if the video sequence is
	currently in low motion) or the spatial resolution in order to		currently in low motion) or the spatial resolution in order to
	improve quality-of-experince (QoE) in the overall encoded video. On		improve quality-of-experince (QoE) in the overall encoded video. On
	the other hand, if target bitrate increases to a point where there is		the other hand, if target bitrate increases to a point where there is
	no longer a perceptible improvement in the picture quality of		no longer a perceptible improvement in the picture quality of
	individual frames, then one might afford to increase the spatial		individual frames, then one might afford to increase the spatial
	resolution or the frame rate (useful if the video is currently in		resolution or the frame rate (useful if the video is currently in
	high motion).		high motion).
	Many techniques have been proposed to choose over time the best		Many techniques have been proposed to choose over time the best
	combination of encoder quatization step size, frame rate, and spatial		combination of encoder quatization step size, frame rate, and spatial
	resolution in order to maximize the quality of live video codecs		resolution in order to maximize the quality of live video codecs
	[Ozer2011][Hu2010]. Future work may consider extending the trace-		[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		From the perspective of congestion control, varying the spatial
	resolution typically requires a new intra-coded frame to be		resolution typically requires a new intra-coded frame to be
	generated, thereby incurring a temporary burst in the output traffic		generated, thereby incurring a temporary burst in the output traffic
	pattern. The impact of frame rate change tends to be more subtle:		pattern. The impact of frame rate change tends to be more subtle:
	reducing frame rate from high to low leads to sparsely spaced larger		reducing frame rate from high to low leads to sparsely spaced larger
	encoded packets instead of many densely spaced smaller packets. Such		encoded packets instead of many densely spaced smaller packets. Such
	difference in traffic profiles may still affect the performance of		difference in traffic profiles may still affect the performance of
	congestion control, especially when outgoing packets are not paced at		congestion control, especially when outgoing packets are not paced at
	the transport module. We leave the investigation of varying frame		the transport module. We leave the investigation of varying frame
	rate to future work.		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		It is worthwhile noting that the statistical and trace-driven models
	each has its own advantages and drawbacks. Both models are fairly		each has its own advantages and drawbacks. While both models are
	simple to implement. However, it takes significantly more effort to		fairly simple to implement, it takes significantly greater effort to
	fit the parameters of a statistical model to actual encoder output		fit the parameters of a statistical model to actual encoder output
	data whereas a trace-based model does not require such fitting. On		data whereas it is straightforward for a trace-driven model to obtain
	the other hand, once validated, the statistical model is more		encoded frame size data. On the other hand, once validated, the
	flexible in mimicking a wide range of encoder/content behavior by		statistical model is more flexible in mimicking a wide range of
	simply varying the correponding parameters in the model. In		encoder/content behaviors by simply varying the correponding
	contrast, a trace-driven model relies, by definition, on additional		parameters in the model. In this regard, a trace-driven model relies
	data collection efforts for accommodating new codecs or video		-- by definition -- on additional data collection efforts for
	contents.		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		ongoing, steady-state behavior of a video traffic source whereas
	statistical model is more versatile for simulating transient events		statistical model is more versatile for simulating transient events
	(e.g., when target rate changes from A to B with temporary bursts		(e.g., when target rate changes from A to B with temporary bursts
	during the transition). Therefore, it may be desirable to combine		during the transition). It is also possible to combine both models
	both approaches into a hybrid model, using traces for steady-state		into a hybrid approach, using traces during steady-state and
	and statistical model for transients.		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		8. Implementation Status
	The statistical model has been implemented as a traffic generator		The statistical model has been implemented as a traffic generator
	module within the [ns-2] network simulation platform.		module within the [ns-2] network simulation platform.
	More recently, both the statistical and trace-driven models have been		More recently, both the statistical and trace-driven models have been
	implemented as a stand-alone traffic source module. This can be		implemented as a stand-alone traffic source module. This can be
	easily integrated into network simulation platforms such as [ns-2]		easily integrated into network simulation platforms such as [ns-2]
	and [ns-3], as well as testbeds using a real network. The stand-		and [ns-3], as well as testbeds using a real network. The stand-
End of changes. 22 change blocks.
	43 lines changed or deleted		70 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/