Internet Engineering Task Force AVT WG INTERNET-DRAFT Ladan Gharai draft-ietf-avt-tfrc-profile-09.txt USC/ISI 8 July 2007 Expires: January 2008 RTP with TCP Friendly Rate Control Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This memo specifies how the TCP Friendly Rate Control (TFRC) of RTP flows can be supported using the RTP/AVPF profile and the general RTP header extension mechanism. AVPF feedback packets and RTP header extensions are defined to support the exchange of control information between RTP TFRC senders and receivers. TFRC is an equation-based congestion control scheme for unicast flows operating in a best effort Internet environment. Gharai [Page 1]
INTERNET-DRAFT Expires: January 2008 July 2007 1. Introduction [Note to RFC Editor: All references to RFC XXXX are to be replaced with the RFC number of this memo, when published] This memo specifies how the TCP Friendly Rate Control (TFRC) of RTP flows can be supported using the RTP/AVPF [RFC3550][RFC4585] profile and RTP header extensions, by defining a new header extension and AVPF feedback packet, and related parameters. TFRC is an equation-based congestion control scheme for unicast flows operating in a best effort Internet environment and competing with TCP traffic. TFRC computes a TCP-friendly data rate based on current network conditions, as represented by the latest round trip time and packet loss calculations. The complete TFRC mechanism is described in detail in [RFC3448.bis]. To calculate a TCP-friendly data rate and keep track of round trip times and packet losses, TFRC senders and receivers rely on exchanging specific information between each other, i.e: the sender provides the receiver with the latest updates to round trip time calculations, while the receiver provides feedback needed to compute round trip times and on packet losses. This memo defines how this information can be exchanged between TFRC senders and receiver with RTP header extensions and an AVPF feedback packet. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. Relation to the Datagram Congestion Control Protocol The TFRC congestion control mechanism is one of a set of congestion control methods provided by the Datagram Congestion Control Protocol (DCCP) [RFC4340] In this section we detail the pros and cons of using TFRC with RTP versus DCCP. DCCP is a minimal general purpose transport-layer protocol with unreliable yet congestion controlled packet delivery semantics and reliable connection setup and teardown [RFC4336]. DCCP currently supports both TFRC [RFC4341] and TCP-like [RFC4341] congestion control, and the protocol is structured to support new congestion control mechanisms defined in the future. A DCCP mapping for RTP has been standardised for media applications [RFCxRTP]. In addition DCCP supports a host of other features, such as: use of Explicit Congestion Notification (ECN) and the ECN Nonce, flexible options Gharai [Page 2]
INTERNET-DRAFT Expires: January 2008 July 2007 processing, reliable option negotiation, DTLS [ID.DTLS], Path Maximum Transfer Unit (PMTU) and Service Codes. Naturally an application using RTP/DCCP as its transport protocol will benefit from the protocol features supported by DCCP. However there are a number of benefits to be gained by the development and standardization of the use RTP with TFRC: o Media applications lacking congestion control can incorporate congestion controlled transport without delay by using RTP with TFRC. Widespread deployment of the DCCP protocol is not currently in place. o Use of RTP with TFRC is not contingent on any OS level changes and can be quickly deployed, because RTP is implemented at the application layer. o RTP/UDP flows face the same restrictions in firewall traversal as do UDP flows and do not require NATs and firewall modifications. DCCP flows, on the other hand, do require NAT and firewall modifications, however once these modifications are in place, they can result in easier NAT and firewall traversal for RTP/DCCP flows in the future. o Use of RTP with TFRC with various media applications will give researchers, implementors and developers a better understanding of the intricate relationship between media quality and equation-based congestion control. Hopefully this experience with congestion control and TFRC will ease the migration of media applications to DCCP once DCCP is deployed. Using the AVPF/RTP profile and header extension to support TFRC provides an immediate means for congestion control in media streams, in the time until DCCP is deployed. Additionally, there are also a number of technical differences as to how (and which) congestion control information is exchanged between DCCP with CCID3 and RTP: o Using header extensions the RTP TFRC sender transmits a send timestamp to the RTP TFRC receiver with every data packet. In addition to congestion control the send timestamp can be used by the receiver for jitter calculations. In contrast DCCP with CCID3 transmits a quad round trip counter to the receiver. o The RTP TFRC receiver only provides the RTP TFRC sender Gharai [Page 3]
INTERNET-DRAFT Expires: January 2008 July 2007 with the loss event rate as computed by the receiver. In contrast DCCP with CCID3, provides 2 other options for the transport of loss event rate. A sender may choose to receive loss intervals or an Ack Vector. These two options provide the sender with the necessary information to compute the loss event rate. o Sequence number: DCCP supports a 48 bit and a 24 bit sequence number, whereas RTP only supports a 16 bit sequence number. While this makes RTP susceptible to data injection attacks, it can be avoided by using the SRTP [RFC3711] profile. 4. The TFRC Information Exchange Loop TFRC depends on the exchange of congestion control information between a sender and receiver. In this section we reiterate which items are exchanged between a TFRC sender and receiver as discussed in [RFC3448.bis]. We note how RTP can accommodates these exchanges. 4.1. Data Packets As stated in [RFC3448.bis] a TFRC sender transmits the following information in each data packet to the receiver: o A sequence number, incremented by one for each data packet transmitted. o A timestamp indicating the packet send time and the sender's current estimate of the round-trip time, RTT. This information is then used by the receiver to compute the TFRC loss intervals. - or - A course-grained timestamp incrementing every quarter of a round trip time, which is then used to determine the TFRC loss intervals. The standard RTP sequence number suffices for the functionality provided by TFRC. A RTP header extension [hdrtxt] is used to transmit the send timestamp and RTT. This extension is defined in Section 5. 4.2. Feedback Packets As stated in [RFC3448.bis] a TFRC receiver provides the following feedback to the sender at least once per RTT or per data packet received (which ever time interval is larger): Gharai [Page 4]
INTERNET-DRAFT Expires: January 2008 July 2007 o The send timestamp of the last data packet received, t_i. o The amount of time elapsed between the receipt of the last data packet at the receiver, and the generation of this feedback report, t_delay. This is used by the sender for RTT computations. o The rate at which the receiver estimates that data was received since the last feedback report was sent, x_recv. o The receiver's current estimate of the loss event rate, p, a real value between 0 and 1.0. To accommodate the feedback of these values a new AVPF transport layer feedback message is defined, as detailed in Section 6. 5. The Header Extension The form of the extension block is depicted in Figure 1. The length field for the extension takes the value 6 to indicate that the payload is 7 bytes. Two header extension fields are defined and used as follows: Send timestamp (t_i): 32 bits The timestamp indicating when the packet is sent. This timestamp is measured in microseconds and is used for round trip time calculations. Round trip time (RTT): 24 bits The round trip time as measured by the RTP TFRC sender in microseconds. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xBE | 0xDE | length=2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID | len=6 | RTT | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | send timestamp (t_i) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: RTP Sender Header Extension Block Gharai [Page 5]
INTERNET-DRAFT Expires: January 2008 July 2007 6. TFRC-FB: A New AVPF Transport Layer Feedback Message A new transport layer AVPF feedback message is defined to support feedback from the receivers: TFRC-FB. This message is depicted in Figure 2. It is defined according to [RFC4585] and includes the following four fields: Send timestamp (t_i): 32 bits The send timestamp of the last data packet received by the RTP TFRC receiver, t_i, in microseconds. Delay (t_delay): 32 bits The amount of time elapsed between the receipt of the last data packet at the RTP TFRC receiver, and the generation of this feedback report in microseconds. This is used by the RTP TFRC sender for RTT computations. Data rate (x_recv): 32 bits The rate at which the receiver estimates that data was received since the last feedback report was sent in bytes per second. Loss event rate (p): 32 bits The receiver's current estimate of the loss event rate, p, expressed as a fixed point number with the binary point at the left edge of the field. (That is equivalent to taking the integer part after multiplying the loss event rate by 2^32.) 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P| FMT=2 | PT=RTPFB | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of packet sender | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | SSRC (SSRC of first source) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | send timestamp (t_i) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | delay (t_delay) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data rate at the receiver (x_recv) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | loss event rate (p) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Figure 2: The AVPF TFRC-FB RTCP Transport Layer Feedback Message Gharai [Page 6]
INTERNET-DRAFT Expires: January 2008 July 2007 7. RTCP Transmission Intervals and Bandwidth Requirements When using TFRC rate controlled RTP, the RTCP transmission intervals must be set according to the requirements of the TFRC algorithm. TFRC requires a receiver to generate a feedback ack packet at least once per RTT or per packet received (based on the larger time interval). These requirements are to ensure timely reaction to congestion. The TFRC requirements of receiving feedback once per RTT can at times conflict with the AVP RTCP bandwidth constraints, particularly at small RTTs of 20 ms or less. Assuming only one TFRC-FB report per RTCP compound packet, Table 1 lists the RTCP bandwidths at RTTs of 2, 5, 10 and 20 ms and the minimum corresponding RTP data rates, where RTCP(X) <= (0.05)*RTP(X) is true. For example, according to Table 1, a TFRC RTP flow of less than 3.2 Mbps and a RTT of 5 ms, can not comply with the 5% RTCP bandwidth constraints (Table 1 assumes each RTCP packet is 100 bytes). RTP flows facing such circumstances should take into account the additional RTCP bandwidth needed when signaling their bandwidth information in SDP [RFC2327]. Based on initial assumptions on round trip time if more than the recommended 5% is needed for RTCP bandwidth, the applications SHOULD use the SDP bandwidth modifiers RS and RR [RFC3556] to signal the amount of RTCP bandwidth needed. If the round trip time assumptions change after the RTP flows start running, the application MAY recalculate the amount of RTCP bandwidth needed and resignal this new value using its signaling protocol of choice. RTT RTCP(X) RTP(X) +------------------------------+ | 20 ms | 40 kbps | 0.8 Mbps | | 10 ms | 80 kbps | 1.6 Mbps | | 5 ms | 160 kbps | 3.2 Mbps | | 2 ms | 400 kbps | 8.0 Mbps | +------------------------------+ Table 1: RTCP bandwidth for TFRC flows with corresponding RTTs of 20, 10, 5 and 2 ms. Assuming, 100 byte RTCP packets and one RTCP packet per RTT. Additionally, to support the transmission of a feedback packet once per RTT, the AVPF T_rr_interval variable MUST NOT be set to a value larger than the current round trip time, RTT, as this would prevent generating feedback packets at least once per RTT (see RFC 4585, Section 3.4,m). Gharai [Page 7]
INTERNET-DRAFT Expires: January 2008 July 2007 8. SDP Example RTP flows using TFRC congestion control MUST signal their use of the AVPF profile and RTCP feedback packets, the round trip time (RTT) and send timestamp extension, and MAY also signal an initial RTCP bandwidth usage: v=0 o=alice 2890844526 2890844526 IN IP4 host.example.com s=congestion control with TFRC c=IN IP4 host.example.com m=video 5400 RTP/AVPF 112 a=rtpmap:112 H261/90000 a=extmap:4 urn:ietf:params:rtp-hdtext:rtt-sendts a=rtcp-fb * tfrc b=AS:400 b=RS:800 b=RR:4000 9. IANA Considerations In this section we detail IANA registry values that need to be registered. The new RTP/AVPF feedback packet, TFRC-FB, must be registered. For the RTPFB range of packets, the following format (FMT) values are needed: Value name: TFRC-FB Long name: TFRC feedback Value: 5 Reference: RFC XXXX Also for the AVPF profile, the rtcp-fd-id tfrc must be registered. For the new header extension, the name rtt-sendts must be registered into the rtp-hdrext section of the urn:ietf: namespace, referring to RFC XXXX. 10. Security Considerations This memo defines how to use the RTP AVPF profile and the general RTP header extensions to support TFRC congestion control. Therefore RTP packets using these mechanisms are subject to the security considerations discussed in the RTP specification [RFC3550], the RTP/AVPF profile specification [RFC4585] and the general header Gharai [Page 8]
INTERNET-DRAFT Expires: January 2008 July 2007 extensions mechanism [hdrtxt]. Combining these mechanisms does not pose any additional security implications. Applications requiring authentication and integrity protection can use the SAVPF [SAVPF] profile. 11. Acknowledgments This memo is based upon work supported by the U.S. National Science Foundation (NSF) under Grant No. 0334182. Any opinions, findings and conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of NSF. 12. Author's Address Ladan Gharai <ladan@isi.edu> Normative References [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", Internet Engineering Task Force, RFC 2119, March 1997. [RFC2327] M. Handley and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. [RFC2434] T. Narten and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", Internet Engineering Task Force, RFC 2434, October 1998. [RFC3550] H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", Internet Engineering Task Force, RFC 3550 (STD0064), July 2003. [RFC3551] H. Schulzrinne and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control," RFC 3551 (STD0065), July 2003. [RFC3556] S. Casner, "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, July 2003. [RFC3711] M. Baugher, D. McGrew, M. Naslund, E. Carrara, K. Norrman, "The Secure Real-time Transport Protocol", RFC 3711, March 2004. Gharai [Page 9]
INTERNET-DRAFT Expires: January 2008 July 2007 [RFC4336] Floyd, S., Handley, M., and E. Kohler, "Problem Statement for the Datagram Congestion Control Protocol (DCCP)", RFC 4336, March 2006. [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006. [RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion Control", RFC 4341, March 2006. [RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, March 2006. [RFC4585] J. Ott, S. Wenger, A. Sato, C. Burmeister and J. Ray, "Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)", RFC 4585, July 2006. [RFC3448.bis] M. Handley, S. Floyed, J. Padhye and J. widmer, "TCP Friendly Rate Control (TRFC): Protocol Specification", draft-ietf-dccp-rfc3448bis-01.txt, March 2007. [hdrext] D. Singer, "A general mechanism for RTP Header Extensions", IETF Work in Progress, draft-ietf-avt-rtp-hdrext-xx.txt. [SAVPF] J. Ott, E. Carrara, "Extended Secure RTP Profile for RTCP-based Feedback (RTP/SAVPF)," IETF Work in Progress, draft-ietf-avt-profile-savpf-xx.txt. [RFCxRTP] C. Perkins, "RTP and the Datagram Congestion Control Protocol (DCCP)", IETF Work in Progress, draft-ietf-dccp- rtp-07.txt. [ID.DTLS] T.Phelan, "Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP)", IETF Work in Progress, draft-phelan-dccp-dtls-xx.txt. Informative References 13. IPR Notice The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has Gharai [Page 10]
INTERNET-DRAFT Expires: January 2008 July 2007 made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. 14. Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Gharai [Page 11]
