TCP Vegas Brakmo & Peterson

No change in TCP spec, merely an alternative implementation –Changes needed only at sender side Main finding –Vegas achieves 40-70% better throughput –Achieved this goal by more efficient use of bw rather than stealing from other flows

Three Techniques New retx mechanism Congestion Avoidance Modified Slow Start

Retx Mechanism in Reno Reno is using coarse-grained timer, 500 ms –Lower accuracy and freq to check for retx Longer retx delay –Retx when Timeout occurs 3 Duplicate acks

Retx Mech. in Vegas Extension for retx in Vegas: keep track of ts to measure accurate RTT –If measured RTT for a dup ack > timeout => retx pkt – if RTT for (1 st or 2 nd pkt after retx) non-dup ack > timeout => retx pkt –What is the Intuition for this? Idea: use arrival of an ACK to check for timeout Keep Reno’s coarse-grained retx timeout Only reduce cwn due to the losses that occured during current rate/window, i.e. lost segment was sent after last window decrease

Reactive vs pro-active Reno is reactive to congestion rather than pro-active –uses pkt loss as sign for congestion Can we design a pro-active congestion detection => to prevent congestion

Other Proactive Cong Detection Mechanisms Some signs of building congestion: –RTT increases –Increase in throughput decreases DUAL: inc similar to Reno but –Once every 2 RTT, if currRTT > Avg(min,max)RTT => cwn*(7/8) ->cwn CARD: use both RTT and cwn –Once every 2 RTT a = (Cwn_curr – Cwn_old) * (RTT_curr – RTT_old) a cwn * 7/8 -> cwn a >= 0 => cwn + 1 -> cwn Tri-S leverages flattening of throughput

Cong Avoid in Vegas Vegas uses changes in the throughput rate Idea: no of byte in transit is proportional to the expected bandwidth –Inc cwn => inc byte in transit => inc throughput Goal: Try to match sending rate with available BW => Determine/Ctrl “right” amount of “extra” bytes –Side effects of too much/little extra?

Cong Avoid in Vegas (Details) Once per RTT Expected_T = cwn/baseRTT –BaseRTT: min RTT observed Actual_T = (bytes sent between pkt & ack)/RTT Examin Diff = Expected_T - Actual_T, by definition diff >= 0 –diff newRTT -> baseRTT –0 LI of cwn in next RTT –alpha no change in cwn –beta LD of cwn in next RTT

Modified SlowStart in Vegas Reno’s exponential inc is expensive –Half the cwn might be lost, worse in higher bw Vegas exp inc cwn once every 2 RTTs –IF Expected_T – Actual_t > Threshold THEN Switch from SlowStart to Add Inc May still lose pkts during slow start –Further investigation needed

Evaluation Simulation showed the Vegas does not adversely affect Reno traffic Vegas can achieve higher throughput and lower losses –Vegas is not aggressive Under heavy load, Vegas behaves like Reno