idnits 2.17.1 draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-00.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 (November 20, 2011) is 4540 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) == Unused Reference: 'RFC3551' is defined on line 359, but no explicit reference was found in the text == Unused Reference: 'RFC5760' is defined on line 375, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-15) exists of draft-ietf-xrblock-rtcp-xr-discard-00 == Outdated reference: A later version (-14) exists of draft-ietf-xrblock-rtcp-xr-burst-gap-discard-00 Summary: 1 error (**), 0 flaws (~~), 5 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: May 23, 2012 I. Curcio 6 Nokia Research Center 7 November 20, 2011 9 Real-time Transport Control Protocol (RTCP) Extension Report (XR) for 10 Run Length Encoding of Discarded Packets 11 draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-00.txt 13 Abstract 15 The Real-time Transport Control Protocol (RTCP) is used in 16 conjunction with the Real-time Transport Protocol (RTP) in to provide 17 a variety of short-term and long-term reception statistics. The 18 available reporting may include aggregate information across longer 19 periods of time as well as individual packet reporting. This 20 document specifies a per-packet report metric capturing individual 21 packets discarded from the jitter 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 May 23, 2012. 40 Copyright Notice 42 Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . 9 69 8.3. Contact information for IANA registrations . . . . . . . . 9 70 9. Normative References . . . . . . . . . . . . . . . . . . . . . 9 71 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 10 72 A.1. changes in 73 draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-00 . . . . 10 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 76 1. Introduction 78 RTP [RFC3550] provides a transport for real-time media flows such as 79 audio and video together with the RTP control protocol which provides 80 periodic feedback about the media streams received in a specific 81 duration. In addition, RTCP can be used for timely feedback about 82 individual events to report (e.g., packet loss) [RFC4585]. Both 83 long-term and short-term feedback enable a sender to adapt its media 84 transmission and/or encoding dynamically to the observed path 85 characteristics. 87 RFC3611 [RFC3611] defines RTCP eXtension Reports as a detailed 88 reporting framework to provide more than just the coarse RR 89 statistics. The detailed reporting may enable a sender to react more 90 appropriately to the observed networking conditions as these can be 91 characterized better, albeit at the expense of extra overhead. 93 Among many other fields, RFC3611 specifies the Loss RLE block which 94 define runs of packets received and lost with the granularity of 95 individual packets. This can help both error recovery and path loss 96 characterization. In addition to lost packets, RFC3611 defines the 97 notion of "discarded" packets: packets that were received but dropped 98 from the jitter buffer because they were either too early (for 99 buffering) or too late (for playout). This metric is part of the 100 VoIP metrics report block even though it is not just applicable to 101 audio: it is specified as the fraction of discarded packets since the 102 beginning of the session. See section 4.7.1 of RFC3611 [RFC3611]. 104 Recently proposed extensions to the XR reporting suggest enhancing 105 this discard metric: 106 o Reporting the number of discarded packets during either the last 107 reporting interval or since the beginning of the session, as 108 indicated by a flag in the suggested XR report 109 [I-D.ietf-xrblock-rtcp-xr-discard]. 110 o Reporting gaps and bursts of discarded packets during the last 111 reporting interval or cumulatively since the beginning of the 112 session [I-D.ietf-xrblock-rtcp-xr-burst-gap-discard]. 114 However, none of these metrics allow a receiver to report precisely 115 which packets were discarded. While this information could in theory 116 be derived from high-frequency reporting on the number of discarded 117 packets or from the gap/burst report, these two mechanisms do not 118 appear feasible: The former would require an unduly high amount of 119 reporting which still might not be sufficient due to the non- 120 deterministic scheduling of RTCP packets. The latter incur 121 significant complexity and reporting overhead and might still not 122 deliver the desired accuracy. 124 This document defines a discard report block following the idea of 125 the run-length encoding applied for lost and received packets in 126 RFC3611 [RFC3611]. 128 Complementary to or instead of the indication which packets were 129 lost, an XR block is defined to indicate the number of bytes lost, 130 per interval or for the duration of the session, similar to other XR 131 report blocks. 133 2. Terminology 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in BCP 14, RFC 2119 138 [RFC2119] and indicate requirement levels for compliant 139 implementations. 141 The terminology defined in RTP [RFC3550] and in the extensions for XR 142 reporting [RFC3611] applies. 144 3. XR Discard RLE Report Block 146 The XR Discard RLE report block uses the same format as specified for 147 the loss and duplicate report blocks in RFC3611 [RFC3611]. Figure 148 Figure 1 recaps the packet format. The fields "BT", "T", "block 149 length", "SSRC of source", "begin_seq", and "end_seq" SHALL have the 150 same semantics and representation as defined in RFC3611. The 151 "chunks" encoding the run length SHALL have the same representation 152 as in RFC3611, but encode discarded packets. 154 0 1 2 3 155 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 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | BT=DRLE |rsvd |E| T | block length | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | SSRC of source | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | begin_seq | end_seq | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | chunk 1 | chunk 2 | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 : ... : 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | chunk n-1 | chunk n | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 Figure 1: XR Discard Report Block 172 The 'E' bit is introduced to distinguish between packets discarded 173 due to early arrival and those discarded due to late arrival. The 174 'E' bit MUST be set to '1' if the chunks represent packets discarded 175 due to too early arrival and MUST be set to '0' otherwise. 177 In case both early and late discarded packets shall be reported, two 178 Discard RLE report blocks MUST be included; their sequence number 179 range MAY overlap, but individual packets MUST only be reported as 180 either early or late. Packets reported in both MUST be considered as 181 discarded without further information available, packets reported in 182 neither are considered to be properly received and not discarded. 184 Discard RLE Report Blocks SHOULD be sent in conjunction with an RTCP 185 RR as a compound RTCP packet. 187 Editor's node: is it acceptable to use one of the 'reserved' bits for 188 this purpose or should two block types be used? 190 4. XR Bytes Discarded Report Block 192 The XR Bytes Discarded report block uses the following format which 193 follows the model of the framework for performance metric development 194 [RFC6390]. 196 0 1 2 3 197 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 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | BT=BDR | I | Tag |E|res| block length=2 | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | SSRC of source | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | number of bytes discarded | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 Figure 2: XR Bytes Discarded Report Block 208 The Interval Metric flag (I) (2 bits) is used to indicate whether the 209 Post-Repair Loss metric is Sampled, Interval, or a Cumulative metric, 210 that is, whether the reported value applies to the most recent 211 measurement interval duration between successive reports (I=10, the 212 Interval Duration) or to the accumulation period characteristic of 213 cumulative measurements (I=11, the Cumulative Duration) or is a 214 sampled value (I=01). Numerical values for sampled duration are 215 provided in the Measurement Identifier block referenced by the tag 216 field below. 218 Measurement Identifier association (Tag) 3 bits: This field is used 219 to identify the Measurement Identifier block which describes the 220 sampled measurement. The tag in the corresponding Measurement 221 Identifier block has the same tag value. Note that there may be more 222 than one Measurement Identifier block per RTCP packet. The tag MUST 223 be set to 0 when using cumulative or interval durations. 225 The 'E' bit is introduced to distinguish between packets discarded 226 due to early arrival and those discarded due to late arrival. The 227 'E' bit MUST be set to '1' if the chunks represent packets discarded 228 due to too early arrival and MUST be set to '0' otherwise. In case 229 both early and late discarded packets shall be reported, two Bytes 230 Discarded report blocks MUST be included. 232 The 'number of bytes discarded' is a 32-bit unsigned integer value 233 indicating the total number of bytes discarded (I=0) or the number of 234 bytes discarded since the last RTCP XR Bytes Discarded block was 235 sent. 237 Bytes Discarded Report Blocks SHOULD be sent in conjunction with an 238 RTCP RR as a compound RTCP packet. 240 Editor's note: is it acceptable to use one of the 'reserved' bits for 241 this purpose or should two block types be used? 243 5. Protocol Operation 245 This section describes the behavior of the reporting (= receiver) RTP 246 node and the sender RTP node. 248 5.1. Reporting Node (Receiver) 250 Transmission of RTCP XR Discard RLE Reports is up to the discretion 251 of the receiver, as is the reporting granularity. However, it is 252 RECOMMENDED that the receiver signals all discarded packets using the 253 method defined in this document. If all packets over a reporting 254 period were lost, the receiver MAY use the Discard Report Block 255 [I-D.ietf-xrblock-rtcp-xr-discard] instead. In case of limited 256 available reporting bandwidth, it is up to the receiver whether or 257 not to include RTCP XR Discard RLE reports or not. 259 The receiver MAY send the Discard RLE Reports as part of the 260 regularly scheduled RTCP packets as per RFC3550. It MAY also include 261 Discard RLE Reports in immediate or early feedback packets as per 262 RFC4585. 264 5.2. Media Sender 266 The media sender MUST be prepared to operate without receiving any 267 Discard RLE reports. If Discard RLE reports are generated by the 268 receiver, the sender cannot rely on all these reports being received, 269 nor can the sender rely on a regular generation pattern from the 270 receiver side. 272 However, if the sender receives any RTCP reports but no Discard RLE 273 report blocks and is aware that the receiver supports Discard RLE 274 report blocks, it MAY assume that no packets were discarded at the 275 receiver. 277 6. SDP signaling 279 The report blocks specified in this document define extensions to 280 RTCP XR reporting. Whether or not this specific extended report is 281 sent is left to the discretion of the receiver. Its presence may 282 enable better operation of the sender since more detailed information 283 is available. Not providing this information will make the sender 284 rely on other RTCP report metrics. 286 A participant of a media session MAY use SDP to signal its support 287 for this attribute. In this case, the RTCP XR attribute as defined 288 in RFC3611 [RFC3611] MUST be used. The SDP RFC4566 [RFC4566] 289 attribute 'xr-format' defined in RFC3611 is augmented as described in 290 the following to indicate the discard metric. 292 rtcp-xr-attrib = "a=" "rtcp-xr" ":" [xr-format *(SP xr-format)] 293 CRLF ; defined in [RFC3611] 295 xr-format =/ xr-discard-rle 296 / xr-discard-bytes 298 xr-discard-rle = "discard-rle" 299 xr-discard-bytes = "discard-bytes" 301 The literal 'discard-rle' MUST be used to indicate support for the 302 Discard RLE Report Block defined in section Section 3, the literal 303 'discard-bytes' to indicate support for the Bytes Discarded Report 304 Block defined in section Section 4 306 For signaling support for the discard metric, the rules defined in 307 RFC3611 apply. Generally, senders and receivers SHOULD indicate this 308 capability if they support this metric and would like to use it in 309 the specific media session being signaled. The receiver MAY decide 310 not to send discard information unless it knows about the sender's 311 support to save on RTCP reporting bandwidth. 313 A participant in a media session MAY use the two report blocks 314 specified in this document without any explicit (SDP) signaling. 316 7. Security Considerations 318 The security considerations of RFC3550 [RFC3550], RFC3611 [RFC3611], 319 and RFC4585 [RFC4585] apply. Since this document offers only a more 320 precise reporting for an already existing metric, no further security 321 implications are foreseen. 323 8. IANA Considerations 325 New block types for RTCP XR are subject to IANA registration. For 326 general guidelines on IANA considerations for RTCP XR, refer to 327 RFC3611 [RFC3611]. 329 8.1. XR Report Block Registration 331 This document extends the IANA "RTCP XR Block Type Registry" by two 332 new values: DRLE and BDR. 334 [Note to RFC Editor: please replace DRLE and BDR with the IANA 335 provided RTCP XR block type for this block here and in the diagrams 336 above.] 338 8.2. SDP Parameter Registration 340 This document registers two new parameters for the Session 341 Description Protocol (SDP), "discard-rle" and "discard-bytes", in the 342 "RTCP XR SDP Parameters Registry". 344 8.3. Contact information for IANA registrations 346 Joerg Ott (jo@comnet.tkk.fi) 348 Aalto University Comnet, Otakaari 5A, 02150 Espoo, Finland. 350 9. Normative References 352 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 353 Requirement Levels", BCP 14, RFC 2119, March 1997. 355 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 356 Jacobson, "RTP: A Transport Protocol for Real-Time 357 Applications", STD 64, RFC 3550, July 2003. 359 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 360 Video Conferences with Minimal Control", STD 65, RFC 3551, 361 July 2003. 363 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 364 "Extended RTP Profile for Real-time Transport Control 365 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 366 July 2006. 368 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 369 Description Protocol", RFC 4566, July 2006. 371 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 372 Protocol Extended Reports (RTCP XR)", RFC 3611, 373 November 2003. 375 [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control 376 Protocol (RTCP) Extensions for Single-Source Multicast 377 Sessions with Unicast Feedback", RFC 5760, February 2010. 379 [I-D.ietf-xrblock-rtcp-xr-discard] 380 Hunt, G., Clark, A., Zorn, G., and W. Wu, "RTCP XR Report 381 Block for Discard metric Reporting", 382 draft-ietf-xrblock-rtcp-xr-discard-00 (work in progress), 383 October 2011. 385 [I-D.ietf-xrblock-rtcp-xr-burst-gap-discard] 386 Hunt, G., Clark, A., Huang, R., and W. Wu, "RTCP XR Report 387 Block for Burst/Gap Discard metric Reporting", 388 draft-ietf-xrblock-rtcp-xr-burst-gap-discard-00 (work in 389 progress), October 2011. 391 [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New 392 Performance Metric Development", BCP 170, RFC 6390, 393 October 2011. 395 Appendix A. Change Log 397 Note to the RFC-Editor: please remove this section prior to 398 publication as an RFC. 400 A.1. changes in draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-00 402 o Changed the interval flag from 1 to 2 bits in the discarded bytes 403 report. Also added the measurement identification tag to the 404 block. 405 o Added this section. 407 Authors' Addresses 409 Joerg Ott 410 Aalto University 411 Otakaari 5 A 412 Espoo, FIN 02150 413 Finland 415 Email: jo@comnet.tkk.fi 417 Varun Singh 418 Aalto University 419 School of Science and Technology 420 Otakaari 5 A 421 Espoo, FIN 02150 422 Finland 424 Email: varun@comnet.tkk.fi 425 URI: http://www.netlab.tkk.fi/~varun/ 426 Igor D.D. Curcio 427 Nokia Research Center 428 P.O. Box 1000 (Visiokatu 1) 429 Tampere, FIN 33721 430 Finland 432 Email: igor.curcio@nokia.com