idnits 2.17.1 draft-wu-xrblock-rtcp-xr-quality-monitoring-01.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 (March 2, 2011) is 4796 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 927, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-pmol-metrics-framework-02' is defined on line 962, but no explicit reference was found in the text == Unused Reference: 'IEEE' is defined on line 965, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) -- No information found for draft-ietf-pmol-metrics-framework-02 - is the name correct? Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). 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: September 3, 2011 Network Zen 6 R. Schott 7 Deutsche Telekom Laboratories 8 March 2, 2011 10 RTP Control Protocol Extended Reports (RTCP XR) Report Blocks for Real- 11 time Application Quality Monitoring 12 draft-wu-xrblock-rtcp-xr-quality-monitoring-01 14 Abstract 16 This document defines a set of RTP Control Protocol Extended Reports 17 (RTCP XR) Report Blocks and associated SDP parameters allowing the 18 report of real time application quality metrics, primarily for video 19 applications of RTP. 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 September 3, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2.1. Standards Language . . . . . . . . . . . . . . . . . . . . 4 70 2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5 72 4. Transport Layer Metrics . . . . . . . . . . . . . . . . . . . 6 73 4.1. RTP Flows Initial Synchronization Delay Report Block . . . 6 74 4.2. RTP Flows General Synchronization Offset Metrics Block . . 7 75 4.3. Layered Streams Statistics Metrics Block . . . . . . . . . 8 76 5. Application Layer Metrics . . . . . . . . . . . . . . . . . . 10 77 5.1. Transport Streams Statistics Summary Report Block . . . . 10 78 5.2. Transport Stream Loss and Discard Metrics Block . . . . . 12 79 5.3. Transport Stream Burst Metrics Block . . . . . . . . . . . 14 80 5.4. Synthetical Multimedia Quality Metrics Block . . . . . . . 16 81 6. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 18 82 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 83 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 84 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 85 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 86 10.1. Normative References . . . . . . . . . . . . . . . . . . . 21 87 10.2. Informative References . . . . . . . . . . . . . . . . . . 22 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 90 1. Introduction 92 Along with the wide deployment of broadband access and the 93 development of new IPTV services (e.g., broadcast video, video on 94 demand), there is increasing interest in monitoring and managing 95 networks and applications that deliver real-time applications over 96 RTP or IP, to ensure that all end users obtain acceptable video/audio 97 quality. The main drives come from operators and enterprises, since 98 offering performance monitoring capability can help diagnose network 99 impairments, facilitate in root cause analysis and aid in verifying 100 compliance with service level agreements (SLAs) between Internet 101 Service Providers (ISPs) and content providers. 103 The factors that affect real-time application quality can be split 104 into two categories. The first category consists of transport- 105 dependent factors such as packet loss, delay and jitter (which also 106 translates into losses in the playback buffer). The factors in the 107 second category are application-specific factors that affect real 108 time application (e.g., video) quality and are sensitivity to network 109 errors. These factors can be but not limited to video codec and loss 110 recovery technique, coding bit rate, packetization scheme, and 111 content characteristics. 113 Compared with application-specific factors, the transport-dependent 114 factors sometimes are not sufficient to measure real time data 115 quality, since the ability to analyze the real time data in the 116 application layer provides quantifiable measurements for subscriber 117 Quality of Experience (QoE) that may not be captured in the 118 transmission layers or from the RTP layer down. In a typical 119 scenario, monitoring of the transmission layers can produce 120 statistics suggesting that quality is not an issue, such as the fact 121 that network jitter is not excessive. However, problems may occur in 122 the service layers leading to poor subscriber QoE. Therefore 123 monitoring using only network-level measurements may be insufficient 124 when application layer video quality is required. 126 In order to provide accurate measures of real time application 127 quality for operators when transporting real time contents across a 128 network, the synthentical multimedia quality Metrics is highly 129 required which can be conveyed in the RTCP XR packets[RFC3611] and 130 may have the following three benefits: 132 * Tuning the content encoder algorithm to satisfy real time data 133 quality requirements 134 * Determining which system techniques to use in a given situation 135 and when to switch from one technique to another as system 136 parameters change 138 * Verifying the continued correct operation of an existing system 140 RFC 3611 [RFC3611] defines seven report block formats for network 141 management and quality monitoring. However, some of these metrics 142 are mostly for multicast inference of network characteristics (MINC) 143 or voice over IP (VoIP) monitoring and not widely applicable to other 144 applications, e.g., video quality monitoring. This document focuses 145 on specifying new additional report block types used to convey QoE 146 related parameters that is genericly designed for use in voice, audio 147 and video services. 149 The report block types defined in this document fall into two 150 categories. The first category consists of general information 151 regarding transmission quality, to be generated and processed by the 152 RTP transport. The report blocks in the second category convey 153 metrics above transport that affect real time application quality and 154 are sensitivity to network errors. 156 Seven report block formats are defined by this document. Of these, 157 three are transport layer metrics: 159 * RTP Flows Initial Synchronization Delay Report Block 160 * RTP Flows General Synchronization Offset Metrics Block 161 * Layered Streams Statistics Metrics Block 163 The other four are application layer metrics: 165 * Transport Stream Statistics Summary Report Block 166 * Transport Stream Loss and Discard Metrics Block 167 * Transport Stream Burst Metrics Block 168 * Synthetical Multimedia Quality Metrics Block 170 2. Terminology 172 2.1. Standards Language 174 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 175 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 176 document are to be interpreted as described in RFC 2119 [RFC2119]. 178 In addition, the following terms are defined: 180 Layered Component Packet 182 a RTP packet using layered codecs containing the specified layered 183 component, e.g., encoded stream at the base layer or at the 184 enhancement layer. 186 Picture Type 188 Picture types used in the different video algorithms compose of 189 the key-frame and the Derivation frame. Key-frame is also called 190 a reference frame and used as a reference for predicting other 191 pictures. It is coded without prediction from other pictures. 192 The Derivation frame is derived from Key-frame using prediction 193 from the reference frame. 195 2.2. Acronyms 197 SSRC 198 Synchronization Source [RFC3550] 200 TS 201 Transport Stream [ISO-IEC.13818-1.2007] 203 3. Applicability 205 All the report blocks defined in this document could be used by 206 dedicated network monitoring applications. As specified in RFC 3611 207 [RFC3611], for such an application it might be appropriate to allow 208 more than 5% of RTP data bandwidth to be used for RTCP packets, thus 209 allowing proportionately larger and more detailed report blocks. 211 RTP Flows General Synchronization Offset Metrics Block in Section 4.2 212 has been defined for various multimedia applications. Such 213 applications can use this report block to monitor offset between two 214 RTP streams synchronization to ensure satisfactory QoE. Tighter 215 tolerances than typically used have been recommended for such 216 applications. 218 The RTP Flows Initial Synchronization Delay Report Block has been 219 defined primarily for layered or multi-description video coding 220 applications. When joining a layered video session in such an 221 application, a receiver may not synchronize playout across the 222 multimedia session until RTCP SR packets have been received on all of 223 the component RTP sessions. This report block can be used to measure 224 synchronization between different media layers for the same 225 multimedia session. 227 The Transport Stream Loss and Discard Metrics Report Block, Transport 228 Stream Burst Metrics report Block, Transport Statistics Summary 229 Report Block and Layered Streams Statistics Metrics Block can be 230 applied to any real time video application, while Synthetical 231 Multimedia Quality Metrics Report Block can be used in any real-time 232 AV application. 234 4. Transport Layer Metrics 236 4.1. RTP Flows Initial Synchronization Delay Report Block 238 This block reports Initial synchronization delay beyond the 239 information carried in the standard RTCP packet format. Information 240 is recorded about the the difference between the start of RTP 241 sessions and the time the RTP receiver acquires all components of RTP 242 sessions [RFC6051]. The components of RTP session are referred to as 243 one RTP session for each media type or the media content in each 244 layer contained in RTP Control Protocol (RTCP) sender report (SR) 245 packets [RFC3550]. For unicast session, the delay due to negotiation 246 of NAT pinholes, firewall holes, quality-of-service, and media 247 security keys is contributed to such initial synchronization delay. 248 For multicast session, the initial synchronization delay varies with 249 the session bandwidth and the number of members, the number of 250 senders in the session. In the absence of packet loss, the initial 251 synchronisation delay equals to the average time taken to receive the 252 first RTCP packet in the RTP session with the longest RTCP reporting 253 interval.In the presence of packet loss, the media synchronization 254 needs to wait until the reporting interval has passed, and the next 255 RTCP SR packet is sent. 257 The RTP Flows Initial Synchronization Delay Report Block has the 258 following format: 260 0 1 2 3 261 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 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | BT=TBD | Reserved | Block length | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | SSRC of Sender | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Initial Synchronization Delay | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 Block type (BT): 8 bits 271 The Statistics Summary Report Block is identified by the constant 272 . 274 Reserved: 8 bits 275 This field is reserved for future definition. In the absence of 276 such a definition, the bits in this field MUST be set to zero and 277 MUST be ignored by the receiver. 279 Block length: 16 bits 280 The constant 3, in accordance with the definition of this field in 281 Section 3 of RFC 3611 [RFC3611]. 283 SSRC of Sender: 32 bits 284 The SSRC of the RTP data packet source being reported upon by this 285 report block. (Section 4.1 of [RFC3611]). 287 Initial Synchronization Delay: 32 bits 288 The average delay, expressed in units of 1/65536 seconds, between 289 the RTCP packets received on all of the components RTP sessions 290 and the beginning of session [RFC6051]. The value is calculated 291 as follows: 293 The average time, expressed in units of 1/65536 seconds, taken 294 to receive the first RTCP packet in the RTP session with the 295 longest RTCP reporting interval [RFC6051] 297 4.2. RTP Flows General Synchronization Offset Metrics Block 299 In an RTP multimedia session, there can be an arbitrary number of 300 streams, with the same RTCP CNAME. This block reports the general 301 Synchronization offset status of these RTP streams beyond the 302 information carried in the standard RTCP packet format. Information 303 is recorded about the synchronization offset time of each RTP stream 304 relative to the reference RTP stream with the same CNAME and General 305 Synchronisation Offset of zero. For layered session or multimedia 306 session,the first RTP packet can be chosen as the basic packet of 307 reference RTP stream. The RTP Flow General Synchronization Offset 308 Report Block has the following format: 310 0 1 2 3 311 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 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | BT=TBD |I| Reserved | Block length | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | SSRC of source | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | General Synchronization Offset | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 Block type (BT): 8 bits 321 The Statistics Summary Report Block is identified by the constant 322 . 324 Interval Metric flag (I): 1 bit 326 This field is used to indicate whether the Audio-Video 327 synchronization metrics are Interval or Cumulative metrics, that 328 is, whether the reported values applies to the most recent 329 measurement interval duration between successive metrics reports 330 (I=1) (the Interval Duration) or to the accumulation period 331 characteristic of cumulative measurements (I=0) (the Cumulative 332 Duration). 334 Reserved: 8 bits 335 This field is reserved for future definition. In the absence of 336 such a definition, the bits in this field MUST be set to zero and 337 MUST be ignored by the receiver. 339 Block length: 16 bits 340 The constant 2, in accordance with the definition of this field in 341 Section 3 of RFC 3611 [RFC3611]. 343 SSRC of source: 32 bits 344 As defined in Section 4.1 of RFC 3611 [RFC3611]. 346 General synchronization offset: 32 bits 347 This field represents the synchronization offset time of one RTP 348 stream in milliseconds relative to the reference RTP stream with 349 the same CNAME and General Synchronisation Offset of zero 350 [RFC6051] This value is calculated based on the interarrival time 351 between arbitray RTP packet and the reference RTP packet with the 352 same CNAME , and timestamps of this arbitray RTP packet and the 353 reference RTP packet with the same CNAME. 355 4.3. Layered Streams Statistics Metrics Block 357 This block reports layered streams statistics beyond the information 358 carried in the Statistics Summary Report Block RTCP packet specified 359 in the section 4.6 of RFC 3611 [RFC3611]. Information is recorded 360 about lost layered component packets, duplicated layered component 361 packets. Such information can be useful for network management and 362 video quality monitoring. 364 The report block contents are dependent upon a series of flag bits 365 carried in the first part of the header. Not all parameters need to 366 be reported in each block. Flags indicate which parameters are 367 reported and which are not. The fields corresponding to unreported 368 parameters MUST be present, but are set to zero. The receiver MUST 369 ignore any Layered Streams Statistics Metrics Block with a non-zero 370 value in any field flagged as unreported. 372 The Layered Stream Statistics metrics Block has the following format: 374 0 1 2 3 375 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 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | BT=TBD |T| rsd. | block length | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | SSRC of source | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | begin_seq | end_seq | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | Lost_Layered Component Packets | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | Dup Layered Component_Packets | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 Block type (BT): 8 bits 389 The Layered stream Statistics Metrics Block is identified by the 390 constant . 392 Layer Type flag (T): 1 bits 393 This field is used to indicate the Layer Type of layered video to 394 be reported. LT is set to 0 if the loss_component_packet field 395 and dup_component packet contain the base layer packet in layered 396 codecs,e.g, SVC in [I-D.ietf-avt-rtp-svc], 1 if the loss_component 397 packet field and dup_component packet contain enhancement layer 398 packet in layered codec. 400 Rsd.: 3 bits 401 This field is reserved for future definition. In the absence of 402 such a definition, the bits in this field MUST be set to zero and 403 MUST be ignored by the receiver. 405 Block length: 16 bits 406 The constant 3, in accordance with the definition of this field in 407 Section 3 of RFC 3611 [RFC3611]. 409 SSRC of source: 32 bits 410 As defined in Section 4.1 of RFC 3611 [RFC3611]. 412 begin_seq: 16 bits 413 As defined in Section 4.1 of RFC 3611 [RFC3611]. 415 end_seq: 16 bits 416 As defined in Section 4.1 of RFC 3611 [RFC3611]. 418 Lost_Layered Component Packets: 32 bits 419 Number of lost_component packets in the above sequence number 420 interval. 422 Dup_Layered Component Packets: 32 bits 423 Number of dup_component packets in the above sequence number 424 interval. 426 5. Application Layer Metrics 428 5.1. Transport Streams Statistics Summary Report Block 430 This block reports statistics beyond the information carried in the 431 Statistics Summary Report Block RTCP packet specified in the section 432 4.6 of RFC 3611 [RFC3611]. Information is recorded about lost frame 433 packets, duplicated frame packets, lost layered component packets, 434 duplicated layered component packets. Such information can be useful 435 for network management and video quality monitoring. 437 The report block contents are dependent upon a series of flag bits 438 carried in the first part of the header. Not all parameters need to 439 be reported in each block. Flags indicate which parameters are 440 reported and which are not. The fields corresponding to unreported 441 parameters MUST be present, but are set to zero. The receiver MUST 442 ignore any Video Statistics Summary Report Block with a non-zero 443 value in any field flagged as unreported. 445 The Transport Streams Statistics Summary Report Block has the 446 following format: 448 0 1 2 3 449 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 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | BT=TBD |T|P| rsd. | block length | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | SSRC of source | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | begin_seq | end_seq | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | lost_frames | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | dup frames | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | partial_lost_frames | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | partial_dup_frames | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | key frames impairement proportion | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 Block type (BT): 8 bits 469 The Transport Statistics Summary Report Block is identified by the 470 constant . 472 Picture type indicator (T): 1 bits 473 Picture types used in the different video algorithms compose of 474 key-frame and derivation frame. This field is used to indicate 475 the frame type to be reported. Bits set to 0 if the lost_frames 476 field or dup_frames field contain a key_frame report or reference 477 frame report, 1 if the lost_frames field and dup_frames field 478 contain other derivation frame report. 480 P: 1 bit 481 Bit set to 1 if the partial_lost_frames field or the partial_dup_ 482 frames field contains a report, 0 otherwise. 484 Rsd.: 3 bits 485 This field is reserved for future definition. In the absence of 486 such a definition, the bits in this field MUST be set to zero and 487 MUST be ignored by the receiver. 489 Block length: 16 bits 490 The constant 5, in accordance with the definition of this field in 491 Section 3 of RFC 3611 [RFC3611]. 493 SSRC of source: 32 bits 494 As defined in Section 4.1 of RFC 3611 [RFC3611]. 496 begin_seq: 16 bits 497 As defined in Section 4.1 of RFC 3611 [RFC3611]. 499 end_seq: 16 bits 500 As defined in Section 4.1 of RFC 3611 [RFC3611]. 502 lost_frames: 32 bits 503 Number of lost_frames in the above sequence number interval. 505 dup_frames: 32 bits 506 Number of dup_frames in the above sequence number interval. 508 partial lost_frames: 32 bits 509 Number of partial lost_frames in the above sequence number 510 interval. 512 partial dup_frames: 32 bits 513 Number of partial_dup_frames in the above sequence number 514 interval. 516 key frames impairment proportion:32bits 517 The proportion of key frame impaired by packet loss,discard and 518 duplication. 520 5.2. Transport Stream Loss and Discard Metrics Block 522 This block reports Loss and Discard metrics statistics beyond the 523 information carried in the standard RTCP packet format. The block 524 reports separately on packets lost on the IP channel, and those that 525 have been received but then discarded by the receiving jitter buffer. 527 It is very useful to distinguish between packets lost by the network 528 and those discarded due to jitter. Both have equal effect on the 529 quality of the video stream, however, having separate counts helps 530 identify the source of quality degradation. These fields MUST be 531 populated, and MUST be set to zero if no packets have been received. 533 Implementations MUST provide values for all the fields defined here. 534 For certain metrics, if the value is undefined or unknown, then the 535 specified default or unknown field value MUST be provided. 537 The block is encoded as six 32-bit words: 539 0 1 2 3 540 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 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | BT=TBD |T | reserved | block length | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 | SSRC of source | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | Loss rate | Discard rate | 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 block type (BT): 8 bits 550 A Transport Stream Metrics Report Block is identified by the 551 constant . 553 Picture type indicator (T): 1 bits 554 Picture types used in the different video algorithms compose of 555 key-frame and derivation frame. This field is used to indicate 556 the picture type to be reported. Bits set to 0 if the Loss rate 557 field and discard rate field contain a Key_frame report or 558 reference frame report, 1 if the Loss rate field and discard rate 559 field contain other derivation frame reports. 561 reserved: 6 bits 562 This field is reserved for future definition. In the absence of 563 such a definition, the bits in this field MUST be set to zero and 564 MUST be ignored by the receiver. 566 block length: 16 bits 567 The constant 1, in accordance with the definition of this field in 568 Section 3 of RFC 3611 [RFC3611]. 570 SSRC of source: 32 bits 571 The SSRC of the RTP data packet source being reported upon by this 572 report block. in accordance with the definition of this field in 573 Section 3 of RFC 3611 [RFC3611]. 574 Loss rate: 8 bits 575 The fraction of RTP data packets from the source lost since the 576 beginning of reception, expressed as a fixed point number with the 577 binary point at the left edge of the field. This value is 578 calculated by dividing the total number of lost packets containing 579 specified frame (e.g., Key frame) (after the effects of applying 580 any error protection such as FEC) by the total number of packets 581 expected, multiplying the result of the division by 256, limiting 582 the maximum value to 255 (to avoid overflow), and taking the 583 integer part. The numbers of duplicated packets and discarded 584 packets do not enter into this calculation. Since receivers 585 cannot be required to maintain unlimited buffers, a receiver MAY 586 categorize late-arriving packets as lost. The degree of lateness 587 that triggers a loss SHOULD be significantly greater than that 588 which triggers a discard. 590 Discard rate: 8 bits 591 The fraction of RTP data packets from the source that have been 592 discarded since the beginning of reception, due to late or early 593 arrival, under-run or overflow at the receiving jitter buffer. 594 This value is expressed as a fixed point number with the binary 595 point at the left edge of the field. It is calculated by dividing 596 the total number of discarded packets containing specified frame 597 (e.g., Key Frame) (excluding duplicate packet discards) by the 598 total number of packets expected, multiplying the result of the 599 division by 256, limiting the maximum value to 255 (to avoid 600 overflow), and taking the integer part. 602 5.3. Transport Stream Burst Metrics Block 604 This block reports Burst metrics statistics beyond the information 605 carried in the standard RTCP packet format. It reports on the 606 combined effect of losses and discards, as both have equal effect on 607 video quality. 609 In order to properly assess the quality of a video stream, it is 610 desirable to consider the degree of burstiness of packet loss RFC 611 3357 [RFC3357]. Following the one-way loss pattern sample metrics 612 discussed in [RFC3357], a measure of the spacing between consecutive 613 network packet loss or error events, is a "loss distance". The loss 614 distance metric captures the spacing between the loss periods. The 615 duration of a loss or error event (e.g. and how many packets are lost 616 in that duration) is a "loss period", the loss period metric captures 617 the frequency and length (burstiness) of loss once it starts. Delay 618 reports include the transit delay between RTP end points and the end 619 system processing delays, both of which contribute to the user 620 perceived delay. 622 Implementations MUST provide values for all the fields defined here. 623 For certain metrics, if the value is undefined or unknown, then the 624 specified default or unknown field value MUST be provided. 626 The block is encoded as six 32-bit words: 628 0 1 2 3 629 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 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 | BT=TBD | Reserved | block length | 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 | SSRC of source | 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 | Loss Distance | Loss Period | 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 | Max Loss Duration | Reserved. | 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 block type (BT): 8 bits 641 A Transport Stream Metrics Report Block is identified by the 642 constant . 644 reserved: 8 bits 645 This field is reserved for future definition. In the absence of 646 such a definition, the bits in this field MUST be set to zero and 647 MUST be ignored by the receiver. 649 block length: 16 bits 650 The constant 2, in accordance with the definition of this field in 651 Section 3 of RFC 3611 [RFC3611]. 653 SSRC of source: 32 bits 654 The SSRC of the RTP data packet source being reported upon by this 655 report block. in accordance with the definition of this field in 656 Section 3 of RFC 3611 [RFC3611]. 658 Loss Distance: 16 bits 659 The mean duration, expressed in milliseconds, of the loss 660 intervals that have occurred since the beginning of reception 661 [DSLF]. The duration of each loss distance is calculated based 662 upon the frames that mark the beginning and end of that period. 663 It is equal to the timestamp of the end frame, plus the duration 664 of the end frame, minus the timestamp of the beginning frame. If 665 the actual values are not available, estimated values MUST be 666 used. If there have been no burst periods, the burst duration 667 value MUST be zero. 669 Loss Period: 16 bits 670 The mean duration, expressed in milliseconds, of the burst loss 671 periods that have occurred since the beginning of reception 672 [DSLF]. The duration of each period is calculated based upon the 673 frame that marks the end of the prior burst loss and the frame 674 that marks the beginning of the subsequent burst loss. It is 675 equal to the timestamp of the subsequent burst frame, minus the 676 timestamp of the prior burst packet, plus the duration of the 677 prior burst packet. If the actual values are not available, 678 estimated values MUST be used. In the case of a gap that occurs 679 at the beginning of reception, the sum of the timestamp of the 680 prior burst packet and the duration of the prior burst packet are 681 replaced by the reception start time. In the case of a gap that 682 occurs at the end of reception, the timestamp of the subsequent 683 burst packet is replaced by the reception end time. If there have 684 been no gap periods, the gap duration value MUST be zero. 686 Max Loss Duration of a single error: 16 bits 687 The maximum loss duration, expressed in milliseconds, of the loss 688 periods that have occurred since the beginning of reception. The 689 recommended max loss duration is specified as less than 16 ms in 690 [DSLF], which provides a balance between interleaver depth 691 protection from xDSL errors induced by impulse noise, delay added 692 to other applications and video service QoE requirements to reduce 693 visible impairments. 695 Reserved: 16 bits 696 All bits SHALL be set to 0 by the sender and SHALL be ignored on 697 reception. 699 block length: 16 bits 700 The constant 2, in accordance with the definition of this field in 701 Section 3 of RFC 3611 [RFC3611]. 703 5.4. Synthetical Multimedia Quality Metrics Block 705 This block reports the multimedia application performance or quality 706 metrics beyond the information carried in the standard RTCP packet 707 format. Information is recorded about multimedia application QoE 708 metric which is expressed as a MOS ("Mean Opinion Score"), MOS is on 709 a scale from 1 to 5, in which 5 represents excellent and 1 represents 710 unacceptable. MOS scores are usually obtained using subjective 711 testing or using objective algorithm to estimate the multimedia 712 quality. However Subjective testing is not suitable for measuring 713 the multimedia quality since the results may vary from test to test. 714 Therefore using objective algorithm to calculate MOS scores is 715 recommended. ITU-T recommendation [G.1082][P.NAMS][P.NBAMS] defines 716 a methodology for verifying the performance of QoE estimation 717 algorithms for video and audio. Hence this document recommends 718 vendors and implementers to use International Telecommunication Union 719 (ITU)-specified methodologies to measure parameters when possible. 721 The report block contents are dependent upon a series of flag bits 722 carried in the first part of the header. Not all parameters need to 723 be reported in each block. Flags indicate which are and which are 724 not reported. The fields corresponding to unreported parameters MUST 725 be present, but are set to zero. The receiver MUST ignore any 726 Perceptual Quality Metrics Block with a non-zero value in any field 727 flagged as unreported. 729 The Synthetical Multimedia Quality Metrics Block has the following 730 format: 732 0 1 2 3 733 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 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 | BT=TBD |I| MC | Rsd.| block length | 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 | SSRC of source | 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 | MOS Value | 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 Block type (BT): 8 bits 743 The Perceptual Quality Metrics Block is identified by the constant 744 . 746 Interval Metric flag (I): 1 bit 747 This field is used to indicate whether the Basic Loss/Discard 748 metrics are Interval or Cumulative metrics, that is, whether the 749 reported values applies to the most recent measurement interval 750 duration between successive metrics reports (I=1) (the Interval 751 Duration) or to the accumulation period characteristic of 752 cumulative measurements (I=0) (the Cumulative Duration). 754 MoS Class (MC): 4 bits 755 This field is used to indicate the MOS type to be reported. The 756 MOS type is defined as follows: 757 0000 MOS-A - Audio Quality MOS [G.107][P.564]. 758 0001 MOS-V - Video Quality MOS [P.NAMS][P.NBAMS]. 759 0010 MOS-AV - Audio-Video Quality MOS[P.NAMS][P.NBAMS]. 760 0100~1111 - Reserved 762 Rsd.: 7 bits 763 This field is reserved for future definition. In the absence of 764 such a definition, the bits in this field MUST be set to zero and 765 MUST be ignored by the receiver. 767 SSRC of source: 32 bits 768 As defined in Section 4.1 of [RFC3611]. 770 MOS Value: Variable Length 772 The estimated mean opinion score for Audio Qulity, Video Quality 773 or Audio-Video quality is defined as including the effects of 774 delay and other effects that would affect Audio-Video quality 775 [G.1082][P.NAMS][P.NBAMS]. It is expressed as an integer in the 776 range 10 to 50, corresponding to MOS x 10, as for MOS. A value of 777 127 indicates that this parameter is unavailable. Values other 778 than 127 and the valid range defined above MUST NOT be sent and 779 MUST be ignored by the receiving system. 781 6. SDP Signaling 783 Six new parameters are defined for the six report blocks defined in 784 this document to be used with Session Description Protocol (SDP) 785 [RFC4566] using the Augmented Backus-Naur Form (ABNF) [RFC5234]. 786 They have the following syntax within the "rtcp-xr" attribute 787 [RFC3611]: 789 rtcp-xr-attrib = "a=rtcp-xr:" 790 [xr-format *(SP xr-format)] CRLF 792 xr-format = RTP-flows-init-syn 793 / RTP-flows-general-syn 794 / multimedia-quality-metrics 795 / transport-stream-loss-metrics 796 / transport-stream-burst-metrics 797 / transport-stat-summary 798 / layered-stream-stat-metrics 800 RTP-flows-init-syn = "RTP-flows-init-syn" 801 ["=" max-size] 802 max-size = 1*DIGIT ; maximum block size in octets 804 RTP-flow-general-syn = "RTP-flows-general-syn" 805 ["=" max-size] 806 max-size = 1*DIGIT ; maximum block size in octets 808 transport-stream-burst-metrics = "transport-stream-burst-metrics" 809 ["=" max-size] 810 max-size = 1*DIGIT ; maximum block size in octets 812 transport-stream-loss-metrics = "transport-stream-loss-metrics" 813 ["=" stat-flag *("," stat-flag)] 814 stat-flag = "key Frame loss and duplication" 815 / "derivation Frame loss and duplication" 817 transport-stream-stat-summary = "transport-stream-stat-summary" 818 ["=" stat-flag *("," stat-flag)] 819 stat-flag = "key Frame loss and duplication" 820 / "derivation Frame loss and duplication" 822 layered-stream-stat-metrics = "layered-stream-stat-metrics" 823 ["=" stat-flag *("," stat-flag)] 824 stat-flag = "base layer packet" 825 / "enhancment layer packet" 827 multimedia-quality-metrics = "multimedia-quality-metrics" 828 ["=" stat-flag *("," stat-flag)] 829 stat-flag = "Interval Metrics" 830 /"Cumulative metrics" 832 Refer to Section 5.1 of RFC 3611 [RFC3611] for a detailed description 833 and the full syntax of the "rtcp-xr" attribute. 835 7. IANA Considerations 837 New report block types for RTCP XR are subject to IANA registration. 838 For general guidelines on IANA allocations for RTCP XR, refer to 839 Section 6.2 of [RFC3611]. 841 This document assigns six new block type values in the RTCP XR Block 842 Type Registry: 844 Name: RFISD 845 Long Name: RTP Flows Initial Synchronization Delay 846 Value 847 Reference: Section 4.1 849 Name: RFGSO 850 Long Name: RTP Flows General Synchronization Offset Metrics Block 851 Value 852 Reference: Section 4.2 854 Name: TSSS 855 Long Name: Transport Stream Statistics Summary 856 Value 857 Reference: Section 5.1 859 Name: LSSM 860 Value 861 Long Name: Layered Stream Statistics Metrics 862 Reference: Section 4.3 864 Name: TSLDM 865 Long Name: Transport Stream Loss and Discard Metrics 866 Value 867 Reference: Section 5.2 869 Name: TSBM 870 Long Name: Transport Stream Burst Metrics 871 Value 872 Reference: Section 5.3 874 Name: SMQM 875 Long Name: Synthetical Multimedia Quality Metric 876 Value 877 Reference: Section 5.4 879 This document also registers seven SDP [RFC4566] parameters for the 880 "rtcp-xr" attribute in the RTCP XR SDP Parameters Registry: 882 * "RTP-flows-init-syn" 883 * "RTP-flows-general-syn" 884 * "multimedia-quality-metrics" 885 * "transport-stream-loss-metrics" 886 * "transport-stream-burst-metrics" 887 * "transport-stat-summary" 888 * "layered-stream-stat-metrics" 890 The contact information for the registrations is: 892 Qin Wu 893 sunseawq@huawei.com 894 101 Software Avenue, Yuhua District 895 Nanjing, JiangSu 210012 China 897 8. Security Considerations 899 The new RTCP XR report blocks proposed in this document introduces no 900 new security considerations beyond those described in [RFC3611]. 902 9. Acknowledgements 904 The authors would like to thank Bill Ver Steeg, David R Oran, Ali 905 Begen,Colin Perkins, Roni Even,Youqing Yang, Wenxiao Yu and Yinliang 906 Hu for their valuable comments and suggestions on this document. 908 10. References 910 10.1. Normative References 912 [I-D.ietf-avt-rtp-svc] 913 Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis, 914 "RTP Payload Format for Scalable Video Coding", 915 draft-ietf-avt-rtp-svc-27 (work in progress), 916 February 2011. 918 [ISO-IEC.13818-1.2007] 919 International Organization for Standardization, 920 "Information technology - Generic coding of moving 921 pictures and associated audio information: Systems", 922 ISO International Standard 13818-1, October 2007. 924 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 925 Requirement Levels", BCP 14, RFC 2119, March 1997. 927 [RFC2250] Hoffman, D., Fernando, G., Goyal, V., and M. Civanlar, 928 "RTP Payload Format for MPEG1/MPEG2 Video", RFC 2250, 929 January 1998. 931 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 932 Jacobson, "RTP: A Transport Protocol for Real-Time 933 Applications", STD 64, RFC 3550, July 2003. 935 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 936 Protocol Extended Reports (RTCP XR)", RFC 3611, 937 November 2003. 939 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 940 Description Protocol", RFC 4566, July 2006. 942 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 943 Specifications: ABNF", STD 68, RFC 5234, January 2008. 945 [RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP 946 Flows", RFC 6051, November 2010. 948 10.2. Informative References 950 [DSLF] Rahrer, T., Ed., Fiandra, Ed., and Wright, Ed., "Triple- 951 play Services Quality of Experience (QoE) Requirements", 952 DSL Forum Technical Report TR-126, December 2006. 954 [G.107] ITU-T, "The E Model, a computational model for use in 955 transmission planning", ITU-T Recommendation G.107, 956 April 2009. 958 [G.1082] ITU-T, "Measurement-based methods for improving the 959 robustness of IPTV performance", ITU-T 960 Recommendation G.1082, April 2009. 962 [I-D.ietf-pmol-metrics-framework-02] 963 Clark, A., "Framework for Performance Metric Development". 965 [IEEE] IEEE, "Human Perception of Jitter and Media 966 Synchronization", IEEE Journal on Selected Areas in 967 Communications Vol. 14, No. 1, January 1996. 969 [P.564] ITU-T, "Conformance testing for narrowband Voice over IP 970 transmission quality assessment models", ITU-T 971 Recommendation P.564, July 2006. 973 [P.NAMS] ITU-T, "Non-intrusive parametric model for the Assessment 974 of performance of Multimedia Streaming", ITU-T 975 Recommendation P.NAMS, November 2009. 977 [P.NBAMS] ITU-T, "non-intrusive bit-stream model for assessment of 978 performance of multimedia streaming", ITU-T 979 Recommendation P.NBAMS, November 2009. 981 [RFC3357] Koodli, R. and R. Ravikanth, "One-way Loss Pattern Sample 982 Metrics", RFC 3357, August 2002. 984 Authors' Addresses 986 Qin Wu 987 Huawei 988 101 Software Avenue, Yuhua District 989 Nanjing, Jiangsu 210012 990 China 992 Email: sunseawq@huawei.com 994 Glen Zorn 995 Network Zen 996 77/440 Soi Phoomjit, Rama IV Road 997 Phra Khanong, Khlong Toie 998 Bangkok 10110 999 Thailand 1001 Phone: +66 (0) 87 502 4274 1002 Email: gwz@net-zen.net 1004 Roland Schott 1005 Deutsche Telekom Laboratories 1006 Deutsche-Telekom-Allee 7 1007 Darmstadt 64295 1008 Germany 1010 Email: Roland.Schott@telekom.de