Internet Engineering Task Force AVT WG
INTERNET-DRAFT Ladan Gharai
draft-ietf-avt-tfrc-profile-03.txt USC/ISI
24 October 2004
Expires: April 2005
RTP Profile for TCP Friendly Rate Control
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
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 (2004). All Rights Reserved.
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 2005 October 2004
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 2005 October 2004
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 2005 October 2004
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 2005 October 2004
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 adapts the use of the SRTP profile in
instances where confidentiality, message authentication and
replay protection of the RTP data flows and RTCP control
flows are desired.
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 2005 October 2004
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.
Gharai [Page 6]
INTERNET-DRAFT Expires: April 2005 October 2004
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
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 time-stamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 time-stamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTT |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: RTP header and additions with R=1, RTT included.
Gharai [Page 7]
INTERNET-DRAFT Expires: April 2005 October 2004
7. Receiver Report Extensions
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
Gharai [Page 8]
INTERNET-DRAFT Expires: April 2005 October 2004
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
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. Open Issues
There are a number of open issues on the AVPCC on which we are
Gharai [Page 9]
INTERNET-DRAFT Expires: April 2005 October 2004
soliciting input from the community:
o RFC 3550 recommends that the percentage of control traffic
relative to data, be fixed at 5%. For some flows, the feedback
traffic for AVPCC may exceed this recommendation. Should AVPCC
mandate a strict limit on the percentage of control traffic
bandwidth? At what point is feedback too much feedback?
(i.e., does it make sense for control traffic be 50% of data
traffic?)
What are the implications of this limit, in terms of congestion
control, for flows which cannot abide by the limit? This is
particularly the case for low bandwidth flows, under 1 Mbps, and
RTTs of say less than 10 ms.
o RTT calculations by the sender: As an alternative to including
t_i and t_delay in each RTCP packet, could the sender use the LSR
and DLSR fields of the Receiver Reports to calculate the RTT?
These fields are particularly redundant in instances of two-way
traffic, i.e. each end point is both sending and receiving.
However, for one-way traffic the SR frequency would most likely
not be sufficient.
10. 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
Type of attribute: Media level only
Purpose: RFC XXXX
Reference: RFC XXXX
11. Security Considerations
This profile adapts the use of the SRTP profile in instances where
confidentiality, message authentication and replay protection of the
RTP data flows and RTCP control flows is desired. When used in
Gharai [Page 10]
INTERNET-DRAFT Expires: April 2005 October 2004
conjunction with the SRTP profile the AVPCC profile inherits its
security properties from the SAVP profile.
12. 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.
13. 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.
[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,
Gharai [Page 11]
INTERNET-DRAFT Expires: April 2005 October 2004
"The Secure Real-time Transport Protocol", RFC 3711, March
2004.
Informative References
14. 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.
15. Full Copyright Statement
Copyright (C) The Internet Society (2004). 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
Gharai [Page 12]
INTERNET-DRAFT Expires: April 2005 October 2004
"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 13]