[Search] [txt|pdfized|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10                              
Internet Engineering Task Force                                   AVT WG
INTERNET-DRAFT                                              Ladan Gharai
draft-ietf-avt-tfrc-profile-02.txt                               USC/ISI
                                                          17 August 2004
                                                  Expires: February 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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved.


   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

Gharai                                                          [Page 1]

INTERNET-DRAFT           Expires: February 2005              August 2004

   an equation based congestion control scheme for unicast flows
   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

    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.

Gharai                                                          [Page 2]

INTERNET-DRAFT           Expires: February 2005              August 2004

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).  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

   Additionally, there are also a number of differences in the exchange
   of congestion control information between DCCP with CCID3 and the

Gharai                                                          [Page 3]

INTERNET-DRAFT           Expires: February 2005              August 2004

   RTP/AVPCC profile:

     o A RTP/AVPCC sender transmits the round trip time and
       the send timestamp to the RTP/AVPCC receiver. 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 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

     o Sequence number: DCCP supports a 48 bit and a 24 bit sequence
       number. RTP supports a 16 bit sequence number.

3.  Conventions Used in this Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   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 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

Gharai                                                          [Page 4]

INTERNET-DRAFT           Expires: February 2005              August 2004

         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: <TBC> See Section 9.

      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.

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

Gharai                                                          [Page 5]

INTERNET-DRAFT           Expires: February 2005              August 2004


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

    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

   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.

   To accommodate the feedback of these values the RTP/AVPCC profile
   defines a 16 octet extension to the RTCP Receiver Reports (see
   Section 7).

Gharai                                                          [Page 6]

INTERNET-DRAFT           Expires: February 2005              August 2004

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.

7.  Receiver Report Extensions

Gharai                                                          [Page 7]

INTERNET-DRAFT           Expires: February 2005              August 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_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

Gharai                                                          [Page 8]

INTERNET-DRAFT           Expires: February 2005              August 2004

   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

     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
   soliciting input from the community:

   o  RFC 3550 recommends that the percentage of control traffic

Gharai                                                          [Page 9]

INTERNET-DRAFT           Expires: February 2005              August 2004

      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

      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  Security: Is it possible for the AVPCC to use the security
      mechanisms of SRTP as defined in RFC 3711 or is it necessary
      to define alternative security profile and mechanisms?

   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?
      This is mainly  a question of: is the frequency of the RTTs
      computed from Sender Reports sufficient for the sender to react
      to changes in the RTT and congestion?

   o  How does this profile relate to other RTP profiles?

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

   See Section 9 (Open Issues).

Gharai                                                         [Page 10]

INTERNET-DRAFT           Expires: February 2005              August 2004

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

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

   [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.

Gharai                                                         [Page 11]

INTERNET-DRAFT           Expires: February 2005              August 2004

Informative References

14.  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

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 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

   The limited permissions granted above are perpetual and will not be

Gharai                                                         [Page 12]

INTERNET-DRAFT           Expires: February 2005              August 2004

   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an

Gharai                                                         [Page 13]