idnits 2.17.1 draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-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 (July 05, 2013) is 3941 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) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 XR Block Working Group J. Ott 3 Internet-Draft V. Singh 4 Intended status: Standards Track Aalto University 5 Expires: January 06, 2014 I. Curcio 6 Nokia Research Center 7 July 05, 2013 9 RTP Control Protocol (RTCP) Extended Reports (XR) for Run Length 10 Encoding (RLE) of Discarded Packets 11 draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-06.txt 13 Abstract 15 The RTP Control Protocol (RTCP) is used in conjunction with the Real- 16 time Transport Protocol (RTP) in to provide a variety of short-term 17 and long-term reception statistics. The available reporting may 18 include aggregate information across longer periods of time as well 19 as individual packet reporting. This document specifies a per-packet 20 report metric capturing individual packets discarded from the jitter 21 buffer after successful reception. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 06, 2014. 40 Copyright Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. XR Discard RLE Report Block . . . . . . . . . . . . . . . . . 4 60 4. XR Bytes Discarded Report Block . . . . . . . . . . . . . . . 5 61 5. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 7 62 5.1. Reporting Node (Receiver) . . . . . . . . . . . . . . . . 7 63 5.2. Media Sender . . . . . . . . . . . . . . . . . . . . . . 7 64 6. SDP signaling . . . . . . . . . . . . . . . . . . . . . . . . 7 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 66 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 67 8.1. XR Report Block Registration . . . . . . . . . . . . . . 8 68 8.2. SDP Parameter Registration . . . . . . . . . . . . . . . 8 69 8.3. Contact information for IANA registrations . . . . . . . 9 70 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 71 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 73 10.2. Informative References . . . . . . . . . . . . . . . . . 10 74 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 10 75 A.1. changes in draft-ietf-xrblock-rtcp-xr-discard-rle- 76 metrics-00 . . . . . . . . . . . . . . . . . . . . . . . 10 77 A.2. changes in draft-ietf-xrblock-rtcp-xr-discard-rle- 78 metrics-01 . . . . . . . . . . . . . . . . . . . . . . . 10 79 A.3. changes in draft-ietf-xrblock-rtcp-xr-discard-rle- 80 metrics-02 . . . . . . . . . . . . . . . . . . . . . . . 10 81 A.4. changes in draft-ietf-xrblock-rtcp-xr-discard-rle- 82 metrics-03 . . . . . . . . . . . . . . . . . . . . . . . 10 83 A.5. changes in draft-ietf-xrblock-rtcp-xr-discard-rle- 84 metrics-04 . . . . . . . . . . . . . . . . . . . . . . . 10 85 A.6. changes in draft-ietf-xrblock-rtcp-xr-discard-rle- 86 metrics-05 . . . . . . . . . . . . . . . . . . . . . . . 11 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 89 1. Introduction 91 RTP [RFC3550] provides a transport for real-time media flows such as 92 audio and video together with the RTP control protocol (RTCP) which 93 provides periodic feedback about the media streams received in a 94 specific duration. In addition, RTCP can be used for timely feedback 95 about individual events to report (e.g., packet loss) [RFC4585]. 96 Both long-term and short-term feedback enable a sender to adapt its 97 media transmission and/or encoding dynamically to the observed path 98 characteristics. 100 RFC3611 [RFC3611] defines RTCP Extended Reports as a detailed 101 reporting framework to provide more than just the coarse RR 102 statistics. The detailed reporting may enable a sender to react more 103 appropriately to the observed networking conditions as these can be 104 characterized better, although at the expense of extra overhead. 106 Among many other report blocks, RFC3611 specifies the Loss Run Length 107 Encoding (RLE) block which reports runs of packets received and lost 108 with the granularity of individual packets. This can help both error 109 recovery and path loss characterization. In addition to lost 110 packets, RFC3611 defines the notion of "discarded" packets: packets 111 that were received but dropped from the jitter buffer because they 112 were either too early (for buffering) or too late (for playout). The 113 "discard rate" metric is part of the VoIP metrics report block even 114 though it is not just applicable to audio: it is specified as the 115 fraction of discarded packets since the beginning of the session. 116 See section 4.7.1 of RFC3611 [RFC3611]. 118 Recently proposed extensions to the Extended Reports (XR) reporting 119 suggest enhancing this discard metric: 121 o Reporting the number of discarded packets in a measurement 122 interval, i.e., during either the last reporting interval or since 123 the beginning of the session, as indicated by a flag in the 124 suggested XR report [I-D.ietf-xrblock-rtcp-xr-discard]. If an 125 endpoint needs to report packet discard due to other reasons than 126 early- and late-arrival (for example, discard due to duplication, 127 redundancy, etc.) then it should consider using the Discarded 128 Packets Report Block [I-D.ietf-xrblock-rtcp-xr-discard]. 130 o Reporting gaps and bursts of discarded packets during a 131 measurement interval, i.e., the last reporting interval or the 132 duration of the session 133 [I-D.ietf-xrblock-rtcp-xr-burst-gap-discard]. 135 However, none of these metrics allow a receiver to report precisely 136 which packets were discarded. While this information could in theory 137 be derived from high-frequency reporting on the number of discarded 138 packets [I-D.ietf-xrblock-rtcp-xr-discard] or from the gap/burst 139 report [I-D.ietf-xrblock-rtcp-xr-burst-gap-discard], these two 140 mechanisms do not appear feasible: The former would require an unduly 141 high amount of reporting which still might not be sufficient due to 142 the non-deterministic scheduling of RTCP packets. The latter incur 143 significant complexity and reporting overhead and might still not 144 deliver the desired accuracy. 146 This document defines a discard report block following the idea of 147 the run-length encoding applied for lost and received packets in 148 [RFC3611]. 150 Complementary to or instead of the indication which packets were 151 discarded, an XR block is defined to indicate the number of bytes 152 discarded, per interval or for the duration of the session, similar 153 to other XR report blocks. 155 2. Terminology 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 159 document are to be interpreted as described in BCP 14, RFC 2119 160 [RFC2119] and indicate requirement levels for compliant 161 implementations. 163 The terminology defined in RTP [RFC3550] and in the extensions for XR 164 reporting [RFC3611] applies. 166 3. XR Discard RLE Report Block 168 The XR Discard RLE report block uses the same format as specified for 169 the loss and duplicate report blocks in [RFC3611]. Figure 1 170 describes the packet format. The fields "BT", "T", "block length", 171 "SSRC of source", "begin_seq", and "end_seq" SHALL have the same 172 semantics and representation as defined in [RFC3611]. The "chunks" 173 encoding the run length SHALL have the same representation as in 174 RFC3611, but encode discarded packets. 176 0 1 2 3 177 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 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | BT=DRLE |rsvd |E| T | block length | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | SSRC of source | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | begin_seq | end_seq | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | chunk 1 | chunk 2 | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 : ... : 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | chunk n-1 | chunk n | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 Figure 1: XR Discard Report Block 194 Block Type (BT, 8 bits): A Run-length encoded Discarded Packets 195 Report Block is identified by the constant DRLE. 197 [Note to RFC Editor: please replace DRLE with the IANA provided RTCP 198 XR block type for this block. Please remove this note prior to 199 publication as an RFC.] 201 rsvd (3 bits): These reserved bits SHOULD be set to zero by receivers 202 and MUST be ignored by senders. 204 The 'E' bit is introduced to distinguish between packets discarded 205 due to early arrival and those discarded due to late arrival. The 206 'E' bit MUST be set to '1' if the chunks represent packets discarded 207 due to too early arrival and MUST be set to '0' otherwise. 209 In case both early and late discarded packets shall be reported, two 210 Discard RLE report blocks MUST be included; their sequence number 211 range MAY overlap, but individual packets MUST only be reported as 212 either early or late and not appear marked in both. Packets reported 213 in neither are considered to be properly received and not discarded. 215 Discard RLE Report Blocks SHOULD be sent in conjunction with an RTCP 216 RR as a compound RTCP packet. 218 4. XR Bytes Discarded Report Block 220 The XR Bytes Discarded report block uses the following format which 221 follows the model of the framework for performance metric development 222 [RFC6390]. 224 0 1 2 3 225 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 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | BT=BDR | I |E|reserved | block length=2 | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | SSRC of source | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | number of bytes discarded | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 Figure 2: XR Bytes Discarded Report Block 236 Block Type (BT, 8 bits): A Bytes Discarded Packets Report Block is 237 identified by the constant BDR. 239 [Note to RFC Editor: please replace BDR with the IANA provided RTCP 240 XR block type for this block. Please remove this note prior to 241 publication as an RFC.] 242 The Interval Metric flag (I) (2 bits) is used to indicate whether the 243 discard metric is Interval, or a Cumulative metric, that is, whether 244 the reported value applies to the most recent measurement interval 245 duration between successive reports (I=10, the Interval Duration) or 246 to the accumulation period characteristic of cumulative measurements 247 (I=11, the Cumulative Duration). Since the bytes discarded are not 248 measured at a particular time instance but over one or several 249 reporting intervals, the metric MUST NOT be reported as a Sampled 250 Metric (I=01). 252 The 'E' bit is introduced to distinguish between packets discarded 253 due to early arrival and those discarded due to late arrival. The 254 'E' bit MUST be set to '1' if it reports bytes discarded due to early 255 arrival and MUST be set to '0' if it reports bytes discarded due to 256 late arrival. In case both early and late discarded packets shall be 257 reported, two Bytes Discarded report blocks MUST be included. 259 These reserved bits (5 bits) SHOULD be set to zero by receivers and 260 MUST be ignored by senders. 262 block length (16 bits) MUST be set to 2, in accordance with the 263 definition of this field in [RFC3611]. The block MUST be discarded 264 if the block length is set to a different value. 266 The 'number of bytes discarded' is a 32-bit unsigned integer value 267 indicating the total number of bytes discarded. 269 If Interval Metric flag (I=11) is set, the value in the field 270 indicates the number of bytes discarded from the start of the 271 session, if Interval Metric flag (I=01) is set, it indicates the 272 number of bytes discarded since the last RTCP XR Byte Discarded Block 273 was received. 275 If the XR block follows a measurement identity block [RFC6776] in the 276 same RTCP compound packet then the cumulative (I=11) or the interval 277 (I=10) for this report block corresponds to the values of the 278 "measurement duration" in the measurement information block. 280 If the receiver sends the Bytes Discarded Report Block without the 281 measurement identity block then the discard block MUST be sent in 282 conjunction with an RTCP Receiver Report (RR) as a compound RTCP 283 packet. 285 5. Protocol Operation 287 This section describes the behavior of the reporting (= receiver) 288 node and the media sender. 290 5.1. Reporting Node (Receiver) 292 Transmission of RTCP XR Discard RLE Reports is up to the discretion 293 of the receiver, as is the reporting granularity. However, it is 294 RECOMMENDED that the receiver signals all discarded packets using the 295 method defined in this document. If all packets over a reporting 296 period were lost, the receiver MAY use the Discard Report Block 297 [I-D.ietf-xrblock-rtcp-xr-discard] instead. In case of limited 298 available reporting bandwidth, it is up to the receiver whether or 299 not to include RTCP XR Discard RLE reports. 301 The receiver MAY send the Discard RLE Reports as part of the 302 regularly scheduled RTCP packets as per RFC3550. It MAY also include 303 Discard RLE Reports in immediate or early feedback packets as per 304 RFC4585. 306 5.2. Media Sender 308 The media sender MUST be prepared to operate without receiving any 309 Discard RLE reports. If Discard RLE reports are generated by the 310 receiver, the sender cannot rely on all these reports being received, 311 nor can the sender rely on a regular generation pattern from the 312 receiver side. 314 However, if the sender receives any RTCP reports but no Discard RLE 315 report blocks and is aware that the receiver supports Discard RLE 316 report blocks, it MAY assume that no packets were discarded at the 317 receiver. 319 The sender SHOULD accept the Bytes Discarded Report Block only if it 320 is received in a compound RTCP receiver report or if it is preceded 321 by a measurement identity block [RFC6776]. Under all other 322 circumstances it MUST ignore the block. 324 6. SDP signaling 326 A participant of a media session MAY use SDP to signal its support 327 for the two report blocks specified in this document or use them 328 without any prior signaling (see section 5 of [RFC3611]). 330 For signaling in SDP, the RTCP XR attribute as defined in [RFC3611] 331 MUST be used. The SDP [RFC4566] attribute 'xr-format' defined in 332 RFC3611 is augmented as described in the following to indicate the 333 RLE discard metric and bytes discarded metric. 335 rtcp-xr-attrib = "a=" "rtcp-xr" ":" [xr-format *(SP xr-format)] 336 CRLF ; defined in [RFC3611] 338 xr-format =/ xr-discard-rle 339 / xr-discard-bytes 341 xr-discard-rle = "discard-rle" 342 xr-discard-bytes = "discard-bytes" 344 The parameter 'discard-rle' MUST be used to indicate support for the 345 Discard RLE Report Block defined in Section 3, the parameter 346 'discard-bytes' to indicate support for the Bytes Discarded Report 347 Block defined in Section 4 349 When SDP is used in Offer/Answer context, the mechanism defined in 350 [RFC3611] for unilateral "rtcp-xr" attribute parameters applies (see 351 section 5.2 of [RFC3611]). 353 7. Security Considerations 355 The security considerations of [RFC3550], [RFC3611], and [RFC4585] 356 apply. Since this document offers only a more precise reporting for 357 an already existing metric, no further security implications are 358 foreseen. 360 8. IANA Considerations 362 New block types for RTCP XR are subject to IANA registration. For 363 general guidelines on IANA considerations for RTCP XR, refer to 364 [RFC3611]. 366 8.1. XR Report Block Registration 368 This document extends the IANA "RTP Control Protocol Extended Reports 369 (RTCP XR) Block Type Registry" by two new values: DRLE and BDR. 371 [Note to RFC Editor: please replace DRLE and BDR with the IANA 372 provided RTCP XR block type for this block here and in the diagrams 373 above. Please remove this note prior to publication as an RFC.] 375 8.2. SDP Parameter Registration 376 This document registers two new parameters for the Session 377 Description Protocol (SDP), "discard-rle" and "discard-bytes", in the 378 "RTP Control Protocol Extended Reports (RTCP XR) Session Description 379 Protocol (SDP) Parameters Registry". 381 8.3. Contact information for IANA registrations 383 Joerg Ott (jo@comnet.tkk.fi) 385 Aalto University Comnet, Otakaari 5A, 02150 Espoo, Finland. 387 9. Acknowledgments 389 Thanks to Qin Wu, Colin Perkins, Dan Romascanu, Roni Even and Dan 390 Wing for providing valuable feedback on earlier versions of this 391 draft 393 10. References 395 10.1. Normative References 397 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 398 Requirement Levels", BCP 14, RFC 2119, March 1997. 400 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 401 Jacobson, "RTP: A Transport Protocol for Real-Time 402 Applications", STD 64, RFC 3550, July 2003. 404 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 405 Protocol Extended Reports (RTCP XR)", RFC 3611, November 406 2003. 408 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 409 "Extended RTP Profile for Real-time Transport Control 410 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 411 2006. 413 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 414 Description Protocol", RFC 4566, July 2006. 416 [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New 417 Performance Metric Development", BCP 170, RFC 6390, 418 October 2011. 420 [RFC6776] Clark, A. and Q. Wu, "Measurement Identity and Information 421 Reporting Using a Source Description (SDES) Item and an 422 RTCP Extended Report (XR) Block", RFC 6776, October 2012. 424 10.2. Informative References 426 [I-D.ietf-xrblock-rtcp-xr-discard] 427 Clark, A., Zorn, G., and W. Wu, "RTP Control Protocol 428 (RTCP) Extended Report (XR) Block for Discard Count metric 429 Reporting", draft-ietf-xrblock-rtcp-xr-discard-15 (work in 430 progress), June 2013. 432 [I-D.ietf-xrblock-rtcp-xr-burst-gap-discard] 433 Clark, A., Huang, R., and W. Wu, "RTP Control 434 Protocol(RTCP) Extended Report (XR) Block for Burst/Gap 435 Discard metric Reporting", draft-ietf-xrblock-rtcp-xr- 436 burst-gap-discard-14 (work in progress), April 2013. 438 Appendix A. Change Log 440 Note to the RFC-Editor: please remove this section prior to 441 publication as an RFC. 443 A.1. changes in draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-00 445 o Changed the interval flag from 1 to 2 bits in the discarded bytes 446 report. Also added the measurement identification tag to the 447 block. 449 o Added this section. 451 A.2. changes in draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-01 453 o Removed the measurement identification tag in the bytes discarded 454 block. 456 A.3. changes in draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-02 458 o Removed the extra Tag bits from the Discarded bytes XR block. 460 o Clarified use of measurement identity block in Section 4 and 5.2 462 A.4. changes in draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-03 464 o Added explanation for block length in bytes discarded block. 466 o Added an acknowledgement section. 468 A.5. changes in draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-04 470 o Added Block Type definition to each XRBlock. 472 o Made changes requested in WGLC. 474 A.6. changes in draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-05 476 o Made changes requested by SDP directorate. 478 Authors' Addresses 480 Joerg Ott 481 Aalto University 482 School of Electrical Engineering 483 Otakaari 5 A 484 Espoo, FIN 02150 485 Finland 487 Email: jo@comnet.tkk.fi 489 Varun Singh 490 Aalto University 491 School of Electrical Engineering 492 Otakaari 5 A 493 Espoo, FIN 02150 494 Finland 496 Email: varun@comnet.tkk.fi 497 URI: http://www.netlab.tkk.fi/~varun/ 499 Igor D.D. Curcio 500 Nokia Research Center 501 P.O. Box 1000 (Visiokatu 3) 502 Tampere, FIN 33721 503 Finland 505 Email: igor.curcio@nokia.com