idnits 2.17.1 draft-wu-xrblock-rtcp-xr-quality-monitoring-00.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 (February 10, 2011) is 4823 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 898, but no explicit reference was found in the text == Unused Reference: 'IEEE' is defined on line 926, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-avt-rapid-rtp-sync-12 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) Summary: 1 error (**), 0 flaws (~~), 5 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: August 14, 2011 Network Zen 6 R. Schott 7 Deutsche Telekom Laboratories 8 February 10, 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-00 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 August 14, 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 . . . . . . . . . . . . . . . . . . 9 77 5.1. Transport Streams Statistics Summary Report Block . . . . 9 78 5.2. Transport Stream Loss and Discard Metrics Block . . . . . 11 79 5.3. Transport Stream Burst Metrics Block . . . . . . . . . . . 13 80 5.4. Synthetical Application Quality Metrics Block . . . . . . 15 81 6. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 17 82 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 83 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 84 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 85 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 86 10.1. Normative References . . . . . . . . . . . . . . . . . . . 20 87 10.2. Informative References . . . . . . . . . . . . . . . . . . 21 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 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, since offering 98 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 video across a network, the 128 video quality Metrics is highly required which can be conveyed in the 129 RTCP XR packets[RFC3611] and may have the following three benefits: 131 * Tuning the audio and video encoder algorithm to satisfy real 132 time data quality requirements 133 * Determining which system techniques to use in a given situation 134 and when to switch from one technique to another as system 135 parameters change 137 * Verifying the continued correct operation of an existing system 139 RFC 3611 [RFC3611] defines seven report block formats for network 140 management and quality monitoring. However, there are no block types 141 specifically designed for conveying real time application quality 142 metrics. This document focuses on specifying new report block types 143 used to convey real time application quality metrics. 145 The report block types defined in this document fall into two 146 categories. The first category consists of general information 147 regarding transmission quality, to be generated and processed by the 148 RTP transport. The report blocks in the second category convey 149 metrics above transport that affect real time application quality and 150 are sensitivity to network errors. 152 Seven report block formats are defined by this document. Of these, 153 three are transport layer metrics: 155 * RTP Flows Initial Synchronization Delay Report Block 156 * RTP Flows General Synchronization Offset Metrics Block 157 * Layered Streams Statistics Metrics Block 159 The other four are application layer metrics: 161 * Transport Stream Statistics Summary Report Block 162 * Transport Stream Loss and Discard Metrics Block 163 * Transport Stream Burst Metrics Block 164 * Synthetical Application Quality Metrics Block 166 2. Terminology 168 2.1. Standards Language 170 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 171 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 172 document are to be interpreted as described in RFC 2119 [RFC2119]. 174 In addition, the following terms are defined: 176 Layered Component Packet 178 a RTP packet using layered codecs containing the specified layered 179 component, e.g., encoded stream at the base layer or at the 180 enhancement layer. 182 Picture Type 184 Picture types used in the different video algorithms compose of 185 the key-frame and the Derivation frame. Key-frame is also called 186 as reference frame and used as a reference for predicting other 187 pictures. It is coded without prediction from other pictures. 188 The Derivation frame is derived from Key-frame using prediction 189 from the reference frame. 191 2.2. Acronyms 193 SSRC 194 Synchronization Source [RFC3550] 196 TS 197 Transport Stream [ISO-IEC.13818-1.2007] 199 3. Applicability 201 All the report blocks defined in this document could be used by 202 dedicated network monitoring applications. As specified in RFC 3611 203 [RFC3611], for such an application it might be appropriate to allow 204 more than 5% of RTP data bandwidth to be used for RTCP packets, thus 205 allowing proportionately larger and more detailed report blocks. 207 RTP Flows General Synchronization Delay Metrics BlockSection 4.2 has 208 been defined for various multimedia applications. Such applications 209 can use this report block to monitor offset between two RTP streams 210 synchronization to ensure satisfactory QoE. Tighter tolerances than 211 typically used have been recommended for such applications. 213 The Flows Synchronization Delay Report Block has been defined 214 primarily for layered or multi-description video coding applications. 215 When joining a layered video session in such an application, a 216 receiver may not synchronize playout across the multimedia session 217 until RTCP SR packets have been received on all of the component RTP 218 sessions. This report block can be used to ensure synchronization 219 between different media layers for the same multimedia session. 221 The Video Stream Loss and Discard Metrics Report Block, Video Stream 222 Burst Metrics report Block, Video Statistics Summary Report Block and 223 Layered Video Statistics Metrics Block can be applied to any real 224 time video application, while Synthetical Multimedia Quality Metrics 225 Report Block can be used in any real-time AV application . 227 4. Transport Layer Metrics 229 4.1. RTP Flows Initial Synchronization Delay Report Block 231 This block reports the initial synchronization delay between RTP 232 sessions of the same media stream sent using Multi-Session 233 Transmission [I-D.ietf-avt-rtp-svc] or the initial synchronization 234 delay betwen RTP session of the different media types 235 [I-D.ietf-avt-rapid-rtp-sync], which is beyond the information 236 carried in the standard RTCP packet format. Information is recorded 237 about session bandwidth and synchronization delay. 239 The RTP Flows Intial Synchronization Delay Report Block has the 240 following format: 242 0 1 2 3 243 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 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | BT=TBD | Reserved | Block length | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | SSRC of Sender | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | Initial Synchronization Delay | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 Block type (BT): 8 bits 253 The Statistics Summary Report Block is identified by the constant 254 . 256 Reserved: 8 bits 257 This field is reserved for future definition. In the absence of 258 such a definition, the bits in this field MUST be set to zero and 259 MUST be ignored by the receiver. 261 Block length: 16 bits 262 The constant 3, in accordance with the definition of this field in 263 Section 3 of RFC 3611 [RFC3611]. 265 SSRC of Sender: 32 bits 266 The SSRC of the RTP data packet source being reported upon by this 267 report block. (Section 4.1 of [RFC3611]). 269 Initial Synchronization Delay: 32 bits 270 The average delay, expressed in units of 1/65536 seconds, between 271 the RTCP packets received on all of the components RTP sessions 272 and the beginning of session [I-D.ietf-avt-rapid-rtp-sync]. The 273 value is calculated as follows: 275 The average time, expressed in units of 1/65536 seconds, taken 276 to receive the first RTCP packet in the RTP session with the 277 longest RTCP reporting interval [I-D.ietf-avt-rapid-rtp-sync] 279 4.2. RTP Flows General Synchronization Offset Metrics Block 281 In an RTP multimedia session, there can be an arbitrary number of 282 streams, with the same RTCP CNAME. This block reports the general 283 Synchronization offset requirements of these RTP streams beyond the 284 information carried in the standard RTCP packet format. Information 285 is recorded about the synchronization offset time of each RTP stream 286 relative to the reference RTP stream with the same CNAME and General 287 Synchronisation Offset of zero. The RTP Flow General Synchronization 288 Offset Report Block has the following format: 290 0 1 2 3 291 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 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | BT=TBD |I| Reserved | Block length | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | SSRC of source | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | General Synchronization Offset | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 Block type (BT): 8 bits 301 The Statistics Summary Report Block is identified by the constant 302 . 304 Interval Metric flag (I): 1 bit 306 This field is used to indicate whether the Audio-Video 307 synchronization metrics are Interval or Cumulative metrics, that 308 is, whether the reported values applies to the most recent 309 measurement interval duration between successive metrics reports 310 (I=1) (the Interval Duration) or to the accumulation period 311 characteristic of cumulative measurements (I=0) (the Cumulative 312 Duration). 314 Reserved: 8 bits 315 This field is reserved for future definition. In the absence of 316 such a definition, the bits in this field MUST be set to zero and 317 MUST be ignored by the receiver. 319 Block length: 16 bits 320 The constant 2, in accordance with the definition of this field in 321 Section 3 of RFC 3611 [RFC3611]. 323 SSRC of source: 32 bits 324 As defined in Section 4.1 of RFC 3611 [RFC3611]. 326 General synchronization offset: 32 bits 327 This field indicates the synchronization offset time of one RTP 328 stream in milliseconds relative to the reference RTP stream with 329 the same CNAME and General Synchronisation Offset of zero 330 [I-D.ietf-avt-rapid-rtp-sync] This value is calculated based on 331 the interarrival time between arbitray RTP packet and the 332 reference RTP packet with the same CNAME , and timestamps of this 333 arbitray RTP packet and the reference RTP packet with the same 334 CNAME. 336 4.3. Layered Streams Statistics Metrics Block 338 This block reports layered streams statistics beyond the information 339 carried in the Statistics Summary Report Block RTCP packet specified 340 in the section 4.6 of RFC 3611 [RFC3611]. Information is recorded 341 about lost layered component packets, duplicated layered component 342 packets. Such information can be useful for network management and 343 video quality monitoring. 345 The report block contents are dependent upon a series of flag bits 346 carried in the first part of the header. Not all parameters need to 347 be reported in each block. Flags indicate which parameters are 348 reported and which are not. The fields corresponding to unreported 349 parameters MUST be present, but are set to zero. The receiver MUST 350 ignore any Layered Streams Statistics Metrics Block with a non-zero 351 value in any field flagged as unreported. 353 The Layered Stream Statistics metrics Block has the following format: 355 0 1 2 3 356 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 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | BT=TBD |T| rsd. | block length | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | SSRC of source | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | begin_seq | end_seq | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | Lost_Layered Component Packets | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Dup Layered Component_Packets | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 Block type (BT): 8 bits 370 The Layered stream Statistics Metrics Block is identified by the 371 constant . 373 Layer Type flag (T): 1 bits 374 This field is used to indicate the Layer Type of layered video to 375 be reported. LT is set to 0 if the loss_component_packet field 376 and dup_component packet contain the base layer packet in layered 377 codecs,e.g, SVC in [I-D.ietf-avt-rtp-svc], 1 if the loss_component 378 packet field and dup_component packet contain enhancement layer 379 packet in layered codec. 381 Rsd.: 3 bits 382 This field is reserved for future definition. In the absence of 383 such a definition, the bits in this field MUST be set to zero and 384 MUST be ignored by the receiver. 386 Block length: 16 bits 387 The constant 3, in accordance with the definition of this field in 388 Section 3 of RFC 3611 [RFC3611]. 390 SSRC of source: 32 bits 391 As defined in Section 4.1 of RFC 3611 [RFC3611]. 393 begin_seq: 16 bits 394 As defined in Section 4.1 of RFC 3611 [RFC3611]. 396 end_seq: 16 bits 397 As defined in Section 4.1 of RFC 3611 [RFC3611]. 399 Lost_Layered Component Packets: 32 bits 400 Number of lost_component packets in the above sequence number 401 interval. 403 Dup_Layered Component Packets: 32 bits 404 Number of dup_component packets in the above sequence number 405 interval. 407 5. Application Layer Metrics 409 5.1. Transport Streams Statistics Summary Report Block 411 This block reports statistics beyond the information carried in the 412 Statistics Summary Report Block RTCP packet specified in the section 413 4.6 of RFC 3611 [RFC3611]. Information is recorded about lost frame 414 packets, duplicated frame packets, lost layered component packets, 415 duplicated layered component packets. Such information can be useful 416 for network management and video quality monitoring. 418 The report block contents are dependent upon a series of flag bits 419 carried in the first part of the header. Not all parameters need to 420 be reported in each block. Flags indicate which parameters are 421 reported and which are not. The fields corresponding to unreported 422 parameters MUST be present, but are set to zero. The receiver MUST 423 ignore any Video Statistics Summary Report Block with a non-zero 424 value in any field flagged as unreported. 426 The Transport Streams Statistics Summary Report Block has the 427 following format: 429 0 1 2 3 430 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 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | BT=TBD |T|P| rsd. | block length | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | SSRC of source | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | begin_seq | end_seq | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | lost_frames | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | dup frames | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | partial_lost_frames | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | partial_dup_frames | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | key frames impairement proportion | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 Block type (BT): 8 bits 450 The Video Statistics Summary Report Block is identified by the 451 constant . 453 Picture type indicator (T): 1 bits 454 Picture types used in the different video algorithms compose of 455 key-frame and derivation frame. This field is used to indicate 456 the frame type to be reported. Bits set to 0 if the lost_frames 457 field or dup_frames field contain a key_frame report or reference 458 frame report, 1 if the lost_frames field and dup_frames field 459 contain other derivation frame report. 461 P: 1 bit 462 Bit set to 1 if the partial_lost_frames field or the partial_dup_ 463 frames field contains a report, 0 otherwise. 465 Rsd.: 3 bits 466 This field is reserved for future definition. In the absence of 467 such a definition, the bits in this field MUST be set to zero and 468 MUST be ignored by the receiver. 470 Block length: 16 bits 471 The constant 5, in accordance with the definition of this field in 472 Section 3 of RFC 3611 [RFC3611]. 474 SSRC of source: 32 bits 475 As defined in Section 4.1 of RFC 3611 [RFC3611]. 477 begin_seq: 16 bits 478 As defined in Section 4.1 of RFC 3611 [RFC3611]. 480 end_seq: 16 bits 481 As defined in Section 4.1 of RFC 3611 [RFC3611]. 483 lost_frames: 32 bits 484 Number of lost_frames in the above sequence number interval. 486 dup_frames: 32 bits 487 Number of dup_frames in the above sequence number interval. 489 partial lost_frames: 32 bits 490 Number of partial lost_frames in the above sequence number 491 interval. 493 partial dup_frames: 32 bits 494 Number of partial_dup_frames in the above sequence number 495 interval. 497 key frames impairment proportion:32bits 498 The proportion of key frame impaired by packet loss,discard and 499 duplication. 501 5.2. Transport Stream Loss and Discard Metrics Block 503 This block reports Loss and Discard metrics statistics beyond the 504 information carried in the standard RTCP packet format. The block 505 reports separately on packets lost on the IP channel, and those that 506 have been received but then discarded by the receiving jitter buffer. 508 It is very useful to distinguish between packets lost by the network 509 and those discarded due to jitter. Both have equal effect on the 510 quality of the video stream, however, having separate counts helps 511 identify the source of quality degradation. These fields MUST be 512 populated, and MUST be set to zero if no packets have been received. 514 Implementations MUST provide values for all the fields defined here. 515 For certain metrics, if the value is undefined or unknown, then the 516 specified default or unknown field value MUST be provided. 518 The block is encoded as six 32-bit words: 520 0 1 2 3 521 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 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | BT=TBD |T | reserved | block length | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | SSRC of source | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | Loss rate | Discard rate | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 block type (BT): 8 bits 531 A Video Stream Metrics Report Block is identified by the constant 532 . 534 Picture type indicator (T): 1 bits 535 Picture types used in the different video algorithms compose of 536 key-frame and derivation frame. This field is used to indicate 537 the picture type to be reported. Bits set to 0 if the Loss rate 538 field and discard rate field contain a Key_frame report or 539 reference frame report, 1 if the Loss rate field and discard rate 540 field contain other derivation frame reports. 542 reserved: 6 bits 543 This field is reserved for future definition. In the absence of 544 such a definition, the bits in this field MUST be set to zero and 545 MUST be ignored by the receiver. 547 block length: 16 bits 548 The constant 1, in accordance with the definition of this field in 549 Section 3 of RFC 3611 [RFC3611]. 551 SSRC of source: 32 bits 552 The SSRC of the RTP data packet source being reported upon by this 553 report block. in accordance with the definition of this field in 554 Section 3 of RFC 3611 [RFC3611]. 556 Loss rate: 8 bits 557 The fraction of RTP data packets from the source lost since the 558 beginning of reception, expressed as a fixed point number with the 559 binary point at the left edge of the field. This value is 560 calculated by dividing the total number of lost packets containing 561 specified frame (e.g., Key frame) (after the effects of applying 562 any error protection such as FEC) by the total number of packets 563 expected, multiplying the result of the division by 256, limiting 564 the maximum value to 255 (to avoid overflow), and taking the 565 integer part. The numbers of duplicated packets and discarded 566 packets do not enter into this calculation. Since receivers 567 cannot be required to maintain unlimited buffers, a receiver MAY 568 categorize late-arriving packets as lost. The degree of lateness 569 that triggers a loss SHOULD be significantly greater than that 570 which triggers a discard. 572 Discard rate: 8 bits 573 The fraction of RTP data packets from the source that have been 574 discarded since the beginning of reception, due to late or early 575 arrival, under-run or overflow at the receiving jitter buffer. 576 This value is expressed as a fixed point number with the binary 577 point at the left edge of the field. It is calculated by dividing 578 the total number of discarded packets containing specified frame 579 (e.g., Key Frame) (excluding duplicate packet discards) by the 580 total number of packets expected, multiplying the result of the 581 division by 256, limiting the maximum value to 255 (to avoid 582 overflow), and taking the integer part. 584 5.3. Transport Stream Burst Metrics Block 586 This block reports Burst metrics statistics beyond the information 587 carried in the standard RTCP packet format. It reports on the 588 combined effect of losses and discards, as both have equal effect on 589 video quality. 591 In order to properly assess the quality of a video stream, it is 592 desirable to consider the degree of burstiness of packet loss RFC 593 3357 [RFC3357]. Following the one-way loss pattern sample metrics 594 discussed in [RFC3357], a measure of the spacing between consecutive 595 network packet loss or error events, is a "loss distance". The loss 596 distance metric captures the spacing between the loss periods. The 597 duration of a loss or error event (e.g. and how many packets are lost 598 in that duration) is a "loss period", the loss period metric captures 599 the frequency and length (burstiness) of loss once it starts. Delay 600 reports include the transit delay between RTP end points and the end 601 system processing delays, both of which contribute to the user 602 perceived delay. 604 Implementations MUST provide values for all the fields defined here. 605 For certain metrics, if the value is undefined or unknown, then the 606 specified default or unknown field value MUST be provided. 608 The block is encoded as six 32-bit words: 610 0 1 2 3 611 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 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | BT=TBD | Reserved | block length | 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 | SSRC of source | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 | Loss Distance | Loss Period | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 | Max Loss Duration | Reserved. | 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 block type (BT): 8 bits 623 A Video Stream Metrics Report Block is identified by the constant 624 . 626 reserved: 8 bits 627 This field is reserved for future definition. In the absence of 628 such a definition, the bits in this field MUST be set to zero and 629 MUST be ignored by the receiver. 631 block length: 16 bits 632 The constant 2, in accordance with the definition of this field in 633 Section 3 of RFC 3611 [RFC3611]. 635 SSRC of source: 32 bits 636 The SSRC of the RTP data packet source being reported upon by this 637 report block. in accordance with the definition of this field in 638 Section 3 of RFC 3611 [RFC3611]. 640 Loss Distance: 16 bits 641 The mean duration, expressed in milliseconds, of the loss 642 intervals that have occurred since the beginning of reception 643 [DSLF]. The duration of each loss distance is calculated based 644 upon the frames that mark the beginning and end of that period. 645 It is equal to the timestamp of the end frame, plus the duration 646 of the end frame, minus the timestamp of the beginning frame. If 647 the actual values are not available, estimated values MUST be 648 used. If there have been no burst periods, the burst duration 649 value MUST be zero. 651 Loss Period: 16 bits 652 The mean duration, expressed in milliseconds, of the burst loss 653 periods that have occurred since the beginning of reception 654 [DSLF]. The duration of each period is calculated based upon the 655 frame that marks the end of the prior burst loss and the frame 656 that marks the beginning of the subsequent burst loss. It is 657 equal to the timestamp of the subsequent burst frame, minus the 658 timestamp of the prior burst packet, plus the duration of the 659 prior burst packet. If the actual values are not available, 660 estimated values MUST be used. In the case of a gap that occurs 661 at the beginning of reception, the sum of the timestamp of the 662 prior burst packet and the duration of the prior burst packet are 663 replaced by the reception start time. In the case of a gap that 664 occurs at the end of reception, the timestamp of the subsequent 665 burst packet is replaced by the reception end time. If there have 666 been no gap periods, the gap duration value MUST be zero. 668 Max Loss Duration of a single error: 16 bits 669 The maximum loss duration, expressed in milliseconds, of the loss 670 periods that have occurred since the beginning of reception. The 671 recommended max loss duration is specified as less than 16 ms in 672 [DSLF], which provides a balance between interleaver depth 673 protection from xDSL errors induced by impulse noise, delay added 674 to other applications and video service QoE requirements to reduce 675 visible impairments. 677 Reserved: 16 bits 678 All bits SHALL be set to 0 by the sender and SHALL be ignored on 679 reception. 681 block length: 16 bits 682 The constant 2, in accordance with the definition of this field in 683 Section 3 of RFC 3611 [RFC3611]. 685 5.4. Synthetical Application Quality Metrics Block 687 This block reports the multimedia quality metrics beyond the 688 information carried in the standard RTCP packet format. Information 689 is recorded about Video MOS, Audio MOS, Audio Video MOS, Video 690 Service Transmission Quality [G.1082][P.NAMS]. 692 The report block contents are dependent upon a series of flag bits 693 carried in the first part of the header. Not all parameters need to 694 be reported in each block. Flags indicate which are and which are 695 not reported. The fields corresponding to unreported parameters MUST 696 be present, but are set to zero. The receiver MUST ignore any 697 Perceptual Quality Metrics Block with a non-zero value in any field 698 flagged as unreported. 700 The Synthetical Multimedia Quality Metrics Block has the following 701 format: 703 0 1 2 3 704 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 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 | BT=TBD |I| |Rsd. | block length | 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 | SSRC of source | 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 | MOS-AV | Rsvd. | 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 Block type (BT): 8 bits 714 The Perceptual Quality Metrics Block is identified by the constant 715 . 717 Interval Metric flag (I): 1 bit 718 This field is used to indicate whether the Basic Loss/Discard 719 metrics are Interval or Cumulative metrics, that is, whether the 720 reported values applies to the most recent measurement interval 721 duration between successive metrics reports (I=1) (the Interval 722 Duration) or to the accumulation period characteristic of 723 cumulative measurements (I=0) (the Cumulative Duration). 725 Rsd.: 3 bits 726 This field is reserved for future definition. In the absence of 727 such a definition, the bits in this field MUST be set to zero and 728 MUST be ignored by the receiver. 730 SSRC of source: 32 bits 731 As defined in Section 4.1 of [RFC3611]. 733 MOS-AV: 16 bits 735 The estimated mean opinion score for Audio-Video quality (MOS-AV) 736 is defined as including the effects of delay and other effects 737 that would affect Audio-Video quality [G.1082][P.NAMS]. It is 738 expressed as an integer in the range 10 to 50, corresponding to 739 MOS x 10, as for MOS-AV. A value of 127 indicates that this 740 parameter is unavailable. Values other than 127 and the valid 741 range defined above MUST NOT be sent and MUST be ignored by the 742 receiving system. 744 Reserved: 16 bits 745 This field is reserved for future definition. In the absence of 746 such a definition, the bits in this field MUST be set to zero and 747 MUST be ignored by the receiver. 749 6. SDP Signaling 751 Six new parameters are defined for the six report blocks defined in 752 this document to be used with Session Description Protocol (SDP) 753 [RFC4566] using the Augmented Backus-Naur Form (ABNF) [RFC5234]. 754 They have the following syntax within the "rtcp-xr" attribute 755 [RFC3611]: 757 rtcp-xr-attrib = "a=rtcp-xr:" 758 [xr-format *(SP xr-format)] CRLF 760 xr-format = RTP-flows-init-syn 761 / RTP-flows-general-syn 762 / application-quality-metrics 763 / transport-stream-loss-metrics 764 / transport-stream-burst-metrics 765 / transport-stat-summary 766 / layered-stream-stat-metrics 768 RTP-flows-init-syn = "RTP-flows-init-syn" 769 ["=" max-size] 770 max-size = 1*DIGIT ; maximum block size in octets 772 RTP-flow-general-syn = "RTP-flows-general-syn" 773 ["=" max-size] 774 max-size = 1*DIGIT ; maximum block size in octets 776 transport-stream-burst-metrics = "transport-stream-burst-metrics" 777 ["=" max-size] 778 max-size = 1*DIGIT ; maximum block size in octets 780 transport-stream-loss-metrics = "transport-stream-loss-metrics" 781 ["=" stat-flag *("," stat-flag)] 782 stat-flag = "key Frame loss and duplication" 783 / "derivation Frame loss and duplication" 785 transport-stream-stat-summary = "transport-stream-stat-summary" 786 ["=" stat-flag *("," stat-flag)] 787 stat-flag = "key Frame loss and duplication" 788 / "derivation Frame loss and duplication" 790 layered-stream-stat-metrics = "layered-stream-stat-metrics" 791 ["=" stat-flag *("," stat-flag)] 792 stat-flag = "base layer packet" 793 / "enhancment layer packet" 795 application-quality-metrics = "application-quality-metrics" 796 ["=" stat-flag *("," stat-flag)] 797 stat-flag = "Interval Metric" 799 Refer to Section 5.1 of RFC 3611 [RFC3611] for a detailed description 800 and the full syntax of the "rtcp-xr" attribute. 802 7. IANA Considerations 804 New report block types for RTCP XR are subject to IANA registration. 805 For general guidelines on IANA allocations for RTCP XR, refer to 806 Section 6.2 of [RFC3611]. 808 This document assigns six new block type values in the RTCP XR Block 809 Type Registry: 811 Name: RFISD 812 Long Name: RTP Flows Initial Synchronization Delay 813 Value 814 Reference: Section 4.1 816 Name: RFGSO 817 Long Name: RTP Flows General Synchronization Offset Metrics Block 818 Value 819 Reference: Section 4.2 821 Name: TSSS 822 Long Name: Transport Stream Statistics Summary 823 Value 824 Reference: Section 5.1 826 Name: LSSM 827 Value 828 Long Name: Layered Stream Statistics Metrics 829 Reference: Section 4.3 831 Name: TSLDM 832 Long Name: Transport Stream Loss and Discard Metrics 833 Value 834 Reference: Section 5.2 836 Name: TSBM 837 Long Name: Transport Stream Burst Metrics 838 Value 839 Reference: Section 5.3 841 Name: SAQM 842 Long Name: Synthetical Application Quality Metric 843 Value 844 Reference: Section 5.4 846 This document also registers seven SDP [RFC4566] parameters for the 847 "rtcp-xr" attribute in the RTCP XR SDP Parameters Registry: 849 * "RTP-flows-init-syn" 850 * "RTP-flows-general-syn" 851 * "application-quality-metrics" 852 * "transport-stream-loss-metrics" 853 * "transport-stream-burst-metrics" 854 * "transport-stat-summary" 855 * "layered-stream-stat-metrics" 857 The contact information for the registrations is: 859 Qin Wu 860 sunseawq@huawei.com 861 101 Software Avenue, Yuhua District 862 Nanjing, JiangSu 210012 China 864 8. Security Considerations 866 TBC 868 9. Acknowledgements 870 The authors would like to thank Bill Ver Steeg, David R Oran, Ali 871 Begen,Colin Perkins, Roni Even,Youqing Yang, Wenxiao Yu and Yinliang 872 Hu for their valuable comments and suggestions on this document. 874 10. References 876 10.1. Normative References 878 [I-D.ietf-avt-rapid-rtp-sync] 879 Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP 880 Flows", draft-ietf-avt-rapid-rtp-sync-12 (work in 881 progress), November 2010. 883 [I-D.ietf-avt-rtp-svc] 884 Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis, 885 "RTP Payload Format for Scalable Video Coding", 886 draft-ietf-avt-rtp-svc-27 (work in progress), 887 February 2011. 889 [ISO-IEC.13818-1.2007] 890 International Organization for Standardization, 891 "Information technology - Generic coding of moving 892 pictures and associated audio information: Systems", 893 ISO International Standard 13818-1, October 2007. 895 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 896 Requirement Levels", BCP 14, RFC 2119, March 1997. 898 [RFC2250] Hoffman, D., Fernando, G., Goyal, V., and M. Civanlar, 899 "RTP Payload Format for MPEG1/MPEG2 Video", RFC 2250, 900 January 1998. 902 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 903 Jacobson, "RTP: A Transport Protocol for Real-Time 904 Applications", STD 64, RFC 3550, July 2003. 906 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 907 Protocol Extended Reports (RTCP XR)", RFC 3611, 908 November 2003. 910 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 911 Description Protocol", RFC 4566, July 2006. 913 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 914 Specifications: ABNF", STD 68, RFC 5234, January 2008. 916 10.2. Informative References 918 [DSLF] Rahrer, T., Ed., Fiandra, Ed., and Wright, Ed., "Triple- 919 play Services Quality of Experience (QoE) Requirements", 920 DSL Forum Technical Report TR-126, December 2006. 922 [G.1082] ITU-T, "Measurement-based methods for improving the 923 robustness of IPTV performance", ITU-T 924 Recommendation G.1082, April 2009. 926 [IEEE] IEEE, "Human Perception of Jitter and Media 927 Synchronization", IEEE Journal on Selected Areas in 928 Communications Vol. 14, No. 1, January 1996. 930 [P.NAMS] ITU-T, "Non-intrusive parametric model for the Assessment 931 of performance of Multimedia Streaming", ITU-T 932 Recommendation P.NAMS, November 2009. 934 [RFC3357] Koodli, R. and R. Ravikanth, "One-way Loss Pattern Sample 935 Metrics", RFC 3357, August 2002. 937 Authors' Addresses 939 Qin Wu 940 Huawei 941 101 Software Avenue, Yuhua District 942 Nanjing, Jiangsu 210012 943 China 945 Email: sunseawq@huawei.com 947 Glen Zorn 948 Network Zen 949 77/440 Soi Phoomjit, Rama IV Road 950 Phra Khanong, Khlong Toie 951 Bangkok 10110 952 Thailand 954 Phone: +66 (0) 87 502 4274 955 Email: gwz@net-zen.net 957 Roland Schott 958 Deutsche Telekom Laboratories 959 Deutsche-Telekom-Allee 7 960 Darmstadt 64295 961 Germany 963 Email: Roland.Schott@telekom.de