idnits 2.17.1 draft-huang-xrblock-rtcweb-rtcp-xr-metrics-04.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 (July 4, 2014) is 3577 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: 'RFC4588' is defined on line 529, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-05 == Outdated reference: A later version (-16) exists of draft-ietf-rtcweb-use-cases-and-requirements-14 == Outdated reference: A later version (-26) exists of draft-ietf-rtcweb-rtp-usage-15 == Outdated reference: A later version (-12) exists of draft-ietf-rtcweb-security-06 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 XR Block Working Group R. Huang 3 Internet-Draft R. Even 4 Intended status: Standards Track Huawei 5 Expires: January 5, 2015 V. Singh 6 Aalto University 7 D. Romascanu 8 Avaya 9 L. Deng 10 China Mobile 11 July 4, 2014 13 Considerations for Selecting RTCP Extended Report (XR) Metrics for the 14 RTCWEB Statistics API 15 draft-huang-xrblock-rtcweb-rtcp-xr-metrics-04 17 Abstract 19 This document describes monitoring features related to RTCWEB. It 20 provides a list of RTCP XR metrics, which are useful and may need to 21 be supported in some RTCWEB implementations. It also describes a 22 list of additional identifiers for WebRTC's statistics API. These 23 identifiers are a set of RTCP XR metrics related to the transport of 24 multimedia flows. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 5, 2015. 43 Copyright Notice 45 Copyright (c) 2014 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 . . . . . . . . . . 7 72 5.2.3. Jitter Buffer Metrics . . . . . . . . . . . . . . . . 8 73 5.3. Recovery metrics . . . . . . . . . . . . . . . . . . . . 8 74 5.3.1. Post-repair Packet Count Metrics . . . . . . . . . . 9 75 5.3.2. Run Length Encoded Metric for Post-repair . . . . . . 9 76 6. Candidate XR Block Metrics for WebRTC Statistics API . . . . 9 77 6.1. Variables from XR Blocks . . . . . . . . . . . . . . . . 10 78 6.1.1. Packets and Octets Discarded . . . . . . . . . . . . 10 79 6.1.2. Cumulative Number of Packets Repaired . . . . . . . . 10 80 6.1.3. Burst Packet Loss or Discarded . . . . . . . . . . . 10 81 6.1.4. Frame Impairment Metrics . . . . . . . . . . . . . . 11 82 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 83 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 84 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 85 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 86 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 87 10.2. Informative References . . . . . . . . . . . . . . . . . 13 88 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 13 89 A.1. changes in draft-huang-xrblock-rtcweb-rtcp-xr-metrics-04 14 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 92 1. Introduction 94 Web-based real-time communication (WebRTC) deployments are emerging 95 and applications need to be able to estimate the service quality. If 96 sufficient information (metrics or statistics) are provided to the 97 applications, it can attempt to improve the media quality. 98 [I-D.ietf-rtcweb-use-cases-and-requirements] specifies a requirement 99 for statistics: 101 F38 The browser must be able to collect statistics, related to the 102 transport of audio and video between peers, needed to estimate 103 quality of experience. 105 The [I-D.alvestrand-rtcweb-stats-registry] describes a registration 106 procedure for metrics reported by the WebRTC Stats API 107 [W3C.WD-webrtc-20130910]. It currently lists basic metrics reported 108 in the RTCP Sender and Receiver Report (SR/RR) [RFC3550] to fulfill 109 this requirement. However, the basic metrics from RTCP SR/RR are not 110 sufficient for precise quality monitoring, or diagnosing potential 111 issues. 113 In this document, we provide some guidelines on choosing additional 114 RTP metrics for the WebRTC Stats API [W3C.WD-webrtc-20130910]. 115 Furthermore, we expose additional RTCP XR metrics to complement the 116 identifiers that already exist in the statistics registry 117 [I-D.alvestrand-rtcweb-stats-registry]. 119 2. Terminology 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in [RFC2119]. 125 3. RTP Statistics in WebRTC Implementations 127 Currently, the statistics registry 128 [I-D.alvestrand-rtcweb-stats-registry] exposes the basic RTCP SR and 129 RR metrics for the local and remote media streams. The exposed 130 identifiers are: SentPacketCount, SentOctetCount, packetsLost, 131 Jitter, ReceivedPacketCount, ReceivedOctetCount. However, these 132 metrics provides only partial or limited information, which may not 133 be sufficient for diagnosing problems or quality monitoring. For 134 example, it may be useful to distinguish between packets lost and 135 packets discarded due to late arrival, even though they have the same 136 impact on the multimedia quality, it helps in diagnosing and 137 identifying issues. 139 RTP Control Protocol Extended Reports [RFC3611] and other extensions 140 discussed in the XRBLOCK working group provide more detailed 141 statistics, which complement the basic metrics reported in the RTCP 142 Sender and Receiver Reports. Section Section 5 discusses the use of 143 XR metrics that may be useful for monitoring the performance of 144 WebRTC applications. 146 The WebRTC application extracts the statistic from the browser by 147 querying the Stats API [W3C.WD-webrtc-20130910], but the browser 148 currently only reports the local variables i.e., the statistics 149 related to the outgoing RTP media streams and the incoming RTP media 150 streams. Without the support of RTCP XRs or some other signaling 151 mechianism, the WebRTC application cannot expose the remote 152 endpoints' statistics. At the moment [I-D.ietf-rtcweb-rtp-usage] 153 does not mandate the use of any RTCP XRs and since their usage is 154 optional. If the use of RTCP XRs is successfully negotiated between 155 endpoints (via SDP), thereafter the application has access to both 156 local and remote statistics. Alternatively, once the WebRTC 157 application gets the local information, they can report it to an 158 application server or a third-party monitoring system, which provides 159 quality estimations or diagnosis services for application developers. 160 The exchange of statistics between endpoints or between a monitoring 161 server and an endpoint is outside the scope of this document. 163 4. Considerations for Impact of Measurement Interval 165 RTCP extensions like RTCP XR usually share the same timing interval 166 with the RTCP SR/RR, i.e., they are sent as compound packets, 167 together with the RTCP SR/RR. Alternatively, if the RTCP XR uses a 168 different measurement interval, all XRs using the same measurement 169 interval are compounded together and the measurement interval is 170 indicated in a specific measurement information block defined in 171 [RFC6776]. 173 When using WebRTC Statistics APIs (see section 7 of 174 [W3C.WD-webrtc-20130910]), the applications can query this 175 information at arbitrary intervals. For the statistics reported by 176 the remote endpoint, e.g., those conveyed in an RTCP SR/RR/XR, these 177 will not change until the next RTCP report is received. Some 178 applications may choose 1 second or a different polling interval, but 179 the statistics from the remote endpoint may not change when using 180 intervals shorter than the average RTCP reporting interval. However, 181 statistics generated by the local endpoint have no such restrictions 182 as long as the endpoint is sending and receiving media. 184 5. Candidate Metrics 186 Since following metrics are all defined in RTCP XR which is not 187 mandated in WebRTC, all of them are local. However, if RTCP XR is 188 supported by negotiation between two browsers, following metrics can 189 also be generated remotely and be sent to local by RTCP XR packets. 191 Following metrics are classified into 3 categories: network impact 192 metrics, application impact metrics and recovery metrics. Network 193 impact metrics are the statistics recording the information only for 194 network transmission. They are useful for network problem diagnosis. 195 Application impact metrics mainly collect the information in the 196 viewpoint of application, e.g., bitrate, frames rate or jitter 197 buffers. Recovery metrics reflect how well the repair mechanisms, 198 e.g. loss concealment, retransmission or FEC, perform. All of the 3 199 types of metrics are useful for quality estimations of services in 200 WebRTC implementations. WebRTC application can use these metrics to 201 better calculate MoS values or Media Delivery Index (MDI) for their 202 services. 204 5.1. Network Impact Metrics 206 5.1.1. Loss and Discard Packet Count Metric 208 In multimedia transport, packets which are received abnormally are 209 classified into 3 types: lost, discarded and duplicate packets. 210 Packet loss may be caused by network device breakdown, bit-error 211 corruption or network congestion (packets dropped by an intermediate 212 router queue). Duplicate packets may be a result of network delays, 213 which causes the sender to retransmit the original packets. 214 Discarded packets are packets that have been delayed long enough 215 (perhaps they missed the playout time) and are considered useless by 216 the receiver. Lost and discarded packets cause problems for 217 multimedia services, as missing data and long delays can cause 218 degradation in service quality, e.g., missing large blocks of 219 contiguous packets (lost or discarded) may cause choppy audio, and 220 long network transmission delay time may cause audio or video 221 buffering. The RTCP SR/RR defines a metric for counting the total 222 number of RTP data packets that have been lost since the beginning of 223 reception. But this statistic does not distinguish lost packets from 224 discarded and duplicate packets. Packets that arrive late will be 225 discarded and are not reported as lost, and duplicate packets will be 226 regarded as a normally received packet. Hence, the loss metric can 227 be misleading if many duplicate packets are received or packets are 228 discarded, which causes the quality of the media transport to appear 229 okay from the statistic point of view, but meanwhile the users may 230 actually be experiencing bad service quality. So in such cases, it 231 is better to use more accurate metrics in addition to those defined 232 in RTCP SR/RR. 234 The lost packets and duplicated packets metrics defined in Statistics 235 Summary Report Block of [RFC3611] extend the information of loss 236 carried in standard RTCP SR/RR. They explicitly give an account of 237 lost and duplicated packets. Lost packets counts are useful for 238 network problem diagnosis. It is better to use the loss packets 239 metrics of [RFC3611] to indicate the packet lost count instead of the 240 cumulative number of packets lost metric of [RFC3550]. Duplicated 241 packets are usually rare and have little effect on QoS evaluation. 242 So it may not be suitable for use in WebRTC. 244 Using loss metrics without considering discard metrics may result in 245 inaccurate quality evaluation, as packet discard due to jitter is 246 often more prevalent than packet loss in modern IP networks. The 247 discarded metric specified in [RFC7002] counts the number of packets 248 discarded due to the jitter. It augments the loss statistics metrics 249 specified in standard RTCP SR/RR. For those RTCWEB services with 250 jitter buffer requiring precise quality evaluation and accurate 251 troubleshooting, this metric is useful as a complement to the metrics 252 of RTCP SR/RR. 254 5.1.2. Burst/Gap Pattern Metrics for Loss and Discard 256 RTCP SR/RR defines coarse metrics regarding loss statistics, the 257 metrics are all about per call statistics and are not detailed enough 258 to capture some transitory nature of the impairments like bursty 259 packet loss. Even if the average packet loss rate is low, the lost 260 packets may occur during short dense periods, resulting in short 261 periods of degraded quality. Distributed burst provides a higher 262 subjective quality than a non-burst distribution for low packet loss 263 rates whereas for high packet loss rates the converse is true. So 264 capturing burst gap information is very helpful for quality 265 evaluation and locating impairments. If the WebRTC application needs 266 to evaluate the services quality, burst gap metrics provides more 267 accurate information than RTCP SR/RR. 269 [RFC3611] introduces burst gap metrics in VoIP report block. These 270 metrics record the density and duration of burst and gap periods, 271 which are helpful in isolating network problems since bursts 272 correspond to periods of time during which the packet loss/discard 273 rate is high enough to produce noticeable degradation in audio or 274 video quality. Burst gap related metrics are also introduced in 275 [RFC7003] and [RFC6958] which define two new report blocks for usage 276 in a range of RTP applications beyond those described in [RFC3611]. 277 These metrics distinguish discarded packets from loss packets that 278 occur in the bursts period and provides more information for 279 diagnosing network problems. Additionally, the block reports the 280 frequency of burst events which is useful information for evaluating 281 the quality of experience. Hence, if WebRTC application need to do 282 quality evaluation and observe when and why quality degrades, these 283 metrics should be considered. 285 5.1.3. Run Length Encoded Metrics for Loss, Discard 287 Run-length encoding uses a bit vector to encode information about the 288 packet. Each bit in the vector represents a packet and depending on 289 the signaled metric it defines if the packet was lost, duplicated, 290 discarded, or repaired. An endpoint typically uses the run length 291 encoding to accurately communicate the status of each packet in the 292 interval to the other endpoint. [RFC3611], [RFC7097] define run- 293 length encoding for lost and duplicate packets, and discarded 294 packets, respectively. 296 The WebRTC application could benefit from the additional information. 297 If losses occur after discards, an endpoint may be able to correlate 298 the two run length vectors to identify congestion-related losses, 299 i.e., a router queue became overloaded causing delays and then 300 overflowed. If the losses are independent, it may indicate bit-error 301 corruption. For the WebRTC StatsAPI, these types of metrics are not 302 recommended for use due to the large amount of data and the 303 computation involved. 305 5.2. Application Impact Metrics 307 5.2.1. Discard Octets Metric 309 The metric reports the cumulative size of the packets discarded in 310 the interval, it is complementary to number of discarded packets. An 311 application measures sent octets and received octets to calculate 312 sending rate and receiving rate, respectively. The application can 313 calculate the actual bitrate in a particular interval by subtracting 314 the discarded octets from the received octets. 316 For WebRTC, discarded octets supplements the sent and received octets 317 and provides an accurate method for calculating the actual bitrate 318 which is an important parameter to reflect the quality of the media. 319 The discarded bytes metric is defined in [RFC7243]. 321 5.2.2. Frame Impairment Summary Metrics 323 RTP has different framing mechanisms for different payload types. 324 For audio streams, a single RTP packet may contain one or multiple 325 audio frames, each of which has a fixed length. On the other hand, 326 in video streams, a single video frame may be transmitted in multiple 327 RTP packets. The size of each packet is limited by the Maximum 328 Transmission Unit (MTU) of the underlying network. However, 329 statistics from standard SR/RR only collect information from 330 transport layer, which may not fully reflect the quality observed by 331 the application. Video is typically encoded using two frame types 332 i.e., key frames and derived frames. Key frames are normally just 333 spatially compressed, i.e., without prediction from other pictures. 334 The derived frames are temporally compressed, i.e., depend on the key 335 frame for decoding. Hence, Key frames are much larger in size than 336 derived frames. The loss of these key frames results in a 337 substantial reduction in video quality. Thus it is reasonable to 338 consider this application layer information in WebRTC 339 implementations, which influence sender strategies to mitigate the 340 problem or require the accurate assessment of users' quality of 341 experience. 343 The following metrics can also be considered for WebRTC's Statistics 344 API: number of discarded key frames, number of lost key frames, 345 number of discarded derived frames, number of lost derived frames. 346 These metrics can be used to calculate Media Loss Rate (MLR) of MDI. 347 Details of the definition of these metrics are described in 348 [RFC7003]. Additionally, the metric provides the rendered frame 349 rate, an important parameter for quality estimation. 351 5.2.3. Jitter Buffer Metrics 353 The size of the jitter buffer affects the end-to-end delay on the 354 network and also the packet discard rate. When the buffer size is 355 too small, slower packets are not played out and dropped, while when 356 the buffer size is too large, packets are held longer than necessary 357 and consequently reduce conversational quality. Measurement of 358 jitter buffer should not be ignored in the evaluation of end user 359 perception of conversational quality. Jitter buffer related metrics, 360 such as maximum and nominal jitter buffer, could be used to show how 361 the jitter buffer behaves at the receiving endpoint. They are useful 362 for providing better end-user quality of experience (QoE) when jitter 363 buffer factors are used as inputs to calculate MoS values. Thus for 364 those cases, jitter buffer metrics should be considered. The 365 definition of these metrics is provided in [RFC7005]. 367 5.3. Recovery metrics 369 [Editor's Note: Concealment Metrics are currently not considered.] 371 5.3.1. Post-repair Packet Count Metrics 373 Error-resilience mechanisms, like RTP retransmission or FEC, are 374 optional in RTCWEB because the overhead of the repair bits adding to 375 the original streams. But they do help to greatly reduce the impact 376 of packet loss and enhance the quality of transmission. Web 377 applications could support certain repair mechanism after negotiation 378 between both sides of browsers when needed. For these web 379 applications using repair mechanisms, providing some statistic 380 information for the performance of their repair mechanisms could help 381 to have a more accurate quality evaluation. 383 The un-repaired packets count and repaired loss count defined in 384 [I-D.ietf-xrblock-rtcp-xr-post-repair-loss-count] provide the 385 recovery information of the error-resilience mechanisms to the 386 monitoring application or the sending endpoint. The endpoint can use 387 these metrics to ascertain the ratio of repaired packets to lost 388 packets. Including this kind of metrics helps the application 389 evaluate the effectiveness of the applied repair mechanisms. 391 5.3.2. Run Length Encoded Metric for Post-repair 393 [RFC5725] defines run-length encoding for post-repair packets. When 394 using error-resilience mechanisms, the endpoint can correlate the 395 loss run length with this metric to ascertain where the losses and 396 repairs occurred in the interval. This provides more accurate 397 information for recovery mechanisms evaluation than those in 398 Section 5.3.1. However, it is not suggested to use due to their 399 enormous amount of data when RTCP XR are supported. 401 For WebRTC, the application may benefit from the additional 402 information. If losses occur after discards, an endpoint may be able 403 to correlate the two run length vectors to identify congestion- 404 related losses, i.e., a router queue became overloaded causing delays 405 and then overflowed. If the losses are independent, it may indicate 406 bit-error corruption. Lastly, when using error-resilience 407 mechanisms, the endpoint can correlate the loss and post-repair run 408 lengths to ascertain where the losses and repairs occurred in the 409 interval. For example, consecutive losses are likely not to be 410 repaired by a simple FEC scheme. 412 6. Candidate XR Block Metrics for WebRTC Statistics API 414 This document describes a list of additional identifiers to 415 complement the identifiers in Section 4.1 of 416 [I-D.alvestrand-rtcweb-stats-registry] and these group of identifiers 417 are defined on a ReportGroup corresponding to an SSRC. In practice 418 the application MUST be able to query the statistic identifiers on 419 both an incoming (remote) and outgoing (local) media stream. 420 Depending on the support of the corresponding XR report the endpoint 421 MAY be able to query the reception statistics for its outgoing 422 (local) media stream. 424 The following contact information is used for all registrations in 425 this document: 427 Contact: Varun Singh 428 mailto:varun.singh@iki.fi 429 tel:+358-9-470-24785 431 6.1. Variables from XR Blocks 433 6.1.1. Packets and Octets Discarded 435 Name: PacketsDiscarded 437 Definition: Cumulative Number of RTP packets discarded due to late or 438 early-arrival, Appendix A (a) of [RFC7002]. 440 Name: OctetsDiscarded 442 Definition: Cumulative Number of octets discarded due to late or 443 early-arrival, Appendix A of [RFC7243] 445 6.1.2. Cumulative Number of Packets Repaired 447 Name: PacketsRepaired 449 Definition: The cumulative number of lost RTP packets repaired after 450 applying a error-resilience mechanism, Appendix A (b) of 451 [I-D.ietf-xrblock-rtcp-xr-post-repair-loss-count]. To clarify, the 452 value is upper bound to the cumulative number of lost packets. 454 6.1.3. Burst Packet Loss or Discarded 456 Name: BurstPacketDiscarded 458 Definition: The total number of RTP packets discarded during discard 459 bursts, Appendix A (b) of [RFC7003]. 461 Name: BurstPacketLost 463 Definition: The total number of RTP packets lost during loss bursts, 464 Appendix A (c) of [RFC6958]. 466 Name: BurstCount 467 Definition: The cumulative number of bursts of lost RTP packets, 468 Appendix A (e) of [RFC6958]. 470 [RFC3611] recommends a Gmin value of 16. 472 6.1.4. Frame Impairment Metrics 474 Name: FullFramesLostCount 476 Definition: Number of full frames lost, Appendix A (i) of [RFC7004] 478 Name: PartialFramesLostCount 480 Definition: Number of frames partially lost, Appendix A (j) of 481 [RFC7004] 483 Name: FramesDiscardedCount 485 Definition: Number of full frames discarded, Appendix A (g) of 486 [RFC7004] 488 7. IANA Considerations 490 This document requests IANA to update the registry described in 491 [I-D.alvestrand-rtcweb-stats-registry] with the identifiers defined 492 in Section 6. 494 8. Security Considerations 496 The monitoring activities are implemented between two browsers or 497 between a browser and a server. Therefore encryption procedures, 498 such as the ones suggested for a Secure RTCP (SRTCP), need to be 499 used. Currently, the monitoring in RTCWEB introduces no new security 500 considerations beyond those described in [I-D.ietf-rtcweb-rtp-usage], 501 [I-D.ietf-rtcweb-security], and 502 [I-D.alvestrand-rtcweb-stats-registry]. 504 9. Acknowledgements 506 The authors would like to thank Bernard Aboba , Al Morton , Colin 507 Perkins , and Shida Schubert , for their valuable comments and 508 suggestions on earlier version of this document. 510 10. References 511 10.1. Normative References 513 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 514 Requirement Levels", BCP 14, RFC 2119, March 1997. 516 [I-D.alvestrand-rtcweb-stats-registry] 517 Alvestrand, H., "A Registry for WebRTC statistics 518 identifiers", draft-alvestrand-rtcweb-stats-registry-00 519 (work in progress), September 2012. 521 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 522 Jacobson, "RTP: A Transport Protocol for Real-Time 523 Applications", STD 64, RFC 3550, July 2003. 525 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 526 Protocol Extended Reports (RTCP XR)", RFC 3611, November 527 2003. 529 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 530 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 531 July 2006. 533 [RFC5725] Begen, A., Hsu, D., and M. Lague, "Post-Repair Loss RLE 534 Report Block Type for RTP Control Protocol (RTCP) Extended 535 Reports (XRs)", RFC 5725, February 2010. 537 [RFC6776] Clark, A. and Q. Wu, "Measurement Identity and Information 538 Reporting Using a Source Description (SDES) Item and an 539 RTCP Extended Report (XR) Block", RFC 6776, October 2012. 541 [RFC6958] Clark, A., Zhang, S., Zhao, J., and Q. Wu, "RTP Control 542 Protocol (RTCP) Extended Report (XR) Block for Burst/Gap 543 Loss Metric Reporting", RFC 6958, May 2013. 545 [RFC7002] Clark, A., Zorn, G., and Q. Wu, "RTP Control Protocol 546 (RTCP) Extended Report (XR) Block for Discard Count Metric 547 Reporting", RFC 7002, September 2013. 549 [RFC7003] Clark, A., Huang, R., and Q. Wu, "RTP Control Protocol 550 (RTCP) Extended Report (XR) Block for Burst/Gap Discard 551 Metric Reporting", RFC 7003, September 2013. 553 [RFC7004] Zorn, G., Schott, R., Wu, Q., and R. Huang, "RTP Control 554 Protocol (RTCP) Extended Report (XR) Blocks for Summary 555 Statistics Metrics Reporting", RFC 7004, September 2013. 557 [RFC7005] Clark, A., Singh, V., and Q. Wu, "RTP Control Protocol 558 (RTCP) Extended Report (XR) Block for De-Jitter Buffer 559 Metric Reporting", RFC 7005, September 2013. 561 [RFC7097] Ott, J., Singh, V., and I. Curcio, "RTP Control Protocol 562 (RTCP) Extended Report (XR) for RLE of Discarded Packets", 563 RFC 7097, January 2014. 565 [RFC7243] Singh, V., Ott, J., and I. Curcio, "RTP Control Protocol 566 (RTCP) Extended Report (XR) Block for the Bytes Discarded 567 Metric", RFC 7243, May 2014. 569 [I-D.ietf-xrblock-rtcp-xr-post-repair-loss-count] 570 Huang, R. and V. Singh, "RTP Control Protocol (RTCP) 571 Extended Report (XR) for Post-Repair Loss Count Metrics", 572 draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-05 (work 573 in progress), June 2014. 575 10.2. Informative References 577 [I-D.ietf-rtcweb-use-cases-and-requirements] 578 Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- 579 Time Communication Use-cases and Requirements", draft- 580 ietf-rtcweb-use-cases-and-requirements-14 (work in 581 progress), February 2014. 583 [W3C.WD-webrtc-20130910] 584 Bergkvist, A., Burnett, D., Jennings, C., and A. 585 Narayanan, "WebRTC 1.0: Real-time Communication Between 586 Browsers", World Wide Web Consortium WD WD- 587 webrtc-20130910, September 2013, 588 . 590 [I-D.ietf-rtcweb-rtp-usage] 591 Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time 592 Communication (WebRTC): Media Transport and Use of RTP", 593 draft-ietf-rtcweb-rtp-usage-15 (work in progress), May 594 2014. 596 [I-D.ietf-rtcweb-security] 597 Rescorla, E., "Security Considerations for WebRTC", draft- 598 ietf-rtcweb-security-06 (work in progress), January 2014. 600 Appendix A. Change Log 602 Note to the RFC-Editor: please remove this section prior to 603 publication as an RFC. 605 A.1. changes in draft-huang-xrblock-rtcweb-rtcp-xr-metrics-04 607 o Addressed comments from the London IETF meeting: 609 o Removed ECN metrics. 611 o Merged draft-singh-xrblock-webrtc-additional-stats-01 613 Authors' Addresses 615 Rachel Huang 616 Huawei 617 101 Software Avenue, Yuhua District 618 Nanjing, CN 210012 619 China 621 Email: rachel.huang@huawei.com 623 Roni Even 624 Huawei 625 14 David Hamelech 626 Tel Aviv 64953 627 Israel 629 Email: roni.even@mail01.huawei.com 631 Varun Singh 632 Aalto University 633 School of Electrical Engineering 634 Otakaari 5 A 635 Espoo, FIN 02150 636 Finland 638 Email: varun@comnet.tkk.fi 639 URI: http://www.netlab.tkk.fi/~varun/ 641 Dan Romascanu 642 Avaya 643 Park Atidim, Bldg. #3 644 Tel Aviv 61581 645 Israel 647 Email: dromasca@avaya.com 648 Lingli Deng 649 China Mobile 651 Email: denglingli@chinamobile.com