tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 5348

 Errata 
Proposed STD
Pages: 58
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: DCCP

TCP Friendly Rate Control (TFRC): Protocol Specification

Part 1 of 3, p. 1 to 19
None       Next RFC Part

Obsoletes:    3448
Updates:    4342


Top       ToC       Page 1 
Network Working Group                                           S. Floyd
Request for Comments: 5348                                          ICIR
Obsoletes: 3448                                               M. Handley
Updates: 4342                                  University College London
                                                               J. Padhye
                                                               Microsoft
                                                               J. Widmer
                                                                  DoCoMo
                                                          September 2008


        TCP Friendly Rate Control (TFRC): Protocol Specification

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

   This document specifies TCP Friendly Rate Control (TFRC).  TFRC is a
   congestion control mechanism for unicast flows operating in a best-
   effort Internet environment.  It is reasonably fair when competing
   for bandwidth with TCP flows, but has a much lower variation of
   throughput over time compared with TCP, making it more suitable for
   applications such as streaming media where a relatively smooth
   sending rate is of importance.

   This document obsoletes RFC 3448 and updates RFC 4342.

Table of Contents

 1. Introduction ....................................................3
 2. Conventions .....................................................4
 3. Protocol Mechanism ..............................................4
    3.1. TCP Throughput Equation ....................................5
    3.2. Packet Contents ............................................7
         3.2.1. Data Packets ........................................7
         3.2.2. Feedback Packets ....................................8
 4. Data Sender Protocol ............................................8
    4.1. Measuring the Segment Size .................................9
    4.2. Sender Initialization .....................................10
    4.3. Sender Behavior When a Feedback Packet Is Received ........10
    4.4. Expiration of Nofeedback Timer ............................15
    4.5. Reducing Oscillations .....................................17

Top      ToC       Page 2 
    4.6. Scheduling of Packet Transmissions ........................18
 5. Calculation of the Loss Event Rate (p) .........................19
    5.1. Detection of Lost or Marked Packets .......................19
    5.2. Translation from Loss History to Loss Events ..............20
    5.3. The Size of a Loss Interval ...............................22
    5.4. Average Loss Interval .....................................22
    5.5. History Discounting .......................................24
 6. Data Receiver Protocol .........................................26
    6.1. Receiver Behavior When a Data Packet Is Received ..........27
    6.2. Expiration of Feedback Timer ..............................27
    6.3. Receiver Initialization ...................................28
         6.3.1. Initializing the Loss History after the
                First Loss Event ...................................29
 7. Sender-Based Variants ..........................................30
 8. Implementation Issues ..........................................31
    8.1. Computing the Throughput Equation .........................31
    8.2. Sender Behavior When a Feedback Packet Is Received ........32
         8.2.1. Determining If an Interval Was a
                Data-Limited Interval ..............................32
         8.2.2. Maintaining X_recv_set .............................34
    8.3. Sending Packets before Their Nominal Send Time ............34
    8.4. Calculation of the Average Loss Interval ..................36
    8.5. The Optional History Discounting Mechanism ................36
 9. Changes from RFC 3448 ..........................................36
    9.1. Overview of Changes .......................................36
    9.2. Changes in Each Section ...................................37
 10. Security Considerations .......................................39
    10.1. Security Considerations for TFRC in DCCP .................40
 11. Acknowledgments ...............................................40
 Appendix A. Terminology ...........................................41
 Appendix B. The Initial Value of the Nofeedback Timer .............43
 Appendix C. Response to Idle or Data-Limited Periods ..............44
    C.1.  Long Idle or Data-Limited Periods ........................45
    C.2.  Short Idle or Data-Limited Periods .......................48
    C.3.  Moderate Idle or Data-Limited Periods ....................49
    C.4.  Losses During Data-Limited Periods .......................50
    C.5.  Other Patterns ...........................................53
    C.6.  Evaluating TFRC's Response to Idle Periods ...............53
 References ........................................................54
    Normative References ...........................................54
    Informative References .........................................54

Top      ToC       Page 3 
1.  Introduction

   This document specifies TCP Friendly Rate Control (TFRC).  TFRC is a
   congestion control mechanism designed for unicast flows operating in
   an Internet environment and competing with TCP traffic [FHPW00].
   Instead of specifying a complete protocol, this document simply
   specifies a congestion control mechanism that could be used in a
   transport protocol such as DCCP (Datagram Congestion Control
   Protocol) [RFC4340], in an application incorporating end-to-end
   congestion control at the application level, or in the context of
   endpoint congestion management [BRS99].  This document does not
   discuss packet formats or reliability.  Implementation-related issues
   are discussed only briefly, in Section 8.

   TFRC is designed to be reasonably fair when competing for bandwidth
   with TCP flows, where we call a flow "reasonably fair" if its sending
   rate is generally within a factor of two of the sending rate of a TCP
   flow under the same conditions.  However, TFRC has a much lower
   variation of throughput over time compared with TCP, which makes it
   more suitable for applications such as telephony or streaming media
   where a relatively smooth sending rate is of importance.

   The penalty of having smoother throughput than TCP while competing
   fairly for bandwidth is that TFRC responds slower than TCP to changes
   in available bandwidth.  Thus, TFRC should only be used when the
   application has a requirement for smooth throughput, in particular,
   avoiding TCP's halving of the sending rate in response to a single
   packet drop.  For applications that simply need to transfer as much
   data as possible in as short a time as possible, we recommend using
   TCP, or if reliability is not required, using an Additive-Increase,
   Multiplicative-Decrease (AIMD) congestion control scheme with similar
   parameters to those used by TCP.

   TFRC is designed for best performance with applications that use a
   fixed segment size, and vary their sending rate in packets per second
   in response to congestion.  TFRC can also be used, perhaps with less
   optimal performance, with applications that do not have a fixed
   segment size, but where the segment size varies according to the
   needs of the application (e.g., video applications).

   Some applications (e.g., some audio applications) require a fixed
   interval of time between packets and vary their segment size instead
   of their packet rate in response to congestion.  The congestion
   control mechanism in this document is not designed for those
   applications; TFRC-SP (Small-Packet TFRC) is a variant of TFRC for
   applications that have a fixed sending rate in packets per second but
   either use small packets or vary their packet size in response to
   congestion.  TFRC-SP is specified in a separate document [RFC4828].

Top      ToC       Page 4 
   This document specifies TFRC as a receiver-based mechanism, with the
   calculation of the congestion control information (i.e., the loss
   event rate) in the data receiver rather in the data sender.  This is
   well-suited to an application where the sender is a large server
   handling many concurrent connections, and the receiver has more
   memory and CPU cycles available for computation.  In addition, a
   receiver-based mechanism is more suitable as a building block for
   multicast congestion control.  However, it is also possible to
   implement TFRC in sender-based variants, as allowed in DCCP's
   Congestion Control ID 3 (CCID 3) [RFC4342].

   This document obsoletes RFC 3448.  In the transport protocol DCCP
   (Datagram Congestion Control Protocol) [RFC4340], the Congestion
   Control ID Profiles CCID-3 [RFC4342] and CCID-4 [CCID-4] both specify
   the use of TFRC from RFC 3448.  CCID-3 and CCID-4 implementations
   SHOULD use this document instead of RFC 3448 for the specification of
   TFRC.

   The normative specification of TFRC is in Sections 3-6.  Section 7
   discusses sender-based variants, Section 8 discusses implementation
   issues, and Section 9 gives a non-normative overview of differences
   with RFC 3448.

2.  Conventions

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

   Appendix A gives a list of technical terms used in this document.

3.  Protocol Mechanism

   For its congestion control mechanism, TFRC directly uses a throughput
   equation for the allowed sending rate as a function of the loss event
   rate and round-trip time.  In order to compete fairly with TCP, TFRC
   uses the TCP throughput equation, which roughly describes TCP's
   sending rate as a function of the loss event rate, round-trip time,
   and segment size.  We define a loss event as one or more lost or
   marked packets from a window of data, where a marked packet refers to
   a congestion indication from Explicit Congestion Notification (ECN)
   [RFC3168].

   Generally speaking, TFRC's congestion control mechanism works as
   follows:

   o   The receiver measures the loss event rate and feeds this
       information back to the sender.

Top      ToC       Page 5 
   o   The sender also uses these feedback messages to measure the
       round-trip time (RTT).

   o   The loss event rate and RTT are then fed into TFRC's throughput
       equation, and the resulting sending rate is limited to at most
       twice the receive rate to give the allowed transmit rate X.

   o   The sender then adjusts its transmit rate to match the allowed
       transmit rate X.

   The dynamics of TFRC are sensitive to how the measurements are
   performed and applied.  We recommend specific mechanisms below to
   perform and apply these measurements.  Other mechanisms are possible,
   but it is important to understand how the interactions between
   mechanisms affect the dynamics of TFRC.

3.1.  TCP Throughput Equation

   Any realistic equation giving TCP throughput as a function of loss
   event rate and RTT should be suitable for use in TFRC.  However, we
   note that the TCP throughput equation used must reflect TCP's
   retransmit timeout behavior, as this dominates TCP throughput at
   higher loss rates.  We also note that the assumptions implicit in the
   throughput equation about the loss event rate parameter have to be a
   reasonable match to how the loss rate or loss event rate is actually
   measured.  While this match is not perfect for the throughput
   equation and loss rate measurement mechanisms given below, in
   practice the assumptions turn out to be close enough.

   The throughput equation currently REQUIRED for TFRC is a slightly
   simplified version of the throughput equation for Reno TCP from
   [PFTK98].  Ideally, we would prefer a throughput equation based on
   selective acknowledgment (SACK) TCP, but no one has yet derived the
   throughput equation for SACK TCP, and simulations and experiments
   suggest that the differences between the two equations would be
   relatively minor [FF99] (Appendix B).

   The throughput equation for X_Bps, TCP's average sending rate in
   bytes per second, is:

                                s
   X_Bps = ----------------------------------------------------------
           R*sqrt(2*b*p/3) + (t_RTO * (3*sqrt(3*b*p/8)*p*(1+32*p^2)))

   Where:

      X_Bps is TCP's average transmit rate in bytes per second.  (X_Bps
      is the same as X_calc in RFC 3448.)

Top      ToC       Page 6 
      s is the segment size in bytes (excluding IP and transport
      protocol headers).

      R is the round-trip time in seconds.

      p is the loss event rate, between 0 and 1.0, of the number of loss
      events as a fraction of the number of packets transmitted.

      t_RTO is the TCP retransmission timeout value in seconds.

      b is the maximum number of packets acknowledged by a single TCP
      acknowledgement.

   Setting the TCP retransmission timeout value t_RTO:
   Implementations SHOULD set t_RTO = 4*R.  Implementations MAY choose
   to implement a more accurate calculation of t_RTO.  Implementations
   MAY also set t_RTO to max(4*R, one second), to match the recommended
   minimum of one second on the RTO [RFC2988].

   Setting the parameter b for delayed acknowledgements:
   Some current TCP connections use delayed acknowledgements, sending an
   acknowledgement for every two data packets received.  However, TCP is
   also allowed to send an acknowledgement for every data packet.  For
   the revised TCP congestion control mechanisms, [RFC2581bis] currently
   specifies that the delayed acknowledgement algorithm should be used
   with TCP.  However, [RFC2581bis] recommends increasing the congestion
   window during congestion avoidance by one segment per RTT even in the
   face of delayed acknowledgements, consistent with a TCP throughput
   equation with b = 1.  On an experimental basis, [RFC2581bis] allows
   for increases of the congestion window during slow-start that are
   also consistent with a TCP throughput equation with b = 1.  Thus, the
   use of b = 1 is consistent with [RFC2581bis].  The use of b = 1 is
   RECOMMENDED.

   With t_RTO=4*R and b=1, the throughput equation for X_Bps, the TCP
   sending rate in bytes per second, can be simplified as:

                                s
   X_Bps = -----------------------------------------------
           R * (sqrt(2*p/3) + 12*sqrt(3*p/8)*p*(1+32*p^2))

   In the future, updates to this document could specify different TCP
   equations to be substituted for this equation.  The requirement is
   that the throughput equation be a reasonable approximation of the
   sending rate of TCP for conformant TCP congestion control.

Top      ToC       Page 7 
   The throughput equation can also be expressed in terms of X_pps, the
   sending rate in packets per second, with

      X_pps =  X_Bps / s .

   The parameters s (segment size), p (loss event rate), and R (RTT)
   need to be measured or calculated by a TFRC implementation.  The
   measurement of s is specified in Section 4.1, the measurement of R is
   specified in Section 4.3, and the measurement of p is specified in
   Section 5.  In the rest of this document, data rates are measured in
   bytes per second unless otherwise specified.

3.2.  Packet Contents

   Before specifying the sender and receiver functionality, we describe
   the contents of the data packets sent by the sender and feedback
   packets sent by the receiver.  As TFRC will be used along with a
   transport protocol, we do not specify packet formats, as these depend
   on the details of the transport protocol used.

3.2.1.  Data Packets

   Each data packet sent by the data sender contains the following
   information:

   o   A sequence number. This number MUST be incremented by one for
       each data packet transmitted.  The field must be sufficiently
       large that it does not wrap causing two different packets with
       the same sequence number to be in the receiver's recent packet
       history at the same time.

   o   A timestamp indicating when the packet is sent.  We denote by
       ts_i the timestamp of the packet with sequence number i.  The
       resolution of the timestamp SHOULD typically be measured in
       milliseconds.

       This timestamp is used by the receiver to determine which losses
       belong to the same loss event.  The timestamp is also echoed by
       the receiver to enable the sender to estimate the round-trip
       time, for senders that do not save timestamps of transmitted data
       packets.

       We note that, as an alternative to a timestamp incremented in
       milliseconds, a "timestamp" that increments every quarter of a
       round-trip time MAY be used for determining when losses belong to
       the same loss event, in the context of a protocol where this is
       understood by both sender and receiver and where the sender saves
       the timestamps of transmitted data packets.

Top      ToC       Page 8 
   o   The sender's current estimate of the round-trip time. The
       estimate reported in packet i is denoted by R_i.  The round-trip
       time estimate is used by the receiver, along with the timestamp,
       to determine when multiple losses belong to the same loss event.
       The round-trip time estimate is also used by the receiver to
       determine the interval to use for calculating the receive rate
       and to determine when to send feedback packets.

       If the sender sends a coarse-grained "timestamp" that increments
       every quarter of a round-trip time, as discussed above, then the
       sender is not required to send its current estimate of the round
       trip time.

3.2.2.  Feedback Packets

   Each feedback packet sent by the data receiver contains the following
   information:

   o   The timestamp of the last data packet received. We denote this by
       t_recvdata.  If the last packet received at the receiver has
       sequence number i, then t_recvdata = ts_i.  This timestamp is
       used by the sender to estimate the round-trip time, and is only
       needed if the sender does not save the 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.  We denote this by t_delay.

   o   The rate at which the receiver estimates that data was received
       in the previous round-trip time.  We denote this by X_recv.

   o   The receiver's current estimate of the loss event rate p.

4.  Data Sender Protocol

   The data sender sends a stream of data packets to the data receiver
   at a controlled rate.  When a feedback packet is received from the
   data receiver, the data sender changes its sending rate based on the
   information contained in the feedback report.  If the sender does not
   receive a feedback report for four round-trip times, then the sender
   cuts its sending rate in half.  This is achieved by means of a timer
   called the nofeedback timer.

Top      ToC       Page 9 
   We specify the sender-side protocol in the following steps:

   o   Measurement of the mean segment size being sent.

   o   Sender initialization.

   o   The sender behavior when a feedback packet is received.

   o   The sender behavior when the nofeedback timer expires.

   o   Oscillation prevention (optional).

   o   Scheduling of packet transmission and allowed burstiness.

4.1.  Measuring the Segment Size

   The TFRC sender uses the segment size, s, in the throughput equation,
   in the setting of the maximum receive rate, the setting of the
   minimum and initial sending rates, and the setting of the nofeedback
   timer.  The TFRC receiver MAY use the average segment size, s, in
   initializing the loss history after the first loss event.  As
   specified in Section 6.3.1, if the TFRC receiver does not know the
   segment size, s, used by the sender, the TFRC receiver MAY instead
   use the arrival rate in packets per second in initializing the loss
   history.

   The segment size is normally known to an application.  This may not
   be so in two cases:

   1)  The segment size naturally varies depending on the data.  In this
       case, although the segment size varies, that variation is not
       coupled to the transmit rate.  The TFRC sender can either compute
       the average segment size or use the maximum segment size for the
       segment size, s.

   2)  The application needs to change the segment size rather than the
       number of segments per second to perform congestion control.
       This would normally be the case with packet audio applications
       where a fixed interval of time needs to be represented by each
       packet.  Such applications need to have a completely different
       way of measuring parameters.

   For the first class of applications where the segment size varies
   depending on the data, the sender SHOULD estimate the segment size,
   s, as the average segment size over the last four loss intervals.
   The sender MAY estimate the average segment size over longer time
   intervals, if so desired.

Top      ToC       Page 10 
   The second class of applications are discussed separately in a
   separate document on TFRC-SP [RFC4828].  For the remainder of this
   section we assume the sender can estimate the segment size and that
   congestion control is performed by adjusting the number of packets
   sent per second.

4.2.  Sender Initialization

   The initial values for X (the allowed sending rate in bytes per
   second) and tld (the Time Last Doubled during slow-start, in seconds)
   are undefined until they are set as described below.  If the sender
   is ready to send data when it does not yet have a round-trip sample,
   the value of X is set to s bytes per second, for segment size s, the
   nofeedback timer is set to expire after two seconds, and tld is set
   to 0 (or to -1, either one is okay).  Upon receiving the first
   round-trip time measurement (e.g., after the first feedback packet or
   the SYN exchange from the connection setup, or from a previous
   connection [RFC2140]), tld is set to the current time, and the
   allowed transmit rate, X, is set to the initial_rate, specified as
   W_init/R, for W_init based on [RFC3390]:

      initial_rate = W_init/R; W_init = min(4*MSS, max(2*MSS, 4380)).

   In computing W_init, instead of using Maximum Segment Size (MSS), the
   TFRC sender SHOULD use the maximum segment size to be used for the
   initial round-trip time of data, if that is known by the TFRC sender
   when X is initialized.

   For responding to the initial feedback packet, this replaces step (4)
   of Section 4.3 below.

   Appendix B explains why the initial value of TFRC's nofeedback timer
   is set to two seconds, instead of the recommended initial value of
   three seconds for TCP's retransmit timer from [RFC2988].

4.3.  Sender Behavior When a Feedback Packet Is Received

   The sender knows its current allowed sending rate, X, and maintains
   an estimate of the current round-trip time R.  The sender also
   maintains X_recv_set as a small set of recent X_recv values
   (typically only two values).

   Initialization: X_recv_set is first initialized to contain a single
   item, with value Infinity.  (As an implementation-specific issue,
   X_recv_set MAY be initialized to a large number instead of to
   Infinity, e.g., to the largest integer that is easily representable.)

Top      ToC       Page 11 
   When a feedback packet is received by the sender at time t_now, the
   current time in seconds, the following actions MUST be performed.

   1)  Calculate a new round-trip sample:

      R_sample = (t_now - t_recvdata) - t_delay.

   As described in Section 3.2.2, t_delay gives the elapsed time at the
   receiver.

   2)  Update the round-trip time estimate:

      If no feedback has been received before {
          R = R_sample;
      } Else {
          R = q*R + (1-q)*R_sample;
      }

   TFRC is not sensitive to the precise value for the filter constant q,
   but a default value of 0.9 is RECOMMENDED.

   3)  Update the timeout interval:

      RTO = max(4*R, 2*s/X)

   4)  Update the allowed sending rate as follows.  This procedure uses
       the variables t_mbi and recv_limit:

      t_mbi: the maximum backoff interval of 64 seconds.
      recv_limit: the limit on the sending rate computed from
                       X_recv_set.

   This procedure also uses the procedures Maximize X_recv_set() and
   Update X_recv_set(), which are defined below.

Top      ToC       Page 12 
   The procedure for updating the allowed sending rate:

      If (the entire interval covered by the feedback packet
            was a data-limited interval) {
          If (the feedback packet reports a new loss event or an
                       increase in the loss event rate p) {
              Halve entries in X_recv_set;
              X_recv = 0.85 * X_recv;
              Maximize X_recv_set();
              recv_limit = max (X_recv_set);
          } Else {
              Maximize X_recv_set();
              recv_limit = 2 * max (X_recv_set);
          }
      } Else {                      // typical behavior
          Update X_recv_set();
          recv_limit = 2 * max (X_recv_set);
      }
      If (p > 0) {          // congestion avoidance phase
          Calculate X_Bps using the TCP throughput equation.
          X = max(min(X_Bps, recv_limit), s/t_mbi);
      } Else if (t_now - tld >= R) {
          // initial slow-start
          X = max(min(2*X, recv_limit), initial_rate);
          tld = t_now;
      }

   5)  If oscillation reduction is used, calculate the instantaneous
       transmit rate, X_inst, following Section 4.5.

   6)  Reset the nofeedback timer to expire after RTO seconds.

   The procedure for maximizing X_recv_set keeps a single value, the
   largest value from X_recv_set and the new X_recv.

      Maximize X_recv_set():
          Add X_recv to X_recv_set;
          Delete initial value Infinity from X_recv_set,
             if it is still a member.
          Set the timestamp of the largest item to the current time;
          Delete all other items.

Top      ToC       Page 13 
   The procedure for updating X_recv_set keeps a set of X_recv values
   with timestamps from the two most recent round-trip times.

      Update X_recv_set():
          Add X_recv to X_recv_set;
          Delete from X_recv_set values older than
              two round-trip times.

   Definition of a data-limited interval:
   We define a sender as data-limited any time it is not sending as much
   as it is allowed to send.  We define an interval as a 'data-limited
   interval' if the sender was data-limited over the *entire* interval;
   Section 8.2.1 discusses implementation issues for a sender in
   determining if an interval was a data-limited interval.  The term
   'data-limited interval' is used in the first "if" condition in step
   (4), which prevents a sender from having to reduce its sending rate
   as a result of a feedback packet reporting the receive rate from a
   data-limited period.

   As an example, consider a sender that is sending at its full allowed
   rate, except that it is sending packets in pairs, rather than sending
   each packet as soon as it can.  Such a sender is considered data-
   limited part of the time, because it is not always sending packets as
   soon as it can.  However, consider an interval that covers this
   sender's transmission of at least two data packets; such an interval
   does not meet the definition of a data-limited interval because the
   sender was not data-limited *over the entire interval*.

   If the feedback packet reports a receive rate X_recv of zero (i.e.,
   the first feedback packet), the sender does not consider that the
   entire interval covered by the feedback packet was a data-limited
   interval.

   X_recv_set and the first feedback packet:
   Because X_recv_set is initialized with a single item, with value
   Infinity, recv_limit is set to Infinity for the first two round-trip
   times of the connection.  As a result, the sending rate is not
   limited by the receive rate during that period.  This avoids the
   problem of the sending rate being limited by the value of X_recv from
   the first feedback packet.

   The interval covered by a feedback packet:
   How does the sender determine the period covered by a feedback
   packet?  This is discussed in more detail in Section 8.2.  In
   general, the receiver will be sending a feedback packet once per
   round-trip time; so typically, the sender will be able to determine
   exactly the period covered by the current feedback packet from the
   previous feedback packet.  However, in cases when the previous

Top      ToC       Page 14 
   feedback packet was lost, or when the receiver sends a feedback
   packet early because it detected a lost or ECN-marked packet, the
   sender will have to estimate the interval covered by the feedback
   packet.  As specified in Section 6.2, each feedback packet sent by
   the receiver covers a round-trip time, for the round-trip time
   estimate R_m maintained by the receiver R_m seconds before the
   feedback packet was sent.

   The response to a loss during a data-limited interval:
   In TFRC, after the initial slow-start, the sender always updates the
   calculated transmit rate, X_Bps, after a feedback packet is received,
   and the allowed sending rate, X, is always limited by X_Bps.
   However, during a data-limited interval, when the actual sending rate
   is usually below X_Bps, the sending rate is still limited by
   recv_limit, derived from X_recv_set.  If the sender is data-limited,
   possibly with a varying sending rate from one round-trip time to the
   next, and is experiencing losses, then we decrease the entry in
   X_recv_set in order to reduce the allowed sending rate.

   The sender can detect a loss event during a data-limited period
   either from explicit feedback from the receiver, or from a reported
   increase in the loss event rate.  When the sender receives a feedback
   packet reporting such a loss event in a data-limited interval, the
   sender limits the allowed increases in the sending rate during the
   data-limited interval.

   The initial slow-start phase:
   Note that when p=0, the sender has not yet learned of any loss
   events, and the sender is in the initial slow-start phase.  In this
   initial slow-start phase, the sender can approximately double the
   sending rate each round-trip time until a loss occurs.  The
   initial_rate term in step (4) gives a minimum allowed sending rate
   during slow-start of the initial allowed sending rate.

   We note that if the sender is data-limited during slow-start, or if
   the connection is limited by the path bandwidth, then the sender is
   not necessarily able to double its sending rate each round-trip time;
   the sender's sending rate is limited to at most twice the past
   receive rate, or at most initial_rate, whichever is larger.  This is
   similar to TCP's behavior, where the sending rate is limited by the
   rate of incoming acknowledgement packets as well as by the congestion
   window.  Thus, in TCP's slow-start, for the most aggressive case of
   the TCP receiver acknowledging every data packet, the TCP sender's
   sending rate is limited to at most twice the rate of these incoming
   acknowledgment packets.

Top      ToC       Page 15 
   The minimum allowed sending rate:
   The term s/t_mbi ensures that when p > 0, the sender is allowed to
   send at least one packet every 64 seconds.

4.4.  Expiration of Nofeedback Timer

   This section specifies the sender's response to a nofeedback timer.
   The nofeedback timer could expire because of an idle period or
   because of data or feedback packets dropped in the network.

   This section uses the variable recover_rate.  If the TFRC sender has
   been idle ever since the nofeedback timer was set, the allowed
   sending rate is not reduced below the recover_rate.  For this
   document, the recover_rate is set to the initial_rate (specified in
   Section 4.2).  Future updates to this specification may explore other
   possible values for the recover_rate.

   If the nofeedback timer expires, the sender MUST perform the
   following actions:

   1)  Cut the allowed sending rate in half.

      If the nofeedback timer expires when the sender has had at least
      one RTT measurement, the allowed sending rate is reduced by
      modifying X_recv_set as described in the pseudocode below
      (including item (2)).  In the general case, the sending rate is
      limited to at most twice X_recv.  Modifying X_recv_set limits the
      sending rate, but still allows the sender to slow-start, doubling
      its sending rate each RTT, if feedback messages resume reporting
      no losses.

      If the sender has been idle since this nofeedback timer was set
      and X_recv is less than the recover_rate, then the allowed sending
      rate is not halved, and X_recv_set is not changed.  This ensures
      that the allowed sending rate is not reduced to less than half the
      recover_rate as a result of an idle period.

      In the general case, the allowed sending rate is halved in
      response to the expiration of the nofeedback timer.  The details,
      in the pseudocode below, depend on whether the sender is in slow-
      start, is in congestion avoidance limited by X_recv, or is in
      congestion avoidance limited by the throughput equation.

Top      ToC       Page 16 
      X_recv = max (X_recv_set);
      If (sender does not have an RTT sample,
          has not received any feedback from receiver,
          and has not been idle ever since the nofeedback timer
          was set) {
          // We do not have X_Bps or recover_rate yet.
          // Halve the allowed sending rate.
          X = max(X/2, s/t_mbi);
      } Else if (((p>0 && X_recv < recover_rate) or
            (p==0 && X < 2 * recover_rate)), and
             sender has been idle ever
             since nofeedback timer was set) {
          // Don't halve the allowed sending rate.
          Do nothing;
      } Else if (p==0) {
          // We do not have X_Bps yet.
          // Halve the allowed sending rate.
          X = max(X/2, s/t_mbi);
      } Else if (X_Bps > 2*X_recv)) {
          // 2*X_recv was already limiting the sending rate.
          // Halve the allowed sending rate.
          Update_Limits(X_recv;)
      } Else {
          // The sending rate was limited by X_Bps, not by X_recv.
          // Halve the allowed sending rate.
          Update_Limits(X_Bps/2);
      }

      The term s/t_mbi limits the backoff to one packet every 64
      seconds.

      The procedure Update_Limits() uses the variable timer_limit for
      the limit on the sending rate computed from the expiration of the
      nofeedback timer, as follows:

      Update_Limits(timer_limit):
          If (timer_limit < s/t_mbi)
              timer_limit = s/t_mbi;
          Replace X_recv_set contents with the single item
               timer_limit/2;
          Recalculate X as in step (4) of Section 4.3;

   2)  Restart the nofeedback timer to expire after max(4*R, 2*s/X)
       seconds.

   If the sender has been data-limited but not idle since the nofeedback
   timer was set, it is possible that the nofeedback timer expired
   because data or feedback packets were dropped in the network.  In

Top      ToC       Page 17 
   this case, the nofeedback timer is the backup mechanism for the
   sender to detect these losses, similar to the retransmit timer in
   TCP.

   Note that when the sender stops sending data for a period of time,
   the receiver will stop sending feedback.  When the sender's
   nofeedback timer expires, the sender could use the procedure above to
   limit the sending rate.  If the sender subsequently starts to send
   again, X_recv_set will be used to limit the transmit rate, and slow-
   start behavior will occur until the transmit rate reaches X_Bps.

   The TFRC sender's reduction of the allowed sending rate after the
   nofeedback timer expires is similar to TCP's reduction of the
   congestion window, cwnd, after each RTO seconds of an idle period,
   for TCP with Congestion Window Validation [RFC2861].

4.5.  Reducing Oscillations

   To reduce oscillations in queueing delay and sending rate in
   environments with a low degree of statistical multiplexing at the
   congested link, it is RECOMMENDED that the sender reduce the transmit
   rate as the queueing delay (and hence RTT) increases.  To do this,
   the sender maintains R_sqmean, a long-term estimate of the square
   root of the RTT, and modifies its sending rate depending on how the
   square root of R_sample, the most recent sample of the RTT, differs
   from the long-term estimate.  The long-term estimate R_sqmean is set
   as follows:

      If no feedback has been received before {
          R_sqmean = sqrt(R_sample);
      } Else {
          R_sqmean = q2*R_sqmean + (1-q2)*sqrt(R_sample);
      }

   Thus, R_sqmean gives the exponentially weighted moving average of the
   square root of the RTT samples.  The constant q2 should be set
   similarly to q, the constant used in the round-trip time estimate R.
   A value of 0.9 as the default for q2 is RECOMMENDED.

   When sqrt(R_sample) is greater than R_sqmean, then the current
   round-trip time is greater than the long-term average, implying that
   queueing delay is probably increasing.  In this case, the transmit
   rate is decreased to minimize oscillations in queueing delay.

   The sender obtains the base allowed transmit rate, X, as described in
   step (4) of Section 4.3 above.  It then calculates a modified
   instantaneous transmit rate X_inst, as follows:

Top      ToC       Page 18 
      X_inst = X * R_sqmean / sqrt(R_sample);
      If (X_inst < s/t_mbi)
          X_inst = s/t_mbi;

   Because we are using square roots, there is generally only a moderate
   difference between the instantaneous transmit rate X_inst and the
   allowed transmit rate X.  For example, in a somewhat extreme case
   when the current RTT sample R_sample is twice as large as the long-
   term average, then sqrt(R_sample) will be roughly 1.44 times
   R_sqmean, and the allowed transmit rate will be reduced by a factor
   of roughly 0.7.

   We note that this modification for reducing oscillatory behavior is
   not always needed, especially if the degree of statistical
   multiplexing in the network is high.  We also note that the
   modification for reducing oscillatory behavior could cause problems
   for connections where the round-trip time is not strongly correlated
   with the queueing delay (e.g., in some wireless links, over paths
   with frequent routing changes, etc.).  However, this modification
   SHOULD be implemented because it makes TFRC behave better in some
   environments with a low level of statistical multiplexing.  The
   performance of this modification is illustrated in Section 3.1.3 of
   [FHPW00].  If it is not implemented, implementations SHOULD use a
   very low value of the weight q for the average round-trip time.

4.6.  Scheduling of Packet Transmissions

   As TFRC is rate-based, and as operating systems typically cannot
   schedule events precisely, it is necessary to be opportunistic about
   sending data packets so that the correct average rate is maintained
   despite the coarse-grain or irregular scheduling of the operating
   system.  To help maintain the correct average sending rate, the TFRC
   sender MAY send some packets before their nominal send time.

   In addition, the scheduling of packet transmissions controls the
   allowed burstiness of senders after an idle or data-limited period.
   The TFRC sender MAY accumulate sending 'credits' for past unused send
   times; this allows the TFRC sender to send a burst of data after an
   idle or data-limited period.  To compare with TCP, TCP may send up to
   a round-trip time's worth of packets in a single burst, but never
   more.  As examples, packet bursts can be sent by TCP when an ACK
   arrives acknowledging a window of data, or when a data-limited sender
   suddenly has a window of data to send after a delay of nearly a
   round-trip time.

Top      ToC       Page 19 
   To limit burstiness, a TFRC implementation MUST prevent bursts of
   arbitrary size.  This limit MUST be less than or equal to one round-
   trip time's worth of packets.  A TFRC implementation MAY limit bursts
   to less than a round-trip time's worth of packets.  In addition, a
   TFRC implementation MAY use rate-based pacing to smooth bursts.

   As an implementation-specific example, a sending loop could calculate
   the correct inter-packet interval, t_ipi, as follows:

      t_ipi = s/X_inst;

   Let t_now be the current time and i be a natural number, i = 0, 1,
   ..., with t_i the nominal send time for the i-th packet.  Then, the
   nominal send time t_(i+1) would derive recursively as:

      t_0 = t_now,
      t_(i+1) = t_i + t_ipi.

   For TFRC senders allowed to accumulate sending credits for unused
   send time over the last T seconds, the sender would be allowed to use
   unused nominal send times t_j for t_j < now - T, for T set to the
   round-trip time.



(page 19 continued on part 2)

Next RFC Part