idnits 2.17.1 draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-04.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 5, 2012) is 4313 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) == Outdated reference: A later version (-10) exists of draft-ietf-xrblock-rtcp-xr-meas-identity-07 == Outdated reference: A later version (-15) exists of draft-ietf-xrblock-rtcp-xr-discard-04 == Outdated reference: A later version (-14) exists of draft-ietf-xrblock-rtcp-xr-burst-gap-discard-03 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 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 6, 2013 I. Curcio 6 Nokia Research Center 7 July 5, 2012 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-04.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 6, 2013. 40 Copyright Notice 42 Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . . . . . . . . 8 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 66 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 67 8.1. XR Report Block Registration . . . . . . . . . . . . . . . 9 68 8.2. SDP Parameter Registration . . . . . . . . . . . . . . . . 9 69 8.3. Contact information for IANA registrations . . . . . . . . 9 70 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 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 76 draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-00 . . . . 11 77 A.2. changes in 78 draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-01 . . . . 11 79 A.3. changes in 80 draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-02 . . . . 11 81 A.4. changes in 82 draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-03 . . . . 11 83 A.5. changes in 84 draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-04 . . . . 11 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 87 1. Introduction 89 RTP [RFC3550] provides a transport for real-time media flows such as 90 audio and video together with the RTP control protocol which provides 91 periodic feedback about the media streams received in a specific 92 duration. In addition, RTCP can be used for timely feedback about 93 individual events (e.g., packet loss) [RFC4585]. Both long-term and 94 short-term feedback enable a sender to adapt its media transmission 95 and/or encoding dynamically to the observed path characteristics. 97 RFC3611 [RFC3611] defines RTCP Extended Reports as a detailed 98 reporting framework to provide more than just the coarse RR 99 statistics. The detailed reporting may enable a sender to react more 100 appropriately to the observed networking conditions as these can be 101 characterized better, although at the expense of extra overhead. 103 Among many other report blocks, RFC3611 specifies the Loss RLE block 104 which reports runs of packets received and lost with the granularity 105 of individual packets. This can help both error recovery and path 106 loss characterization. In addition to lost packets, RFC3611 defines 107 the notion of "discarded" packets: packets that were received but 108 dropped from the jitter buffer because they were either too early 109 (for buffering) or too late (for playout). The "discard rate" metric 110 is part of the VoIP metrics report block even though it is not just 111 applicable to audio: it is specified as the fraction of discarded 112 packets since the beginning of the session. See section 4.7.1 of 113 RFC3611 [RFC3611]. 115 Recently proposed extensions to the XR reporting suggest enhancing 116 this discard metric: 117 o Reporting the number of discarded packets in a measurement 118 interval, i.e., during either the last reporting interval or since 119 the beginning of the session, as indicated by a flag in the 120 suggested XR report [I-D.ietf-xrblock-rtcp-xr-discard]. If an 121 endpoint needs to report packet discard due to other reasons than 122 early- and late-arrival (for example, discard due to duplication, 123 redundancy, etc.) then it should consider using the Discarded 124 Packets Report Block [I-D.ietf-xrblock-rtcp-xr-discard]. 125 o Reporting gaps and bursts of discarded packets during a 126 measurement interval, i.e., the last reporting interval or the 127 duration of the session 128 [I-D.ietf-xrblock-rtcp-xr-burst-gap-discard]. 130 However, none of these metrics allow a receiver to report precisely 131 which packets were discarded. While this information could in theory 132 be derived from high-frequency reporting on the number of discarded 133 packets [I-D.ietf-xrblock-rtcp-xr-discard] or from the gap/burst 134 report [I-D.ietf-xrblock-rtcp-xr-burst-gap-discard], these two 135 mechanisms do not appear feasible: The former would require an unduly 136 high amount of reporting which still might not be sufficient due to 137 the non-deterministic scheduling of RTCP packets. The latter incur 138 significant complexity and reporting overhead and might still not 139 deliver the desired accuracy. 141 This document defines a discard report block following the idea of 142 the run-length encoding applied for lost and received packets in 143 [RFC3611]. 145 Complementary to or instead of the indication which packets were 146 discarded, an XR block is defined to indicate the number of bytes 147 discarded, per interval or for the duration of the session, similar 148 to other XR report blocks. 150 2. Terminology 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 154 document are to be interpreted as described in BCP 14, RFC 2119 155 [RFC2119] and indicate requirement levels for compliant 156 implementations. 158 The terminology defined in RTP [RFC3550] and in the extensions for XR 159 reporting [RFC3611] applies. 161 3. XR Discard RLE Report Block 163 The XR Discard RLE report block uses the same format as specified for 164 the loss and duplicate report blocks in [RFC3611]. Figure 1 recaps 165 the packet format. The fields "BT", "T", "block length", "SSRC of 166 source", "begin_seq", and "end_seq" SHALL have the same semantics and 167 representation as defined in [RFC3611]. The "chunks" encoding the 168 run length SHALL have the same representation as in RFC3611, but 169 encode discarded packets. 171 0 1 2 3 172 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 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | BT=DRLE |rsvd |E| T | block length | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | SSRC of source | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | begin_seq | end_seq | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | chunk 1 | chunk 2 | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 : ... : 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | chunk n-1 | chunk n | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 Figure 1: XR Discard Report Block 189 Block Type (BT, 8 bits): A Run-length encoded Discarded Packets 190 Report Block is identified by the constant DRLE. 192 [Note to RFC Editor: please replace DRLE with the IANA provided RTCP 193 XR block type for this block. Please remove this note prior to 194 publication as an RFC.] 196 rsvd (3 bits): These reserved bits SHOULD be set to zero by receivers 197 and MUST be ignored by senders. 199 The 'E' bit is introduced to distinguish between packets discarded 200 due to early arrival and those discarded due to late arrival. The 201 'E' bit MUST be set to '1' if the chunks represent packets discarded 202 due to too early arrival and MUST be set to '0' otherwise. 204 In case both early and late discarded packets shall be reported, two 205 Discard RLE report blocks MUST be included; their sequence number 206 range MAY overlap, but individual packets MUST only be reported as 207 either early or late and not appear marked in both. Packets reported 208 in neither are considered to be properly received and not discarded. 210 Discard RLE Report Blocks SHOULD be sent in conjunction with an RTCP 211 RR as a compound RTCP packet. 213 4. XR Bytes Discarded Report Block 215 The XR Bytes Discarded report block uses the following format which 216 follows the model of the framework for performance metric development 217 [RFC6390]. 219 0 1 2 3 220 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 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | BT=BDR | I |E|reserved | block length=2 | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | SSRC of source | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | number of bytes discarded | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 Figure 2: XR Bytes Discarded Report Block 231 Block Type (BT, 8 bits): A Bytes Discarded Packets Report Block is 232 identified by the constant BDR. 234 [Note to RFC Editor: please replace BDR with the IANA provided RTCP 235 XR block type for this block. Please remove this note prior to 236 publication as an RFC.] 238 The Interval Metric flag (I) (2 bits) is used to indicate whether the 239 discard metric is Interval, or a Cumulative metric, that is, whether 240 the reported value applies to the most recent measurement interval 241 duration between successive reports (I=10, the Interval Duration) or 242 to the accumulation period characteristic of cumulative measurements 243 (I=11, the Cumulative Duration). Since the bytes discarded are not 244 measured at a particular time instance but over one or several 245 reporting intervals, the metric MUST NOT be reported as a Sampled 246 Metric (I=01). 248 The 'E' bit is introduced to distinguish between packets discarded 249 due to early arrival and those discarded due to late arrival. The 250 'E' bit MUST be set to '1' if it reports bytes discarded due to early 251 arrival and MUST be set to '0' if it reports bytes discarded due to 252 late arrival. In case both early and late discarded packets shall be 253 reported, two Bytes Discarded report blocks MUST be included. 255 These reserved bits (5 bits) SHOULD be set to zero by receivers and 256 MUST be ignored by senders. 258 block length (16 bits) MUST be set to 2, in accordance with the 259 definition of this field in [RFC3611]. The block MUST be discarded 260 if the block length is set to a different value. 262 The 'number of bytes discarded' is a 32-bit unsigned integer value 263 indicating the total number of bytes discarded. 265 If Interval Metric flag (I=11) is set, the value in the field 266 indicates the number of bytes discarded from the start of the 267 session, if Interval Metric flag (I=01) is set, it indicates the 268 number of bytes discarded since the last RTCP XR Byte Discarded Block 269 was received. 271 If the XR block follows a measurement identity block 272 [I-D.ietf-xrblock-rtcp-xr-meas-identity] in the same RTCP compound 273 packet then the cumulative (I=11) or the interval (I=10) for this 274 report block corresponds to the values of the "measurement duration" 275 in the measurement information block. 277 If the receiver sends the Bytes Discarded Report Block without the 278 measurement identity block then the discard block MUST be sent in 279 conjunction with an RTCP RR as a compound RTCP packet. 281 5. Protocol Operation 283 This section describes the behavior of the reporting (= receiver) 284 node and the media sender. 286 5.1. Reporting Node (Receiver) 288 Transmission of RTCP XR Discard RLE Reports is up to the discretion 289 of the receiver, as is the reporting granularity. However, it is 290 RECOMMENDED that the receiver signals all discarded packets using the 291 method defined in this document. If all packets over a reporting 292 period were lost, the receiver MAY use the Discard Report Block 293 [I-D.ietf-xrblock-rtcp-xr-discard] instead. In case of limited 294 available reporting bandwidth, it is up to the receiver whether or 295 not to include RTCP XR Discard RLE reports. 297 The receiver MAY send the Discard RLE Reports as part of the 298 regularly scheduled RTCP packets as per RFC3550. It MAY also include 299 Discard RLE Reports in immediate or early feedback packets as per 300 RFC4585. 302 5.2. Media Sender 304 The media sender MUST be prepared to operate without receiving any 305 Discard RLE reports. If Discard RLE reports are generated by the 306 receiver, the sender cannot rely on all these reports being received, 307 nor can the sender rely on a regular generation pattern from the 308 receiver side. 310 However, if the sender receives any RTCP reports but no Discard RLE 311 report blocks and is aware that the receiver supports Discard RLE 312 report blocks, it MAY assume that no packets were discarded at the 313 receiver. 315 The sender SHOULD accept the Bytes Discarded Report Block only if it 316 is received in a compound RTCP receiver report or if it is preceded 317 by a measurement identity block 318 [I-D.ietf-xrblock-rtcp-xr-meas-identity]. Under all other 319 circumstances it MUST ignore the block. 321 6. SDP signaling 323 The report blocks specified in this document define extensions to 324 RTCP XR reporting. Whether or not this specific extended report is 325 sent is left to the discretion of the receiver. Its presence may 326 enable better operation of the sender since more detailed information 327 is available. Not providing this information will make the sender 328 rely on other RTCP reports. 330 A participant of a media session MAY use SDP to signal its support 331 for this attribute. In this case, the RTCP XR attribute as defined 332 in RFC3611 [RFC3611] MUST be used. The SDP RFC4566 [RFC4566] 333 attribute 'xr-format' defined in RFC3611 is augmented as described in 334 the following to indicate the RLE discard metric and bytes discarded 335 metric. 337 rtcp-xr-attrib = "a=" "rtcp-xr" ":" [xr-format *(SP xr-format)] 338 CRLF ; defined in [RFC3611] 340 xr-format =/ xr-discard-rle 341 / xr-discard-bytes 343 xr-discard-rle = "discard-rle" 344 xr-discard-bytes = "discard-bytes" 346 The parameter 'discard-rle' MUST be used to indicate support for the 347 Discard RLE Report Block defined in Section 3, the parameter 348 'discard-bytes' to indicate support for the Bytes Discarded Report 349 Block defined in Section 4 351 For signaling support of the RLE discard metric and bytes discarded 352 metric, the rules defined in RFC3611 apply. Generally, senders and 353 receivers SHOULD indicate this capability if they support these 354 metrics and would like to use it in the specific media session being 355 signaled. The receiver MAY decide not to send discard information 356 unless it knows about the sender's support to save on RTCP reporting 357 bandwidth. 359 A participant in a media session MAY use the two report blocks 360 specified in this document without any explicit (SDP) signaling. 362 7. Security Considerations 364 The security considerations of RFC3550 [RFC3550], RFC3611 [RFC3611], 365 and RFC4585 [RFC4585] apply. Since this document offers only a more 366 precise reporting for an already existing metric, no further security 367 implications are foreseen. 369 8. IANA Considerations 371 New block types for RTCP XR are subject to IANA registration. For 372 general guidelines on IANA considerations for RTCP XR, refer to 373 RFC3611 [RFC3611]. 375 8.1. XR Report Block Registration 377 This document extends the IANA "RTCP XR Block Type Registry" by two 378 new values: DRLE and BDR. 380 [Note to RFC Editor: please replace DRLE and BDR with the IANA 381 provided RTCP XR block type for this block here and in the diagrams 382 above. Please remove this note prior to publication as an RFC.] 384 8.2. SDP Parameter Registration 386 This document registers two new parameters for the Session 387 Description Protocol (SDP), "discard-rle" and "discard-bytes", in the 388 "RTCP XR SDP Parameters Registry". 390 8.3. Contact information for IANA registrations 392 Joerg Ott (jo@comnet.tkk.fi) 394 Aalto University Comnet, Otakaari 5A, 02150 Espoo, Finland. 396 9. Acknowledgements 398 Thanks to Qin Wu, Colin Perkins, Dan Romascanu, and Roni Even for 399 providing valuable feedback on earlier versions of this draft 401 10. References 403 10.1. Normative References 405 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 406 Requirement Levels", BCP 14, RFC 2119, March 1997. 408 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 409 Jacobson, "RTP: A Transport Protocol for Real-Time 410 Applications", STD 64, RFC 3550, July 2003. 412 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 413 "Extended RTP Profile for Real-time Transport Control 414 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 415 July 2006. 417 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 418 Description Protocol", RFC 4566, July 2006. 420 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 421 Protocol Extended Reports (RTCP XR)", RFC 3611, 422 November 2003. 424 [I-D.ietf-xrblock-rtcp-xr-meas-identity] 425 Hunt, G., Clark, A., and W. Wu, "Measurement Identity and 426 information Reporting using SDES item and XR Block", 427 draft-ietf-xrblock-rtcp-xr-meas-identity-07 (work in 428 progress), January 2012. 430 [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New 431 Performance Metric Development", BCP 170, RFC 6390, 432 October 2011. 434 10.2. Informative References 436 [I-D.ietf-xrblock-rtcp-xr-discard] 437 Hunt, G., Clark, A., Zorn, G., and W. Wu, "RTCP XR Report 438 Block for Discard metric Reporting", 439 draft-ietf-xrblock-rtcp-xr-discard-04 (work in progress), 440 December 2011. 442 [I-D.ietf-xrblock-rtcp-xr-burst-gap-discard] 443 Hunt, G., Clark, A., Huang, R., and W. Wu, "RTCP XR Report 444 Block for Burst/Gap Discard metric Reporting", 445 draft-ietf-xrblock-rtcp-xr-burst-gap-discard-03 (work in 446 progress), October 2011. 448 Appendix A. Change Log 450 Note to the RFC-Editor: please remove this section prior to 451 publication as an RFC. 453 A.1. changes in draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-00 455 o Changed the interval flag from 1 to 2 bits in the discarded bytes 456 report. Also added the measurement identification tag to the 457 block. 458 o Added this section. 460 A.2. changes in draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-01 462 o Removed the measurement identification tag in the bytes discarded 463 block. 465 A.3. changes in draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-02 467 o Removed the extra Tag bits from the Discarded bytes XR block. 468 o Clarified use of measurement identity block in Section 4 and 5.2 470 A.4. changes in draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-03 472 o Added explanation for block length in bytes discarded block 473 o Added an acknowledgement section 475 A.5. changes in draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-04 477 o Added Block Type definition to each XRBlock 478 o Made changes requested in WGLC 480 Authors' Addresses 482 Joerg Ott 483 Aalto University 484 Otakaari 5 A 485 Espoo, FIN 02150 486 Finland 488 Email: jo@comnet.tkk.fi 489 Varun Singh 490 Aalto University 491 School of Science and Technology 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 1) 502 Tampere, FIN 33721 503 Finland 505 Email: igor.curcio@nokia.com