idnits 2.17.1 draft-ietf-avt-rtcpxr-video-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 873. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 884. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 891. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 897. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 2006) is 6335 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: '1' is defined on line 833, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 836, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 840, but no explicit reference was found in the text Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force A. Clark 2 Internet-Draft Telchemy Incorporated 3 Expires: 11th May 2007 A. Pendleton 4 Nortel 5 December 2006 7 RTCP XR - IP Video Metrics Report Blocks 8 draft-ietf-avt-rtcpxr-video-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on 11th May 2007. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 This document defines extensions to the RTCP XR extended report 42 packet type blocks to support the monitoring of video over IP 43 and the associated audio streams, if present, for IPTV and video 44 conferencing endpoint reporting. 46 Clark [Page 1] 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 2 51 3. IP Video Metrics Report Block . . . . . . . . . . . . . . . 5 52 4. IP Video Metrics Compact Format Block . . . . . . . . . . . 12 53 5. IP Video Metrics Configuration Block . . . . . . . . . . . . 14 54 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 16 55 7. Security Considerations . . . . . . . . . . . . . . . . . . 17 56 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 17 57 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 58 10. Informative References . . . . . . . . . . . . . . . . . . . 17 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17 60 Intellectual Property and Copyright Statements . . . . . . . 17 62 1. Introduction 64 This draft defines several new block types to augment those defined 65 in RFC3611 for use in Quality of Service reporting for video over IP. 66 The new block types defined in this draft are the IP Video Metrics 67 Report Block, and the IP Video Metrics Configuration Block. It 68 is intended to support both the identification of problems affecting 69 performance and the collection of data that may be useful in 70 optimizing system configuration. 72 Video performance may be measured using zero (no) reference, partial 73 (reduced) reference or full reference. The primary application of 74 this draft is to support the reporting of real-time, in-service 75 performance obtained using a zero or partial reference model however 76 this approach could also be used to support the remote reporting of 77 metrics from a full reference test. 79 2. Definitions 81 2.1 Reporting Endpoint 83 A report block produced per this draft is produced by the receiving 84 endpoint of an RTP stream, and relates to the quality of the received 85 stream and impairments that may affect perceived quality. A single 86 report block relates to an individual video stream. 88 2.2 Protocol layering 90 Packet video may be encapsulated in RTP, MPEG-2 Transport or other 91 video transport protocols. Some implementations encapsulate one 92 transport protocol within another, for example MPEG-2 Transport over 93 RTP. 95 Clark [Page 2] 96 Video transport protocols may be carried over TCP, UDP, Reliable UDP 97 and may be unicast, multicast or broadcast. Some implementations use 98 combinations of these, for example multicast transmission with 99 unicast retransmission. Forward Error Correction (FEC) may also be 100 used to correct (replace) lost packets. 102 The video stream comprises a series of I frames, which are intra- 103 frame encoded, and potentially P and B frames, which are interframe 104 encoded. The effects of packet loss can vary considerably depending 105 on the type of frame being impacted. 107 This draft supports the reporting of metrics related to each layer. 109 2.2 Cumulative and Interval Metrics 111 Cumulative metrics relate to the entire duration of the session to 112 the point at which metrics are determined and reported, and are 113 typically used to report session quality. Cumulative metrics 114 generally result in a lower volume of data that may need to be 115 stored, as each report supersedes earlier reports. 117 Interval metrics relate to the period since the last Interval report. 118 Interval data may be easier to correlate with specific network events 119 for which timing is known, and may also be used as a basis for 120 threshold crossing alerts. 121 Note that interval metrics for the start and end of sessions may be 122 unreliable due to factors such as irregular interval length and the 123 difficulty in knowing when packet transmission started and ended. 125 2.3 Metrics related to packet loss distribution 127 The distribution of lost packets can have a material impact on the 128 quality of a decoded video stream as packets tend to be lost in 129 high loss periods or bursts. 131 The terms Burst and Gap are used in a manner consistent with that of 132 RTCP XR (RFC3611). A Gap is a period of time between Bursts such 133 that any lost or discarded packets or frames are separated by some 134 number of "good" packets or frames. A Burst is a period of time that 135 fails the test for a Gap, and hence corresponds to a degraded quality 136 period. The recommended value for Gmin in RFC3611 resulted in a 137 Burst being a period of time during which the packet loss/discard 138 rate exceeded 5%. As video is generally more sensitive to packet loss 139 this report block recommends a larger value for Gmin. 141 Some video decoders do not properly handle out-of-sequence packets 142 and may discard them. The term "discarded" is used to relate to 143 packets that have been discarded due to late arrival or arrival 144 out-of-sequence. 146 Burst metrics may be used to identify "worst case" settings for FEC 147 or peak bandwidth for retransmission based protocols. 149 Clark [Page 3] 150 (i) FEC configuration 151 The burst loss rate represents the average packet loss rate during 152 worst case conditions. If the loss rate correctable by FEC is 153 greater than the burst loss rate, then most bursts of packet loss 154 should be corrected. 156 (ii) Peak bandwidth 157 Each lost packet that occurs during a burst period would potentially 158 be retransmitted. The peak retransmitted packet rate will therefore 159 be equivalent to the burst packet loss rate. 161 The term Loss Period is used in the sense defined by IPPM in RFC3357 162 and relates to a period of consecutive loss. 164 2.4 Absolute and Relative MOS scores 166 The term MOS (Mean Opinion Score) is used in subjective testing and 167 hence is a range that has a known relationship to "quality". The 168 term can however be confusing when used with services that are not 169 similar. For example, should the MOS score associated with a high 170 definition TV service be the same as that associated with video 171 displayed on a mobile handset? This can make it hard to understand 172 what a MOS score such as 3.1 for a mobile service means - is this 173 the result of degradation or just the result of the smaller display 174 size? 176 The term Absolute MOS is used in this draft to indicate a MOS score 177 that considers image resolution, frame rate, codec and compression 178 level, the effects of transmission impairments and frame loss 179 concealment, but not the physical size of the display. 181 The term Relative MOS is used in this draft to indicate a MOS score 182 that is expressed relative to the ideal for this codec and image 183 resolution. 185 For example, a mobile handset service has an Absolute MOS of 3.1 186 and a Relative MOS of 4.4. This indicates that the service is close 187 to ideal for the application but that some degradation is occurring. 189 2.5 Numeric formats 191 This report block makes use of binary fractions. The terminology 192 used is 194 S X:Y, where S indicates a signed representation, 195 X the number of bits prior to the decimal place and 196 Y the number of bits after the decimal place. 198 Hence 8:8 represents an unsigned number in the range 0.0039 to 199 255.996. 201 Clark [Page 4] 202 3 Video Metrics Report Block 204 3.1 Block Description 206 This block comprises a header and a series of sub-blocks. The 207 Map field in the header defines which sub-blocks are present. 209 Header sub-block (Required) 210 0 1 2 3 211 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | BT=N | Map | block length | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | Duration | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 IP Layer Loss Metrics sub-block (Required) 219 0 1 2 3 220 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | Pre-EC Loss Rate | Post-EC Loss Rate | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Number of IP packets expected | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 RTP Metrics sub-block (Optional) 228 0 1 2 3 229 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | SSRC of source | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Average Network PDV | Peak smoothing PDV | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Loss Rate | Discard Rate | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 MPEG Transport Metrics sub-block (Optional) 239 0 1 2 3 240 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | Video Stream PID | Audio Stream PID | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Video Stream Loss Rate | Audio Stream Loss Rate | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | PCR Jitter | Discard Rate | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 Clark [Page 5] 250 Packet Loss/Discard Distribution Metrics Sub-block (Required) 251 0 1 2 3 252 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Burst Duration (ms) | Gmin | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | Gap Duration (ms) | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | Burst Loss/Disc Proportion | Gap Loss/Disc Proportion | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Maximum Loss Period | Mean Loss Period | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 Video/Audio Metrics sub-block (Required) 265 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Full Frame Loss Rate | Interpolated Frame Loss Rate | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | VSTQ - Transmission Quality | VSCQ - Control Quality | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | MOS-A - Audio Quality | Reserved | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | Absolute MOS-V | Relative MOS-V | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | Absolute MOS-AV | Relative MOS-AV | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | Video bit rate (bits/sec) | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | Audio bit rate (bits/sec) | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | A-V Delay (Network I/F) | A-V Delay (Video I/F) | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | Round Trip Delay (media) | Round Trip Delay (control) | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 Playout Buffer Metrics sub-block (Required) 287 0 1 2 3 288 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Playout Interrupt Count | Mean Playout Interrupt Size | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | Playout buffer size | Mean buffer level | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 3.2 Header 296 Implementations MUST send the Header block within each RTCP XR 297 Video Metrics report. 299 3.2.1 Block type 301 Clark [Page 6] 302 Three Video Performance Reporting Metrics blocks are defined 304 mmm = Video Metrics- Cumulative 305 mmm+1 = Video Metrics- Interval 306 mmm+2 = Video Metrics- Alert 308 The time interval associated with these report blocks is left to the 309 implementation. Spacing of RTCP reports should be in accordance 310 with RFC3550 however the specific timing of RTCP XR Video reports may 311 be determined in response to an internally derived alert such as a 312 threshold crossing. 314 3.2.2 Map field 315 A Map field indicates the optional sub-blocks present in this 316 report. A 1 indicates that the sub-block is present, and a 0 that 317 the block is absent. If present, the sub-blocks must be in the 318 sequence defined in this document. 319 The bits have the following definitions: 321 0 RTP Metrics block 322 1 MPEG Transport Metrics block 323 2-7 Reserved, set to 0 325 3.2.3 Block Length 326 The block length indicates the length of this report in 32 bit 327 words and includes the header and any extension octets. 329 3.2.5 Correlation tag 330 The correlation tag facilitates the correlation of this report 331 block with other call or session related data or endpoint data. 333 3.3 IP Layer loss metrics sub-block 335 The IP Layer loss metrics sub-block MUST be present. 337 This block provides information on IP packet loss, both before 338 and after the effects of error correction. 340 3.3.1 Pre-EC Loss Rate 341 The proportion of IP packets lost before the effects of error 342 correction (FEC or retransmission), expressed as a binary fraction 343 in 0:16 format. 345 3.3.2 Post-EC Loss Rate 346 The effective proportion of IP packets after before the effects of 347 error correction, expressed as a binary fraction in 0:16 format. 349 3.3.3 Number of IP Packets Expected 350 The number of IP packets that the receiving system estimates that 351 it should have received. 353 3.4 RTP Metrics sub-block 355 Clark [Page 7] 356 If RTP is used for media transport, the RTP Metrics sub-block MUST 357 be present and if present MUST be indicated in the Map field. 359 This block provides information on the effects of IP transmission 360 impairments on the RTP stream. 362 3.4.1 Source SSRC 363 The SSRC associated with the RTP stream to which this report block 364 relates. 366 3.4.2 Average network PDV 367 The average delay variation of RTP packets due to the effects of 368 network congestion and buffering. 370 3.4.3 Peak smoothing PDV 371 The peak delay variation due to smoothing of the video packet 372 transmission rate, either by the sending system or network based 373 rate control. This should be determined by comparing the variation 374 in arrival time to the variation in RTP time stamp, and observing 375 any periodicity in the resulting sequence of delay variations. 377 3.4.4 Loss Rate 378 The proportion of RTP packets lost in the network, after the effects 379 of any error correction or retransmission. This should be determined 380 by comparing the variation in in RTP time stamp, and removing 381 any periodicity in the resulting sequence of delay variations. 383 3.4.5 Discard Rate 384 The proportion of RTP packets discarded due to out-of-sequence, late 385 or early arrival. 387 3.5 MPEG-2 Transport Metrics sub-block 389 The MPEG-2 Transport Metrics sub-block MUST be present if MPEG 390 Transport is used, and if present MUST be indicated in the Map 391 field. 393 This block contains a number of metrics associated with MPEG 394 transport stream packets. 396 3.5.1 Video Stream Program ID 397 The Program ID (PID) associated with the video stream. 399 3.5.2 Audio Stream Program ID 400 The Program ID (PID) associated with the audio stream 402 3.5.3 Loss Rate 403 The proportion of MPEG Transport Stream packets lost in the 404 network, after the effects of any error correction or retransmission. 406 3.5.4 Discard Rate 408 Clark [Page 8] 409 The proportion of MPEG Transport Stream packets discarded due to 410 late or early arrival. 412 3.5.5 PCR Jitter 413 The average PCR (Program Clock Reference) jitter level in 414 milliseconds for this MPEG Transport Stream. 416 3.6 Packet Loss/Discard Distribution Metrics sub-block 418 The Packet Loss/Discard Distribution Metrics sub-block MUST be 419 present. 421 This block contains metrics that describe the time distribution 422 of lost and discarded packets after the effects of any error 423 correction. 425 3.6.1 Burst duration 426 The duration of bursts of lost and discarded RTP packets 427 expressed in milliseconds. 429 3.6.2 Gmin Threshold 430 The Gmin threshold associated with the definition of bursts and 431 gaps. 433 3.6.3 Gap duration 434 The mean duration of gaps between bursts expressed in milliseconds. 436 3.6.4 Burst loss/discard proportion 437 The proportion of frames lost or discarded during burst periods 438 expressed as a binary fraction. 440 3.6.5 Gap loss/discard proportion 441 The proportion of frames lost or discarded during burst periods 442 expressed as a binary fraction. 444 3.6.6 Maximum Loss Period 445 The maximum number of consecutive lost packets during this session. 447 3.6.7 Mean Loss Period 448 The mean number of consecutive lost packets during this session. 450 3.7 Video/Audio Metrics sub-block 452 The Video/Audio Metrics sub-block MUST be present. 454 The metrics in this block provide information on the quality of the 455 video stream. 457 3.7.1 Full frame packet loss rate 458 The packet loss rate that affected full or intra-frame encoded 459 video frames (I frames). 461 3.7.2 Interpolated frame packet loss rate 463 Clark [Page 9] 464 The packet loss rate that affected interpolated or inter-frame 465 encoded video frames (B/P frames). 467 3.7.3 VSTQ - Video Service Transmission Quality 468 The video service transmission quality expressed as a score in the 469 range 0.0 to 50.0. This is a codec independent measure of the 470 ability of the bearer channel to support reliable video. 472 3.7.4 VSCQ - Video Service Control Plane Quality 473 The video service control plane (trick play) quality expressed as 474 a score in the range 0.0 to 50.0. This is a measure that is related 475 to the performance of the video stream control channel. 477 3.7.5 MOS-A Audio Quality 478 The video service audio quality expressed as a score in the range 479 1.0 to 5.0. This is an audio codec dependant measure that is 480 related to the subjective quality of the decoded audio stream(s). 481 (ATIS) 483 3.7.6 Absolute MOS-V Picture Quality 484 The absolute picture quality expressed as a score in the range 485 1.0 to 5.0. This is a codec dependant measure that is related to 486 the subjective quality of the decoded video stream and considers 487 the effects of codec, loss, bit rate/ quantization level, image 488 resolution and frame loss concealment. 490 3.7.7 Relative MOS-V Picture Quality 491 Picture quality expressed as a score relative to an ideal picture 492 with the same configuration. 494 3.7.8 Absolute MOS-AV Multimedia Quality 495 The multimedia quality expressed as a score in the range 1.0 to 5.0. 496 This is a composite audio/video measure that is related to the 497 overall subjective user experience and considers picture quality, 498 audio quality and audio/video synchronization. 500 3.7.9 Relative MOS-AV Multimedia Quality 501 Multimedia quality expressed as a score relative to an ideal video 502 and audio with the same configuration. 504 3.7.10 Video bit rate 505 The short term average bit rate of the video codec. 507 3.7.11 Audio bit rate 508 The short term average bit rate of the audio codec. 510 3.7.12 Audio-Video Delay (Network Interface) 511 The relative delay between audio and video measured before the 512 decoder and expressed in milliseconds 514 3.7.13 Audio-Video Delay (Video Interface) 515 The relative delay between audio and video measured after the 516 decoder and expressed in milliseconds 518 Clark [Page 10] 519 3.7.14 Round Trip Delay (Media) 520 The round trip delay for the media path, required only for 521 interactive video sessions. 523 3.7.15 Round Trip Delay (Control) 524 The round trip delay for the video control (trick play) path. 526 3.8 Playout Buffer Metrics sub-block 527 The Playout Buffer Metrics sub-block MUST be present. 529 3.8.1 Playout Interruption Count 530 The number of interruptions in video playout that have occurred due 531 to playout buffer starvation or excessive packet loss. 533 3.8.2 Mean Playout Interruption Size 534 The mean size of interruptions in playout, expressed in multiples of 535 100 milliseconds 537 3.8.3 Playout Buffer Size 538 The playout buffer size, expressed in multiples of 100 milliseconds 540 3.8.4 Mean Buffer Size 541 The average playout buffer size expressed in multiples of 100 542 milliseconds 544 Clark [Page 11] 545 4. RTCP XR Video Metrics - Compact Report Block 547 4.1 Block description 549 This block provides a compact alternative to the Video Metrics 550 report block for bandwidth or MTU size constrained applications. 552 0 1 2 3 553 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | BT=N | reserved | block length=9 | 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 | Stream ID | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | Pre-EC Loss Rate | Post-EC Loss Rate | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | Discard Rate | Burst density | Gap density | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | Burst duration | Gap duration | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | Round trip delay | Peak Smoothing Jitter | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | Network Jitter |Relative MOS-V | Abs MOS-V | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 |Relative MOS-AV| Abs MOS-AV | MOS-A | A-V Delay | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | Playout Interrupt Count | Mean Playout Interrupt Size | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | Playout buffer size | Mean buffer level | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 4.2 Header 578 Three Compact Video Report Blocks are defined 580 mmm+3 = Compact Video Metrics- Cumulative 581 mmm+4 = Compact Video Metrics- Interval 582 mmm+5 = Compact Video Metrics- Alert 584 The time interval associated with these report blocks is left to the 585 implementation. Spacing of RTCP reports should be in accordance 586 with RFC3550 however the specific timing of RTCP XR Video reports may 587 be determined in response to an internally derived alert such as a 588 threshold crossing. 590 4.3 Metrics 592 4.3.1 Pre-EC Loss Rate 593 Pre-Error Correction Loss Rate is defined in Section 3.3.1. 595 4.3.2 Post-EC Loss Rate 597 Clark [Page 12] 598 Post-Error Correction Loss Rate is defined in Section 3.3.2. 600 4.3.3 Discard Rate 601 Discard Rate is defined in Section 3.4.5. 603 4.3.4 Burst Density 604 Burst Density is defined in Sections 3.6.4 606 4.3.5 Gap Density 607 Gap Density is defined in Section 3.6.5. 609 4.3.6 Burst Duration 610 Burst Duration is defined in Section 3.6.1 612 4.3.7 Gap Duration 613 Gap Duration is defined in Section 3.6.3 615 4.3.8 Round Trip Delay 616 Round Trip Delay is defined in Section 3.7.14. 618 4.3.9 Peak Smoothing jitter 619 Smoothing jitter is defined in section 3.4.3 621 4.3.10 Average Network Jitter 622 Average netwwork Jitter is defined in Section 3.4.2. 624 4.3.11 Relative MOS-V 625 MOS-V is defined in Section 3.7.7. 627 4.3.12 Absolute MOS-V 628 MOS-V is defined in Section 3.7.6. 630 4.3.13 Relative MOS-AV 631 MOS-AV is defined in Section 3.7.9. 633 4.3.14 Absolute MOS-AV 634 MOS-AV is defined in Section 3.7.8. 636 4.3.15 MOS-A 637 MOS-A is defined in Section 3.7.5. 639 4.3.16 A-V Delay 640 Audio-Video Delay is defined in Section 3.7.12. 642 4.3.16 Playout Interrupt count 643 Playout Interrupt Count is defined in Section 3.8.1. 645 4.3.15 Playout Interrupt size 646 Playout Interrupt Size is defined in Section 3.8.2. 648 4.3.14 Playout buffer size 649 Playout buffer size is defined in Section 3.8.3. 651 Clark [Page 13] 652 4.3.17 Mean buffer size 653 Mean playout buffer size is defined in Section 3.8.4. 655 5. RTCP XR Video Metrics Configuration Block 657 This block type provides a flexible means to describe the algorithms 658 used for video quality calculation and other data. This block need 659 only be exchanged occasionally, for example sent once at the start 660 of a session. 662 Header sub-block 663 0 1 2 3 664 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 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 | BT=N | Map | block length | 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 | SSRC of source | 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 Correlation tag 672 0 1 2 3 673 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 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 | SSRC of source | 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 Algorithm sub-block 679 0 1 2 3 680 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 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 | Alg type | Descriptor len| Algorithm descriptor... | 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 | ... Algorithm descriptor | 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 5.1 Header 689 Implementations MUST send the Header block within each Video Metrics 690 Configuration report. 692 5.1.1 Block type 693 One Video Metrics Configuration block is defined 695 mmm+6 = Video Metric Configuration Block 697 The time interval associated with these report blocks is left to the 698 implementation. Spacing of RTCP reports should be in accordance 699 with RFC3550 however the specific timing of RTCP XR Video reports may 701 Clark [Page 14] 702 be determined in response to an internally derived alert such as a 703 threshold crossing. 705 5.1.2 Map field 706 A Map field indicates the optional sub-blocks present in this 707 report. A 1 indicates that the sub-block is present, and a 0 that 708 the block is absent. If present, the sub-blocks must be in the 709 sequence defined in this document. 710 The bits have the following definitions: 712 0 Correlation Tag 713 1 Algorithm Descriptor 1 714 2 Algorithm Descriptor 2 715 3 Algorithm Descriptor 3 716 4 Algorithm Descriptor 4 717 5 Vendor Specific Extension 718 6-7 Reserved, set to 0 720 5.1.3 Block Length 721 The block length indicates the length of this report in 32 bit 722 words and includes the header and any extension octets. 724 5.1.4 SSRC 725 The SSRC of the stream to which this report relates. 727 5.2 Correlation Tag 729 The Correlation Tag sub-block MAY be present and if present 730 MUST be indicated in the map field. This tag facilitates the 731 correlation of the RTCP XR Video Metrics report blocks 732 with other session-related data, session-related data or endpoint 733 data. 735 An example use case is for an endpoint may convey its version of a 736 session identifier or a global session identifier via this tag. A 737 flow measurement tool (sniffer) that is not session-aware can then 738 forward the RTCP XR reports along with this correlation tag to 739 network management. Network management can then use this tag to 740 correlate this report with other diagnostic information such as 741 session detail records. 743 The Tag Type indicates the use of the correlation tag. The following 744 values are defined: 746 0: IMS Charging Identity (ICID) subfield of the 747 P-Charging-Vector header specified in RFC 3455. 749 1: Globally unique ID as specified in ITU-T H.225.0 750 (Table 20/H.225.0). 752 2: Conference Identifier, per ITU-T H.225.0 753 (Table 20/H.225.0). 755 Clark [Page 15] 756 3: SIP Call-ID as defined in RFC 3261. 758 4: PacketCable Billing Call ID (BCID). 760 5: Text string using the US-ASCII character set. 762 6: Octet sting. 764 7-255: Future growth. 766 Although the intent of this RFC is to list all currently known 767 values of usable correlation tags, it is possible that new values 768 may be defined in the future. An IANA registry of correlation 769 tags is recommended. 771 The tag length indicates the overall length of the sub-block in 772 32 bit words and includes the tag type and length fields. 774 5.3 Algorithm description 776 The Algorithm Description sub-block MAY be present however if present 777 MUST be indicated in the MAP field 778 The Algorithm descriptor is a bit field which indicates which 779 algorithm is being described. The bits are defined as:- 781 Bit 0: MOS-LQ Algorithm 782 Bit 1: MOS-CQ Algorithm 783 Bit 2: R-LQ Algorithm 784 Bit 3: R-CQ Algorithm 785 Bit 4: Video Monitoring Algorithm 786 Bit 5: Audio Monitoring Algorithm 787 Bit 6: Multimedia Monitoring Algorithm 788 Bit 7: Transmission Quality Monitoring Algorithm 790 The descriptor length gives the overall length of the descriptor in 791 32 bit words and includes the algorithm descriptor and length fields. 793 The algorithm descriptor is a text field that contains the 794 description or name of the algorithm. If the algorithm name is 795 shorter than the length of the field then the trailing octets 796 must be set to 0x00. 798 For example, an implementation may report: 800 Algorithm descriptor = 0x10 - Video estimation algorithm 801 Descriptor length = 3 - 3 words 802 Descriptor = "Alg X" 0x00 - description 804 6. Summary 806 This draft defines a full and a compact RTCP XR report block for 807 video quality reporting. This is intended for in-service monitoring 808 of video streaming, IPTV and IP videoconferencing services to provide 810 Clark [Page 16] 811 real time performance feedback and support performance management. 813 7. IANA Considerations 815 The block type "mmm" will need to be replaced with an IANA assigned 816 number within those allocated for RTCP XR report blocks (RFC 3611). 818 8. Security Considerations 820 RTCP reports can contain sensitive information since they can provide 821 information about the nature and duration of a session established 822 between two endpoints. As a result, any third party wishing to 823 obtain this information should be properly authenticated and the 824 information transferred securely. 826 9. Acknowledgments 828 The authors would like to acknowledge Keith Lantz, Kaynam Hedayat, 829 Satish Kumar for their helpful comments. 831 10. Informative References 833 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 834 Levels", BCP 14, RFC 2119, March 1997. 836 [2] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, 837 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 838 RFC 3550, July 2003. 840 [3] Friedman, T., Caceres, R. and A. Clark, "RTP Control Protocol 841 Extended Reports (RTCP XR)", RFC 3611, November 2003. 843 Authors' Addresses 845 Alan Clark 846 Telchemy Incorporated 847 2905 Premiere Parkway, Suite 280 848 Duluth, GA 30097 849 Email: alan@telchemy.com 851 Amy Pendleton 852 Nortel 853 2380 Performance Drive 854 Richardson, TX 75081 855 Email: aspen@nortel.com 857 Full Copyright Statement 859 Copyright (C) The Internet Society (2006). 861 This document is subject to the rights, licenses and restrictions 862 contained in BCP 78, and except as set forth therein, the authors 864 Clark [Page 17] 865 retain all their rights. 867 This document and the information contained herein are provided on an 868 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 869 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 870 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 871 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 872 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 873 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 875 Intellectual Property 877 The IETF takes no position regarding the validity or scope of any 878 Intellectual Property Rights or other rights that might be claimed to 879 pertain to the implementation or use of the technology described in 880 this document or the extent to which any license under such rights 881 might or might not be available; nor does it represent that it has 882 made any independent effort to identify any such rights. Information 883 on the procedures with respect to rights in RFC documents can be 884 found in BCP 78 and BCP 79. 886 Copies of IPR disclosures made to the IETF Secretariat and any 887 assurances of licenses to be made available, or the result of an 888 attempt made to obtain a general license or permission for the use of 889 such proprietary rights by implementers or users of this 890 specification can be obtained from the IETF on-line IPR repository at 891 http://www.ietf.org/ipr. 893 The IETF invites any interested party to bring to its attention any 894 copyrights, patents or patent applications, or other proprietary 895 rights that may cover technology that may be required to implement 896 this standard. Please address the information to the IETF at ietf- 897 ipr@ietf.org. 899 Acknowledgement 901 Funding for the RFC Editor function is currently provided by the 902 Internet Society. 904 Clark [Page 18]