RTT Measurement Reno: coarse-grained timer. Vegas: fine-grained clock values. More accurate calculations of timeout, resulting faster detection of lost segments
Retransmission decision Reno: w hen receiving n (usually 3) duplicate ACKs. Vegas: when receiving duplicate ACK, checks if timeout expired and if so, retransmits. when receiving a non-duplicate ACK (1 st or 2 nd after retransmission), checks if timeout expired and if so, retransmits.
Retransmission example Rcvd ACK for Packet 10 (11 and 12 are in transit). Send packet 13 (which is lost). Rcvd ACK for Packet 11. Send packet 14. Rcvd ACK for Packet 12. Send packet 15 (which is lost) Should have gotten ACK for packet 13 Rcvd dup ACK for packet 13 (due to packet 14). Vegas checks timeout for packet 13 and retransmits it. (Reno would need to wait for the 3 rd dup ACK) Rcvd ACK for packet 13 and packet 14. Vegas checks timeout for packet 15 and retransmits it. (Reno would need to wait for the 3 rd dup ACK) One RTT
Congestion window decrease Reno: possible to decrease the congestion window more than once during one RTT. Vegas: in case of multiple segment loss and more than one fast retransmission the congestion window is reduced only for the first fast retransmission.
Congestion detection Reno: reactive – uses the loss of segments as a signal that there is congestion in the network. Vegas: proactive – tries to detect incipient congestion by comparing the measured throughput to its notion of expected throughput.
The algorithm baseRTT – RTT of a segment when the connection is not congested. windowSize – the size of the current congestion window. expected = windowSize / baseRTT
The algorithm – cont. rttLen – number of bytes transmitted during the last RTT. rtt – average RTT of the segments acknowledged during the last RTT. actual = rttLen / rtt diff = expected – actual Define two thresholds: <
The algorithm – cont. diff < increase the congestion window linearly during the next RTT. diff > decrease the congestion window linearly during the next RTT. < diff < do nothing
Congestion window increase Reno: doubles congestion window size every RTT. Vegas: doubles congestion window size every other RTT (valid comparison of the expected and the actual rates). Detect and avoid congestion during slow-start
Background Traffic Experiment What is the performance of a TCP connection when the network is loaded with traffic? Two kinds of experiments: Background traffic using Reno Background traffic using Vegas
Background Traffic Experiment – cont. 1 MB TransferTraffic over VegasReno 8268Reno (KB/S) 8584Vegas (KB/S) Throughput of Background Traffic
Conclusions When most of the traffic is from Reno connections it ’ s better to run Vegas. When the whole world running Vegas Enough buffers in the routers Vegas Congestion mechanism is effective Load increases and/or number of router buffers decreases Vegas behaves similarly to Reno
Algorithms In TCP Vegas Q: Which of the techniques incorporated in TCP Vegas are responsible for the performance gains?
2 k Factorial Design Determine the effect of k factors, each of them having two levels. In case of TCP Vegas, these factors are the different algorithms. The factor levels are “ on ” and “ off ” (indicate whether the TCP Vegas algorithm is used or not).
Conducted experiment The Vegas algorithms were clustered into three groups according to the phase they affect: Slow start Congestion avoidance Congestion recovery
Experiment Results Slow-start and Congestion recovery have the most influence on throughput Congestion detection mechanism during congestion avoidance, has only minor or negative effect on throughput Congestion detection mechanism may exhibit problems related to fairness among competing connections
References Lawrence S. Brakmo, Sean W. O ’ Malley and Larry L. Peterson. TCP Vegas: New Techniques For Congestion Detection And Avoidance U. Hengartner, J. Bolliger and Th. Gross. TCP Vegas Revisited