idnits 2.17.1 draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-08.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 4, 2015) is 3399 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 INTERNET-DRAFT R. Huang 3 Intended Status: Standards Track Huawei 4 Expires: July 8, 2015 V. Singh 5 Aalto University 6 January 4, 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-08 12 Abstract 14 This document defines an RTP Control Protocol (RTCP) Extended Report 15 (XR) Block that allows reporting of post-repair loss count metrics 16 for a range of RTP applications. 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as 26 Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/1id-abstracts.html 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 Copyright and License Notice 41 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3 Post-Repair Loss Count Metrics Report Block . . . . . . . . . . 4 59 4 SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 4.1 SDP rtcp-xr-attrib Attribute Extension . . . . . . . . . . 6 61 4.2 Offer/Answer Usage . . . . . . . . . . . . . . . . . . . . 6 62 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 6 63 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 64 6.1 New RTCP XR Block Type value . . . . . . . . . . . . . . . 7 65 6.2 New RTCP XR SDP Parameter . . . . . . . . . . . . . . . . . 7 66 6.3 Contact Information for registrations . . . . . . . . . . . 7 67 7 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 68 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 8.1 Normative References . . . . . . . . . . . . . . . . . . . 7 70 8.2 Informative References . . . . . . . . . . . . . . . . . . 8 71 Appendix A. Metrics Represented Using the Template from RFC 6390 . 8 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 74 1 Introduction 76 RTCP Sender Reports (SR)/Receiver Reports (RR) [RFC3550] contain some 77 rough statistics about the data received from the particular source 78 indicated in that block. One of them is the cumulative number of 79 packets lost, which is called pre-repair loss metric in this 80 document. This metric conveys information regarding the total number 81 of RTP data packets that have been lost since the beginning of the 82 RTP session. 84 However, this metric is measured on media stream before any loss 85 repair mechanism, e.g., retransmission [RFC4588] or Forward Error 86 Correction (FEC) [RFC5109], is applied. Using a repair mechanism 87 usually results in recovering some or all of the lost packets. Hence, 88 the sending endpoint cannot assess the performance of the repair 89 mechanism by observing the change in fraction loss and the cumulative 90 loss statistics from RTCP SR/RR [RFC3550]. 92 Consequently, [RFC5725] specifies a post-repair loss Run-length 93 Encoding (RLE) XR report block to address this issue. The sending 94 endpoint is able to infer which packets were repaired from the RLE 95 report block, but the reporting overhead for the packet-by-packet 96 report block is higher compared to other report blocks. 98 When applications use multiple XR blocks, the endpoints may require 99 more concise reporting to save bandwidth. This document defines a new 100 XR block type to augment those defined in [RFC3611] and complement 101 the report block defined in [RFC5725] for use in a range of RTP 102 applications. This new block type reports the post-repair loss count 103 metric which records the number of primary source RTP packets that 104 are still lost after applying one or more loss repair mechanisms. In 105 addition, another metric, repaired loss count, is also introduced in 106 this report block for calculating the pre-repair loss count during 107 the this range, so that the RTP sender or a third-party entity is 108 able to evaluate the effectiveness of the repair methods used by the 109 system. The metrics defined in this document are packet level rather 110 than slice/picture level, which means the partial recovery of a 111 packet will not be regarded as a repaired packet. 113 The metrics defined in this document belong to the class of 114 transport-related metrics defined in [RFC6792] and are specified in 115 accordance with the guidelines in [RFC6390] and [RFC6792]. These 116 metrics are applicable to any RTP application, especially those that 117 use loss repair mechanisms. 119 2 Terminology 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in [KEYWORDS]. 125 primary source RTP packet: The original RTP packet sent from the RTP 126 sender for the first time. A lost primary source RTP packet may be 127 repaired by some other RTP packets used in repair mechanisms like FEC 128 or retransmission. 130 3 Post-Repair Loss Count Metrics Report Block 132 This block reports the number of packets lost after applying repair 133 mechanisms to complement the RTCP XR metrics defined in [RFC5725]. 134 This packet may be stacked with other RTCP packets to form compound 135 RTCP packets and share the average reporting interval calculated by 136 the RTCP method described in [RFC3550]. When comparing this metric 137 with pre-repair loss metric of RTCP SR/RR, ambiguity may occur as 138 noted in [RFC5725]: Some packets will not be repaired in the current 139 RTCP interval, but could be repaired later. 141 Thus it is RECOMMENDED that this report block should be generated 142 only for those source packets that have no further chance of being 143 repaired and not for any other packets. This block needs to specify 144 its own measurement period to avoid ambiguity in calculating the 145 post-repair loss count. 147 The sequence number range reported by RTCP SR/RR may contain some 148 sequence numbers of packets for which repair might still be possible. 149 To avoid the ambiguity, we use begin sequence number and end sequence 150 number to explicitly indicate the actual sequence number range that 151 this RTCP XR report block reports on as the measurement timing. These 152 metrics defined in this report block are all interval metrics and the 153 measurement of them is made at the RTP receiver. The relationship 154 between the metrics in this report block and the pre-repair loss 155 metric of RTCP XR could be expressed in the following formula: 157 cumulative number of packets lost = post-repair loss count + 158 repaired loss count + to be repaired lost packet 160 "cumulative number of packets lost" is the metric from RTCP SR/RR. 161 "post-repair loss count" and "repaired loss count" are the metrics 162 defined in this draft. 164 The post-repair loss count metrics report block has the following 165 format: 167 0 1 2 3 4 168 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 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | BT=PRLR | Reserved | block length = 4 | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | SSRC of Source | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | begin_seq | end_seq | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | post-repair loss count | repaired loss count | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 Block Type (BT): 8 bits 181 A Post-Repair Loss Count Metrics Report Block is identified by the 182 constant PRLR. 184 [Note to RFC Editor: Please replace PRLR with the IANA provided 185 RTCP XR block type for this block.] 187 Reserved: 8 bits 189 These bits are reserved for future use. They MUST be set to zero 190 by senders and ignored by receivers (see [RFC6709], Section 4.2). 192 block length: 16 bits 194 This field is in accordance with the definition in [RFC3611]. In 195 this report block, it MUST be set to 4. The block MUST be 196 discarded if the block length is set to a different value. 198 SSRC of source: 32 bits 200 As defined in Section 4.1 of [RFC3611]. 202 begin_seq: 16 bits 204 The first sequence number that this block reports on. 206 end_seq: 16 bits 208 The last sequence number that this block reports on plus one. 210 post-repair loss count: 16 bits 212 Total number of packets finally lost after applying one or more 213 loss-repair methods, e.g., FEC and/or retransmission, during the 214 actual sequence number range indicated by begin_seq and end_seq. 215 This metric MUST NOT count the lost packets for which repair might 216 still be possible. Note that this metric MUST measure only primary 217 source RTP packets. 219 repaired loss count: 16 bits 221 Total number of packets fully repaired after applying one or more 222 loss-repair methods, e.g., FEC and/or retransmission, during the 223 actual sequence number range indicated by begin_seq and end_seq. 224 Note that this metric MUST measure only primary source RTP 225 packets. 227 4 SDP Signaling 229 [RFC3611] defines the use of SDP (Session Description Protocol) for 230 signaling the use of RTCP XR blocks. However XR blocks MAY be used 231 without prior signaling (see section 5 of [RFC3611]). 233 4.1 SDP rtcp-xr-attrib Attribute Extension 235 This session augments the SDP attribute "rtcp-xr" defined in Section 236 5.1 of [RFC3611] by providing an additional value of "xr-format" to 237 signal the use of the report block defined in this document. 239 xr-format =/ xr-prlr-block 241 xr-prlr-block = "post-repair-loss-count" 243 4.2 Offer/Answer Usage 245 When SDP is used in offer-answer context, the SDP Offer/Answer usage 246 defined in [RFC3611] for unilateral "rtcp-xr" attribute parameters 247 applies. For detailed usage of Offer/Answer for unilateral 248 parameters, refer to section 5.2 of [RFC3611]. 250 5 Security Considerations 252 This proposed RTCP XR block introduces no new security considerations 253 beyond those described in [RFC3611]. This block does not provide per- 254 packet statistics, so the risk to confidentiality documented in 255 Section 7, paragraph 3 of [RFC3611] does not apply. 257 An attacker may put incorrect information in the Post-Repair Loss 258 Count reports, which will be affect the performance of loss repair 259 mechanisms. Implementers should consider the guidance in [RFC7202] 260 for using appropriate security mechanisms, i.e., where security is a 261 concern, the implementation should apply encryption and 262 authentication to the report block. For example, this can be achieved 263 by using the AVPF profile together with the Secure RTP profile as 264 defined in [RFC3711]; an appropriate combination of the two profiles 265 (an "SAVPF") is specified in [RFC5124]. However, other mechanisms 266 also exist (documented in [RFC7201]) and might be more suitable. 268 6 IANA Considerations 270 New block types for RTCP XR are subject to IANA registration. For 271 general guidelines on IANA considerations for RTCP XR, refer to 272 [RFC3611]. 274 6.1 New RTCP XR Block Type value 276 This document assigns the block type value PRLR in the IANA "RTP 277 Control Protocol Extended Reports (RTCP XR) Block Type Registry" to 278 the "Post-Repair Loss Count Metrics Report Block". 280 [Note to RFC Editor: please replace PRLR with the IANA provided RTCP 281 XR block type for this block.] 283 6.2 New RTCP XR SDP Parameter 285 This document also registers a new parameter "post-repair-loss-count" 286 in the "RTP Control Protocol Extended Reports (RTCP XR) Session 287 Description Protocol (SDP) Parameters Registry". 289 6.3 Contact Information for registrations 291 The contact information for the registration is : 293 RAI Area Directors 295 7 Acknowledgments 297 The author would like to thank Roni Even, Colin Perkins, and Qin Wu 298 for giving valuable comments and suggestions. 300 8 References 302 8.1 Normative References 304 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 305 Requirement Levels", BCP 14, RFC 2119, March 1997. 307 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 308 Jacobson, "RTP: A Transport Protocol for Real-Time 309 Applications", STD 64, RFC 3550, July 2003. 311 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 312 "RTP Control Protocol Extended Reports (RTCP XR)", 313 RFC 3611, November 2003. 315 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 316 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 317 RFC 3711, March 2004. 319 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 320 Real-time Transport Control Protocol (RTCP)-Based Feedback 321 (RTP/SAVPF)", RFC 5124, February 2008. 323 [RFC5725] Begen, A., Hsu, D., and M. Lague, "Post-Repair Loss RLE 324 Report Block Type for RTP Control Protocol (RTCP) Extended 325 Reports (XRs)", RFC 5725, February 2010. 327 8.2 Informative References 329 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 330 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 331 July 2006. 333 [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error 334 Correction", RFC 5109, December 2007. 336 [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New 337 Performance Metric Development", BCP 170, RFC 6390, 338 October 2011. 340 [RFC6709] Carpenter, B., Aboba, B., and S. Cheshire, "Design 341 Considerations for Protocol Extensions", RFC6709, 342 September 2012. 344 [RFC6792] Wu, Q., Hunt, G., and P. Arden, "Guidelines for Use of the 345 RTP Monitoring Framework", RFC 6792, November 2012. 347 [RFC7201] Westerlund, M. and C., Perkins, "Qptions for Securing RTP 348 Sessions", RFC 7201, April 2014. 350 [RFC7202] Perkins, C. and M., Westerlund, "Securing the RTP 351 Framework: Why RTP Does Not Mandate a Single Media 352 Security Solution", RFC 7202, April 2014. 354 Appendix A. Metrics Represented Using the Template from RFC 6390 355 a. Post-Repair RTP Packet Loss Count Metric 357 * Metric Name: Post-Repair RTP Packet Loss Count Metric. 359 * Metric Description: Total number of RTP packets still lost after 360 loss repair methods are applied 362 * Method of Measurement or Calculation: See section 3, Post-Repair 363 RTP Packet Loss Count Metric definition. It is directly measured 364 and must be measured for the primary source RTP packets with no 365 further chance of repair. 367 * Units of Measurement: This metric is expressed as a 16-bit 368 unsigned integer value giving the number of RTP packets. 370 * Measurement Point(s) with Potential Measurement Domain: It is 371 measured at the receiving end of the RTP stream. 373 * Measurement Timing: This metric relies on the sequence number 374 interval to determine measurement timing. See Section 3, 1st 375 paragraph, for details. 377 * Use and Applications: These metrics are applicable to any RTP 378 application, especially those that use loss repair mechanisms. See 379 Section 1 for details. 381 * Reporting Model: See RFC3611. 383 b. Repaired RTP Packet Loss Count Metric 385 * Metric Name: Repaired RTP Packet Count Metric. 387 * Metric Description: The number of RTP packets lost but repaired 388 after applying loss repair methods 390 * Method of Measurement or Calculation: See section 3, Repaired 391 RTP Packet Loss Count Metric definition. It is directly measured 392 and must be measured for the primary source RTP packets with no 393 further chance of repair. 395 * Units of Measurement: This metric is expressed as a 16-bit 396 unsigned integer value giving the number of RTP packets. 398 * Measurement Point(s) with Potential Measurement Domain: It is 399 measured at the receiving end of the RTP stream. 401 * Measurement Timing: This metric relies on the sequence number 402 interval to determine measurement timing. See Section 3, 1st 403 paragraph, for details. 405 * Use and Applications: These metrics are applicable to any RTP 406 application, especially those that use loss repair mechanisms. See 407 Section 1 for details. 409 * Reporting Model: See RFC3611. 411 Authors' Addresses 413 Rachel Huang 414 Huawei 415 101 Software Avenue, Yuhua District 416 Nanjing 210012 417 China 419 EMail: rachel.huang@huawei.com 421 Varun Singh 422 Aalto University 423 School of Electrical Engineering 424 Otakaari 5 A 425 Espoo, FIN 02150 426 Finland 428 Email: varun@comnet.tkk.fi 429 URI: http://www.netlab.tkk.fi/~varun/