Network Working Group                                          L. Gharai
Internet-Draft
Expires: September 8, 2011                                    C. Perkins
                                                   University of Glasgow
                                                           March 7, 2011


                   RTP with TCP Friendly Rate Control
                    draft-gharai-avtcore-rtp-tfrc-00

Abstract

   This memo specifies how the TCP Friendly Rate Control (TFRC) of RTP
   flows can be supported using the RTP/AVPF profile and the general RTP
   header extension mechanism.  AVPF feedback packets and RTP header
   extensions are defined to support the exchange of control information
   between RTP TFRC senders and receivers.  TFRC is an equation-based
   congestion control scheme for unicast flows operating in a best
   effort Internet environment.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on September 8, 2011.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must



Gharai & Perkins        Expires September 8, 2011               [Page 1]


Internet-Draft                RTP with TFRC                   March 2011


   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Relation to the Datagram Congestion Control Protocol . . . . .  3
   4.  The TFRC Information Exchange Loop . . . . . . . . . . . . . .  5
     4.1.  Data Packets . . . . . . . . . . . . . . . . . . . . . . .  5
     4.2.  Feedback Packets . . . . . . . . . . . . . . . . . . . . .  5
   5.  The Header Extension . . . . . . . . . . . . . . . . . . . . .  6
   6.  TFRC-FB: A New AVPF Transport Layer Feedback Message . . . . .  7
   7.  RTCP Transmission Intervals and Bandwidth Requirements . . . .  8
   8.  SDP Usoage . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     8.1.  Usage with the SDP Offer/Answer Model  . . . . . . . . . . 10
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   11. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 11
   12. Normative References . . . . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12




























Gharai & Perkins        Expires September 8, 2011               [Page 2]


Internet-Draft                RTP with TFRC                   March 2011


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 specifies how the TCP Friendly Rate Control (TFRC) of RTP
   flows can be supported using the RTP/AVPF [RFC3550][RFC4585] profile
   and RTP header extensions, by defining a new header extension and
   AVPF feedback packet, and related parameters.  Any of the AVPF based
   RTP profiles, such as SAVPF, can be used to support TFRC RTP flows.

   TFRC is an equation-based congestion control scheme for unicast flows
   operating in a best effort Internet environment and competing with
   TCP traffic.  TFRC computes a TCP-friendly data rate based on current
   network conditions, as represented by the latest round trip time and
   packet loss calculations.  The complete TFRC mechanism is described
   in detail in [RFC3448].

   To calculate a TCP-friendly data rate and keep track of round trip
   times and packet losses, TFRC senders and receivers rely on
   exchanging specific information between each other, i.e: the sender
   provides the receiver with the latest updates to round trip time
   calculations, while the receiver provides feedback needed to compute
   round trip times and on packet losses.  This memo defines how this
   information can be exchanged between TFRC senders and receiver with
   RTP header extensions and an AVPF feedback packet.


2.  Terminology

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


3.  Relation to the Datagram Congestion Control Protocol

   The TFRC congestion control mechanism is one of a set of congestion
   control methods provided by the Datagram Congestion Control Protocol
   (DCCP) [RFC4340] In this section we detail the pros and cons of using
   TFRC with RTP versus DCCP.

   DCCP is a minimal general purpose transport-layer protocol with
   unreliable yet congestion controlled packet delivery semantics and
   reliable connection setup and teardown [RFC4336].  DCCP currently
   supports both TFRC [RFC4342] and TCP-like [RFC4341] congestion
   control, and the protocol is structured to support new congestion
   control mechanisms defined in the future.  A DCCP mapping for RTP has



Gharai & Perkins        Expires September 8, 2011               [Page 3]


Internet-Draft                RTP with TFRC                   March 2011


   been standardized for media applications [RFC5762].  In addition DCCP
   supports a host of other features, such as: use of Explicit
   Congestion Notification (ECN) and the ECN Nonce, flexible options
   processing, reliable option negotiation, DTLS [RFC5238], Path Maximum
   Transfer Unit (PMTU) and Service Codes.  Naturally an application
   using RTP/DCCP as its transport protocol will benefit from the
   protocol features supported by DCCP.

   However there are a number of benefits to be gained by the
   development and standardization of the use RTP with TFRC:

   o  Media applications lacking congestion control can incorporate
      congestion controlled transport without delay by using RTP with
      TFRC.  Widespread deployment of the DCCP protocol is not currently
      in place.

   o  Use of RTP with TFRC is not contingent on any OS level changes and
      can be quickly deployed, because RTP is implemented at the
      application layer.

   o  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 RTP with TFRC 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.

   Using the AVPF/RTP profile and header extension to support TFRC
   provides an immediate means for congestion control in media streams,
   in the time 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 RTP:

   o  Using header extensions the RTP TFRC sender transmits a send
      timestamp to the RTP TFRC receiver with every data packet.  This
      send timestamp is used by TFRC congestion control, but may also be
      used by the receiver for jitter calculation.  In contrast DCCP
      with CCID3 transmits a quad round trip counter to the receiver.




Gharai & Perkins        Expires September 8, 2011               [Page 4]


Internet-Draft                RTP with TFRC                   March 2011


   o  The RTP TFRC receiver only provides the RTP TFRC 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 [RFC3711] profile.


4.  The TFRC Information Exchange 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 [RFC3448].  We note how RTP can accommodates these exchanges.

4.1.  Data Packets

   As stated in [RFC3448] 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 the functionality
   provided by TFRC.  A RTP header extension [hdrtxt] is used to
   transmit the send timestamp and RTT.  This extension is defined in
   Section 5.

4.2.  Feedback Packets

   As stated in [RFC3448] 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):






Gharai & Perkins        Expires September 8, 2011               [Page 5]


Internet-Draft                RTP with TFRC                   March 2011


   o  The send 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.

   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
      value between 0 and 1.0.

   To accommodate the feedback of these values a new AVPF transport
   layer feedback message is defined, as detailed in Section 6.  The
   timing interval between the feedback packets is discussed in
   Section 7.


5.  The Header Extension

   The form of the extension block is depicted in Figure 1.  The length
   field for the extension takes the value 6 to indicate that the
   payload is 7 bytes.  Two header extension fields are defined and used
   as follows:

   Send timestamp (t_i): 32 bits

      The timestamp indicating when the packet is sent.  This timestamp
      is measured in microseconds and is used for round trip time
      calculations.

   Round trip time (RTT): 24 bits

      The round trip time as measured by the RTP TFRC sender in
      microseconds.
















Gharai & Perkins        Expires September 8, 2011               [Page 6]


Internet-Draft                RTP with TFRC                   March 2011


     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      0xBE     |      0xDE     |            length=2           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  ID   | len=6 |                RTT                            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     send timestamp  (t_i)                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 1: RTP Sender Header Extension Block

                                 Figure 1


6.  TFRC-FB: A New AVPF Transport Layer Feedback Message

   A new transport layer AVPF feedback message is defined to support
   feedback from the receivers: TFRC-FB.  Figure 2 depicts the both the
   common packet format (the first 12 octets) and the feedback control
   information (FCI) for the TFRC-FB packet.

   We note that the TFRC related feedback, is specific to one media
   stream sender, therefore all messages in the compound RTCP packet
   MUST share the same media source SSRC.  In the case where a sender is
   sending multiple media streams to a receiver, each media flow will be
   allocated its own AVPF feedback flow.

   We define four FCI fields for the TFRC-FB message as follows:

   Send timestamp (t_i): 32 bits

      The send timestamp of the last data packet received by the RTP
      TFRC 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 TFRC receiver, and the generation of this
      feedback report in microseconds.  This is used by the RTP TFRC
      sender for RTT computations.

   Data rate (X_recv): 32 bits








Gharai & Perkins        Expires September 8, 2011               [Page 7]


Internet-Draft                RTP with TFRC                   March 2011


      The rate at which the receiver estimates that data was received
      since the last feedback report was sent in bytes per second.
      X_recv is computed per [RFC3448].

   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.)  The value of
      the loss event rate is computed per [RFC3448] Section 5.


    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|  FMT=2  |  PT=RTPFB     |             length            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     SSRC of packet sender                     |
    +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
    |                     SSRC of media source                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      send timestamp (t_i)                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      delay  (t_delay)                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                  data rate at the receiver (x_recv)           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    loss event rate (p)                        |
    +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

   Figure 2: The AVPF TFRC-FB RTCP Transport Layer Feedback Message

                                 Figure 2


7.  RTCP Transmission Intervals and Bandwidth Requirements

   When using TFRC rate controlled RTP, the RTCP transmission intervals
   must be set according to the requirements of the TFRC algorithm.
   TFRC requires a receiver to generate a feedback ack packet at least
   once per RTT or per packet received (based on the larger time
   interval).  These requirements are to ensure timely reaction to
   congestion.

   The TFRC requirements of receiving feedback once per RTT can at times
   conflict with the AVP RTCP bandwidth constraints, particularly at
   small RTTs of 20 ms or less.  Assuming only one TFRC-FB report per



Gharai & Perkins        Expires September 8, 2011               [Page 8]


Internet-Draft                RTP with TFRC                   March 2011


   RTCP compound packet, Figure 3 lists the RTCP bandwidths at RTTs of
   2, 5, 10 and 20 ms and the minimum corresponding RTP data rates,
   where RTCP(X) <= (0.05)*RTP(X) is true.  For example, according to
   Table 1, a TFRC RTP flow of less than 3.2 Mbps and a RTT of 5 ms, can
   not comply with the 5% RTCP bandwidth constraints (Table 1 assumes
   each RTCP packet is 100 bytes).  RTP flows facing such circumstances
   should take into account the additional RTCP bandwidth needed when
   signaling their bandwidth information in SDP [RFC4566].

   Based on initial assumptions on round trip time if more than the
   recommended 5% is needed for RTCP bandwidth, the applications SHOULD
   use the SDP bandwidth modifiers RS and RR [RFC3556] to signal the
   amount of RTCP bandwidth needed.  If the round trip time assumptions
   change after the RTP flows start running, the application MAY
   recalculate the amount of RTCP bandwidth needed and re-signal this
   new value using its signaling protocol of choice.

                      RTT      RTCP(X)   RTP(X)
                  +------------------------------+
                  |  20 ms |  40 kbps | 0.8 Mbps |
                  |  10 ms |  80 kbps | 1.6 Mbps |
                  |   5 ms | 160 kbps | 3.2 Mbps |
                  |   2 ms | 400 kbps | 8.0 Mbps |
                  +------------------------------+

   RTCP bandwidth for TFRC flows with corresponding RTTs of 20, 10, 5
   and 2 ms.  Assuming, 100 byte RTCP packets and one RTCP packet per
   RTT.

                                 Figure 3

   Additionally, to support the transmission of a feedback packet once
   per RTT, the AVPF T_rr_interval variable MUST NOT be set to a value
   larger than the current round trip time, RTT, as this would prevent
   generating feedback packets at least once per RTT (see [RFC4585],
   Section 3.4).


8.  SDP Usoage

   RTP flows using TFRC congestion control MUST signal their use of the
   AVPF profile and RTCP feedback packets, the round trip time (RTT) and
   send timestamp extension, and MAY also signal an initial RTCP
   bandwidth usage:

      v=0





Gharai & Perkins        Expires September 8, 2011               [Page 9]


Internet-Draft                RTP with TFRC                   March 2011


      o=alice 2890844526 2890844526 IN IP4 host.example.com

      s=congestion control with TFRC

      c=IN IP4 host.example.com

      m=video 5400 RTP/AVPF 112

      a=rtpmap:112 H261/90000

      a=extmap:4 urn:ietf:params:rtp-hdtext:rtt-sendts

      a=rtcp-fb * tfrc

      b=AS:400

      b=RS:800

      b=RR:4000

8.1.  Usage with the SDP Offer/Answer Model

   TBC


9.  IANA Considerations

   In this section we detail IANA registry values that need to be
   registered.  Two new values must be reistered for the AVPF profile:

   The new RTP/AVPF feedback packet, TFRC-FB.  The following format
   (FMT) values must be registerd in the FMT sub-registry of the RTPFB
   payload type:

      Value name:TFRC-FB

      Long name: TFRC feedback

      Value: 5

      Reference: RFC XXXX

   The new rtcp-fd-id "tfrc" must be registered with the "rtcp-fb"
   attribute registry:

      Value name: tfrc





Gharai & Perkins        Expires September 8, 2011              [Page 10]


Internet-Draft                RTP with TFRC                   March 2011


      Long name: TFRC Feedback

      Reference: RFC XXXX

   For the new header extension, the name rtt-sendts must be registered
   into the rtp-hdrext section of the urn:ietf: namespace, referring to
   RFC XXXX.


10.  Security Considerations

   This memo defines how to use the RTP AVPF profile and the general RTP
   header extensions to support TFRC congestion control.  Therefore RTP
   packets using these mechanisms are subject to the security
   considerations discussed in the RTP specification [RFC3550], the RTP/
   AVPF profile specification [RFC4585] and the general header
   extensions mechanism [RFC5285].  Combining these mechanisms does not
   pose any additional security implications.  Applications requiring
   authentication and integrity protection, or applictions operating in
   environments that must strictly adhere to the TFRC send rate (and
   fear manipulation of the feedback messsages) can use the SAVPF
   [RFC5124] profile.


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.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3448]  Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP
              Friendly Rate Control (TFRC): Protocol Specification",
              RFC 3448, January 2003.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, July 2003.

   [RFC3556]  Casner, S., "Session Description Protocol (SDP) Bandwidth
              Modifiers for RTP Control Protocol (RTCP) Bandwidth",
              RFC 3556, July 2003.



Gharai & Perkins        Expires September 8, 2011              [Page 11]


Internet-Draft                RTP with TFRC                   March 2011


   [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
              Norrman, "The Secure Real-time Transport Protocol (SRTP)",
              RFC 3711, March 2004.

   [RFC4336]  Floyd, S., Handley, M., and E. Kohler, "Problem Statement
              for the Datagram Congestion Control Protocol (DCCP)",
              RFC 4336, March 2006.

   [RFC4340]  Kohler, E., Handley, M., and S. Floyd, "Datagram
              Congestion Control Protocol (DCCP)", RFC 4340, March 2006.

   [RFC4341]  Floyd, S. and E. Kohler, "Profile for Datagram Congestion
              Control Protocol (DCCP) Congestion Control ID 2: TCP-like
              Congestion Control", RFC 4341, March 2006.

   [RFC4342]  Floyd, S., Kohler, E., and J. Padhye, "Profile for
              Datagram Congestion Control Protocol (DCCP) Congestion
              Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342,
              March 2006.

   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, July 2006.

   [RFC4585]  Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
              "Extended RTP Profile for Real-time Transport Control
              Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
              July 2006.

   [RFC5124]  Ott, J. and E. Carrara, "Extended Secure RTP Profile for
              Real-time Transport Control Protocol (RTCP)-Based Feedback
              (RTP/SAVPF)", RFC 5124, February 2008.

   [RFC5238]  Phelan, T., "Datagram Transport Layer Security (DTLS) over
              the Datagram Congestion Control Protocol (DCCP)",
              RFC 5238, May 2008.

   [RFC5285]  Singer, D. and H. Desineni, "A General Mechanism for RTP
              Header Extensions", RFC 5285, July 2008.

   [RFC5762]  Perkins, C., "RTP and the Datagram Congestion Control
              Protocol (DCCP)", RFC 5762, April 2010.










Gharai & Perkins        Expires September 8, 2011              [Page 12]


Internet-Draft                RTP with TFRC                   March 2011


Authors' Addresses

   Ladan Gharai

   Email: ladan@gharai.org


   Colin Perkins
   University of Glasgow
   School of Computing Science
   Glasgow  G12 8QQ
   United Kingdom

   Email: csp@csperkins.org





































Gharai & Perkins        Expires September 8, 2011              [Page 13]