idnits 2.17.1 draft-ietf-xrblock-rtcweb-rtcp-xr-metrics-09.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 (March 5, 2018) is 2216 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-rtcweb-security' is defined on line 685, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-rtcweb-security-10 Summary: 0 errors (**), 0 flaws (~~), 3 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: September 6, 2018 R. Even 6 Huawei 7 D. Romascanu 8 Individual 9 L. Deng 10 China Mobile 11 March 5, 2018 13 Considerations for Selecting RTCP Extended Report (XR) Metrics for the 14 WebRTC Statistics API 15 draft-ietf-xrblock-rtcweb-rtcp-xr-metrics-09 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) 2018 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 ReportGroup: It is a set of metrics identified by a common 132 Synchronization source (SSRC). 134 3. RTP Statistics in WebRTC Implementations 136 The RTCP Sender Reports (SRs) and Receiver Reports (RRs) [RFC3550] 137 exposes the basic metrics for the local and remote media streams. 138 However, these metrics provides only partial or limited information, 139 which may not be sufficient for diagnosing problems or quality 140 monitoring. For example, it may be useful to distinguish between 141 packets lost and packets discarded due to late arrival, even though 142 they have the same impact on the multimedia quality, it helps in 143 identifying and diagnosing issues. RTP Control Protocol Extended 144 Reports (XRs) [RFC3611] and other extensions discussed in the XRBLOCK 145 working group provide more detailed statistics, which complement the 146 basic metrics reported in the RTCP SR and RRs. 148 The WebRTC application extracts the statistic from the browser by 149 querying the getStats() API [W3C.WD-webrtc-20161124], but the browser 150 currently only reports the local variables i.e., the statistics 151 related to the outgoing RTP media streams and the incoming RTP media 152 streams. Without the support of RTCP XRs or some other signaling 153 mechanism, the WebRTC application cannot expose the remote endpoints' 154 statistics. [I-D.ietf-rtcweb-rtp-usage] does not mandate the use of 155 any RTCP XRs and since their usage is optional. If the use of RTCP 156 XRs is successfully negotiated between endpoints (via SDP), 157 thereafter the application has access to both local and remote 158 statistics. Alternatively, once the WebRTC application gets the 159 local information, they can report it to an application server or a 160 third-party monitoring system, which provides quality estimations or 161 diagnosis services for application developers. The exchange of 162 statistics between endpoints or between a monitoring server and an 163 endpoint is outside the scope of this document. 165 4. Considerations for Impact of Measurement Interval 167 RTCP extensions like RTCP XR usually share the same timing interval 168 with the RTCP SR/RR, i.e., they are sent as compound packets, 169 together with the RTCP SR/RR. Alternatively, if the RTCP XR uses a 170 different measurement interval, all XRs using the same measurement 171 interval are compounded together and the measurement interval is 172 indicated in a specific measurement information block defined in 173 [RFC6776]. 175 When using WebRTC getStats() APIs (see section 7 of [W3C.WD-webrtc- 176 20161124]), the applications can query this information at arbitrary 177 intervals. For the statistics reported by the remote endpoint, e.g., 178 those conveyed in an RTCP SR/RR/XR, these will not change until the 179 next RTCP report is received. However, statistics generated by the 180 local endpoint have no such restrictions as long as the endpoint is 181 sending and receiving media. For example, an application may choose 182 to poll the stack for statistics every 1 second, in this case the 183 underlying stack local will return the current snapshot of the local 184 statistics (for incoming and outgoing media streams). However it may 185 return the same remote statistics as before for the remote 186 statistics, as no new RTCP reports may have been received in the past 187 1 second. This can occur when the polling interval is shorter than 188 the average RTCP reporting interval. 190 5. Candidate Metrics 192 Since following metrics are all defined in RTCP XR which is not 193 mandated in WebRTC, all of them are local. However, if RTCP XR is 194 supported by negotiation between two browsers, following metrics can 195 also be generated remotely and be sent to local by RTCP XR packets. 197 Following metrics are classified into 3 categories: network impact 198 metrics, application impact metrics and recovery metrics. Network 199 impact metrics are the statistics recording the information only for 200 network transmission. They are useful for network problem diagnosis. 201 Application impact metrics mainly collect the information from the 202 viewpoint of application, e.g., bit rate, frames rate or jitter 203 buffers. Recovery metrics reflect how well the repair mechanisms 204 perform, e.g. loss concealment, retransmission or Forward Error 205 Correction (FEC). All of the 3 types of metrics are useful for 206 quality estimations of services in WebRTC implementations. WebRTC 207 application can use these metrics to calculate the Mean Opinion Score 208 (MoS) values or Media Delivery Index (MDI) for their services. 210 5.1. Network Impact Metrics 212 5.1.1. Loss and Discard Packet Count Metric 214 In multimedia transport, packets which are received abnormally are 215 classified into 3 types: lost, discarded and duplicate packets. 216 Packet loss may be caused by network device breakdown, bit-error 217 corruption or network congestion (packets dropped by an intermediate 218 router queue). Duplicate packets may be a result of network delays 219 that causes the sender to retransmit the original packets. Discarded 220 packets are packets that have been delayed long enough (perhaps they 221 missed the playout time) and are considered useless by the receiver. 222 Lost and discarded packets cause problems for multimedia services, as 223 missing data and long delays can cause degradation in service 224 quality, e.g., missing large blocks of contiguous packets (lost or 225 discarded) may cause choppy audio, and long network transmission 226 delay time may cause audio or video buffering. The RTCP SR/RR 227 defines a metric for counting the total number of RTP data packets 228 that have been lost since the beginning of reception. But this 229 statistic does not distinguish lost packets from discarded and 230 duplicate packets. Packets that arrive late will be discarded and 231 are not reported as lost, and duplicate packets will be regarded as a 232 normally received packet. Hence, the loss metric can be misleading 233 if many duplicate packets are received or packets are discarded, 234 which causes the quality of the media transport to appear okay from 235 the statistic point of view, but meanwhile the users may actually be 236 experiencing bad service quality. So in such cases, it is better to 237 use more accurate metrics in addition to those defined in RTCP SR/RR. 239 The lost packets and duplicated packets metrics defined in Statistics 240 Summary Report Block of [RFC3611] extend the information of loss 241 carried in standard RTCP SR/RR. They explicitly give an account of 242 lost and duplicated packets. Lost packets counts are useful for 243 network problem diagnosis. It is better to use the loss packets 244 metrics of [RFC3611] to indicate the packet lost count instead of the 245 cumulative number of packets lost metric of [RFC3550]. Duplicated 246 packets are usually rare and have little effect on QoS evaluation. So 247 it may not be suitable for use in WebRTC. 249 Using loss metrics without considering discard metrics may result in 250 inaccurate quality evaluation, as packet discard due to jitter is 251 often more prevalent than packet loss in modern IP networks. The 252 discarded metric specified in [RFC7002] counts the number of packets 253 discarded due to the jitter. It augments the loss statistics metrics 254 specified in standard RTCP SR/RR. For those RTCWEB services with 255 jitter buffers requiring precise quality evaluation and accurate 256 troubleshooting, this metric is useful as a complement to the metrics 257 of RTCP SR/RR. 259 5.1.2. Burst/Gap Pattern Metrics for Loss and Discard 261 RTCP SR/RR defines coarse metrics regarding loss statistics: the 262 metrics are all about per call statistics and are not detailed enough 263 to capture the transitory nature of some impairments like bursty 264 packet loss. Even if the average packet loss rate is low, the lost 265 packets may occur during short dense periods, resulting in short 266 periods of degraded quality. Bursts cause lower quality experience 267 than the non-bursts for low packet loss rates, whereas for high 268 packet loss rates the converse is true. So capturing burst gap 269 information is very helpful for quality evaluation and locating 270 impairments. If the WebRTC application needs to evaluate the 271 services quality, burst gap metrics provides more accurate 272 information than RTCP SR/RR. 274 [RFC3611] introduces burst gap metrics in VoIP report block. These 275 metrics record the density and duration of burst and gap periods, 276 which are helpful in isolating network problems since bursts 277 correspond to periods of time during which the packet loss/discard 278 rate is high enough to produce noticeable degradation in audio or 279 video quality. Burst gap related metrics are also introduced in 280 [RFC7003] and [RFC6958] which define two new report blocks for usage 281 in a range of RTP applications beyond those described in [RFC3611]. 282 These metrics distinguish discarded packets from loss packets that 283 occur in the bursts period and provides more information for 284 diagnosing network problems. Additionally, the block reports the 285 frequency of burst events which is useful information for evaluating 286 the quality of experience. Hence, if WebRTC applications need to do 287 quality evaluation and observe when and why quality degrades, these 288 metrics should be considered. 290 5.1.3. Run Length Encoded Metrics for Loss, Discard 292 Run-length encoding uses a bit vector to encode information about the 293 packet. Each bit in the vector represents a packet and depending on 294 the signaled metric it defines if the packet was lost, duplicated, 295 discarded, or repaired. An endpoint typically uses the run length 296 encoding to accurately communicate the status of each packet in the 297 interval to the other endpoint. [RFC3611], [RFC7097] define run- 298 length encoding for lost and duplicate packets, and discarded 299 packets, respectively. 301 The WebRTC application could benefit from the additional information. 302 If losses occur after discards, an endpoint may be able to correlate 303 the two run length vectors to identify congestion-related losses, 304 i.e., a router queue became overloaded causing delays and then 305 overflowed. If the losses are independent, it may indicate bit-error 306 corruption. For the WebRTC Stats API [W3C.WD-webrtc-stats-20161214], 307 these types of metrics are not recommended for use due to the large 308 amount of data and the computation involved. 310 5.2. Application Impact Metrics 312 5.2.1. Discarded Octets Metric 314 The metric reports the cumulative size of the packets discarded in 315 the interval, it is complementary to number of discarded packets. An 316 application measures sent octets and received octets to calculate 317 sending rate and receiving rate, respectively. The application can 318 calculate the actual bit rate in a particular interval by subtracting 319 the discarded octets from the received octets. 321 For WebRTC, discarded octets supplements the sent and received octets 322 and provides an accurate method for calculating the actual bit rate 323 which is an important parameter to reflect the quality of the media. 324 The discarded bytes metric is defined in [RFC7243]. 326 5.2.2. Frame Impairment Summary Metrics 328 RTP has different framing mechanisms for different payload types. For 329 audio streams, a single RTP packet may contain one or multiple audio 330 frames, each of which has a fixed length. On the other hand, in 331 video streams, a single video frame may be transmitted in multiple 332 RTP packets. The size of each packet is limited by the Maximum 333 Transmission Unit (MTU) of the underlying network. However, 334 statistics from standard SR/RR only collect information from 335 transport layer, which may not fully reflect the quality observed by 336 the application. Video is typically encoded using two frame types 337 i.e., key frames and derived frames. Key frames are normally just 338 spatially compressed, i.e., without prediction from other pictures. 339 The derived frames are temporally compressed, i.e., depend on the key 340 frame for decoding. Hence, key frames are much larger in size than 341 derived frames. The loss of these key frames results in a 342 substantial reduction in video quality. Thus it is reasonable to 343 consider this application layer information in WebRTC 344 implementations, which influence sender strategies to mitigate the 345 problem or require the accurate assessment of users' quality of 346 experience. 348 The metrics in this category includes: number of discarded key 349 frames, number of lost key frames, number of discarded derived 350 frames, number of lost derived frames. These metrics can be used to 351 calculate Media Loss Rate (MLR) of MDI. Details of the definition of 352 these metrics are described in [RFC7003]. Additionally, the metric 353 provides the rendered frame rate, an important parameter for quality 354 estimation. 356 5.2.3. Jitter Buffer Metrics 358 The size of the jitter buffer affects the end-to-end delay on the 359 network and also the packet discard rate. When the buffer size is 360 too small, slower packets are not played out and dropped, while when 361 the buffer size is too large, packets are held longer than necessary 362 and consequently reduce conversational quality. Measurement of 363 jitter buffer should not be ignored in the evaluation of end user 364 perception of conversational quality. Jitter buffer related metrics, 365 such as maximum and nominal jitter buffer, could be used to show how 366 the jitter buffer behaves at the receiving endpoint. They are useful 367 for providing better end-user quality of experience (QoE) when jitter 368 buffer factors are used as inputs to calculate MoS values. Thus for 369 those cases, jitter buffer metrics should be considered. The 370 definition of these metrics is provided in [RFC7005]. 372 5.3. Recovery metrics 374 This document does not consider concealment metrics [RFC7294] as part 375 of recovery metrics. 377 5.3.1. Post-repair Packet Count Metrics 379 Error-resilience mechanisms, like RTP retransmission or FEC, are 380 optional in RTCWEB because the overhead of the repair bits adding to 381 the original streams. But they do help to greatly reduce the impact 382 of packet loss and enhance the quality of transmission. Web 383 applications could support certain repair mechanism after negotiation 384 between both sides of browsers when needed. For these web 385 applications using repair mechanisms, providing some statistic 386 information for the performance of their repair mechanisms could help 387 to have a more accurate quality evaluation. 389 The un-repaired packets count and repaired loss count defined in 390 [RFC7509] provide the recovery information of the error-resilience 391 mechanisms to the monitoring application or the sending endpoint. The 392 endpoint can use these metrics to ascertain the ratio of repaired 393 packets to lost packets. Including this kind of metrics helps the 394 application evaluate the effectiveness of the applied repair 395 mechanisms. 397 5.3.2. Run Length Encoded Metric for Post-repair 399 [RFC5725] defines run-length encoding for post-repair packets. When 400 using error-resilience mechanisms, the endpoint can correlate the 401 loss run length with this metric to ascertain where the losses and 402 repairs occurred in the interval. This provides more accurate 403 information for recovery mechanisms evaluation than those in 404 Section 5.3.1. However, it is not suggested to use due to their 405 enormous amount of data when RTCP XR are supported. 407 For WebRTC, the application may benefit from the additional 408 information. If losses occur after discards, an endpoint may be able 409 to correlate the two run length vectors to identify congestion- 410 related losses, i.e., a router queue became overloaded causing delays 411 and then overflowed. If the losses are independent, it may indicate 412 bit-error corruption. Lastly, when using error-resilience 413 mechanisms, the endpoint can correlate the loss and post-repair run 414 lengths to ascertain where the losses and repairs occurred in the 415 interval. For example, consecutive losses are likely not to be 416 repaired by a simple FEC scheme. 418 6. Identifiers from Sender, Receiver, and Extended Report Blocks 420 This document describes a list of metrics and corresponding 421 identifiers relevant to RTP media in WebRTC. These group of 422 identifiers are defined on a ReportGroup corresponding to an 423 Synchronization source (SSRC). In practice the application need to 424 be able to query the statistic identifiers on both an incoming 425 (remote) and outgoing (local) media stream. Since sending and 426 receiving SR and RR are mandatory, the metrics defined in the SR and 427 RR report blocks are always available. For XR metrics, it depends on 428 two factors: 1) if it measured at the endpoint, 2) if it reported by 429 the endpoint in an XR report. If a metric is only measured by the 430 endpoint and not reported, the metrics will only be available for the 431 incoming (remote) media stream. Alternatively, if the corresponding 432 metric is also reported in an XR report, it will be available for 433 both the incoming (remote) and outgoing (local) media stream. 435 For a remote statistic, the timestamp represents the timestamp from 436 an incoming SR/RR/XR packet. Conversely, for a local statistic, it 437 refers to the current timestamp generated by the local clock 438 (typically the POSIX timestamp, i.e., milliseconds since Jan 1, 439 1970). 441 As per [RFC3550], the octets metrics represent the payload size 442 (i.e., not including header or padding). 444 6.1. Cumulative Number of Packets and Octets Sent 446 Name: packetsSent 448 Definition: section 6.4.1 in [RFC3550]. 450 Name: bytesSent 452 Definition: section 6.4.1 in [RFC3550]. 454 6.2. Cumulative Number of Packets and Octets Received 456 Name: packetsReceived 458 Definition: section 6.4.1 in [RFC3550]. 460 Name: bytesReceived 462 Definition: section 6.4.1 in [RFC3550]. 464 6.3. Cumulative Number of Packets Lost 466 Name: packetsLost 468 Definition: section 6.4.1 in [RFC3550]. 470 6.4. Interval Packet Loss and Jitter 472 Name: jitter 474 Definition: section 6.4.1 in [RFC3550]. 476 Name: fractionLost 478 Definition: section 6.4.1 in [RFC3550]. 480 6.5. Cumulative Number of Packets and Octets Discarded 482 Name: packetsDiscarded 484 Definition: The cumulative number of RTP packets discarded due to 485 late or early-arrival, Appendix A (a) of [RFC7002]. 487 Name: bytesDiscarded 489 Definition: The cumulative number of octets discarded due to late or 490 early-arrival, Appendix A of [RFC7243]. 492 6.6. Cumulative Number of Packets Repaired 494 Name: packetsRepaired 496 Definition: The cumulative number of lost RTP packets repaired after 497 applying a error-resilience mechanism, Appendix A (b) of [RFC7509]. 498 To clarify, the value is upper bound to the cumulative number of lost 499 packets. 501 6.7. Burst Packet Loss and Burst Discards 503 Name: burstPacketsLost 505 Definition: The cumulative number of RTP packets lost during loss 506 bursts, Appendix A (c) of [RFC6958]. 508 Name: burstLossCount 510 Definition: The cumulative number of bursts of lost RTP packets, 511 Appendix A (e) of [RFC6958]. 513 Name: burstPacketsDiscarded 515 Definition: The cumulative number of RTP packets discarded during 516 discard bursts, Appendix A (b) of [RFC7003]. 518 Name: burstDiscardCount 520 Definition: The cumulative number of bursts of discarded RTP packets, 521 Appendix A (e) of [RFC8015]. 523 [RFC3611] recommends a Gmin (threshold) value of 16 for classifying 524 packet loss or discard burst. 526 6.8. Burst/Gap Rates 528 Name: burstLossRate 530 Definition: The fraction of RTP packets lost during bursts, 531 Appendix A (a) of [RFC7004]. 533 Name: gapLossRate 535 Definition: The fraction of RTP packets lost during gaps, Appendix A 536 (b) of [RFC7004]. 538 Name: burstDiscardRate 540 Definition: The fraction of RTP packets discarded during bursts, 541 Appendix A (e) of [RFC7004]. 543 Name: gapDiscardRate 545 Definition: The fraction of RTP packets discarded during gaps, 546 Appendix A (f) of [RFC7004]. 548 6.9. Frame Impairment Metrics 550 Name: framesLost 552 Definition: The cumulative number of full frames lost, Appendix A (i) 553 of [RFC7004]. 555 Name: framesCorrupted 557 Definition: The cumulative number of frames partially lost, 558 Appendix A (j) of [RFC7004]. 560 Name: framesDropped 561 Definition: The cumulative number of full frames discarded, 562 Appendix A (g) of [RFC7004]. 564 Name: framesSent 566 Definition: The cumulative number of frames sent. 568 Name: framesReceived 570 Definition: The cumulative number of partial or full frames received. 572 7. Adding new metrics to WebRTC Statistics API 574 During the progress of this work, the metrics defined in this draft 575 have already been added to the W3C WebRTC specification. The working 576 process to add new metrics for future is to create an issue or pull 577 request on the repository of the W3C WebRTC specification 578 (https://github.com/w3c/webrtc-stats). 580 8. Security Considerations 582 This document focuses on listing the RTCP XR metrics defined in the 583 corresponding RTCP reporting extensions and do not give rise to any 584 new security vulnerabilities beyond those described in [RFC3611] and 585 [RFC6792]. 587 The overall security considerations for RTP used in WebRTC 588 applicaitons is described in [I-D.ietf-rtcweb-rtp-usage] and [I- 589 D.ietf-rtcweb-security], which are also apply to this memo. 591 9. IANA Consideration 593 This document requests no action by IANA. 595 10. 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 11. References 603 11.1. Normative References 605 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 606 Jacobson, "RTP: A Transport Protocol for Real-Time 607 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 608 July 2003, . 610 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 611 "RTP Control Protocol Extended Reports (RTCP XR)", 612 RFC 3611, DOI 10.17487/RFC3611, November 2003, 613 . 615 [RFC5725] Begen, A., Hsu, D., and M. Lague, "Post-Repair Loss RLE 616 Report Block Type for RTP Control Protocol (RTCP) Extended 617 Reports (XRs)", RFC 5725, DOI 10.17487/RFC5725, February 618 2010, . 620 [RFC6776] Clark, A. and Q. Wu, "Measurement Identity and Information 621 Reporting Using a Source Description (SDES) Item and an 622 RTCP Extended Report (XR) Block", RFC 6776, 623 DOI 10.17487/RFC6776, October 2012, 624 . 626 [RFC6792] Qu, Q. and P. Arden, "Guidelines for Use of the RTP 627 Monitoring Framework", RFC 6792, November 2012, 628 630 [RFC6958] Clark, A., Zhang, S., Zhao, J., and Q. Wu, Ed., "RTP 631 Control Protocol (RTCP) Extended Report (XR) Block for 632 Burst/Gap Loss Metric Reporting", RFC 6958, 633 DOI 10.17487/RFC6958, May 2013, 634 . 635 [RFC7002] Clark, A., Zorn, G., and Q. Wu, "RTP Control Protocol 636 (RTCP) Extended Report (XR) Block for Discard Count Metric 637 Reporting", RFC 7002, DOI 10.17487/RFC7002, September 638 2013, . 640 [RFC7003] Clark, A., Huang, R., and Q. Wu, Ed., "RTP Control 641 Protocol (RTCP) Extended Report (XR) Block for Burst/Gap 642 Discard Metric Reporting", RFC 7003, DOI 10.17487/RFC7003, 643 September 2013, . 645 [RFC7004] Zorn, G., Schott, R., Wu, Q., Ed., and R. Huang, "RTP 646 Control Protocol (RTCP) Extended Report (XR) Blocks for 647 Summary Statistics Metrics Reporting", RFC 7004, 648 DOI 10.17487/RFC7004, September 2013, 649 . 651 [RFC7005] Clark, A., Singh, V., and Q. Wu, "RTP Control Protocol 652 (RTCP) Extended Report (XR) Block for De-Jitter Buffer 653 Metric Reporting", RFC 7005, DOI 10.17487/RFC7005, 654 September 2013, . 656 [RFC7097] Ott, J., Singh, V., Ed., and I. Curcio, "RTP Control 657 Protocol (RTCP) Extended Report (XR) for RLE of Discarded 658 Packets", RFC 7097, DOI 10.17487/RFC7097, January 2014, 659 . 661 [RFC7243] Singh, V., Ed., Ott, J., and I. Curcio, "RTP Control 662 Protocol (RTCP) Extended Report (XR) Block for the Bytes 663 Discarded Metric", RFC 7243, DOI 10.17487/RFC7243, May 664 2014, . 666 [RFC7509] Huang, R. and V. Singh, "RTP Control Protocol (RTCP) 667 Extended Report (XR) for Post-Repair Loss Count Metrics", 668 RFC 7509, DOI 10.17487/RFC7509, May 2015, 669 . 671 [RFC8015] Singh, V., Perkins, C., Clark, A., and R. Huang, "RTP 672 Control Protocol (RTCP) Extended Report (XR) Block for 673 Independent Reporting of Burst/Gap Discard Metrics", 674 RFC 8015, DOI 10.17487/RFC8015, November 2016, 675 . 677 11.2. Informative References 679 [I-D.ietf-rtcweb-rtp-usage] 680 Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time 681 Communication (WebRTC): Media Transport and Use of RTP", 682 draft-ietf-rtcweb-rtp-usage-26 (work in progress), March 683 2016. 685 [I-D.ietf-rtcweb-security] 686 Rescorla, E., "Security Considerations for WebRTC", draft- 687 ietf-rtcweb-security-10 (work in progress), January 2018. 689 [RFC7294] Clark, A., Zorn, G., Bi, C. and Q. Wu, "RTP Control 690 Protocol (RTCP) Extended Report (XR) Blocks for 691 Concealment Metrics Reporting on Audio Applications", RFC 692 7294, July 2014, 694 [RFC7478] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- 695 Time Communication Use Cases and Requirements", RFC 7478, 696 DOI 10.17487/RFC7478, March 2015, 697 . 699 [W3C.WD-webrtc-20161124] 700 Sporny, M. and D. Longley, "WebRTC 1.0: Real-time 701 Communication Between Browsers", World Wide Web Consortium 702 WD WD-webrtc-20161124, November 2016, 703 . 705 [W3C.WD-webrtc-stats-20161214] 706 Alvestrand, H. and V. Singh, "Identifiers for 707 WebRTC's Statistics API", World Wide Web Consortium 708 WD WD-webrtc-stats-20161214, December 2016, 709 . 711 Appendix A. Change Log 713 Note to the RFC-Editor: please remove this section prior to 714 publication as an RFC. 716 A.1. changes in draft-ietf-xrblock-rtcweb-rtcp-xr-metrics-05 and -06 718 o Keep alive the document! Keeping it alive. 720 A.2. changes in draft-ietf-xrblock-rtcweb-rtcp-xr-metrics-04 722 o Removed IANA registry. 724 A.3. changes in draft-ietf-xrblock-rtcweb-rtcp-xr-metrics-02, -03 726 o Keep-alive versions, updates to references. 728 A.4. changes in draft-ietf-xrblock-rtcweb-rtcp-xr-metrics-01 730 o Create new registry for WebRTC media metrics. 732 o Using camelCase instead of TitleCase for identifier names. 734 o Imported RTCP SR and RR metrics from the registry in alvestrand- 735 rtcweb-stats-registry. 737 o Added Burst/Gap rate metrics. 739 o Added Frames sent and received metrics. 741 A.5. changes in draft-ietf-xrblock-rtcweb-rtcp-xr-metrics-00 743 o Submitted as WG Draft. 745 A.6. changes in draft-huang-xrblock-rtcweb-rtcp-xr-metrics-04 747 o Addressed comments from the London IETF meeting: 749 o Removed ECN metrics. 751 Authors' Addresses 752 Varun Singh 753 CALLSTATS I/O Oy 754 Annankatu 31-33 C 42 755 Helsinki 00100 756 Finland 758 Email: varun@callstats.io 759 URI: https://www.callstats.io/about 761 Rachel Huang 762 Huawei 763 101 Software Avenue, Yuhua District 764 Nanjing, CN 210012 765 China 767 Email: rachel.huang@huawei.com 769 Roni Even 770 Huawei 771 14 David Hamelech 772 Tel Aviv 64953 773 Israel 775 Email: roni.even@huawei.com 777 Dan Romascanu 779 Email: dromasca@gmail.com 781 Lingli Deng 782 China Mobile 784 Email: denglingli@chinamobile.com