summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4445.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4445.txt')
-rw-r--r--doc/rfc/rfc4445.txt563
1 files changed, 563 insertions, 0 deletions
diff --git a/doc/rfc/rfc4445.txt b/doc/rfc/rfc4445.txt
new file mode 100644
index 0000000..b272dc8
--- /dev/null
+++ b/doc/rfc/rfc4445.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+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.
+
+Abstract
+
+ This 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.
+
+
+
+
+Welch & Clark Informational [Page 1]
+
+RFC 4445 A Proposed Media Delivery Index (MDI) April 2006
+
+
+1. Introduction
+
+ There has been considerable progress over the last several years in
+ the development of methods to provide for Quality of Service (QoS)
+ over packet-switched networks to improve the delivery of streaming
+ media and other time-sensitive and packet-loss-sensitive applications
+ such as [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
+
+
+
+Welch & Clark Informational [Page 2]
+
+RFC 4445 A Proposed Media Delivery Index (MDI) April 2006
+
+
+ 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.
+
+2. Media Delivery Index Overview
+
+ The MDI provides a relative indicator of needed buffer depths at the
+ consumer node due to packet jitter as well as an indication of lost
+ packets. By probing a streaming media service network at various
+ nodes and under varying load conditions, it is possible to quickly
+ identify devices or locales that 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 impairments for streaming
+ video or voice-over-IP applications. 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 that 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. The Maximums and Minimums may be obtained by sampling
+ the measurement with adequate frequency.
+
+
+
+
+
+
+
+
+
+Welch & Clark Informational [Page 3]
+
+RFC 4445 A Proposed Media Delivery Index (MDI) April 2006
+
+
+3. Media Delivery Index Components
+
+ The MDI consists of two components: the Delay Factor (DF) and the
+ Media Loss Rate (MLR).
+
+3.1. Delay Factor
+
+ The Delay Factor is the maximum difference, observed at the end of
+ each media stream packet, between the arrival of media data and the
+ drain of media data. This assumes the drain rate is the nominal
+ constant traffic rate for constant bit rate streams or the piece-wise
+ computed traffic rate of variable rate media stream packet data. The
+ "drain rate" here refers to the payload media rate; e.g., for a
+ typical 3.75 Mb/s MPEG video Transport Stream (TS), the drain rate is
+ 3.75 Mb/s -- the rate at which the payload is consumed (displayed) at
+ a decoding node. 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 over
+ a calculation interval. This buffered media data in bytes is
+ expressed in terms of how long, in milliseconds, it would take to
+ drain (or fill) this data at the nominal traffic rate to obtain the
+ DF. Display of DF with a resolution of tenths of milliseconds is
+ recommended to provide adequate indication of stream variations for
+ monitoring and diagnostic applications for typical stream rates from
+ 1 to 40 Mb/s. The DF value must be updated and displayed at the end
+ of a selected time interval. The selected time interval is chosen to
+ be long enough to sample a number of TS packets and will, therefore,
+ vary based on the nominal traffic rate. For typical stream rates of
+ 1 Mb/s and up, an interval of 1 second provides a long enough sample
+ time and should be included for all implementations. The Delay
+ Factor indicates how long a data stream must be buffered (i.e.,
+ delayed) at its nominal bit rate to prevent packet loss. This time
+ may also be seen as a measure of the network latency that must be
+ induced from buffering, which is required to accommodate stream
+ jitter and prevent loss. The DF`s max and min over the measurement
+ period (multiple intervals) may also be displayed to show the worst
+ case arrival time deviation, or jitter, relative to the nominal
+ 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.
+
+ The Delay Factor gives a hint of the minimum size of the buffer
+ required at the next downstream node. As a stream progresses, the
+ variation of the Delay Factor indicates packet bunching or packet
+
+
+
+Welch & Clark Informational [Page 4]
+
+RFC 4445 A Proposed Media Delivery Index (MDI) April 2006
+
+
+ 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.
+
+
+
+
+
+
+Welch & Clark Informational [Page 5]
+
+RFC 4445 A Proposed Media Delivery Index (MDI) April 2006
+
+
+3.2. Media Loss Rate
+
+ The Media Loss Rate is the count of lost or out-of-order flow packets
+ over a selected time interval, where the flow packets are packets
+ carrying streaming application information. There may be zero or
+ more streaming packets in a single IP packet. For example, it is
+ common to carry seven 188 Byte MPEG Transport Stream packets in an IP
+ packet. In such a case, a single IP packet loss would result in 7
+ lost packets counted (if those 7 lost packets did not include null
+ packets). Including out-of-order packets is important, as many
+ stream consumer-type devices do not attempt to reorder packets that
+ are received out of order.
+
+3.3. Media Delivery Index
+
+ Combining the Delay Factor and Media Loss Rate quantities for
+ presentation results in the following MDI:
+
+ DF:MLR
+ Where:
+ DF is the Delay Factor
+ MLR is the Media Loss Rate
+
+ At a receiving node, knowing its nominal drain bit rate, the DF`s max
+ indicates the size of buffer required 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 given
+ nominal traffic rate, r.
+
+3.4. MDI Application Examples
+
+ If 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 flows. 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.
+
+
+
+
+
+
+
+
+
+
+Welch & Clark Informational [Page 6]
+
+RFC 4445 A Proposed Media Delivery Index (MDI) April 2006
+
+
+ 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.
+
+4. 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
+ network, traffic congestion or device impairments may be detected and
+ isolated for a network carrying streaming media content.
+
+
+
+
+
+Welch & Clark Informational [Page 7]
+
+RFC 4445 A Proposed Media Delivery Index (MDI) April 2006
+
+
+5. 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 that may affect the available bandwidth of the
+ network or the availability of a service is out of scope for this
+ document.
+
+ Performing the measurements described in this document only requires
+ examination of payload header information (such as MPEG transport
+ stream headers or RTP headers) to determine nominal stream bit rate
+ and sequence number information. Content may be encrypted without
+ affecting these measurements. Therefore, content privacy is not
+ expected to be a concern.
+
+6. Informative References
+
+ [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.
+
+
+
+
+Welch & Clark Informational [Page 8]
+
+RFC 4445 A Proposed Media Delivery Index (MDI) April 2006
+
+
+ [i11] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol
+ Extended Reports (RTCP XR)", RFC 3611, November 2003.
+
+ [i12] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
+ "RTP: A Transport Protocol for Real-Time Applications", STD 64,
+ RFC 3550, July 2003.
+
+7. Acknowledgements
+
+ 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 versions of this document and implementations for MDI.
+
+Authors' Addresses
+
+ James Welch
+ IneoQuest Technologies, Inc
+ 170 Forbes Blvd
+ Mansfield, Massachusetts 02048
+
+ Phone: 508 618 0312
+ EMail: Jim.Welch@ineoquest.com
+
+
+ James Clark
+ Cisco Systems, Inc
+ 500 Northridge Road
+ Suite 800
+ Atlanta, Georgia 30350
+
+ Phone: 678 352 2726
+ EMail: jiclark@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+Welch & Clark Informational [Page 9]
+
+RFC 4445 A Proposed Media Delivery Index (MDI) April 2006
+
+
+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
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Welch & Clark Informational [Page 10]
+