TFRC: TCP Friendly Rate Control using TCP Equation Based Congestion Model

CS 218 W 2003

Oct 29, 2003

References

• S. Floyd, J. Padhye, J.Widmer “Equation Based Congestion Control for Unicast Applications”, Sigcomm 2000

• J. Padhye, V.Firoiu, D. Towsley, J. Kurose” Modeling TCP Throughput: a Simple Model and its Empirical Validation” Sigcomm 98

Congestion Control of UDP streaming traffic

• Uncontrolled UDP major threat to Internet stability• Best effort streaming traffic must be rate-controlled in a

way that it is TCP-friendly• Existing schemes (eg, RAP – Rate Adaptation Protocol) do

not include retx timeout and slow start; some use AIMD and window halfing (too abrupt)

• Also, some schemes do not scale as they react to each packet loss

• TFRC is TCP friendly in that it adjusts the rate by “mimicking” a TCP Reno connection using the TCP “equation” model; it provides smooth rate adaptation

The equation was derived for TCP Reno; it relates source rate (Throughput) T to:

•Round trip delay R (measured at source)•Packet size s (measured at source)•Packet loss (congestion) rate p (fed back by rcv each RTT)•Retransmission time out tRTO (measured at source)

TCP Equation Model (Padhye et al)

Key Idea of TFRC

• Sender receives the feed back re packet loss event rate p from receiver every RTT

• Sender calculates new value of allowed sending rate; it increases/decreases current value to match the calculated rate

• In so doing, TFRC behaves like any other TCP Reno session (same equation); it produced the same external effects

Background on TCP cong. control Equation (from J. Padhye et al)

• A simple model relating T to RTT and p already existed (Floyd) – but did not account for TCP time out

The main innovation of Padhye’s work is to includethe Trto and the advertised window Wmax

Trto is important as most of packet loss leads to Time out, rather than 3 Dup ACKs

The equation model

• Single “saturated” TCP sender pumping into a loaded bottleneck – the other flows are modeled only through bottleneck packet loss p

• TCP behavior modelled as a sequence of “rounds”

• The round begins when the sender sends out W pkts back-to-back (this takes < RTT)

• Round ends when receiver gets first ACK

• Packet loss p independent from round to round

• First model: the renewal interval is terminated by a Triple Dup ACK (TDP)

Model similar to the Markov model used for TCP Westwood – but, here, closed form

TDP = Markov renewal interval terminated by Triple Dup ACK; made up of several RTTs

Detail view of TDP model

b = # of packets acked by a single ACK (typically b =2; see details on Padhye’s paper

TDP model

Next, include Trto in model

Now, the renewal interval is more complicated..

Finally, the advertised Window

Measurements and Trace Analysis

• Empirical validation from 37 TCP connections between 18 hosts in the US and Europe

• Measurement data gathered with TCP-Dump at sender; analyzed with UMASS tools

• From results, the importance of timeouts is obvious

Validation Experiments based on 1hr traces.Hourly traces were subdivided in 36 X 100s segments; each segment maps into a point on the T vs p graph

Summary data for the 100s traces

Full model:

Approximate model:

Back to TFRC

• Sender: measures various parameters; calculates the TCP-like rate corresponding to the measured parameters

• Receiver: provides feedback to sender to allow it to calculate RTT; also calculates loss event rate p

• The p rate computation critical for performance of TFRC. • Average Loss Interval: weighted average of loss rate over

the last N loss intervals (loss interval = interval of packets between loss episodes)

NS Simulation results: TCP SACK +TFRC fair sharingNormalized TCP Thr =1 means perfect fairness

N TCP flows +N TFRC flows

TFRC less aggressive than TCPTFRC internally unevenly “fair”

40 “long lived” flows simulation: the 40 flows start in the first 20 s. We show bottleneck queue dynamics

Comment: TFRC (bottom) is as stable as TCP (top). TCP drop rate =4.9%; TFRC drop rate = 3.5%

Internet Measurements: 3 TCP connections – London to Berkeley. Throughput measured over 1 sec intervals

TFRC much more stable than TCP

Conclusions

• TFRC valuable for best effort unicast streaming

• Simulation and Implementation code available for testing

• Multicast extension very attractive

• Need to include ECN in eq. model

• What about random link loss?