idnits 2.17.00 (12 Aug 2021) /tmp/idnits37932/draft-zheng-xrblock-effective-loss-index-02.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 2, 2018) is 1534 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) 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: Standard Track Q. Wu 5 Expires: September 3, 2018 Huawei 6 R. Gu 7 China Mobile 8 R. Huang 9 Huawei 10 March 2, 2018 12 RTP Control Protocol (RTCP) Extended Report (XR) Block for Effective 13 Loss Index Reporting 14 draft-zheng-xrblock-effective-loss-index-02 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 . . . . . . . . . . . . . . . . . . . . . . 5 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 by calculating the 93 probability of the post-repair losses. The new metric provides a 94 simpler view on the post-repair loss than the mechanisms documented 95 in [RFC5725] and [RFC7509]. ELI is an index, so the values reported 96 from the monitors deployed in the different places in the network can 97 be compared directly, which makes it easier to diagnose the network 98 problem when delivering the RTP streams. A use case is to compare the 99 ELI value reported by a monitor in the network with a certain 100 reasonable threshold to see if there are any problems in the IPTV 101 services. For those endpoints, more informative XR reports such as 102 those in [RFC5725] and [RFC7509] can then be used to discover more 103 details about the loss situations. 105 This document also defines in section 3, an XR block to report the 106 metric. 108 1.1. Effective Loss Index 110 Effective Loss Index (ELI) uses a simple model to measure the loss 111 impact after applying loss repairsof loss repair. It is useful 112 especially in the middleboxes which usually are passive observer and 113 do not have the ability to recover the loss data. 115 The model assumes that repair means are applied onto packets by 116 batches of equal size. Lower ELI means that loss impact is minimal. 117 Specifically, a batch is identified by a range of RTP sequence 118 numbers. The size of a batch is number of packets. An application 119 can agree upon a default batch size, or use the SDP signaling defined 120 in Section 4.1 to communicate one if the middlebox can see the SDP, 121 or just configure it. 123 An RTP endpoint is assumed to process received packets and apply 124 repair means batch by batch. For each batch, if there is still some 125 unrecoverable loss after having applied the repair means, then the 126 repair means are deemed as ineffective. The ineffectiveness is 127 denoted by Effective Loss Factor (ELF), along with a parameter Loss 128 Repair Threshold, showing below: 130 if Loss Packets Number > Loss Repair Threshold 131 Effective Loss Factor = 1 132 else 133 Effective Loss Factor = 0 134 endif 136 Figure 1: Calculation of Effective Loss Factor 138 The parameters in Figure 1 are explained below: 140 o Loss Packets Number is the number of packet lost in the batch. 142 o Loss Repair Threshold indicates the maximum loss packets number 143 that can be recovered. 145 The minimum value of Loss Repair Threshold is zero, which means there 146 is no loss repair. This document does not mandate any value for Loss 147 Repair Threshold. Applications can prescribe a value for themselves 148 without signaling. For example, it can be calculated by the batch 149 size multiplied by the fixed redundancy ratio of the FEC algorithm; 150 And when used in the retransmission case, it can be set to the 151 maximum number of lost packets to be retransmitted in a batch. On the 152 other hand, SDP signaling defined in Section 4.1 can be used to 153 communicate the value. 155 Effective Loss Index is an integer derived by calculating the average 156 Effective Loss Factor across a sequence of consecutive batches of RTP 157 packets. Let ELF(i) be the Effective Loss Factor calculated for i-th 158 batch, and N as number of batches in the sequence, then Effective 159 Loss Index is calculated as: 161 ELF(1)+ELF(2)+ ...+ELF(N) 162 Effective Loss Index = ------------------------- 163 N 165 Figure 2: Calculation of Effective Loss Index 167 The following is an example of how to calculate Effective Loss Index. 168 For simplicity and demonstration purpose, the size of a batch is 169 assumed to be 3, and the Loss Repair Threshold is assumed to be 1. 170 The example processes a sequence of 9 RTP packets (x means lost) in 7 171 batches. 173 1xx4x6x89 175 Batch Loss Effective Loss Factor 176 | 1 2 3 | 2, 3 1 177 | 2 3 4 | 2, 3 1 178 | 3 4 5 | 3 0 179 | 4 5 6 | 5 0 180 | 5 6 7 | 5, 7 1 181 | 6 7 8 | 7 0 182 | 7 8 9 | 7 0 184 1+1+0+0+1+0+0 185 Effective Loss Index = --------------- = 0.4285 186 7 188 This example provides fine grained estimation for loss recovery. It 189 can detect the loss burst happening over batches. Implementations can 190 also do coarse grained estimation by simply dividing total packets 191 into several batches. 193 1.2. Applicability 195 The metric defined by this document is applicable to a range of RTP 196 applications that send packets with stream repair means (e.g., 197 Forward Error Correction (FEC) [RFC5109] and/or retransmission 198 [RFC4588]) applied on them. Note that this metric is only valuable 199 for FECs where he redundant data are sent in a different RTP stream 200 from the original media stream. 202 This document does not mandate any value for the batch size. 203 Applications can prescribe a value for themselves without signaling. 204 For example, the batch size can be set to the number of packets 205 containing source symbols in a source block in the case of FEC, and 206 can be prescribed arbitrarily, e.g. 100, in the case of 207 retransmission. 209 The number of batches among which ELI is calculated should not be too 210 few, otherwise the result may be biased. It is suggested to calculate 211 it based on the total number of RTP packets during the measurement 212 interval, as in the section 1.1 example: 214 The number of batches = (The total number of RTP packets - the size 215 of a batch) + 1. 217 1.3. RTCP and RTCP XR Reports 219 The use of RTCP for reporting is defined in [RFC3550]. [RFC3611] 220 defines an extensible structure for reporting by using an RTCP 221 Extended Report (XR). This document defines a new Extended Report 222 block for use with [RFC3550] and [RFC3611]. 224 1.4. Performance Metrics Framework 226 The Performance Metrics Framework [RFC6390] provides guidance on the 227 definition and specification of performance metrics. The "Guidelines 228 for Use of the RTP Monitoring Framework" [RFC6792] provides 229 guidelines for reporting block format using RTCP XR. The Metrics 230 Block described in this document is in accordance with the guidelines 231 in [RFC6390] and [RFC6792]. 233 2. Terminology 235 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 236 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 237 document are to be interpreted as described in RFC 2119 [RFC2119]. 239 3. Effective Loss Index Report Block 240 The Effective Loss Index Report Block has the following format: 242 0 1 2 3 4 243 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 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | BT=TBD | Reserved | Block length = 3 | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | SSRC of Source | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | Effective Loss Index | Padding | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 Block Type (BT): 8 bits: An Effect Loss Index Report Block is 253 identified by the constant 'TBD'. 255 [[Editor Note: should replace 'TBD' with assigned value]] 257 Reserved: 8 bits: These bits are reserved for future use. They MUST 258 be set to zero by senders and ignored by receivers (see 259 Section 4.2 of [RFC6709]). 261 Block length: 16 bits: This field is in accordance with the 262 definition in [RFC3611]. In this report block, it MUST be set to 264 3. The block MUST be discarded if the block length is set to a 265 different value. 267 SSRC of source: 32 bits: The SSRC of the RTP data packet source 268 being reported upon by this report block, as defined in Section 269 4.1 of [RFC3611]. 271 Effective Loss Index: 16 bits: The value of Effective Loss Index, 272 equivalent to taking the integer part after multiplying the the 273 calculated result of Effective Loss Index (as in Figure 2) by 274 65535. 276 Padding: 16 bits: These bits MUST be set to zero by senders and 277 ignored by receivers. 279 4. SDP Signaling 281 [RFC3611] defines the use of SDP (Session Description Protocol) for 282 signaling the use of RTCP XR blocks. However, XR blocks MAY be used 283 without prior signaling (see Section 5 of [RFC3611]). 285 4.1. SDP rtcp-xr-attrib Attribute Extension 286 This session augments the SDP attribute "rtcp-xr" defined in 287 Section 5.1 of [RFC3611] by providing an additional value of "xr- 288 format" to signal the use of the report block defined in this 289 document. The ABNF [RFC5234] syntax is as follows. 291 xr-format =/ xr-eli-block 293 xr-eli-block = "effective-loss-index" 294 [ ":" effective-loss-batch-size] 295 [ ">" effective-loss-threshold] 297 effective-loss-batch-size = 1*DIGIT 298 ; the batch size is in number of packets 300 effective-loss-threshold = 1*DIGIT 301 ; the threshold is in number of packets 303 DIGIT = %x30-39 305 The SDP attribute "xr-eli-block" is designed to contain two optional 306 values, one for signaling the batch size, another for the Effective 307 Loss Threshold. Here are some examples: 309 1. signaling both batch size (100) and Effective Loss Threshold (2) 311 xr-eli-block = "effective-loss-index" : "100" > "2" 313 2. signaling only batch size (100) 315 xr-eli-block = "effective-loss-index" : "100" 317 3. signaling only Effective Loss Threshold (2) 319 xr-eli-block = "effective-loss-index" > "2" 321 4.2. Offer/Answer Usage 323 When SDP is used in offer/answer context, the SDP Offer/Answer usage 324 defined in [RFC3611] for the unilateral "rtcp-xr" attribute 325 parameters applies. For detailed usage of Offer/Answer for 326 unilateral parameters, refer to Section 5.2 of [RFC3611]. 328 5. Security Considerations 330 This proposed RTCP XR block introduces no new security considerations 331 beyond those described in [RFC3611] This block does not provide per- 332 packet statistics, so the risk to confidentiality documented in 333 Section 7, paragraph 3 of [RFC3611] does not apply. 335 An attacker may put incorrect information in the Effective Loss Index 336 reports. Implementers should consider the guidance in [RFC7202] for 337 using appropriate security mechanisms, i.e., where security is a 338 concern, the implementation should apply encryption and 339 authentication to the report block. For example, this can be 340 achieved by using the AVPF profile together with the Secure RTP 341 profile as defined in [RFC3711] an appropriate combination of the two 342 profiles (an "SAVPF") is specified in [RFC5124] However, other 343 mechanisms also exist (documented in [RFC7201] and might be more 344 suitable. 346 6. IANA Considerations 348 New block types for RTCP XR are subject to IANA registration. For 349 general guidelines on IANA considerations for RTCP XR, refer to 350 [RFC3611]. 352 6.1. New RTCP XR Block Type Value 354 This document assigns the block type value 'TBD' in the IANA "RTP 355 Control Protocol Extended Reports (RTCP XR) Block Type Registry" to 356 the "Post-Repair Loss Count Metrics Report Block". 358 [[Editor Note: should replace 'TBD' with assigned value]] 360 6.2. New RTCP XR SDP Parameter 362 This document also registers a new parameter "effective-loss-index" 363 in the "RTP Control Protocol Extended Reports (RTCP XR) Session 364 Description Protocol (SDP) Parameters Registry". 366 6.3. Contact Information for Registrations 368 The contact information for the registrations is: 370 RAI Area Directors 372 7. Acknowledgements 374 This document has benefited greatly from the comments of various 375 people. The following individuals have contributed to this document: 376 Colin Perkins, Yanfang Zhang. 378 8. References 380 8.1. Normative References 382 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 383 Requirement Levels", BCP 14, RFC 2119, 384 DOI 10.17487/RFC2119, March 1997, . 387 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 388 Jacobson, "RTP: A Transport Protocol for Real-Time 389 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 390 July 2003, . 392 8.2. Informative References 394 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 395 "RTP Control Protocol Extended Reports (RTCP XR)", 396 RFC 3611, DOI 10.17487/RFC3611, November 2003, 397 . 399 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 400 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 401 RFC 3711, DOI 10.17487/RFC3711, March 2004, 402 . 404 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 405 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 406 DOI 10.17487/RFC4588, July 2006, . 409 [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error 410 Correction", RFC 5109, DOI 10.17487/RFC5109, December 411 2007, . 413 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 414 Real-time Transport Control Protocol (RTCP)-Based Feedback 415 (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February 416 2008, . 418 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 419 Specifications: ABNF", STD 68, RFC 5234, 420 DOI 10.17487/RFC5234, January 2008, . 423 [RFC5725] Begen, A., Hsu, D., and M. Lague, "Post-Repair Loss RLE 424 Report Block Type for RTP Control Protocol (RTCP) Extended 425 Reports (XRs)", RFC 5725, DOI 10.17487/RFC5725, February 426 2010, . 428 [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New 429 Performance Metric Development", BCP 170, RFC 6390, 430 DOI 10.17487/RFC6390, October 2011, . 433 [RFC6709] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design 434 Considerations for Protocol Extensions", RFC 6709, 435 DOI 10.17487/RFC6709, September 2012, . 438 [RFC6792] Wu, Q., Ed., Hunt, G., and P. Arden, "Guidelines for Use 439 of the RTP Monitoring Framework", RFC 6792, 440 DOI 10.17487/RFC6792, November 2012, . 443 [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP 444 Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, 445 . 447 [RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP 448 Framework: Why RTP Does Not Mandate a Single Media 449 Security Solution", RFC 7202, DOI 10.17487/RFC7202, April 450 2014, . 452 [RFC7509] Huang, R. and V. Singh, "RTP Control Protocol (RTCP) 453 Extended Report (XR) for Post-Repair Loss Count Metrics", 454 RFC 7509, DOI 10.17487/RFC7509, May 2015, 455 . 457 Appendix A. Metric Represented Using the Template from RFC 6390 459 A.1. Effective Loss Index 461 o Metric Name: RTP Effective Loss Index. 463 o Metric Description: The effectiveness of stream repair means 464 applied on a sequence of RTP packets. 466 o Method of Measurement or Calculation: See the "Effective Loss 467 Index" definition in Section 1.1. It is directly measured and 468 must be measured for the primary source RTP packets with no 469 further chance of repair. 471 o Units of Measurement: This metric is expressed as a 16-bit 472 unsigned integer value representing the effectiveness of stream 473 repair means. 475 o Measurement Point(s) with Potential Measurement Domain: It is 476 measured at the receiving end of the RTP stream. 478 o Measurement Timing: This metric relies on the sequence number 479 interval to determine measurement timing. 481 o Use and Applications: These metrics are applicable to any RTP 482 applications, especially those that use loss-repair mechanisms. 483 See Section 1 for details. 485 o Reporting Model: See RFC 3611. 487 Authors' Addresses 489 Hui Zheng (Marvin) 490 Individual 492 Email: zh4ui@huawei.comoutlook.com 494 Roni Even 495 Huawei 497 Email: roni.even@huawei.com 498 Qin Wu 499 Huawei 501 Email: bill.wu@huawei.com 503 Rong Gu 504 China Mobile 506 Email: gurong_cmcc@outlook.com 508 Rachel Huang 509 Huawei 511 Email: rachel.huang@huawei.com