[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-gharai-avt-tfrc-profile) 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-00.txt                               USC/ISI
                                                            21 June 2004
                                                  Expires: December 2004


                RTP Profile for TCP Friendly Rate Control



Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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 (2003).  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
   equation based congestion control scheme for unicast flows operating
   in a best effort Internet environment.



Gharai                                                          [Page 1]


INTERNET-DRAFT           Expires: December 2004                June 2004


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
      at least once per round-trip time (RTT) in order to adjust
      its send rate (for flows with send rates of less than one
      packet per RTT time, a feedback packet should be sent for
      every data packet received). 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 needs the current
      RTT to compute its loss event rate. Therefore it is imperative
      that both the senders and receiver have access to current and
      accurate RTT measurements.

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




Gharai                                                          [Page 2]


INTERNET-DRAFT           Expires: December 2004                June 2004


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



Gharai                                                          [Page 3]


INTERNET-DRAFT           Expires: December 2004                June 2004


   deployed.


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:  Two 32bit additional fixed fields
         are added to the RTP data header for the transport
         of packet send time and the current RTT 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.




Gharai                                                          [Page 4]


INTERNET-DRAFT           Expires: December 2004                June 2004


      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: 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. This timestamp
      is used by the receiver to (1) compute the loss event rate
      and (2) is returned to the sender for RTT computation.

      The standard RTP header includes a 32 bit timestamp. For
      real-time data this timestamp indicates the sampling
      instance of the first octet of the packet. For stored media



Gharai                                                          [Page 5]


INTERNET-DRAFT           Expires: December 2004                June 2004


      it represents the presentation time of the packet. Packets
      belonging to the same video frame/audio sample share the same
      RTP timestamp value.

      While it would be preferable to use the RTP timestamp for TFRC's
      calculations, it can lead to incorrect RTT and loss event rate
      calculations.  For example ...

    o The sender's current estimate of the round-trip time, RTT.

   The standard RTP sequence number suffices for TFRCs functionality.
   To transmit the send timestamp and the RTT to the receiver the AVPCC
   profile extends the RTP data header by two 32bit fields in order to
   accommodate their transmission (see Section 5).


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 timestamp of the last data packet received. This is the
      timestamp is used by the sender to estimate RTT and is only
      needed if the sender does not save timestamps of transmitted
      data packets.

    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 for estimation of the RTT.

    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 16 octet extension to the RTCP Receiver Reports (see Section 6).



6.  RTP Data Header Additions










Gharai                                                          [Page 6]


INTERNET-DRAFT           Expires: December 2004                June 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|X|  CC   |M|     PT      |       sequence number         |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                           timestamp                           |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |           synchronization source (SSRC) identifier            |
        +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
        |                       timestamp (packet send time)            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                             RTT                               |
        +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
        |            contributing source (CSRC) identifiers             |
        |                             ....                              |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     Figure 1:



7.  Receiver Report Extensions






























Gharai                                                          [Page 7]


INTERNET-DRAFT           Expires: December 2004                June 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)                  |
        +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
        |                         timestamp_i                           |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                           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



Gharai                                                          [Page 8]


INTERNET-DRAFT           Expires: December 2004                June 2004


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






Gharai                                                          [Page 9]


INTERNET-DRAFT           Expires: December 2004                June 2004


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




Gharai                                                         [Page 10]


INTERNET-DRAFT           Expires: December 2004                June 2004


   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 2003. All Rights Reserved.

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


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/