Network Working Group J. Welch Request for Comments: 4445 IneoQuest Technologies Category: Informational J. Clark Cisco Systems April 2006 A Proposed Media Delivery Index (MDI) Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2006). IESG Note This RFC is not a candidate for any level of Internet Standard. There are IETF standards which are highly applicable to the space defined by this document as its applicability, in particular, RFCs 3393 and 3611, and there is ongoing IETF work in these areas as well. The IETF also notes that the decision to publish this RFC is not based on IETF review for such things as security, congestion control, MIB fitness, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this document should exercise caution in evaluating its value for implementation and deployment. See RFC 3932 for more information.
AbstractThis memo defines a Media Delivery Index (MDI) measurement that can be used as a diagnostic tool or a quality indicator for monitoring a network intended to deliver applications such as streaming media, MPEG video, Voice over IP, or other information sensitive to arrival time and packet loss. It provides an indication of traffic jitter, a measure of deviation from nominal flow rates, and a data loss at-a-glance measure for a particular flow. For instance, the MDI may be used as a reference in characterizing and comparing networks carrying UDP streaming media. The MDI measurement defined in this memo is intended for Information only.
i1], [i5], [i6], [i7]. QoS is required for many practical networks involving applications such as video transport to assure the availability of network bandwidth by providing upper limits on the number of flows admitted to a network, as well as to bound the packet jitter introduced by the network. These bounds are required to dimension a receiver`s buffer to display the video properly in real time without buffer overflow or underflow. Now that large-scale implementations of such networks based on RSVP and Diffserv are undergoing trials [i3] and being specified by major service providers for the transport of streaming media such as MPEG video [i4], there is a need to diagnose issues easily and to monitor the real-time effectiveness of networks employing these QoS methods or to assess whether they are required. Furthermore, due to the significant installed base of legacy networks without QoS methods, a delivery system`s transitional solution may be composed of networks with and without these methods, thus increasing the difficulty in characterizing the dynamic behavior of these networks. The purpose of this memo is to describe a set of measurements that can be used to derive a Media Delivery Index (MDI) that indicates the instantaneous and longer-term behavior of networks carrying streaming media such as MPEG video. While this memo addresses monitoring MPEG Transport Stream (TS) packets [i8] over UDP, the general approach is expected to be applicable to other streaming media and protocols. The approach is applicable to both constant and variable bit rate streams though the variable bit rate case may be somewhat more difficult to calculate. This document focuses on the constant bit rate case as the example to describe the measurement, but as long as the dynamic bit rate of the encoded stream can be determined (the "drain rate" as described below in Section 3), then the MDI provides the measurement of network- induced cumulative jitter. Suggestions and direction for calculation of MDI for a variable bit rate encoded stream may be the subject of a future document. Network packet delivery time variation and various statistics to characterize the same are described in a generic approach in [i10]. The approach is capable of being parameterized for various purposes with the intent of defining a flexible, customizable definition that can be applied to a wide range of applications and further
experimentation. Other approaches to characterizing jitter behavior are also captured such as in [i12]. A wide-ranging report format [i11] has been described to convey information including jitter for use with the RTP Control Protocol (RTCP) [i12]. The MDI is instead intended to specifically address the need for a scalable, economical-to-compute metric that characterizes network impairments that may be imposed on streaming media, independent of control plane or measurement transport protocol or stream encapsulation protocol. It is a targeted metric for use in production networks carrying large numbers of streams for the purpose of monitoring the network quality of the flows or for other applications intended to analyze large numbers of streams susceptible to IP network device impairments. An example application is the burgeoning deployments of Internet Protocol Television (IPTV) by cable and telecommunication service providers. As described below, MDI provides for a readily scalable per-stream measure focused on loss and the cumulative effects of jitter.
gaps (jitter). Greater DF values also indicate that more network latency is necessary to deliver a stream due to the need to pre-fill a receive buffer before beginning the drain to guarantee no underflow. The DF comprises a fixed part based on packet size and a variable part based on the buffer utilization of the various network component switch elements that comprise the switched network infrastructure [i2]. To further detail the calculation of DF, consider a virtual buffer VB used to buffer received packets of a stream. When a packet P(i) arrives during a calculation interval, compute two VB values, VB(i,pre) and VB(i,post), defined as: VB(i,pre) = sum (Sj) - MR * Ti; where j=1..i-1 VB(i,post) = VB(i,pre) + Si where Sj is the media payload size of the jth packet, Ti is the relative time at which packet i arrives in the interval, and MR is the nominal media rate. VB(i,pre) is the Virtual Buffer size just before the arrival of P(i). VB(i,post) is the Virtual Buffer size just after the arrival of P(i). The initial condition of VB(0) = 0 is used at the beginning of each measurement interval. A measurement interval is defined from just after the time of arrival of the last packet during a nominal period (typically 1 second) as mentioned above to the time just after the arrival of the last packet of the next nominal period. During a measurement interval, if k packets are received, then there are 2*k+1 VB values used in deriving VB(max) and VB(min). After determining VB(max) and VB(min) from the 2k+1 VB samples, DF for the measurement interval is computed and displayed as: DF = [VB(max) - VB(min)]/ MR As noted above, a measurement interval of 1 second is typically used. If no packets are received during an interval, the last DF calculated during an interval in which packets did arrive is displayed. The time of arrival of the last previous packet is always retained for use in calculating VB when the next packet arrives (even if the time of the last received packet spans measurement intervals). For the first received measurement interval of a measurement period, no DF is calculated; however, packet arrival times are recorded for use in calculating VB during the following interval.
i9] parameters, DF indicates bucket size b, expressed in time to transmit bucket traffic b, at the given nominal traffic rate, r.
For a given MDI, if DF is high and/or the DF Max-Min captured over a significant measurement period of multiple intervals is high, jitter has been detected but the longer-term, average flow rate may be nominal. This could be the result of a transient flow upset due to a coincident traffic stream unrelated to the flow of interest causing packet bunching. A high DF may cause downstream buffer overflow or underflow or unacceptable latency even in the absence of lost data. Due to transient network failures or DF excursions, packets may be lost within the network. The MLR component of the MDI shows this condition. Through automated or manual flow detection and identification and subsequent MDI calculations for real-time statistics on a flow, the DF can indicate the dynamic deterioration or increasing burstiness of a flow, which can be used to anticipate a developing network operation problem such as transient oversubscription. Such statistics can be obtained for flows within network switches using available switch cpu resources due to the minimal computational requirements needed for small numbers of flows. Statistics for all flows present on, say, a gigabit Ethernet network, will likely require dedicated hardware facilities, though these can be modest, as buffer requirements and the required calculations per flow are minimal. By equipping network switches with MDI measurements, flow impairment issues can quickly be identified, localized, and corrected. Until switches are so equipped with appropriate hardware resources, dedicated hardware tools can provide supplemental switch statistics by gaining access to switch flows via mirror ports, link taps, or the like as a transition strategy. The MDI figure can also be used to characterize a flow decoder's acceptable performance. For example, an MPEG decoder could be characterized as tolerating a flow with a given maximum DF and MLR for acceptable display performance (acceptable on-screen artifacts). Network conditions such as Interior Gateway Protocol (IGP) reconvergence time then might also be included in the flow tolerance DF resulting in a higher-quality user experience.
[i1] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [i2] Partridge, C., "A Proposed Flow Specification", RFC 1363, September 1992. [i3] R. Fellman, `Hurdles to Overcome for Broadcast Quality Video Delivery over IP` VidTranS 2002. [i4] CableLabs `PacketCable Dynamic Quality-of-Service Specification`, PKT-SP-DQOS-I06-030415, 2003. [i5] Shenker, S., Partridge, C., and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997. [i6] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997. [i7] Braden, R., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994. [i8] ISO/IEC 13818-1 (MPEG-2 Systems) [i9] V. Raisanen, "Implementing Service Quality in IP Networks", John Wiley & Sons Ltd., 2003. [i10] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, November 2002.
Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at email@example.com. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).