Model-Based Estimation of Streaming Performance
Author(s): Ken Ko
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...
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 [RFC 2119]. 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 [RFC 2119] 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", RFC2330, May 1998. [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zekauskas, "A One-way Active Measurement Protocol (OWAMP)", RFC4656, September 2006. [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", RFC5357, October 2008. [RFC6349] Constantine, B., Forget, G., Geib, R., and Schrage, R., "Framework for TCP Throughput Testing," RFC6349, 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: firstname.lastname@example.org Ko Expires August 18, 2013 [Page 18]