Internet Engineering Task Force AVT WG
INTERNET-DRAFT Ladan Gharai
draft-ietf-avt-tfrc-profile-01.txt USC/ISI
9 July 2004
Expires: January 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 a
Gharai [Page 1]
INTERNET-DRAFT Expires: January 2005 July 2004
equation based congestion control scheme for unicast flows operating
in a best effort Internet environment.
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 a 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 AVPCC profile
differs from other RTP profiles in the following ways:
o TFRC is a unicast congestion control scheme, therefore by
extension the AVPCC profile can only be used by unicast RTP
flows.
o A TFRC sender relies on receiving feedback from the receiver
roughly once per round-trip time (RTT) in order to adjust
its send rate. For certain flows (depending on RTTs and data
rates) this TFRC requirement can result in control traffic
that exceeds RTP's bandwidth recommendations for control
traffic.
RTP restricts control traffic to a fixed fraction of session
bandwidth, so as to prevent RTCP feedback implosion in multicast
scenarios. As AVPCC can only be used by unicast flows, TFRCs
increased use of traffic does not effect scalability or cause
traffic implosion.
o TFRC is highly sensitive and dependent on accurate and current
computations of the RTT. The sender uses the RTT to compute
a TCP-friendly send rate, while the receiver uses the RTT or
an estimate of the RTT to compute the loss event rate.
This memo primarily addresses the means of supporting TFRC's
exchange of 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)
relaxation of 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
Gharai [Page 2]
INTERNET-DRAFT Expires: January 2005 July 2004
fixed packet size. TFRC-PS is a variant of TFRC for applications with
varying packet sizes. The 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-
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) to name a few. 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
AVPCC profile. The DCCP protocol is currently in its early
stages of development and widespread deployment is not yet
in place.
o Use of the 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 can traverse firewalls as they are
essentially UDP flows and therefore do not require any special
changes to NATs and firewalls.
o Use of the 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.
In short, the AVPCC profile provides an immediate means for
congestion control in media streams, in the time being until DCCP is
deployed.
Gharai [Page 3]
INTERNET-DRAFT Expires: January 2005 July 2004
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 AVPCC profile:
RTP data header: The standard format of the fixed RTP data
header is used (one marker bit).
Payload types: This profile does not define new payload types,
and has no payload type restrictions.
RTP data header additions: A 16 bit fixed field is added to
the RTP data header for the transport of the quad RTT
counter to the TFRC receiver.
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 12 octet RR extension is defined for the RTCP
RR packet.
SDES use: Applications MAY use any of the SDES items described
Gharai [Page 4]
INTERNET-DRAFT Expires: January 2005 July 2004
in the RTP specification.
Security: The RTP default security services are also the default
under this profile.
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.
Transport mapping: The standard mapping of RTP and RTCP to
transport-level addresses is used.
Encapsulation: This profile leaves to applications the
specification of RTP encapsulation in protocols other than UDP.
5. The TFRC Feedback Loop
TFRC depends on the exchange of 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 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 AVPCC profile extends
the RTP data header by 16 bit field in order to accommodate the
transmission of a quad RTT counter (see Section 5).
Gharai [Page 5]
INTERNET-DRAFT Expires: January 2005 July 2004
5.2. Feedback Packets
As stated in [TFRC] a TFRC receiver provides the following feedback
to the sender at least once per RTT:
o The amount of time elapsed between the receipt of the last
data packet at the receiver, and the generation of this feedback
report. 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.
o The receiver's current estimate of the loss event rate, p.
To accommodate the feedback of these values the AVPCC profile defines
a 12 octet extension to the RTCP Receiver Reports (see Section 6).
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| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| quad RTT counter | |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1:
7. Receiver Report Extensions
Gharai [Page 6]
INTERNET-DRAFT Expires: January 2005 July 2004
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_delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data rate at the receiver (x_recv) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| loss event rate (p) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Figure 2:
8. RTCP Timing Intervals
RFC3550 recommends that control traffic be limited to a small and
known fraction of the session bandwidth. Specifically it recommends
that the fraction of session bandwidth be added for RTCP be fixed at
5%. Based on this fixed bandwidth allotment and the number of senders
and receivers the interval between RTCP feedback packets is
calculated.
In addition to recommended restrictions on control traffic bandwidth,
RFC3550 also recommends an average minimum interval of 5 seconds
between sending RTCP packets, however this minimum interval can be
scaled to a reduced minimum. Computed in seconds of 360 divided by
session bandwidth in kilobits/second.
These restrictions on the fraction of control traffic bandwidth and
the frequency of feedback is to ensure scalability to large multicast
groups and prevent control traffic implosion.
The TFRC algorithm requires feedback from receivers at least once per
Gharai [Page 7]
INTERNET-DRAFT Expires: January 2005 July 2004
RTT. For data rates less than 5Mbps (depending on the RTT) this may
require transmitting RTCP packets at higher frequency than
recommended by the scaled minimum interval. This increased frequency
may or may not results in a control traffic in excess of 5% of the
session bandwidth.
The AVPCC profile defines the control traffic bandwidth as a separate
parameter of the session to accommodate TFRCs feedback requirements.
+--------------------------+----------+---------+-----------+------------+
| Session Bandwidth (B) | 10 kbps | 72 kbps | 5000 kbps | 10000 kbps |
| Minimum Interval (360/B)| 36 sec | 5 sec | 72 msec | 36 msec |
| RTCP Bandwidth | - | - | ~7 kpbs | ~14 kpbs |
+--------------------------+----------+---------------------+------------+
Figure 3: Session bandwidth and RTCP minimum intervals. RTCP bandwidth is
computed assuming compound packet sizes of 60bytes.
9. IANA Considerations
<TBC>
10. Security Considerations
<TBC>
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",
Gharai [Page 8]
INTERNET-DRAFT Expires: January 2005 July 2004
Internet Engineering Task Force, RFC 3550, 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.
Informative References
13. IPR Notice
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
14. 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.
Gharai [Page 9]
INTERNET-DRAFT Expires: January 2005 July 2004
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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 10]