idnits 2.17.1 draft-ietf-avt-post-repair-rtcp-xr-03.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 326. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 337. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 344. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 350. 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 21, 2008) is 5638 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 24, 2009 Cisco Systems 6 October 21, 2008 8 Post-Repair Loss RLE Report Block Type for RTCP XR 9 draft-ietf-avt-post-repair-rtcp-xr-03 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 24, 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 . . . . . . . . . . . . 6 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 65 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 68 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 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 or a different RTCP XR report), which reflects the 98 packet receipt/loss events after all loss-repair methods are applied. 99 This report block, which we refer to as the Post-repair Loss RLE, 100 indicates the remaining missing, i.e., unrepairable, source packets. 101 When the pre-repair and post-repair Loss RLEs are compared, the RTP 102 sender or another third party entity can evaluate the effectiveness 103 of the loss-repair methods in an aggregated fashion. To avoid any 104 ambiguity in the evaluation, it is RECOMMENDED that the post-repair 105 Loss RLE is generated for the source packets that have no further 106 chance of being repaired. If the loss-repair method(s) may still 107 recover one or more missing source packets, the post-repair Loss RLE 108 SHOULD NOT be sent until the loss-recovery process has been 109 completed. 111 Similar to the pre-repair Loss RLE, the post-repair Loss RLE conveys 112 the receipt/loss events at the packet level and considers partially 113 repaired packets as unrepaired. Thus, methods that can do partially 114 recover the missing data SHOULD NOT be evaluated based on the 115 information provided by the Post-repair Loss RLE Reports. 117 Note that the idea of using pre-repair and post-repair Loss RLEs can 118 be further extended when multiple sequential loss-repair methods are 119 applied to the primary source stream. Reporting the Loss RLEs before 120 and after each loss-repair method can provide specific information 121 about the individual performances of these methods. However, it can 122 be a difficult task to quantify the specific contribution made by 123 each loss-repair method in hybrid systems, where different methods 124 collectively work together to repair the lost source packets. Thus, 125 in this specification we only consider reporting the Loss RLE after 126 all loss-repair methods are applied. 128 This document registers a new report block type to cover the post- 129 repair Loss RLE within the framework of RTCP XR. Applications that 130 are employing one or more loss-repair methods MAY use Post-repair 131 Loss RLE Reports for every packet they receive or for a set of 132 specific packets they have received. In other words, the coverage of 133 the post-repair Loss RLEs may or may not be contiguous. 135 2. Requirements Notation 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in [RFC2119]. 141 3. Post-Repair Loss RLE Report Block 143 The Post-repair Loss RLE Report Block is similar to the existing Loss 144 RLE Report Block defined in [RFC3611]. The report format is shown in 145 Figure 1. Using the same structure for reporting both pre-repair and 146 post-repair Loss RLEs allows the implementations to compare the Loss 147 RLEs very efficiently. 149 0 1 2 3 150 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 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | BT=10 | rsvd. | T | block length | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | SSRC of source | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | begin_seq | end_seq | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | chunk 1 | chunk 2 | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 : ... : 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | chunk n-1 | chunk n | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 Figure 1: Format for the post-repair loss RLE report block 167 o block type (BT): 8 bits 168 A Post-repair Loss RLE Report Block is identified by the constant 169 10. 171 o rsvd.: 4 bits 172 This field is reserved for future definition. In the absence of 173 such definition, the bits in this field MUST be set to zero and 174 MUST be ignored by the receiver. 176 o thinning (T): 4 bits 177 The amount of thinning performed on the sequence number space. 178 Only those packets with sequence numbers 0 mod 2^T are reported on 179 by this block. A value of 0 indicates that there is no thinning, 180 and all packets are reported on. The maximum thinning is one 181 packet in every 32,768 (amounting to two packets within each 16- 182 bit sequence space). 184 o block length: 16 bits 185 The length of this report block, including the header, in 32-bit 186 words minus one. 188 o SSRC of source: 32 bits 190 The SSRC of the RTP data packet source being reported upon by this 191 report block. 193 o begin_seq: 16 bits 195 The first sequence number that this block reports on. 197 o end_seq: 16 bits 199 The last sequence number that this block reports on plus one. 201 o chunk i: 16 bits 202 There are three chunk types: run length, bit vector, and 203 terminating null, defined in [RFC3611] (Section 4). If the chunk 204 is all zeroes, then it is a terminating null chunk. Otherwise, 205 the left most bit of the chunk determines its type: 0 for run 206 length and 1 for bit vector. 208 Note that the sequence numbers that are included in the report refer 209 to the primary source stream. 211 4. Session Description Protocol Signaling 213 A new parameter is defined for the Post-repair Loss RLE Report Block 214 to be used with Session Description Protocol (SDP) [RFC4566]. It has 215 the following syntax within the "rtcp-xr" attribute: 217 rtcp-xr-attrib = "a=rtcp-xr:" [xr-format *(SP xr-format)] CRLF 219 xr-format = "post-repair-loss-rle" ["=" max-size] 221 max-size = 1*DIGIT ; maximum block size in octets 222 DIGIT = %x30-39 223 CRLF = %d13.10 225 Figure 2 227 Refer to Section 5.1 of [RFC3611] for a detailed description and the 228 full syntax of the "rtcp-xr" attribute. 230 5. Security Considerations 232 The security considerations of [RFC3611] apply in this document as 233 well. 235 6. IANA Considerations 237 New block types for RTCP XR are subject to IANA registration. For 238 general guidelines on IANA considerations for RTCP XR, refer to 239 [RFC3611]. 241 This document assigns the block type value 10 in the RTCP XR Block 242 Type Registry to "Post-repair Loss RLE Report Block." This document 243 also registers the SDP [RFC4566] parameter "post-repair-loss-rle" for 244 the "rtcp-xr" attribute in the RTCP XR SDP Parameters Registry. 246 The contact information for the registrations is: 248 Ali Begen 249 abegen@cisco.com 251 170 West Tasman Drive 252 San Jose, CA 95134 USA 254 7. Acknowledgments 256 The authors would like to thank the members of the VQE Team at Cisco 257 and Colin Perkins for their inputs and suggestions. 259 8. References 261 8.1. Normative References 263 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 264 Requirement Levels", BCP 14, RFC 2119, March 1997. 266 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 267 Jacobson, "RTP: A Transport Protocol for Real-Time 268 Applications", STD 64, RFC 3550, July 2003. 270 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 271 Protocol Extended Reports (RTCP XR)", RFC 3611, 272 November 2003. 274 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 275 Description Protocol", RFC 4566, July 2006. 277 8.2. Informative References 279 [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error 280 Correction", RFC 5109, December 2007. 282 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 283 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 284 July 2006. 286 Authors' Addresses 288 Ali Begen 289 Cisco Systems 290 170 West Tasman Drive 291 San Jose, CA 95134 292 USA 294 Email: abegen@cisco.com 296 Dong Hsu 297 Cisco Systems 298 1414 Massachusetts Ave. 299 Boxborough, MA 01719 300 USA 302 Email: dohsu@cisco.com 304 Michael Lague 305 Cisco Systems 306 1414 Massachusetts Ave. 307 Boxborough, MA 01719 308 USA 310 Email: mlague@cisco.com 312 Full Copyright Statement 314 Copyright (C) The IETF Trust (2008). 316 This document is subject to the rights, licenses and restrictions 317 contained in BCP 78, and except as set forth therein, the authors 318 retain all their rights. 320 This document and the information contained herein are provided on an 321 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 322 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 323 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 324 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 325 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 326 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 328 Intellectual Property 330 The IETF takes no position regarding the validity or scope of any 331 Intellectual Property Rights or other rights that might be claimed to 332 pertain to the implementation or use of the technology described in 333 this document or the extent to which any license under such rights 334 might or might not be available; nor does it represent that it has 335 made any independent effort to identify any such rights. Information 336 on the procedures with respect to rights in RFC documents can be 337 found in BCP 78 and BCP 79. 339 Copies of IPR disclosures made to the IETF Secretariat and any 340 assurances of licenses to be made available, or the result of an 341 attempt made to obtain a general license or permission for the use of 342 such proprietary rights by implementers or users of this 343 specification can be obtained from the IETF on-line IPR repository at 344 http://www.ietf.org/ipr. 346 The IETF invites any interested party to bring to its attention any 347 copyrights, patents or patent applications, or other proprietary 348 rights that may cover technology that may be required to implement 349 this standard. Please address the information to the IETF at 350 ietf-ipr@ietf.org. 352 Acknowledgment 354 Funding for the RFC Editor function is provided by the IETF 355 Administrative Support Activity (IASA).