idnits 2.17.1 draft-zheng-xrblock-effective-loss-index-01.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 (January 29, 2018) is 2277 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: August 2, 2018 Huawei 6 R. Gu 7 China Mobile 8 R. Huang 9 Huawei 10 January 29, 2018 12 RTP Control Protocol (RTCP) Extended Report (XR) Block for Effective 13 Loss Index Reporting 14 draft-zheng-xrblock-effective-loss-index-01 16 Abstract 18 This document defines a new metric for RTP monitors to estimate the 19 effectiveness of stream repair means, and an RTP Control Protocol 20 (RTCP) Extended Report (XR) Block to report the metric. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on May 3, 2018. 39 Copyright Notice 41 Copyright (c) 2018 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Effective Loss Index . . . . . . . . . . . . . . . . . . . 3 58 1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 59 1.3. RTCP and RTCP XR Reports . . . . . . . . . . . . . . . . . 5 60 1.4. Performance Metrics Framework . . . . . . . . . . . . . . 5 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3. Effective Loss Index Report Block . . . . . . . . . . . . . . 5 63 4. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 6 64 4.1. SDP rtcp-xr-attrib Attribute Extension . . . . . . . . . . 6 65 4.2. Offer/Answer Usage . . . . . . . . . . . . . . . . . . . . 8 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 68 6.1. New RTCP XR Block Type Value . . . . . . . . . . . . . . . 8 69 6.2. New RTCP XR SDP Parameter . . . . . . . . . . . . . . . . 9 70 6.3. Contact Information for Registrations . . . . . . . . . . 9 71 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 74 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 75 Appendix A. Metric Represented Using the Template from RFC 6390 . 11 76 A.1. Effective Loss Index . . . . . . . . . . . . . . . . . . . 11 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 79 1. Introduction 81 RTP applications often use stream repair means, e.g. FEC (Forward 82 Error Correction) [RFC5109] and/or retransmission [RFC4588] to 83 improve the robustness of media streams. With the presence of those 84 stream repair means, a degree of packet loss can be recovered for a 85 media stream. In the past, some RTCP Extend Reports (XRs) were 86 defined to reflect the situation of post-repair loss. For example, 87 [RFC5725] defines an XR block using Run Length Encoding (RLE) to 88 report post-repair loss; [RFC7509] defines count metrics for post- 89 repair loss. 91 This document proposes a new metric Effective Loss Index (ELI) to 92 estimate the effectiveness of stream repair means. The new metric 93 provides a simpler view on the post-repair loss than the mechanisms 94 documented in [RFC5725] and [RFC7509]. EFI is an index, so the 95 values reported from the monitors deployed in the different places in 96 the network can be compared directly, which makes it easier to 97 diagnose the network problem when delivering the RTP streams. A use 98 case is to compare the ELI value reported by a monitor with a certain 99 reasonable threshold to see if there are any problems during an RTP 100 streaming session. For those endpoints, more informative XR reports 101 such as those in [RFC5725] and [RFC7509] can then be used to discover 102 more details about the loss situations. 104 This document also defines in section 3, an XR block to report the 105 metric. 107 1.1. Effective Loss Index 109 Effective Loss Index (ELI) uses a simple model to measure the loss 110 impact after applying loss repairsof loss repair. It is useful 111 especially in the middleboxes which usually are passive observer and 112 do not have the ability to recover the loss data. 114 The model assumes that repair means are applied onto packets by 115 batches of equal size. Lower ELI means that loss impact is minimal. 116 Specifically, a batch is identified by a range of RTP sequence 117 numbers. The size of a batch is number of packets. An application 118 can agree upon a default batch size, or use the SDP signaling defined 119 in Section 4.1 to communicate one if the middlebox can see the SDP, 120 or just configure it. 122 An RTP endpoint is assumed to process received packets and apply 123 repair means batch by batch. For each batch, if there is still some 124 unrecoverable loss after having applied the repair means, then the 125 repair means are deemed as ineffective. The ineffectiveness is 126 denoted by Effective Loss Factor (ELF), along with a parameter Loss 127 Repair Threshold, showing below: 129 if Loss Packets Number > Loss Repair Threshold 130 Effective Loss Factor = 1 131 else 132 Effective Loss Factor = 0 133 endif 135 Figure 1: Calculation of Effective Loss Factor 137 The parameters in Figure 1 are explained below: 139 o Loss Packets Number is the number of packet lost in the batch. 141 o Loss Repair Threshold indicates the maximum loss packets number 142 that can be recovered. 144 The minimum value of Loss Repair Threshold is zero, which means there 145 is no loss repair. This document does not mandate any value for Loss 146 Repair Threshold. Applications can prescribe a value for themselves 147 without signaling. For example, it can be calculated by the batch 148 size multiplied by the fixed redundancy ratio of the FEC algorithm. 149 On the other hand, SDP signaling defined in Section 4.1 can be used 150 to communicate the value. 152 Effective Loss Index is an integer derived by calculating the average 153 Effective Loss Factor across a sequence of consecutive batches of RTP 154 packets. Let ELF(i) be the Effective Loss Factor calculated for i-th 155 batch, and N as number of batches in the sequence, then Effective 156 Loss Index is calculated as: 158 ELF(1)+ELF(2)+ ...+ELF(N) 159 Effective Loss Index = ------------------------- 160 N 162 Figure 2: Calculation of Effective Loss Index 164 The following is an example of how to calculate Effective Loss Index. 165 For simplicity and demonstration purpose, the size of a batch is 166 assumed to be 3, and the Loss Repair Threshold is assumed to be 1. 167 The example processes a sequence of 9 RTP packets (x means lost) in 7 168 batches. 170 1xx4x6x89 172 Batch Loss Effective Loss Factor 173 | 1 2 3 | 2, 3 1 174 | 2 3 4 | 2, 3 1 175 | 3 4 5 | 3 0 176 | 4 5 6 | 5 0 177 | 5 6 7 | 5, 7 1 178 | 6 7 8 | 7 0 179 | 7 8 9 | 7 0 181 1+1+0+0+1+0+0 182 Effective Loss Index = --------------- = 0.4285 183 7 185 This example provides fine grained estimation for loss recovery. It 186 can detect the loss burst happening over batches. Implementations can 187 also do coarse grained estimation by simply dividing total packets 188 into several batches. 190 1.2. Applicability 191 The metric defined by this document is applicable to a range of RTP 192 applications that send packets with stream repair means (e.g., 193 Forward Error Correction (FEC) [RFC5109] and/or retransmission 194 [RFC4588]) applied on them. Note that this metric is only valuable 195 for FECs where he redundant data are sent in a different RTP stream 196 from the original media stream. 198 The number of batches among which ELI is calculated should not be too 199 few, otherwise the result may be biased. It is suggested to calculate 200 it based on the total number of RTP packets during the measurement 201 interval, as in the section 1.1 example: 203 The number of batches = (The total number of RTP packets - the size 204 of a batch) + 1. 206 1.3. RTCP and RTCP XR Reports 208 The use of RTCP for reporting is defined in [RFC3550]. [RFC3611] 209 defines an extensible structure for reporting by using an RTCP 210 Extended Report (XR). This document defines a new Extended Report 211 block for use with [RFC3550] and [RFC3611]. 213 1.4. Performance Metrics Framework 215 The Performance Metrics Framework [RFC6390] provides guidance on the 216 definition and specification of performance metrics. The "Guidelines 217 for Use of the RTP Monitoring Framework" [RFC6792] provides 218 guidelines for reporting block format using RTCP XR. The Metrics 219 Block described in this document is in accordance with the guidelines 220 in [RFC6390] and [RFC6792]. 222 2. Terminology 224 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 225 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 226 document are to be interpreted as described in RFC 2119 [RFC2119]. 228 3. Effective Loss Index Report Block 230 The Effective Loss Index Report Block has the following format: 232 0 1 2 3 4 233 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 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | BT=TBD | Reserved | Block length = 3 | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | SSRC of Source | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | Effective Loss Index | Padding | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 Block Type (BT): 8 bits: An Effect Loss Index Report Block is 243 identified by the constant 'TBD'. 245 [[Editor Note: should replace 'TBD' with assigned value]] 247 Reserved: 8 bits: These bits are reserved for future use. They MUST 248 be set to zero by senders and ignored by receivers (see 249 Section 4.2 of [RFC6709]). 251 Block length: 16 bits: This field is in accordance with the 252 definition in [RFC3611]. In this report block, it MUST be set to 254 3. The block MUST be discarded if the block length is set to a 255 different value. 257 SSRC of source: 32 bits: The SSRC of the RTP data packet source 258 being reported upon by this report block, as defined in Section 259 4.1 of [RFC3611]. 261 Effective Loss Index: 16 bits: The value of Effective Loss Index, 262 equivalent to taking the integer part after multiplying the the 263 calculated result of Effective Loss Index (as in Figure 2) by 264 65535. 266 Padding: 16 bits: These bits MUST be set to zero by senders and 267 ignored by receivers. 269 4. SDP Signaling 271 [RFC3611] defines the use of SDP (Session Description Protocol) for 272 signaling the use of RTCP XR blocks. However, XR blocks MAY be used 273 without prior signaling (see Section 5 of [RFC3611]). 275 4.1. SDP rtcp-xr-attrib Attribute Extension 277 This session augments the SDP attribute "rtcp-xr" defined in 278 Section 5.1 of [RFC3611] by providing an additional value of "xr- 279 format" to signal the use of the report block defined in this 280 document. The ABNF [RFC5234] syntax is as follows. 282 xr-format =/ xr-eli-block 284 xr-eli-block = "effective-loss-index" 285 [ ":" effective-loss-batch-size] 287 [ ">" effective-loss-threshold] 289 effective-loss-batch-size = 1*DIGIT 290 ; the batch size is in number of packets 292 effective-loss-threshold = 1*DIGIT 293 ; the threshold is in number of packets 295 DIGIT = %x30-39 297 The SDP attribute "xr-eli-block" is designed to contain two optional 298 values, one for signaling the batch size, another for the Effective 299 Loss Threshold. Here are some examples: 301 1. signaling both batch size (100) and Effective Loss Threshold (2) 303 xr-eli-block = "effective-loss-index" : "100" > "2" 305 2. signaling only batch size (100) 307 xr-eli-block = "effective-loss-index" : "100" 309 3. signaling only Effective Loss Threshold (2) 311 xr-eli-block = "effective-loss-index" > "2" 313 4.2. Offer/Answer Usage 315 When SDP is used in offer/answer context, the SDP Offer/Answer usage 316 defined in [RFC3611] for the unilateral "rtcp-xr" attribute 317 parameters applies. For detailed usage of Offer/Answer for 318 unilateral parameters, refer to Section 5.2 of [RFC3611]. 320 5. Security Considerations 322 This proposed RTCP XR block introduces no new security considerations 323 beyond those described in [RFC3611] This block does not provide per- 324 packet statistics, so the risk to confidentiality documented in 325 Section 7, paragraph 3 of [RFC3611] does not apply. 327 An attacker may put incorrect information in the Effective Loss Index 328 reports. Implementers should consider the guidance in [RFC7202] for 329 using appropriate security mechanisms, i.e., where security is a 330 concern, the implementation should apply encryption and 331 authentication to the report block. For example, this can be 332 achieved by using the AVPF profile together with the Secure RTP 333 profile as defined in [RFC3711] an appropriate combination of the two 334 profiles (an "SAVPF") is specified in [RFC5124] However, other 335 mechanisms also exist (documented in [RFC7201] and might be more 336 suitable. 338 6. IANA Considerations 340 New block types for RTCP XR are subject to IANA registration. For 341 general guidelines on IANA considerations for RTCP XR, refer to 342 [RFC3611]. 344 6.1. New RTCP XR Block Type Value 346 This document assigns the block type value 'TBD' in the IANA "RTP 347 Control Protocol Extended Reports (RTCP XR) Block Type Registry" to 348 the "Post-Repair Loss Count Metrics Report Block". 350 [[Editor Note: should replace 'TBD' with assigned value]] 352 6.2. New RTCP XR SDP Parameter 354 This document also registers a new parameter "effective-loss-index" 355 in the "RTP Control Protocol Extended Reports (RTCP XR) Session 356 Description Protocol (SDP) Parameters Registry". 358 6.3. Contact Information for Registrations 360 The contact information for the registrations is: 362 RAI Area Directors 364 7. Acknowledgements 366 This document has benefited greatly from the comments of various 367 people. The following individuals have contributed to this document: 368 Colin Perkins, Yanfang Zhang. 370 8. References 372 8.1. Normative References 374 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 375 Requirement Levels", BCP 14, RFC 2119, 376 DOI 10.17487/RFC2119, March 1997, . 379 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 380 Jacobson, "RTP: A Transport Protocol for Real-Time 381 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 382 July 2003, . 384 8.2. Informative References 386 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 387 "RTP Control Protocol Extended Reports (RTCP XR)", 388 RFC 3611, DOI 10.17487/RFC3611, November 2003, 389 . 391 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 392 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 393 RFC 3711, DOI 10.17487/RFC3711, March 2004, 394 . 396 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 397 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 398 DOI 10.17487/RFC4588, July 2006, . 401 [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error 402 Correction", RFC 5109, DOI 10.17487/RFC5109, December 403 2007, . 405 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 406 Real-time Transport Control Protocol (RTCP)-Based Feedback 407 (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February 408 2008, . 410 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 411 Specifications: ABNF", STD 68, RFC 5234, 412 DOI 10.17487/RFC5234, January 2008, . 415 [RFC5725] Begen, A., Hsu, D., and M. Lague, "Post-Repair Loss RLE 416 Report Block Type for RTP Control Protocol (RTCP) Extended 417 Reports (XRs)", RFC 5725, DOI 10.17487/RFC5725, February 418 2010, . 420 [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New 421 Performance Metric Development", BCP 170, RFC 6390, 422 DOI 10.17487/RFC6390, October 2011, . 425 [RFC6709] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design 426 Considerations for Protocol Extensions", RFC 6709, 427 DOI 10.17487/RFC6709, September 2012, . 430 [RFC6792] Wu, Q., Ed., Hunt, G., and P. Arden, "Guidelines for Use 431 of the RTP Monitoring Framework", RFC 6792, 432 DOI 10.17487/RFC6792, November 2012, . 435 [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP 436 Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, 437 . 439 [RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP 440 Framework: Why RTP Does Not Mandate a Single Media 441 Security Solution", RFC 7202, DOI 10.17487/RFC7202, April 442 2014, . 444 [RFC7509] Huang, R. and V. Singh, "RTP Control Protocol (RTCP) 445 Extended Report (XR) for Post-Repair Loss Count Metrics", 446 RFC 7509, DOI 10.17487/RFC7509, May 2015, 447 . 449 Appendix A. Metric Represented Using the Template from RFC 6390 451 A.1. Effective Loss Index 453 o Metric Name: RTP Effective Loss Index. 455 o Metric Description: The effectiveness of stream repair means 456 applied on a sequence of RTP packets. 458 o Method of Measurement or Calculation: See the "Effective Loss 459 Index" definition in Section 1.1. It is directly measured and 460 must be measured for the primary source RTP packets with no 461 further chance of repair. 463 o Units of Measurement: This metric is expressed as a 16-bit 464 unsigned integer value representing the effectiveness of stream 465 repair means. 467 o Measurement Point(s) with Potential Measurement Domain: It is 468 measured at the receiving end of the RTP stream. 470 o Measurement Timing: This metric relies on the sequence number 471 interval to determine measurement timing. 473 o Use and Applications: These metrics are applicable to any RTP 474 applications, especially those that use loss-repair mechanisms. 475 See Section 1 for details. 477 o Reporting Model: See RFC 3611. 479 Authors' Addresses 481 Hui Zheng (Marvin) 482 Individual 484 Email: zh4ui@huawei.comoutlook.com 486 Roni Even 487 Huawei 489 Email: roni.even@huawei.com 490 Qin Wu 491 Huawei 493 Email: bill.wu@huawei.com 495 Rong Gu 496 China Mobile 498 Email: gurong_cmcc@outlook.com 500 Rachel Huang 501 Huawei 503 Email: rachel.huang@huawei.com