idnits 2.17.1 draft-welch-mdi-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 46. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 391. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 397. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 7) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == In addition to RFC 3979, Section 5, paragraph 1 boilerplate, a section with a similar start was also found: 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. == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 2005) is 6827 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 A Proposed Media Delivery Index August 2005 3 Network Working Group J. Welch 4 Internet Draft IneoQuest Technologies 5 Intended Category: Informational J. Clark 6 Cisco Systems 7 August, 2005 9 A Proposed Media Delivery Index 10 draft-welch-mdi-03.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than a "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/lid-abstracts.html 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 This memo provides information for the Internet community. It does 36 not specify an Internet standard. Distribution of this memo is 37 unlimited. 39 The IETF takes no position regarding the validity or scope of any 40 Intellectual Property Rights or other rights that might be claimed to 41 pertain to the implementation or use of the technology described in 42 this document or the extent to which any license under such rights 43 might or might not be available; nor does it represent that it has 44 made any independent effort to identify any such rights. Information 45 on the procedures with respect to rights in RFC documents can be 46 found in BCP 78 and BCP 79. 48 Abstract 50 This memo defines a Media Delivery Index (MDI) measurement which can 51 be used as a diagnostic tool or a quality indicator for monitoring a 52 network intended to deliver applications such as streaming media MPEG 53 video and Voice over IP or other arrival time and packet loss 54 sensitive information. It provides an indication of traffic jitter, 55 a measure of deviation from nominal flow rates, and a data loss at-a- 56 glance measure for a particular flow. For instance, the MDI may be 57 used as a reference in characterizing and comparing networks carrying 58 UDP streaming media. 60 The Media Delivery Index measurement defined in this memo is intended 61 for Information only. 63 1. 64 Introduction 66 There has been considerable progress over the last several years in 67 the development of methods to provide for Quality of Service (QoS) 68 over packet switched networks to improve the delivery of streaming 69 media and other time and packet loss sensitive applications such as 70 [i1], [i5], [i6], [i7]. QoS is required for many practical networks 71 involving applications such as video transport to assure the 72 availability of network bandwidth by providing upper limits on the 73 number of flows admitted to a network as well as to bound the packet 74 jitter introduced by the network. These bounds are required to 75 dimension a receiver`s buffer to properly display the video in real 76 time without buffer overflow or underflow. 78 Now that large scale implementations of such networks based on RSVP 79 and Diffserv are undergoing trials [i3] and being specified by major 80 service providers for the transport of streaming media such as MPEG 81 video [i4], there is a need to easily diagnose issues and monitor the 82 real time effectiveness of networks employing these QoS methods or to 83 assess whether they are required. Furthermore, due to the significant 84 installed base of legacy networks without QoS methods, a delivery 85 system`s transitional solution may be comprised of both networks with 86 and without these methods thus increasing the difficulty in 87 characterizing the dynamic behavior of these networks. 89 The purpose of this memo is to describe a set of measurements that 90 can be used to derive a Media Delivery Index (MDI) which indicates 91 the instantaneous and longer term behavior of networks carrying 92 streaming media such as MPEG video. 94 While this memo addresses monitoring MPEG Transport Stream (TS) 95 packets [i8] over UDP, the general approach is expected to be 96 applicable to other streaming media and protocols. The approach is 97 applicable to both constant and variable bit rate streams though the 98 variable bit rate case may be somewhat more difficult to calculate. 99 This draft focuses on the constant bit rate case as the example to 100 describe the measurement but as long as the dynamic bit rate of the 101 encoded stream can be determined (the "drain rate" as described 102 below in Section 3), then the MDI provides the measurement of 103 network induced cumulative jitter. Suggestions and direction for 104 calculation of MDI for a variable bit rate encoded stream may be the 105 subject of a future document. 107 2. 108 Media Delivery Index Overview 110 The MDI provides a relative indicator of needed buffer depths at the 111 consumer node due to packet jitter as well as an indication of lost 112 packets. By probing a streaming media service network at various 113 nodes and under varying load conditions, it is possible to quickly 114 identify devices or locales which introduce significant jitter or 115 packet loss to the packet stream. By monitoring a network 116 continuously, deviations from nominal jitter or loss behavior can be 117 used to indicate an impending or ongoing fault condition such as 118 excessive load. It is believed that the MDI provides the necessary 119 information to detect all network induced impairments for streaming 120 video or voice over IP applications. Other parameters may be 121 required to troubleshoot and correct the impairments. 123 The MDI is updated at the termination of selected time intervals 124 spanning multiple packets which contain the streaming media (such as 125 transport stream packets in the MPEG-2 case.) The Maximums and 126 Minimums of the MDI component values are captured over a measurement 127 time. The measurement time may range from just long enough to 128 capture an anticipated network anomaly during a troubleshooting 129 exercise to indefinitely long for a long term monitoring or 130 logging application. The Maximums and Minimums may be obtained by 131 sampling the measurement with adequate frequency. 133 3. 134 Media Delivery Index Components 136 The MDI consists of two components: the Delay Factor (DF) and the 137 Media Loss Rate (MLR). 139 3.1 140 Delay Factor 142 The Delay Factor is the maximum difference, observed at the end of 143 each media stream packet, between the arrival of media data and the 144 drain of media data, assuming the drain rate is the nominal constant 145 traffic rate for constant bit rate streams or the piece-wise computed 146 traffic rate of variable rate media stream packet data. The "drain 147 rate" here refers to the payload media rate; e.g., for a typical 3.75 148 Mb/s MPEG video Transport Stream (TS), the drain rate is 3.75 Mb/s -- 149 the rate at which the payload is consumed (displayed) at a decoding 150 node. If, at the sample time, the number of bytes received equals 151 the number transmitted, the instantaneous flow rate balance will be 152 zero, however the minimum DF will be a line packet's worth of media 153 data as that is the minimum amount of data that must be buffered. 155 The DF is the maximum observed value of the flow rate imbalance. 156 This buffered media data in bytes is expressed in terms of how long, 157 in milliseconds, it would take to drain (or fill) this data at the 158 nominal traffic rate to obtain the DF. Display of DF with a 159 resolution of tenths of milliseconds provides adequate indication of 160 stream variations for monitoring and diagnostic applications for 161 typical stream rates of up to 40 Mb/s. The DF value must be updated 162 and displayed at the end of a selected time interval. The selected 163 time interval is chosen to be long enough to sample a number of TS 164 packets and will, therefore, vary based on the nominal traffic rate. 165 For typical stream rates of 64 Kbps and up, an interval of 1 second 166 provides a long enough sample time and should be included for all 167 implementations. The Delay Factor indicates how long a data stream 168 must be buffered (i.e. delayed) at its nominal bit rate to prevent 169 packet loss. Another perspective of this time is as a measure of the 170 network latency that must be induced from buffering that is required 171 to accommodate stream jitter and prevent loss. The DF`s max and min 172 over the measurement period may also be displayed to show the worst 173 case arrival time deviation, or jitter, relative to the nominal 174 traffic rate in a measurement period. It provides a dynamic flow 175 rate balance indication with its max and min showing the worst 176 excursions from balance. To arrive at a bounded DF, the long term 177 flow rate deviation (LFRD) must be 0, where LFRD is a running 178 deviation of flow rate from expected nominal traffic rate over a 179 measurement period. A large positive or negative LFRD usually 180 indicates a source flow failure or misconfiguration and would cause 181 the DF value to steadily increase from interval to interval. 183 The Delay Factor gives a hint of the minimum size of the buffer 184 required at the next downstream node. As a stream progresses, the 185 variation of the Delay Factor indicates packet bunching (jitter). 186 Greater DF values also indicate more network latency necessary to 187 deliver a stream due to the need to prefill a receive buffer before 188 beginning the drain to guarantee no underflow. The DF comprises a 189 fixed part based on packet size and a variable part based on the 190 various network component switch elements` buffer utilization that 191 comprise the switched network infrastructure [i2]. 193 3.2 194 Media Loss Rate 195 The Media Loss Rate is the count of lost or out of order flow packets 196 over a selected time interval, where the flow packets are packets 197 carrying streaming application information. There may be zero or 198 more streaming packets in a single IP packet. For example, it is 199 common to carry seven 188 Byte MPEG Transport Stream packets in an IP 200 packet. In such a case, a single IP packet loss would result in 7 201 lost packets counted for the case where the 7 lost packets did not 202 include null packets. Including out of order packets is important as 203 many stream consumer type devices do not attempt to reorder packets 204 that are received out of order. 206 3.3 207 Media Delivery Index 209 Combining the Delay Factor and Media Loss Rate quantities for 210 presentation results in the MDI: 212 DF:MLR 214 Where: 216 DF is the Delay Factor 217 MLR is the Media Loss Rate 219 At a receiving node, knowing its nominal drain bit rate, the DF`s max 220 indicates the size of required buffer to accommodate packet jitter. 221 Or, in terms of Leaky Bucket [i9] parameters, DF indicates bucket 222 size b expressed in time to transmit bucket traffic b, at the given 223 nominal traffic rate, r. 225 3.4 226 MDI Application Examples 228 In the case where a known, well characterized receive node is 229 separated from the data source by unknown or less well characterized 230 nodes such as intermediate switch nodes, the MDI measured at 231 intermediate data links provides a relative indication of the 232 behavior of upstream traffic flows. DF difference indications 233 between one node and another in a data stream for a given constant 234 interval of calculation can indicate local areas of traffic 235 congestion or possibly misconfigured QoS flow specification(s) 236 leading to greater filling of measurement point local device buffers, 237 resultant flow rate deviations, and possible data loss. 239 For a given MDI, if DF is high and/or the DF Max-Min captured over a 240 significant measurement period is high, jitter has been detected but 241 the longer term, average flow rate may be nominal. This could be the 242 result of a transient flow upset due to a coincident traffic stream 243 unrelated to the flow of interest causing packet bunching. A high DF 244 may cause downstream buffer overflow or underflow or unacceptable 245 latency even in the absence of lost data. 247 Due to transient network failures or DF excursions, packets may be 248 lost within the network. The MLR component of the MDI shows this 249 condition. 251 Through automated or manual flow detection and identification and 252 subsequent MDI calculations for real time statistics on a flow, the 253 DF can indicate the dynamic deterioration or increasing burstiness of 254 a flow which can be used to anticipate a developing network operation 255 problem such as transient oversubscription. Such statistics can be 256 obtained for flows within network switches using available switch cpu 257 resources due to the minimal computational requirements needed for 258 small numbers of flows. Statistics for all flows present on, say, a 259 gigabit Ethernet network, will likely require dedicated hardware 260 facilities though these can be modest as buffer requirements and the 261 required calculations per flow are minimal. By equipping network 262 switches with MDI measurements, flow impairment issues can quickly be 263 identified, localized, and corrected. Until switches are so equipped 264 with appropriate hardware resources, dedicated hardware tools can 265 provide supplemental switch statistics by gaining access to switch 266 flows via mirror ports, link taps, or the like as a transition 267 strategy. 269 The MDI figure can also be used to characterize a flow decoder's 270 acceptable performance. For example, an MPEG decoder could be 271 characterized as tolerating a flow with a given maximum DF and MLR 272 for acceptable display performance (acceptable on-screen artifacts). 273 Network conditions such as Interior Gateway Protocol (IGP) 274 reconvergence might also be included in the flow tolerance resulting 275 in a higher quality user experience. 277 4. 278 Summary 280 The MDI combines the Delay Factor which indicates potential for 281 impending data loss and Media Loss Rate as the indicator of lost 282 data. By monitoring the DF and MLR and their min and max excursions 283 over a measurement period and at multiple strategic locations in a 284 network, traffic congestion or device impairments may be detected and 285 isolated for a network carrying streaming media content. 287 5. 288 Security Considerations 290 The measurements identified in this document do not directly affect 291 the security of a network or user. Actions taken in response to 292 these measurements which may affect the available bandwidth of the 293 network or availability of a service is out of scope for this 294 document. 296 Performing the measurements described in this document only requires 297 examination of payload header information such as MPEG transport 298 stream headers or RTP headers to determine nominal stream bit rate 299 and sequence number information. Content may be encrypted without 300 affecting these measurements. Therefore, content privacy is not 301 expected to be a concern. 303 6. 304 Normative References 306 7. 307 Informative References 309 i1. R. Braden et al., `Resource Reservation Protocol ` Version 1 310 Functional Specification`, RFC 2205, 1997. 311 i2. C. Partridge, `A Proposed Flow Specification`, RFC 1363, 1992. 312 i3. R. Fellman, `Hurdles to Overcome for Broadcast Quality Video 313 Delivery over IP` VidTranS 2002. 314 i4. CableLabs `PacketCable Dynamic Quality-of-Service Specification`, 315 PKT-SP-DQOS-I06-030415, 2003. 316 i5. S. Shenker, C. Partridge, R. Guerin, `Specification of Guaranteed 317 Quality of Service`, RFC 2212, 1997. 318 i6. J. Wroclawski, `Specification of the Controlled-Load Network 319 Element Service`, RFC 2211, 1997. 320 i7. R. Braden, D. Clark, S. Shenker, `Integrated Services in the 321 Internet Architecture: an Overview` RFC 1633, 1994. 322 i8. ISO/IEC 13818-1 (MPEG-2 Systems) 323 i9. V. Raisanen, `Implementing Service Quality in IP Networks`, John 324 Wiley & Sons Ltd., 2003. 326 8. 327 Acknowledgments 329 The authors gratefully acknowledge the contributions of Marc Todd and 330 Jesse Beeson of IneoQuest Technologies, Inc., Bill Trubey and John 331 Carlucci of Time Warner Cable, Nishith Sinha of Cox Communications, 332 Ken Chiquoine of SeaChange International, Phil Proulx of Bell Canada, 333 Dr Paul Stallard of TANDBERG Television, Gary Hughes of Broadbus 334 Technologies, Brad Medford of SBC Laboratories, John Roy of Adelphia 335 Communications, Cliff Mercer, PhD of Kasenna, Mathew Ho of Rogers 336 Cable, and Irl Duling of Optinel Systems for reviewing and evaluating 337 early drafts of this document and implementations for MDI. 339 9. 340 Authors' Address 342 James Welch 343 IneoQuest Technologies, Inc 344 170 Forbes Blvd 345 Mansfield, Massachusetts 02048 346 508 618 0312 347 Jim.Welch@ineoquest.com 348 James Clark 349 Cisco Systems, Inc 350 500 Northridge Road 351 Suite 800 352 Atlanta, Georgia 30350 353 678 352 2726 354 jiclark@cisco.com 356 10. 357 Copyright Notice 359 Copyright (C) The Internet Society (2005). This document is subject to 360 the rights, licenses and restrictions contained in BCP 78, and except 361 as set forth therein, the authors retain all their rights. 363 11. 364 Disclaimer 366 This document and the information contained herein are provided on an 367 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 368 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 369 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 370 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 371 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 372 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.' 374 12. 375 Intellectual Property 377 The IETF takes no position regarding the validity or scope of any 378 Intellectual Property Rights or other rights that might be claimed to 379 pertain to the implementation or use of the technology described in 380 this document or the extent to which any license under such rights 381 might or might not be available; nor does it represent that it has 382 made any independent effort to identify any such rights. Information 383 on the ISOC's procedures with respect to rights in ISOC Documents can 384 be found in BCP 78 and BCP 79. 386 Copies of IPR disclosures made to the IETF Secretariat and any 387 assurances of licenses to be made available, or the result of an 388 attempt made to obtain a general license or permission for the use of 389 such proprietary rights by implementers or users of this 390 specification can be obtained from the IETF on-line IPR repository at 391 http://www.ietf.org/ipr. 393 The IETF invites any interested party to bring to its attention any 394 copyrights, patents or patent applications, or other proprietary 395 rights that may cover technology that may be required to implement 396 this standard. Please address the information to the IETF at ietf- 397 ipr@ietf.org. 399 TO BE DELETED BY THE RFC EDITOR UPON PUBLICATION: 400 Changes from draft-welch-mdi-02.txt: 402 *removed representative MIB that could be used for export since 403 focus of document is the MDI measurement and suggested MIB did not 404 comply with MIB review guidelines. 405 *clarified recommended common measurement period and quantization 406 to promote common implementations