idnits 2.17.1 draft-gharai-avt-tfrc-profile-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 45 instances of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 47 has weird spacing: '...defines a pro...' == Line 84 has weird spacing: '... of the recom...' == Line 290 has weird spacing: '...may not resul...' == Line 380 has weird spacing: '...for the purpo...' -- 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 (8 February 2004) is 7382 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: '2434' is defined on line 336, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3448 (ref. 'TFRC') (Obsoleted by RFC 5348) Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force AVT WG 2 INTERNET-DRAFT Ladan Gharai 3 draft-gharai-avt-tfrc-profile-00.txt USC/ISI 4 8 February 2004 5 Expires: August 2004 7 RTP Profile for TCP Friendly Rate Control 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Copyright Notice 32 Copyright (C) The Internet Society (2003). All Rights Reserved. 34 Abstract 36 This memo specifies a profile called "RTP/AVPCC" for the use of the 37 real-time transport protocol (RTP) and its associated control 38 protocol, RTCP, with the TCP Friendly Rate Control (TFRC). TFRC is a 39 equation based congestion control scheme for unicast flows operating 40 in a best effort Internet environment. 42 1. Introduction 44 [Note to RFC Editor: All references to RFC XXXX are to be replaced 45 with the RFC number of this memo, when published] 47 This memo defines a profile called "RTP/AVPCC" for the use of the 48 real-time transport protocol (RTP) [RTP] and its associated control 49 protocol, RTCP, with the TCP Friendly Rate Control (TFRC) [TFRC]. 50 TFRC is a equation based congestion control scheme for unicast flows 51 operating in a best effort Internet environment and competing with 52 TCP traffic. 54 Due to a number of inherent TFRC characteristics, the AVPCC profile 55 differs from other RTP profiles in the following ways: 57 - TFRC is a unicast congestion control scheme, therefore by 58 extension the AVPCC profile can only be used by unicast RTP 59 flows. 61 - A TFRC sender relies on receiving feedback from the receiver at 62 least once per round-trip time (RTT) in order to adjust its send 63 rate. For certain flows (depending on RTTs and data rates) this 64 TFRC requirement can result in control traffic that exceeds RTP's 65 bandwidth recommendations for control traffic. 67 RTP restricts control traffic to a fixed fraction of session 68 bandwidth, so as to prevent RTCP feedback implosion in multicast 69 scenarios. As AVPCC can only be used by unicast flows, TFRCs 70 increased use of traffic does not effect scalability or cause 71 traffic implosion. 73 - TFRC is highly sensitive and dependent on accurate and current 74 computations of the RTT. The sender uses the RTT to compute 75 a TCP-friendly send rate, while the receiver needs the current 76 RTT to compute its loss event rate. Therefore it is imperative 77 that both the senders and receiver have access to a current and 78 accurate RTT measurements. 80 This memo primarily addresses the means of supporting TFRC's 81 exchange of information between senders and receivers via the 82 following modifications to RTP and RTCP: (1) RTP data header 83 additions; (2) extensions to the RTCP Receiver Reports; and (3) 84 relaxation of the recommended RTCP timing intervals. For details on 85 TFRC congestion control readers are referred to [TFRC]. 87 The current TFRC standard, RFC3448, only targets applications with 88 fixed packet size. TFRC-PS is a variant of TFRC for applications with 89 varying packet sizes. The AVPCC profile is applicable to both 90 congestion control schemes. 92 2. Conventions Used in this Document 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in RFC 2119 [2119]. 98 3. RTP and RTCP Packet Forms and Protocol Behavior 100 The section "RTP Profiles and Payload Format Specifications" of RFC 101 3550 enumerates a number of items that can be specified or modified 102 in a profile. This section addresses each of these items and states 103 which item is modified by the AVPCC profile: 105 RTP data header: The standard format of the fixed RTP data 106 header is used (one marker bit). 108 Payload types: This profile does not define new payload types, 109 and has no payload type restrictions. 111 RTP data header additions: Two 32bit additional fixed fields 112 are added to the RTP data header for the transport 113 of packet send time and the current RTT to the TFRC receiver. 115 RTP data header extensions: No RTP header extensions are 116 defined, but applications operating under this profile 117 MAY use such extensions. Thus, applications SHOULD NOT 118 assume that the RTP header X bit is always zero and SHOULD 119 be prepared to ignore the header extension. If a header 120 extension is defined in the future, that definition MUST 121 specify the contents of the first 16 bits in such a way 122 that multiple different extensions can be identified. 124 RTCP packet types: No additional RTCP packet types are defined 125 by this profile specification. 127 RTCP report interval: This profile is restricted to unicast 128 flows, therefore at all times there is only one active sender 129 and one receiver. Sessions operating under this profile MAY 130 specify a separate parameter for the RTCP traffic bandwidth 131 rather than using the default fraction of the session 132 bandwidth. In particular this may be necessary for data 133 flows were the the RTCP recommended reduced minimum interval 134 is still greater than the RTT. 136 SR/RR extension: A 16 octet RR extension is defined for the RTCP 137 RR packet. 139 SDES use: Applications MAY use any of the SDES items described 140 in the RTP specification. 142 Security: The RTP default security services are also the default 143 under this profile. 145 String-to-key mapping: No mapping is specified by this profile. 147 Congestion: This profile specifies how to use RTP/RTCP with TFRC 148 congestion control. 150 Underlying protocol: The profile specifies the use of RTP over 151 unicast UDP flows only. 153 Transport mapping: The standard mapping of RTP and RTCP to 154 transport-level addresses is used. 156 Encapsulation: This profile leaves to applications the 157 specification of RTP encapsulation in protocols other than UDP. 159 4. The TFRC Feedback Loop 161 TFRC depends on the exchange of information between a sender and 162 receiver. In this section we reiterate which items are exchanged 163 between a TFRC sender and receiver as discussed in [TFRC]. We note 164 how the AVPCC profile accommodates these exchanges. 166 4.1. Data Packets 168 As stated in [TFRC] a TFRC sender transmits the following information 169 in each data packet to the receiver: 171 o A sequence number, incremented by one for each data packet 172 transmitted. 174 o A timestamp indicating the packet send time. This timestamp 175 is used by the receiver to (1) compute the loss event rate 176 and (2) is returned to the sender for RTT computation. 178 The standard RTP header includes a 32 bit timestamp. For 179 real-time data this timestamp indicates the sampling 180 instance of the first octet of the packet. For stored media 181 it represents the presentation time of the packet. Packets 182 belonging to the same video frame/audio sample share the same 183 RTP timestamp value. 185 While it would be preferable to use the RTP timestamp for TFRC's 186 calculations, it can lead to incorrect RTT and loss event rate 187 calculations. For example ... 189 o The sender's current estimate of the round-trip time, RTT. 191 The standard RTP sequence number suffices for TFRCs functionality. 192 To transmit the send timestamp and the RTT to the receiver the AVPCC 193 profile extends the RTP data header by two 32bit fields in order to 194 accommodate their transmission (see Section 5). 196 4.2. Feedback Packets 198 As stated in [TFRC] a TFRC receiver provides the following feedback 199 to the sender at least once per RTT: 201 o The timestamp of the last data packet received. This is the 202 timestamp is used by the sender to estimate RTT and is only 203 needed if the sender does not save timestamps of transmitted 204 data packets. 206 o The amount of time elapsed between the receipt of the last 207 data packet at the receiver, and the generation of this feedback 208 report. This is used for estimation of the RTT. 210 o The rate at which the receiver estimates that data was received 211 since the last feedback report was sent. 213 o The receiver's current estimate of the loss event rate, p. 215 To accommodate the feedback of these values the AVPCC profile defines 216 a 16 octet extension to the RTCP Receiver Reports (see Section 6). 218 5. RTP Data Header Additions 219 0 1 2 3 220 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 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 |V=2|P|X| CC |M| PT | sequence number | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | timestamp | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | synchronization source (SSRC) identifier | 227 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 228 | timestamp (packet send time) | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | RTT | 231 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 232 | contributing source (CSRC) identifiers | 233 | .... | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 Figure 1: 237 6. Receiver Report Extensions 238 0 1 2 3 239 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 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 |V=2|P| RC | PT=RR=201 | length | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | SSRC of packet sender | 244 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 245 | SSRC (SSRC of first source) | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | fraction lost | cumulative number of packets lost | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | extended highest sequence number received | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | interarrival jitter | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | last SR (LSR) | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | delay since last SR (DLSR) | 256 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 257 | timestamp_i | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | t_delay | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | data rate at the receiver (x_recv) | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | loss event rate (p) | 264 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 265 Figure 2: 267 7. RTCP Timing Intervals 269 RFC3550 recommends that control traffic be limited to a small and 270 known fraction of the session bandwidth. Specifically it recommends 271 that the fraction of session bandwidth be added for RTCP be fixed at 272 5%. Based on this fixed bandwidth allotment and the number of senders 273 and receivers the interval between RTCP feedback packets is 274 calculated. 276 In addition to recommended restrictions on control traffic bandwidth, 277 RFC3550 also recommends an average minimum interval of 5 seconds 278 between sending RTCP packets, however this minimum interval can be 279 scaled to a reduced minimum. Computed in seconds of 360 divided by 280 session bandwidth in kilobits/second. 282 These restrictions on the fraction of control traffic bandwidth and 283 the frequency of feedback is to ensure scalability to large multicast 284 groups and prevent control traffic implosion. 286 The TFRC algorithm requires feedback from receivers at least once per 287 RTT. For data rates less than 5Mbps (depending on the RTT) this may 288 require transmitting RTCP packets at higher frequency than 289 recommended by the scaled minimum interval. This increased frequency 290 may or may not results in a control traffic in excess of 5% of the 291 session bandwidth. 293 The AVPCC profile defines the control traffic bandwidth as a separate 294 parameter of the session to accommodate TFRCs feedback requirements. 296 +--------------------------+----------+---------+-----------+------------+ 297 | Session Bandwidth (B) | 10 kbps | 72 kbps | 5000 kbps | 10000 kbps | 298 | Minimum Interval (360/B)| 36 sec | 5 sec | 72 msec | 36 msec | 299 | RTCP Bandwidth | - | - | ~7 kpbs | ~14 kpbs | 300 +--------------------------+----------+---------------------+------------+ 301 Figure 3: Session bandwidth and RTCP minimum intervals. RTCP bandwidth is 302 computed assuming compound packet sizes of 60bytes. 304 8. IANA Considerations 306 308 9. Security Considerations 310 312 10. Acknowledgments 314 This memo is based upon work supported by the U.S. National Science 315 Foundation (NSF) under Grant No. 0334182. Any opinions, findings and 316 conclusions or recommendations expressed in this material are those 317 of the authors and do not necessarily reflect the views of NSF. 319 11. Author's Address 320 Ladan Gharai 321 USC Information Sciences Institute 322 3811 N. Fairfax Drive, #200 323 Arlington, VA 22203 324 USA 326 Normative References 328 [RTP] H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, 329 "RTP: A Transport Protocol for Real-Time Applications", 330 Internet Engineering Task Force, RFC 3550, July 2003. 332 [2119] S. Bradner, "Key words for use in RFCs to Indicate 333 Requirement Levels", Internet Engineering Task Force, 334 RFC 2119, March 1997. 336 [2434] T. Narten and H. Alvestrand, "Guidelines for Writing an IANA 337 Considerations Section in RFCs", Internet Engineering Task 338 Force, RFC 2434, October 1998. 340 [TFRC] M. Handley, S. Floyed, J. Padhye and J. widmer, 341 "TCP Friendly Rate Control (TRFC): Protocol Specification", 342 Internet Engineering Task Force, RFC 3448, January 2003. 344 Informative References 346 12. IPR Notice 348 The IETF takes no position regarding the validity or scope of any 349 intellectual property or other rights that might be claimed to 350 pertain to the implementation or use of the technology described in 351 this document or the extent to which any license under such rights 352 might or might not be available; neither does it represent that it 353 has made any effort to identify any such rights. Information on the 354 IETF's procedures with respect to rights in standards-track and 355 standards-related documentation can be found in BCP-11. Copies of 356 claims of rights made available for publication and any assurances of 357 licenses to be made available, or the result of an attempt made to 358 obtain a general license or permission for the use of such 359 proprietary rights by implementors or users of this specification can 360 be obtained from the IETF Secretariat. 362 The IETF invites any interested party to bring to its attention any 363 copyrights, patents or patent applications, or other proprietary 364 rights which may cover technology that may be required to practice 365 this standard. Please address the information to the IETF Executive 366 Director. 368 13. Full Copyright Statement 370 Copyright (C) The Internet Society 2003. All Rights Reserved. 372 This document and translations of it may be copied and furnished to 373 others, and derivative works that comment on or otherwise explain it 374 or assist in its implementation may be prepared, copied, published 375 and distributed, in whole or in part, without restriction of any 376 kind, provided that the above copyright notice and this paragraph are 377 included on all such copies and derivative works. However, this 378 document itself may not be modified in any way, such as by removing 379 the copyright notice or references to the Internet Society or other 380 Internet organizations, except as needed for the purpose of 381 developing Internet standards in which case the procedures for 382 copyrights defined in the Internet Standards process must be 383 followed, or as required to translate it into languages other than 384 English. 386 The limited permissions granted above are perpetual and will not be 387 revoked by the Internet Society or its successors or assigns. 389 This document and the information contained herein is provided on an 390 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 391 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 392 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 393 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 394 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.