idnits 2.17.1 draft-ietf-xrblock-rtcp-xr-discard-00.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 (October 17, 2011) is 4575 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: 'DISCARD' is defined on line 297, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) -- No information found for draft-ietf-rtcp-xr-discard - is the name correct? == Outdated reference: A later version (-22) exists of draft-ietf-avtcore-monarch-04 -- No information found for draft-ietf-rtcp-xr-postrepair-loss - is the name correct? Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). 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: April 19, 2012 Telchemy 6 G. Zorn, Ed. 7 Network Zen 8 Q. Wu 9 Huawei 10 October 17, 2011 12 RTCP XR Report Block for Discard metric Reporting 13 draft-ietf-xrblock-rtcp-xr-discard-00.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 April 19, 2012. 38 Copyright Notice 40 Copyright (c) 2011 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. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 8. Changes from previous version . . . . . . . . . . . . . . . . 11 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 75 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 78 1. Introduction 80 1.1. Discard Report Block 82 This draft defines a new block type to augment those defined in 83 [RFC3611] for use in a range of RTP applications. The new block type 84 supports the reporting of the number of packets which are received 85 correctly but are never played out, typically because they arrive too 86 late to be played out (buffer underflow) or too early (buffer 87 overflow). The metric is applicable both to systems which use packet 88 loss repair techniques (such as forward error correction [RFC5109] or 89 retransmission [RFC4588]) and to those which do not. 91 This metric is useful for identifying the existence, and 92 characterising the severity, of a packet transport problem which may 93 affect users' perception of a service delivered over RTP. 95 The metric belongs to the class of transport-related terminal metrics 96 defined in [MONARCH] (work in progress). 98 1.2. RTCP and RTCP XR Reports 100 The use of RTCP for reporting is defined in [RFC3550]. [RFC3611] 101 defined an extensible structure for reporting using an RTCP Extended 102 Report (XR). This draft defines a new Extended Report block that 103 MUST be used as defined in [RFC3550] and [RFC3611]. 105 1.3. Performance Metrics Framework 107 The Performance Metrics Framework [PMOLFRAME] provides guidance on 108 the definition and specification of performance metrics. Metrics 109 described in this draft either reference external definitions or 110 define metrics generally in accordance with the guidelines in 111 [PMOLFRAME]. 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 [POSTREPAIRLOSS] is available to report on packets 142 which are not recovered by any repair techniques which may be in 143 use. 145 3. Discard Metric Report Block 147 3.1. Report Block Structure 149 0 1 2 3 150 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 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | BT=NBGD |I| resv. | block length = 2 | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | SSRC of Source | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | number of packets discarded | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 Figure 1: Report Block Structure 161 3.2. Definition of Fields in Discard Metric Report Block 163 Block type (BT): 8 bits 165 A Discard Metric Report Block is identified by the constant ND. 167 [Note to RFC Editor: please replace ND with the IANA provided RTCP 168 XR block type for this block.] 170 Interval Metric flag (I): 1 bit 172 This field is used to indicate whether the Packet Delay Variation 173 metrics block is an Interval or a Cumulative report, that is, 174 whether the reported values apply to the most recent measurement 175 interval duration between successive metrics reports (I=1) (the 176 Interval Duration) or to the accumulation period characteristic of 177 cumulative measurements (I=0) (the Cumulative Duration). 179 Reserved (resv): 7 bits 181 These bits are reserved. They SHOULD be set to zero by senders 182 and MUST be ignored by receivers. 184 block length: 16 bits 186 The length of this report block in 32-bit words, minus one. For 187 the Delay block, the block length is equal to 2. 189 SSRC of source: 32 bits 191 As defined in Section 4.1 of [RFC3611]. 193 number of packets discarded: 32 bits 195 Number of packets discarded over the period (Interval or 196 Cumulative) covered by this report. 198 If the measured value exceeds 0xFFFFFFFD, the value 0xFFFFFFFE 199 SHOULD be reported to indicate an over-range measurement. If the 200 measurement is unavailable, the value 0xFFFFFFFF SHOULD be 201 reported. 203 Note that the number of packets expected in the period covered by 204 the metric (whether interval or cumulative) is available from the 205 difference between a pair of extended sequence numbers in the 206 Measurement Identity block, so need not be repeated in this block. 208 4. SDP Signaling 210 [RFC3611] defines the use of SDP (Session Description Protocol) 211 [RFC4566] for signaling the use of XR blocks. XR blocks MAY be used 212 without prior signaling. 214 This section augments the SDP [RFC4566] attribute "rtcp-xr" defined 215 in [RFC3611] by providing an additional value of "xr-format" to 216 signal the use of the report block defined in this document. 218 rtcp-xr-attrib = "a=" "rtcp-xr" ":" [xr-format *(SP xr-format)] CRLF 220 (defined in [RFC3611]) 222 xr-format =/ xr-pd-block 224 xr-pd-block = "pkt-dscrd" 226 5. IANA Considerations 228 New block types for RTCP XR are subject to IANA registration. For 229 general guidelines on IANA considerations for RTCP XR, refer to 230 [RFC3611]. 232 5.1. New RTCP XR Block Type value 234 This document assigns the block type value ND in the IANA "RTCP XR 235 Block Type Registry" to the "Discard Metrics Block". 237 [Note to RFC Editor: please replace ND with the IANA provided RTCP XR 238 block type for this block.] 240 5.2. New RTCP XR SDP Parameter 242 This document also registers a new parameter "pkt-dscrd" in the "RTCP 243 XR SDP Parameters Registry". 245 5.3. Contact information for registrations 247 The contact information for the registrations is: 249 Geoff Hunt (r.geoff.hunt@gmail.com) 251 Orion 2 PP3, Adastral Park, Martlesham Heath, Ipswich IP5 3RE, United 252 Kingdom 254 6. Security Considerations 256 It is believed that this proposed RTCP XR report block introduces no 257 new security considerations beyond those described in [RFC3611]. 258 This block does not provide per-packet statistics so the risk to 259 confidentiality documented in Section 7, paragraph 3 of [RFC3611] 260 does not apply. 262 7. Contributors 264 The authors gratefully acknowledge the comments and contributions 265 made by Bruce Adams, Philip Arden, Amit Arora, Bob Biskner, Kevin 266 Connor, Claus Dahm, Randy Ethier, Roni Even, Jim Frauenthal, Albert 267 Higashi, Tom Hock, Shane Holthaus, Paul Jones, Rajesh Kumar, Keith 268 Lantz, Mohamed Mostafa, Amy Pendleton, Colin Perkins, Mike Ramalho, 269 Ravi Raviraj, Albrecht Schwarz, Tom Taylor, and Hideaki Yamada. 271 8. Changes from previous version 273 Changed BNF for SDP following Christian Groves' and Tom Taylor's 274 comments (4th and 5th May 2009), now aligned with RFC 5234 section 275 3.3 "Incremental Alternatives". 277 Updated references. 279 9. References 281 9.1. Normative References 283 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 284 Requirement Levels", March 1997. 286 [RFC3550] Schulzrinne, H., "RTP: A Transport Protocol for Real-Time 287 Applications", RFC 3550, July 2003. 289 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 290 Protocol Extended Reports (RTCP XR)", November 2003. 292 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 293 Description Protocol", July 2006. 295 9.2. Informative References 297 [DISCARD] Hunt, G., "RTCP XR Report Block for Discard metric 298 Reporting", ID draft-ietf-rtcp-xr-discard-02, May 2009. 300 [MONARCH] Wu, Q., "Monitoring Architectures for RTP", 301 ID draft-ietf-avtcore-monarch-04, August 2011. 303 [PMOLFRAME] 304 Clark, A. and B. Claise, "Framework for Performance Metric 305 Development", ID draft-ietf-pmol-metrics-framework-12, 306 July 2011. 308 [POSTREPAIRLOSS] 309 Hunt, G., "RTCP XR Report Block for Post-Repair Loss 310 metric Reporting", 311 ID draft-ietf-rtcp-xr-postrepair-loss-02, May 2009. 313 [RFC4588] Rey, J., "RTP Retransmission Payload Format", RFC 4588, 314 July 2006. 316 [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error 317 Correction", RFC 5109, July 2006. 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 (editor) 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