Sandeep Kakumanu Smita Vemulapalli Gnan TCP – VEGAS an overview Sandeep Kakumanu Smita Vemulapalli Gnan

Contents Introduction Flavors of TCP Limitations of Tahoe and Reno TCP-Vegas Techniques used Claimed results Critique

INTRODUCTION TO TCP TCP provides a reliable byte-stream transfer service between two endpoints on an internet. TCP continuously adjusts the sender's data rate to achieve maximum data throughput while avoiding congestion. If there is a packet loss, TCP does retransmission.

FLAVORS OF TCP TCP – Tahoe TCP – Reno TCP – New Reno TCP – SACK TCP – Vegas

Limitations TCP – Tahoe: TCP – Reno: Too aggressive Returns to slow start on every congestion TCP – Reno: Has to wait for 3 Dup-ACKs Inefficient incase of multiple losses

TCP - Vegas A substitute flavor with claims of 40-70% better throughput and one half to one fifth the losses compared to TCP – Reno. Key features Not too aggressive retransmission Anticipates congestion – hence lesser losses Interoperates with other implementations of TCP.

Techniques used Accurate Round Trip Time (RTT) Calculation: RTT = Time difference between the instant when the packet is sent and its ACK received Clock measures smaller time intervals. Accurate estimation of RTT results in more accurate timeout calculation.

New Retransmit Decisions Individual packet timeout value is smaller. Need not wait for n(3 as in Reno) Dup-ACKs. If it doesn't receive ACK before the packet timeout, retransmission takes place. What happens when there are multiple losses?

Modified window sizing on Congestion Congestion window size should be modified only based on losses that happened during current sending rate. What happens if Vegas uses Reno’s window sizing policy?

4. Spike suppression: Spikes are sudden bursts in sending rates. Why do they happen? Generally the congestion window limits the throughput but doesn't affect the spacing of packets. Vegas calculates a segment spacing and sends packets at evenly spaced intervals.

5. Congestion detection and avoidance: (during steady state) Looks at changes in throughput rate. Finds a base RTT (= RTT during no congestion). Expected throughput = W/Base RTT. Actual throughput is also calculated. Diff = Expected-Actual (always > 0 Why?) Define bounds of Diff, α and β. Change W such that α <Diff< β. How will the W plot look now?

(During slow start) W+=1 only every second RTT. Another threshold called γ is found out experimentally and when Diff crosses γ it goes into steady state.

Claimed Results Vegas produces 40-70% better throughput than Reno. One-half to one-fifth the losses. Can work with other protocols in the background. Some preliminary results based on real internet runs.

The Critique Basically Vegas assumes that the packets go in order. If they are received out of order , unnecessary retransmissions will result. ACK losses might create problems. When TCP Reno and Vegas, Reno will use most of network bandwidth and Vegas will back off.