idnits 2.17.1 draft-zheng-xr-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 2370 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 Huawei 5 Expires: May 3, 2018 October 30, 2017 7 RTP Control Protocol (RTCP) Extended Report (XR) Block for Effective 8 Loss Index Reporting 9 draft-zheng-xr-effective-loss-index-00 11 Abstract 13 This document defines a new metric for RTP applications to measure 14 the effectiveness of stream repair means, and an RTP Control Protocol 15 (RTCP) Extended Report (XR) Block to report the metric. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on May 3, 2018. 34 Copyright Notice 36 Copyright (c) 2017 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Effective Loss Index . . . . . . . . . . . . . . . . . . 3 53 1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 54 1.3. RTCP and RTCP XR Reports . . . . . . . . . . . . . . . . 4 55 1.4. Performance Metrics Framework . . . . . . . . . . . . . . 5 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 3. Effective Loss Index Report Block . . . . . . . . . . . . . . 5 58 4. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 6 59 4.1. SDP rtcp-xr-attrib Attribute Extension . . . . . . . . . 6 60 4.2. Offer/Answer Usage . . . . . . . . . . . . . . . . . . . 7 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 63 6.1. New RTCP XR Block Type Value . . . . . . . . . . . . . . 7 64 6.2. New RTCP XR SDP Parameter . . . . . . . . . . . . . . . . 7 65 6.3. Contact Information for Registrations . . . . . . . . . . 8 66 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 69 8.2. Informative References . . . . . . . . . . . . . . . . . 8 70 Appendix A. Metric Represented Using the Template from RFC 6390 10 71 A.1. Effective Loss Index . . . . . . . . . . . . . . . . . . 10 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 74 1. Introduction 76 RTP applications often use stream repair means, e.g. FEC (Forward 77 Error Correction) [RFC5109] and/or retransmission [RFC4588] to 78 improve the robustness of media streams. With the presence of those 79 stream repair means, a degree of packet loss can be recovered for a 80 media stream. In the past, some RTCP Extend Reports (XRs) were 81 defined to reflect the situation of post-repair loss. For example, 82 [RFC5725] defines an XR block using Run Length Encoding (RLE) to 83 report post-repair loss; [RFC7509] defines count metrics for post- 84 repair loss. 86 This document proposes a new metric Effective Loss Index (ELI) to 87 measure the effectiveness of stream repair means. The new metric 88 provides a simpler view on the post-repair loss than the mechanisms 89 documented in [RFC5725] and [RFC7509]. EFI is an index, so the 90 values reported from different RTP sources can be compared directly, 91 which makes it easier to rank the effectiveness of loss repair means. 92 An example use case is to find endpoints whose ELI values are at 93 bottom 10%. For those endpoints, more informative XR reports such as 94 those in [RFC5725] and [RFC7509] can then be used to discover more 95 details about the loss situations. 97 This document also defines an XR block to report the metric, which 98 can be found out in Section 3. 100 1.1. Effective Loss Index 102 Effective Loss Index (ELI) uses a simple model to measure the 103 effectiveness of loss repair. The model assumes that repair means 104 are applied onto packets by batches of equal size. Lower ELI means 105 that the repair was more successful. Specifically, a batch is 106 identified by a range of RTP sequence numbers. The size of a batch 107 is number of packets. An application can agree upon a default batch 108 size, or use the SDP signaling defined in Section 4.1 to communicate 109 one. 111 An RTP endpoint is thought to process received packets and apply 112 repair means batch by batch. For each batch, if there is still some 113 unrecoverable loss after having applied the repair means, then the 114 repair means are deemed as ineffective. The ineffectiveness is 115 denoted by Effective Loss Factor (ELF), along with a parameter 116 Effective Loss Threshold, showing below: 118 if Post-Repair Loss > Effective Loss Threshold 119 Effective Loss Factor = 1 120 else 121 Effective Loss Factor = 0 122 endif 124 Figure 1: Calculation of Effective Loss Factor 126 The parameters in Figure 1 are explained below: 128 o Post-Repair Loss is the number of packet lost after repair in the 129 batch. 131 o Effective Loss Threshold is in number of packets. 133 The minimum value of Effective Loss Threshold is zero. This document 134 does not mandate any value for Effective Loss Threshold. 135 Applications can prescribe a value for themselves without signaling. 136 On the other hand, SDP signaling defined in Section 4.1 can be used 137 to communicate the value. Determining an Effective Loss Threshold 138 value for use can be empirical, applications may have to try out and 139 change the value from time to time, depending on their needs. 141 Effective Loss Index is an integer derived by calculating the average 142 Effective Loss Factor across a sequence of consecutive batches of RTP 143 packets. Let ELF(i) be the Effective Loss Factor calculated for i-th 144 batch, and N as number of batches in the sequence, then Effective 145 Loss Index is calculated as: 147 ELF(1)+ELF(2)+ ...+ELF(N) 148 Effective Loss Index = ------------------------- x 10000 149 N 151 Figure 2: Calculation of Effective Loss Index 153 The following is an example of how to calculate Effective Loss Index. 154 For simplicity and demonstration purpose, the size of batches is 155 assumed to be 3, and the Effective Loss Threshold is assumed to be 1. 156 The example processes a sequence of 9 RTP packets in 3 batches. 158 Batch Post-Repair Effective 159 Loss Loss Factor 160 | 1 2 3 | 2, 3 1 161 | 4 5 6 | 5 0 162 | 7 8 9 | 7 0 164 1 + 0 + 0 165 Effective Loss Index = ----------- x 10000 = 3333 166 3 168 1.2. Applicability 170 The metric defined by this document is applicable to a range of RTP 171 applications that send packets in batches of equal length, probably 172 with stream repair means (e.g., Forward Error Correction (FEC) 173 [RFC5109] and/or retransmission [RFC4588]) applied on the batches. 174 Note that in order to not interfere with the batches being protected, 175 any additional packets generated by the stream repair means SHOULD be 176 in a different RTP stream. 178 The number of batches among which ELI is calculated should not be too 179 few, otherwise the result may be too biased. However, specifying a 180 minimal number of batches seems unrealistic, due to the stream repair 181 means used by applications can be quite different. This document 182 leaves it to applications to choose a suitable minimal value for the 183 number of batches. 185 1.3. RTCP and RTCP XR Reports 187 The use of RTCP for reporting is defined in [RFC3550]. [RFC3611] 188 defines an extensible structure for reporting by using an RTCP 189 Extended Report (XR). This document defines a new Extended Report 190 block for use with [RFC3550] and [RFC3611]. 192 1.4. Performance Metrics Framework 194 The Performance Metrics Framework [RFC6390] provides guidance on the 195 definition and specification of performance metrics. The "Guidelines 196 for Use of the RTP Monitoring Framework" [RFC6792] provides 197 guidelines for reporting block format using RTCP XR. The Metrics 198 Block described in this document is in accordance with the guidelines 199 in [RFC6390] and [RFC6792]. 201 2. Terminology 203 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 204 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 205 document are to be interpreted as described in RFC 2119 [RFC2119]. 207 3. Effective Loss Index Report Block 209 The Effective Loss Index Report Block has the following format: 211 0 1 2 3 4 212 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 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | BT=TBD | Reserved | Block length = 3 | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | SSRC of Source | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | Effective Loss Index | Padding | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 Block Type (BT): 8 bits: An Effect Loss Index Report Block is 222 identified by the constant 'TBD'. 224 [[Editor Note: should replace 'TBD' with assigned value]] 226 Reserved: 8 bits: These bits are reserved for future use. They MUST 227 be set to zero by senders and ignored by receivers (see 228 Section 4.2 of [RFC6709]). 230 Block length: 16 bits: This field is in accordance with the 231 definition in [RFC3611]. In this report block, it MUST be set to 232 3. The block MUST be discarded if the block length is set to a 233 different value. 235 SSRC of source: 32 bits: As defined in Section 4.1 of [RFC3611]. 237 Effective Loss Index: 16 bits: The value of this field SHOULD be set 238 to the calculated result of Effective Loss Index (as in Figure 2). 240 Padding: 16 bits: These bits MUST be set to zero by senders and 241 ignored by receivers. 243 4. SDP Signaling 245 [RFC3611] defines the use of SDP (Session Description Protocol) for 246 signaling the use of RTCP XR blocks. However, XR blocks MAY be used 247 without prior signaling (see Section 5 of [RFC3611]). 249 4.1. SDP rtcp-xr-attrib Attribute Extension 251 This session augments the SDP attribute "rtcp-xr" defined in 252 Section 5.1 of [RFC3611] by providing an additional value of "xr- 253 format" to signal the use of the report block defined in this 254 document. The ABNF [RFC5234] syntax is as follows. 256 xr-format =/ xr-eli-block 258 xr-eli-block = "effective-loss-index" 259 [ ":" effective-loss-batch-size] 260 [ ">" effective-loss-threshold] 262 effective-loss-batch-size = 1*DIGIT 263 ; the batch size is in number of packets 265 effective-loss-threshold = 1*DIGIT 266 ; the threshold is in number of packets 268 DIGIT = %x30-39 270 The SDP attribute "xr-eli-block" is designed to contain two optional 271 values, one for signaling the batch size, another for the Effective 272 Loss Threshold. Here are some examples: 274 1. signaling both batch size (100) and Effective Loss Threshold (2) 276 xr-eli-block = "effective-loss-index" : "100" > "2" 278 2. signaling only batch size (100) 280 xr-eli-block = "effective-loss-index" : "100" 282 3. signaling only Effective Loss Threshold (2) 284 xr-eli-block = "effective-loss-index" > "2" 286 4.2. Offer/Answer Usage 288 When SDP is used in offer/answer context, the SDP Offer/Answer usage 289 defined in [RFC3611] for the unilateral "rtcp-xr" attribute 290 parameters applies. For detailed usage of Offer/Answer for 291 unilateral parameters, refer to Section 5.2 of [RFC3611]. 293 5. Security Considerations 295 This proposed RTCP XR block introduces no new security considerations 296 beyond those described in [RFC3611] This block does not provide per- 297 packet statistics, so the risk to confidentiality documented in 298 Section 7, paragraph 3 of [RFC3611] does not apply. 300 An attacker may put incorrect information in the Effective Loss Index 301 reports. Implementers should consider the guidance in [RFC7202] for 302 using appropriate security mechanisms, i.e., where security is a 303 concern, the implementation should apply encryption and 304 authentication to the report block. For example, this can be 305 achieved by using the AVPF profile together with the Secure RTP 306 profile as defined in [RFC3711] an appropriate combination of the two 307 profiles (an "SAVPF") is specified in [RFC5124] However, other 308 mechanisms also exist (documented in [RFC7201] and might be more 309 suitable. 311 6. IANA Considerations 313 New block types for RTCP XR are subject to IANA registration. For 314 general guidelines on IANA considerations for RTCP XR, refer to 315 [RFC3611]. 317 6.1. New RTCP XR Block Type Value 319 This document assigns the block type value 'TBD' in the IANA "RTP 320 Control Protocol Extended Reports (RTCP XR) Block Type Registry" to 321 the "Post-Repair Loss Count Metrics Report Block". 323 [[Editor Note: should replace 'TBD' with assigned value]] 325 6.2. New RTCP XR SDP Parameter 327 This document also registers a new parameter "effective-loss-index" 328 in the "RTP Control Protocol Extended Reports (RTCP XR) Session 329 Description Protocol (SDP) Parameters Registry". 331 6.3. Contact Information for Registrations 333 The contact information for the registrations is: 335 RAI Area Directors 337 7. Acknowledgements 339 This document has benefited greatly from the comments of various 340 people. The following individuals have contributed to this document: 341 Rachel Huang, Colin Perkins, Yanfang Zhang, Lingyan Wu. 343 8. References 345 8.1. Normative References 347 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 348 Requirement Levels", BCP 14, RFC 2119, 349 DOI 10.17487/RFC2119, March 1997, . 352 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 353 Jacobson, "RTP: A Transport Protocol for Real-Time 354 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 355 July 2003, . 357 8.2. Informative References 359 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 360 "RTP Control Protocol Extended Reports (RTCP XR)", 361 RFC 3611, DOI 10.17487/RFC3611, November 2003, 362 . 364 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 365 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 366 RFC 3711, DOI 10.17487/RFC3711, March 2004, 367 . 369 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 370 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 371 DOI 10.17487/RFC4588, July 2006, . 374 [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error 375 Correction", RFC 5109, DOI 10.17487/RFC5109, December 376 2007, . 378 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 379 Real-time Transport Control Protocol (RTCP)-Based Feedback 380 (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February 381 2008, . 383 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 384 Specifications: ABNF", STD 68, RFC 5234, 385 DOI 10.17487/RFC5234, January 2008, . 388 [RFC5725] Begen, A., Hsu, D., and M. Lague, "Post-Repair Loss RLE 389 Report Block Type for RTP Control Protocol (RTCP) Extended 390 Reports (XRs)", RFC 5725, DOI 10.17487/RFC5725, February 391 2010, . 393 [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New 394 Performance Metric Development", BCP 170, RFC 6390, 395 DOI 10.17487/RFC6390, October 2011, . 398 [RFC6709] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design 399 Considerations for Protocol Extensions", RFC 6709, 400 DOI 10.17487/RFC6709, September 2012, . 403 [RFC6792] Wu, Q., Ed., Hunt, G., and P. Arden, "Guidelines for Use 404 of the RTP Monitoring Framework", RFC 6792, 405 DOI 10.17487/RFC6792, November 2012, . 408 [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP 409 Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, 410 . 412 [RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP 413 Framework: Why RTP Does Not Mandate a Single Media 414 Security Solution", RFC 7202, DOI 10.17487/RFC7202, April 415 2014, . 417 [RFC7509] Huang, R. and V. Singh, "RTP Control Protocol (RTCP) 418 Extended Report (XR) for Post-Repair Loss Count Metrics", 419 RFC 7509, DOI 10.17487/RFC7509, May 2015, 420 . 422 Appendix A. Metric Represented Using the Template from RFC 6390 424 A.1. Effective Loss Index 426 o Metric Name: RTP Effective Loss Index. 428 o Metric Description: The effectiveness of stream repair means 429 applied on a sequence of RTP packets. 431 o Method of Measurement or Calculation: See the "Effective Loss 432 Index" definition in Section 1.1. It is directly measured and 433 must be measured for the primary source RTP packets with no 434 further chance of repair. 436 o Units of Measurement: This metric is expressed as a 16-bit 437 unsigned integer value representing the effectiveness of stream 438 repair means. 440 o Measurement Point(s) with Potential Measurement Domain: It is 441 measured at the receiving end of the RTP stream. 443 o Measurement Timing: This metric relies on the sequence number 444 interval to determine measurement timing. 446 o Use and Applications: These metrics are applicable to any RTP 447 application, especially those that use loss-repair mechanisms. 448 See Section 1 for details. 450 o Reporting Model: See RFC 3611. 452 Authors' Addresses 454 Hui Zheng (Marvin) 455 Huawei 457 Email: marvin.zhenghui@huawei.com 459 Roni Even 460 Huawei 462 Email: roni.even@huawei.com