ietf-corpus

rfc-3448

TCP Friendly Rate Control (TFRC): Protocol Specification

M. Handley, S. Floyd, J. Padhye, J. Widmer
date2003-01 streamIETF areawit wgtsvwg statusPROPOSED STANDARD pages24 canonicalhttps://www.rfc-editor.org/rfc/rfc3448 doi10.17487/RFC3448 errataview
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 telephony or streaming media where a relatively smooth sending rate is of importance. [STANDARDS-TRACK]

obsoleted by

Extracted elements (26)

design-rationale §1

TFRC is receiver-based: the receiver calculates the loss event rate and feeds it back to the sender. This suits servers handling many concurrent connections by offloading computation to clients, and is also better suited as a building block for multicast congestion control.

congestion, multicast

design-rationale §1

TFRC trades slower response to bandwidth changes for smoother throughput compared to TCP. It is suitable for telephony and streaming media where a relatively smooth sending rate matters, but TCP or AIMD should be preferred for bulk transfer because TFRC avoids TCP's halving of sending rate on a single drop.

congestion, realtime, rtp

design-rationale §7

The receiver-based TFRC variant is specified (rather than sender-based) because it is robust to feedback packet loss without requiring reliable delivery, better offloads work from servers to clients, and is a better building block for multicast congestion control. Sender-based variants would have tighter transport protocol requirements.

congestion, multicast

design-rationale §3.1

The throughput equation sets t_RTO=4*R as a simplification. A more accurate calculation is possible but experiments show reasonable fairness with existing TCP implementations. Setting b=1 is recommended because many TCP implementations do not use delayed acknowledgements.

congestion, tcp

normative-requirement §5.1 REQUIRED

A lost packet is detected only upon arrival of at least three packets with higher sequence numbers than the missing packet, matching TCP's reordering robustness threshold. An ECN-marked packet, however, is treated as a congestion event immediately on arrival.

congestion, ecn, tcp

normative-requirement §5.1 MUST

If a retransmission is required by the transport protocol, the retransmitted packet MUST use a new sequence number (not the original), so TFRC can distinguish delayed from retransmitted packets. Protocols that must retransmit with the original sequence number must resolve the ambiguity themselves.

congestion

normative-requirement §4.4 SHOULD

If no feedback is received for two round-trip times, the nofeedback timer fires and the sender SHOULD halve its sending rate by modifying X_recv. If no RTT sample exists yet, the sender cuts X directly by half down to s/t_mbi minimum (one packet per 64 seconds).

congestion

normative-requirement §4.4 MUST NOT

If the sender has been idle since the nofeedback timer was set and X_recv is less than four packets per RTT, X_recv MUST NOT be halved on timer expiration. This ensures the allowed rate never drops below two packets per RTT due to idleness.

congestion

normative-requirement §4.3 SHOULD

On receiving feedback, the sender SHOULD update RTT using R = q*R + (1-q)*R_sample with recommended q=0.9, set t_RTO=4*R, and update the sending rate: if p>0, X = max(min(X_calc, 2*X_recv), s/t_mbi); if p==0 (slow-start), double X at most once per RTT up to 2*X_recv.

congestion, tcp

normative-requirement §5.4 SHOULD NOT

TFRC SHOULD NOT be used with n significantly greater than 8 loss intervals for traffic competing on the global Internet with TCP. Safe operation with larger n would require a more severe response to two or more RTTs of heavy loss.

congestion, tcp

normative-requirement §6 MUST

The receiver MUST send a feedback packet at least once per RTT. If the sender transmits less than one packet per RTT, the receiver MUST send a feedback packet for every data packet received. A feedback packet MUST also be sent immediately whenever a new loss event is detected or an out-of-order packet removes a loss event.

congestion

normative-requirement §4.2 MUST

The sender MUST initialize X to 1 packet/second and set the nofeedback timer to expire after 2 seconds. The initial value of tld (time last doubled during slow-start) is set to -1; initial values of R and t_RTO are undefined until first feedback is received.

congestion

normative-requirement §6.1 MUST

When a data packet arrives that increases p (loss event rate), the receiver MUST immediately trigger the feedback timer expiration procedure, causing prompt feedback to the sender. If p does not increase, no immediate action is required.

congestion

protocol-element §6.3.1

After the first loss event, TFRC does not use the raw packet count to the first loss as the initial loss interval. Instead, it finds the value p for which the throughput equation yields a sending rate within 5% of X_recv, and sets the initial loss interval to 1/p, because the sending rate changes rapidly during slow-start.

congestion

protocol-element §3.2.1

Each TFRC data packet MUST contain: (1) a sequence number incremented by one per packet with sufficient width to avoid wrap-around collisions in recent history; (2) a millisecond-resolution timestamp ts_i used by the receiver to group losses into events and echoed for RTT estimation; (3) the sender's current RTT estimate R_i for use by the receiver in loss event grouping.

congestion

protocol-element §3.2.2

Each TFRC feedback packet contains: (1) t_recvdata, the timestamp of the last received data packet; (2) t_delay, the elapsed time between last data packet receipt and feedback generation; (3) X_recv, the estimated receive rate since the last feedback; (4) the receiver's current loss event rate estimate p.

congestion

protocol-element §5.2

Multiple lost or marked packets within one RTT are grouped into a single loss event. A new loss is part of an existing event if T_new <= T_old + R (using interpolated nominal arrival times). Lost packet arrival time is interpolated linearly between surrounding received packets' timestamps.

congestion, tcp

protocol-element §6.2

On feedback timer expiration, if data packets have been received, the receiver calculates the average loss event rate and X_recv over the previous R_m seconds, sends a feedback packet, and restarts the feedback timer for R_m seconds. If no data was received, the timer is restarted without sending feedback.

congestion

protocol-element §4.6

Packet scheduling computes inter-packet interval t_ipi = s/X_inst. To handle coarse OS scheduling granularity, each packet's nominal send time is calculated from the previous packet's nominal time (not actual time), and delta=min(t_ipi/2, t_gran/2) allows early transmission. t_gran defaults to 10ms.

congestion, realtime

protocol-element §3.1

TFRC uses the TCP throughput equation X = s / (R*sqrt(2*b*p/3) + t_RTO*(3*sqrt(3*b*p/8)*p*(1+32*p^2))), where X is transmit rate in bytes/second, s is packet size, R is RTT, p is loss event rate, t_RTO is retransmission timeout, and b is packets acknowledged per ACK. Simplified with t_RTO=4*R and b=1.

congestion, tcp

protocol-element §5.4

The average loss interval I_mean is computed over the n most recent loss event intervals (recommended n=8) using linearly decreasing weights: w_i=1 for i<n/2 and w_i=1-(i-(n/2-1))/(n/2+1) otherwise. The loss event rate p = 1/I_mean.

congestion, measurement

protocol-element §5.5

The optional history discounting mechanism (Section 5.5) associates per-interval discount factors DF_i and a general discount factor DF (initialized to 1). When the current loss-free interval I_0 exceeds twice the weighted average I_mean, DF is reduced to 2*I_mean/I_0, clamped to a THRESHOLD of 0.5, concentrating weight on recent history.

congestion, measurement

protocol-element §4.5

The optional oscillation prevention mechanism (Section 4.5) maintains R_sqmean as an EWMA of sqrt(RTT). The instantaneous transmit rate is modified to X_inst = X * R_sqmean / sqrt(R_sample), reducing rate when RTT is growing. Recommended when statistical multiplexing is low.

congestion, qos

security-consideration §9

A greedy receiver can inflate its share by falsely claiming receipt of lost (congested) packets, causing the sender to compute an artificially low loss rate and increase throughput unfairly. Defenses typically involve a nonce the receiver must echo back to the sender to prove actual receipt; details are transport-protocol-specific.

security, congestion

security-consideration §9

Protocols combining ECN with TFRC should incorporate the ECN nonce mechanism to prevent a receiver from concealing marked packets (accidentaly or maliciously), which would otherwise cause the sender to underestimate congestion. ECN nonce details are outside the scope of this document.

security, congestion, ecn

security-consideration §9

Spoofed feedback packets can be used to manipulate the sender's rate, creating a denial-of-service risk. Any transport protocol using TFRC MUST ensure feedback is accepted only from the legitimate receiver of the data; the mechanism depends on the transport protocol's authentication design.

security, congestion