idnits 2.17.1 draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-06.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 (December 2, 2014) is 3430 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: June 5, 2015 V. Singh 5 Aalto University 6 December 2, 2014 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-06 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) 2014 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 . . . . . . . . . . . . . . . . . . . . . . 6 64 6.1 New RTCP XR Block Type value . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . . . . . . 9 74 1 Introduction 76 RTCP SR/RR [RFC3550] contains some rough statistics about the data 77 received from the particular source indicated in that block. One of 78 them is the cumulative number of packet lost, which is called pre- 79 repair loss metric in this document. This metric conveys information 80 regarding the total number of RTP data packets that have been lost 81 since the beginning of the RTP session. However, this metric is 82 measured on media stream before any loss repair mechanism, e.g., 83 retransmission [RFC4588] and Forward Error Correction (FEC) 84 [RFC5109], is applied. Using a repair mechanism usually results in 85 recovering some or all of the lost packets. Hence, the sending 86 endpoint cannot assess the performance of the repair mechanism by 87 observing the change in fraction loss and the cumulative loss 88 statistics from RTCP SR/RR [RFC3550]. Consequently, [RFC5725] 89 specifies a post-repair loss Run-length Encoding (RLE) XR report 90 block to address this issue. The sending endpoint is able to infer 91 which packets were repaired from the RLE report block, but at the 92 cost of higher overhead. When applications use multiple XR blocks, 93 the endpoints may require more concise reporting to save bandwidth. 95 This document defines a new XR block type to augment those defined in 96 [RFC3611] and complement the report block defined in [RFC5725] for 97 use in a range of RTP application. This new block type reports the 98 number of primary source RTP packets that are still lost after 99 applying one or more loss repair mechanisms. The metrics defined in 100 this document are packet level rather than slice/picture level, which 101 means the partial recovery of a packet will not be regarded as a 102 repaired packet. In addition, another metric, repaired loss count, 103 is also introduced in this report block for calculating the pre- 104 repair loss count during the this range, so that the RTP sender or a 105 third-party entity is able to evaluate the effectiveness of the 106 repair methods used by the system. 108 The metrics defined in this document belongs to the class of 109 transport-related metrics defined in [RFC6792]. And it is in 110 accordance with the guidelines in [RFC6390] and [RFC6792]. These 111 metrics are applicable to any RTP application, especially those that 112 use loss repair mechanisms. 114 2 Terminology 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in [KEYWORDS]. 120 primary source RTP packet: The original RTP packet sent from the RTP 121 sender for the first time. A lost primary source RTP packet may be 122 repaired by some other RTP packets used in repair mechanisms like FEC 123 or retransmission. 125 3 Post-Repair Loss Count Metrics Report Block 127 This block reports the number of packets lost after applying repair 128 mechanisms to complement the RTCP XR metrics defined in [RFC5725]. 129 This packet may be stacked with other RTCP packets to form compound 130 RTCP packets and share the average reporting interval calculated by 131 the RTCP method described in [RFC3550]. When comparing this metric 132 with pre-repair loss metric of RTCP SR/RR, ambiguity may occur as 133 noted in [RFC5725]: Some packets will not be repaired in current RTCP 134 interval. Thus it is RECOMMENDED that this report block should be 135 generated for those source packets that have no further chance of 136 being repaired. But a potential ambiguity may result from sequence 137 number range inconsistent. The sequence number range reported by RTCP 138 SR/RR may contain some sequence numbers of packets for which repair 139 might still be possible. To address this issue, we use begin sequence 140 number and end sequence number to explicitly indicate the actual 141 sequence number range that this RTCP XR report block reports on as 142 the measurement timing. These metrics defined in this report block 143 are all interval metrics and the measurement of them is made at the 144 RTP receiver. The relationship between the metrics in this report 145 block and the pre-repair loss metric of RTCP XR could be expressed in 146 the following formula: 148 cumulative number of packets lost = unrepaired loss count + 149 repaired loss count + to be repaired lost packet 151 "cumulative number of packets lost" is the metric from RTCP SR/RR. 152 "unrepaired loss count" and "repaired loss count" are the metrics 153 defined in this draft. 155 The post-repair loss count metrics report block has the following 156 format: 158 0 1 2 3 4 159 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 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | BT=PRLR | Reserved | block length = 4 | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | SSRC of Source | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | begin_seq | end_seq | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | unrepaired loss count | repaired loss count | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 Figure 1: Format for the Post-Repair Loss Count Metrics Report 170 Block 172 Block Type (BT): 8 bits 174 A Post-Repair Loss Count Metrics Report Block is identified by the 175 constant PRLR. 177 [Note to RFC Editor: Please replace PRLR with the IANA provided 178 RTCP XR block type for this block.] 180 Reserved: 8 bits 182 These bits are reserved for future use. They MUST be set to zero 183 by senders and ignored by receivers (see [RFC6709], Section 4.2). 185 block length: 16 bits 187 This field is in accordance with the definition in [RFC3611]. In 188 this report block, it MUST be set to 4. The block MUST be 189 discarded if the block length is set to a different value. 191 SSRC of source: 32 bits 193 As defined in Section 4.1 of [RFC3611]. 195 begin_seq: 16 bits 197 The first sequence number that this block reports on. 199 end_seq: 16 bits 201 The last sequence number that this block reports on plus one. 203 unrepaired loss count: 16 bits 205 Total number of packets finally lost after one or more loss-repair 206 methods, e.g., FEC and/or retransmission, during this interval. 207 This metric MUST NOT count the lost packets for which repair might 208 still be possible. Note that this metric must be measured in the 209 primary source RTP packets. 211 repaired loss count: 16 bits 213 Total number of packets fully repaired after one or more loss- 214 repair methods, e.g., FEC and/or retransmission, during this 215 interval. Note that this metric must be measured in the primary 216 source RTP packets. 218 4 SDP Signaling 220 [RFC3611] defines the use of SDP (Session Description Protocol) for 221 signaling the use of RTCP XR blocks. However XR blocks MAY be used 222 without prior signaling (see section 5 of [RFC3611]). 224 4.1 SDP rtcp-xr-attrib Attribute Extension 226 This session augments the SDP attribute "rtcp-xr" defined in Section 227 5.1 of [RFC3611] by providing an additional value of "xr-format" to 228 signal the use of the report block defined in this document. 230 xr-format =/ xr-prlr-block 232 xr-prlr-block = "post-repair-loss-count" 234 4.2 Offer/Answer Usage 236 When SDP is used in offer-answer context, the SDP Offer/Answer usage 237 defined in [RFC3611] for unilateral "rtcp-xr" attribute parameters 238 applies. For detailed usage of Offer/Answer for unilateral 239 parameter, refer to section 5.2 of [RFC3611]. 241 5 Security Considerations 243 It is believed that this RTCP XR block introduces no new security 244 considerations beyond those described in [RFC3611]. This block does 245 not provide per-packet statistics, so the risk to confidentially 246 documented in Section 7, paragraph 3 of [RFC3611] does not apply. 248 An attacker may put incorrect information in the Post-Repair Loss 249 Count reports, which will be affect the performance of loss repair 250 mechanisms. Implementers should consider the guidance in [RFC7202] 251 for using appropriate security mechanisms, i.e., where security is a 252 concern, the implementation should apply encryption and 253 authentication to the report block. For example, this can be achieved 254 by using the AVPF profile together with the Secure RTP profile as 255 defined in [RFC3711]; an appropriate combination of the two profiles 256 (an "SAVPF") is specified in [RFC5124]. However, other mechanisms 257 also exist (documented in [RFC7201]) and might be more suitable. 259 6 IANA Considerations 261 New block types for RTCP XR are subject to IANA registration. For 262 general guidelines on IANA considerations for RTCP XR, refer to 263 [RFC3611]. 265 6.1 New RTCP XR Block Type value 266 This document assigns the block type value PRLR in the IANA "RTP 267 Control Protocol Extended Reports (RTCP XR) Block Type Registry" to 268 the "Post-Repair Loss Count Metrics Report Block". 270 [Note to RFC Editor: please replace PRLR with the IANA provided RTCP 271 XR block type for this block.] 273 6.2 New RTCP XR SDP Parameter 275 This document also registers a new parameter "post-repair-loss-count" 276 in the "RTP Control Protocol Extended Reports (RTCP XR) Session 277 Description Protocol (SDP) Parameters Registry". 279 6.3 Contact Information for registrations 281 The following contact information is provided for all registrations 282 in this document: 284 Rachel Huang (rachel.huang@huawei.com) 286 101 Software Avenue, Yuhua District 287 Nanjing, Jiangsu 210012 288 China 290 7 Acknowledgments 292 The author would like to thank Roni Even and Colin Perkins for giving 293 valuable comments and suggestions. 295 8 References 297 8.1 Normative References 299 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 300 Requirement Levels", BCP 14, RFC 2119, March 1997. 302 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 303 Jacobson, "RTP: A Transport Protocol for Real-Time 304 Applications", STD 64, RFC 3550, July 2003. 306 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 307 "RTP Control Protocol Extended Reports (RTCP XR)", RFC 308 3611, November 2003. 310 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 311 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 312 RFC 3711, March 2004. 314 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 315 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 316 July 2006. 318 [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error 319 Correction", RFC 5109, December 2007. 321 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 322 Real-time Transport Control Protocol (RTCP)-Based Feedback 323 (RTP/SAVPF)", RFC 5124, February 2008. 325 [RFC5725] Begen, A., Hsu, D., and M. Lague, "Post-Repair Loss RLE 326 Report Block Type for RTP Control Protocol (RTCP) Extended 327 Reports (XRs)", RFC 5725, February 2010. 329 8.2 Informative References 331 [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New 332 Performance Metric Development", BCP 170, RFC 6390, 333 October 2011. 335 [RFC6709] Carpenter, B., Aboba, B., and S. Cheshire, "Design 336 Considerations for Protocol Extensions", RFC 6709, 337 September 2012. 339 [RFC6792] Wu, Q., Hunt, G., and P. Arden, "Guidelines for Use of the 340 RTP Monitoring Framework", RFC 6792, November 2012. 342 [RFC7201] Westerlund, M. and C., Perkins, "Qptions for Securing RTP 343 Sessions", RFC 7201, April 2014. 345 [RFC7202] Perkins, C. and M., Westerlund, "Securing the RTP 346 Framework: Why RTP Does Not Mandate a Single Media 347 Security Solution", RFC 7202, April 2014. 349 Appendix A. Metrics Represented Using the Template from RFC 6390 351 a. Unrepaired RTP Packet Loss Count Metric 353 * Metric Name: Unrepaired RTP Packet Loss Count Metric 355 * Metric Description: Total number of RTP packets still lost after 356 loss repair methods are applied 358 * Method of Measurement or Calculation: It must be measured for 359 the primary source RTP packets with no further chance of repair 360 * Units of Measurement: See section 3, unrepaired loss count 361 definition 363 * Measurement Point(s) with Potential Measurement Domain: See 364 section 3, 1st paragraph 366 * Measurement Timing: See Section 3, 1st paragraph, for 367 measurement timing 369 * Use and Applications: See Section 1 371 * Reporting Model: See RFC3611 373 b. Repaired RTP Packet Loss Count Metric 375 * Metric Name: Repaired RTP Packet Count Metric 377 * Metric Description: The number of RTP packets lost but repaired 378 after applying loss repair methods 380 * Method of Measurement or Calculation: It must be measured for 381 the primary source RTP packets with no further chance of repair 383 * Units of Measurement: See section 3, repaired loss count 384 definition 386 * Measurement Point(s) with Potential Measurement Domain: See 387 section 3, 1st paragraph 389 * Measurement Timing: See Section 3, 1st paragraph, for 390 measurement timing 392 * Use and Applications: See Section 1 394 * Reporting Model: See RFC3611 396 Authors' Addresses 398 Rachel Huang 399 Huawei 400 101 Software Avenue, Yuhua District 401 Nanjing 210012 402 China 404 EMail: rachel.huang@huawei.com 405 Varun Singh 406 Aalto University 407 School of Electrical Engineering 408 Otakaari 5 A 409 Espoo, FIN 02150 411 Finland 413 Email: varun@comnet.tkk.fi 414 URI: http://www.netlab.tkk.fi/~varun/