TCP Friendly Rate Control (TFRC): Protocol Specification
obsoletes
- rfc-3448 — TCP Friendly Rate Control (TFRC): Protocol Specification
updates
- rfc-4342 — Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)
Extracted elements (28)
During data-limited intervals, the sender avoids reducing its allowed sending rate in response to receive-rate feedback, because low X_recv during a data-limited period does not indicate network congestion. X_recv_set is initialized to {Infinity} so the first feedback packet does not artificially cap the sending rate.
TFRC deliberately trades faster bandwidth adaptation for smoother throughput: it responds slower than TCP to changes in available bandwidth but avoids TCP's halving of the sending rate on a single drop. This makes it suitable for streaming and telephony but inappropriate for bulk transfer applications.
TFRC is specified as a receiver-based mechanism (loss event rate computed at receiver) rather than sender-based, because it is well-suited to large servers handling many connections where the receiver has spare CPU, and because it is a better building block for multicast congestion control. Sender-based variants are permitted via DCCP CCID-3.
The initial nofeedback timer is set to 2 seconds rather than TCP's recommended 3-second initial RTO (RFC 2988), because TFRC's initial sending rate is much lower than TCP's (1 packet per RTT vs. a full window), so the expected time to receive the first feedback packet is shorter. See Appendix B for full analysis.
DCCP Congestion Control ID profiles CCID-3 (RFC 4342) and CCID-4 SHOULD use RFC 5348 instead of RFC 3448 for the TFRC specification. RFC 5348 obsoletes RFC 3448 and updates RFC 4342; the main change is adding mechanisms to handle data-limited senders and incorporating RFC 3390's higher initial sending rates.
A lost packet is detected upon arrival of at least NDUPACK=3 packets with higher sequence numbers, mirroring TCP behavior for robustness against reordering. Unlike TCP, a late-arriving packet in TFRC can still fill the hole and cause recalculation of the loss event rate.
A TFRC implementation MUST prevent bursts of arbitrary size; the burst limit MUST be less than or equal to one round-trip time's worth of packets. Implementations MAY use rate-based pacing to smooth bursts within that limit.
After the first loss event, the TFRC receiver MUST initialize the loss history by computing a synthetic first loss interval: the receiver finds p such that the throughput equation gives a rate within 5% of X_target = max(X_recv_max, 0.5/R), then seeds the loss history with I_0 = 1/p.
If a lost packet is retransmitted, the retransmission MUST be given a new sequence number (the latest in the transmission sequence), not the original sequence number. Transport protocols requiring original sequence numbers must separately distinguish delayed from retransmitted packets.
If the nofeedback timer expires, the sender MUST halve the allowed sending rate (via X_recv_set manipulation), with a minimum of s/t_mbi (one packet per 64 seconds). Exception: if the sender was idle and X_recv < recover_rate (initial_rate), the rate is not halved. The timer is restarted to max(4*R, 2*s/X).
Implementations SHOULD set the TCP retransmission timeout value t_RTO = 4*R. Implementations MAY use max(4*R, one second) to match the recommended minimum RTO from RFC 2988.
On sender initialization before any RTT sample, X is set to s bytes/second, the nofeedback timer is set to 2 seconds, and tld=0. Upon receiving the first RTT measurement, X is set to initial_rate = W_init/R where W_init = min(4*MSS, max(2*MSS, 4380)), following RFC 3390.
The data packet sequence number MUST be incremented by one for each packet transmitted, and the field must be large enough that it does not wrap such that two different packets with the same sequence number exist in the receiver's recent history simultaneously.
The number of loss intervals n used in calculating the loss event rate is RECOMMENDED to be 8. TFRC SHOULD NOT use values of n greater than 8 for traffic competing with TCP on the global Internet, as this would require additional mechanisms to handle sustained heavy loss.
The receiver SHOULD send feedback at least once per RTT; if the sender's rate is less than one packet per RTT, feedback SHOULD be sent for every data packet received. Feedback SHOULD also be sent immediately upon detection of a new loss event, without waiting for the timer.
The throughput equation from Reno TCP (simplified with t_RTO=4*R and b=1) is REQUIRED for TFRC: X_Bps = s / (R * (sqrt(2*p/3) + 12*sqrt(3*p/8)*p*(1+32*p^2))). This equation must reflect TCP's retransmit timeout behavior.
The use of b=1 (one packet per acknowledgement) in the throughput equation is RECOMMENDED, consistent with RFC 2581bis which specifies increasing the congestion window by one segment per RTT even with delayed acknowledgements.
To reduce oscillations in queueing delay, the sender SHOULD maintain R_sqmean (EWMA of sqrt(RTT)) and compute an instantaneous rate X_inst = X * R_sqmean / sqrt(R_sample). This dampens the sending rate when the current RTT exceeds the long-term average. The constant q2=0.9 is RECOMMENDED.
When a feedback packet is received, the sender MUST: compute a new RTT sample R_sample = (t_now - t_recvdata) - t_delay, update R with exponential filter (q=0.9 RECOMMENDED), update RTO = max(4*R, 2*s/X), update the allowed sending rate X via the X_recv_set procedure, and reset the nofeedback timer to RTO seconds.
Each data packet sent by the TFRC sender MUST contain: a sequence number (incremented by one per packet, large enough to avoid wrap causing ambiguity), a millisecond-resolution timestamp (ts_i), and the sender's current RTT estimate (R_i). These fields are used by the receiver to compute loss event rate and feedback timing.
Each feedback packet from the TFRC receiver contains: the timestamp of the last data packet received (t_recvdata), the elapsed time since that packet was received (t_delay), the estimated receive rate over the previous RTT (X_recv), and the receiver's current loss event rate estimate (p).
Loss events are determined by grouping consecutive lost/marked packets within one RTT window. Two lost packets S_old and S_new belong to the same loss event if T_old + R >= T_new, where arrival times are interpolated from neighboring received packets for lost ones and measured directly for ECN-marked ones.
The loss event rate p is computed as 1/I_mean, where I_mean is the weighted average of the n most recent loss intervals. Weights w_i = 1 for i < n/2 and w_i = 2*(n-i)/(n+2) for i >= n/2, giving (for n=8): 1.0, 1.0, 1.0, 1.0, 0.8, 0.6, 0.4, 0.2. The current interval I_0 is only included if it increases I_mean.
The optional history discounting mechanism adjusts the weighted loss interval computation by a general discount factor DF = max(2*I_mean/I_0, THRESHOLD=0.25) when I_0 > 2*I_mean, reducing the relative weight on older intervals. This allows TFRC to respond more quickly to the sudden absence of congestion.
X_recv_set is a small set (typically 2–3 values) of recent receive-rate measurements maintained by the sender. It is initialized to {Infinity}. The Update procedure keeps values from the two most recent RTTs; the Maximize procedure keeps only the single largest value. The sender's recv_limit is derived as twice the maximum of X_recv_set.
A misbehaving receiver can cause a TFRC sender to send at an arbitrarily high rate by reporting an artificially low loss event rate or high receive rate. Sender-based variants (e.g., DCCP CCID-3 with Ack Vector and ECN Nonce Echo) allow the sender to verify the receiver's loss reports, mitigating this attack.
In DCCP deployments, a receiver could spoof feedback packets to manipulate the sender's rate. RFC 4340's security mechanisms (e.g., Init Cookies) address this threat. Section 10.1 notes that TFRC-in-DCCP inherits DCCP's security properties for protecting feedback integrity.
The TFRC sender operates in two phases: initial slow-start (p=0), where the sending rate approximately doubles each RTT up to twice the receive rate; and congestion avoidance (p>0), where X = max(min(X_Bps, recv_limit), s/t_mbi). Transition from slow-start to congestion avoidance is triggered by the first reported loss event.