RFC 5348
TCP Friendly Rate Control (TFRC): Protocol Specification
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.
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.
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).
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).
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.
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); } }
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.
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
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.
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
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.
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
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.
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
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
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.
[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.
[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/>.
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
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.