Internet DRAFT - draft-ko-ippm-streaming-performance
draft-ko-ippm-streaming-performance
Network Working Group K. Ko
Internet-Draft ADTRAN
Intended status: Informational February 18, 2013
Expires: August 18, 2013
Model-Based Estimation of Streaming Performance
draft-ko-ippm-streaming-performance-00.txt
Abstract
This memo defines metrics plus a methodology for post-measurement
processing of sample metrics to evaluate network path performance
relative to streaming video traffic. The metrics are based on
established methodologies for TCP throughput testing. The post-
processing methodology is based on a model of streaming traffic that
allows a given sample metric to be evaluated against multiple sets
of parameters representing different streaming rates, delays and
buffering values. The results of the post-processing methodology are
derived metrics that are suitable for statistical analysis.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on August 18, 2013.
Ko Expires August 18, 2013 [Page 1]
Internet-Draft Model-Based Streaming Performance February 2013
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction...................................................3
2. Conventions used in this document..............................4
3. Transmission and Buffering of Streaming Data...................4
4. Methodology....................................................5
5. Streaming model................................................6
5.1. Model parameters..........................................6
5.2. Model behavior............................................7
6. Metrics........................................................9
6.1. A Singleton Definition for Short Term TCP Throughput......9
6.1.1. Metric Name..........................................9
6.1.2. Metric Parameters....................................9
6.1.3. Metric Units.........................................9
6.1.4. Definition..........................................10
6.1.5. Discussion..........................................10
6.2. A Definition of Sample for Short Term TCP Throughput.....11
6.2.1. Metric Name.........................................11
6.2.2. Metric Parameters...................................11
6.2.3. Metric Units........................................11
6.2.4. Definition..........................................12
6.2.5. Discussion..........................................12
6.3. A Definition of Sample for Dejitter Buffer Fill..........12
6.3.1. Metric Name.........................................13
6.3.2. Metric Parameters...................................13
6.3.3. Metric Units........................................13
6.3.4. Definition..........................................14
6.3.5. Discussion..........................................14
6.3.6. Methodologies.......................................15
6.4. Some Statistics Definitions for Dejitter-Buffer-Fill.....15
6.4.1. Initial-Streaming-Delay.............................15
6.4.2. Percentage-Viewing-Time.............................16
Ko Expires August 18, 2013 [Page 2]
Internet-Draft Model-Based Streaming Performance February 2013
6.4.3. Minimum-Buffer-Depth................................17
7. Additional topics.............................................17
8. Security Considerations.......................................17
9. IANA Considerations...........................................17
10. References...................................................17
10.1. Normative References....................................17
10.2. Informative References..................................18
11. Acknowledgments..............................................18
1. Introduction
As the rates at which residential users access the Internet have
increased over time, the types of traffic accessed by those users
have evolved. Dialup access at rates of up to 56 kbps supported
little more than email and non-real time traffic such as static web
pages. The introduction of DSL and cable modems helped drive the
trend towards more complex web pages with higher information
content, as well as the emergence of real-time traffic such as VoIP
and near-real time traffic such as streaming audio and video at low
speeds. With the introduction of Fiber To The Premises (FTTP) as
well as increasingly high DSL, cable and mobile wireless access
rates, streaming video has become the largest category of consumer
traffic on the Internet. According to one source [Cis2012], 49% of
all consumer Internet traffic in 2011 was streaming video in some
form and the percentage is continuing to increase.
The applications that display streaming video can be sensitive to
variations in throughput and delay in the network. If the dejitter
buffer in the destination host doesn't receive a steady enough
stream of packets at the required rate it may underflow, causing a
noticeable freeze in the video being played out. While application
providers can mitigate the frequency and severity of these freezes,
doing so typically involves trading off both the perceived quality
of the video and the delay before it starts against the possibility
of performance issues in mid-playout.
Recent large scale performance trials have included dedicated tests
to measure video streaming performance [FCC2012]. These tests are
designed to measure streaming at a defined performance point, with a
new dedicated test required for each new performance point. This
document proposes a different approach in which metrics resulting
from TCP throughput performance testing are used to evaluate the
network path's ability to support streaming at multiple performance
points.
This document defines metrics plus a methodology for post-
measurement processing of sample metrics to determine network path
Ko Expires August 18, 2013 [Page 3]
Internet-Draft Model-Based Streaming Performance February 2013
performance relative to the requirements for streaming video
traffic. The metrics are based on established methodologies for TCP
throughput testing [RFC6349]. The post-processing methodology is
based on a model of streaming traffic that allows a given sample
metric to be evaluated against multiple sets of parameters
representing different streaming rates, delays and buffering values.
The results of the post-processing methodology are derived metrics
that are suitable for statistical analysis.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119].
In this document, these words will appear with that interpretation
only when in ALL CAPS. Lower case uses of these words are not to be
interpreted as carrying RFC-2119 significance.
Whenever a technical term from the IPPM Framework document [RFC2330]
is first used in this memo, it will be tagged with a trailing
asterisk. For example, "term*" indicates that "term" is defined in
the Framework.
3. Transmission and Buffering of Streaming Data
Streaming video is a near-real time application, the performance of
which is dependent upon many factors including: the throughput and
delay characteristics of the network; the rate, susceptibility to
lost packets and other characteristics of the encoded content; and
the protocols and application parameters used to deliver and display
the content. In a typical implementation, packets are sent from a
content serving host to a destination host where they are stored in
a dejitter buffer. The buffered packets are read from the buffer,
decoded, and displayed by a video display application as needed in
real time. The dejitter buffer stores the packets from the time of
arrival at the destination host until they are needed by the display
application. This dejitter buffer compensates for variability in the
delivery of packets across the network and also allows the content
serving host to send packets on a schedule that can differ from the
timing required by the display application. For example, content
serving hosts commonly schedule transmission of streaming video
packets in bursts separated by idle time such that the average rate
of transmission approximates the rate required for display, but the
momentary rate at a given point in time is either much higher than
the display rate or it is zero.
Ko Expires August 18, 2013 [Page 4]
Internet-Draft Model-Based Streaming Performance February 2013
The amount of data present in the dejitter buffer at a given point
in time is a function of the difference between the packet arrival
activity and the packet read activity. The display application
typically waits until the dejitter buffer has stored some minimum
amount of received data before starting to read it, to allow the
momentary read rate to exceed the arrival rate without exhausting
the buffer contents. As long as there are unread packets available
in the dejitter buffer, the display application can read, decode and
display the video content without interruption. However, if packet
reads empty the buffer without the corresponding arrival of new
packets, the resulting underflow will interrupt the display of
video. When this happens, video freezes until the buffer has once
again received and stored a minimum amount of data.
Nearly all video streaming traffic is carried over TCP. TCP is a
connection oriented protocol which responds to packet loss by
reducing its congestion window. As a result, the momentary
throughput for the protocol varies, which can lead to the buffer
exhaustion and video interruptions described above. In the
methodology described below, the variation in throughput is measured
directly during the course of TCP throughput testing and the
measured results are applied to a model of streaming video behavior
to estimate the ability of the measured network path to support
streaming video at a given combination of parameters. The same
measured results can be tested against multiple sets of streaming
parameters, generating a picture of how well the measured
performance would support streaming video at different rates and
with different amounts of delay.
4. Methodology
This methodology is intended for operational IP networks. The
metrics measured in the first step rely on the framework for TCP
throughput testing defined in RFC6349.
The methodology is described in the following sequence of steps:
1. Using the methodology in RFC6349, perform TCP throughput testing
on the network path under test. During the throughput testing,
collect the sample metric Short-term-TCP-throughput-constant-
stream defined in Section 6.2. This metric may be collected on
its own in a TCP throughput test dedicated to streaming video
performance, or it may be collected in addition to the metrics
defined in RFC6349 as part of a larger series of performance
tests.
Ko Expires August 18, 2013 [Page 5]
Internet-Draft Model-Based Streaming Performance February 2013
2. Define the model parameter values described in Section 5.1. for
the streaming model of Section 5.
3. Apply the streaming model to the sample metric Short-term-TCP-
throughput-constant-stream using the model behavior defined in
Section 5.2.
4. Step 3 may be performed as many times as desired defining
different sets of model parameter values in step 2. Each
iteration of the process generates results indicating how well
the network path performance at the time of the throughput test
would support streaming content under a different set of
conditions.
5. Streaming model
In this section we define a generalized model for the reception,
storage and subsequent reading of a media stream. The streaming
model generates a sequence of values representing the amount of data
stored in the dejitter buffer at discrete times during the simulated
reception and display of streaming media content. The input to the
model is the sample metric Short-term-TCP-throughput-constant-stream
defined in Section 6.2. The output of the model is the derived
sample metric Dejitter-Buffer-Fill defined in Section 6.3.
5.1. Model parameters
The following parameters are used in the streaming model:
o The average encoded media rate Ravg, in bits per second. This is
the average rate at which data is read from the dejitter buffer
by the streaming media application for decoding and display when
the model is in state FILL_PLAY or MAINTAIN. It is also the
maximum rate at which data is written to the buffer in state
MAINTAIN.
o The initial streaming rate Rinit, in bits per second where Rinit
> Ravg. This is the maximum rate at which data is written to the
dejitter buffer when the model is in state FILL_NOPLAY or
FILL_PLAY. Rinit may be set to an arbitrarily high value to allow
the buffer to be filled as quickly as can be supported by the
network.
Ko Expires August 18, 2013 [Page 6]
Internet-Draft Model-Based Streaming Performance February 2013
o The buffer depth Binit, in bytes, at which the streaming display
application starts to read content out of the dejitter buffer for
encoding and display. The combination of Rinit and Binit
determines the minimum time delay between the beginning of
streaming over the network and the beginning of content decoding
and display at the destination.
o The target buffer depth Btarget, in bytes where Btarget >= Binit.
As long as the fill level of the dejitter buffer remains at or
above this depth, the average streaming rate is reduced to the
encoded rate Ravg and the buffer depth remains constant until the
end of the simulation. If the buffer depth drops below this value
due to a reduction in TCP throughput, the streaming rate can
increase as high as Rinit until the buffer depth once again
reaches Btarget.
o The time interval I, in seconds. This is the interval I used to
generate the value of the sample metric Short-term-TCP-
throughput-constant-stream used as an input to the simulation.
5.2. Model behavior
The streaming model is stateful. When the model is used to simulate
streaming performance using a value of sample Short-term-TCP-
throughput-constant-stream, it iteratively updates a number of
variables which are then used to update the model's state:
o The fill rate F at which data is written to the buffer. The units
for F are bytes per time interval I. When the model is in state
FILL_NOPLAY or FILL_PLAY, the value of F for an interval k is
calculated from the minimum of Rinit (normalized to bytes per
interval I) or the short-term TCP throughput for the interval
R(k). When the model is in state MAINTAIN, the value of F for an
interval k is calculated from the minimum of Ravg (normalized to
bytes per interval I) or R(k). Note that F may have a non-integer
value.
o The playout rate P at which data is read from the buffer. The
units for P are bytes per time interval I. When the model is in
state FILL_NOPLAY, the value of P is zero. When the model is in
state FILL_PLAY or MAINTAIN, the value of P is calculated from
the average encoded rate Ravg. Note that P may have a non-integer
value.
Ko Expires August 18, 2013 [Page 7]
Internet-Draft Model-Based Streaming Performance February 2013
o The buffer depth B, in bytes. The value of B in each time
interval is iteratively calculated from the value of B from the
previous interval and the fill and playout rates for the current
interval. Note that since F and P may have non-integer values, B
may also have a non-integer value.
The following pseudocode specifies the model algorithm:
// Initialize the parameters for time T(0)
B(0) = 0 // Initial buffer state
T(0) = T(1) - I // T(0) = T0
Finit = Rinit / 8 * I // Initial fill rate
Fmaint = Ravg / 8 * I // Maintenance fill rate
P = Ravg / 8 * I // Playout rate
Model_state = FILL_NOPLAY // Initial state
// Run the simulation for each time interval T(k)
For k = 1 to k_max
Switch(Model_state)
// Buffer filling, no playout
Case FILL_NOPLAY:
B(k) = B(k-1) + min(Finit, R(k))
If B(k) >= Btarget then
Model_state = MAINTAIN
Else If B(k) >= Binit then
Model_state = FILL_PLAY
End if
// Buffer filling, media playing out
Case FILL_PLAY:
B(k) = B(k-1) + min(Finit, R(k)) - P
If B(k) >= Btarget then
Model_state = MAINTAIN
Else If B(k) <= 0 then
B(k) = 0
Model_state = FILL_NOPLAY
End if
// Buffer at target, media playing out
Case MAINTAIN:
B(k) = B(k-1) + min(Fmaint, R(k)) - P
If B(k) <= 0 then
B(k) = 0
Model_state = FILL_NOPLAY
Else If B(k) < Btarget then
Model_state = FILL_PLAY
End if
Ko Expires August 18, 2013 [Page 8]
Internet-Draft Model-Based Streaming Performance February 2013
End switch
Next k
6. Metrics
The structure of this section is as follows:
o A 'singleton' analytic metric, called Short-term-TCP-throughput,
will be introduced to measure a single observation of short-term
TCP throughput.
o Using this singleton metric, a 'sample', called Short-term-TCP-
throughput-constant-stream, will be introduced to measure a
sequence of singleton short-term TCP throughputs measured at
regular intervals.
o Using this sample and the streaming model defined in Section 5. ,
a derived sample metric called Dejitter-Buffer-Fill will be
defined and discussed.
o Using this derived sample metric, several 'statistics' will be
defined and discussed.
This progression from singleton to sample to derived sample to
statistics, with clear separation among them, is important.
6.1. A Singleton Definition for Short Term TCP Throughput
6.1.1. Metric Name
Short-term-TCP-throughput
6.1.2. Metric Parameters
o Src, the IP address of a host
o Dst, the IP address of a host
o T, a time
o I, a time interval
6.1.3. Metric Units
The value of Short-term-TCP-throughput is an integer number.
Ko Expires August 18, 2013 [Page 9]
Internet-Draft Model-Based Streaming Performance February 2013
6.1.4. Definition
>>The *Short-term-TCP-throughput* from Src to Dst at time T over the
interval I is R<< means that the number of new bytes sent over TCP
from Src which are acknowledged by Dst during the time interval I
preceding wire-time* T is R.
6.1.5. Discussion
Short-term-TCP-throughput is measured using the framework for TCP
testing described in RFC6349. Like the metrics in that document,
this metric should be measured in the TCP Equilibrium state [see
RFC6349 Section 1.3].
Short-term-TCP-throughput can be measured at either the Src or Dst
host. If measured at Dst, the first step in generating the metric is
to record the highest Acknowledgement Numbers generated by Dst for
the TCP connection being measured at the beginning and end of the
time interval I preceding time T.
o Assign A(k) = the highest Acknowledgement Number generated by Dst
at time T
o Assign A(k-1) = the highest Acknowledgement Number generated by
Dst at time (T - I)
If the metric is measured at Src, then
o Assign A(k) = the highest Acknowledgement Number received by Src
at time T
o Assign A(k-1) = the highest Acknowledgement Number received by
Src at time (T - I)
Short-term-TCP-throughput is then calculated in bytes per interval I
as
R = A(k) - A(k-1)
Calculation of the difference A(k) - A(k-1) must account for the TCP
window scaling option and for the potential rollover of the
Acknowledgement Number from (2^32 - 1) to 0 between the beginning
and the end of a measurement interval.
The streaming video applications described in Section 3. typically
allow at least several seconds worth of content to be buffered
before beginning to stream data, and then continue to send and store
Ko Expires August 18, 2013 [Page 10]
Internet-Draft Model-Based Streaming Performance February 2013
data faster than it is being read for display until a target level
of buffer fill is reached that may support several tens of seconds
worth of content. To effectively apply the streaming model from
Section 5. with an acceptable level of accuracy, we require short
term throughput values at intervals on the order of two orders of
magnitude smaller than the buffering intervals described above. A
measurement interval I on the order of 100 milliseconds is
suggested.
TCP throughput testing using the methodology described in RFC6349
can make use of multiple TCP connections operating concurrently
between the same Src and Dst. If this is the case, the process
described above should be used to calculate the short term
throughput at time T for each TCP connection separately, and then
the values should be summed to generate Short-term-TCP-throughput.
6.2. A Definition of Sample for Short Term TCP Throughput
Given the singleton metric Short-term-TCP-throughput, we now define
one particular sample of such singletons. The idea of the sample is
to select a particular binding of the parameters Src, Dst, and I,
and then define a sample of values of parameter T. The means for
defining the values of T is to select a beginning time T0, a final
time Tf, and an interval I, then define a series of regularly spaced
time values T whose values fall between T0 and Tf. The time interval
between successive values of T will have the constant value I.
6.2.1. Metric Name
Short-term-TCP-throughput-constant-stream
6.2.2. Metric Parameters
o Src, the IP address of a host
o Dst, the IP address of a host
o T0, a time
o Tf, a time
o I, a time interval
6.2.3. Metric Units
A sequence of pairs; the elements of each pair are:
Ko Expires August 18, 2013 [Page 11]
Internet-Draft Model-Based Streaming Performance February 2013
o T, a time, and
o R, an integer number
The values of T in the sequence are monotonic and increasing at
constant intervals I. Note that T and I would be valid parameters to
Short-term-TCP-throughput, and that R would be a valid value of
Short-term-TCP-throughput. Note also that since T can be determined
from T0, I and the position of the value in the sequence, it is
possible to alternatively define the metric units as: a time T0, a
time interval I; and a sequence of integer numbers R.
6.2.4. Definition
Given T0, Tf, and I, we compute a series of time values T(k) where
T(k) = T0 + (k) * I, for 1 <= k <= (Tf - T0) / I.
The first time value in the sequence occurs at T(1) = T0 + I, and
successive time values are regularly spaced with the constant
interval I between successive values of T. The last time value in
the sequence occurs in the interval Tf - I < T(kmax) <= Tf. At each
of the times in this sequence, we obtain the value of Short-term-
TCP-throughput at this time using interval I. The value of the
sample is made up of the resulting <time, rate> pairs. If there are
no such pairs, the sequence is of length zero and the sample is said
to be empty.
6.2.5. Discussion
The <time, rate> pairs that make up the value of Short-term-TCP-
throughput-constant-stream provide a continuous view of the
momentary throughput in the network path from Src to Dst from time
T0 to time Tf. By defining a single value of I as a common input
parameter to both Short-term-TCP-throughput and Short-term-TCP-
throughput-constant-stream, the 'final' highest Acknowledgement
Number A(k) used to calculate the kth singleton value in the
sequence becomes the 'initial' highest value A(j-1) used to
calculate the next successive (jth, where j = k+1) value in the
sequence. In this way, each new segment acknowledged from time T0
until the end of the final interval preceding time Tf contributes to
exactly one of the singleton values in the sample.
6.3. A Definition of Sample for Dejitter Buffer Fill
Given the sample metric Short-term-TCP-throughput-constant-stream,
we now define one additional sample derived from such sample. The
Ko Expires August 18, 2013 [Page 12]
Internet-Draft Model-Based Streaming Performance February 2013
idea of the derived sample is to select a particular binding of the
model parameters Ravg, Rinit, Binit, Btarget and I defined in
Section 5.1. , and then to apply the streaming model defined in
Section 5. to the value of the sample Short-term-TCP-throughput-
constant-stream. The buffer fill depths per time interval generated
by the streaming model then form the value for the derived sample
metric.
6.3.1. Metric Name
Dejitter-Buffer-Fill
6.3.2. Metric Parameters
o Rseq, a value of type Short-term-TCP-throughput-constant-stream
The following model parameters are defined in Section 5.1. :
o Rinit, a real number
o Ravg, a real number
o Binit, a real number
o Btarget, a real number
o I, a time interval
6.3.3. Metric Units
A sequence of pairs; the elements of each pair are:
o T, a time, and
o B, a real number
The values of T in the sequence are monotonic and increasing at
constant intervals I. Note that if the input parameter Rseq is
defined using parameters T0 and I and a sequence of integer numbers
R, Dejitter-Buffer-Fill may likewise be defined as: a time T0; a
time interval I; and a set of real numbers B. Note also that the
number of pairs in a value of Dejitter-Buffer-Fill will be one more
than the number of pairs in the input parameter Rseq.
Ko Expires August 18, 2013 [Page 13]
Internet-Draft Model-Based Streaming Performance February 2013
6.3.4. Definition
Given Rseq and the model parameters from Section 5.1. , we compute a
series of buffer fill values B(k) at regular time intervals T(k)
using the model algorithm defined in Section 5.2. The value of the
sample is made up of the resulting <T(k), B(k)> pairs.
The first time value in the sequence occurs at T(0) = T0, and
successive time values are regularly spaced with the constant
interval I between successive values of T. The last time value in
the sequence occurs in the interval Tf - I < T(kmax) <= Tf. The
number of pairs in a value of the sample metric is one greater than
the number of pairs in the input sample Rseq. If Rseq is an empty
sample, then the value of Dejitter-Buffer-Fill is defined to be of
length zero and the sample is said to be empty.
6.3.5. Discussion
The <T(k), B(k)> pairs that make up the value of Dejitter-Buffer-
Fill approximate the variation in fill depth over time of a dejitter
buffer for a streaming media application. As new data arrives from
the network, it is written to the buffer and the fill depth
increases. As data is read from the buffer to be decoded and
displayed, the fill depth decreases. In any given time interval, any
combination of write and read operations may occur, and both writes
and reads may occur multiple times.
When a streaming session is initiated, data is sent from source to
destination at a high rate (Rinit) to fill the buffer as quickly as
possible. For the same reason, read operations are disabled during
this initiation period. Once the buffer has reached an initial fill
level (Binit), read operations are enabled and the streaming media
application begins to read, decode and display the streamed content.
The data may continue streaming at a high rate until the buffer
reaches a target fill level (Btarget).
Once the buffer has reached its target fill level, the rate at which
data is streamed is reduced to a value equal to the rate at which
data is being read from the dejitter buffer. So long as the short-
term throughput in the network supports this streaming rate, the
dejitter buffer is in equilibrium, with the rates at which data is
being written and read at the same average value. If the short-term
throughput falls below the streaming rate, the buffer fill depth
will fall below the target value. Once this occurs, the maximum
streaming rate is increased to Rinit until the buffer fill depth
reaches Btarget once more.
Ko Expires August 18, 2013 [Page 14]
Internet-Draft Model-Based Streaming Performance February 2013
(Note that the increase in the maximum streaming rate does not imply
either the presence or the absence of an explicit feedback mechanism
between the buffer fill depth and the source of the streaming
traffic. In some cases there may be such a mechanism, for example by
varying the value of the advertised window in TCP. In other cases,
allowing the rate at which data is written to the buffer to increase
beyond Ravg is simply an acknowledgement that the remote source has
continued to stream the data at the average rate but it has not all
been successfully received, hence there is extra data in the network
pipeline that may be received at higher than the average rate until
the shortfall is made up.)
If the short-term throughput falls and remains below the streaming
rate for some time, the buffer fill depth may drop to zero. At this
point the buffer is exhausted, an underflow condition occurs, and
read operations are disabled until the buffer once again reaches the
initial fill level. Of course if this occurs, it signals an error
condition in which the decoding and display of the streaming media
is interrupted.
6.3.6. Methodologies
A single value Rseq of Short-term-TCP-throughput-constant-stream can
be used with different model parameters to generate many values of
Dejitter-Buffer-Fill. Each resulting value of Dejitter-Buffer-Fill
represents the response of the jitter buffer to streaming content
with different characteristics and/or displayed with different
parameters over the same network conditions as recorded in Rseq.
6.4. Some Statistics Definitions for Dejitter-Buffer-Fill
Given the sample metric Dejitter-Buffer-Fill, we now offer several
statistics of that sample. These statistics are offered mostly to be
illustrative of what could be done.
6.4.1. Initial-Streaming-Delay
Given a Dejitter-Buffer-Fill and the model parameters used to derive
it, the time between the time of the first pair T0 and the first
time at which the buffer fill depth B(k) is equal to or greater than
Binit. This is the delay between the initiation of streaming and the
time at which the streaming media application first starts to decode
and display the streamed content.
Ko Expires August 18, 2013 [Page 15]
Internet-Draft Model-Based Streaming Performance February 2013
6.4.2. Percentage-Viewing-Time
Given a Dejitter-Buffer-Fill and the model parameters used to derive
it, the total time during which data is being read from the dejitter
buffer divided by the total time after the initial transition from
state FILL_NOPLAY to another state. This represents the percentage
of time spent viewing media content once the display starts, as
opposed to observing an interruption in the content and waiting for
it to resume. The metric can be calculated from Dejitter-Buffer-Fill
using the algorithm specified by the following pseudo code:
// Initialization
Total_time = 0 // Total time after start of playout
View_time = 0 // Viewing time after start of playout
Model_state = INITIAL_FILL // Initial state
// Run iteratively for each time interval T(k)
For k = 1 to k_max
Switch(Model_state)
// initial buffer fill not counted toward total
Case INITIAL_FILL:
If B(k) >= Binit then
Model_state = PLAYING
End if
// Buffer filling, no playout
Case FILL_NOPLAY:
Total_time = Total_Time + I
If B(k) >= Binit then
Model_state = PLAYING
End if
// media playing out
Case PLAYING:
Total_time = Total_Time + I
View_time = View_Time + I
If B(k) = 0 then
Model_state = FILL_NOPLAY
End if
End switch
Next k
If Total_time > 0
Percentage-Viewing-Time = View_time / Total_time
Else
Percentage-Viewing-Time = 0
End if
Ko Expires August 18, 2013 [Page 16]
Internet-Draft Model-Based Streaming Performance February 2013
6.4.3. Minimum-Buffer-Depth
Given a Dejitter-Buffer-Fill and the model parameters used to derive
it, the minimum dejitter buffer depth at any point in time after
Btarget is initially reached. A minimum value close to zero
indicates that the buffer was close to exhaustion at some point in
the simulation.
7. Additional topics
The following topics are candidates for inclusion but have not yet
been addressed in this Internet-Draft.
o Discussion of the different ways in which streams are scheduled
and why the streaming model approximates this scheduling
behavior.
o Discussion of the differences between model behavior and network
streaming behavior. Limitations of the model.
o Discussion of short-term streaming rates that vary around the
average.
o Extension to adaptive streaming. At least, discussion of how the
model can be extended to adaptive streaming.
o Addition of explanatory figures.
8. Security Considerations
The security considerations that apply to any active measurement of
live networks are relevant here as well. See [RFC4656] and
[RFC5357].
9. IANA Considerations
This memo makes no requests of IANA
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Ko Expires August 18, 2013 [Page 17]
Internet-Draft Model-Based Streaming Performance February 2013
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
"Framework for IP Performance Metrics", RFC 2330, May
1998.
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
Zekauskas, "A One-way Active Measurement Protocol
(OWAMP)", RFC 4656, September 2006.
[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J.
Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",
RFC 5357, October 2008.
[RFC6349] Constantine, B., Forget, G., Geib, R., and Schrage, R.,
"Framework for TCP Throughput Testing," RFC 6349, August
2011.
10.2. Informative References
[Cis2012] Cisco, "Cisco Visual Networking Index: Forecast and
Methodology, 2011-2016," May 30, 2012.
[FCC2012] FCC, "Measuring Broadband America: Technical Appendix,"
July 2012.
11. Acknowledgments
The authors wish to thank the following people for reading and
commenting on this draft <TBD>.
This document was prepared using 2-Word-v2.0.template.dot.
Authors' Addresses
Ken Ko
ADTRAN
901 Explorer Blvd.
Huntsville, AL 35806
USA
Email: ken.ko@adtran.com
Ko Expires August 18, 2013 [Page 18]
