idnits 2.17.1 draft-ietf-xrblock-rtcp-xr-discard-04.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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: This field is used to indicate whether the Discard Count Metric is an Interval or Cumulative metric, Sample metric,that is, whether the reported values applies to the most recent measurement interval duration between successive metrics reports (I=10) (the Interval Duration) or to the accumulation period characteristic of cumulative measurements (I=11) (the Cumulative Duration) or is a sampled instantaneous value (I=01) (Sampled Value). In this document, Discard Count Metric is not measured at a particular time instant but over one or several reporting intervals. Therefore Discard Count Metric MUST not be chosen as Sampled Metric. -- The document date (June 29, 2012) is 4316 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) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-10) exists of draft-ietf-xrblock-rtcp-xr-meas-identity-06 == Outdated reference: A later version (-22) exists of draft-ietf-avtcore-monarch-12 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Audio/Video Transport Working Group G. Hunt 3 Internet-Draft Unaffiliated 4 Intended status: Standards Track A. Clark 5 Expires: December 31, 2012 Telchemy 6 G. Zorn 7 Network Zen 8 Q. Wu 9 Huawei 10 June 29, 2012 12 RTCP XR Report Block for Discard Count metric Reporting 13 draft-ietf-xrblock-rtcp-xr-discard-04.txt 15 Abstract 17 This document defines an RTCP XR Report Block that allows the 18 reporting of a simple discard count metric for use in a range of RTP 19 applications. 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 December 31, 2012. 38 Copyright Notice 40 Copyright (c) 2012 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 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Discard Count Report Block . . . . . . . . . . . . . . . . 3 57 1.2. RTCP and RTCP XR Reports . . . . . . . . . . . . . . . . . 3 58 1.3. Performance Metrics Framework . . . . . . . . . . . . . . 3 59 1.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.1. Standards Language . . . . . . . . . . . . . . . . . . . . 4 62 3. Discard Count Metric Report Block . . . . . . . . . . . . . . 5 63 3.1. Report Block Structure . . . . . . . . . . . . . . . . . . 5 64 3.2. Definition of Fields in Discard Metric Report Block . . . 5 65 4. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 7 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 67 5.1. New RTCP XR Block Type value . . . . . . . . . . . . . . . 8 68 5.2. New RTCP XR SDP Parameter . . . . . . . . . . . . . . . . 8 69 5.3. Contact information for registrations . . . . . . . . . . 8 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 71 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 74 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 77 1. Introduction 79 1.1. Discard Count Report Block 81 This draft defines a new block type to augment those defined in 82 [RFC3611] for use in a range of RTP applications. The new block type 83 supports the reporting of the number of packets which are received 84 correctly but are never played out, typically because they arrive too 85 late to be played out (buffer underflow) or too early (buffer 86 overflow). The metric is applicable both to systems which use packet 87 loss repair techniques (such as forward error correction [RFC5109] or 88 retransmission [RFC4588]) and to those which do not. 90 This metric is useful for identifying the existence, and 91 characterising the severity, of a packet transport problem which may 92 affect users' perception of a service delivered over RTP. 94 The metric belongs to the class of transport-related terminal metrics 95 defined in [MONARCH] (work in progress). 97 1.2. RTCP and RTCP XR Reports 99 The use of RTCP for reporting is defined in [RFC3550]. [RFC3611] 100 defined an extensible structure for reporting using an RTCP Extended 101 Report (XR). This draft defines a new Extended Report block that 102 MUST be used as defined in [RFC3550] and [RFC3611]. 104 1.3. Performance Metrics Framework 106 The Performance Metrics Framework [RFC6390] provides guidance on the 107 definition and specification of performance metrics. The RTP 108 Monitoring Architectures [MONARCH] provides guideline for reporting 109 block format using RTCP XR. The Metrics Block described in this 110 document are in accordance with the guidelines in [RFC6390] and 111 [MONARCH]. 113 1.4. Applicability 115 This metric is believed to be applicable to a large class of RTP 116 applications which use a jitter buffer. 118 2. Terminology 120 2.1. Standards Language 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC 2119 [RFC2119]. 126 In addition, the following terms are defined: 128 Received, Lost and Discarded 130 A packet shall be regarded as lost if it fails to arrive within an 131 implementation-specific time window. A packet that arrives within 132 this time window but is too early or late to be played out or 133 thrown away before playout (e.g., packet duplication or 134 redundancy) shall be regarded as discarded. A packet shall be 135 classified as one of received (or OK), discarded or lost. The 136 Discard Count Metric counts only discarded packets. The metric 137 "cumulative number of packets lost" defined in [RFC3550] reports a 138 count of packets lost from the media stream (single SSRC within 139 single RTP session). Similarly the metric "number of packets 140 discarded" reports a count of packets discarded from the media 141 stream (single SSRC within single RTP session) arriving at the 142 receiver. Another metric defined in [RFC5725] is available to 143 report on packets which are not recovered by any repair techniques 144 which may be in use. 146 3. Discard Count Metric Report Block 148 3.1. Report Block Structure 150 0 1 2 3 151 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 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | BT=PDC | I |DT | resv.| block length = 2 | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | SSRC of Source | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | number of packets discarded | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 Figure 1: Report Block Structure 162 3.2. Definition of Fields in Discard Metric Report Block 164 Block type (BT): 8 bits 166 A Discard Count Metric Report Block is identified by the constant 167 PDC. 169 [Note to RFC Editor: please replace PDC with the IANA provided 170 RTCP XR block type for this block.] 172 Interval Metric flag (I): 2 bits 174 This field is used to indicate whether the Discard Count Metric is 175 an Interval or Cumulative metric, Sample metric,that is, whether 176 the reported values applies to the most recent measurement 177 interval duration between successive metrics reports (I=10) (the 178 Interval Duration) or to the accumulation period characteristic of 179 cumulative measurements (I=11) (the Cumulative Duration) or is a 180 sampled instantaneous value (I=01) (Sampled Value). In this 181 document, Discard Count Metric is not measured at a particular 182 time instant but over one or several reporting intervals. 183 Therefore Discard Count Metric MUST not be chosen as Sampled 184 Metric. 186 Discard Type (DT): 2bits 188 This field is used to identify the discard type used in this 189 report block. The discard type is defined as follows: 191 00: Report packet discarded due to too early to be played out. 193 01: Report packet discarded due to too late to be played out. 195 10: Report packet discarded due to both early and late to be 196 played out. 198 11: Report the total number of discarded packets in the 199 interval. The reasons to discard packet include too early to 200 be played out, too late to be playout,being thrown away before 201 playout. 203 Reserved (resv): 5 bits 205 These bits are reserved. They SHOULD be set to zero by senders 206 and MUST be ignored by receivers. 208 block length: 16 bits 210 The length of this report block in 32-bit words, minus one. For 211 the Delay block, the block length is equal to 2. 213 SSRC of source: 32 bits 215 As defined in Section 4.1 of [RFC3611]. 217 number of packets discarded: 32 bits 219 Number of packets discarded over the period (Interval or 220 Cumulative) covered by this report. 222 If the measured value exceeds 0xFFFFFFFD, the value 0xFFFFFFFE 223 MUST be reported to indicate an over-range measurement. If the 224 measurement is unavailable, the value 0xFFFFFFFF MUST be reported. 226 Note that the number of packets expected in the period covered by 227 the metric (whether interval or cumulative) is available from the 228 difference between a pair of extended sequence numbers in the 229 Measurement Information block [MEASI], so need not be repeated in 230 this block. 232 4. SDP Signaling 234 [RFC3611] defines the use of SDP (Session Description Protocol) 235 [RFC4566] for signaling the use of XR blocks. XR blocks MAY be used 236 without prior signaling. 238 This section augments the SDP [RFC4566] attribute "rtcp-xr" defined 239 in [RFC3611] by providing an additional value of "xr-format" to 240 signal the use of the report block defined in this document. 242 rtcp-xr-attrib = "a=" "rtcp-xr" ":" [xr-format *(SP xr-format)] CRLF 244 (defined in [RFC3611]) 246 xr-format =/ xr-pdc-block 248 xr-pdc-block = "pkt-dscrd-count" 250 5. IANA Considerations 252 New block types for RTCP XR are subject to IANA registration. For 253 general guidelines on IANA considerations for RTCP XR, refer to 254 [RFC3611]. 256 5.1. New RTCP XR Block Type value 258 This document assigns the block type value PDC in the IANA "RTCP XR 259 Block Type Registry" to the "Discard Count Metrics Block". 261 [Note to RFC Editor: please replace PDC with the IANA provided RTCP 262 XR block type for this block.] 264 5.2. New RTCP XR SDP Parameter 266 This document also registers a new parameter "pkt-dscrd" in the "RTCP 267 XR SDP Parameters Registry". 269 5.3. Contact information for registrations 271 The following contact information is provided for all 272 registrations in this document: 274 Geoff Hunt (r.geoff.hunt@gmail.com) 276 Orion 2 PP3, Adastral Park, Martlesham Heath, Ipswich IP5 3RE, United 277 Kingdom 279 6. Security Considerations 281 It is believed that this proposed RTCP XR report block introduces no 282 new security considerations beyond those described in [RFC3611]. 283 This block does not provide per-packet statistics so the risk to 284 confidentiality documented in Section 7, paragraph 3 of [RFC3611] 285 does not apply. 287 7. Acknowledgments 289 The authors gratefully acknowledge the comments and contributions 290 made by Bruce Adams, Philip Arden, Amit Arora, Bob Biskner, Kevin 291 Connor, Claus Dahm, Randy Ethier, Roni Even, Jim Frauenthal, Albert 292 Higashi, Tom Hock, Shane Holthaus, Paul Jones, Rajesh Kumar, Keith 293 Lantz, Mohamed Mostafa, Amy Pendleton, Colin Perkins, Mike Ramalho, 294 Ravi Raviraj, Albrecht Schwarz, Tom Taylor, and Hideaki Yamada,Kevin 295 Gross, Varun Singh,Claire Bi, Roni Even, Dan Romascanu. 297 8. References 299 8.1. Normative References 301 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 302 Requirement Levels", March 1997. 304 [RFC3550] Schulzrinne, H., "RTP: A Transport Protocol for Real-Time 305 Applications", RFC 3550, July 2003. 307 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 308 Protocol Extended Reports (RTCP XR)", November 2003. 310 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 311 Description Protocol", July 2006. 313 8.2. Informative References 315 [MEASI] Hunt, G., "Measurement Identity and information Reporting 316 using SDES item and XR Block", 317 ID draft-ietf-xrblock-rtcp-xr-meas-identity-06, 318 April 2012. 320 [MONARCH] Wu, Q., "Monitoring Architectures for RTP", 321 ID draft-ietf-avtcore-monarch-12, April 2012. 323 [RFC4588] Rey, J., "RTP Retransmission Payload Format", RFC 4588, 324 July 2006. 326 [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error 327 Correction", RFC 5109, July 2006. 329 [RFC5725] Begen, A., "RTCP XR Report Block for Post-Repair Loss 330 metric Reporting", RFC 5725, February 2010. 332 [RFC6390] Clark, A. and B. Claise, "Framework for Performance Metric 333 Development", RFC 6390, October 2011. 335 Authors' Addresses 337 Geoff Hunt 338 Unaffiliated 340 Email: r.geoff.hunt@gmail.com 342 Alan Clark 343 Telchemy Incorporated 344 2905 Premiere Parkway, Suite 280 345 Duluth, GA 30097 346 USA 348 Email: alan.d.clark@telchemy.com 350 Glen Zorn 351 Network Zen 352 77/440 Soi Phoomjit, Rama IV Road 353 Phra Khanong, Khlong Toie 354 Bangkok 10110 355 Thailand 357 Phone: +66 (0) 87 502 4274 358 Email: gwz@net-zen.net 360 Qin Wu 361 Huawei 362 101 Software Avenue, Yuhua District 363 Nanjing, Jiangsu 210012 364 China 366 Email: sunseawq@huawei.com