170 likes | 294 Vues
This review explores TCP congestion control strategies including Slow-Start, Congestion Avoidance, and Fast Recovery. Key TCP flavors like Tahoe, Reno, NewReno, and Vegas are dissected, each with distinct behaviors in response to packet loss. The interplay of ACKs and the impact of selective acknowledgments (SACK) in managing multiple losses are examined. Furthermore, we discuss the implications of non-congestion-related losses on throughput and the potential for "cheating" in congestion control algorithms. This serves as a foundational understanding of how TCP regulates network traffic effectively.
E N D
EE 122: Congestion ControlThe Sequel October 1, 2003
Quick Review • Slow-Start: cwnd++ upon every new ACK • Congestion avoidance: AIMD if cwnd > ssthresh • ACK: cwnd = cwnd + 1/cwnd • Drop: ssthresh =cwnd/2 and cwnd=1 • Fast Recovery: • duplicate ACKS: cwnd=cwnd/2 • Timeout: cwnd=1
TCP Flavors • TCP-Tahoe • cwnd =1 whenever drop is detected • TCP-Reno • cwnd =1 on timeout • cwnd = cwnd/2 on dupack • TCP-newReno • TCP-Reno + improved fast recovery • TCP-Vegas, TCP-SACK
TCP Vegas • Improved timeout mechanism • Decrease cwnd only for losses sent at current rate • avoids reducing rate twice • Congestion avoidance phase: • compare Actual rate (A) to Expected rate (E) • if E-A > , decrease cwnd linearly • if E-A < , increase cwnd linearly • rate measurements ~ delay measurements • see textbook for details!
TCP-SACK • SACK = Selective Acknowledgements • ACK packets identify exactly which packets have arrived • Makes recovery from multiple losses much easier
Standards? • How can all these algorithms coexist? • Don’t we need a single, uniform standard? • What happens if I’m using Reno and you are using Tahoe, and we try to communicate?
Equation-Based CC • Simple scenario • assume a drop every k’th RTT (for some large k) • w, w+1, w+2, ...w+k-1 DROP (w+k-1)/2, (w+k-1)/2+1,... • Observations: • In steady state: w= (w+k-1)/2 so w=k-1 • Average window: 1.5(k-1) • Total packets between drops: 1.5k(k-1) • Drop probability: p = 1/[1.5k(k-1)] • Throughput: T ~ (1/RTT)*sqrt(3/2p)
Equation-Based CC • Idea: • Forget complicated increase/decrease algorithms • Use this equation T(p) directly! • Approach: • measure drop rate (don’t need ACKs for this) • send drop rate p to source • source sends at rate T(p) • Good for streaming audio/video that can’t tolerate the high variability of TCP’s sending rate
Question! • Why use the TCP equation? • Why not use any equation for T(p)?
Cheating • Three main ways to cheat: • increasing cwnd faster than 1 per RTT • using large initial cwnd • Opening many connections
x A B y D E Increasing cwnd Faster y C x increases by 2 per RTT y increases by 1 per RTT Limit rates: x = 2y x
x A B y D E Increasing cwnd Faster
x A B y D E Larger Initial cwnd x starts SS with cwnd = 4 y starts SS with cwnd = 1
x A B y D E Open Many Connections • Assume • A starts 10 connections to B • D starts 1 connection to E • Each connection gets about the same throughput • Then A gets 10 times more throughput than D
x A B y D E Cheating and Game Theory D Increases by 1 Increases by 5 A Increases by 1 Increases by 5 (x, y) • Too aggressive • Losses • Throughput falls Individual incentives: cheating pays Social incentives: better off without cheating Classic PD: resolution depends on accountability
Lossy Links • TCP assumes that all losses are due to congestion • What happens when the link is lossy? • Recall that Tput ~ 1/sqrt(p) where p is loss prob. • This applies even for non-congestion losses
Example p = 0 p = 1% p = 10%