idnits 2.17.1 draft-ietf-avt-rtcpxr-video-02.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, updated by RFC 4748 on line 306. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 318. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 325. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 331. 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 IETF Trust 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 (November 2007) is 6006 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 266, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 269, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 273, but no explicit reference was found in the text Summary: 1 error (**), 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: 16th May 2008 A. Pendleton 4 Nortel 5 November 2007 7 RTCP XR - Video Metrics Report Blocks 8 draft-ietf-avt-rtcpxr-video-02.txt 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 16th May 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 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 for IPTV and videoconferencing endpoint reporting. 45 Clark [Page 1] 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 49 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 2 50 3. IP Video Metrics Report Block . . . . . . . . . . . . . . . 2 51 4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 5 52 5. Security Considerations . . . . . . . . . . . . . . . . . . 5 53 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 5 54 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 55 8. Informative References . . . . . . . . . . . . . . . . . . . 6 56 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 57 Intellectual Property and Copyright Statements . . . . . . . 59 1. Introduction 61 This draft defines an RTCP XR block type for Quality of Service 62 reporting for video over IP. It is intended to support both the 63 identification of problems affecting performance and the collection 64 of data that may be useful in optimizing system configuration. 66 Video performance may be measured using zero (no) reference, partial 67 (reduced) reference or full reference. The primary application of 68 this draft is to support the reporting of real-time, in-service 69 performance obtained using a zero or partial reference model however 70 this approach could also be used to support the remote reporting of 71 metrics from a full reference test. 73 2. Definitions 75 This draft defines metrics related to IP Video performance. Video 76 MOS scores have not been included in this draft however may be 77 incorporated later if an industry standard method for computing 78 such scores is defined. 80 3 Video Metrics Report Block 82 3.1 Block Description 84 0 1 2 3 85 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 86 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 87 | BT=N | Reserved | block length | 88 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 89 | SSRC | 90 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 91 |0 0 0| Program ID | Reserved | 92 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 94 Clark [Page 2] 95 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 96 | Measurement Interval (ms) | 97 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 98 | Proportion Impaired I frames | Proportion Impaired BP frames | 99 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 100 | Loss rate within I frames | Loss rate within BP frames | 101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 102 | Mean GoP Length (frames) | Max GoP Length (frames) | 103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 104 | EPSNR Threshold | Time below PSNR threshold | 105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 106 | Mean Video bit rate (bits/sec) | 107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 108 | Round trip delay | A-V Delay (Video I/F) | 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 | Playout Interrupt Count | Mean Playout Interrupt Size | 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 | Video Playout buffer size | Mean buffer level | 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 3.2 Metric definitions 116 3.2.1 Header 117 The header comprises: 118 (i) Block Type for this report block 119 (ii) Reserved (set to 0xFF) 120 (iii) Block length in words (set to 0x000C) 121 (iv) SSRC of the received RTP stream that this report refers to 122 (v) Program ID (PID) for the video stream (if MPEG Transport 123 encapsulation is used) 124 (vi) Reserved (set to 0xFFFF) 126 3.2.2 Measurement Interval 127 The interval of time over which these metrics were measured, 128 expressed in milliseconds. 130 3.2.3 Proportion of impaired I frames 131 The proportion of I (intra-frame encoded) frames [4] that were 132 impaired by packet loss or discard, expressed as a binary fraction. 134 3.2.4 Proportion of impaired BP frames 135 The proportion of B and P (inter-frame encoded) frames [4] that 136 were impaired by packet loss or discard, expressed as a binary 137 fraction. 139 3.2.5 Loss rate within I frames 140 The average packet loss/discard rate occurring within I frames, 141 [4] expressed as a binary fraction. 143 3.2.6 Loss rate within BP frames 144 The average packet loss/discard rate occurring within B and P 145 [4] frames, expressed as a binary fraction. 147 3.2.7 Mean inter-I-frame gap (MIIF) 149 Clark [Page 3] 150 The average interval between I frames expressed in terms of frames. 151 If n(j) is the number of P and B frames between the jth and (j+1)th 152 I frame then the mean inter-I-frame gap is 154 MIIF(j) = ( MIIF(j-1) * 15 + n(j) ) / 16 156 The I frames occur at the start of Groups of Pictures (GoP) and 157 may also be inserted during GoP's due to large scale changes in 158 picture content (e.g. scene changes). This can result in 159 bandwidth being larger than expected. 161 3.2.8 Max GoP Length (MGoP) 162 The maximum GoP size (including the starting I frame and 163 subsequent P and B frames) expressed in terms of frames. 164 If m(j) comprises a count of the starting I frame and the 165 subsequent frames (P, B or inserted I) prior to the I frame 166 that forms the start of the next GoP, then the maximum GoP 167 length is 169 MGoP(j) = max( m(j), MGoP(j-1) ) 171 A long GoP may result in lower bandwidth however will lead to 172 increased error propagation and hence degraded performance. 174 3.2.9 Estimated PSNR (EPSNR) 175 An estimate of the average Peak Signal to Noise Ratio, averaged 176 over the duration of the measurement interval. This is expressed 177 in unsigned 8:8 format and has the range 0.0 to 100.0. For 178 typical high quality video streams this parameter would have a 179 value in the range 35-45. 181 The per frame PSNR value SHOULD be estimated by the decoder, based 182 on the proportion of macroblocks within the frame that required 183 concealment, the concealment algorithm used and quantization level. 184 If a per-frame PSNR estimate is not available from the decoder 185 then this value MAY be estimated from the proportion of packet 186 loss per frame [4]. 188 A value of 0xFFFF shall indicate that this parameter is not 189 available. 191 3.2.10 EPSNR Threshold 192 Threshold defined as the level below which quality is not 193 acceptable 195 A value of 0xFFFF shall indicate that this parameter is not 196 available. 198 3.2.11 Proportion of time below EPSNR threshold 199 The proportion of the measurement interval during which estimated 200 PSNR was below the PSNR Threshold, expressed as a binary fraction. 202 If the value of MOS Threshold is 0xFFFF then the value of this 204 Clark [Page 4] 205 parameter is undefined. 207 3.2.12 Mean Video Bit Rate 208 The average video bit rate [4] calculated over the measurement 209 interval. This shall include RTP and MPEG Transport packet 210 headers and payloads but shall exclude IP and UDP or TCP 211 overhead. 213 3.2.13 Round Trip Delay 214 The Round Trip Delay between the originating and terminating ends 215 of this RTP stream, expressed in millseconds. In unicast or 216 multicast applications this parameter may be set to "undefined" 217 (0xFFFF). 219 3.2.14 A-V Delay 220 The relative delay between decoded audio and video streams expressed 221 in milliseconds [4]. 223 3.2.15 Playout Interrupt Count 224 The number of interruptions or frame freezes that occurred during 225 playout, due to either packet loss or buffer underrun [4]. 227 3.2.16 Mean Playout Interrupt Size 228 The mean duration of interruptions in playout expressed in 229 milliseconds. 231 3.2.17 Video Playout Buffer Size 232 The available playout buffer size, expressed in milliseconds. 234 3.2.18 Mean Buffer Level 235 The mean playout buffer size, expressed in milliseconds. 237 4. Summary 239 This draft defines an RTCP XR report block for video quality 240 reporting. This is intended for in-service monitoring of video 241 streaming, IPTV and IP videoconferencing services to provide 242 real time performance feedback and support performance management. 244 5. IANA Considerations 246 The block type "mmm" will need to be replaced with an IANA assigned 247 number within those allocated for RTCP XR report blocks (RFC 3611). 249 6. Security Considerations 251 RTCP reports can contain sensitive information since they can provide 252 information about the nature and duration of a session established 253 between two endpoints. As a result, any third party wishing to 254 obtain this information should be properly authenticated and the 256 Clark [Page 5] 257 information transferred securely. 259 7. Acknowledgments 261 The authors would like to acknowledge Keith Lantz, Kaynam Hedayat, 262 Satish Kumar for their helpful comments. 264 8. Informative References 266 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 267 Levels", BCP 14, RFC 2119, March 1997. 269 [2] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, 270 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 271 RFC 3550, July 2003. 273 [3] Friedman, T., Caceres, R. and A. Clark, "RTP Control Protocol 274 Extended Reports (RTCP XR)", RFC 3611, November 2003. 276 [4] ATIS-080008 QoS Metrics for Linear Broadcast IPTV. ATIS 2007 278 Authors' Addresses 280 Alan Clark 281 Telchemy Incorporated 282 2905 Premiere Parkway, Suite 280 283 Duluth, GA 30097 284 Email: alan@telchemy.com 286 Amy Pendleton 287 Nortel 288 2380 Performance Drive 289 Richardson, TX 75081 290 Email: aspen@nortel.com 292 Full Copyright Statement 294 Copyright (C) The IETF Trust (2007). 296 This document is subject to the rights, licenses and restrictions 297 contained in BCP 78, and except as set forth therein, the authors 298 retain all their rights. 300 This document and the information contained herein are provided on an 301 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 302 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 303 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 304 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 305 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 306 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 308 Intellectual Property 310 Clark [Page 6] 311 The IETF takes no position regarding the validity or scope of any 312 Intellectual Property Rights or other rights that might be claimed to 313 pertain to the implementation or use of the technology described in 314 this document or the extent to which any license under such rights 315 might or might not be available; nor does it represent that it has 316 made any independent effort to identify any such rights. Information 317 on the procedures with respect to rights in RFC documents can be 318 found in BCP 78 and BCP 79. 320 Copies of IPR disclosures made to the IETF Secretariat and any 321 assurances of licenses to be made available, or the result of an 322 attempt made to obtain a general license or permission for the use of 323 such proprietary rights by implementers or users of this 324 specification can be obtained from the IETF on-line IPR repository at 325 http://www.ietf.org/ipr. 327 The IETF invites any interested party to bring to its attention any 328 copyrights, patents or patent applications, or other proprietary 329 rights that may cover technology that may be required to implement 330 this standard. Please address the information to the IETF at ietf- 331 ipr@ietf.org. 333 Acknowledgement 335 Funding for the RFC Editor function is provided by the IETF 336 Administrative Support Activity (IASA). 338 Clark [Page 7]