idnits 2.17.1 draft-zheng-xrblock-effective-loss-index-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 30, 2017) is 2367 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Zheng 3 Internet-Draft R. Even 4 Intended status: Informational Q. Wu 5 Expires: May 3, 2018 Huawei 6 R. Gu 7 China Mobile 8 October 30, 2017 10 RTP Control Protocol (RTCP) Extended Report (XR) Block for Effective 11 Loss Index Reporting 12 draft-zheng-xrblock-effective-loss-index-00 14 Abstract 16 This document defines a new metric for RTP applications to measure 17 the effectiveness of stream repair means, and an RTP Control Protocol 18 (RTCP) Extended Report (XR) Block to report the metric. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on May 3, 2018. 37 Copyright Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Effective Loss Index . . . . . . . . . . . . . . . . . . 3 56 1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 57 1.3. RTCP and RTCP XR Reports . . . . . . . . . . . . . . . . 5 58 1.4. Performance Metrics Framework . . . . . . . . . . . . . . 5 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3. Effective Loss Index Report Block . . . . . . . . . . . . . . 5 61 4. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 6 62 4.1. SDP rtcp-xr-attrib Attribute Extension . . . . . . . . . 6 63 4.2. Offer/Answer Usage . . . . . . . . . . . . . . . . . . . 7 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 66 6.1. New RTCP XR Block Type Value . . . . . . . . . . . . . . 7 67 6.2. New RTCP XR SDP Parameter . . . . . . . . . . . . . . . . 8 68 6.3. Contact Information for Registrations . . . . . . . . . . 8 69 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 72 8.2. Informative References . . . . . . . . . . . . . . . . . 8 73 Appendix A. Metric Represented Using the Template from RFC 6390 10 74 A.1. Effective Loss Index . . . . . . . . . . . . . . . . . . 10 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 77 1. Introduction 79 RTP applications often use stream repair means, e.g. FEC (Forward 80 Error Correction) [RFC5109] and/or retransmission [RFC4588] to 81 improve the robustness of media streams. With the presence of those 82 stream repair means, a degree of packet loss can be recovered for a 83 media stream. In the past, some RTCP Extend Reports (XRs) were 84 defined to reflect the situation of post-repair loss. For example, 85 [RFC5725] defines an XR block using Run Length Encoding (RLE) to 86 report post-repair loss; [RFC7509] defines count metrics for post- 87 repair loss. 89 This document proposes a new metric Effective Loss Index (ELI) to 90 measure the effectiveness of stream repair means. The new metric 91 provides a simpler view on the post-repair loss than the mechanisms 92 documented in [RFC5725] and [RFC7509]. EFI is an index, so the 93 values reported from different RTP sources can be compared directly, 94 which makes it easier to rank the effectiveness of loss repair means. 95 An example use case is to find endpoints whose ELI values are at 96 bottom 10%. For those endpoints, more informative XR reports such as 97 those in [RFC5725] and [RFC7509] can then be used to discover more 98 details about the loss situations. 100 This document also defines an XR block to report the metric, which 101 can be found out in Section 3. 103 1.1. Effective Loss Index 105 Effective Loss Index (ELI) uses a simple model to measure the 106 effectiveness of loss repair. The model assumes that repair means 107 are applied onto packets by batches of equal size. Lower ELI means 108 that the repair was more successful. Specifically, a batch is 109 identified by a range of RTP sequence numbers. The size of a batch 110 is number of packets. An application can agree upon a default batch 111 size, or use the SDP signaling defined in Section 4.1 to communicate 112 one. 114 An RTP endpoint is thought to process received packets and apply 115 repair means batch by batch. For each batch, if there is still some 116 unrecoverable loss after having applied the repair means, then the 117 repair means are deemed as ineffective. The ineffectiveness is 118 denoted by Effective Loss Factor (ELF), along with a parameter 119 Effective Loss Threshold, showing below: 121 if Post-Repair Loss > Effective Loss Threshold 122 Effective Loss Factor = 1 123 else 124 Effective Loss Factor = 0 125 endif 127 Figure 1: Calculation of Effective Loss Factor 129 The parameters in Figure 1 are explained below: 131 o Post-Repair Loss is the number of packet lost after repair in the 132 batch. 134 o Effective Loss Threshold is in number of packets. 136 The minimum value of Effective Loss Threshold is zero. This document 137 does not mandate any value for Effective Loss Threshold. 138 Applications can prescribe a value for themselves without signaling. 139 On the other hand, SDP signaling defined in Section 4.1 can be used 140 to communicate the value. Determining an Effective Loss Threshold 141 value for use can be empirical, applications may have to try out and 142 change the value from time to time, depending on their needs. 144 Effective Loss Index is an integer derived by calculating the average 145 Effective Loss Factor across a sequence of consecutive batches of RTP 146 packets. Let ELF(i) be the Effective Loss Factor calculated for i-th 147 batch, and N as number of batches in the sequence, then Effective 148 Loss Index is calculated as: 150 ELF(1)+ELF(2)+ ...+ELF(N) 151 Effective Loss Index = ------------------------- x 10000 152 N 154 Figure 2: Calculation of Effective Loss Index 156 The following is an example of how to calculate Effective Loss Index. 157 For simplicity and demonstration purpose, the size of batches is 158 assumed to be 3, and the Effective Loss Threshold is assumed to be 1. 159 The example processes a sequence of 9 RTP packets in 3 batches. 161 Batch Post-Repair Effective 162 Loss Loss Factor 163 | 1 2 3 | 2, 3 1 164 | 4 5 6 | 5 0 165 | 7 8 9 | 7 0 167 1 + 0 + 0 168 Effective Loss Index = ----------- x 10000 = 3333 169 3 171 1.2. Applicability 173 The metric defined by this document is applicable to a range of RTP 174 applications that send packets in batches of equal length, probably 175 with stream repair means (e.g., Forward Error Correction (FEC) 176 [RFC5109] and/or retransmission [RFC4588]) applied on the batches. 177 Note that in order to not interfere with the batches being protected, 178 any additional packets generated by the stream repair means SHOULD be 179 in a different RTP stream. 181 The number of batches among which ELI is calculated should not be too 182 few, otherwise the result may be too biased. However, specifying a 183 minimal number of batches seems unrealistic, due to the stream repair 184 means used by applications can be quite different. This document 185 leaves it to applications to choose a suitable minimal value for the 186 number of batches. 188 1.3. RTCP and RTCP XR Reports 190 The use of RTCP for reporting is defined in [RFC3550]. [RFC3611] 191 defines an extensible structure for reporting by using an RTCP 192 Extended Report (XR). This document defines a new Extended Report 193 block for use with [RFC3550] and [RFC3611]. 195 1.4. Performance Metrics Framework 197 The Performance Metrics Framework [RFC6390] provides guidance on the 198 definition and specification of performance metrics. The "Guidelines 199 for Use of the RTP Monitoring Framework" [RFC6792] provides 200 guidelines for reporting block format using RTCP XR. The Metrics 201 Block described in this document is in accordance with the guidelines 202 in [RFC6390] and [RFC6792]. 204 2. Terminology 206 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 207 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 208 document are to be interpreted as described in RFC 2119 [RFC2119]. 210 3. Effective Loss Index Report Block 212 The Effective Loss Index Report Block has the following format: 214 0 1 2 3 4 215 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | BT=TBD | Reserved | Block length = 3 | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | SSRC of Source | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | Effective Loss Index | Padding | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 Block Type (BT): 8 bits: An Effect Loss Index Report Block is 225 identified by the constant 'TBD'. 227 [[Editor Note: should replace 'TBD' with assigned value]] 229 Reserved: 8 bits: These bits are reserved for future use. They MUST 230 be set to zero by senders and ignored by receivers (see 231 Section 4.2 of [RFC6709]). 233 Block length: 16 bits: This field is in accordance with the 234 definition in [RFC3611]. In this report block, it MUST be set to 235 3. The block MUST be discarded if the block length is set to a 236 different value. 238 SSRC of source: 32 bits: As defined in Section 4.1 of [RFC3611]. 240 Effective Loss Index: 16 bits: The value of this field SHOULD be set 241 to the calculated result of Effective Loss Index (as in Figure 2). 243 Padding: 16 bits: These bits MUST be set to zero by senders and 244 ignored by receivers. 246 4. SDP Signaling 248 [RFC3611] defines the use of SDP (Session Description Protocol) for 249 signaling the use of RTCP XR blocks. However, XR blocks MAY be used 250 without prior signaling (see Section 5 of [RFC3611]). 252 4.1. SDP rtcp-xr-attrib Attribute Extension 254 This session augments the SDP attribute "rtcp-xr" defined in 255 Section 5.1 of [RFC3611] by providing an additional value of "xr- 256 format" to signal the use of the report block defined in this 257 document. The ABNF [RFC5234] syntax is as follows. 259 xr-format =/ xr-eli-block 261 xr-eli-block = "effective-loss-index" 262 [ ":" effective-loss-batch-size] 263 [ ">" effective-loss-threshold] 265 effective-loss-batch-size = 1*DIGIT 266 ; the batch size is in number of packets 268 effective-loss-threshold = 1*DIGIT 269 ; the threshold is in number of packets 271 DIGIT = %x30-39 273 The SDP attribute "xr-eli-block" is designed to contain two optional 274 values, one for signaling the batch size, another for the Effective 275 Loss Threshold. Here are some examples: 277 1. signaling both batch size (100) and Effective Loss Threshold (2) 279 xr-eli-block = "effective-loss-index" : "100" > "2" 281 2. signaling only batch size (100) 283 xr-eli-block = "effective-loss-index" : "100" 285 3. signaling only Effective Loss Threshold (2) 287 xr-eli-block = "effective-loss-index" > "2" 289 4.2. Offer/Answer Usage 291 When SDP is used in offer/answer context, the SDP Offer/Answer usage 292 defined in [RFC3611] for the unilateral "rtcp-xr" attribute 293 parameters applies. For detailed usage of Offer/Answer for 294 unilateral parameters, refer to Section 5.2 of [RFC3611]. 296 5. Security Considerations 298 This proposed RTCP XR block introduces no new security considerations 299 beyond those described in [RFC3611] This block does not provide per- 300 packet statistics, so the risk to confidentiality documented in 301 Section 7, paragraph 3 of [RFC3611] does not apply. 303 An attacker may put incorrect information in the Effective Loss Index 304 reports. Implementers should consider the guidance in [RFC7202] for 305 using appropriate security mechanisms, i.e., where security is a 306 concern, the implementation should apply encryption and 307 authentication to the report block. For example, this can be 308 achieved by using the AVPF profile together with the Secure RTP 309 profile as defined in [RFC3711] an appropriate combination of the two 310 profiles (an "SAVPF") is specified in [RFC5124] However, other 311 mechanisms also exist (documented in [RFC7201] and might be more 312 suitable. 314 6. IANA Considerations 316 New block types for RTCP XR are subject to IANA registration. For 317 general guidelines on IANA considerations for RTCP XR, refer to 318 [RFC3611]. 320 6.1. New RTCP XR Block Type Value 322 This document assigns the block type value 'TBD' in the IANA "RTP 323 Control Protocol Extended Reports (RTCP XR) Block Type Registry" to 324 the "Post-Repair Loss Count Metrics Report Block". 326 [[Editor Note: should replace 'TBD' with assigned value]] 328 6.2. New RTCP XR SDP Parameter 330 This document also registers a new parameter "effective-loss-index" 331 in the "RTP Control Protocol Extended Reports (RTCP XR) Session 332 Description Protocol (SDP) Parameters Registry". 334 6.3. Contact Information for Registrations 336 The contact information for the registrations is: 338 RAI Area Directors 340 7. Acknowledgements 342 This document has benefited greatly from the comments of various 343 people. The following individuals have contributed to this document: 344 Rachel Huang, Colin Perkins, Yanfang Zhang, Lingyan Wu. 346 8. References 348 8.1. Normative References 350 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 351 Requirement Levels", BCP 14, RFC 2119, 352 DOI 10.17487/RFC2119, March 1997, . 355 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 356 Jacobson, "RTP: A Transport Protocol for Real-Time 357 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 358 July 2003, . 360 8.2. Informative References 362 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 363 "RTP Control Protocol Extended Reports (RTCP XR)", 364 RFC 3611, DOI 10.17487/RFC3611, November 2003, 365 . 367 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 368 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 369 RFC 3711, DOI 10.17487/RFC3711, March 2004, 370 . 372 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 373 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 374 DOI 10.17487/RFC4588, July 2006, . 377 [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error 378 Correction", RFC 5109, DOI 10.17487/RFC5109, December 379 2007, . 381 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 382 Real-time Transport Control Protocol (RTCP)-Based Feedback 383 (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February 384 2008, . 386 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 387 Specifications: ABNF", STD 68, RFC 5234, 388 DOI 10.17487/RFC5234, January 2008, . 391 [RFC5725] Begen, A., Hsu, D., and M. Lague, "Post-Repair Loss RLE 392 Report Block Type for RTP Control Protocol (RTCP) Extended 393 Reports (XRs)", RFC 5725, DOI 10.17487/RFC5725, February 394 2010, . 396 [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New 397 Performance Metric Development", BCP 170, RFC 6390, 398 DOI 10.17487/RFC6390, October 2011, . 401 [RFC6709] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design 402 Considerations for Protocol Extensions", RFC 6709, 403 DOI 10.17487/RFC6709, September 2012, . 406 [RFC6792] Wu, Q., Ed., Hunt, G., and P. Arden, "Guidelines for Use 407 of the RTP Monitoring Framework", RFC 6792, 408 DOI 10.17487/RFC6792, November 2012, . 411 [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP 412 Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, 413 . 415 [RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP 416 Framework: Why RTP Does Not Mandate a Single Media 417 Security Solution", RFC 7202, DOI 10.17487/RFC7202, April 418 2014, . 420 [RFC7509] Huang, R. and V. Singh, "RTP Control Protocol (RTCP) 421 Extended Report (XR) for Post-Repair Loss Count Metrics", 422 RFC 7509, DOI 10.17487/RFC7509, May 2015, 423 . 425 Appendix A. Metric Represented Using the Template from RFC 6390 427 A.1. Effective Loss Index 429 o Metric Name: RTP Effective Loss Index. 431 o Metric Description: The effectiveness of stream repair means 432 applied on a sequence of RTP packets. 434 o Method of Measurement or Calculation: See the "Effective Loss 435 Index" definition in Section 1.1. It is directly measured and 436 must be measured for the primary source RTP packets with no 437 further chance of repair. 439 o Units of Measurement: This metric is expressed as a 16-bit 440 unsigned integer value representing the effectiveness of stream 441 repair means. 443 o Measurement Point(s) with Potential Measurement Domain: It is 444 measured at the receiving end of the RTP stream. 446 o Measurement Timing: This metric relies on the sequence number 447 interval to determine measurement timing. 449 o Use and Applications: These metrics are applicable to any RTP 450 application, especially those that use loss-repair mechanisms. 451 See Section 1 for details. 453 o Reporting Model: See RFC 3611. 455 Authors' Addresses 457 Hui Zheng (Marvin) 458 Huawei 460 Email: marvin.zhenghui@huawei.com 462 Roni Even 463 Huawei 465 Email: roni.even@huawei.com 466 Qin Wu 467 Huawei 469 Email: bill.wu@huawei.com 471 Rong Gu 472 China Mobile 474 Email: gurong_cmcc@outlook.com