idnits 2.17.1 draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-09.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 == Line 251 has weird spacing: '...ctively will ...' -- The document date (January 21, 2015) is 3376 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 (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT R. Huang 3 Intended Status: Standards Track Huawei 4 Expires: July 25, 2015 V. Singh 5 Aalto University 6 January 21, 2015 8 RTP Control Protocol (RTCP) Extended Report (XR) for Post-Repair 9 Loss Count Metrics 10 draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-09 12 Abstract 14 This document defines an RTP Control Protocol (RTCP) Extended Report 15 (XR) Block that allows reporting of post-repair loss count metric for 16 a range of RTP applications. In addition, another metric, repaired 17 loss count, is also introduced in this report block for calculating 18 the pre-repair loss count during this rage. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that 27 other groups may also distribute working documents as 28 Internet-Drafts. 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 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/1id-abstracts.html 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html 41 Copyright and License Notice 43 Copyright (c) 2015 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3 Post-Repair Loss Count Metrics Report Block . . . . . . . . . . 4 61 3.1 Report Block Structure . . . . . . . . . . . . . . . . . . 5 62 3.2 Report Block Example Usage . . . . . . . . . . . . . . . . 6 63 4 SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 4.1 SDP rtcp-xr-attrib Attribute Extension . . . . . . . . . . 7 65 4.2 Offer/Answer Usage . . . . . . . . . . . . . . . . . . . . 7 66 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 7 67 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 68 6.1 New RTCP XR Block Type value . . . . . . . . . . . . . . . 7 69 6.2 New RTCP XR SDP Parameter . . . . . . . . . . . . . . . . . 8 70 6.3 Contact Information for registrations . . . . . . . . . . . 8 71 7 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 72 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 8.1 Normative References . . . . . . . . . . . . . . . . . . . 8 74 8.2 Informative References . . . . . . . . . . . . . . . . . . 9 75 Appendix A. Metrics Represented Using the Template from RFC 6390 . 9 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 78 1 Introduction 80 RTCP Sender Reports (SR)/Receiver Reports (RR) [RFC3550] contain some 81 rough statistics about the data received from the particular source 82 indicated in that block. One of them is the cumulative number of 83 packets lost, which is called pre-repair loss metric in this 84 document. This metric conveys information regarding the total number 85 of RTP data packets that have been lost since the beginning of the 86 RTP session. 88 However, this metric is measured on media stream before any loss 89 repair mechanism, e.g., retransmission [RFC4588] or Forward Error 90 Correction (FEC) [RFC5109], is applied. Using a repair mechanism 91 usually results in recovering some or all of the lost packets. Hence, 92 the sending endpoint cannot assess the performance of the repair 93 mechanism by observing the change in fraction loss and the cumulative 94 loss statistics from RTCP SR/RR [RFC3550]. 96 Consequently, [RFC5725] specifies a post-repair loss Run-length 97 Encoding (RLE) XR report block to address this issue. The sending 98 endpoint is able to infer which packets were repaired from the RLE 99 report block, but the reporting overhead for the packet-by-packet 100 report block is higher compared to other report blocks. 102 When applications use multiple XR blocks, the endpoints may require 103 more concise reporting to save bandwidth. This document defines a new 104 XR block type to augment those defined in [RFC3611] and complement 105 the report block defined in [RFC5725] for use in a range of RTP 106 applications. This new block type reports the post-repair loss count 107 metric which records the number of primary source RTP packets that 108 are still lost after applying one or more loss repair mechanisms. In 109 addition, another metric, repaired loss count, is also introduced in 110 this report block for calculating the pre-repair loss count during 111 this range, so that the RTP sender or a third-party entity is able to 112 evaluate the effectiveness of the repair methods used by the system. 113 The metrics defined in this document are packet level rather than 114 slice/picture level, which means the partial recovery of a packet 115 will not be regarded as a repaired packet. 117 The metrics defined in this document belong to the class of 118 transport-related metrics defined in [RFC6792] and are specified in 119 accordance with the guidelines in [RFC6390] and [RFC6792]. These 120 metrics are applicable to any RTP application, especially those that 121 use loss repair mechanisms. 123 2 Terminology 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in [KEYWORDS]. 129 primary source RTP packet: The original RTP packet sent from the RTP 130 sender for the first time. A lost primary source RTP packet may be 131 repaired by some other RTP packets used in repair mechanisms like FEC 132 or retransmission. 134 3 Post-Repair Loss Count Metrics Report Block 136 This block reports the number of packets lost after applying repair 137 mechanisms to complement the RTCP XR metrics defined in [RFC5725]. 138 The sender of this XR report can ensure it match the SR/RR packet 139 sent in the same compound RTCP packet. When comparing this metric 140 with pre-repair loss metric of RTCP SR/RR, ambiguity may occur as 141 noted in [RFC5725]: Some packets will not be repaired in the current 142 RTCP interval, but could be repaired later. 144 Accordingly, only packets that have no further chance of being 145 repaired are included in this report block. This block needs to 146 specify its own measurement period to avoid ambiguity in calculating 147 the post-repair loss count. 149 The sequence number range reported by RTCP SR/RR may contain some 150 sequence numbers of packets for which repair might still be possible. 151 To avoid the ambiguity, we use begin sequence number and end sequence 152 number to explicitly indicate the actual sequence number range that 153 this RTCP XR report block reports on as the measurement timing. These 154 metrics defined in this report block are all measured at the RTP 155 receiver. The relationship between the metrics in this report block 156 and the pre-repair loss metric of RTCP RR could be expressed in the 157 following formula: 159 still to be repaired lost packet = cumulative number of packets 160 lost - cumulative post-repair loss count - cumulative repaired 161 loss count 163 "cumulative number of packets lost" is the metric from RTCP SR/RR. 164 "cumulative post-repair loss count" and "cumulative repaired loss 165 count" could be obtained by the way introduced in the end of this 166 section. 168 It is also possible to send this XR report block and SR/RR with 169 different intervals, in which case the "cumulative number of packets 170 lost" can't be easily compared with the post-repair metrics defined 171 in this draft. However, the endpoint could rely on the post-repair 172 loss count and repaired loss count to calculate the efficiency of the 173 error resilience algorithm. 175 3.1 Report Block Structure 177 The post-repair loss count metrics report block has the following 178 format: 180 0 1 2 3 4 181 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 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | BT=PRLR | Reserved | block length = 4 | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | SSRC of Source | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | begin_seq | end_seq | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | post-repair loss count | repaired loss count | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 Block Type (BT): 8 bits 194 A Post-Repair Loss Count Metrics Report Block is identified by the 195 constant PRLR. 197 [Note to RFC Editor: Please replace PRLR with the IANA provided 198 RTCP XR block type for this block.] 200 Reserved: 8 bits 202 These bits are reserved for future use. They MUST be set to zero 203 by senders and ignored by receivers (see [RFC6709], Section 4.2). 205 block length: 16 bits 207 This field is in accordance with the definition in [RFC3611]. In 208 this report block, it MUST be set to 4. The block MUST be 209 discarded if the block length is set to a different value. 211 SSRC of source: 32 bits 213 As defined in Section 4.1 of [RFC3611]. 215 begin_seq: 16 bits 217 The first sequence number that this block reports on. It can 218 remain fixed when calculating metrics over several RTCP reporting 219 intervals. 221 end_seq: 16 bits 223 The last sequence number that this block reports on plus one. 225 post-repair loss count: 16 bits 227 Total number of packets finally lost after applying one or more 228 loss-repair methods, e.g., FEC and/or retransmission, during the 229 actual sequence number range indicated by begin_seq and end_seq. 230 This metric MUST NOT count the lost packets for which repair might 231 still be possible. Note that this metric MUST measure only primary 232 source RTP packets. 234 repaired loss count: 16 bits 236 Total number of packets fully repaired after applying one or more 237 loss-repair methods, e.g., FEC and/or retransmission, during the 238 actual sequence number range indicated by begin_seq and end_seq. 239 Note that this metric MUST measure only primary source RTP 240 packets. 242 3.2 Report Block Example Usage 244 This block could be reported by the endpoint in 2 different ways: 246 1. Cumulative report 248 In this case, implementations may set begin_seq to the first packet 249 in the RTP session and it will remain fixed across all reports. In 250 this case the "post-repair loss count" and "repaired loss count" 251 respectively will correspond to "cumulative post-repair loss count" 252 and "cumulative repaired loss count" in this case. 254 2. Interval report 256 Some implementations may align the begin_seq and end_seq number with 257 the last RTCP interval. If the reports are consecutive and there is 258 no sequence number range overlap or RTCP XR packets loss, "cumulative 259 post-repair loss count" and "cumulative repaired loss count" can be 260 respectively calculated by sum of "post-repair loss count" and by sum 261 of "repaired loss count". 263 Alternatively, for providing better robustness against packet loss, 264 implementations may choose begin_seq and end_seq numbers covering 265 several RTCP intervals. 267 4 SDP Signaling 269 [RFC3611] defines the use of SDP (Session Description Protocol) for 270 signaling the use of RTCP XR blocks. However XR blocks MAY be used 271 without prior signaling (see section 5 of [RFC3611]). 273 4.1 SDP rtcp-xr-attrib Attribute Extension 275 This session augments the SDP attribute "rtcp-xr" defined in Section 276 5.1 of [RFC3611] by providing an additional value of "xr-format" to 277 signal the use of the report block defined in this document. 279 xr-format =/ xr-prlr-block 281 xr-prlr-block = "post-repair-loss-count" 283 4.2 Offer/Answer Usage 285 When SDP is used in offer-answer context, the SDP Offer/Answer usage 286 defined in [RFC3611] for unilateral "rtcp-xr" attribute parameters 287 applies. For detailed usage of Offer/Answer for unilateral 288 parameters, refer to section 5.2 of [RFC3611]. 290 5 Security Considerations 292 This proposed RTCP XR block introduces no new security considerations 293 beyond those described in [RFC3611]. This block does not provide per- 294 packet statistics, so the risk to confidentiality documented in 295 Section 7, paragraph 3 of [RFC3611] does not apply. 297 An attacker may put incorrect information in the Post-Repair Loss 298 Count reports, which will be affect the performance of loss repair 299 mechanisms. Implementers should consider the guidance in [RFC7202] 300 for using appropriate security mechanisms, i.e., where security is a 301 concern, the implementation should apply encryption and 302 authentication to the report block. For example, this can be achieved 303 by using the AVPF profile together with the Secure RTP profile as 304 defined in [RFC3711]; an appropriate combination of the two profiles 305 (an "SAVPF") is specified in [RFC5124]. However, other mechanisms 306 also exist (documented in [RFC7201]) and might be more suitable. 308 6 IANA Considerations 310 New block types for RTCP XR are subject to IANA registration. For 311 general guidelines on IANA considerations for RTCP XR, refer to 312 [RFC3611]. 314 6.1 New RTCP XR Block Type value 316 This document assigns the block type value PRLR in the IANA "RTP 317 Control Protocol Extended Reports (RTCP XR) Block Type Registry" to 318 the "Post-Repair Loss Count Metrics Report Block". 320 [Note to RFC Editor: please replace PRLR with the IANA provided RTCP 321 XR block type for this block.] 323 6.2 New RTCP XR SDP Parameter 325 This document also registers a new parameter "post-repair-loss-count" 326 in the "RTP Control Protocol Extended Reports (RTCP XR) Session 327 Description Protocol (SDP) Parameters Registry". 329 6.3 Contact Information for registrations 331 The contact information for the registration is : 333 RAI Area Directors 335 7 Acknowledgments 337 The author would like to thank Roni Even, Colin Perkins, and Qin Wu 338 for giving valuable comments and suggestions. 340 8 References 342 8.1 Normative References 344 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 345 Requirement Levels", BCP 14, RFC 2119, March 1997. 347 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 348 Jacobson, "RTP: A Transport Protocol for Real-Time 349 Applications", STD 64, RFC 3550, July 2003. 351 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 352 "RTP Control Protocol Extended Reports (RTCP XR)", 353 RFC 3611, November 2003. 355 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 356 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 357 RFC 3711, March 2004. 359 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 360 Real-time Transport Control Protocol (RTCP)-Based Feedback 361 (RTP/SAVPF)", RFC 5124, February 2008. 363 [RFC5725] Begen, A., Hsu, D., and M. Lague, "Post-Repair Loss RLE 364 Report Block Type for RTP Control Protocol (RTCP) Extended 365 Reports (XRs)", RFC 5725, February 2010. 367 8.2 Informative References 369 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 370 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 371 July 2006. 373 [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error 374 Correction", RFC 5109, December 2007. 376 [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New 377 Performance Metric Development", BCP 170, RFC 6390, 378 October 2011. 380 [RFC6709] Carpenter, B., Aboba, B., and S. Cheshire, "Design 381 Considerations for Protocol Extensions", RFC6709, 382 September 2012. 384 [RFC6792] Wu, Q., Hunt, G., and P. Arden, "Guidelines for Use of the 385 RTP Monitoring Framework", RFC 6792, November 2012. 387 [RFC7201] Westerlund, M. and C., Perkins, "Qptions for Securing RTP 388 Sessions", RFC 7201, April 2014. 390 [RFC7202] Perkins, C. and M., Westerlund, "Securing the RTP 391 Framework: Why RTP Does Not Mandate a Single Media 392 Security Solution", RFC 7202, April 2014. 394 Appendix A. Metrics Represented Using the Template from RFC 6390 396 a. Post-Repair RTP Packet Loss Count Metric 398 * Metric Name: Post-Repair RTP Packet Loss Count Metric. 400 * Metric Description: Total number of RTP packets still lost after 401 loss repair methods are applied 403 * Method of Measurement or Calculation: See section 3.1, Post- 404 Repair RTP Packet Loss Count Metric definition. It is directly 405 measured and must be measured for the primary source RTP packets 406 with no further chance of repair. 408 * Units of Measurement: This metric is expressed as a 16-bit 409 unsigned integer value giving the number of RTP packets. 411 * Measurement Point(s) with Potential Measurement Domain: It is 412 measured at the receiving end of the RTP stream. 414 * Measurement Timing: This metric relies on the sequence number 415 interval to determine measurement timing. See Section 3, 3rd 416 paragraph, for details. 418 * Use and Applications: These metrics are applicable to any RTP 419 application, especially those that use loss repair mechanisms. See 420 Section 1 for details. 422 * Reporting Model: See RFC3611. 424 b. Repaired RTP Packet Loss Count Metric 426 * Metric Name: Repaired RTP Packet Count Metric. 428 * Metric Description: The number of RTP packets lost but repaired 429 after applying loss repair methods 431 * Method of Measurement or Calculation: See section 3.1, Repaired 432 RTP Packet Loss Count Metric definition. It is directly measured 433 and must be measured for the primary source RTP packets with no 434 further chance of repair. 436 * Units of Measurement: This metric is expressed as a 16-bit 437 unsigned integer value giving the number of RTP packets. 439 * Measurement Point(s) with Potential Measurement Domain: It is 440 measured at the receiving end of the RTP stream. 442 * Measurement Timing: This metric relies on the sequence number 443 interval to determine measurement timing. See Section 3, 3rd 444 paragraph, for details. 446 * Use and Applications: These metrics are applicable to any RTP 447 application, especially those that use loss repair mechanisms. See 448 Section 1 for details. 450 * Reporting Model: See RFC3611. 452 Authors' Addresses 454 Rachel Huang 455 Huawei 456 101 Software Avenue, Yuhua District 457 Nanjing 210012 458 China 460 EMail: rachel.huang@huawei.com 462 Varun Singh 463 Aalto University 464 School of Electrical Engineering 465 Otakaari 5 A 466 Espoo, FIN 02150 467 Finland 469 Email: varun@comnet.tkk.fi 470 URI: http://www.netlab.tkk.fi/~varun/