idnits 2.17.1 draft-ietf-xrblock-rtcp-xr-burst-gap-loss-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 4574 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 403, 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 == Outdated reference: A later version (-06) exists of draft-zorn-xrblock-rtcp-xr-al-stat-03 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 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 S. Zhang, Ed. 7 STTRI 8 Q. Wu 9 Huawei 10 October 17, 2011 12 RTCP XR Report Block for Burst/Gap Loss metric Reporting 13 draft-ietf-xrblock-rtcp-xr-burst-gap-loss-00.txt 15 Abstract 17 This document defines an RTCP XR Report Block that allows the 18 reporting of Burst and Gap Loss metrics 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. Burst and Gap Loss Report Block . . . . . . . . . . . . . 3 57 1.2. RTCP and RTCP XR Reports . . . . . . . . . . . . . . . . . 3 58 1.3. Performance Metrics Framework . . . . . . . . . . . . . . 3 59 1.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 2.1. Standards Language . . . . . . . . . . . . . . . . . . . . 5 62 3. Burst/Gap Loss Block . . . . . . . . . . . . . . . . . . . . . 6 63 3.1. Report Block Structure . . . . . . . . . . . . . . . . . . 6 64 3.2. Definition of Fields in Burst/Gap Loss Report Block . . . 6 65 3.3. Derived metrics based on reported metrics . . . . . . . . 8 66 4. Considerations for Voice-over-IP applications . . . . . . . . 10 67 5. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 11 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 69 6.1. New RTCP XR Block Type value . . . . . . . . . . . . . . . 12 70 6.2. New RTCP XR SDP Parameter . . . . . . . . . . . . . . . . 12 71 6.3. Contact information for registrations . . . . . . . . . . 12 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 73 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14 74 9. Changes from previous version . . . . . . . . . . . . . . . . 15 75 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 76 10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 77 10.2. Informative References . . . . . . . . . . . . . . . . . . 16 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 80 1. Introduction 82 1.1. Burst and Gap Loss Report Block 84 This draft defines a new block type to augment those defined in 85 [RFC3611] for use in a range of RTP applications. The new block type 86 supports the reporting of the proportion of packets lost by the 87 network. The losses during loss bursts are reported, together with 88 the number of bursts and additional data allowing the calculation of 89 statistical parameters (mean and variance) of the distribution of 90 burst lengths. Some uses of these metrics depend on the availability 91 of the metric "cumulative number of packets lost" from RTCP 92 [RFC3550]. 94 This block provides information on transient IP problems. Burst/Gap 95 metrics are typically used in Cumulative reports however MAY be used 96 in Interval reports. The burstiness of packet loss affects user 97 experience, may influence any sender strategies to mitigate the 98 problem, and may also have diagnostic value. 100 The metric belongs to the class of transport-related terminal metrics 101 defined in [MONARCH] (work in progress). 103 The definitions of Burst, Gap, Loss and Discard are consistent with 104 definitions in [RFC3611]. To accommodate the range of jitter buffer 105 algorithms and packet discard logic that may be used by implementors, 106 the method used to distinguish between bursts and gaps may be an 107 equivalent method to that defined in [RFC3611]. The method used 108 SHOULD produce the same result as that defined in [RFC3611] for 109 conditions of burst packet loss, but MAY produce different results 110 for conditions of time varying jitter. 112 1.2. RTCP and RTCP XR Reports 114 The use of RTCP for reporting is defined in [RFC3550]. [RFC3611] 115 defined an extensible structure for reporting using an RTCP Extended 116 Report (XR). This draft defines a new Extended Report block that 117 MUST be used as defined in [RFC3550] and [RFC3611]. 119 1.3. Performance Metrics Framework 121 The Performance Metrics Framework [PMOLFRAME] provides guidance on 122 the definition and specification of performance metrics. Metrics 123 described in this draft either reference external definitions or 124 define metrics generally in accordance with the guidelines in 125 [PMOLFRAME]. 127 1.4. Applicability 129 These metrics are applicable to a range of RTP applications. 131 2. Terminology 133 2.1. Standards Language 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in RFC 2119 [RFC2119]. 139 In addition, the following terms are defined: 141 Received, Lost and Discarded 143 A packet shall be regarded as lost if it fails to arrive within an 144 implementation-specific time window. A packet that arrives within 145 this time window but is too early or late to be played out shall 146 be regarded as discarded. A packet shall be classified as one of 147 received (or OK), discarded or lost. 149 Bursts and Gaps 151 The terms Burst and Gap are used in a manner consistent with that 152 of RTCP XR [RFC3611]. RTCP XR views a RTP stream as being divided 153 into bursts, which are periods during which the loss rate is high 154 enough to cause noticeable quality degradation (generally over 5 155 percent loss rate), and gaps, which are periods during which lost 156 packets are infrequent and hence quality is generally acceptable. 158 3. Burst/Gap Loss Block 160 Metrics in this block report on Burst/Gap Loss in the stream arriving 161 at the RTP system. 163 3.1. Report Block Structure 165 Delay metrics block 167 0 1 2 3 168 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 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | BT=NDEL |I| resv. | block length = 5 | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | SSRC of Source | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | Threshold | Sum of Burst Durations (ms) | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | Packets Lost in Bursts | Total... | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | ...Packets expected in bursts | Number of bursts | Sum of| 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | ...Squares of Burst Durations (ms-squared) | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 Figure 1: Report Block Structure 185 3.2. Definition of Fields in Burst/Gap Loss Report Block 187 Block type (BT): 8 bits 189 A Burst/Gap Loss Report Block is identified by the constant NBGL. 191 [Note to RFC Editor: please replace NBGL with the IANA provided 192 RTCP XR block type for this block.] 194 Interval Metric flag (I): 1 bit 196 This field is used to indicate whether the Packet Delay Variation 197 metrics block is an Interval or a Cumulative report, that is, 198 whether the reported values apply to the most recent measurement 199 interval duration between successive metrics reports (I=1) (the 200 Interval Duration) or to the accumulation period characteristic of 201 cumulative measurements (I=0) (the Cumulative Duration). 203 Reserved (resv): 7 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 5. 213 SSRC of source: 32 bits 215 As defined in Section 4.1 of [RFC3611]. 217 Threshold: 8 bits 219 The Threshold is equivalent to Gmin in [RFC3611], i.e. the number 220 of successive packets that must be received prior to and following 221 a lost frame in order for this lost frame to be regarded as part 222 of a gap. 224 Sum of Burst Durations (ms): 24 bits 226 The total duration of bursts of lost frames in the period of the 227 report (Interval or Cumulative). 229 If the measured value exceeds 0xFFFFFD, the value 0xFFFFFE SHOULD 230 be reported to indicate an over-range measurement. If the 231 measurement is unavailable, the value 0xFFFFFF SHOULD be reported. 233 Packets lost in bursts: 24 bits 235 The total number of packets lost during loss bursts. 237 If the measured value exceeds 0xFFFFFD, the value 0xFFFFFE SHOULD 238 be reported to indicate an over-range measurement. If the 239 measurement is unavailable, the value 0xFFFFFF SHOULD be reported. 241 Total packets expected in bursts: 24 bits 243 The total number of packets expected during loss bursts (that is, 244 the sum of received packets and lost packets). 246 If the measured value exceeds 0xFFFFFD, the value 0xFFFFFE SHOULD 247 be reported to indicate an over-range measurement. If the 248 measurement is unavailable, the value 0xFFFFFF SHOULD be reported. 250 Number of bursts: 16 bits 252 The number of bursts in the period of the report (Interval or 253 Cumulative). 255 If the measured value exceeds 0xFFFD, the value 0xFFFE SHOULD be 256 reported to indicate an over-range measurement. If the 257 measurement is unavailable, the value 0xFFFF SHOULD be reported. 259 Sum of Squares of Burst Durations (ms-squared): 36 bits 261 The sum of the squares of burst durations (where individual burst 262 durations are expressed in ms) over in the period of the report 263 (Interval or Cumulative). The units for this quantity are 264 milliseconds-squared. 266 If the measured value exceeds 0xFFFFFFFFD, the value 0xFFFFFFFFE 267 SHOULD be reported to indicate an over-range measurement. If the 268 measurement is unavailable, the value 0xFFFFFFFFF SHOULD be 269 reported. 271 3.3. Derived metrics based on reported metrics 273 The metrics described here are intended to be used as described in 274 this section, in conjunction with information from the Measurement 275 Information block (which MUST be present in the same RTCP packet as 276 the Burst/Gap Loss block) and also with the metric "cumulative number 277 of packets lost" provided in standard RTCP [RFC3550]. 279 These metrics provides information relevant to statistical 280 parameters, including: 282 o The fraction of packets lost during bursts 284 o The fraction of packets lost during gaps 286 o burst duration mean 288 o burst duration variance 290 The details on calculation these parameters in the metrics are 291 described in [SUMSTAT]. 293 4. Considerations for Voice-over-IP applications 295 This metric block is applicable to a broad range of RTP applications. 296 Where the metric is used with a Voice-overIP (VoIP) application, the 297 following considerations apply. 299 RTCP XR views a call as being divided into bursts, which are periods 300 during which the loss rate is high enough to cause noticeable call 301 quality degradation (generally over 5 percent loss rate), and gaps, 302 which are periods during which lost packets are infrequent and hence 303 call quality is generally acceptable. 305 If Voice Activity Detection is used the Burst and Gap Duration shall 306 be determined as if silence frames had been sent, i.e. a period of 307 silence in excess of Gmin frames MUST terminate a burst condition. 309 The recommended value for the threshold Gmin in [RFC3611] results in 310 a Burst being a period of time during which the call quality is 311 degraded to a similar extent to a typical PCM Severely Errored Second 312 [SDES]. 314 5. SDP Signaling 316 [RFC3611] defines the use of SDP (Session Description Protocol) 317 [RFC4566] for signaling the use of XR blocks. XR blocks MAY be used 318 without prior signaling. 320 This section augments the SDP [RFC4566] attribute "rtcp-xr" defined 321 in [RFC3611] by providing an additional value of "xr-format" to 322 signal the use of the report block defined in this document. 324 rtcp-xr-attrib = "a=" "rtcp-xr" ":" [xr-format *(SP xr-format)] CRLF 326 (defined in [RFC3611]) 328 xr-format =/ xr-bgl-block 330 xr-bgl-block = "brst-gap-loss" 332 6. IANA Considerations 334 New block types for RTCP XR are subject to IANA registration. For 335 general guidelines on IANA considerations for RTCP XR, refer to 336 [RFC3611]. 338 6.1. New RTCP XR Block Type value 340 This document assigns the block type value NDEL in the IANA "RTCP XR 341 Block Type Registry" to the "Burst/Gap Loss Metrics Block". 343 [Note to RFC Editor: please replace NBGL with the IANA provided RTCP 344 XR block type for this block.] 346 6.2. New RTCP XR SDP Parameter 348 This document also registers a new parameter "brst-gap-loss" in the 349 "RTCP XR SDP Parameters Registry". 351 6.3. Contact information for registrations 353 The contact information for the registrations is: 355 Geoff Hunt (r.geoff.hunt@gmail.com) 357 Orion 2 PP3, Adastral Park, Martlesham Heath, Ipswich IP5 3RE, United 358 Kingdom 360 7. Security Considerations 362 It is believed that this proposed RTCP XR report block introduces no 363 new security considerations beyond those described in [RFC3611]. 364 This block does not provide per-packet statistics so the risk to 365 confidentiality documented in Section 7, paragraph 3 of [RFC3611] 366 does not apply. 368 8. Contributors 370 The authors gratefully acknowledge the comments and contributions 371 made by Bruce Adams, Philip Arden, Amit Arora, Bob Biskner, Kevin 372 Connor, Claus Dahm, Randy Ethier, Roni Even, Jim Frauenthal, Albert 373 Higashi, Tom Hock, Shane Holthaus, Paul Jones, Rajesh Kumar, Keith 374 Lantz, Mohamed Mostafa, Amy Pendleton, Colin Perkins, Mike Ramalho, 375 Ravi Raviraj, Albrecht Schwarz, Tom Taylor, and Hideaki Yamada. 377 9. Changes from previous version 379 Changed BNF for SDP following Christian Groves' and Tom Taylor's 380 comments (4th and 5th May 2009), now aligned with RFC 5234 section 381 3.3 "Incremental Alternatives". 383 Updated references. 385 10. References 387 10.1. Normative References 389 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 390 Requirement Levels", March 1997. 392 [RFC3550] Schulzrinne, H., "RTP: A Transport Protocol for Real-Time 393 Applications", RFC 3550, July 2003. 395 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 396 Protocol Extended Reports (RTCP XR)", November 2003. 398 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 399 Description Protocol", July 2006. 401 10.2. Informative References 403 [DISCARD] Hunt, G., "RTCP XR Report Block for Discard metric 404 Reporting", ID draft-ietf-rtcp-xr-discard-02, May 2009. 406 [MONARCH] Hunt, G., "Monitoring Architectures for RTP", 407 ID draft-ietf-avtcore-monarch-04, August 2011. 409 [PMOLFRAME] 410 Clark, A. and B. Claise, "Framework for Performance Metric 411 Development", ID draft-ietf-pmol-metrics-framework-12, 412 July 2011. 414 [SDES] "", URL http://www.its.bldrdoc.gov/projects/devglossary/ 415 _severely_errored_second.html, October 2011. 417 [SUMSTAT] Zorn, G., "RTCP XR for Summary Statistics Metrics 418 Reporting", ID draft-zorn-xrblock-rtcp-xr-al-stat-03, 419 October 2011. 421 Authors' Addresses 423 Geoff Hunt 424 Unaffiliated 426 Email: r.geoff.hunt@gmail.com 428 Alan Clark 429 Telchemy Incorporated 430 2905 Premiere Parkway, Suite 280 431 Duluth, GA 30097 432 USA 434 Email: alan.d.clark@telchemy.com 436 Sunshine Zhang (editor) 437 Shanghai Research Institure of China Telecom Corporation Limited 438 No.1835,South Pudong Road 439 Shanghai 200122 440 China 442 Email: zhangyx@sttri.com.cn 444 Qin Wu 445 Huawei 446 101 Software Avenue, Yuhua District 447 Nanjing, Jiangsu 210012 448 China 450 Email: sunseawq@huawei.com