Internet Engineering Task Force A. Clark Internet-Draft Telchemy Incorporated Expires: 11th May 2007 A. Pendleton Nortel December 2006 RTCP XR - IP Video Metrics Report Blocks draft-ietf-avt-rtcpxr-video-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on 11th May 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document defines extensions to the RTCP XR extended report packet type blocks to support the monitoring of video over IP and the associated audio streams, if present, for IPTV and video conferencing endpoint reporting. Clark [Page 1] draft-ietf-avt-rtcpxr-video-00.txt December 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 2 3. IP Video Metrics Report Block . . . . . . . . . . . . . . . 5 4. IP Video Metrics Compact Format Block . . . . . . . . . . . 12 5. IP Video Metrics Configuration Block . . . . . . . . . . . . 14 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 17 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 10. Informative References . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . 17 1. Introduction This draft defines several new block types to augment those defined in RFC3611 for use in Quality of Service reporting for video over IP. The new block types defined in this draft are the IP Video Metrics Report Block, and the IP Video Metrics Configuration Block. It is intended to support both the identification of problems affecting performance and the collection of data that may be useful in optimizing system configuration. Video performance may be measured using zero (no) reference, partial (reduced) reference or full reference. The primary application of this draft is to support the reporting of real-time, in-service performance obtained using a zero or partial reference model however this approach could also be used to support the remote reporting of metrics from a full reference test. 2. Definitions 2.1 Reporting Endpoint A report block produced per this draft is produced by the receiving endpoint of an RTP stream, and relates to the quality of the received stream and impairments that may affect perceived quality. A single report block relates to an individual video stream. 2.2 Protocol layering Packet video may be encapsulated in RTP, MPEG-2 Transport or other video transport protocols. Some implementations encapsulate one transport protocol within another, for example MPEG-2 Transport over RTP. Clark [Page 2] draft-ietf-avt-rtcpxr-video-00.txt December 2006 Video transport protocols may be carried over TCP, UDP, Reliable UDP and may be unicast, multicast or broadcast. Some implementations use combinations of these, for example multicast transmission with unicast retransmission. Forward Error Correction (FEC) may also be used to correct (replace) lost packets. The video stream comprises a series of I frames, which are intra- frame encoded, and potentially P and B frames, which are interframe encoded. The effects of packet loss can vary considerably depending on the type of frame being impacted. This draft supports the reporting of metrics related to each layer. 2.2 Cumulative and Interval Metrics Cumulative metrics relate to the entire duration of the session to the point at which metrics are determined and reported, and are typically used to report session quality. Cumulative metrics generally result in a lower volume of data that may need to be stored, as each report supersedes earlier reports. Interval metrics relate to the period since the last Interval report. Interval data may be easier to correlate with specific network events for which timing is known, and may also be used as a basis for threshold crossing alerts. Note that interval metrics for the start and end of sessions may be unreliable due to factors such as irregular interval length and the difficulty in knowing when packet transmission started and ended. 2.3 Metrics related to packet loss distribution The distribution of lost packets can have a material impact on the quality of a decoded video stream as packets tend to be lost in high loss periods or bursts. The terms Burst and Gap are used in a manner consistent with that of RTCP XR (RFC3611). A Gap is a period of time between Bursts such that any lost or discarded packets or frames are separated by some number of "good" packets or frames. A Burst is a period of time that fails the test for a Gap, and hence corresponds to a degraded quality period. The recommended value for Gmin in RFC3611 resulted in a Burst being a period of time during which the packet loss/discard rate exceeded 5%. As video is generally more sensitive to packet loss this report block recommends a larger value for Gmin. Some video decoders do not properly handle out-of-sequence packets and may discard them. The term "discarded" is used to relate to packets that have been discarded due to late arrival or arrival out-of-sequence. Burst metrics may be used to identify "worst case" settings for FEC or peak bandwidth for retransmission based protocols. Clark [Page 3] draft-ietf-avt-rtcpxr-video-00.txt December 2006 (i) FEC configuration The burst loss rate represents the average packet loss rate during worst case conditions. If the loss rate correctable by FEC is greater than the burst loss rate, then most bursts of packet loss should be corrected. (ii) Peak bandwidth Each lost packet that occurs during a burst period would potentially be retransmitted. The peak retransmitted packet rate will therefore be equivalent to the burst packet loss rate. The term Loss Period is used in the sense defined by IPPM in RFC3357 and relates to a period of consecutive loss. 2.4 Absolute and Relative MOS scores The term MOS (Mean Opinion Score) is used in subjective testing and hence is a range that has a known relationship to "quality". The term can however be confusing when used with services that are not similar. For example, should the MOS score associated with a high definition TV service be the same as that associated with video displayed on a mobile handset? This can make it hard to understand what a MOS score such as 3.1 for a mobile service means - is this the result of degradation or just the result of the smaller display size? The term Absolute MOS is used in this draft to indicate a MOS score that considers image resolution, frame rate, codec and compression level, the effects of transmission impairments and frame loss concealment, but not the physical size of the display. The term Relative MOS is used in this draft to indicate a MOS score that is expressed relative to the ideal for this codec and image resolution. For example, a mobile handset service has an Absolute MOS of 3.1 and a Relative MOS of 4.4. This indicates that the service is close to ideal for the application but that some degradation is occurring. 2.5 Numeric formats This report block makes use of binary fractions. The terminology used is S X:Y, where S indicates a signed representation, X the number of bits prior to the decimal place and Y the number of bits after the decimal place. Hence 8:8 represents an unsigned number in the range 0.0039 to 255.996. Clark [Page 4] draft-ietf-avt-rtcpxr-video-00.txt December 2006 3 Video Metrics Report Block 3.1 Block Description This block comprises a header and a series of sub-blocks. The Map field in the header defines which sub-blocks are present. Header sub-block (Required) 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT=N | Map | block length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Duration | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IP Layer Loss Metrics sub-block (Required) 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pre-EC Loss Rate | Post-EC Loss Rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of IP packets expected | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ RTP Metrics sub-block (Optional) 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Average Network PDV | Peak smoothing PDV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Loss Rate | Discard Rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MPEG Transport Metrics sub-block (Optional) 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Video Stream PID | Audio Stream PID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Video Stream Loss Rate | Audio Stream Loss Rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PCR Jitter | Discard Rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Clark [Page 5] draft-ietf-avt-rtcpxr-video-00.txt December 2006 Packet Loss/Discard Distribution Metrics Sub-block (Required) 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Burst Duration (ms) | Gmin | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Gap Duration (ms) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Burst Loss/Disc Proportion | Gap Loss/Disc Proportion | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maximum Loss Period | Mean Loss Period | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Video/Audio Metrics sub-block (Required) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Full Frame Loss Rate | Interpolated Frame Loss Rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VSTQ - Transmission Quality | VSCQ - Control Quality | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MOS-A - Audio Quality | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Absolute MOS-V | Relative MOS-V | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Absolute MOS-AV | Relative MOS-AV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Video bit rate (bits/sec) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Audio bit rate (bits/sec) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | A-V Delay (Network I/F) | A-V Delay (Video I/F) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Round Trip Delay (media) | Round Trip Delay (control) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Playout Buffer Metrics sub-block (Required) 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Playout Interrupt Count | Mean Playout Interrupt Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Playout buffer size | Mean buffer level | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.2 Header Implementations MUST send the Header block within each RTCP XR Video Metrics report. 3.2.1 Block type Clark [Page 6] draft-ietf-avt-rtcpxr-video-00.txt December 2006 Three Video Performance Reporting Metrics blocks are defined mmm = Video Metrics- Cumulative mmm+1 = Video Metrics- Interval mmm+2 = Video Metrics- Alert The time interval associated with these report blocks is left to the implementation. Spacing of RTCP reports should be in accordance with RFC3550 however the specific timing of RTCP XR Video reports may be determined in response to an internally derived alert such as a threshold crossing. 3.2.2 Map field A Map field indicates the optional sub-blocks present in this report. A 1 indicates that the sub-block is present, and a 0 that the block is absent. If present, the sub-blocks must be in the sequence defined in this document. The bits have the following definitions: 0 RTP Metrics block 1 MPEG Transport Metrics block 2-7 Reserved, set to 0 3.2.3 Block Length The block length indicates the length of this report in 32 bit words and includes the header and any extension octets. 3.2.5 Correlation tag The correlation tag facilitates the correlation of this report block with other call or session related data or endpoint data. 3.3 IP Layer loss metrics sub-block The IP Layer loss metrics sub-block MUST be present. This block provides information on IP packet loss, both before and after the effects of error correction. 3.3.1 Pre-EC Loss Rate The proportion of IP packets lost before the effects of error correction (FEC or retransmission), expressed as a binary fraction in 0:16 format. 3.3.2 Post-EC Loss Rate The effective proportion of IP packets after before the effects of error correction, expressed as a binary fraction in 0:16 format. 3.3.3 Number of IP Packets Expected The number of IP packets that the receiving system estimates that it should have received. 3.4 RTP Metrics sub-block Clark [Page 7] draft-ietf-avt-rtcpxr-video-00.txt December 2006 If RTP is used for media transport, the RTP Metrics sub-block MUST be present and if present MUST be indicated in the Map field. This block provides information on the effects of IP transmission impairments on the RTP stream. 3.4.1 Source SSRC The SSRC associated with the RTP stream to which this report block relates. 3.4.2 Average network PDV The average delay variation of RTP packets due to the effects of network congestion and buffering. 3.4.3 Peak smoothing PDV The peak delay variation due to smoothing of the video packet transmission rate, either by the sending system or network based rate control. This should be determined by comparing the variation in arrival time to the variation in RTP time stamp, and observing any periodicity in the resulting sequence of delay variations. 3.4.4 Loss Rate The proportion of RTP packets lost in the network, after the effects of any error correction or retransmission. This should be determined by comparing the variation in in RTP time stamp, and removing any periodicity in the resulting sequence of delay variations. 3.4.5 Discard Rate The proportion of RTP packets discarded due to out-of-sequence, late or early arrival. 3.5 MPEG-2 Transport Metrics sub-block The MPEG-2 Transport Metrics sub-block MUST be present if MPEG Transport is used, and if present MUST be indicated in the Map field. This block contains a number of metrics associated with MPEG transport stream packets. 3.5.1 Video Stream Program ID The Program ID (PID) associated with the video stream. 3.5.2 Audio Stream Program ID The Program ID (PID) associated with the audio stream 3.5.3 Loss Rate The proportion of MPEG Transport Stream packets lost in the network, after the effects of any error correction or retransmission. 3.5.4 Discard Rate Clark [Page 8] draft-ietf-avt-rtcpxr-video-00.txt December 2006 The proportion of MPEG Transport Stream packets discarded due to late or early arrival. 3.5.5 PCR Jitter The average PCR (Program Clock Reference) jitter level in milliseconds for this MPEG Transport Stream. 3.6 Packet Loss/Discard Distribution Metrics sub-block The Packet Loss/Discard Distribution Metrics sub-block MUST be present. This block contains metrics that describe the time distribution of lost and discarded packets after the effects of any error correction. 3.6.1 Burst duration The duration of bursts of lost and discarded RTP packets expressed in milliseconds. 3.6.2 Gmin Threshold The Gmin threshold associated with the definition of bursts and gaps. 3.6.3 Gap duration The mean duration of gaps between bursts expressed in milliseconds. 3.6.4 Burst loss/discard proportion The proportion of frames lost or discarded during burst periods expressed as a binary fraction. 3.6.5 Gap loss/discard proportion The proportion of frames lost or discarded during burst periods expressed as a binary fraction. 3.6.6 Maximum Loss Period The maximum number of consecutive lost packets during this session. 3.6.7 Mean Loss Period The mean number of consecutive lost packets during this session. 3.7 Video/Audio Metrics sub-block The Video/Audio Metrics sub-block MUST be present. The metrics in this block provide information on the quality of the video stream. 3.7.1 Full frame packet loss rate The packet loss rate that affected full or intra-frame encoded video frames (I frames). 3.7.2 Interpolated frame packet loss rate Clark [Page 9] draft-ietf-avt-rtcpxr-video-00.txt December 2006 The packet loss rate that affected interpolated or inter-frame encoded video frames (B/P frames). 3.7.3 VSTQ - Video Service Transmission Quality The video service transmission quality expressed as a score in the range 0.0 to 50.0. This is a codec independent measure of the ability of the bearer channel to support reliable video. 3.7.4 VSCQ - Video Service Control Plane Quality The video service control plane (trick play) quality expressed as a score in the range 0.0 to 50.0. This is a measure that is related to the performance of the video stream control channel. 3.7.5 MOS-A Audio Quality The video service audio quality expressed as a score in the range 1.0 to 5.0. This is an audio codec dependant measure that is related to the subjective quality of the decoded audio stream(s). (ATIS) 3.7.6 Absolute MOS-V Picture Quality The absolute picture quality expressed as a score in the range 1.0 to 5.0. This is a codec dependant measure that is related to the subjective quality of the decoded video stream and considers the effects of codec, loss, bit rate/ quantization level, image resolution and frame loss concealment. 3.7.7 Relative MOS-V Picture Quality Picture quality expressed as a score relative to an ideal picture with the same configuration. 3.7.8 Absolute MOS-AV Multimedia Quality The multimedia quality expressed as a score in the range 1.0 to 5.0. This is a composite audio/video measure that is related to the overall subjective user experience and considers picture quality, audio quality and audio/video synchronization. 3.7.9 Relative MOS-AV Multimedia Quality Multimedia quality expressed as a score relative to an ideal video and audio with the same configuration. 3.7.10 Video bit rate The short term average bit rate of the video codec. 3.7.11 Audio bit rate The short term average bit rate of the audio codec. 3.7.12 Audio-Video Delay (Network Interface) The relative delay between audio and video measured before the decoder and expressed in milliseconds 3.7.13 Audio-Video Delay (Video Interface) The relative delay between audio and video measured after the decoder and expressed in milliseconds Clark [Page 10] draft-ietf-avt-rtcpxr-video-00.txt December 2006 3.7.14 Round Trip Delay (Media) The round trip delay for the media path, required only for interactive video sessions. 3.7.15 Round Trip Delay (Control) The round trip delay for the video control (trick play) path. 3.8 Playout Buffer Metrics sub-block The Playout Buffer Metrics sub-block MUST be present. 3.8.1 Playout Interruption Count The number of interruptions in video playout that have occurred due to playout buffer starvation or excessive packet loss. 3.8.2 Mean Playout Interruption Size The mean size of interruptions in playout, expressed in multiples of 100 milliseconds 3.8.3 Playout Buffer Size The playout buffer size, expressed in multiples of 100 milliseconds 3.8.4 Mean Buffer Size The average playout buffer size expressed in multiples of 100 milliseconds Clark [Page 11] draft-ietf-avt-rtcpxr-video-00.txt December 2006 4. RTCP XR Video Metrics - Compact Report Block 4.1 Block description This block provides a compact alternative to the Video Metrics report block for bandwidth or MTU size constrained applications. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT=N | reserved | block length=9 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Stream ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pre-EC Loss Rate | Post-EC Loss Rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Discard Rate | Burst density | Gap density | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Burst duration | Gap duration | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Round trip delay | Peak Smoothing Jitter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Jitter |Relative MOS-V | Abs MOS-V | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Relative MOS-AV| Abs MOS-AV | MOS-A | A-V Delay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Playout Interrupt Count | Mean Playout Interrupt Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Playout buffer size | Mean buffer level | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.2 Header Three Compact Video Report Blocks are defined mmm+3 = Compact Video Metrics- Cumulative mmm+4 = Compact Video Metrics- Interval mmm+5 = Compact Video Metrics- Alert The time interval associated with these report blocks is left to the implementation. Spacing of RTCP reports should be in accordance with RFC3550 however the specific timing of RTCP XR Video reports may be determined in response to an internally derived alert such as a threshold crossing. 4.3 Metrics 4.3.1 Pre-EC Loss Rate Pre-Error Correction Loss Rate is defined in Section 3.3.1. 4.3.2 Post-EC Loss Rate Clark [Page 12] draft-ietf-avt-rtcpxr-video-00.txt December 2006 Post-Error Correction Loss Rate is defined in Section 3.3.2. 4.3.3 Discard Rate Discard Rate is defined in Section 3.4.5. 4.3.4 Burst Density Burst Density is defined in Sections 3.6.4 4.3.5 Gap Density Gap Density is defined in Section 3.6.5. 4.3.6 Burst Duration Burst Duration is defined in Section 3.6.1 4.3.7 Gap Duration Gap Duration is defined in Section 3.6.3 4.3.8 Round Trip Delay Round Trip Delay is defined in Section 3.7.14. 4.3.9 Peak Smoothing jitter Smoothing jitter is defined in section 3.4.3 4.3.10 Average Network Jitter Average netwwork Jitter is defined in Section 3.4.2. 4.3.11 Relative MOS-V MOS-V is defined in Section 3.7.7. 4.3.12 Absolute MOS-V MOS-V is defined in Section 3.7.6. 4.3.13 Relative MOS-AV MOS-AV is defined in Section 3.7.9. 4.3.14 Absolute MOS-AV MOS-AV is defined in Section 3.7.8. 4.3.15 MOS-A MOS-A is defined in Section 3.7.5. 4.3.16 A-V Delay Audio-Video Delay is defined in Section 3.7.12. 4.3.16 Playout Interrupt count Playout Interrupt Count is defined in Section 3.8.1. 4.3.15 Playout Interrupt size Playout Interrupt Size is defined in Section 3.8.2. 4.3.14 Playout buffer size Playout buffer size is defined in Section 3.8.3. Clark [Page 13] draft-ietf-avt-rtcpxr-video-00.txt December 2006 4.3.17 Mean buffer size Mean playout buffer size is defined in Section 3.8.4. 5. RTCP XR Video Metrics Configuration Block This block type provides a flexible means to describe the algorithms used for video quality calculation and other data. This block need only be exchanged occasionally, for example sent once at the start of a session. Header sub-block 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT=N | Map | block length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Correlation tag 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Algorithm sub-block 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Alg type | Descriptor len| Algorithm descriptor... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Algorithm descriptor | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.1 Header Implementations MUST send the Header block within each Video Metrics Configuration report. 5.1.1 Block type One Video Metrics Configuration block is defined mmm+6 = Video Metric Configuration Block The time interval associated with these report blocks is left to the implementation. Spacing of RTCP reports should be in accordance with RFC3550 however the specific timing of RTCP XR Video reports may Clark [Page 14] draft-ietf-avt-rtcpxr-video-00.txt December 2006 be determined in response to an internally derived alert such as a threshold crossing. 5.1.2 Map field A Map field indicates the optional sub-blocks present in this report. A 1 indicates that the sub-block is present, and a 0 that the block is absent. If present, the sub-blocks must be in the sequence defined in this document. The bits have the following definitions: 0 Correlation Tag 1 Algorithm Descriptor 1 2 Algorithm Descriptor 2 3 Algorithm Descriptor 3 4 Algorithm Descriptor 4 5 Vendor Specific Extension 6-7 Reserved, set to 0 5.1.3 Block Length The block length indicates the length of this report in 32 bit words and includes the header and any extension octets. 5.1.4 SSRC The SSRC of the stream to which this report relates. 5.2 Correlation Tag The Correlation Tag sub-block MAY be present and if present MUST be indicated in the map field. This tag facilitates the correlation of the RTCP XR Video Metrics report blocks with other session-related data, session-related data or endpoint data. An example use case is for an endpoint may convey its version of a session identifier or a global session identifier via this tag. A flow measurement tool (sniffer) that is not session-aware can then forward the RTCP XR reports along with this correlation tag to network management. Network management can then use this tag to correlate this report with other diagnostic information such as session detail records. The Tag Type indicates the use of the correlation tag. The following values are defined: 0: IMS Charging Identity (ICID) subfield of the P-Charging-Vector header specified in RFC 3455. 1: Globally unique ID as specified in ITU-T H.225.0 (Table 20/H.225.0). 2: Conference Identifier, per ITU-T H.225.0 (Table 20/H.225.0). Clark [Page 15] draft-ietf-avt-rtcpxr-video-00.txt December 2006 3: SIP Call-ID as defined in RFC 3261. 4: PacketCable Billing Call ID (BCID). 5: Text string using the US-ASCII character set. 6: Octet sting. 7-255: Future growth. Although the intent of this RFC is to list all currently known values of usable correlation tags, it is possible that new values may be defined in the future. An IANA registry of correlation tags is recommended. The tag length indicates the overall length of the sub-block in 32 bit words and includes the tag type and length fields. 5.3 Algorithm description The Algorithm Description sub-block MAY be present however if present MUST be indicated in the MAP field The Algorithm descriptor is a bit field which indicates which algorithm is being described. The bits are defined as:- Bit 0: MOS-LQ Algorithm Bit 1: MOS-CQ Algorithm Bit 2: R-LQ Algorithm Bit 3: R-CQ Algorithm Bit 4: Video Monitoring Algorithm Bit 5: Audio Monitoring Algorithm Bit 6: Multimedia Monitoring Algorithm Bit 7: Transmission Quality Monitoring Algorithm The descriptor length gives the overall length of the descriptor in 32 bit words and includes the algorithm descriptor and length fields. The algorithm descriptor is a text field that contains the description or name of the algorithm. If the algorithm name is shorter than the length of the field then the trailing octets must be set to 0x00. For example, an implementation may report: Algorithm descriptor = 0x10 - Video estimation algorithm Descriptor length = 3 - 3 words Descriptor = "Alg X" 0x00 - description 6. Summary This draft defines a full and a compact RTCP XR report block for video quality reporting. This is intended for in-service monitoring of video streaming, IPTV and IP videoconferencing services to provide Clark [Page 16] draft-ietf-avt-rtcpxr-video-00.txt December 2006 real time performance feedback and support performance management. 7. IANA Considerations The block type "mmm" will need to be replaced with an IANA assigned number within those allocated for RTCP XR report blocks (RFC 3611). 8. Security Considerations RTCP reports can contain sensitive information since they can provide information about the nature and duration of a session established between two endpoints. As a result, any third party wishing to obtain this information should be properly authenticated and the information transferred securely. 9. Acknowledgments The authors would like to acknowledge Keith Lantz, Kaynam Hedayat, Satish Kumar for their helpful comments. 10. Informative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [3] Friedman, T., Caceres, R. and A. Clark, "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003. Authors' Addresses Alan Clark Telchemy Incorporated 2905 Premiere Parkway, Suite 280 Duluth, GA 30097 Email: alan@telchemy.com Amy Pendleton Nortel 2380 Performance Drive Richardson, TX 75081 Email: aspen@nortel.com Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors Clark [Page 17] draft-ietf-avt-rtcpxr-video-00.txt December 2006 retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Clark [Page 18]