idnits 2.17.1 draft-ietf-avt-post-repair-rtcp-xr-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 318. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 329. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 336. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 342. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 17, 2008) is 5668 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: 2 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVT A. Begen 3 Internet-Draft D. Hsu 4 Intended status: Standards Track M. Lague 5 Expires: April 20, 2009 Cisco Systems 6 October 17, 2008 8 Post-Repair Loss RLE Report Block Type for RTCP XR 9 draft-ietf-avt-post-repair-rtcp-xr-02 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 20, 2009. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 This document defines a new report block type within the framework of 43 RTP Control Protocol (RTCP) Extended Reports (XR). One of the 44 initial XR report block types is the Loss Run Length Encoding (RLE) 45 Report Block. This report conveys the information regarding the 46 individual Real-time Transport Protocol (RTP) packet receipt and loss 47 events experienced during the RTCP interval preceding the 48 transmission of the report. The new report, which is referred to as 49 the Post-repair Loss RLE Report, carries the information regarding 50 the remaining lost packets after all loss-repair methods are applied. 51 By comparing the RTP packet receipts/losses before and after the loss 52 repair is completed, one can determine the effectiveness of the loss- 53 repair methods in an aggregated fashion. This document also defines 54 the signaling of the Post-repair Loss RLE Report in the Session 55 Description Protocol (SDP). 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . . 4 61 3. Post-Repair Loss RLE Report Block . . . . . . . . . . . . . . . 4 62 4. Session Description Protocol Signaling . . . . . . . . . . . . 5 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 65 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 68 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 70 Intellectual Property and Copyright Statements . . . . . . . . . . 9 72 1. Introduction 74 RTP Control Protocol (RTCP) is the out-of-band control protocol for 75 the applications that are using the Real-time Transport Protocol 76 (RTP) for media delivery and communications [RFC3550]. RTCP allows 77 the RTP entities to monitor the data delivery and provides them 78 minimal control functionality via sender and receiver reports as well 79 as other control packets. [RFC3611] expands the RTCP functionality 80 further by introducing the RTCP Extended Reports (XR). 82 One of the initial XR report block types defined in [RFC3611] is the 83 Loss Run Length Encoding (RLE) Report Block. This report conveys the 84 information regarding the individual RTP packet receipt and loss 85 events experienced during the RTCP interval preceding the 86 transmission of the report. However, the Loss RLE in an RTCP XR 87 report is usually collected only on the primary source stream before 88 any loss-repair method is applied. Once one or more loss-repair 89 methods, e.g., Forward Error Correction (FEC) [RFC5109] and/or 90 retransmission [RFC4588], are applied, some or all of the lost 91 packets on the primary source stream may be recovered. However, the 92 pre-repair Loss RLE cannot indicate which source packets were 93 recovered and which are still missing. Thus, the pre-repair Loss RLE 94 cannot specify how well the loss repair performed. 96 This issue can be addressed by generating an additional report block 97 (within the same RTCP XR report), which reflects the packet receipt/ 98 loss events after all loss-repair methods are applied. This report 99 block, which we refer to as the Post-repair Loss RLE, indicates the 100 remaining missing, i.e., unrepairable, source packets. When the pre- 101 repair and post-repair Loss RLEs are compared, the RTP sender or 102 another third party entity can evaluate the effectiveness of the 103 loss-repair methods (at the packet level) in an aggregated fashion. 104 To avoid any ambiguity in the evaluation, it is RECOMMENDED that the 105 post-repair Loss RLE is generated for the source packets that have no 106 further chance of being repaired. If the loss-repair method(s) may 107 still recover one or more missing source packets, the post-repair 108 Loss RLE SHOULD NOT be sent until the loss-recovery process has been 109 completed. 111 Note that the idea of using pre-repair and post-repair Loss RLEs can 112 be further extended when multiple sequential loss-repair methods are 113 applied to the primary source stream. Reporting the Loss RLEs before 114 and after each loss-repair method can provide specific information 115 about the individual performances of these methods. However, it can 116 be a difficult task to quantify the specific contribution made by 117 each loss-repair method in hybrid systems, where different methods 118 collectively work together to repair the lost source packets. Thus, 119 in this specification we only consider reporting the Loss RLE after 120 all loss-repair methods are applied. 122 This document registers a new report block type to cover the post- 123 repair Loss RLE within the framework of RTCP XR. Applications that 124 are employing one or more loss-repair methods MAY use Post-repair 125 Loss RLE Reports for every packet they receive or for a set of 126 specific packets they have received. In other words, the coverage of 127 the post-repair Loss RLEs may or may not be contiguous. 129 2. Requirements Notation 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in [RFC2119]. 135 3. Post-Repair Loss RLE Report Block 137 The Post-repair Loss RLE Report Block is similar to the existing Loss 138 RLE Report Block defined in [RFC3611]. The report format is shown in 139 Figure 1. Using the same structure for reporting both pre-repair and 140 post-repair Loss RLEs allows the implementations to compare the Loss 141 RLEs very efficiently. 143 0 1 2 3 144 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | BT=10 | rsvd. | T | block length | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | SSRC of source | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | begin_seq | end_seq | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | chunk 1 | chunk 2 | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 : ... : 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | chunk n-1 | chunk n | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 Figure 1: Format for the post-repair loss RLE report block 161 o block type (BT): 8 bits 162 A Post-repair Loss RLE Report Block is identified by the constant 163 10. 165 o rsvd.: 4 bits 166 This field is reserved for future definition. In the absence of 167 such definition, the bits in this field MUST be set to zero and 168 MUST be ignored by the receiver. 170 o thinning (T): 4 bits 171 The amount of thinning performed on the sequence number space. 172 Only those packets with sequence numbers 0 mod 2^T are reported on 173 by this block. A value of 0 indicates that there is no thinning, 174 and all packets are reported on. The maximum thinning is one 175 packet in every 32,768 (amounting to two packets within each 16- 176 bit sequence space). 178 o block length: 16 bits 179 The length of this report block, including the header, in 32-bit 180 words minus one. 182 o SSRC of source: 32 bits 184 The SSRC of the RTP data packet source being reported upon by this 185 report block. 187 o begin_seq: 16 bits 189 The first sequence number that this block reports on. 191 o end_seq: 16 bits 193 The last sequence number that this block reports on plus one. 195 o chunk i: 16 bits 196 There are three chunk types: run length, bit vector, and 197 terminating null, defined in [RFC3611] (Section 4). If the chunk 198 is all zeroes, then it is a terminating null chunk. Otherwise, 199 the left most bit of the chunk determines its type: 0 for run 200 length and 1 for bit vector. 202 Note that the sequence numbers that are included in the report refer 203 to the primary source stream. 205 4. Session Description Protocol Signaling 207 A new parameter is defined for the Post-repair Loss RLE Report Block 208 to be used with Session Description Protocol (SDP) [RFC4566]. It has 209 the following syntax within the "rtcp-xr" attribute: 211 rtcp-xr-attrib = "a=rtcp-xr:" [xr-format *(SP xr-format)] CRLF 213 xr-format = "post-repair-loss-rle" ["=" max-size] 215 max-size = 1*DIGIT ; maximum block size in octets 216 DIGIT = %x30-39 217 CRLF = %d13.10 219 Figure 2 221 Refer to Section 5.1 of [RFC3611] for a detailed description and the 222 full syntax of the "rtcp-xr" attribute. 224 5. Security Considerations 226 The security considerations of [RFC3611] apply in this document as 227 well. 229 6. IANA Considerations 231 New block types for RTCP XR are subject to IANA registration. For 232 general guidelines on IANA considerations for RTCP XR, refer to 233 [RFC3611]. 235 This document assigns the block type value 10 in the RTCP XR Block 236 Type Registry to "Post-repair Loss RLE Report Block." This document 237 also registers the SDP [RFC4566] parameter "post-repair-loss-rle" for 238 the "rtcp-xr" attribute in the RTCP XR SDP Parameters Registry. 240 The contact information for the registrations is: 242 Ali Begen 243 abegen@cisco.com 245 170 West Tasman Drive 246 San Jose, CA 95134 USA 248 7. Acknowledgments 250 The authors would like to thank the members of the VQE Team at Cisco 251 and Colin Perkins for their inputs and suggestions. 253 8. References 254 8.1. Normative References 256 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 257 Requirement Levels", BCP 14, RFC 2119, March 1997. 259 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 260 Jacobson, "RTP: A Transport Protocol for Real-Time 261 Applications", STD 64, RFC 3550, July 2003. 263 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 264 Protocol Extended Reports (RTCP XR)", RFC 3611, 265 November 2003. 267 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 268 Description Protocol", RFC 4566, July 2006. 270 8.2. Informative References 272 [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error 273 Correction", RFC 5109, December 2007. 275 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 276 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 277 July 2006. 279 Authors' Addresses 281 Ali Begen 282 Cisco Systems 283 170 West Tasman Drive 284 San Jose, CA 95134 285 USA 287 Email: abegen@cisco.com 289 Dong Hsu 290 Cisco Systems 291 1414 Massachusetts Ave. 292 Boxborough, MA 01719 293 USA 295 Email: dohsu@cisco.com 296 Michael Lague 297 Cisco Systems 298 1414 Massachusetts Ave. 299 Boxborough, MA 01719 300 USA 302 Email: mlague@cisco.com 304 Full Copyright Statement 306 Copyright (C) The IETF Trust (2008). 308 This document is subject to the rights, licenses and restrictions 309 contained in BCP 78, and except as set forth therein, the authors 310 retain all their rights. 312 This document and the information contained herein are provided on an 313 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 314 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 315 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 316 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 317 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 318 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 320 Intellectual Property 322 The IETF takes no position regarding the validity or scope of any 323 Intellectual Property Rights or other rights that might be claimed to 324 pertain to the implementation or use of the technology described in 325 this document or the extent to which any license under such rights 326 might or might not be available; nor does it represent that it has 327 made any independent effort to identify any such rights. Information 328 on the procedures with respect to rights in RFC documents can be 329 found in BCP 78 and BCP 79. 331 Copies of IPR disclosures made to the IETF Secretariat and any 332 assurances of licenses to be made available, or the result of an 333 attempt made to obtain a general license or permission for the use of 334 such proprietary rights by implementers or users of this 335 specification can be obtained from the IETF on-line IPR repository at 336 http://www.ietf.org/ipr. 338 The IETF invites any interested party to bring to its attention any 339 copyrights, patents or patent applications, or other proprietary 340 rights that may cover technology that may be required to implement 341 this standard. Please address the information to the IETF at 342 ietf-ipr@ietf.org. 344 Acknowledgment 346 Funding for the RFC Editor function is provided by the IETF 347 Administrative Support Activity (IASA).