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