idnits 2.17.1 draft-ietf-xrblock-rtcp-xr-discard-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 31, 2012) is 4348 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 (-22) exists of draft-ietf-avtcore-monarch-12 Summary: 1 error (**), 0 flaws (~~), 2 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 2, 2012 Telchemy 6 G. Zorn 7 Network Zen 8 Q. Wu 9 Huawei 10 May 31, 2012 12 RTCP XR Report Block for Discard metric Reporting 13 draft-ietf-xrblock-rtcp-xr-discard-03.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 2, 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 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 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 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 shall 133 be regarded as discarded. A packet shall be classified as one of 134 received (or OK), discarded or lost. The Discard Metric counts 135 only discarded packets. The metric "cumulative number of packets 136 lost" defined in [RFC3550] reports a count of packets lost from 137 the media stream (single SSRC within single RTP session). 138 Similarly the metric "number of packets discarded" reports a count 139 of packets discarded from the media stream (single SSRC within 140 single RTP session) arriving at the receiver. Another metric 141 defined in [RFC5725] is available to report on packets which are 142 not recovered by any repair techniques which may be in use. 144 3. Discard Metric Report Block 146 3.1. Report Block Structure 148 0 1 2 3 149 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 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | BT=NBGD | I |DT | resv.| block length = 2 | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | SSRC of Source | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | number of packets discarded | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 Figure 1: Report Block Structure 160 3.2. Definition of Fields in Discard Metric Report Block 162 Block type (BT): 8 bits 164 A Discard Metric Report Block is identified by the constant ND. 166 [Note to RFC Editor: please replace ND with the IANA provided RTCP 167 XR block type for this block.] 169 Interval Metric flag (I): 2 bits 171 This field is used to indicate whether the Discard metric is an 172 Interval or Cumulative metric, that is, whether the reported 173 values applies to the most recent measurement interval duration 174 between successive metrics reports (I=10) (the Interval Duration) 175 or to the accumulation period characteristic of cumulative 176 measurements (I=11) (the Cumulative Duration). 178 Discard Type (DT): 2bits 180 This field is used to identify the discard type used in this 181 report block. The discard type is defined as follows: 183 00: packets are discarded due to other reasons than late 184 arrival, early arrival, or both (e.g., duplicate, redundant 185 packets). 187 01: packets are discarded due to too early arrival. 189 10: packets are discarded due to too late arrival. 191 11: packets are discarded due to both early arrival and late 192 arrival. 194 Reserved (resv): 5 bits 196 These bits are reserved. They SHOULD be set to zero by senders 197 and MUST be ignored by receivers. 199 block length: 16 bits 201 The length of this report block in 32-bit words, minus one. For 202 the Delay block, the block length is equal to 2. 204 SSRC of source: 32 bits 206 As defined in Section 4.1 of [RFC3611]. 208 number of packets discarded: 32 bits 210 Number of packets discarded over the period (Interval or 211 Cumulative) covered by this report. 213 If the measured value exceeds 0xFFFFFFFD, the value 0xFFFFFFFE 214 SHOULD be reported to indicate an over-range measurement. If the 215 measurement is unavailable, the value 0xFFFFFFFF MUST be reported. 217 Note that the number of packets expected in the period covered by 218 the metric (whether interval or cumulative) is available from the 219 difference between a pair of extended sequence numbers in the 220 Measurement Identity block, so need not be repeated in this block. 222 4. SDP Signaling 224 [RFC3611] defines the use of SDP (Session Description Protocol) 225 [RFC4566] for signaling the use of XR blocks. XR blocks MAY be used 226 without prior signaling. 228 This section augments the SDP [RFC4566] attribute "rtcp-xr" defined 229 in [RFC3611] by providing an additional value of "xr-format" to 230 signal the use of the report block defined in this document. 232 rtcp-xr-attrib = "a=" "rtcp-xr" ":" [xr-format *(SP xr-format)] CRLF 234 (defined in [RFC3611]) 236 xr-format =/ xr-pd-block 238 xr-pd-block = "pkt-dscrd" 240 5. IANA Considerations 242 New block types for RTCP XR are subject to IANA registration. For 243 general guidelines on IANA considerations for RTCP XR, refer to 244 [RFC3611]. 246 5.1. New RTCP XR Block Type value 248 This document assigns the block type value ND in the IANA "RTCP XR 249 Block Type Registry" to the "Discard Metrics Block". 251 [Note to RFC Editor: please replace ND with the IANA provided RTCP XR 252 block type for this block.] 254 5.2. New RTCP XR SDP Parameter 256 This document also registers a new parameter "pkt-dscrd" in the "RTCP 257 XR SDP Parameters Registry". 259 5.3. Contact information for registrations 261 The contact information for the registrations is: 263 Geoff Hunt (r.geoff.hunt@gmail.com) 265 Orion 2 PP3, Adastral Park, Martlesham Heath, Ipswich IP5 3RE, United 266 Kingdom 268 6. Security Considerations 270 It is believed that this proposed RTCP XR report block introduces no 271 new security considerations beyond those described in [RFC3611]. 272 This block does not provide per-packet statistics so the risk to 273 confidentiality documented in Section 7, paragraph 3 of [RFC3611] 274 does not apply. 276 7. Acknowledgments 278 The authors gratefully acknowledge the comments and contributions 279 made by Bruce Adams, Philip Arden, Amit Arora, Bob Biskner, Kevin 280 Connor, Claus Dahm, Randy Ethier, Roni Even, Jim Frauenthal, Albert 281 Higashi, Tom Hock, Shane Holthaus, Paul Jones, Rajesh Kumar, Keith 282 Lantz, Mohamed Mostafa, Amy Pendleton, Colin Perkins, Mike Ramalho, 283 Ravi Raviraj, Albrecht Schwarz, Tom Taylor, and Hideaki Yamada,Kevin 284 Gross, Varun Singh. 286 8. References 288 8.1. Normative References 290 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 291 Requirement Levels", March 1997. 293 [RFC3550] Schulzrinne, H., "RTP: A Transport Protocol for Real-Time 294 Applications", RFC 3550, July 2003. 296 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 297 Protocol Extended Reports (RTCP XR)", November 2003. 299 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 300 Description Protocol", July 2006. 302 8.2. Informative References 304 [MONARCH] Wu, Q., "Monitoring Architectures for RTP", 305 ID draft-ietf-avtcore-monarch-12, April 2012. 307 [RFC4588] Rey, J., "RTP Retransmission Payload Format", RFC 4588, 308 July 2006. 310 [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error 311 Correction", RFC 5109, July 2006. 313 [RFC5725] Begen, A., "RTCP XR Report Block for Post-Repair Loss 314 metric Reporting", RFC 5725, February 2010. 316 [RFC6390] Clark, A. and B. Claise, "Framework for Performance Metric 317 Development", RFC 6390, October 2011. 319 Authors' Addresses 321 Geoff Hunt 322 Unaffiliated 324 Email: r.geoff.hunt@gmail.com 326 Alan Clark 327 Telchemy Incorporated 328 2905 Premiere Parkway, Suite 280 329 Duluth, GA 30097 330 USA 332 Email: alan.d.clark@telchemy.com 334 Glen Zorn 335 Network Zen 336 77/440 Soi Phoomjit, Rama IV Road 337 Phra Khanong, Khlong Toie 338 Bangkok 10110 339 Thailand 341 Phone: +66 (0) 87 502 4274 342 Email: gwz@net-zen.net 344 Qin Wu 345 Huawei 346 101 Software Avenue, Yuhua District 347 Nanjing, Jiangsu 210012 348 China 350 Email: sunseawq@huawei.com