idnits 2.17.1 draft-wu-xrblock-rtcp-xr-quality-monitoring-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 16, 2011) is 4728 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2250' is defined on line 300, but no explicit reference was found in the text == Unused Reference: 'RFC3550' is defined on line 304, but no explicit reference was found in the text == Unused Reference: 'DSLF' is defined on line 320, but no explicit reference was found in the text == Unused Reference: 'IEEE' is defined on line 332, but no explicit reference was found in the text == Unused Reference: 'PMOL' is defined on line 356, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-22) exists of draft-ietf-avtcore-monarch-00 == Outdated reference: A later version (-12) exists of draft-ietf-pmol-metrics-framework-08 Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Q. Wu 3 Internet-Draft Huawei 4 Intended status: Standards Track G. Zorn 5 Expires: November 17, 2011 Network Zen 6 R. Schott 7 Deutsche Telekom Laboratories 8 K. Lee 9 China Telecom 10 May 16, 2011 12 RTCP XR Blocks for multimedia quality metric reporting 13 draft-wu-xrblock-rtcp-xr-quality-monitoring-02 15 Abstract 17 This document defines an RTCP XR Report Block and associated SDP 18 parameters that allows the reporting of multimedia quality metrics 19 for use in a range of RTP applications. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on November 17, 2011. 38 Copyright Notice 40 Copyright (c) 2011 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 This document may contain material from IETF Documents or IETF 54 Contributions published or made publicly available before November 55 10, 2008. The person(s) controlling the copyright in some of this 56 material may not have granted the IETF Trust the right to allow 57 modifications of such material outside the IETF Standards Process. 58 Without obtaining an adequate license from the person(s) controlling 59 the copyright in such materials, this document may not be modified 60 outside the IETF Standards Process, and derivative works of it may 61 not be created outside the IETF Standards Process, except to format 62 it for publication as an RFC or to translate it into languages other 63 than English. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2.1. Standards Language . . . . . . . . . . . . . . . . . . . . 3 70 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . . 3 71 4. Synthetical Multimedia Quality Metrics Block . . . . . . . . . 4 72 4.1. Metric Block Structure . . . . . . . . . . . . . . . . . . 4 73 4.2. Definition of Fields in Multimedia Quality Metrics 74 Block . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 75 5. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 78 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 80 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 81 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 82 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . . 9 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 85 1. Introduction 87 This draft defines a new block type to augment those defined in 88 [RFC3611], for use in a range of RTP applications. 90 The new block type provides information on multimedia quality using 91 one of several standard metrics. 93 The metrics belong to the class of application level metrics defined 94 in [MONARCH] (work in progress). 96 2. Terminology 98 2.1. Standards Language 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in RFC 2119 [RFC2119]. 104 3. Applicability 106 The Multimedia Quality Metrics Report Block can be used in any real- 107 time AV application. 109 The factors that affect real-time AV application quality can be split 110 into two categories. The first category consists of transport- 111 dependent factors such as packet loss, delay and jitter (which also 112 translates into losses in the playback buffer). The factors in the 113 second category are application-specific factors that affect real 114 time application (e.g., video) quality and are sensitivity to network 115 errors. These factors can be but not limited to video codec and loss 116 recovery technique, coding bit rate, packetization scheme, and 117 content characteristics. 119 Compared with application-specific factors, the transport-dependent 120 factors sometimes are not sufficient to measure real time data 121 quality, since the ability to analyze the real time data in the 122 application layer provides quantifiable measurements for subscriber 123 Quality of Experience (QoE) that may not be captured in the 124 transmission layers or from the RTP layer down. In a typical 125 scenario, monitoring of the transmission layers can produce 126 statistics suggesting that quality is not an issue, such as the fact 127 that network jitter is not excessive. However, problems may occur in 128 the service layers leading to poor subscriber QoE. Therefore 129 monitoring using only network-level measurements may be insufficient 130 when application layer content quality is required. 132 In order to provide accurate measures of real time application 133 quality when transporting real time contents across a network, the 134 synthentical multimedia quality Metrics is highly required which can 135 be conveyed in the RTCP XR packets[RFC3611] and may have the 136 following three benefits: 138 o Tuning the content encoder algorithm to satisfy real time data 139 quality requirements 140 o Determining which system techniques to use in a given situation 141 and when to switch from one technique to another as system 142 parameters change 143 o Verifying the continued correct operation of an existing system 145 4. Synthetical Multimedia Quality Metrics Block 147 This block reports the multimedia application performance or quality 148 metrics beyond the information carried in the standard RTCP packet 149 format. Information is recorded about multimedia application QoE 150 metric which is expressed as a MOS ("Mean Opinion Score"), MOS is on 151 a scale from 1 to 5, in which 5 represents excellent and 1 represents 152 unacceptable. MOS scores are usually obtained using subjective 153 testing or using objective algorithm to estimate the multimedia 154 quality. However Subjective testing is not suitable for measuring 155 the multimedia quality since the results may vary from test to test. 156 Therefore using objective algorithm to calculate MOS scores is 157 recommended. ITU-T recommendation [G.1082][P.NAMS][P.NBAMS] defines 158 a methodology for verifying the performance of QoE estimation 159 algorithms for video and audio. Hence this document recommends 160 vendors and implementers to use International Telecommunication Union 161 (ITU)-specified methodologies to measure parameters when possible. 163 4.1. Metric Block Structure 165 The report block contents are dependent upon a series of flag bits 166 carried in the first part of the header. Not all parameters need to 167 be reported in each block. Flags indicate which are and which are 168 not reported. The fields corresponding to unreported parameters MUST 169 be present, but are set to zero. The receiver MUST ignore any 170 Perceptual Quality Metrics Block with a non-zero value in any field 171 flagged as unreported. 173 The Synthetical Multimedia Quality Metrics Block has the following 174 format: 176 0 1 2 3 177 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | BT=TBD |I| tag | MC | block length | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | SSRC of source | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | MOS Value | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 4.2. Definition of Fields in Multimedia Quality Metrics Block 188 Block type (BT): 8 bits 190 The Perceptual Quality Metrics Block is identified by the constant 191 . 193 Interval Metric flag (I): 1 bit 195 This field is used to indicate whether the Basic Loss/Discard 196 metrics are Interval or Cumulative metrics, that is, whether the 197 reported values applies to the most recent measurement interval 198 duration between successive metrics reports (I=1) (the Interval 199 Duration) or to the accumulation period characteristic of 200 cumulative measurements (I=0) (the Cumulative Duration). 202 Measurement Identifier association (tag): 3 bits 204 This field is used to identify the Measurement Identifier block 205 [MEASIDENT] which describes this measurement. 207 MoS Class (MC): 4 bits 209 This field is used to indicate the MOS type to be reported. The 210 MOS type is defined as follows: 211 0000 MOS-A - Audio Quality MOS [G.107][P.564]. 212 0001 MOS-V - Video Quality MOS [P.NAMS][P.NBAMS]. 213 0010 MOS-AV - Audio-Video Quality MOS[P.NAMS][P.NBAMS]. 214 0100~1111 - Reserved 216 Rsd.: 7 bits 218 This field is reserved for future definition. In the absence of 219 such a definition, the bits in this field MUST be set to zero and 220 MUST be ignored by the receiver. 222 SSRC of source: 32 bits 224 As defined in Section 4.1 of [RFC3611]. 226 MOS Value: Variable Length 228 The estimated mean opinion score for Audio Qulity, Video Quality 229 or Audio-Video quality is defined as including the effects of 230 delay and other effects that would affect Audio-Video quality 231 [G.1082][P.NAMS][P.NBAMS]. It is expressed as an integer in the 232 range 10 to 50, corresponding to MOS x 10, as for MOS. A value of 233 127 indicates that this parameter is unavailable. Values other 234 than 127 and the valid range defined above MUST NOT be sent and 235 MUST be ignored by the receiving system. 237 5. SDP Signaling 239 One new parameter is defined for the six report blocks defined in 240 this document to be used with Session Description Protocol (SDP) 241 [RFC4566] using the Augmented Backus-Naur Form (ABNF) [RFC5234]. 242 They have the following syntax within the "rtcp-xr" attribute 243 [RFC3611]: 245 rtcp-xr-attrib = "a=rtcp-xr:" 246 [xr-format *(SP xr-format)] CRLF 247 xr-format = multimedia-quality-metrics 248 multimedia-quality-metrics = "multimedia-quality-metrics" 249 ["=" stat-flag *("," stat-flag)] 250 stat-flag = "Interval Metrics" 251 /"Cumulative metrics" 253 Refer to Section 5.1 of RFC 3611 [RFC3611] for a detailed description 254 and the full syntax of the "rtcp-xr" attribute. 256 6. IANA Considerations 258 New report block types for RTCP XR are subject to IANA registration. 259 For general guidelines on IANA allocations for RTCP XR, refer to 260 Section 6.2 of [RFC3611]. 262 This document assigns one new block type value in the RTCP XR Block 263 Type Registry: 265 Name: SMQM 266 Long Name: Synthetical Multimedia Quality Metric 267 Value 268 Reference: Section 4 270 This document also registers one new SDP [RFC4566] parameter for the 271 "rtcp-xr" attribute in the RTCP XR SDP Parameters Registry: 273 * "multimedia-quality-metrics" 275 The contact information for the registrations is: 277 Qin Wu 278 sunseawq@huawei.com 279 101 Software Avenue, Yuhua District 280 Nanjing, JiangSu 210012 China 282 7. Security Considerations 284 The new RTCP XR report blocks proposed in this document introduces no 285 new security considerations beyond those described in [RFC3611]. 287 8. Acknowledgements 289 The authors would like to thank Bill Ver Steeg, David R Oran, Ali 290 Begen,Colin Perkins, Roni Even,Youqing Yang, Wenxiao Yu and Yinliang 291 Hu for their valuable comments and suggestions on this document. 293 9. References 295 9.1. Normative References 297 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 298 Requirement Levels", BCP 14, RFC 2119, March 1997. 300 [RFC2250] Hoffman, D., Fernando, G., Goyal, V., and M. Civanlar, 301 "RTP Payload Format for MPEG1/MPEG2 Video", RFC 2250, 302 January 1998. 304 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 305 Jacobson, "RTP: A Transport Protocol for Real-Time 306 Applications", STD 64, RFC 3550, July 2003. 308 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 309 Protocol Extended Reports (RTCP XR)", RFC 3611, 310 November 2003. 312 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 313 Description Protocol", RFC 4566, July 2006. 315 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 316 Specifications: ABNF", STD 68, RFC 5234, January 2008. 318 9.2. Informative References 320 [DSLF] Rahrer, T., Ed., Fiandra, Ed., and Wright, Ed., "Triple- 321 play Services Quality of Experience (QoE) Requirements", 322 DSL Forum Technical Report TR-126, December 2006. 324 [G.107] ITU-T, "The E Model, a computational model for use in 325 transmission planning", ITU-T Recommendation G.107, 326 April 2009. 328 [G.1082] ITU-T, "Measurement-based methods for improving the 329 robustness of IPTV performance", ITU-T 330 Recommendation G.1082, April 2009. 332 [IEEE] IEEE, "Human Perception of Jitter and Media 333 Synchronization", IEEE Journal on Selected Areas in 334 Communications Vol. 14, No. 1, January 1996. 336 [MEASIDENT] 337 Hunt, G. and A. Clark, "RTCP XR Measurement Identifier 338 Block", ID draft-ietf-avt-rtcp-xr-meas-identity-02, 339 May 2009. 341 [MONARCH] Wu, Q., "Monitoring Architectures for RTP", 342 ID draft-ietf-avtcore-monarch-00, April 2011. 344 [P.564] ITU-T, "Conformance testing for narrowband Voice over IP 345 transmission quality assessment models", ITU-T 346 Recommendation P.564, July 2006. 348 [P.NAMS] ITU-T, "Non-intrusive parametric model for the Assessment 349 of performance of Multimedia Streaming", ITU-T 350 Recommendation P.NAMS, November 2009. 352 [P.NBAMS] ITU-T, "non-intrusive bit-stream model for assessment of 353 performance of multimedia streaming", ITU-T 354 Recommendation P.NBAMS, November 2009. 356 [PMOL] Clark, A., "Framework for Performance Metric Development", 357 ID draft-ietf-pmol-metrics-framework-08, January 2011. 359 Appendix A. Change Log 361 This version focuses on multimedia quality metrics and separated 362 other metrics block as independent documents. 364 Authors' Addresses 366 Qin Wu 367 Huawei 368 101 Software Avenue, Yuhua District 369 Nanjing, Jiangsu 210012 370 China 372 Email: sunseawq@huawei.com 374 Glen Zorn 375 Network Zen 376 77/440 Soi Phoomjit, Rama IV Road 377 Phra Khanong, Khlong Toie 378 Bangkok 10110 379 Thailand 381 Phone: +66 (0) 87 502 4274 382 Email: gwz@net-zen.net 384 Roland Schott 385 Deutsche Telekom Laboratories 386 Deutsche-Telekom-Allee 7 387 Darmstadt 64295 388 Germany 390 Email: Roland.Schott@telekom.de 392 Kai Lee 393 China Telecom 394 China Telecom Beijing Research Institute 396 Email: leekai@ctbri.com.cn