TCP Veno: TCP Enhancement for Transmission Over Wireless Access Networks

1. TCP Veno: TCP Enhancement for Transmission OverWireless Access Networks IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS, VOL. 21, NO. 2, FEBRUARY 2003 Speaker : Chen YoChuan

2. Outline • Introduction • TCP Reno, TCP Vegas • TCP Veno algorithm • Performance Evaluation of TCP Veno • Concluding Remarks and Future Works

3. Introduction • Wireless communication has been making significant progress • Usually using wired backbone networks • Many applications on the networks run TCP/IP • Transmission control protocol (TCP) • a reliable connection-oriented protocol • Implement flow control (sliding window) • TCP Reno is most popular in real network • Include SS, CA, Fast retransmission… algorithm

4. Introduction • Reno treats the occurrence of packet loss as a manifestation of network congestion • In wireless environment, packet loss is often induced by noise, link error… • To tackle this problem, 2 parts of solution • How to distinguish between random loss and congestion loss? • How to make use of that information to refine the congestion-window adjustment process in Reno? • TCP Veno (modify Vegas & Reno)

5. Relative work • TCP Reno • TCP Vegas

6. TCP Reno • Sliding windows • Slow start and congestion avoidance algorithms • Fast retransmit and fast recovery

7. TCP Reno • AIMD (Additive Increase and Multiplicative Decrease) algorithm • 2 adjustment phases • Traffic load is steady or decreasing • The internal traffic increases linearly • Congestion signal is received • When 3 duplicate acks or retransmit timer timeout • Algorithm decreases the window size by half

8. TCP Reno • The Rough Evolution of TCP Reno

9. TCP Reno • Slow start • initiated at the start of a TCP connection • initiated after a retransmission timeout • Slow start threshold • If cwnd is larger than ssthresh, cwnd is linear growth

10. TCP Reno • Fast retransmit & fast recovery

11. TCP Reno --end • Round trip time (RTT) • Retransmit Time Out (RTO) • Too small, TCP will retransmit segments unnecessarily • Too large, actual throughput will be low • SRTT = ( ALPHA * SRTT ) + ((1-ALPHA) * RTT) • RTO = min[UPBOUND, max[LBOUND,(BETA*SRTT)] ] • Reno conclusion

12. TCP Vegas • Basic ideas • Beforepacket loss occurs, detect the early stage of congestion in the routers between source and destination • Additively decrease the sending rate when incipient congestion is detected

13. TCP Vegas • Expected = cwnd/BaseRTT • Actual = cwnd/RTT • DIFF = (Expected-Actual) BaseRTT : the minimum of all measured RTT if ( DIFF*BaseRTT < α ) cwnd = cwmd + 1 else if ( DIFF*BaseRTT > β ) cwnd = cwnd – 1 else cwnd = cwnd RTT: the actual round-trip time of a tagged packet α and β are constant values that be set by experimentation

14. TCP Vegas • Vegas main idea • Maintain the extra data (queue size) in the bottleneck router buffer to be between the lower threshold (α) and upper threshold (β) • To reach high throughput • Avoid packet overflow μf = cwnd/RTT RTT = BaseRTT + N/μf N = cwnd *( 1- BaseRTT/RTT) = DIFF*BaseRTT. μf *RTT = μf * BaseRTT + N cwnd = BDP + N

15. TCP Vegas • New Retransmission Mechanism • decreases cwnd multiplicatively using a factor of ¾ rather than Reno’s ½ • On receiving a duplicate ack • Vegas resends the corresponding segment if the segment timer has expired • Without having to wait for n (3) duplicate acks as in Reno

16. TCP Vegas • Modified Slow Start • Try to find the correct window size without incurring a loss • exponentially increasing its window every other RTT and using the other RTT to calculate DIFF • As soon as Vegas detects queue buildup during slow start, it transitions to congestion avoidance

17. TCP Vegas • Problem with TCP Vegas • Asymmetry • Rerouting problem • Persistent congestion

18. TCP Veno algorithm • Distinguishing between congestive & non-congestive (random) states • Using N as an indication of whether the connection is in a congestive state • N<βwhen packet loss is detected • Veno assume that loss is random • N>=βwhen packet loss is detected • Veno assume that loss is congestion

19. TCP Veno algorithm • In Vegas, BaseRTT is continually updated throughout the TCP connection • with the min RTT collected so far • In this paper, BaseRTT is reset whenever packet loss is detected • either due to time-out or duplicate ACKs • To avoid BaseRTT change from time to time

20. TCP Veno algorithm • Congestion Control Based on Connection State • Slow start algorithm (cwnd<sstresh) • Employ the same algorithm as Reno • Additive increase algorithm (cwnd>sstresh) • Specifically, cwnd will be increased by 1 after each RTT • cwnd is set to cwnd+1/cwnd

21. TCP Veno algorithm • Additive increase algorithm • Goal : let connection can stay in operating region longer if ( DIFF*BaseRTT < β ) // available bandwidth under-utilized cwnd=cwnd+1/cwnd when every new ack received else if (DIFF*BaseRTT ≥ β ) // available bandwidth fully utilized cwnd=cwnd+1/cwnd when every other new ack received

22. TCP Veno algorithm

23. TCP Veno algorithm

24. Reno Fast recovery 1) Retransmit the missing packet set ssthresh = cwnd/2 set cwnd= ssthresh+3 2) Each time another dup ACK arrives, increment cwnd by one packet. 3) When the next ACK acknowledging new data arrives, set cwnd to ssthresh (value in step 1) Veno modify step (1) of Reno if (DIFF*BaseRTT < β) //random loss due to bit errors is most //likely to have occurred ssthresh = cwndloss* (4/5); else if ssthresh = cwndloss/2 ; // congestive loss is most //likely to have occurred TCP Veno algorithm • Multiplicative decrease algorithm ½~1 More than ¾ is better

25. TCP Veno algorithm Veno reduce window by 1/5 Detail is later

26. TCP Veno algorithm Reno reduce window by 1/2 Detail is later

27. TCP Veno algorithm --end • In summary, veno only refines the additive increase , multiplicative decrease (AIMD) • All other parts of Reno remain intack • Including slow start, fast retransmit, fast recovery, computation of retransmission timeout algorithm

28. Outline Performance evaluation of TCP Veno • Verification of packet loss distinguishing scheme in Veno • Experimental Network setup • The verification of packet loss distinguishing scheme • Single connection experiments • Experiment involving multiple co-existing connections • Live internet measurements

29. Network setup Performance evaluation of TCP Veno • Two experiments • Packet loss artificially induced, • On real wireless network where random packet loss actually occurs

30. Network setup Performance evaluation of TCP Veno Random loss is artificially induced in router Src1,Src2 : TCP sendersthat run TCP Reno or Veno over NetBSD1.1 Dst1,Dst2 : TCP receivers with Red Hat Linux installed Router :drop-tail router with (FIFO) queues is set up using FreeBSD4.2 Bf: forward buffer, Br: backward buffer μf : forward bandwidth, μr : reverse bandwidth τf : forwardpropagation delay, τr : reverse propagation delay Differentrandom packet loss rates can also be artificially induced using the embedded system command in FreeBSD4.2

31. Network setup Performance evaluation of TCP Veno Random loss actually occurs in the wireless link WC1 : wireless client Src2 : Veno source TCP connection : Src2 WC1 UDP connection : Src1Dst1( provide the background traffic) TCPsuit : Tool developed by author, to infer 1.packet loss due to buffer overflow 2.packet loss due to wireless link

32. Verification of Packet Loss Distinguishing Scheme Performance evaluation of TCP • Single TCP Veno connection without background traffic • Background traffic is provided by a UDP Configuration forward bufferμf = μr = 1.6 MB/s backward buffer Bf = Br = 12 Round-trip timebetween WC1 and Src2 = 60 ms 12 MB file was transferred between WC1 and Src2 in each Veno’s test

33. Verification of Packet Loss Distinguishing Scheme Performance evaluation of TCP • First run experiment • UDP sending rate is 500kb/s • 240 fast retransmits • 84 non-congestive • 156 in congestive state • Correct rate in non-congestive 83/84 = 99% • Correct rate in congestive 10/156 = 6.4%, 146 is misinterpreting • Use Reno’s algorithm (worst case) • Misdiagnosis does not bring any throughput improvement

34. Verification of Packet Loss Distinguishing Scheme Performance evaluation of TCP Veno estimate in congestion state Veno estimate in non-congestive state EFFECTIVENESS OF VENO’S PACKET LOSSDISTINGUISHING SCHEME UNDER DIFFERENT UDP SENDING RATES

35. Verification of Packet Loss Distinguishing Scheme Performance evaluation of TCP • Window-halved reductions corresponding to these kinds of random loss may be right actions • Because the available bandwidth has been fully utilized in these situations Really ?

36. Single connection experiments Performance evaluation of TCP • Only one of the source-destination pairs is turned on • The figure below shows the evolution of the average sending rate • For loss probabilities ranging from 10-4 to 10-1 • buffer size at the router is set to be 12 • link speed μf = μr = 1.6 MB/s • RTT = 120ms • Maximum segment size is 1460 Byte • Each data point of the sending rate divided by 160 ms

37. TCP Reno & Veno Average sending rate for loss probability ranging from 10-4 to 10-1

38. Single connection experiments Performance evaluation of TCP • When the packet loss rate is relatively smaller • The evolutions of Veno and Reno are similar • But when the loss rate is close to 10-2 packets/s • Veno shows large improvements over Reno

39. Single connection experiments Performance evaluation of TCP Veno • One 32-MB file is transferred for each run • Other parameters are the same as the above experiment setting Veno and Reno operate similarly by falling back to the slow start algorithm TCP Veno (146.5 kB/s) is 80% higher than that of TCP Reno (81.9 kB/s) Multiplicative decrease algorithm that performs intelligent window adjustment based on the estimated connection state

40. Single connection experiments Performance evaluation of TCP Veno • RFC3002 shows that • wireless channel with IS-95 CDMA-based data service has an error rate of 1%–2%.

41. Multiple Co-existing Connections Performance evaluation of TCP Veno • 4 connections consisting of a mixture of Veno and Reno to share a common bottleneck link of 4 Mb/s • Maximum segment size is 1460 Bytes • Bf= Br = 28 • Round-trip propagation time of 120 ms

42. Multiple Co-existing Connections Performance evaluation of TCP Veno • Veno connections exhibit higher throughput than coexisting Reno connections • Evolution of two Reno connections in (d) is close to that of (c) • Veno does not achieve its superior throughput by aggressively grabbing bandwidth away from Reno • Use the available bandwidth that will be otherwise left unused

43. Multiple Co-existing Connections Performance evaluation of TCP Veno • Conclude : Veno is compatible with Reno • (d) are roughly the same as those in (b) • Veno connections are not adversely affected by the random loss rate of 0.01

44. Multiple Co-existing Connections Performance evaluation of TCP Veno • Throughput for a total of five connections • consisting of a mixture of Reno and Veno connections • The horizontal axis is the number of Veno connections

45. Multiple Co-existing Connections Performance evaluation of TCP Veno • From these two graphs, three important observations can be made • Fairness • All the data points exhibit small standard deviations • Curves are nearly horizontal • Veno will not starve the bandwidth used by Reno connections • throughput improvement • Veno has somewhat higher throughput than Reno in nonlossy environments

46. Live Internet Measurements Performance evaluation of TCP Veno • The performance over WLAN and wide area network (WAN)

47. Live Internet Measurements Performance evaluation of TCP Veno in WLAN • The base station and the laptop in different room, distance between them is about 8 m • Use laptop as a client to download an 8-MB file from the data server • 10/100 Ethernet switch, RTT=20 ms

48. Live Internet Measurements Performance evaluation of TCP Veno in WLAN • 10 throughput measurements over one day duration • Test over a period of five days • Veno connection is about 336 kb/s, 21% improvement over that of a Reno connection (about 255 kb/s) • In our latest experiments on 802.11, Veno gets throughput improvement of up to 35%

49. Live Internet Measurements Performance evaluation of TCP Veno in WAN Veno & Reno cross-country WANs metropolitan WANs Planning

50. Live Internet Measurements Performance evaluation of TCP Veno • RTT = 45 ms with 10 ms variation over different time slots • The general trends of the results among the five days are similar • Veno only obtains slightly higher throughput than Reno • Based on the reduced amount of timeouts, fast retransmits, and retransmitted packets • Veno does not “steal” bandwidth from Reno and can coexist