tech-invite   World Map     

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

RFC 5348

 
 
 

TCP Friendly Rate Control (TFRC): Protocol Specification

Part 3 of 3, p. 39 to 58
Prev RFC Part

 


prevText      Top      Up      ToC       Page 39 
10.  Security Considerations

   TFRC is not a transport protocol in its own right, but a congestion
   control mechanism that is intended to be used in conjunction with a
   transport protocol.  Therefore, security primarily needs to be
   considered in the context of a specific transport protocol and its
   authentication mechanisms.

   Congestion control mechanisms can potentially be exploited to create
   denial of service.  This may occur through spoofed feedback.  Thus,
   any transport protocol that uses TFRC should take care to ensure that
   feedback is only accepted from the receiver of the data.  The precise
   mechanism to achieve this will however depend on the transport
   protocol itself.

   In addition, congestion control mechanisms may potentially be
   manipulated by a greedy receiver that wishes to receive more than its
   fair share of network bandwidth.  A receiver might do this by
   claiming to have received packets that, in fact, were lost due to
   congestion.  Possible defenses against such a receiver would normally
   include some form of nonce that the receiver must feed back to the
   sender to prove receipt.  However, the details of such a nonce would
   depend on the transport protocol, and in particular on whether the
   transport protocol is reliable or unreliable.

Top      Up      ToC       Page 40 
   We expect that protocols incorporating ECN with TFRC will also want
   to incorporate feedback from the receiver to the sender using the ECN
   nonce [RFC3540].  The ECN nonce is a modification to ECN that
   protects the sender from the accidental or malicious concealment of
   marked packets.  Again, the details of such a nonce would depend on
   the transport protocol, and are not addressed in this document.

10.1.  Security Considerations for TFRC in DCCP

   TFRC is currently used in Congestion Control ID 3 (CCID 3) [RFC4342]
   of the Datagram Congestion Control Protocol (DCCP) [RFC4340].  The
   Security Considerations section of RFC 4340 [RFC4340] (Section 18)
   discusses some of the security issues of DCCP, including sequence
   number validity checks to protect against hijacked connections.
   Section 18 of RFC 4340 also discusses mechanisms in DCCP to limit the
   potential impact of denial-of-service attacks.

   RFC 4342 specifies the use of TFRC in CCID 3.  RFC 4342 includes
   extensive discussions of the mechanisms the sender can use to verify
   the information sent by the receiver.  When ECN is used with CCID 3,
   the receiver returns ECN Nonce information to the sender, to allow
   the sender to verify information sent by the receiver.  When ECN is
   not used, Section 9 of RFC 4342 discusses how the sender could still
   use various techniques that might catch the receiver in an error in
   reporting congestion.  However, as stated in RFC 4342, this is not as
   robust or non-intrusive as the verification provided by the ECN
   Nonce.

11.  Acknowledgments

   We would like to acknowledge feedback and discussions on equation-
   based congestion control with a wide range of people, including
   members of the Reliable Multicast Research Group, the Reliable
   Multicast Transport Working Group, and the End-to-End Research Group.
   We would like to thank Dado Colussi, Gorry Fairhurst, Ladan Gharai,
   Wim Heirman, Eddie Kohler, Ken Lofgren, Mike Luby, Ian McDonald,
   Vladimir Moltchanov, Colin Perkins, Michele R., Gerrit Renker, Arjuna
   Sathiaseelan, Vladica Stanisic, Randall Stewart, Eduardo Urzaiz,
   Shushan Wen, and Wendy Lee (lhh@zsu.edu.cn) for feedback on earlier
   versions of this document, and to thank Mark Allman for his extensive
   feedback from using [RFC3448] to produce a working implementation.

Top      Up      ToC       Page 41 
Appendix A.  Terminology

   This document uses the following terms.  Timer variables (e.g.,
   t_now, tld) are assumed to be in seconds, with a timer resolution of
   at least a millisecond.

   data-limited interval:
      An interval where the sender is data-limited (not sending as much
      as it is allowed to send) over the entire interval (Section 4.3).

   DF: Discount factor for a loss interval (Section 5.5).

   initial_rate:
      Allowed initial sending rate.

   last_counter:
      Greatest received value of the window counter (Section 6.3).

   n:  Number of loss intervals.

   NDUPACK:
      Number of dupacks for inferring loss (constant) (Section 5.1).

   nofeedback timer:
      Sender-side timer (Section 4).

   p:  Estimated Loss Event Rate.

   p_prev:
      Previous value of p (Section 6.1).

   q:  Filter constant for RTT (constant) (Section 4.3).

   q2: Filter constant for long-term RTT (constant) (Section 4.6).

   R:  Estimated path round-trip time.

   R_m:
      A specific estimate of the path round-trip time (Sections 4.3, 6).

   R_sample:
      Measured path RTT (Section 4.3).

   R_sqmean:
      Long-term estimate of the square root of the RTT (Section 4.6).

   recover_rate:
      Allowed rate for resuming after an idle period (Section 4.4).

Top      Up      ToC       Page 42 
   recv_limit;
      Limit on sending rate computed from X_recv_set (Section 4.3).

   s:  Nominal packet size in bytes.

   S:  Sequence number.

   t_delay:
      Reported time delay between receipt of the last packet at the
      receiver and the generation of the feedback packet (Section
      3.2.2).

   t_delta:
      Parameter for flexibility in send time (Section 8.3).

   t_gran:
      Scheduling timer granularity of the operating system (constant)
      (Section 8.3).

   t_ipi:
      Inter-packet interval for sending packets (Section 4.6).

   t_mbi:
      Maximum RTO value of TCP (constant) (Section 4.3).

   t_recvdata:
      Timestamp of the last data packet received (Section 3.2.2).

   timer_limit:
      Limit on the sending rate from the expiration of the nofeedback
      timer (Section 4.4).

   tld:
      Time Last Doubled (Section 4.2).

   t_now:
      Current time (Section 4.3).

   t_RTO:
      Estimated RTO of TCP (Section 4.3).

   X:  Allowed transmit rate, as limited by the receive rate.

   X_Bps:
      Calculated sending rate in bytes per second (Section 3.1).

   X_pps:
      Calculated sending rate in packets per second (Section 3.1).

Top      Up      ToC       Page 43 
   X_inst:
      Instantaneous allowed transmit rate (Section 4.6).

   X_recv:
      Estimated receive rate at the receiver (Section 3.2.2).

   X_recv_set:
      A small set of recent X_recv values (Section 4.3).

   X_target:
      The target sending rate after the first loss event (Section
      6.3.1).

   W_init:
      TCP initial window (constant) (Section 4.2).

Appendix B.  The Initial Value of the Nofeedback Timer

   Why is the initial value of TFRC's nofeedback timer set to two
   seconds, instead of the recommended initial value of three seconds
   for TCP's retransmit timer, from [RFC2988]?  There is not any
   particular reason why TFRC's nofeedback timer should have the same
   initial value as TCP's retransmit timer.  TCP's retransmit timer is
   used not only to reduce the sending rate in response to congestion,
   but also to retransmit a packet that is assumed to have been dropped
   in the network.  In contrast, TFRC's nofeedback timer is only used to
   reduce the allowed sending rate, not to trigger the sending of a new
   packet.  As a result, there is no danger to the network for the
   initial value of TFRC's nofeedback timer to be smaller than the
   recommended initial value for TCP's retransmit timer.

   Further, when the nofeedback timer has not yet expired, TFRC has a
   more slowly responding congestion control mechanism than TCP, and
   TFRC's use of the receive rate for limiting the sending rate is
   somewhat less precise than TCP's use of windows and ack-clocking, so
   the nofeedback timer is a particularly important safety mechanism for
   TFRC.  For all of these reasons, it is perfectly reasonable for
   TFRC's nofeedback timer to have a smaller initial value than that of
   TCP's retransmit timer.

Top      Up      ToC       Page 44 
Appendix C.  Response to Idle or Data-Limited Periods

   Future work could explore alternate responses to using the receive
   rate during a data-limited period, and to responding to a loss event
   during a data-limited period.

   In particular, an Experimental RFC [RFC2861] specifies Congestion
   Window Validation (CWV) for TCP.  For this discussion, we use the
   term "Standard TCP" to refer to the TCP congestion control mechanisms
   in [RFC2581] and [RFC2581bis].  [RFC2861] specifies a different
   response to idle or data-limited periods than those of Standard TCP.
   With CWV, the TCP sender halves the congestion window after each RTO
   during an idle period, down to the initial window.  Similarly, with
   CWV the TCP sender halves the congestion window half-way down to the
   flight size after each RTO during a data-limited period.

   This document already specifies a TFRC response to idle periods that
   is similar to that of TCP with Congestion Window Validation.
   However, this document does not specify a TFRC response to data-
   limited periods similar to that of CWV.  Adding such a mechanism to
   TFRC would require a one-line change to step (4) of Section 4.3.  In
   particular, the sender's response to a feedback packet could be
   changed from:

      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);
          }
      }

Top      Up      ToC       Page 45 
   to:

      If (the entire interval covered by the feedback packet
            was a data-limited interval) {
          Multiply old entries in X_recv_set by 0.85;
          If (the feedback packet reports a new loss event or an
                       increase in the loss event rate p) {
              Multiply new value X_recv by 0.85.
          }
          Maximize X_recv_set();
          recv_limit = 2 * max (X_recv_set);
      }

   In particular, if the receive rate from before a data-limited period
   is saved in X_recv_set, then the change in step (4) above would
   multiply that receive rate by 0.85 each time that a feedback packet
   is received and the above code is executed.  As a result, after four
   successive round-trip times of data-limited intervals, the receive
   rate from before the data-limited period would be reduced by 0.85^4 =
   0.52.  Thus, this one-line change to step (4) of Section 4.3 would
   result in the allowed sending rate being halved for each four
   roundtrip times in which the sender was data-limited.  Because of the
   nature of X_recv_set, this mechanism would never reduce the allowed
   sending rate below twice the most recent receive rate.

   We note that in the suggested code above, with CWV-style behavior in
   response to data-limited intervals, we keep

      recv_limit = 2 * max (X_recv_set);

   instead of using

      recv_limit = max (X_recv_set);

   following loss events in data-limited intervals.  This relaxed
   response to a loss event is allowed because the CWV-style behavior
   itself limits rapid fluctuations in the sending rate during data-
   limited periods.

C.1.  Long Idle or Data-Limited Periods

   Table 1 summarizes the response of Standard TCP [RFC2581], TCP with
   Congestion Window Validation [RFC2861], Standard TFRC [RFC3448], and
   Revised TFRC (this document) in response to long idle or data-limited
   periods.  For the purposes of this section, we define a long period
   as a period of at least an RTO.

Top      Up      ToC       Page 46 
     Protocol         Long idle periods      Long data-limited periods
   --------------   --------------------     ----------------------
   Standard TCP:       Window -> initial.     Window increases for
                                              each cwnd of data.

   TCP with CWV:         Halve window         Reduce window half way
                   (not below initial cwnd).    to used window.

   Standard TFRC:        Halve rate            Rate limited to
                    (not below 2 pkts/rtt).      twice receive rate.
                    One RTT after sending pkt,
                    rate is limited by X_recv.

   Revised TFRC:         Halve rate             Rate limited to twice
                    (not below initial rate).     max (current X_recv,
                                                  receive rate before
                                                  data-limited period).

     Table 1: Response to Long Idle or Data-Limited Periods

   Standard TCP after long idle periods: For Standard TCP, [RFC2581]
   specifies that TCP SHOULD set the congestion window to no more than
   the initial window after an idle period of at least an RTO.  (To be
   precise, RFC 2581 specifies that the TCP sender should set cwnd to
   the initial window if the sender has not sent data in an interval
   exceeding the retransmission timeout.)

   Standard TCP after long data-limited periods: Standard TCP [RFC2581]
   does not reduce TCP's congestion window after a data-limited period,
   when the congestion window is not fully used.  Standard TCP in
   [RFC2581] uses the FlightSize, the amount of outstanding data in the
   network, only in setting the slow-start threshold after a retransmit
   timeout.  Standard TCP is not limited by TCP's ack-clocking mechanism
   during a data-limited period.

   Standard TCP's lax response to a data-limited period is quite
   different from its stringent response to an idle period.

   TCP with Congestion Window Validation (CWV) after long idle periods:
   As an experimental alternative, [RFC2861] specifies a more moderate
   response to an idle period than that of Standard TCP, where during an
   idle period the TCP sender halves cwnd after each RTO, down to the
   initial cwnd.

   TCP with Congestion Window Validation after long data-limited
   periods: As an experimental alternative, [RFC2861] specifies a more
   stringent response to a data-limited period than that of Standard
   TCP, where after each RTO seconds of a data-limited period, the

Top      Up      ToC       Page 47 
   congestion window is reduced half way down to the window that is
   actually used.

   The response of TCP with CWV to an idle period is similar to its
   response to a data-limited period.  TCP with CWV is less restrictive
   than Standard TCP in response to an idle period, and more restrictive
   than Standard TCP in response to a data-limited period.

   Standard TFRC after long idle periods: For Standard TFRC, [RFC3448]
   specifies that the allowed sending rate is halved after each RTO
   seconds of an idle period.  The allowed sending rate is not reduced
   below two packets per RTT after idle periods.  After an idle period,
   the first feedback packet received reports a receive rate of one
   packet per round-trip time, and this receive rate is used to limit
   the sending rate.  Standard TFRC effectively slow-starts up from this
   allowed sending rate.

   Standard TFRC after long data-limited periods: [RFC3448] does not
   distinguish between data-limited and non-data-limited periods.  As a
   consequence, the allowed sending rate is limited to at most twice the
   receive rate during and after a data-limited period.  This is a very
   restrictive response, more restrictive than that of either Standard
   TCP or of TCP with CWV.

   Revised TFRC after long idle periods: For Revised TFRC, this document
   specifies that the allowed sending rate is halved after each RTO
   seconds of an idle period.  The allowed sending rate is not reduced
   below the initial sending rate as the result of an idle period.  The
   first feedback packet received after the idle period reports a
   receive rate of one packet per round-trip time.  However, the Revised
   TFRC sender does not use this receive rate for limiting the sending
   rate.  Thus, Revised TFRC differs from Standard TFRC in the lower
   limit used in the reduction of the sending rate, and in the better
   response to the first feedback packet received after the idle period.

   Revised TFRC after long data-limited periods: For Revised TFRC, this
   document distinguishes between data-limited and non-data-limited
   periods.  As specified in Section 4.3, during a data-limited period
   Revised TFRC remembers the receive rate before the data-limited
   period began, and does not reduce the allowed sending rate below
   twice that receive rate.  This is somewhat similar to the response of
   Standard TCP, and is quite different from the very restrictive
   response of Standard TFRC to a data-limited period.  However, the
   response of Revised TFRC is not as conservative as the response of
   TCP with Congestion Window Validation, where the congestion window is
   gradually reduced down to the window actually used during a data-
   limited period.

Top      Up      ToC       Page 48 
   We note that for current TCP implementations, the congestion window
   is generally not increased during a data-limited period (when the
   current congestion window is not being fully used) [MAF05] (Section
   5.7).  We note that there is no mechanism comparable to this in
   Revised TFRC.

   Recovery after idle or data-limited periods: When TCP reduces the
   congestion window after an idle or data-utilized period, TCP can set
   the slow-start threshold, ssthresh, to allow the TCP sender to slow-
   start back up towards its old sending rate when the idle or data-
   limited period is over.  However, in TFRC, even when the TFRC
   sender's sending rate is restricted by twice the previous receive
   rate, this results in the sender being able to double the sending
   rate from one round-trip time to the next, if permitted by the
   throughput equation.  Thus, TFRC does not need a mechanism such as
   TCP's setting of ssthresh to allow a slow-start after an idle or
   data-limited period.

   For future work, one avenue to explore would be the addition of
   Congestion Window Validation mechanisms for TFRC's response to data-
   limited periods.  Currently, following Standard TCP, during data-
   limited periods Revised TFRC does not limit its allowed sending rate
   as a function of the receive rate.

C.2.  Short Idle or Data-Limited Periods

   Table 2 summarizes the response of Standard TCP [RFC2581], TCP with
   Congestion Window Validation [RFC2861], Standard TFRC [RFC3448], and
   Revised TFRC (this document) in response to short idle or data-
   limited periods.  For the purposes of this section, we define a short
   period as a period of less than an RTT.

     Protocol         Short idle periods   Short data-limited periods
   --------------   --------------------     ----------------------
   Standard TCP:    Send a burst up to cwnd.  Send a burst up to cwnd.

   TCP with CWV:    Send a burst up to cwnd.  Send a burst up to cwnd.

   Standard TFRC:             ?                         ?

   Revised TFRC:         Send a burst               Send a burst
                        (up to an RTT of           (up to an RTT of
                      unused send credits).      unused send credits).

     Table 2: Response to Short Idle or Data-Limited Periods

   Table 2 shows that Revised TFRC has a similar response to that of
   Standard TCP and of TCP with CWV to a short idle or data-limited

Top      Up      ToC       Page 49 
   period.  For a short idle or data-limited period, TCP is limited only
   by the size of the unused congestion window, and Revised TFRC is
   limited only by the number of unused send credits (up to an RTT's
   worth).  For Standard TFRC, [RFC3448] did not explicitly specify the
   behavior with respect to unused send credits.

C.3.  Moderate Idle or Data-Limited Periods

   Table 3 summarizes the response of Standard TCP [RFC2581], TCP with
   Congestion Window Validation [RFC2861], Standard TFRC [RFC3448], and
   Revised TFRC (this document) in response to moderate idle or data-
   limited periods.  For the purposes of this section, we define a
   moderate period as a period greater than an RTT, but less than an
   RTO.

     Protocol      Moderate idle periods  Moderate data-limited periods
   -------------   ---------------------      -------------------------
   Standard TCP:    Send a burst up to cwnd.  Send a burst up to cwnd.

   TCP with CWV:    Send a burst up to cwnd.  Send a burst up to cwnd.

   Standard TFRC:             ?                   Limited by X_recv.

   Revised TFRC:         Send a burst               Send a burst
                        (up to an RTT of           (up to an RTT of
                      unused send credits).      unused send credits).

     Table 3: Response to Moderate Idle or Data-Limited Periods

   Table 3 shows that Revised TFRC has a similar response to that of
   Standard TCP and of TCP with CWV to a moderate idle or data-limited
   period.  For a moderate idle or data-limited period, TCP is limited
   only by the size of the unused congestion window.  For a moderate
   idle period, Revised TFRC is limited only by the number of unused
   send credits (up to an RTT's worth).  For a moderate data-limited
   period, Standard TFRC would be limited by X_recv from the most recent
   feedback packet.  In contrast, Revised TFRC is not limited by the
   receive rate from data-limited periods that cover an entire feedback
   period of a round-trip time.  For Standard TFRC, [RFC3448] did not
   explicitly specify the behavior with respect to unused send credits.

Top      Up      ToC       Page 50 
C.4.  Losses During Data-Limited Periods

   This section discusses the response to a loss during a data-limited
   period.

     Protocol      Response to a loss during a data-limited period
   -------------   -----------------------------------------------
   Standard TCP:   Set ssthresh, cwnd to FlightSize/2.

   TCP with CWV:   Same as Standard TCP.

   Standard TFRC:  Calculate X_Bps, send at most 2*X_recv.

   Revised TFRC:   Calculate X_Bps, send at most recv_limit.
                   In addition, modify X_recv_set.

     Table 4: Response to a Loss during a Data-Limited Period

   In TCP [RFC2581], the response to a loss during a data-limited period
   is the same as the response to a loss at any other time in TCP.  This
   response is to set the congestion window to half of the FlightSize,
   where the FlightSize is the actual amount of unacknowledged data.
   Thus, after a loss during a data-limited period, the TCP sender must
   halve its allowed sending rate, as it normally does in response to a
   loss.

   In Standard TFRC, the response to a loss during a data-limited period
   is also the same as the response to a loss at any other time in
   Standard TFRC.  The sending rate is limited by X_Bps, from the
   throughput equation, and the sending rate is also limited by twice
   X_recv, the most recent receive rate.  As a result, after a loss in a
   data-limited period, the sender can at most double its sending rate
   to twice X_recv, even if the throughput equation X_Bps would allow a
   sending rate much higher than that.

   In Revised TFRC, there have been changes to the use of the receive
   rate X_recv during data-limited intervals; the sender is limited to
   sending at most recv_limit, where the sender can remember the receive
   rate X_recv from just before the data-limited period.  This allows
   the sender to more than double its sending rate during data-limited
   periods, up to the receive rate from before the data-limited period
   (if allowed by the throughput equation as given in X_Bps).  This is
   similar to Standard TCP's practice of not reducing the window during
   data-limited periods (in the absence of loss).

   As with Standard TFRC, during a data-limited period the Revised TFRC
   sender is sending less than is allowed by the throughput equation
   X_Bps.  After the loss event, the sender still might not want to be

Top      Up      ToC       Page 51 
   sending as much as allowed by the recalculated value of X_Bps that
   takes into account the new loss event.  Revised TFRC adds an
   additional mechanism to gradually limit the sender's sending rate
   after losses during data-limited periods.  Unlike TCP's response of
   setting cwnd to half the FlightSize, this additional mechanism in
   Revised TFRC uses TFRC's practice of using slowly-responding changes
   for both increases and decreases in the allowed sending rate.

   This is done in Revised TFRC (in step (4) of Section 4.3) by
   decreasing the entry in X_recv_set after a loss in a data-limited
   interval, and by allowing the sender to send at most max
   (X_recv_set), instead of at most twice max (X_recv_set), in the
   immediate round-trip time following the reported loss.  Thus, the
   'price' for allowing the sender to send more than twice the most
   immediately reported value of X_recv during a data-limited interval
   is the introduction of an additional mechanism to reduce this allowed
   sending rate following losses in data-limited periods.

   In TFRC's response to a loss in a data-limited interval, we have
   considered the following examples.

   Example 1, Losses *after* a Data-Limited Period: This example shows
   that losses after a data-limited period has ended are addressed by
   the throughput equation X_Bps.

   -------------------------------------------------------------------
   Stage 1: Not data-limited.
            Sending 100 packets per round-trip time (PPR).
   Stage 2: Data-limited, sending 10 PPR.
   Stage 3: Not data-limited.
            Sending 100 PPR again, as allowed by X_Bps.
            A packet loss in the first RTT of Stage 3.
            X_Bps is updated,
   Response of Revised TFRC: a slight reduction in the allowed sending
     rate, depending on the number of packets since the last loss event.
   -------------------------------------------------------------------

      Table 5:  Example 1, Losses after a Data-Limited Period

   For example 1, when there is a packet loss in the first RTT of Stage
   3, this will be reflected in a modified value of X_Bps, and future
   loss events would result in future reductions of the throughput
   equation X_Bps.  In particular, following TFRC's standard use of the
   throughput equation [FHPW00] (Section A.2), the allowed TFRC sending
   rate would be halved after something like five successive round-trip
   times with loss.

Top      Up      ToC       Page 52 
   Example 2, a Mildly Data-Limited Sender: This example considers
   losses in a data-limited period when, during the data-limited period,
   the sender is sending *almost* as much as it is allowed to send.

   -------------------------------------------------------------------
   Stage 1: Not data-limited.  Sending 100 PPR.
   Stage 2: Data-limited, sending 99 PPR.
            A packet loss in Stage 2.
   Response of Revised TFRC: a slight reduction in the allowed sending
     rate, down to 85 PPR or less, depending on the number of packets
     since the last loss event.
   -------------------------------------------------------------------

      Table 6:  Example 2, a Mildly Data-Limited Sender

   Consider a Revised TFRC connection where the sender has been sending
   a hundred PPR and then enters a data-limited period of sending only
   99 PPR because of data limitations from the application.  (That is,
   at every instance of time during the data-limited period, the sender
   could have sent one more packet.)  If there are losses in the data-
   limited period, the allowed sending rate is reduced to min(X_Bps,
   recv_limit), where both the throughput equation X_Bps and the limit
   recv_limit force a slight reduction in the allowed sending rate.

   Example 3, a Single Packet Loss during a Data-Limited Period.  This
   example considers the loss of a single packet during a data-limited
   period, after the sender has not sent a packet for two RTTs.

   -------------------------------------------------------------------
   Stage 1: Not data-limited.  Sending 100 PPR.
   Stage 2: Data-limited, sending 10 PPR.
   Stage 3: Data-limited, sending no data for two RTTs.
   Stage 4: Data-limited, sending one packet, which is ECN-marked.
   Response of Revised TFRC: a reduction in the allowed sending
     rate, down to 50 PPR or less.  For each loss event during
     the data-limited period, the 'remembered' X_recv from before
     the data-limited period is effectively halved.
   -------------------------------------------------------------------

      Table 7:  Example 3, a Single Packet Loss

   Consider a Revised TFRC connection where the sender has been sending
   a hundred PPR, and then enters a data-limited period of sending only
   ten PPR, and then does not send any packets for two RTTs, and then
   sends a single packet, which is ECN-marked.  In this case, with
   Revised TFRC, for each loss event during the data-limited period, the
   sender halves its 'remembered' X_recv from before the data-limited
   period

Top      Up      ToC       Page 53 
   Example 4, Losses after Increasing the Sending Rate during a Data-
   Limited Period.  This example considers losses when the sender
   significantly increases its sending rate during a data-limited
   period.

   -------------------------------------------------------------------
   Stage 1: Not data-limited.  Sending 100 PPR.
   Stage 2: Data-limited, sending 1 PPR.
   Stage 3: Data-limited, sending 20 PPR.
            Several packets are lost in each RTT of Stage 3.
            During Stage 3, the sender would *like* to send 20 PPR.
   Response of Revised TFRC:  For each loss event during
     the data-limited period, the 'remembered' X_recv from before
     the data-limited period is effectively halved, and the most
     recent X_recv is reduced by 0.85.
   -------------------------------------------------------------------

      Table 8:  Example 4, Losses after Increasing the Sending Rate

   Consider a Revised TFRC connection where the sender has been sending
   a hundred PPR, and then enters a data-limited period of sending only
   one PPR, and then, while still data-limited, increases its sending
   rate to twenty PPR, where it experiences a number of successive loss
   events.

   In this case, with Revised TFRC, for each loss event during the
   data-limited period, the sender halves its 'remembered' X_recv from
   before the data-limited period, and the most recent X_recv is reduced
   by 0.85.

C.5.  Other Patterns

   Other possible patterns to consider in evaluating Revised TFRC would
   be to compare the behavior of TCP, Standard TFRC, and Revised TFRC
   for connections with alternating busy and idle periods, alternating
   idle and data-limited periods, or with idle or data-limited periods
   during slow-start.

C.6.  Evaluating TFRC's Response to Idle Periods

   In this section we focus on evaluating Revised TFRC's response to
   idle or data-limited periods.

   One drawback to Standard TFRC's strict response to idle or data-
   limited periods is that it could be seen as encouraging applications
   to pad their sending rate during idle or data-limited periods, by
   sending dummy data when there was no other data to send.  Because
   Revised TFRC has a less strict response to data-limited periods than

Top      Up      ToC       Page 54 
   that of Standard TFRC, Revised TFRC also could be seen as giving
   applications less of an incentive to pad their sending rates during
   data-limited periods.  Work in progress, such as Faster Restart
   [KFS07], can also decrease an application's incentive to pad its
   sending rate, by allowing faster start-up after idle periods.
   Further research would be useful to understand, in more detail, the
   interaction between TCP or TFRC's congestion control mechanisms, and
   an application's incentive to pad its sending rate during idle or
   data-limited periods.

   TCP Congestion Window Validation, described in Appendix C.1 above, is
   an Experimental standard specifying that the TCP sender slowly
   reduces the congestion window during an idle or data-limited period
   [RFC2861].  While TFRC and Revised TFRC's responses to idle periods
   are roughly similar to those of TCP with Congestion Window
   Validation, Revised TFRC's response to data-limited periods is less
   conservative than those of TCP with Congestion Window Validation (and
   Standard TFRC's response to data-limited periods was considerably
   *more* conservative than those of Congestion Window Validation).
   Future work could include modifications to this document so that the
   response of Revised TFRC to a data-limited period includes a slow
   reduction of the allowed sending rate; Section C specifies a possible
   mechanism for this.  Such a modification would be particularly
   compelling if Congestion Window Validation became a Proposed Standard
   in the IETF for TCP.

References

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.

Informative References

   [BRS99]      Balakrishnan, H., Rahul, H., and Seshan, S., "An
                Integrated Congestion Management Architecture for
                Internet Hosts," Proc. ACM SIGCOMM, Cambridge, MA,
                September 1999.

   [CCID-4]     Floyd, S., and E. Kohler, "Profile for DCCP Congestion
                Control ID 4: the Small-Packet Variant of TFRC
                Congestion Control", Work in Progress, February 2008.

Top      Up      ToC       Page 55 
   [FHPW00]     S. Floyd, M. Handley, J. Padhye, and J. Widmer,
                "Equation-Based Congestion Control for Unicast
                Applications", August 2000, Proc SIGCOMM 2000.

   [FHPW00a]    S. Floyd, M. Handley, J. Padhye, and J. Widmer,
                "Equation-Based Congestion Control for Unicast
                Applications: the Extended Version", ICSI tech report
                TR-00-03, March 2000.

   [FF99]       Floyd, S., and K. Fall, Promoting the Use of End-to-End
                Congestion Control in the Internet, IEEE/ACM
                Transactions on Networking, August 1999.

   [KFS07]      E. Kohler, S. Floyd, and A. Sathiaseelan, "Faster
                Restart for TCP Friendly Rate Control (TFRC)", Work in
                Progress, November 2007.

   [MAF05]      A. Medina, M. Allman, and S. Floyd, "Measuring the
                Evolution of Transport Protocols in the Internet", ACM
                Computer Communications Review, April 2005.

   [PFTK98]     Padhye, J. and  Firoiu, V. and Towsley, D. and Kurose,
                J., "Modeling TCP Throughput: A Simple Model and its
                Empirical Validation", Proc ACM SIGCOMM 1998.

   [RFC2140]    Touch, J., "TCP Control Block Interdependence", RFC
                2140, April 1997.

   [RFC2581]    Allman, M., Paxson, V., and W. Stevens, "TCP Congestion
                Control", RFC 2581, April 1999.

   [RFC2581bis] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion
                Control", Work in Progress, April 2008.

   [RFC2861]    Handley, M., Padhye, J., and S. Floyd, "TCP Congestion
                Window Validation", RFC 2861, June 2000.

   [RFC2988]    Paxson, V. and M. Allman, "Computing TCP's
                Retransmission Timer", RFC 2988, November 2000.

   [RFC3168]    Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
                of Explicit Congestion Notification (ECN) to IP", RFC
                3168, September 2001.

   [RFC3390]    Allman, M., Floyd, S., and C. Partridge, "Increasing
                TCP's Initial Window", RFC 3390, October 2002.

Top      Up      ToC       Page 56 
   [RFC3448Err] RFC 3448 Errata,
                <http://www.rfc-editor.org/errata_search.php?rfc=3448>.

   [RFC3540]    Spring, N., Wetherall, D., and D. Ely, "Robust Explicit
                Congestion Notification (ECN) Signaling with Nonces",
                RFC 3540, June 2003.

   [RFC4340]    Kohler, E., Handley, M., and S. Floyd, "Datagram
                Congestion Control Protocol (DCCP)", RFC 4340, 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.

   [RFC4828]    Floyd, S. and E. Kohler, "TCP Friendly Rate Control
                (TFRC): The Small-Packet (SP) Variant", RFC 4828, April
                2007.

   [W00]        Widmer, J., "Equation-Based Congestion Control", Diploma
                Thesis, University of Mannheim, February 2000,
                <http://www.icir.org/tfrc/>.

Top      Up      ToC       Page 57 
Authors' Addresses

   Sally Floyd
   ICSI
   1947 Center St, Suite 600
   Berkeley, CA 94708
   EMail: floyd@icir.org

   Mark Handley,
   Department of Computer Science
   University College London
   Gower Street
   London WC1E 6BT
   UK
   EMail: M.Handley@cs.ucl.ac.uk

   Jitendra Padhye
   Microsoft Research
   EMail: padhye@microsoft.com

   Joerg Widmer
   DoCoMo Euro-Labs
   Landsberger Strasse 312
   80687 Munich
   Germany
   EMail: widmer@acm.org

Top      Up      ToC       Page 58 
Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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 the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights 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; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.