idnits 2.17.1 draft-ietf-avt-rtcp-xr-burst-gap-loss-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 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 (May 15, 2009) is 5431 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: 'RFC2119' is defined on line 407, but no explicit reference was found in the text == Unused Reference: 'DISCARD' is defined on line 421, 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 (-12) exists of draft-ietf-pmol-metrics-framework-02 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Audio/Video Transport Working G. Hunt 3 Group BT 4 Internet-Draft A. Clark 5 Intended status: Standards Track Telchemy 6 Expires: November 16, 2009 May 15, 2009 8 RTCP XR Report Block for Burst/Gap Loss metric Reporting 9 draft-ietf-avt-rtcp-xr-burst-gap-loss-02.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on November 16, 2009. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 This document defines an RTCP XR Report Block that allows the 48 reporting of Burst and Gap Loss metrics for use in a range of RTP 49 applications. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Burst and Gap Loss Report Block . . . . . . . . . . . . . 3 55 1.2. RTCP and RTCP XR Reports . . . . . . . . . . . . . . . . . 3 56 1.3. Performance Metrics Framework . . . . . . . . . . . . . . 4 57 1.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3. Burst/Gap Loss Block . . . . . . . . . . . . . . . . . . . . . 6 60 3.1. Report Block Structure . . . . . . . . . . . . . . . . . . 6 61 3.2. Definition of Fields in Burst/Gap Loss Report Block . . . 6 62 3.3. Derived metrics based on reported metrics . . . . . . . . 8 63 4. Considerations for Voice-over-IP applications . . . . . . . . 10 64 5. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 11 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 66 6.1. New RTCP XR Block Type value . . . . . . . . . . . . . . . 12 67 6.2. New RTCP XR SDP Parameter . . . . . . . . . . . . . . . . 12 68 6.3. Contact information for registrations . . . . . . . . . . 12 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 70 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14 71 9. Changes from previous version . . . . . . . . . . . . . . . . 15 72 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 73 10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 74 10.2. Informative References . . . . . . . . . . . . . . . . . . 16 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 77 1. Introduction 79 1.1. Burst and Gap Loss 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 proportion of packets lost by the 84 network. The losses during loss bursts are reported, together with 85 the number of bursts and additional data allowing the calculation of 86 statistical parameters (mean and variance) of the distribution of 87 burst lengths. Some uses of these metrics depend on the availability 88 of the metric "cumulative number of packets lost" from RTCP 89 [RFC3550]. 91 This block provides information on transient IP problems. Burst/Gap 92 metrics are typically used in Cumulative reports however MAY be used 93 in Interval reports. The burstiness of packet loss affects user 94 experience, may influence any sender strategies to mitigate the 95 problem, and may also have diagnostic value. 97 The metric belongs to the class of transport-related terminal metrics 98 defined in [MONARCH] (work in progress). 100 The definitions of Burst, Gap, Loss and Discard are consistent with 101 definitions in [RFC3611], with the clarification that Loss and 102 Discard are defined in terms of frames. To accomodate the range of 103 jitter buffer algorithms and packet discard logic that may be used by 104 implementors, the method used to distinguish between bursts and gaps 105 may be an equivalent method to that defined in [RFC3611]. The method 106 used SHOULD produce the same result as that defined in [RFC3611] for 107 conditions of burst packet loss, but MAY produce different results 108 for conditions of time varying jitter. 110 Instances of this Metrics Block refer by tag to the separate 111 auxiliary Measurement Identity block [MEASIDENT] which contains 112 information such as the SSRC of the measured stream, and RTP sequence 113 numbers and time intervals indicating the span of the report. 115 1.2. RTCP and RTCP XR Reports 117 The use of RTCP for reporting is defined in [RFC3550]. [RFC3611] 118 defined an extensible structure for reporting using an RTCP Extended 119 Report (XR). This draft defines a new Extended Report block that 120 MUST be used as defined in [RFC3550] and [RFC3611]. 122 1.3. Performance Metrics Framework 124 The Performance Metrics Framework [PMOLFRAME] provides guidance on 125 the definition and specification of performance metrics. Metrics 126 described in this draft either reference external definitions or 127 define metrics generally in accordance with the guidelines in 128 [PMOLFRAME]. 130 1.4. Applicability 132 This metric is believed to be applicable to all RTP applications. 134 2. Definitions 136 Received, Lost and Discarded 138 A packet shall be regarded as lost if it fails to arrive within an 139 implementation-specific time window. A packet that arrives within 140 this time window but is too early or late to be played out shall 141 be regarded as discarded. A packet shall be classified as one of 142 received (or OK), discarded or lost. 144 Bursts and Gaps 146 The terms Burst and Gap are used in a manner consistent with that 147 of RTCP XR [RFC3611]. RTCP XR views a call as being divided into 148 bursts, which are periods during which the loss rate is high 149 enough to cause noticeable call quality degradation (generally 150 over 5 percent loss rate), and gaps, which are periods during 151 which lost packets are infrequent and hence call quality is 152 generally acceptable. 154 In the application of the metric to Voice over IP, if Voice 155 Activity Detection is used the Burst and Gap Duration shall be 156 determined as if silence frames had been sent, i.e. a period of 157 silence in excess of Gmin frames MUST terminate a burst condition. 159 3. Burst/Gap Loss Block 161 3.1. Report Block Structure 163 0 1 2 3 164 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 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | BT=NBGL |I| tag | resv | block length = 4 | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Threshold | Sum of Burst Durations (ms) | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | Packets Lost in Bursts | Total... | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | ...Packets expected in bursts | Number of bursts | Sum of| 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | ...Squares of Burst Durations (ms-squared) | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 Figure 1: Report Block Structure 179 3.2. Definition of Fields in Burst/Gap Loss Report Block 181 block type (BT): 8 bits 183 A Burst/Gap Loss Report Block is identified by the constant NBGL. 185 [Note to RFC Editor: please replace NBGL with the IANA provided RTCP 186 XR block type for this block.] 188 Interval Metric flag (I): 1 bit 190 This field is used to indicate whether the Burst/Gap Loss metric 191 is an Interval or a Cumulative metric, that is, whether the 192 reported value applies to the most recent measurement interval 193 duration between successive metrics reports (I=1) (the Interval 194 Duration) or to the accumulation period characteristic of 195 cumulative measurements (I=0) (the Cumulative Duration). 196 Numerical values for both these intervals are provided in the 197 Measurement Identifier block referenced by the tag field below. 199 Measurement Identifier association (tag): 3 bits 201 This field is used to identify the Measurement Identifier block 202 [MEASIDENT] which describes this measurement. The relevant 203 Measurement Identifier block has the same tag value as the Burst/ 204 Gap Loss block. Note that there may be more than one Measurement 205 Identifier block per RTCP packet. 207 Reserved (resv): 4 bits 209 These bits are reserved. They SHOULD be set to zero by senders 210 and MUST be ignored by receivers. 212 block length: 16 bits 214 The length of this report block in 32-bit words, minus one. For 215 the Burst/Gap Loss block, the block length is equal to 4. 217 Threshold: 8 bits 219 The Threshold is equivalent to Gmin in [RFC3611], i.e. the number 220 of successive frames 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 Identity block (which MUST be present in the same RTCP packet as the 276 Burst/Gap Loss block) and also with the metric "cumulative number of 277 packets lost" provided in standard RTCP [RFC3550]. 279 The fraction of packets lost during bursts is the quotient: Packets 280 Lost in Bursts / Total Packets expected in Bursts 282 The fraction of packets lost during gaps is the quotient: (number of 283 packets lost - Packets Lost in Bursts) / (Packets Expected - Total 284 Packets expected in Bursts) 286 where "number of packets lost" is obtained from standard RTCP 287 [RFC3550] and Packets Expected is calculated as the difference 288 between "extended last sequence number" and "extended first sequence 289 number" (Interval or Cumulative) provided in the Measurement Identity 290 block [MEASIDENT] associated with this Burst/Gap Loss block. 292 Note that if the metric is to be calculated on an Interval basis, a 293 difference must be taken between the current and preceding values of 294 "cumulative number of packets lost" in RTCP, to obtain the "number of 295 packets lost" for the reporting interval. 297 The mean burst duration is obtained as the quotient: 299 mean = Sum of Burst Durations / Number of Bursts 301 The variance of the burst duration is obtained using the standard 302 result: 304 var = ( Sum of Squares of Burst Durations - Number of Bursts * mean^2 305 ) / (Number of Bursts - 1) 307 4. Considerations for Voice-over-IP applications 309 This metric block is applicable to a broad range of RTP applications. 310 Where the metric is used with a Voice-overIP (VoIP) application, the 311 following considerations apply. 313 RTCP XR views a call as being divided into bursts, which are periods 314 during which the loss rate is high enough to cause noticeable call 315 quality degradation (generally over 5 percent loss rate), and gaps, 316 which are periods during which lost packets are infrequent and hence 317 call quality is generally acceptable. 319 If Voice Activity Detection is used the Burst and Gap Duration shall 320 be determined as if silence frames had been sent, i.e. a period of 321 silence in excess of Gmin frames MUST terminate a burst condition. 323 The recommended value for the threshold Gmin in [RFC3611] results in 324 a Burst being a period of time during which the call quality is 325 degraded to a similar extent to a typical PCM Severely Errored 326 Second. 328 5. SDP Signaling 330 [RFC3611] defines the use of SDP (Session Description Protocol) 331 [RFC4566] for signaling the use of XR blocks. XR blocks MAY be used 332 without prior signaling. 334 This section augments the SDP [RFC4566] attribute "rtcp-xr" defined 335 in [RFC3611] by providing an additional value of "xr-format" to 336 signal the use of the report block defined in this document. 338 rtcp-xr-attrib = "a=" "rtcp-xr" ":" [xr-format *(SP xr-format)] CRLF 340 (defined in [RFC3611]) 342 xr-format =/ xr-bgl-block 344 xr-bgl-block = "brst-gap-loss" 346 6. IANA Considerations 348 New block types for RTCP XR are subject to IANA registration. For 349 general guidelines on IANA considerations for RTCP XR, refer to 350 [RFC3611]. 352 6.1. New RTCP XR Block Type value 354 This document assigns the block type value NBGL in the IANA "RTCP XR 355 Block Type Registry" to the "Concealed Seconds Metrics Block". 357 [Note to RFC Editor: please replace NBGL with the IANA provided RTCP 358 XR block type for this block.] 360 6.2. New RTCP XR SDP Parameter 362 This document also registers a new parameter "brst-gap-loss" in the 363 "RTCP XR SDP Parameters Registry". 365 6.3. Contact information for registrations 367 The contact information for the registrations is: 369 Geoff Hunt (geoff.hunt@bt.com) 371 Orion 2 PP3, Adastral Park, Martlesham Heath, Ipswich IP5 3RE, United 372 Kingdom 374 7. Security Considerations 376 It is believed that this proposed RTCP XR report block introduces no 377 new security considerations beyond those described in [RFC3611]. 378 This block does not provide per-packet statistics so the risk to 379 confidentiality documented in Section 7, paragraph 3 of [RFC3611] 380 does not apply. 382 8. Contributors 384 The authors gratefully acknowledge the comments and contributions 385 made by Bruce Adams, Philip Arden, Amit Arora, Bob Biskner, Kevin 386 Connor, Claus Dahm, Randy Ethier, Roni Even, Jim Frauenthal, Albert 387 Higashi, Tom Hock, Shane Holthaus, Paul Jones, Rajesh Kumar, Keith 388 Lantz, Mohamed Mostafa, Amy Pendleton, Colin Perkins, Mike Ramalho, 389 Ravi Raviraj, Albrecht Schwarz, Tom Taylor, and Hideaki Yamada. 391 9. Changes from previous version 393 Changed BNF for SDP following Christian Groves' and Tom Taylor's 394 comments (4th and 5th May 2009), now aligned with RFC 5234 section 395 3.3 "Incremental Alternatives". 397 Updated references. 399 10. References 401 10.1. Normative References 403 [MEASIDENT] 404 Hunt, G., "RTCP XR Measurement Identifier Block", 405 ID draft-ietf-avt-rtcp-xr-meas-identity-02, May 2009. 407 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 408 Requirement Levels", RFC 2119, BCP 14, March 1997. 410 [RFC3550] Schulzrinne, H., "RTP: A Transport Protocol for Real-Time 411 Applications", RFC 3550, July 2003. 413 [RFC3611] Friedman, T., "RTP Control Protocol Extended Reports (RTCP 414 XR)", RFC 3611, November 2003. 416 [RFC4566] Handley, M., "SDP: Session Description Protocol", 417 RFC 4566, July 2006. 419 10.2. Informative References 421 [DISCARD] Hunt, G., "RTCP XR Report Block for Discard metric 422 Reporting", ID draft-ietf-rtcp-xr-discard-02, May 2009. 424 [MONARCH] Hunt, G., "Monitoring Architectures for RTP", 425 ID draft-hunt-avt-monarch-01, August 2008. 427 [PMOLFRAME] 428 Clark, A., "Framework for Performance Metric Development", 429 ID draft-ietf-pmol-metrics-framework-02, March 2009. 431 Authors' Addresses 433 Geoff Hunt 434 BT 435 Orion 2 PP3 436 Adastral Park 437 Martlesham Heath 438 Ipswich, Suffolk IP5 3RE 439 United Kingdom 441 Phone: +44 1473 651704 442 Email: geoff.hunt@bt.com 444 Alan Clark 445 Telchemy Incorporated 446 2905 Premiere Parkway, Suite 280 447 Duluth, GA 30097 448 USA 450 Email: alan.d.clark@telchemy.com