idnits 2.17.1 draft-wu-xrblock-rtcp-xr-quality-monitoring-04.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 date (October 29, 2011) is 4560 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) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-22) exists of draft-ietf-avtcore-monarch-00 Summary: 1 error (**), 0 flaws (~~), 2 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: May 1, 2012 Network Zen 6 R. Schott 7 Deutsche Telekom Laboratories 8 K. Lee 9 China Telecom 10 October 29, 2011 12 RTCP XR Blocks for multimedia quality metric reporting 13 draft-wu-xrblock-rtcp-xr-quality-monitoring-04 15 Abstract 17 This document defines an RTCP XR Report Block and associated SDP 18 parameters that allow the reporting of multimedia quality metrics for 19 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 May 1, 2012. 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 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2.1. Standards Language . . . . . . . . . . . . . . . . . . . . 3 58 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 3 59 4. Synthetical Multimedia Quality Metrics Block . . . . . . . . . 4 60 4.1. Metric Block Structure . . . . . . . . . . . . . . . . . . 5 61 4.2. Definition of Fields in Multimedia Quality Metrics 62 Block . . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 5. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 7 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 66 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 67 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 69 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 70 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 9 71 A.1. draft-wu-xrblock-rtcp-xr-quality-monitoring-03 . . . . . . 9 72 A.2. draft-wu-xrblock-rtcp-xr-quality-monitoring-04 . . . . . . 9 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 75 1. Introduction 77 This draft defines a new block type to augment those defined in 78 [RFC3611], for use in a range of RTP applications. 80 The new block type provides information on multimedia quality using 81 one of several standard metrics. 83 The metrics belong to the class of application level metrics defined 84 in [MONARCH] (work in progress). 86 2. Terminology 88 2.1. Standards Language 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in RFC 2119 [RFC2119]. 94 The terminology used is 95 Numeric formats S X:Y 96 where S indicates a two's complement signed representation, X 97 the number of bits prior to the decimal place and Y the number 98 of bits after the decimal place. 99 Hence 8:8 represents an unsigned number in the range 0.0 to 100 255.996 with a granularity of 0.0039. S7:8 would represent the 101 range -127.996 to +127.996. 0:16 represents a proper binary 102 fraction with range 103 0.0 to 1 - 1/65536 = 0.9999847 104 though note that use of flag values at the top of the numeric 105 range slightly reduces this upper limit. For example, if the 106 16- bit values 0xfffe and 0xffff are used as flags for "over- 107 range" and "unavailable" conditions, a 0:16 quantity has range 108 0.0 to 1 - 3/65536 = 0.9999542 110 3. Applicability 112 The Multimedia Quality Metrics Report Block can be used in any real- 113 time AV application. 115 The factors that affect real-time AV application quality can be split 116 into two categories. The first category consists of transport- 117 dependent factors such as packet loss, delay and jitter (which also 118 translates into losses in the playback buffer). The factors in the 119 second category are application-specific factors that affect real 120 time application (e.g., video) quality and are sensitivity to network 121 errors. These factors can be but not limited to video codec and loss 122 recovery technique, coding bit rate, packetization scheme, and 123 content characteristics. 125 Compared with application-specific factors, the transport-dependent 126 factors sometimes are not sufficient to measure real time data 127 quality, since the ability to analyze the real time data in the 128 application layer provides quantifiable measurements for subscriber 129 Quality of Experience (QoE) that may not be captured in the 130 transmission layers or from the RTP layer down. In a typical 131 scenario, monitoring of the transmission layers can produce 132 statistics suggesting that quality is not an issue, such as the fact 133 that network jitter is not excessive. However, problems may occur in 134 the service layers leading to poor subscriber QoE. Therefore 135 monitoring using only network-level measurements may be insufficient 136 when application layer content quality is required. 138 In order to provide accurate measures of real time application 139 quality when transporting real time contents across a network, the 140 synthentical multimedia quality Metrics is highly required which can 141 be conveyed in the RTCP XR packets[RFC3611] and may have the 142 following three benefits: 144 o Tuning the content encoder algorithm to satisfy real time data 145 quality requirements 146 o Determining which system techniques to use in a given situation 147 and when to switch from one technique to another as system 148 parameters change 149 o Verifying the continued correct operation of an existing system 151 4. Synthetical Multimedia Quality Metrics Block 153 This block reports the multimedia application performance or quality 154 beyond the information carried in the standard RTCP packet format. 155 Information is recorded about multimedia application QoE metric which 156 provides a measure that is indicative of the user's view of a 157 service. Multimedia application QoE metric is commonly expressed as 158 a MOS ("Mean Opinion Score"), MOS is on a scale from 1 to 5, in which 159 5 represents excellent and 1 represents unacceptable. MOS scores are 160 usually obtained using subjective testing or using objective 161 algorithm. However Subjective testing to estimate the multimedia 162 quality may be not suitable for measuring the multimedia quality 163 since the results may vary from test to test. Therefore using 164 objective algorithm to calculate MOS scores is recommended. ITU-T 165 recommendations define the methodologies for assessment of the 166 performance of multimedia stream 167 [G.107][P.564][G.1082][P.NAMS][P.NBAMS] and provides a method to 168 evaluate QoE estimation algorithms and objective model for video and 169 audio. Hence this document recommends vendors and implementers to 170 use these International Telecommunication Union (ITU)-specified 171 methodologies to measure parameters when possible. 173 4.1. Metric Block Structure 175 The report block contents are dependent upon a series of flag bits 176 carried in the first part of the header. Not all parameters need to 177 be reported in each block. Flags indicate which are and which are 178 not reported. The fields corresponding to unreported parameters MUST 179 be present, but are set to zero. The receiver MUST ignore any 180 Perceptual Quality Metrics Block with a non-zero value in any field 181 flagged as unreported. 183 The Synthetical Multimedia Quality Metrics Block has the following 184 format: 186 0 1 2 3 187 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 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | BT=TBD |I| MC | Rsd.| block length | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | SSRC of source | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Rsv. | MOS Value | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 4.2. Definition of Fields in Multimedia Quality Metrics Block 198 Block type (BT): 8 bits 200 The Synthetical Multimedia Quality Metrics Block is identified by 201 the constant . 203 Interval Metric flag (I): 1 bit 205 This field is used to indicate whether the Basic Loss/Discard 206 metrics are Interval or Cumulative metrics, that is, whether the 207 reported values applies to the most recent measurement interval 208 duration between successive metrics reports (I=1) (the Interval 209 Duration) or to the accumulation period characteristic of 210 cumulative measurements (I=0) (the Cumulative Duration). 212 MoS Type (MT): 4 bits 214 This field is used to indicate the MOS type to be reported. The 215 MOS type is defined as follows: 217 0000 MOS-LQ - Listening Quality MoS. 218 0001 MOS-CQ - Conversation Quality MoS. 219 0010 MOS-V - Video Quality MOS. 220 0011 MOS-AV - Audio-Video Quality MOS. 221 0100~1111 - Reserved for future definitions. 223 MoS-LQ measures the quality of audio for listening purposes only 224 while MoS-CQ measures the quality of audio for conversation 225 purpose only. MoS-V and MoS-AV measures the quality of video 226 application or Audio-Video application.Both MoS-LQ and MoS-CQ are 227 commonly used in VoIP applications. MOS-LQ uses either wideband 228 audio codec or narrowband audio codec, or both and does not take 229 into account any of bidirectional effects, such as delay and echo. 230 MOS-CQ uses narrowband codec and takes into account listening 231 quality in each direction, as well as the bidirectional effects. 232 If MoS type is MoS-LQ and MoS-CQ, the MoS value can be calculated 233 based on ITU-T G.107[G.107], ITU-T P.564 [P.564]or ETSI TS 101 234 329-5 [ETSI], if the Mos type is MoS-V or MoS-AV, the Mos value 235 can be calculated based on ITU-T P.NAMS [P.NAMS]or ITU-T P.NBAMS 236 [P.NBAMS]. If new MOS types are defined, they can be added by an 237 update to this document. If the receiver does not understand the 238 MOS type defined in this document it should discard this report. 240 Rsd.:3 bits 242 This field is reserved for future definition. In the absence of 243 such a definition, the bits in this field MUST be set to zero and 244 MUST be ignored by the receiver. 246 Block Length: 16 bits 248 The length of this report block in 32-bit words, minus one. For 249 the Packet Delay Variation Metrics block, the block length is 250 equal to 2. 252 SSRC of source: 32 bits 254 As defined in Section 4.1 of [RFC3611]. 256 Rsd.:16 bits 258 This field is reserved for future definition. In the absence of 259 such a definition, the bits in this field MUST be set to zero and 260 MUST be ignored by the receiver. 262 MOS Value: 16 bits 264 The estimated mean opinion score for multimedia application 265 quality is defined as including the effects of delay,loss, 266 discard,jitter and other effects that would affect multimedia 267 quality . It is expressed in numeric format 8:8 with the value in 268 the range 0.0 to 255.996. The valid the measured value ranges 269 from 0.0 to 50.0, corresponding to MoS x 10 as for MoS. If the 270 measured value is over ranged, the value 0xFFFE SHOULD be reported 271 to indicate an over-range measurement. If the measurement is 272 unavailable, the value 0xFFFF SHOULD be reported. Values other 273 than 0xFFFE,0xFFFF and the valid range defined above MUST NOT be 274 sent and MUST be ignored by the receiving system. 276 5. SDP Signaling 278 One new parameter is defined for the report block defined in this 279 document to be used with Session Description Protocol (SDP) [RFC4566] 280 using the Augmented Backus-Naur Form (ABNF) [RFC5234]. It has the 281 following syntax within the "rtcp-xr" attribute [RFC3611]: 283 rtcp-xr-attrib = "a=rtcp-xr:" 284 [xr-format *(SP xr-format)] CRLF 285 xr-format = multimedia-quality-metrics 286 multimedia-quality-metrics = "multimedia-quality-metrics" 288 Refer to Section 5.1 of RFC 3611 [RFC3611] for a detailed description 289 and the full syntax of the "rtcp-xr" attribute. 291 6. IANA Considerations 293 New report block types for RTCP XR are subject to IANA registration. 294 For general guidelines on IANA allocations for RTCP XR, refer to 295 Section 6.2 of [RFC3611]. 297 This document assigns one new block type value in the RTCP XR Block 298 Type Registry: 300 Name: SMQM 301 Long Name: Synthetical Multimedia Quality Metric 302 Value 303 Reference: Section 4 305 This document also registers one new SDP [RFC4566] parameter for the 306 "rtcp-xr" attribute in the RTCP XR SDP Parameters Registry: 308 * "multimedia-quality-metrics" 310 The contact information for the registrations is: 312 Qin Wu 313 sunseawq@huawei.com 314 101 Software Avenue, Yuhua District 315 Nanjing, JiangSu 210012 China 317 7. Security Considerations 319 The new RTCP XR report blocks proposed in this document introduces no 320 new security considerations beyond those described in [RFC3611]. 322 8. Acknowledgements 324 The authors would like to thank Alan Clark, Bill Ver Steeg, David R 325 Oran, Ali Begen,Colin Perkins, Roni Even,Youqing Yang, Wenxiao Yu and 326 Yinliang Hu for their valuable comments and suggestions on this 327 document. 329 9. References 331 9.1. Normative References 333 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 334 Requirement Levels", BCP 14, RFC 2119, March 1997. 336 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 337 Protocol Extended Reports (RTCP XR)", RFC 3611, 338 November 2003. 340 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 341 Description Protocol", RFC 4566, July 2006. 343 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 344 Specifications: ABNF", STD 68, RFC 5234, January 2008. 346 9.2. Informative References 348 [ETSI] ETSI, "Quality of Service (QoS) measurement 349 methodologies", ETSI TS 101 329-5 V1.1.1, November 2000. 351 [G.107] ITU-T, "The E Model, a computational model for use in 352 transmission planning", ITU-T Recommendation G.107, 353 April 2009. 355 [G.1082] ITU-T, "Measurement-based methods for improving the 356 robustness of IPTV performance", ITU-T 357 Recommendation G.1082, April 2009. 359 [MONARCH] Wu, Q., "Monitoring Architectures for RTP", 360 ID draft-ietf-avtcore-monarch-00, April 2011. 362 [P.564] ITU-T, "Conformance testing for narrowband Voice over IP 363 transmission quality assessment models", ITU-T 364 Recommendation P.564, July 2006. 366 [P.NAMS] ITU-T, "Non-intrusive parametric model for the Assessment 367 of performance of Multimedia Streaming", ITU-T 368 Recommendation P.NAMS, November 2009. 370 [P.NBAMS] ITU-T, "non-intrusive bit-stream model for assessment of 371 performance of multimedia streaming", ITU-T 372 Recommendation P.NBAMS, November 2009. 374 Appendix A. Change Log 376 A.1. draft-wu-xrblock-rtcp-xr-quality-monitoring-03 378 The following are the major changes compared to previous version 02: 379 o Remove the tag field. 380 o Define MOS Value field as 32 bits integer value field. 381 o Clear unused references. 382 o Add text to MOS type field for clarification. 383 o Other Editorial changes. 385 A.2. draft-wu-xrblock-rtcp-xr-quality-monitoring-04 387 The following are the major changes compared to previous version 03: 388 o Add Numeric format definition and express the MoS-Value in Numeric 389 format. 391 o Change 32bits MoS Value into 16bits MoS Value. 392 o Add some text to MoS Type definition to clarify the algorithm 393 calculation. 394 o Separate MoS-A into MoS-LQ and MoS-CQ and add some text to clarify 395 the difference between them. 396 o Add one more reference for MoS-LQ and MoS-CQ value calculation. 397 o Other Editorial changes. 399 Authors' Addresses 401 Qin Wu 402 Huawei 403 101 Software Avenue, Yuhua District 404 Nanjing, Jiangsu 210012 405 China 407 Email: sunseawq@huawei.com 409 Glen Zorn 410 Network Zen 411 77/440 Soi Phoomjit, Rama IV Road 412 Phra Khanong, Khlong Toie 413 Bangkok 10110 414 Thailand 416 Phone: +66 (0) 87 502 4274 417 Email: gwz@net-zen.net 419 Roland Schott 420 Deutsche Telekom Laboratories 421 Deutsche-Telekom-Allee 7 422 Darmstadt 64295 423 Germany 425 Email: Roland.Schott@telekom.de 427 Kai Lee 428 China Telecom 429 China Telecom Beijing Research Institute 431 Email: leekai@ctbri.com.cn