idnits 2.17.1 draft-ietf-xrblock-rtcweb-rtcp-xr-metrics-07.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (December 11, 2017) is 2326 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC3792' is mentioned on line 589, but not defined == Unused Reference: 'I-D.ietf-rtcweb-security' is defined on line 687, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-rtcweb-security-08 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 XR Block Working Group V. Singh 3 Internet-Draft callstats.io 4 Intended status: Informational R. Huang 5 Expires: June 14, 2018 R. Even 6 Huawei 7 D. Romascanu 8 Individual 9 L. Deng 10 China Mobile 11 December 11, 2017 13 Considerations for Selecting RTCP Extended Report (XR) Metrics for the 14 WebRTC Statistics API 15 draft-ietf-xrblock-rtcweb-rtcp-xr-metrics-07 17 Abstract 19 This document describes monitoring features related to media streams 20 in Web real-time communication (WebRTC). It provides a list of RTCP 21 Sender Report, Receiver Report and Extended Report metrics, which may 22 need to be supported by RTP implementations in some diverse 23 environments. It lists a set of identifiers for the WebRTC's 24 statistics API. These identifiers are a set of RTCP SR, RR, and XR 25 metrics related to the transport of multimedia flows. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on January 21, 2018. 44 Copyright Notice 45 Copyright (c) 2017 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. RTP Statistics in WebRTC Implementations . . . . . . . . . . 3 63 4. Considerations for Impact of Measurement Interval . . . . . . 4 64 5. Candidate Metrics . . . . . . . . . . . . . . . . . . . . . . 5 65 5.1. Network Impact Metrics . . . . . . . . . . . . . . . . . 5 66 5.1.1. Loss and Discard Packet Count Metric . . . . . . . . 5 67 5.1.2. Burst/Gap Pattern Metrics for Loss and Discard . . . 6 68 5.1.3. Run Length Encoded Metrics for Loss, Discard . . . . 7 69 5.2. Application Impact Metrics . . . . . . . . . . . . . . . 7 70 5.2.1. Discard Octets Metric . . . . . . . . . . . . . . . . 7 71 5.2.2. Frame Impairment Summary Metrics . . . . . . . . . . 8 72 5.2.3. Jitter Buffer Metrics . . . . . . . . . . . . . . . . 8 73 5.3. Recovery metrics . . . . . . . . . . . . . . . . . . . . 9 74 5.3.1. Post-repair Packet Count Metrics . . . . . . . . . . 9 75 5.3.2. Run Length Encoded Metric for Post-repair . . . . . . 9 76 6. Identifiers from Sender, Receiver, and Extended Report Blocks 10 77 6.1. Cumulative Number of Packets and Octets Sent . . . . . . 10 78 6.2. Cumulative Number of Packets and Octets Received . . . . 10 79 6.3. Cumulative Number of Packets Lost . . . . . . . . . . . . 11 80 6.4. Interval Packet Loss and Jitter . . . . . . . . . . . . . 11 81 6.5. Cumulative Number of Packets and Octets Discarded . . . . 11 82 6.6. Cumulative Number of Packets Repaired . . . . . . . . . . 11 83 6.7. Burst Packet Loss and Burst Discards . . . . . . . . . . 11 84 6.8. Burst/Gap Rates . . . . . . . . . . . . . . . . . . . . . 12 85 6.9. Frame Impairment Metrics . . . . . . . . . . . . . . . . 12 86 7. Adding new metrics to WebRTC Statistics API . . . . . . . . . 13 87 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 88 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 89 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 90 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 91 10.2. Informative References . . . . . . . . . . . . . . . . . 15 93 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 16 94 A.1. changes in draft-ietf-xrblock-rtcweb-rtcp-xr-metrics-05 95 and -06 . . . . . . . . . . . . . . . . . . . . . . . . . 16 96 A.2. changes in draft-ietf-xrblock-rtcweb-rtcp-xr-metrics-04 . 16 97 A.3. changes in draft-ietf-xrblock-rtcweb-rtcp-xr-metrics-02, 98 -03 . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 99 A.4. changes in draft-ietf-xrblock-rtcweb-rtcp-xr-metrics-01 . 16 100 A.5. changes in draft-ietf-xrblock-rtcweb-rtcp-xr-metrics-00 . 16 101 A.6. changes in draft-huang-xrblock-rtcweb-rtcp-xr-metrics-04 16 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 104 1. Introduction 106 Web real-time communication (WebRTC) deployments are emerging and 107 applications need to be able to estimate the service quality. If 108 sufficient information (metrics or statistics) is provided to the 109 application, it can attempt to improve the media quality. [RFC7478] 110 specifies a requirement for statistics: 112 F38 The browser must be able to collect statistics, related to the 113 transport of audio and video between peers, needed to estimate 114 quality of experience. 116 The WebRTC Stats API [W3C.WD-webrtc-stats-20161214] currently lists 117 metrics reported in the RTCP Sender and Receiver Report (SR/RR) 118 [RFC3550] to fulfill this requirement. However, the basic metrics 119 from RTCP SR/RR are not sufficient for precise quality monitoring, or 120 diagnosing potential issues. 122 In this document, we provide rationale for choosing additional RTP 123 metrics for the WebRTC getStats() API [W3C.WD-webrtc-20161124]. All 124 identifiers proposed in this document are recommended to be 125 implemented by an WebRTC endpoint. An endpoint may choose not to 126 expose an identifier if it does not implement the corresponding RTCP 127 Report. 129 2. Terminology 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in [RFC2119]. 135 ReportGroup: It is a set of metrics identified by a common 136 Synchronization source (SSRC). 138 3. RTP Statistics in WebRTC Implementations 140 The RTCP Sender Reports (SRs) and Receiver Reports (RRs) [RFC3550] 141 exposes the basic metrics for the local and remote media streams. 142 However, these metrics provides only partial or limited information, 143 which may not be sufficient for diagnosing problems or quality 144 monitoring. For example, it may be useful to distinguish between 145 packets lost and packets discarded due to late arrival, even though 146 they have the same impact on the multimedia quality, it helps in 147 identifying and diagnosing issues. RTP Control Protocol Extended 148 Reports (XRs) [RFC3611] and other extensions discussed in the XRBLOCK 149 working group provide more detailed statistics, which complement the 150 basic metrics reported in the RTCP SR and RRs. 152 The WebRTC application extracts the statistic from the browser by 153 querying the getStats() API [W3C.WD-webrtc-20161124], but the browser 154 currently only reports the local variables i.e., the statistics 155 related to the outgoing RTP media streams and the incoming RTP media 156 streams. Without the support of RTCP XRs or some other signaling 157 mechanism, the WebRTC application cannot expose the remote endpoints' 158 statistics. [I-D.ietf-rtcweb-rtp-usage] does not mandate the use of 159 any RTCP XRs and since their usage is optional. If the use of RTCP 160 XRs is successfully negotiated between endpoints (via SDP), 161 thereafter the application has access to both local and remote 162 statistics. Alternatively, once the WebRTC application gets the 163 local information, they can report it to an application server or a 164 third-party monitoring system, which provides quality estimations or 165 diagnosis services for application developers. The exchange of 166 statistics between endpoints or between a monitoring server and an 167 endpoint is outside the scope of this document. 169 4. Considerations for Impact of Measurement Interval 171 RTCP extensions like RTCP XR usually share the same timing interval 172 with the RTCP SR/RR, i.e., they are sent as compound packets, 173 together with the RTCP SR/RR. Alternatively, if the RTCP XR uses a 174 different measurement interval, all XRs using the same measurement 175 interval are compounded together and the measurement interval is 176 indicated in a specific measurement information block defined in 177 [RFC6776]. 179 When using WebRTC getStats() APIs (see section 7 of [W3C.WD-webrtc- 180 20161124]), the applications can query this information at arbitrary 181 intervals. For the statistics reported by the remote endpoint, e.g., 182 those conveyed in an RTCP SR/RR/XR, these will not change until the 183 next RTCP report is received. However, statistics generated by the 184 local endpoint have no such restrictions as long as the endpoint is 185 sending and receiving media. For example, an application may choose 186 to poll the stack for statistics every 1 second, in this case the 187 underlying stack local will return the current snapshot of the local 188 statistics (for incoming and outgoing media streams). However it may 189 return the same remote statistics as before for the remote 190 statistics, as no new RTCP reports may have been received in the past 191 1 second. This can occur when the polling interval is shorter than 192 the average RTCP reporting interval. 194 5. Candidate Metrics 196 Since following metrics are all defined in RTCP XR which is not 197 mandated in WebRTC, all of them are local. However, if RTCP XR is 198 supported by negotiation between two browsers, following metrics can 199 also be generated remotely and be sent to local by RTCP XR packets. 201 Following metrics are classified into 3 categories: network impact 202 metrics, application impact metrics and recovery metrics. Network 203 impact metrics are the statistics recording the information only for 204 network transmission. They are useful for network problem diagnosis. 205 Application impact metrics mainly collect the information from the 206 viewpoint of application, e.g., bit rate, frames rate or jitter 207 buffers. Recovery metrics reflect how well the repair mechanisms 208 perform, e.g. loss concealment, retransmission or Forward Error 209 Correction (FEC). All of the 3 types of metrics are useful for 210 quality estimations of services in WebRTC implementations. WebRTC 211 application can use these metrics to calculate the Mean Opinion Score 212 (MoS) values or Media Delivery Index (MDI) for their services. 214 5.1. Network Impact Metrics 216 5.1.1. Loss and Discard Packet Count Metric 218 In multimedia transport, packets which are received abnormally are 219 classified into 3 types: lost, discarded and duplicate packets. 220 Packet loss may be caused by network device breakdown, bit-error 221 corruption or network congestion (packets dropped by an intermediate 222 router queue). Duplicate packets may be a result of network delays 223 that causes the sender to retransmit the original packets. Discarded 224 packets are packets that have been delayed long enough (perhaps they 225 missed the playout time) and are considered useless by the receiver. 226 Lost and discarded packets cause problems for multimedia services, as 227 missing data and long delays can cause degradation in service 228 quality, e.g., missing large blocks of contiguous packets (lost or 229 discarded) may cause choppy audio, and long network transmission 230 delay time may cause audio or video buffering. The RTCP SR/RR 231 defines a metric for counting the total number of RTP data packets 232 that have been lost since the beginning of reception. But this 233 statistic does not distinguish lost packets from discarded and 234 duplicate packets. Packets that arrive late will be discarded and 235 are not reported as lost, and duplicate packets will be regarded as a 236 normally received packet. Hence, the loss metric can be misleading 237 if many duplicate packets are received or packets are discarded, 238 which causes the quality of the media transport to appear okay from 239 the statistic point of view, but meanwhile the users may actually be 240 experiencing bad service quality. So in such cases, it is better to 241 use more accurate metrics in addition to those defined in RTCP SR/RR. 243 The lost packets and duplicated packets metrics defined in Statistics 244 Summary Report Block of [RFC3611] extend the information of loss 245 carried in standard RTCP SR/RR. They explicitly give an account of 246 lost and duplicated packets. Lost packets counts are useful for 247 network problem diagnosis. It is better to use the loss packets 248 metrics of [RFC3611] to indicate the packet lost count instead of the 249 cumulative number of packets lost metric of [RFC3550]. Duplicated 250 packets are usually rare and have little effect on QoS evaluation. So 251 it may not be suitable for use in WebRTC. 253 Using loss metrics without considering discard metrics may result in 254 inaccurate quality evaluation, as packet discard due to jitter is 255 often more prevalent than packet loss in modern IP networks. The 256 discarded metric specified in [RFC7002] counts the number of packets 257 discarded due to the jitter. It augments the loss statistics metrics 258 specified in standard RTCP SR/RR. For those RTCWEB services with 259 jitter buffers requiring precise quality evaluation and accurate 260 troubleshooting, this metric is useful as a complement to the metrics 261 of RTCP SR/RR. 263 5.1.2. Burst/Gap Pattern Metrics for Loss and Discard 265 RTCP SR/RR defines coarse metrics regarding loss statistics: the 266 metrics are all about per call statistics and are not detailed enough 267 to capture the transitory nature of some impairments like bursty 268 packet loss. Even if the average packet loss rate is low, the lost 269 packets may occur during short dense periods, resulting in short 270 periods of degraded quality. Bursts cause lower quality experience 271 than the non-bursts for low packet loss rates, whereas for high 272 packet loss rates the converse is true. So capturing burst gap 273 information is very helpful for quality evaluation and locating 274 impairments. If the WebRTC application needs to evaluate the 275 services quality, burst gap metrics provides more accurate 276 information than RTCP SR/RR. 278 [RFC3611] introduces burst gap metrics in VoIP report block. These 279 metrics record the density and duration of burst and gap periods, 280 which are helpful in isolating network problems since bursts 281 correspond to periods of time during which the packet loss/discard 282 rate is high enough to produce noticeable degradation in audio or 283 video quality. Burst gap related metrics are also introduced in 284 [RFC7003] and [RFC6958] which define two new report blocks for usage 285 in a range of RTP applications beyond those described in [RFC3611]. 286 These metrics distinguish discarded packets from loss packets that 287 occur in the bursts period and provides more information for 288 diagnosing network problems. Additionally, the block reports the 289 frequency of burst events which is useful information for evaluating 290 the quality of experience. Hence, if WebRTC applications need to do 291 quality evaluation and observe when and why quality degrades, these 292 metrics should be considered. 294 5.1.3. Run Length Encoded Metrics for Loss, Discard 296 Run-length encoding uses a bit vector to encode information about the 297 packet. Each bit in the vector represents a packet and depending on 298 the signaled metric it defines if the packet was lost, duplicated, 299 discarded, or repaired. An endpoint typically uses the run length 300 encoding to accurately communicate the status of each packet in the 301 interval to the other endpoint. [RFC3611], [RFC7097] define run- 302 length encoding for lost and duplicate packets, and discarded 303 packets, respectively. 305 The WebRTC application could benefit from the additional information. 306 If losses occur after discards, an endpoint may be able to correlate 307 the two run length vectors to identify congestion-related losses, 308 i.e., a router queue became overloaded causing delays and then 309 overflowed. If the losses are independent, it may indicate bit-error 310 corruption. For the WebRTC Stats API [W3C.WD-webrtc-stats-20161214], 311 these types of metrics are not recommended for use due to the large 312 amount of data and the computation involved. 314 5.2. Application Impact Metrics 316 5.2.1. Discarded Octets Metric 318 The metric reports the cumulative size of the packets discarded in 319 the interval, it is complementary to number of discarded packets. An 320 application measures sent octets and received octets to calculate 321 sending rate and receiving rate, respectively. The application can 322 calculate the actual bit rate in a particular interval by subtracting 323 the discarded octets from the received octets. 325 For WebRTC, discarded octets supplements the sent and received octets 326 and provides an accurate method for calculating the actual bit rate 327 which is an important parameter to reflect the quality of the media. 328 The discarded bytes metric is defined in [RFC7243]. 330 5.2.2. Frame Impairment Summary Metrics 332 RTP has different framing mechanisms for different payload types. For 333 audio streams, a single RTP packet may contain one or multiple audio 334 frames, each of which has a fixed length. On the other hand, in 335 video streams, a single video frame may be transmitted in multiple 336 RTP packets. The size of each packet is limited by the Maximum 337 Transmission Unit (MTU) of the underlying network. However, 338 statistics from standard SR/RR only collect information from 339 transport layer, which may not fully reflect the quality observed by 340 the application. Video is typically encoded using two frame types 341 i.e., key frames and derived frames. Key frames are normally just 342 spatially compressed, i.e., without prediction from other pictures. 343 The derived frames are temporally compressed, i.e., depend on the key 344 frame for decoding. Hence, key frames are much larger in size than 345 derived frames. The loss of these key frames results in a 346 substantial reduction in video quality. Thus it is reasonable to 347 consider this application layer information in WebRTC 348 implementations, which influence sender strategies to mitigate the 349 problem or require the accurate assessment of users' quality of 350 experience. 352 The following metrics can also be considered for WebRTC's Statistics 353 API: number of discarded key frames, number of lost key frames, 354 number of discarded derived frames, number of lost derived frames. 355 These metrics can be used to calculate Media Loss Rate (MLR) of MDI. 356 Details of the definition of these metrics are described in 357 [RFC7003]. Additionally, the metric provides the rendered frame 358 rate, an important parameter for quality estimation. 360 5.2.3. Jitter Buffer Metrics 362 The size of the jitter buffer affects the end-to-end delay on the 363 network and also the packet discard rate. When the buffer size is 364 too small, slower packets are not played out and dropped, while when 365 the buffer size is too large, packets are held longer than necessary 366 and consequently reduce conversational quality. Measurement of 367 jitter buffer should not be ignored in the evaluation of end user 368 perception of conversational quality. Jitter buffer related metrics, 369 such as maximum and nominal jitter buffer, could be used to show how 370 the jitter buffer behaves at the receiving endpoint. They are useful 371 for providing better end-user quality of experience (QoE) when jitter 372 buffer factors are used as inputs to calculate MoS values. Thus for 373 those cases, jitter buffer metrics should be considered. The 374 definition of these metrics is provided in [RFC7005]. 376 5.3. Recovery metrics 378 This document does not consider concealment metrics as part of 379 recovery metrics. 381 5.3.1. Post-repair Packet Count Metrics 383 Error-resilience mechanisms, like RTP retransmission or FEC, are 384 optional in RTCWEB because the overhead of the repair bits adding to 385 the original streams. But they do help to greatly reduce the impact 386 of packet loss and enhance the quality of transmission. Web 387 applications could support certain repair mechanism after negotiation 388 between both sides of browsers when needed. For these web 389 applications using repair mechanisms, providing some statistic 390 information for the performance of their repair mechanisms could help 391 to have a more accurate quality evaluation. 393 The un-repaired packets count and repaired loss count defined in 394 [RFC7509] provide the recovery information of the error-resilience 395 mechanisms to the monitoring application or the sending endpoint. The 396 endpoint can use these metrics to ascertain the ratio of repaired 397 packets to lost packets. Including this kind of metrics helps the 398 application evaluate the effectiveness of the applied repair 399 mechanisms. 401 5.3.2. Run Length Encoded Metric for Post-repair 403 [RFC5725] defines run-length encoding for post-repair packets. When 404 using error-resilience mechanisms, the endpoint can correlate the 405 loss run length with this metric to ascertain where the losses and 406 repairs occurred in the interval. This provides more accurate 407 information for recovery mechanisms evaluation than those in 408 Section 5.3.1. However, it is not suggested to use due to their 409 enormous amount of data when RTCP XR are supported. 411 For WebRTC, the application may benefit from the additional 412 information. If losses occur after discards, an endpoint may be able 413 to correlate the two run length vectors to identify congestion- 414 related losses, i.e., a router queue became overloaded causing delays 415 and then overflowed. If the losses are independent, it may indicate 416 bit-error corruption. Lastly, when using error-resilience 417 mechanisms, the endpoint can correlate the loss and post-repair run 418 lengths to ascertain where the losses and repairs occurred in the 419 interval. For example, consecutive losses are likely not to be 420 repaired by a simple FEC scheme. 422 6. Identifiers from Sender, Receiver, and Extended Report Blocks 424 This document describes a list of metrics and corresponding 425 identifiers relevant to RTP media in WebRTC. These group of 426 identifiers are defined on a ReportGroup corresponding to an 427 Synchronization source (SSRC). In practice the application need to 428 be able to query the statistic identifiers on both an incoming 429 (remote) and outgoing (local) media stream. Since sending and 430 receiving SR and RR are mandatory, the metrics defined in the SR and 431 RR report blocks are always available. For XR metrics, it depends on 432 two factors: 1) if it measured at the endpoint, 2) if it reported by 433 the endpoint in an XR report. If a metric is only measured by the 434 endpoint and not reported, the metrics will only be available for the 435 incoming (remote) media stream. Alternatively, if the corresponding 436 metric is also reported in an XR report, it will be available for 437 both the incoming (remote) and outgoing (local) media stream. 439 For a remote statistic, the timestamp represents the timestamp from 440 an incoming SR/RR/XR packet. Conversely, for a local statistic, it 441 refers to the current timestamp generated by the local clock 442 (typically the POSIX timestamp, i.e., milliseconds since Jan 1, 443 1970). 445 As per [RFC3550], the octets metrics represent the payload size 446 (i.e., not including header or padding). 448 6.1. Cumulative Number of Packets and Octets Sent 450 Name: packetsSent 452 Definition: section 6.4.1 in [RFC3550]. 454 Name: bytesSent 456 Definition: section 6.4.1 in [RFC3550]. 458 6.2. Cumulative Number of Packets and Octets Received 460 Name: packetsReceived 462 Definition: section 6.4.1 in [RFC3550]. 464 Name: bytesReceived 466 Definition: section 6.4.1 in [RFC3550]. 468 6.3. Cumulative Number of Packets Lost 470 Name: packetsLost 472 Definition: section 6.4.1 in [RFC3550]. 474 6.4. Interval Packet Loss and Jitter 476 Name: jitter 478 Definition: section 6.4.1 in [RFC3550]. 480 Name: fractionLost 482 Definition: section 6.4.1 in [RFC3550]. 484 6.5. Cumulative Number of Packets and Octets Discarded 486 Name: packetsDiscarded 488 Definition: The cumulative number of RTP packets discarded due to 489 late or early-arrival, Appendix A (a) of [RFC7002]. 491 Name: bytesDiscarded 493 Definition: The cumulative number of octets discarded due to late or 494 early-arrival, Appendix A of [RFC7243]. 496 6.6. Cumulative Number of Packets Repaired 498 Name: packetsRepaired 500 Definition: The cumulative number of lost RTP packets repaired after 501 applying a error-resilience mechanism, Appendix A (b) of [RFC7509]. 502 To clarify, the value is upper bound to the cumulative number of lost 503 packets. 505 6.7. Burst Packet Loss and Burst Discards 507 Name: burstPacketsLost 509 Definition: The cumulative number of RTP packets lost during loss 510 bursts, Appendix A (c) of [RFC6958]. 512 Name: burstLossCount 514 Definition: The cumulative number of bursts of lost RTP packets, 515 Appendix A (e) of [RFC6958]. 517 Name: burstPacketsDiscarded 519 Definition: The cumulative number of RTP packets discarded during 520 discard bursts, Appendix A (b) of [RFC7003]. 522 Name: burstDiscardCount 524 Definition: The cumulative number of bursts of discarded RTP packets, 525 Appendix A (e) of [RFC8015]. 527 [RFC3611] recommends a Gmin (threshold) value of 16 for classifying 528 packet loss or discard burst. 530 6.8. Burst/Gap Rates 532 Name: burstLossRate 534 Definition: The fraction of RTP packets lost during bursts, 535 Appendix A (a) of [RFC7004]. 537 Name: gapLossRate 539 Definition: The fraction of RTP packets lost during gaps, Appendix A 540 (b) of [RFC7004]. 542 Name: burstDiscardRate 544 Definition: The fraction of RTP packets discarded during bursts, 545 Appendix A (e) of [RFC7004]. 547 Name: gapDiscardRate 549 Definition: The fraction of RTP packets discarded during gaps, 550 Appendix A (f) of [RFC7004]. 552 6.9. Frame Impairment Metrics 554 Name: framesLost 556 Definition: The cumulative number of full frames lost, Appendix A (i) 557 of [RFC7004]. 559 Name: framesCorrupted 561 Definition: The cumulative number of frames partially lost, 562 Appendix A (j) of [RFC7004]. 564 Name: framesDropped 565 Definition: The cumulative number of full frames discarded, 566 Appendix A (g) of [RFC7004]. 568 Name: framesSent 570 Definition: The cumulative number of frames sent. 572 Name: framesReceived 574 Definition: The cumulative number of partial or full frames received. 576 7. Adding new metrics to WebRTC Statistics API 578 During the progress of this work, the metrics defined in this draft 579 have already been added to the W3C WebRTC specification. The working 580 process to add new metrics for future is to create an issue or pull 581 request on the repository of the W3C WebRTC specification 582 (https://github.com/w3c/webrtc-stats). 584 8. Security Considerations 586 This document focuses on listing the RTCP XR metrics defined in the 587 corresponding RTCP reporting extensions and do not give rise to any 588 new security vulnerabilities beyond those described in [RFC3611] and 589 [RFC3792]. 591 The overall security considerations for RTP used in WebRTC 592 applicaitons is described in [I-D.ietf-rtcweb-rtp-usage] and [I- 593 D.ietf-rtcweb-security], which are also apply to this memo. 595 9. Acknowledgements 597 The authors would like to thank Bernard Aboba, Harald Alvestrand, Al 598 Morton, Colin Perkins, and Shida Schubert for their valuable comments 599 and suggestions on earlier version of this document. 601 10. References 603 10.1. Normative References 605 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 606 Requirement Levels", BCP 14, RFC 2119, 607 DOI 10.17487/RFC2119, March 1997, 608 . 610 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 611 Jacobson, "RTP: A Transport Protocol for Real-Time 612 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 613 July 2003, . 615 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 616 "RTP Control Protocol Extended Reports (RTCP XR)", 617 RFC 3611, DOI 10.17487/RFC3611, November 2003, 618 . 620 [RFC5725] Begen, A., Hsu, D., and M. Lague, "Post-Repair Loss RLE 621 Report Block Type for RTP Control Protocol (RTCP) Extended 622 Reports (XRs)", RFC 5725, DOI 10.17487/RFC5725, February 623 2010, . 625 [RFC6776] Clark, A. and Q. Wu, "Measurement Identity and Information 626 Reporting Using a Source Description (SDES) Item and an 627 RTCP Extended Report (XR) Block", RFC 6776, 628 DOI 10.17487/RFC6776, October 2012, 629 . 631 [RFC6958] Clark, A., Zhang, S., Zhao, J., and Q. Wu, Ed., "RTP 632 Control Protocol (RTCP) Extended Report (XR) Block for 633 Burst/Gap Loss Metric Reporting", RFC 6958, 634 DOI 10.17487/RFC6958, May 2013, 635 . 637 [RFC7002] Clark, A., Zorn, G., and Q. Wu, "RTP Control Protocol 638 (RTCP) Extended Report (XR) Block for Discard Count Metric 639 Reporting", RFC 7002, DOI 10.17487/RFC7002, September 640 2013, . 642 [RFC7003] Clark, A., Huang, R., and Q. Wu, Ed., "RTP Control 643 Protocol (RTCP) Extended Report (XR) Block for Burst/Gap 644 Discard Metric Reporting", RFC 7003, DOI 10.17487/RFC7003, 645 September 2013, . 647 [RFC7004] Zorn, G., Schott, R., Wu, Q., Ed., and R. Huang, "RTP 648 Control Protocol (RTCP) Extended Report (XR) Blocks for 649 Summary Statistics Metrics Reporting", RFC 7004, 650 DOI 10.17487/RFC7004, September 2013, 651 . 653 [RFC7005] Clark, A., Singh, V., and Q. Wu, "RTP Control Protocol 654 (RTCP) Extended Report (XR) Block for De-Jitter Buffer 655 Metric Reporting", RFC 7005, DOI 10.17487/RFC7005, 656 September 2013, . 658 [RFC7097] Ott, J., Singh, V., Ed., and I. Curcio, "RTP Control 659 Protocol (RTCP) Extended Report (XR) for RLE of Discarded 660 Packets", RFC 7097, DOI 10.17487/RFC7097, January 2014, 661 . 663 [RFC7243] Singh, V., Ed., Ott, J., and I. Curcio, "RTP Control 664 Protocol (RTCP) Extended Report (XR) Block for the Bytes 665 Discarded Metric", RFC 7243, DOI 10.17487/RFC7243, May 666 2014, . 668 [RFC7509] Huang, R. and V. Singh, "RTP Control Protocol (RTCP) 669 Extended Report (XR) for Post-Repair Loss Count Metrics", 670 RFC 7509, DOI 10.17487/RFC7509, May 2015, 671 . 673 [RFC8015] Singh, V., Perkins, C., Clark, A., and R. Huang, "RTP 674 Control Protocol (RTCP) Extended Report (XR) Block for 675 Independent Reporting of Burst/Gap Discard Metrics", 676 RFC 8015, DOI 10.17487/RFC8015, November 2016, 677 . 679 10.2. Informative References 681 [I-D.ietf-rtcweb-rtp-usage] 682 Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time 683 Communication (WebRTC): Media Transport and Use of RTP", 684 draft-ietf-rtcweb-rtp-usage-26 (work in progress), March 685 2016. 687 [I-D.ietf-rtcweb-security] 688 Rescorla, E., "Security Considerations for WebRTC", draft- 689 ietf-rtcweb-security-08 (work in progress), February 2015. 691 [RFC7478] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- 692 Time Communication Use Cases and Requirements", RFC 7478, 693 DOI 10.17487/RFC7478, March 2015, 694 . 696 [W3C.WD-webrtc-20161124] 697 Sporny, M. and D. Longley, "WebRTC 1.0: Real-time 698 Communication Between Browsers", World Wide Web Consortium 699 WD WD-webrtc-20161124, November 2016, 700 . 702 [W3C.WD-webrtc-stats-20161214] 703 Alvestrand, H. and V. Singh, "Identifiers for 704 WebRTC's Statistics API", World Wide Web Consortium 705 WD WD-webrtc-stats-20161214, December 2016, 706 . 708 Appendix A. Change Log 710 Note to the RFC-Editor: please remove this section prior to 711 publication as an RFC. 713 A.1. changes in draft-ietf-xrblock-rtcweb-rtcp-xr-metrics-05 and -06 715 o Keep alive the document! Keeping it alive. 717 A.2. changes in draft-ietf-xrblock-rtcweb-rtcp-xr-metrics-04 719 o Removed IANA registry. 721 A.3. changes in draft-ietf-xrblock-rtcweb-rtcp-xr-metrics-02, -03 723 o Keep-alive versions, updates to references. 725 A.4. changes in draft-ietf-xrblock-rtcweb-rtcp-xr-metrics-01 727 o Create new registry for WebRTC media metrics. 729 o Using camelCase instead of TitleCase for identifier names. 731 o Imported RTCP SR and RR metrics from the registry in alvestrand- 732 rtcweb-stats-registry. 734 o Added Burst/Gap rate metrics. 736 o Added Frames sent and received metrics. 738 A.5. changes in draft-ietf-xrblock-rtcweb-rtcp-xr-metrics-00 740 o Submitted as WG Draft. 742 A.6. changes in draft-huang-xrblock-rtcweb-rtcp-xr-metrics-04 744 o Addressed comments from the London IETF meeting: 746 o Removed ECN metrics. 748 Authors' Addresses 749 Varun Singh 750 CALLSTATS I/O Oy 751 Annankatu 31-33 C 42 752 Helsinki 00100 753 Finland 755 Email: varun@callstats.io 756 URI: https://www.callstats.io/about 758 Rachel Huang 759 Huawei 760 101 Software Avenue, Yuhua District 761 Nanjing, CN 210012 762 China 764 Email: rachel.huang@huawei.com 766 Roni Even 767 Huawei 768 14 David Hamelech 769 Tel Aviv 64953 770 Israel 772 Email: roni.even@huawei.com 774 Dan Romascanu 776 Email: dromasca@gmail.com 778 Lingli Deng 779 China Mobile 781 Email: denglingli@chinamobile.com