idnits 2.17.1 draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-07.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 12, 2014) is 3420 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 15, 2015 V. Singh 5 Aalto University 6 December 12, 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-07 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 Sender Reports (SR)/Receiver Reports (RR) [RFC3550] contains 77 some rough statistics about the data received from the particular 78 source indicated in that block. One of them is the cumulative number 79 of 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. However, this metric is measured on media stream before 83 any loss repair mechanism, e.g., retransmission [RFC4588] and Forward 84 Error Correction (FEC) [RFC5109], is applied. Using a repair 85 mechanism usually results in recovering some or all of the lost 86 packets. Hence, the sending endpoint cannot assess the performance of 87 the repair mechanism by observing the change in fraction loss and the 88 cumulative loss statistics from RTCP SR/RR [RFC3550]. Consequently, 89 [RFC5725] specifies a post-repair loss Run-length Encoding (RLE) XR 90 report block to address this issue. The sending endpoint is able to 91 infer which packets were repaired from the RLE report block, but at 92 the cost of higher overhead. When applications use multiple XR 93 blocks, the endpoints may require more concise reporting to save 94 bandwidth. 96 This document defines a new XR block type to augment those defined in 97 [RFC3611] and complement the report block defined in [RFC5725] for 98 use in a range of RTP applications. This new block type reports the 99 number of primary source RTP packets that are still lost after 100 applying one or more loss repair mechanisms. The metrics defined in 101 this document are packet level rather than slice/picture level, which 102 means the partial recovery of a packet will not be regarded as a 103 repaired packet. In addition, another metric, repaired loss count, 104 is also introduced in this report block for calculating the pre- 105 repair loss count during the this range, so that the RTP sender or a 106 third-party entity is able to evaluate the effectiveness of the 107 repair methods used by the system. 109 The metrics defined in this document belong to the class of 110 transport-related metrics defined in [RFC6792] and are specified in 111 accordance with the guidelines in [RFC6390] and [RFC6792]. These 112 metrics are applicable to any RTP application, especially those that 113 use loss repair mechanisms. 115 2 Terminology 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [KEYWORDS]. 121 primary source RTP packet: The original RTP packet sent from the RTP 122 sender for the first time. A lost primary source RTP packet may be 123 repaired by some other RTP packets used in repair mechanisms like FEC 124 or retransmission. 126 3 Post-Repair Loss Count Metrics Report Block 128 This block reports the number of packets lost after applying repair 129 mechanisms to complement the RTCP XR metrics defined in [RFC5725]. 130 This packet may be stacked with other RTCP packets to form compound 131 RTCP packets and share the average reporting interval calculated by 132 the RTCP method described in [RFC3550]. When comparing this metric 133 with pre-repair loss metric of RTCP SR/RR, ambiguity may occur as 134 noted in [RFC5725]: Some packets will not be repaired in the current 135 RTCP interval. Thus it is RECOMMENDED that this report block should 136 be generated only for those source packets that have no further 137 chance of being repaired and not for any other packets. This block 138 needs to specify its own measurement period to avoid ambiguity in 139 calculating the post-repair loss count. The sequence number range 140 reported by RTCP SR/RR may contain some sequence numbers of packets 141 for which repair might still be possible. To avoid the ambiguity, we 142 use begin sequence number and end sequence number to explicitly 143 indicate the actual sequence number range that this RTCP XR report 144 block reports on as the measurement timing. These metrics defined in 145 this report block are all interval metrics and the measurement of 146 them is made at the RTP receiver. The relationship between the 147 metrics in this report block and the pre-repair loss metric of RTCP 148 XR could be expressed in the following formula: 150 cumulative number of packets lost = unrepaired loss count + 151 repaired loss count + to be repaired lost packet 153 "cumulative number of packets lost" is the metric from RTCP SR/RR. 154 "unrepaired loss count" and "repaired loss count" are the metrics 155 defined in this draft. 157 The post-repair loss count metrics report block has the following 158 format: 160 0 1 2 3 4 161 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 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | BT=PRLR | Reserved | block length = 4 | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | SSRC of Source | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | begin_seq | end_seq | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | unrepaired loss count | repaired loss count | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 Figure 1: Format for the Post-Repair Loss Count Metrics Report 173 Block 175 Block Type (BT): 8 bits 177 A Post-Repair Loss Count Metrics Report Block is identified by the 178 constant PRLR. 180 [Note to RFC Editor: Please replace PRLR with the IANA provided 181 RTCP XR block type for this block.] 183 Reserved: 8 bits 185 These bits are reserved for future use. They MUST be set to zero 186 by senders and ignored by receivers (see [RFC6709], Section 4.2). 188 block length: 16 bits 190 This field is in accordance with the definition in [RFC3611]. In 191 this report block, it MUST be set to 4. The block MUST be 192 discarded if the block length is set to a different value. 194 SSRC of source: 32 bits 196 As defined in Section 4.1 of [RFC3611]. 198 begin_seq: 16 bits 200 The first sequence number that this block reports on. 202 end_seq: 16 bits 204 The last sequence number that this block reports on plus one. 206 unrepaired loss count: 16 bits 208 Total number of packets finally lost after one or more loss-repair 209 methods, e.g., FEC and/or retransmission, during this interval. 210 This metric MUST NOT count the lost packets for which repair might 211 still be possible. Note that this metric MUST measure only primary 212 source RTP packets. 214 repaired loss count: 16 bits 216 Total number of packets fully repaired after one or more loss- 217 repair methods, e.g., FEC and/or retransmission, during this 218 interval. Note that this metric MUST measure only primary source 219 RTP packets. 221 4 SDP Signaling 223 [RFC3611] defines the use of SDP (Session Description Protocol) for 224 signaling the use of RTCP XR blocks. However XR blocks MAY be used 225 without prior signaling (see section 5 of [RFC3611]). 227 4.1 SDP rtcp-xr-attrib Attribute Extension 229 This session augments the SDP attribute "rtcp-xr" defined in Section 230 5.1 of [RFC3611] by providing an additional value of "xr-format" to 231 signal the use of the report block defined in this document. 233 xr-format =/ xr-prlr-block 235 xr-prlr-block = "post-repair-loss-count" 237 4.2 Offer/Answer Usage 239 When SDP is used in offer-answer context, the SDP Offer/Answer usage 240 defined in [RFC3611] for unilateral "rtcp-xr" attribute parameters 241 applies. For detailed usage of Offer/Answer for unilateral 242 parameters, refer to section 5.2 of [RFC3611]. 244 5 Security Considerations 246 It is believed that this RTCP XR block introduces no new security 247 considerations beyond those described in [RFC3611]. This block does 248 not provide per-packet statistics, so the risk to confidentially 249 documented in Section 7, paragraph 3 of [RFC3611] does not apply. 251 An attacker may put incorrect information in the Post-Repair Loss 252 Count reports, which will be affect the performance of loss repair 253 mechanisms. Implementers should consider the guidance in [RFC7202] 254 for using appropriate security mechanisms, i.e., where security is a 255 concern, the implementation should apply encryption and 256 authentication to the report block. For example, this can be achieved 257 by using the AVPF profile together with the Secure RTP profile as 258 defined in [RFC3711]; an appropriate combination of the two profiles 259 (an "SAVPF") is specified in [RFC5124]. However, other mechanisms 260 also exist (documented in [RFC7201]) and might be more suitable. 262 6 IANA Considerations 264 New block types for RTCP XR are subject to IANA registration. For 265 general guidelines on IANA considerations for RTCP XR, refer to 266 [RFC3611]. 268 6.1 New RTCP XR Block Type value 269 This document assigns the block type value PRLR in the IANA "RTP 270 Control Protocol Extended Reports (RTCP XR) Block Type Registry" to 271 the "Post-Repair Loss Count Metrics Report Block". 273 [Note to RFC Editor: please replace PRLR with the IANA provided RTCP 274 XR block type for this block.] 276 6.2 New RTCP XR SDP Parameter 278 This document also registers a new parameter "post-repair-loss-count" 279 in the "RTP Control Protocol Extended Reports (RTCP XR) Session 280 Description Protocol (SDP) Parameters Registry". 282 6.3 Contact Information for registrations 284 The contact information for the registration is : 286 RAI Area Directors 288 7 Acknowledgments 290 The author would like to thank Roni Even, Colin Perkins, and Qin Wu 291 for giving valuable comments and suggestions. 293 8 References 295 8.1 Normative References 297 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 298 Requirement Levels", BCP 14, RFC 2119, March 1997. 300 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 301 Jacobson, "RTP: A Transport Protocol for Real-Time 302 Applications", STD 64, RFC 3550, July 2003. 304 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 305 "RTP Control Protocol Extended Reports (RTCP XR)", RFC 306 3611, November 2003. 308 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 309 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 310 RFC 3711, March 2004. 312 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 313 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 314 July 2006. 316 [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error 317 Correction", RFC 5109, December 2007. 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 [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New 330 Performance Metric Development", BCP 170, RFC 6390, 331 October 2011. 333 [RFC6709] Carpenter, B., Aboba, B., and S. Cheshire, "Design 334 Considerations for Protocol Extensions", RFC 6709, 335 September 2012. 337 [RFC6792] Wu, Q., Hunt, G., and P. Arden, "Guidelines for Use of the 338 RTP Monitoring Framework", RFC 6792, November 2012. 340 [RFC7201] Westerlund, M. and C., Perkins, "Qptions for Securing RTP 341 Sessions", RFC 7201, April 2014. 343 [RFC7202] Perkins, C. and M., Westerlund, "Securing the RTP 344 Framework: Why RTP Does Not Mandate a Single Media 345 Security Solution", RFC 7202, April 2014. 347 Appendix A. Metrics Represented Using the Template from RFC 6390 349 a. Unrepaired RTP Packet Loss Count Metric 351 * Metric Name: Unrepaired RTP Packet Loss Count Metric 353 * Metric Description: Total number of RTP packets still lost after 354 loss repair methods are applied. 356 * Method of Measurement or Calculation: See section 3, Unrepaired 357 RTP Packet Loss Count Metric definition. It is directly measured 358 and must be measured for the primary source RTP packets with no 359 further chance of repair. 361 * Units of Measurement: This metric is expressed as a 16-bit 362 unsigned integer value. 364 * Measurement Point(s) with Potential Measurement Domain: It is 365 measured at the receiving end of the RTP stream. 367 * Measurement Timing: This metric relies on the sequence number 368 interval to determine measurement timing. See Section 3, 1st 369 paragraph, for details. 371 * Use and Applications: These metrics are applicable to any RTP 372 application, especially those that use loss repair mechanisms. See 373 Section 1 for details. 375 * Reporting Model: See RFC3611. 377 b. Repaired RTP Packet Loss Count Metric 379 * Metric Name: Repaired RTP Packet Count Metric 381 * Metric Description: The number of RTP packets lost but repaired 382 after applying loss repair methods. 384 * Method of Measurement or Calculation: See section 3, Repaired 385 RTP Packet Loss Count Metric definition. It is directly measured 386 and must be measured for the primary source RTP packets with no 387 further chance of repair. 389 * Units of Measurement: This metric is expressed as a 16-bit 390 unsigned integer value. 392 * Measurement Point(s) with Potential Measurement Domain: It is 393 measured at the receiving end of the RTP stream. 395 * Measurement Timing: This metric relies on the sequence number 396 interval to determine measurement timing. See Section 3, 1st 397 paragraph, for details. 399 * Use and Applications: These metrics are applicable to any RTP 400 application, especially those that use loss repair mechanisms. See 401 Section 1 for details. 403 * Reporting Model: See RFC3611. 405 Authors' Addresses 407 Rachel Huang 408 Huawei 409 101 Software Avenue, Yuhua District 410 Nanjing 210012 411 China 412 EMail: rachel.huang@huawei.com 414 Varun Singh 415 Aalto University 416 School of Electrical Engineering 417 Otakaari 5 A 418 Espoo, FIN 02150 420 Finland 422 Email: varun@comnet.tkk.fi 423 URI: http://www.netlab.tkk.fi/~varun/