Network Working Group J. Welch Internet Draft IneoQuest Technologies Intended Category: Informational J. Clark Cisco Systems August, 2004 A Proposed Media Delivery Index draft-welch-mdi-00.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR Claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 a "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/lid-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited. 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. Welch, Clark Expires February 2005 [Page 1] A Proposed Media Delivery Index August 2004 By submitting this Internet-Draft, I accept the provisions of Section 3 of RFC 3667. Abstract This memo defines a Media Delivery Index (MDI) measurement which can be used as a diagnostic tool or a quality indicator for monitoring a network intended to transport streaming media such as MPEG video or other arrival time and packet loss sensitive information. It provides an indication of traffic jitter, a measure of deviation from nominal flow rates, and data loss at-a-glance. For instance, the MDI may be used as a reference in characterizing and comparing networks carrying constant bit rate streaming media. Included is a set of managed objects for SNMP-based management of IP media streams for which an MDI measurement is obtained. The Media Delivery Index measurement and MIB defined in this memo is intended for Information only. 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 [n14]. Introduction There has been considerable progress over the last several years in the development of methods to provide for QOS over packet switched networks to improve the delivery of streaming media and other time and packet loss sensitive applications such as [i1], [i5], [i6], [i7]. QOS is required for 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 properly display the video 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 easily diagnose issues and monitor the real time effectiveness of networks employing these QOS methods. Furthermore, due to the significant installed base of legacy networks without QOS methods, a delivery system`s transitional solution may be comprised of both networks with and without these methods thus increasing the difficulty in characterizing the dynamic behavior of Welch, Clark Expires February 2005 [Page 2] A Proposed Media Delivery Index August 2004 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) which indicates the instantaneous and longer term behavior of networks carrying streaming media such as MPEG data. 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. Media Delivery Index Overview The MDI provides a relative indicator of needed buffer depths at the consumer node due to packet jitter and network latency as well as an indication of lost packets. By probing a streaming media network at various nodes and under varying load conditions, it is possible to quickly identify devices or locales which introduce significant jitter or packet loss to the packet stream. By monitoring a network continuously, deviations from nominal jitter or loss behavior can be used to indicate an impending or ongoing fault condition such as excessive load. It is believed that the MDI provides the necessary information to detect all network induced MPEG video display impairments. Other parameters may be required to troubleshoot and correct the impairments. The MDI is updated at the termination of selected time intervals spanning multiple packets which contain the streaming media (such as transport stream packets in the MPEG-2 case.) The Maximums and Minimums of the MDI component values are captured over a measurement time. The measurement time may range from just long enough to capture an anticipated network anomaly during a troubleshooting exercise to indefinitely long for a long term monitoring or logging application. Media Delivery Index Components - Delay Factor (DF): The maximum difference, observed at the end of each media stream packet, between the arrival of media data and the drain of media data, assuming the drain rate is the nominal constant traffic rate of media stream packet data. If, at the sample time, the number of bytes received equals the number transmitted, the instantaneous flow rate balance will be zero, however the minimum DF will be a line packet's worth of media data as that is the minimum amount of data that must be buffered. The DF is the maximum observed value of the flow rate imbalance. This buffered media data in bytes is expressed in terms of how long it would take to drain (or fill) this data at the nominal constant traffic rate in milliseconds to obtain the DF. The DF value MUST be updated and displayed at the end Welch, Clark Expires February 2005 [Page 3] A Proposed Media Delivery Index August 2004 of a selected time interval. The selected time interval is chosen to be long enough to include a number of TS packets and will, therefore, vary based on the nominal constant traffic rate. The Delay Factor indicates how long a data stream must be buffered (i.e. delayed) at its nominal constant bit rate to prevent packet loss. Thus, it is also proportional to latency. The DF`s max and min over the measurement period MAY also be displayed to show the worst case arrival time deviation, or jitter, relative to the nominal constant traffic rate in a measurement period. It provides a dynamic flow rate balance indication with its max and min showing the worst excursions from balance. To arrive at a bounded DF, the long term flow rate deviation (LFRD) must be 0, where LFRD is a running deviation of flow rate from expected nominal constant traffic rate over a measurement period. A large positive or negative LFRD usually indicates a media stream source failure or misconfiguration and would cause the DF value to steadily increase from interval to interval. The Delay Factor gives a hint of the size of the buffer required at the next downstream node. As a stream progresses, the variation of the Delay Factor indicates packet bunching (jitter). Greater DF values also indicate more network latency to deliver a stream due to the need to prefill a receive buffer before beginning the drain to guarantee no underflow. The DF is comprised of a fixed part based on packet size and a variable part based on the various network component switch elements` buffer utilization that comprise the switched network infrastructure [i2]. - Media Loss Rate: Lost or out of order Media packets counted over a selected time interval, where Media packets are packets carrying media information. There may be 0 or more media packets in a single layer 2 network packet such as Ethernet. For example, it is common to carry seven 188 Byte MPEG Transport Stream packets in a 1362 Byte Ethernet frame. In such a case, a single Ethernet frame loss would result in 7 lost Media packets counted for the case where the 7 lost Media packets did not include null packets. Combining these quantities for presentation results in the MDI: DF:MLR Where: DF is the Delay Factor MLR is the Media Loss Rate At a receiving node, knowing its nominal constant drain bit rate, the DF`s max indicates the size of required buffer to accommodate packet jitter. Or, in terms of Leaky Bucket [i9] parameters, DF indicates bucket size b expressed in time to transmit bucket traffic b, at the Welch, Clark Expires February 2005 [Page 4] A Proposed Media Delivery Index August 2004 given nominal constant traffic rate, r. In the case where a known, well characterized receive node is separated from the data source by unknown or less well characterized nodes such as intermediate switch nodes, the MDI measured at intermediate data links provides a relative indication of the behavior of upstream traffic flow. DF difference indications between one node and another in a data stream for a given constant interval of calculation can indicate local areas of traffic congestion or possibly misconfigured QOS flow specification(s) leading to greater filling of measurement point local device buffers, resultant flow rate deviations, and possible data loss. For a given MDI, if DF is high and/or the DF Max-Min captured over a significant measurement period 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. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [i10]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [n11], STD 58, RFC 2579 [n12] and STD 58, RFC 2580 [n13]. MIB Overview This MIB provides a set of objects required for the export of MDI metrics of IP streaming media streams. MIB Definitions -- -- Media Stream Monitor MIB -- Welch, Clark Expires February 2005 [Page 5] A Proposed Media Delivery Index August 2004 MEDIA-MONITOR-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Integer32, Unsigned32, mib-2, NOTIFICATION-TYPE, OBJECT-IDENTITY, IpAddress FROM SNMPv2-SMI -- RFC2578 DisplayString FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF; -- RFC2580 mediaMonitorMIB MODULE-IDENTITY LAST-UPDATED "200404040000Z" -- 04 April 2004 ORGANIZATION " xx " CONTACT-INFO "IneoQuest Technologies, Inc. Postal: 170 Forbes Boulevard Mansfield, MA, 02048 Tel: +1 508 618 0312 E-mail: jim.welch@ineoquest.com" DESCRIPTION "The media Monitor MIB (MEDIA-MONITOR-MIB) provides Metrics for Monitoring IP streaming Media Flows." -- Revision history REVISION "200404040000Z" -- 04 April 2004 DESCRIPTION "Initial version, published as RFC xxxx. (this RFC)" ::= { xxxx } -- Top level structure of the MIB mediaMonitorObjects OBJECT IDENTIFIER ::= { mediaMonitorMIB 1 } ipMediaStreamMonitorTable OBJECT-TYPE SYNTAX SEQUENCE OF IpMediaStreamMonitorEntry MAX-ACCESS not-accessible STATUS current Welch, Clark Expires February 2005 [Page 6] A Proposed Media Delivery Index August 2004 DESCRIPTION "IP Stream Monitor Table. This table is indexed by the Stream Handle. This Table only shows the currently ACTIVE video Streams." ::= { mediaMonitorObjects 1 } ipMediaStreamMonitorEntry OBJECT-TYPE SYNTAX IpMediaStreamMonitorEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "IP Stream Monitor Table Entry." INDEX { ipMediaStreamMonitorHandle } ::= { ipMediaStreamMonitorTable 1 } IpMediaStreamMonitorEntry ::= SEQUENCE { ipMediaStreamHandle Unsigned32, ipMediaStreamSourceIpAddress IpAddress, ipMediaStreamSourcePort Unsigned32, ipMediaStreamDestinationIpAddress IpAddress, ipMediaStreamDestinationPort Unsigned32, ipMediaStreamBitRate Unsigned32, ipMediaStreamInterval Unsigned32, ipMediaStreamStartTime DisplayString, ipMediaStreamMDIDelayFactor Unsigned32, ipMediaStreamMDILossRate Unsigned32, ipMediaStreamMDIDFThreshold Unsigned32, ipMediaStreamMDILRThreshold Unsigned32, ipMediaStreamMDIDFErrorIntervals Unsigned32 ipMediaStreamMonitorMDIMLRErrorIntervals Unsigned32 } ipMediaStreamHandle OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only Welch, Clark Expires February 2005 [Page 7] A Proposed Media Delivery Index August 2004 STATUS current DESCRIPTION "Table is indexed by stream Handle. The table has one row for each Media Stream detected from the Ip Interface. The Stream Handle shall be a unique value for the life of the stream." ::= { ipMediaStreamMonitorEntry 1 } ipMediaStreamSourceIpAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "Source IpAddress for the Stream indexed by the Stream Handle." ::= { ipMediaStreamMonitorEntry 2 } ipMediaStreamSourcePort OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The Source port for the Stream indexed by the Stream Handle." ::= { ipMediaStreamMonitorEntry 3 } ipMediaStreamDestinationIpAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "Destination IpAddress for the Stream indexed by the Stream Handle." ::= { ipMediaStreamMonitorEntry 4 } ipMediaStreamDestinationPort OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The Destination port for the Stream indexed by the Stream Handle." ::= { ipMediaStreamMonitorEntry 5 } ipMediaStreamBitRate OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION Welch, Clark Expires February 2005 [Page 8] A Proposed Media Delivery Index August 2004 "The nominal Bit Rate of the Media Stream in bits/second." ::= { ipMediaStreamMonitorEntry 6 } ipMediaStreamInterval OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number indicates the minimum Interval in seconds for a good MDI Measurement. The Interval is based on the current Bit Rate of the Stream. The minimum interval should be chosen such that at least 10 IP packets occur per interval. This value defaults to 1 second and the Interval is typically configured to 1 second unless the above criteria is not met." ::= { ipMediaStreamMonitorEntry 7 } ipMediaStreamStartTime OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-only STATUS current DESCRIPTION "The Timestamp shows the Real time at which the stream was detected. The Timestamp format is YYYY/MM/DD/HH/MM/SS." ::= { ipMediaStreamMonitorEntry 8 } ipMediaStreamMDIDelayFactor OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object displays the Media Delivery Index Delay Factor parameter in units of milliseconds. This parameter indicates the burstiness of the stream." ::= { ipMediaStreamMonitorEntry 9 } ipMediaStreamMDILossRate OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object displays the Media Delivery Index Media Loss Rate in packets/sec. This parameter indicates rate of lost media packets of the of the stream." ::= { ipMediaStreamMonitorEntry 10 } ipMediaStreamMDIDFThreshold OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write Welch, Clark Expires February 2005 [Page 9] A Proposed Media Delivery Index August 2004 STATUS current DESCRIPTION "The Threshold for Media Delivery Index Delay Factor in milliSeconds. The default value is set to 0 indicating that it is invalid until configured." ::= { ipMediaStreamMonitorEntry 11 } ipMediaStreamMDILRThreshold OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "The Threshold for Media Delivery Loss Rate in Packets/second. The default value is set to 0xffffffff indicating that it is invalid until configured." ::= { ipMediaStreamMonitorEntry 12 } ipMediaStreamMDIDFErrorIntervals OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number indicates the number of MDI DF Threshold (ipMediaStreamMonitorMDIDFThreshold) Crossed Intervals during the life of a stream. This shall be 0 and invalid until the MDI DF Thresholds are configured." ::= { ipMediaStreamMonitorEntry 13 } ipMediaStreamMDIMLRErrorIntervals OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number indicates the number of MDI MLR Threshold (ipMediaStreamMDILRThreshold)Crossed Intervals during the life of a stream. This shall be 0 and invalid until the MDI MLR Thresholds are configured." ::= { ipMediaStreamMonitorEntry 14 } END Summary The MDI combines the Delay Factor which indicates potential for impending data loss and Media Loss Rate as the indicator of lost data. By monitoring the DF and MLR and their min and max excursions over a measurement period and at multiple strategic locations in a Welch, Clark Expires February 2005 [Page 10] A Proposed Media Delivery Index August 2004 network, traffic congestion or device impairments may be detected and isolated for a network carrying streaming media content. The included MIB provides a set of objects required for the export of MDI metrics of IP streaming media streams. Security Considerations The measurements identified in this document do not directly affect the security of a network or user. Actions taken in response to these measurements which may affect the available bandwidth of the network or availability of a service is out of scope for this document. Normative References n1. K. McCloghrie, D. Perkins, J. Schoenwaelder, J. Case, J. Rose, M. and S. Waldbusser, 'Structure of Management Information Version 2 (SMIv2)', STD 58, RFC 2578, April 1999. n2. K. McCloghrie, D. Perkins, J. Schoenwaelder, J. Case, J. Rose, M. and S. Waldbusser, 'Textual Conventions for SMIv2', STD 58, RFC 2579, April 1999. n3. K. McCloghrie, D. Perkins, J. Schoenwaelder, J. Case, J. Rose, M. and S. Waldbusser, 'Conformance Statements for SMIv2', STD 58, RFC 2580, April 1999. n4. S. Bradner, 'Key words for use in RFCs to Indicate Requirement Levels', BCP 14, RFC 2119, March 1997. Informative References i1. R. Braden et al., `Resource Reservation Protocol ` Version 1 Functional Specification`, RFC 2205, 1997. i2. C. Partridge, `A Proposed Flow Specification`, RFC 1363, 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. S. Shenker, C. Partridge, R. Guerin, `Specification of Guaranteed Quality of Service`, RFC 2212, 1997. i6. J. Wroclawski, `Specification of the Controlled-Load Network Element Service`, RFC 2211, 1997. i7. R. Braden, D. Clark, S. Shenker, `Integrated Services in the Internet Architecture: an Overview` RFC 1633, 1994. i8. ISO/IEC 13818-1 (MPEG-2 Systems) i9. V. Raisanen, `Implementing Service Quality in IP Networks`, John Wiley & Sons Ltd., 2003. Welch, Clark Expires February 2005 [Page 11] A Proposed Media Delivery Index August 2004 i10. J. Case, R. Mundy, D. Partain, B. Stewart, 'Introduction and Applicability Statements for Internet Standard Management Framework', RFC 3410, 2002. Acknowledgments The authors gratefully acknowledge the contributions of Marc Todd and Jesse Beeson of IneoQuest Technologies, Inc., Bill Trubey and John Carlucci of Time Warner Cable, Nishith Sinha of Cox Communications, Ken Chiquoine of SeaChange International, Phil Proulx of Bell Canada, Dr Paul Stallard of TANDBERG Television, Gary Hughes of Broadbus Technologies, Brad Medford of SBC Laboratories, John Roy of Adelphia Communications, Cliff Mercer, PhD of Kasenna, Mathew Ho of Rogers Cable, and Irl Duling of Optinel Systems for reviewing and evaluating early drafts of this document and implementations for MDI. Authors' Address James Welch IneoQuest Technologies, Inc 170 Forbes Blvd Mansfield, Massachusetts 02048 508 618 0312 Jim.Welch@ineoquest.com James Clark Cisco Systems, Inc 500 Northridge Road Suite 800 Atlanta, Georgia 30350 678 352 2726 jiclark@cisco.com Copyright Notice Copyright (C) The Internet Society 2004. This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Disclaimer 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.' Welch, Clark Expires February 2005 [Page 12] A Proposed Media Delivery Index August 2004 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 ISOC's procedures with respect to rights in ISOC 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 ietf- ipr@ietf.org. Welch, Clark Expires February 2005 [Page 13]