Internet Engineering Task Force AVT WG INTERNET-DRAFT Ladan Gharai draft-ietf-avt-tfrc-profile-05.txt USC/ISI 22 October 2005 Expires: April 2006 RTP Profile for 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 Internet Society (2005). Abstract This memo specifies a profile called "RTP/AVPCC" for the use of the real-time transport protocol (RTP) and its associated control protocol, RTCP, with the TCP Friendly Rate Control (TFRC). TFRC is an equation based congestion control scheme for unicast flows Gharai [Page 1]
INTERNET-DRAFT Expires: April 2006 October 2005 operating in a best effort Internet environment. This profile provides RTP flows with the mechanism to use congestion control in best effort IP networks. 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 defines a profile called "RTP/AVPCC" for the use of the real-time transport protocol (RTP) [RTP] and its associated control protocol, RTCP, with the TCP Friendly Rate Control (TFRC) [TFRC]. TFRC is an equation based congestion control scheme for unicast flows operating in a best effort Internet environment and competing with TCP traffic. Due to a number of inherent TFRC characteristics, the RTP/AVPCC profile differs from other RTP profiles [AVP] in the following ways: o TFRC is a unicast congestion control scheme, therefore by extension the RTP/AVPCC profile can only be used by unicast RTP flows. o A TFRC sender relies on receiving feedback from the receiver either once per round-trip time (RTT) or per data packet. For certain flows (depending on RTTs and data rates) these TFRC requirements can result in control traffic that exceeds RFC 3550's bandwidth and/or timing recommendations for control traffic. The RTP/AVPCC profile recommends modifications to these recommendations in order to satisfy TFRCs timing needs for control traffic in a safe manner. This memo primarily addresses the means of supporting TFRC's exchange of congestion control information between senders and receivers via the following modifications to RTP and RTCP: (1) RTP data header additions; (2) extensions to the RTCP Receiver Reports; and (3) modifications to the recommended RTCP timing intervals. For details on TFRC congestion control readers are referred to [TFRC]. The current TFRC standard, RFC3448, only targets applications with fixed packet size. TFRC-PS is a variant of TFRC for applications with varying packet sizes. The RTP/AVPCC profile is applicable to both congestion control schemes. 2. Relation to the Datagram Congestion Control Protocol The Datagram Congestion Control Protocol (DCCP) is a minimal general purpose transport-layer protocol with unreliable yet congestion Gharai [Page 2]
INTERNET-DRAFT Expires: April 2006 October 2005 controlled packet delivery semantics and reliable connection setup and teardown. DCCP currently supports both TFRC and TCP-like congestion control. In addition DCCP supports a host of other features, such as: use of Explicit Congestion Notification (ECN) and the ECN Nonce, reliable option negotiation and Path Maximum Transfer Unit (PMTU). Naturally an application using RTP/DCCP as its transport protocol will benefit from the protocol features supported by DCCP. In contrast the RTP Profile for TFRC only provides RTP applications a standardized means for using the TFRC congestion control scheme, without any of the protocol features of DCCP. However there are a number of benefits to be gained by the development and standardization of a RTP Profile for TFRC: o Media applications lacking congestion control can incorporate congestion controlled transport without delay by using the RTP/AVPCC profile. The DCCP protocol is currently under development and widespread deployment is not yet in place. o Use of the RTP/AVPCC profile is not contingent on any OS level changes and can be quickly deployed, as the AVPCC profile is implemented at the application layer. o AVPCC/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 the RTP/AVPCC profile 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. Overall, the RTP/AVPCC profile provides an immediate means for congestion control in media streams, in the time being 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 the RTP/AVPCC profile: o A RTP/AVPCC sender transmits a send timestamp to the RTP/AVPCC receiver with every data packet. In addition to congestion Gharai [Page 3]
INTERNET-DRAFT Expires: April 2006 October 2005 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 A RTP/AVPCC receiver only provides the RTP/AVPCC sender 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 [SRTP] profile in conjunction with the AVPCC profile. 3. Conventions Used in this Document 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 [2119]. 4. RTP and RTCP Packet Forms and Protocol Behavior The section "RTP Profiles and Payload Format Specifications" of RFC 3550 enumerates a number of items that can be specified or modified in a profile. This section addresses each of these items and states which item is modified by the RTP/AVPCC profile: RTP data header: The standard format of the fixed RTP data header has been modified (see Section 6). Payload types: The payload type in the RTP data header is reduced to 6 bits, therefore payload types are restricted to values in the range of 0 to 63. RTP data header additions: Two 32 bit fixed fields, send timestamp and round trip time (RTT), are added to the RTP data header. The send time stamp is always present and the RTT field is present if the R bit is set. Gharai [Page 4]
INTERNET-DRAFT Expires: April 2006 October 2005 RTP data header extensions: No RTP header extensions are defined, but applications operating under this profile MAY use such extensions. Thus, applications SHOULD NOT assume that the RTP header X bit is always zero and SHOULD be prepared to ignore the header extension. If a header extension is defined in the future, that definition MUST specify the contents of the first 16 bits in such a way that multiple different extensions can be identified. RTCP packet types: No additional RTCP packet types are defined by this profile specification. RTCP report interval: This profile is restricted to unicast flows, therefore at all times there is only one active sender and one receiver. Sessions operating under this profile MAY specify a separate parameter for the RTCP traffic bandwidth rather than using the default fraction of the session bandwidth. In particular this may be necessary for data flows were the the RTCP recommended reduced minimum interval is still greater than the RTT. SR/RR extension: A 16 octet RR extension is defined for the RTCP RR packet. SDES use: Applications MAY use any of the SDES items described in the RTP specification. Security: This profile is subject to the security considerations discussed in the TFRC and RTP specifications [TFRC][RTP]. This profile does not specify any additional security services. String-to-key mapping: No mapping is specified by this profile. Congestion: This profile specifies how to use RTP/RTCP with TFRC congestion control. Underlying protocol: The profile specifies the use of RTP over unicast UDP flows only, multicast MUST NOT be used. Transport mapping: The standard mapping of RTP and RTCP to transport-level addresses is used. Encapsulation: This profile is defined for encapsulation over UDP only. Gharai [Page 5]
INTERNET-DRAFT Expires: April 2006 October 2005 5. The TFRC Feedback 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 [TFRC]. We note how the RTP/AVPCC profile accommodates these exchanges. 5.1. Data Packets As stated in [TFRC] 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 TFRCs functionality. For the computation of the loss intervals the RTP/AVPCC profile extends the RTP data header as follows: a 32 bit field to transmit a send timestamp and an additional 32 bit field, present only when the RTT changes, to transmit the RTT. The presence of the RTT is indicated by the R bit in the RTP header (see Section 6). 5.2. Feedback Packets As stated in [TFRC] 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): o The 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 (see Section 9). 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 Gharai [Page 6]
INTERNET-DRAFT Expires: April 2006 October 2005 value between 0 and 1.0. To accommodate the feedback of these values the RTP/AVPCC profile defines a 16 octet extension to the RTCP Receiver Reports (see Section 7). 6. RTP Data Header Additions The RTP/AVPCC profile makes the following changes to the RTP header (other fields of the payload header are defined as in RFC 3550 [RTP]): o the profile uses a 6 bit payload type (PT) field, o defines a 1 bit R field in the second octet, and o defines two additional 32 bit fixed fields: 1. the packets send timestamp, 2. the round trip time (RTT) as measured by the sender. This field is present if the R bit is set (see Figures 1 and 2). The additional fields of the RTP header are defined and used as follows: Round trip time indicator (R): 1 bit This field indicates the existence of the additional RTT field. If the R bit is set, the RTP payload header includes a 32 bit field representing the current round trip time (Figures 1 and 2). Payload type (PT): 6 bits The RTP/AVPCC profile uses a 6 bit field for the payload type (instead of a 7 bit field). Send timestamp: 32 bits The timestamp indicating when the packet is sent. This timestamp is measured in microseconds and is used for round trip time calculations. At microsecond granularity the send timestamp wraps around in approximately 71 minutes. Round trip time (RTT): 32 bits The round trip time as measured by the RTP/AVPCC sender in microseconds. This field is only present if the R bit is set (Figure 2). Gharai [Page 7]
INTERNET-DRAFT Expires: April 2006 October 2005 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|X| CC |M|R| PT | sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | send timestamp | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | contributing source (CSRC) identifiers | | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: RTP header and additions with R=0, no RTT included. 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|X| CC |M|R| PT | sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | send timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTT | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | contributing source (CSRC) identifiers | | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: RTP header and additions with R=1, RTT included. 7. Receiver Report Extensions The RTP/AVPCC profile defines four 32 bit fixed fields as profile- specific extensions to the receiver reports (Figure 3). These four fields are: Gharai [Page 8]
INTERNET-DRAFT Expires: April 2006 October 2005 Timestamp (t_i): 32 bits The timestamp of the last data packet received by the RTP/AVPCC 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/AVPCC receiver, and the generation of this feedback report in microseconds. This is used by the 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.) Gharai [Page 9]
INTERNET-DRAFT Expires: April 2006 October 2005 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| RC | PT=RR=201 | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of packet sender | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | SSRC (SSRC of first source) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | fraction lost | cumulative number of packets lost | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | extended highest sequence number received | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | interarrival jitter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | last SR (LSR) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | delay since last SR (DLSR) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | t_i | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | t_delay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data rate at the receiver (x_recv) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | loss event rate (p) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Figure 3: RTCP Receiver Report extensions. 8. RTCP Timing Intervals The RTP/AVPCC profile recommends the use of the TFRC timing feedback requirements for the RTCP timing intervals, only in instances where control traffic bandwidth does not exceed RFC 3550's recommended 5% of data traffic. A TFRC sender requires feedback from its receiver at least once per RTT or per packet received (based on the larger time interval). These requirements are to ensure timely reaction to congestion. In some instances TFRC's timing requirements may result in timing intervals for RTCP traffic that are smaller than RFC 3550's recommended scaled reduced minimum timing interval of 360 divided by session bandwidth in kilobits/second or t(s) = 360/X(kbps). For example, Figure 4 depicts two AVPCC flows and their relationship with RTCP's reduced minimum interval: t(ms) = 360/X (Mbps). The two Gharai [Page 10]
INTERNET-DRAFT Expires: April 2006 October 2005 flows have data rates of 2 Mbps and 4 Mbps with RTTs of 70 ms and 130 ms, respectively. The 4 Mbps flow's TFRC feedback requirements of 130 ms falls within RFC 3550's recommended reduced minimum interval for RTCP traffic. However the 2 Mbps flow's TFRC feedback requirement of once per 70 ms is more frequent than the 180 ms recommended by RFC 3550. However in this case, it is safe to use TFRC's 70 ms interval, as at the rate of roughly one 88 octet RTCP compound packet per 70 ms, the feedback traffic for the 2 Mbps flow amounts to 10 kbps, that is less than 1% of the data flow and well with the 5% recommended by RFC 3550. Bandwidth (Mbps) ^ | \ | \ | \ | \ 360 | \ t(ms)= ------- | \ X (Mbps) | \ | \_ 4 | \__ x | \___ 2 | x \____ | \_________ +----------------------------------> 70 130 Time (ms) Figure 4: Relationship between RFC 3550 recommended reduced minimum interval and session bandwidth (Mbps). 9. IANA Considerations The RTP profile for TCP Friendly Rate Control extends the profile for audio- visual conferences with minimal control and needs to be registered for the Session Description Protocol [SDP] as "RTP/AVPCC". SDP Protocol ("proto"): Name: RTP/AVPCC Long form: RTP Profile for TCP Friendly Rate Control Type of name: proto Gharai [Page 11]
INTERNET-DRAFT Expires: April 2006 October 2005 Type of attribute: Media level only Purpose: RFC XXXX Reference: RFC XXXX 10. Security Considerations The RTP/AVPCC profile is subject to the security considerations discussed in the TFRC and RTP specifications [TFRC][RTP]. This profile does not specify any additional security services. To guard against spoofed feedback attacks using false RTCP packets, authentication can be used for all RTCP messages. This can be done by defining a combined secure SAVPCC profile, by using the AVPCC profile together with the Secure RTP profile [SRTP]. 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> USC Information Sciences Institute 3811 N. Fairfax Drive, #200 Arlington, VA 22203 USA Normative References [RTP] 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. [AVP] H. Schulzrinne and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control," RFC 3551 (STD0065), July 2003. [2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", Internet Engineering Task Force, RFC 2119, March 1997. Gharai [Page 12]
INTERNET-DRAFT Expires: April 2006 October 2005 [2434] T. Narten and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", Internet Engineering Task Force, RFC 2434, October 1998. [TFRC] M. Handley, S. Floyed, J. Padhye and J. widmer, "TCP Friendly Rate Control (TRFC): Protocol Specification", Internet Engineering Task Force, RFC 3448, January 2003. [SDP] M. Handley and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. [SRTP] M. Baugher, D. McGrew, M. Naslund, E. Carrara, K. Norrman, "The Secure Real-time Transport Protocol", RFC 3711, March 2004. 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 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 Internet Society (2005). This document is subject Gharai [Page 13]
INTERNET-DRAFT Expires: April 2006 October 2005 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 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 14]
