From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4445.txt | 563 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 563 insertions(+) create mode 100644 doc/rfc/rfc4445.txt (limited to 'doc/rfc/rfc4445.txt') 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] + -- cgit v1.2.3