idnits 2.17.1 draft-ietf-avt-tfrc-profile-07.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 14. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 420. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 427. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 433. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1, updated by RFC 4748 (on line 437), which is fine, but *also* found old RFC 3978, Section 5.4, paragraph 1 text on line 33. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 230 has weird spacing: '... to the recei...' -- 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 (1 March 2007) is 6265 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: 'AVP' is defined on line 375, but no explicit reference was found in the text == Unused Reference: '2434' is defined on line 387, but no explicit reference was found in the text == Unused Reference: 'SDP' is defined on line 395, 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) ** Obsolete normative reference: RFC 2327 (ref. 'SDP') (Obsoleted by RFC 4566) == Outdated reference: A later version (-12) exists of draft-ietf-avt-profile-savpf-09 Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 6 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-ietf-avt-tfrc-profile-07.txt USC/ISI 4 1 March 2007 5 Expires: September 2007 7 RTP with TCP Friendly Rate Control 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Copyright Notice 33 Copyright (C) The Internet Society (2007). 35 Abstract 37 This memo specifies how the TCP Friendly Rate Control (TFRC) of RTP 38 flows can be supported using the RTP/AVPF profile and the general RTP 39 header extension mechanism. AVPF feedback packets and RTP header 40 extensions are defined to support the exchange of control information 41 between RTP TFRC senders and receivers. TFRC is an equation based 42 congestion control scheme for unicast flows operating in a best 43 effort Internet environment. 45 1. Introduction 47 [Note to RFC Editor: All references to RFC XXXX are to be replaced 48 with the RFC number of this memo, when published] 50 This memo specifies how the TCP Friendly Rate Control (TFRC) of RTP 51 flows can be supported using the RTP/AVPF profile and RTP header 52 extensions, by defining the header extensions to be used and a new 53 AVPF feedback packet. 55 TFRC is an equation based congestion control scheme for unicast flows 56 operating in a best effort Internet environment and competing with 57 TCP traffic. TFRC computes a TCP-friendly data rate based on current 58 network conditions, as represented by the latest round trip time and 59 packet loss calculations. The complete TFRC mechanism is described in 60 detail in [TFRC]. 62 To calculate a TCP-friendly data rate and keep track of round trip 63 times and packet losses, TFRC senders and receivers rely on 64 exchanging specific information between each other, i.e: the sender 65 provides the receiver with the latest updates to round trip time 66 calculations, while the receiver provides feedback needed to compute 67 round trip times and on packet losses. This memo defines how this 68 information can be exchanged between TFRC senders and receiver with 69 RTP header extensions and an AVPF feedback packet. 71 2. Terminology 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in RFC 2119 [2119]. 77 3. Relation to the Datagram Congestion Control Protocol 79 The TFRC congestion control mechanism is also supported by the 80 Datagram Congestion Control Protocol (DCCP). In this section we 81 detail the pros and cons of using TFRC with RTP versus DCCP. 83 DCCP is a minimal general purpose transport-layer protocol with 84 unreliable yet congestion controlled packet delivery semantics and 85 reliable connection setup and teardown. DCCP currently supports both 86 TFRC and TCP-like congestion control, and the protocol is structured 87 to support new congestion control mechanisms defined in the future. 88 In addition DCCP supports a host of other features, such as: use of 89 Explicit Congestion Notification (ECN) and the ECN Nonce, reliable 90 option negotiation and Path Maximum Transfer Unit (PMTU). Naturally 91 an application using RTP/DCCP as its transport protocol will benefit 92 from the protocol features supported by DCCP. 94 However there are a number of benefits to be gained by the 95 development and standardization of the use RTP with TFRC: 97 o Media applications lacking congestion control can incorporate 98 congestion controlled transport without delay by using RTP with 99 TFRC. The DCCP protocol is currently under development and 100 widespread deployment is not yet in place. 102 o Use of the RTP with TFRC is not contingent on any OS level 103 changes and can be quickly deployed, as RTP is implemented 104 at the application layer. 106 o RTP/UDP flows face the same restrictions in firewall traversal 107 as do UDP flows and do not require NATs and firewall 108 modifications. DCCP flows, on the other hand, do require NAT 109 and firewall modifications, however once these modifications are 110 in place, they can result in easier NAT and firewall traversal 111 for RTP/DCCP flows in the future. 113 o Use of RTP with TFRC with various media applications will give 114 researchers, implementors and developers a better understanding 115 of the intricate relationship between media quality and equation 116 based congestion control. Hopefully this experience with 117 congestion control and TFRC will ease the migration of media 118 applications to DCCP once DCCP is deployed. 120 Overall, using the AVPF/RTP profile and header extension to support 121 TFRC provides an immediate means for congestion control in media 122 streams, in the time being until DCCP is deployed. 124 Additionally, there are also a number of technical differences as to 125 how (and which) congestion control information is exchanged between 126 DCCP with CCID3 and RTP: 128 o Using header extensions the RTP TFRC sender transmits a 129 send timestamp to the RTP TFRC receiver with every data packet. 130 In addition to congestion control the send timestamp can be 131 used by the receiver for jitter calculations. 133 In contrast DCCP with CCID3 transmits a quad round trip 134 counter to the receiver. 136 o The RTP TFRC receiver only provides the RTP TFRC sender 137 with the loss event rate as computed by the receiver. 139 In contrast DCCP with CCID3, provides 2 other options for the 140 transport of loss event rate. A sender may choose to receive 141 loss intervals or an Ack Vector. These two options provide the 142 sender with the necessary information to compute the loss event 143 rate. 145 o Sequence number: DCCP supports a 48 bit and a 24 bit sequence 146 number, whereas RTP only supports a 16 bit sequence number. While 147 this makes RTP susceptible to data injection attacks, it can be 148 avoided by using the SRTP [SRTP] profile. 150 4. The TFRC Information Exchange Loop 152 TFRC depends on the exchange of congestion control information 153 between a sender and receiver. In this section we reiterate which 154 items are exchanged between a TFRC sender and receiver as discussed 155 in [TFRC]. We note how the RTP can accommodates these exchanges. 157 4.1. Data Packets 159 As stated in [TFRC] a TFRC sender transmits the following information 160 in each data packet to the receiver: 162 o A sequence number, incremented by one for each data packet 163 transmitted. 165 o A timestamp indicating the packet send time and the sender's 166 current estimate of the round-trip time, RTT. This information 167 is then used by the receiver to compute the TFRC loss intervals. 168 - or - 169 A course-grained timestamp incrementing every quarter of a 170 round trip time, which is then used to determine the TFRC loss 171 intervals. 173 The standard RTP sequence number suffices for TFRCs functionality. 174 RTP header extension [hdrtxt] are used to transmit the send timestamp 175 and RTT. The RTT can be transmitted in band with every RTP packet 176 or when there is significant change is the RTT. Each extension 177 payload is 3 bytes long (see Section 6). 179 4.2. Feedback Packets 181 As stated in [TFRC] a TFRC receiver provides the following feedback 182 to the sender at least once per RTT or per data packet received 183 (which ever time interval is larger): 185 o The send timestamp of the last data packet received, t_i. 187 o The amount of time elapsed between the receipt of the last 188 data packet at the receiver, and the generation of this feedback 189 report, t_delay. This is used by the sender for RTT computations. 191 o The rate at which the receiver estimates that data was received 192 since the last feedback report was sent, x_recv. 194 o The receiver's current estimate of the loss event rate, p, a real 195 value between 0 and 1.0. 197 To accommodate the feedback of these values a new AVPF transport 198 layer feedback message is defined, as detailed in Section 7. 200 5. The Header Extensions 202 The form of the extension block when both the RTT and send timestamp 203 are being transmitted is depicted in Figure 1. The length field for 204 each extensions takes the value 2 to indicate that the payload is 3 205 bytes. The two header extension fields are defined and used as 206 follows: 208 Send timestamp: 24 bits 209 The timestamp indicating when the packet is sent. This timestamp 210 is measured in microseconds and is used for round trip time 211 calculations. 213 Round trip time (RTT): 24 bits 214 The round trip time as measured by the RTP TFRC sender in 215 microseconds. 217 0 1 2 3 218 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 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | 0xBE | 0xDE | length=2 | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | ID | len=2 | RTT | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | ID | len=2 | send timestamps | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 Figure 1 228 6. TFRC-FB: A New AVPF Transport Layer Feedback Message 230 To support feedback to the receivers a new transport layer AVPF 231 feedback message is defined: TFRC-FB. This message is depicted in 232 Figure 2. It is defined according to [AVPF] and includes the 233 following four fields: 235 Timestamp (t_i): 32 bits 236 The send timestamp of the last data packet received by the 237 RTP TFRC receiver, t_i, in microseconds. 239 Delay (t_delay): 32 bits 240 The amount of time elapsed between the receipt of the last data 241 packet at the RTP TFRC receiver, and the generation of this 242 feedback report in microseconds. This is used by the RTP TFRC 243 sender for RTT computations. 245 Data rate (x_recv): 32 bits 246 The rate at which the receiver estimates that data was received 247 since the last feedback report was sent in bytes per second. 249 Loss event rate (p): 32 bits 250 The receiver's current estimate of the loss event rate, p, 251 expressed as a fixed point number with the binary point at the 252 left edge of the field. (That is equivalent to taking the integer 253 part after multiplying the loss event rate by 2^32.) 255 0 1 2 3 256 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 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 |V=2|P| FMT=2 | PT=RTPFB | length | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | SSRC of packet sender | 261 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 262 | SSRC (SSRC of first source) | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | t_i | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | t_delay | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | data rate at the receiver (x_recv) | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | loss event rate (p) | 271 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 272 Figure 2 274 7. RTCP Transmission Intervals, TFRC and the AVPF Profile 276 When running TFRC rate controlled RTP, the RTCP transmission 277 intervals MUST be set according to the requirements of the TFRC 278 algorithm. TFRC requires a receiver to generate a feedback packet at 279 least once per RTT or per packet received (based on the larger time 280 interval). These requirements are to ensure timely reaction to 281 congestion. 283 To support the transmission of feedback packet once per RTT, a 284 RTP/AVPF flow with TFRC congestion control must: 286 o set allow_early to "true" at all times. Essentially, this means 287 that a receiver can always generate an early feedback packet, and 288 does not need to alternate between early and regular RTCP packets 289 (see RFC 4585, Section 3.4,k). 291 o T_rr_interval must not be set to a value larger than the current 292 round trip time, as this would prevent generating feedback packets 293 at least once per RTT (see RFC 4585, Section 3.4,m). 295 The TFRC requirements of receiving feedback once per RTT can at times 296 conflict with the AVP RTCP bandwidth constraints, particularly at 297 small RTTs of 20ms or less. Assuming only one TFRC-FB report per 298 RTCP compound packet, Table 1 lists the RTCP bandwidths at RTTs of 2, 299 5, 10 and 20 ms and the minimum corresponding RTP data rates, where 300 RTCP(X) <= (0.05)*RTP(X) is true. For example, according to Table 301 1, a TFRC RTP flow of less than 3.2 Mbps and a RTT of 5 ms, can not 302 comply with the 5% RTCP bandwidth constraints (Table 1 assumes each 303 RTCP packet is 100 bytes). RTP flows facing such circumstance should 304 take into account the additional RTCP bandwidth needed when signaling 305 their bandwidth information in SDP. 307 RTT RTCP(X) RTP(X) 308 +------------------------------+ 309 | 20 ms | 40 kbps | 0.8 Mbps | 310 | 10 ms | 80 kbps | 1.6 Mbps | 311 | 5 ms | 160 kbps | 3.2 Mbps | 312 | 2 ms | 400 kbps | 8.0 Mbps | 313 +------------------------------+ 314 Table 1 316 8. SDP Definitions 318 RTP flows using TFRC congestion control must signal their use of 319 header extensions for round trip times (RTT) and the send timestamp: 321 a=extmap:4 urn:ietf:params:rtp-hdtext:rtt 322 a=extmap:4 urn:ietf:params:rtp-hdtext:send-ts 324 9. IANA Considerations 326 In this section we detail IANA registry values that need to be 327 registered. 329 The new RTP/AVPF feedback packet, TFRC-FB, must be registered. For 330 the RTPFB range of packets, the following format (FMT) values are 331 needed: 333 Value name: TFRC-FB 334 Long name: TFRC feedback 335 Value: 2 336 Reference: RFC XXXX 338 The names rtt and send-ts need to be registered into the rtp-hdrext 339 section of the urn:ietf: namespace, referring to RFC XXXX. 341 10. Security Considerations 343 This memo defines how to use the RTP AVPF profile and the general RTP 344 header extensions to support TFRC congestion control. Therefore RTP 345 packets using these mechanisms are subject to the security 346 considerations discussed in the RTP specification [RTP], the RTP/AVPF 347 profile specification [AVPF] and the general header extensions 348 mechanism [hdrtxt]. Combining these mechanisms does not pose any 349 additional security implications. Applications requiring 350 authentication and integrity protection can use the SAVPF [SAVPF] 351 profile. 353 11. Acknowledgments 355 This memo is based upon work supported by the U.S. National Science 356 Foundation (NSF) under Grant No. 0334182. Any opinions, findings and 357 conclusions or recommendations expressed in this material are those 358 of the authors and do not necessarily reflect the views of NSF. 360 12. Author's Address 362 Ladan Gharai 363 USC Information Sciences Institute 364 3811 N. Fairfax Drive, #200 365 Arlington, VA 22203 366 USA 368 Normative References 370 [RTP] H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, 371 "RTP: A Transport Protocol for Real-Time Applications", 372 Internet Engineering Task Force, RFC 3550 (STD0064), July 373 2003. 375 [AVP] H. Schulzrinne and S. Casner, "RTP Profile for Audio and 376 Video Conferences with Minimal Control," RFC 3551 (STD0065), 377 July 2003. 379 [AVPF] J. Ott, S. Wenger, A. Sato, C. Burmeister and J. Ray, 380 "Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)", 381 RFC 4585, July 2006. 383 [2119] S. Bradner, "Key words for use in RFCs to Indicate 384 Requirement Levels", Internet Engineering Task Force, 385 RFC 2119, March 1997. 387 [2434] T. Narten and H. Alvestrand, "Guidelines for Writing an IANA 388 Considerations Section in RFCs", Internet Engineering Task 389 Force, RFC 2434, October 1998. 391 [TFRC] M. Handley, S. Floyed, J. Padhye and J. widmer, 392 "TCP Friendly Rate Control (TRFC): Protocol Specification", 393 Internet Engineering Task Force, RFC 3448, January 2003. 395 [SDP] M. Handley and V. Jacobson, "SDP: Session Description 396 Protocol", RFC 2327, April 1998. 398 [SRTP] M. Baugher, D. McGrew, M. Naslund, E. Carrara, K. Norrman, 399 "The Secure Real-time Transport Protocol", RFC 3711, March 400 2004. 402 [hdrext] D. Singer, "A general mechanism for RTP Header Extensions", 403 ID draft-ietf-avt-rtp-hdrext-08, October 2006. 405 [SAVPF] J. Ott, E. Carrara, "Extended Secure RTP Profile for 406 RTCP-based Feedback (RTP/SAVPF)," draft-ietf-avt-profile- 407 savpf-09.txt, April, 2007. 409 Informative References 411 13. IPR Notice 413 The IETF takes no position regarding the validity or scope of any 414 Intellectual Property Rights or other rights that might be claimed to 415 pertain to the implementation or use of the technology described in 416 this document or the extent to which any license under such rights 417 might or might not be available; nor does it represent that it has 418 made any independent effort to identify any such rights. Information 419 on the procedures with respect to rights in RFC documents can be 420 found in BCP 78 and BCP 79. 422 Copies of IPR disclosures made to the IETF Secretariat and any 423 assurances of licenses to be made available, or the result of an 424 attempt made to obtain a general license or permission for the use of 425 such proprietary rights by implementers or users of this 426 specification can be obtained from the IETF on-line IPR repository at 427 http://www.ietf.org/ipr. 429 The IETF invites any interested party to bring to its attention any 430 copyrights, patents or patent applications, or other proprietary 431 rights that may cover technology that may be required to implement 432 this standard. Please address the information to the IETF at ietf- 433 ipr@ietf.org. 435 14. Full Copyright Statement 437 Copyright (C) The IETF Trust (2007). 439 This document is subject to the rights, licenses and restrictions 440 contained in BCP 78, and except as set forth therein, the authors 441 retain all their rights. 443 This document and the information contained herein are provided on an 444 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 445 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 446 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 447 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 448 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 449 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."