TCP Veno: Solution to TCP over Wireless

Transcription

1 TCP Veno: Solution to TCP over Wireless Franklin FU Presented by Franklin Fu Asst Professor School of Computer Engineering Nanyang Technological University Singapore January 31, 2004, 5:00am Singapore January 30, 11:00am Hawaii, USA 1/30/2004 1

2 Outline What s TCP Veno? TCP Briefing TCP Veno Common Issues Concerned Ongoing Work 1/30/2004 2

3 TCP Briefing TCP Reno 1988, 1990 V. Jacobson Congestion Control and Avoidance ACM SIGCOMM 1988 (Real source codes available immediately) TCP Vegas 1994 L. S. Brakmo, L. L. Peterson TCP Vegas: New Techniques for Congestion Detection and Avoidance ACM SIGCOMM 1994 & IEEE (JSAC) Journal of Selected Areas in Communications 1995 (Real source codes available immediately) TCP Veno 2001 C. P. Fu, S. C. Liew TCP Veno: TCP Enhancement for Transmission Over Wireless Access Networks IEEE (JSAC) Journal of Selected Areas in Communications /30/2004(Real source codes available immediately) 3

4 TCP Reno --- SS AIMD FF KB Slow Start, Additive Increase and Multiplicative Decrease, Fast Retransmit and Fast Recovery Time (seconds) 1988 Tahoe,1990--Reno: sawtooth (fluctuation) behavior aggressively increases window, resulting in periodic congestion loss Reno estimates the equilibrium point of a connection using a rough mechanism (AIMD) Reno s variants: (AIMD, FF *, SS) NewReno, SACK, FACK, Rate-Halving, NetReno etc. 1/30/2004 4

5 TCP Vegas --- SS * FF * AIAD AIAD: Additive Increase and Additive Decrease CAM KBps α = 1 packet β = 3 packets T ime (seconds) Proactive Congestion Control ( ) Vegas carefully probes the equilibrium of a connection using the estimated # packets at bottleneck router Avoids occurrence of congestion loss buffer overflowing Similar Algorithms: DUAL, CARD, Tri-S, Packet-Pair, Santa Cruz 1/30/2004 5

6 Any Disadvantages? Shortcomings of Reno Reno considers all packet losses to be indicators of network congestion Cannot distinguish between random loss and congestion loss Window is erroneously reduced in lossy environments Shortcomings of Vegas Inability to distinguish between congestion loss and random loss, Vegas rigidly treats all packet loss as random loss Not compatible with large installed-based TCP Reno Performance degrades substantially in asymmetric networks (i.e., ADSL) 1/30/2004 6

7 Outline What s TCP Veno? TCP Briefing TCP Veno Common Issues Concerned Ongoing Work 1/30/2004 7

8 TCP Veno Combines elements from two opposing TCP camps: 1) Reno which uses reactive congestion control; and 2) Vegas which uses proactive congestion control. Specifically, integrate the idea of Congestion Detection of Vegas TCP into Reno TCP in order to Distinguish connection evolution in congestive or noncongestive state, so that window size can be adjusted rationally Extend Additive Increase phase to better make use of available bandwidth and reduces occurrences of congestion loss 1/30/2004 8

9 Congestion Loss / Random Loss vs Congestive State / Non-congestive State sender equilibrium point receiver BDP=Bandwidth* RTT Congestion loss Random loss or Congestion loss? Random loss 1/30/2004 9

10 TCP Veno Mechanism (1) Refining Reno s MD If loss occurs when not in congestive state, declare random loss; otherwise, declare congestion loss Algorithms: when packet loss is detected by fast retransmit: if (DIFF*BaseRTT < β) ssthresh =cwnd loss * (4/5); //where DIFF=(cwnd/BaseRTT - cwnd/rtt )*BaseRTT //random loss ( due to bit errors ) is most likely to have occurred else if ssthresh = cwnd loss /2 ; // congestive state is most likely to have occurred, //even there occurs random loss at this time when packet loss is detected by retransmit-timeout timer: ssthresh is set to half of the current window ; slow start is performed; // performs the same action as in Reno 1/30/

11 TCP Evolution Snapshot in Real Network Veno 80% Over Reno Random loss rate 0.01 Reno 1/30/

12 TCP Veno Mechanism (2) Refining Reno s AI Algorithms: during the additive increase (AI) period, if ( DIFF*BaseRTT β) cwnd=cwnd+1/cwnd else if (DIFF*BaseRTT > β ) cwnd=cwnd+1/cwnd; // available bandwidth under-utilized // for every new ack received // available bandwidth fully utilized //for every other new ack received AI dominates most part of the connection evolution Try to stay at the ideal transmission rate as long as possible. 1/30/

13 Cont d Veno No Random loss 40% congestion loss is reduced Reno 1/30/

14 How to Implement TCP Veno? Logical concept Application process Application process W rite bytes Read bytes TCP Send buffer Out filter TCP Receive buffer In filter Segment Segment Segment T ransmit segments 1/30/

15 More Details 1/30/

16 Outline What s TCP Veno? TCP Briefing TCP Veno Common Issues Concerned Ongoing Work 1/30/

17 How to Evaluate TCP? Throughput (for a single connection) Higher, better? Need evaluation in one scenario or in different scenarios? Flexibility Compatibility (for multi-connections) Within own connections: Fairness definition = ( n i=1 b i )2 / n*( n i=1 b i2 ) With installed-based legacy TCP ( Higher throughput from better efficient utilization rather than grabbing bandwidth from other TCP connections) Robustness Deployability (practical consideration) 1/30/

18 Experiments Small scale Sender: FreeBSD 4.3 Gateway: FreeBSD4.2 Receiver: Linux OS Src 1 10Mbps, 1ms Src N 10Mbps, 1ms Pkt. direction B f BW r, D r, L r BW f, D f, L f B r Dst 1 10Mbps, 1ms Dst N Ack direction Large scale --- live Internet 1/30/

19 Throughput 1/30/

20 Compatibility & Throughput Four Reno connections Two Reno connections Two Veno connections No random loss in this situation Fairness/Compatible? 1/30/

21 Cont d Random loss with rate=0.01 (10-5 ~10-6 bit /s) Four Reno connections Two Reno connections Two Veno connections 80% improvement over Reno for single connection with loss rate=0.01 1/30/

22 Cont d No Random Loss Reno Veno Throughput(kBytes/s) X X Total connections is 5 with X Veno connections and (5-X) Reno connections 1) Veno achieves higher throughput 2) Veno doesnot steal bandwidth from its counterpart since curve is horizontal 3) Fair among Veno s connections since standard deviation is small 1/30/

23 Robustness Robustness Repeat 1980 s Internet collapse? Veno comply with the principle of Protocol should be designed defensively, and be liberal in what you accept but conservative in what you believe. Dah-Ming Chiu, Raj Jain, Analysis of the Increase and Decrease Algorithms for Congestion Avoidance in Computer Networks, Journal of Computer Networks and ISDN, Vol. 17, No. 1, June 1989 T. Anderson, S. Shenker, I. Stoica, and D. Wetherall, "Design Guidelines for Robust Internet Protocols", HotNets-I, October /30/

24 Deployability? One side modification? Two sides modification? Need support from Intermediate node? Any more? Which do you prefer? 1/30/

25 Deployability Client PC Wireless (802.11) Client PC Client PC ADSL Wired Proxy Internet Server 1/30/

26 Cont d App Client Host kernel sockets proxy Server Host kernel sockets Server TCP/IP stack TCP/IP stack network interface 1/30/

27 Flexibility in different networks Compatibility with Summary of TCP Veno VENO Vegas Veno Normal[1] general general better than Reno Wireless very bad good good Asymmetric general very bad better than Reno Reno good bad good Itself good good good Robustness good general good Deployability N/A sending sending side Congestion Proactive no side yes yes control with Reactive yes no yes 1/30/

28 Outline What s TCP Veno? TCP Briefing TCP Veno Common Issues Concerned Ongoing Work 1/30/

29 Ongoing Work Extend Veno TCP to Multicast in Wired/wireless Networks Dynamics Study of Veno TCP Synchronization in TCP Reno Work with ECN/RED? Further theory Analysis?. 1/30/

30 Acknowledgements Team Members: Miss Gigi Chung and Mr. Lui Hung Ngai, Wang wei, Chang chun lei, C.H. Foh Prof. Victor Li General Chairman of INFOCOM 2004 Prof. Li Xing and Dr. Wang Ji Long at Tsinghua Univ, China Dr Vern Paxson at ICIRI, Berkeley. Prof. Lee Bu Sung at Singapore, Prof. Lawence Yeung at HKU, And. 1/30/

31 THANK YOU! Q&A 1/30/