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
Outline What s TCP Veno? TCP Briefing TCP Veno Common Issues Concerned Ongoing Work 1/30/2004 2
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 2003 1/30/2004(Real source codes available immediately) 3
TCP Reno --- SS AIMD FF KB 70 60 50 40 30 20 10 Slow Start, Additive Increase and Multiplicative Decrease, Fast Retransmit and Fast Recovery 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 10.0 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: 1995-2000 (AIMD, FF *, SS) NewReno, SACK, FACK, Rate-Halving, NetReno etc. 1/30/2004 4
TCP Vegas --- SS * FF * AIAD AIAD: Additive Increase and Additive Decrease CAM KBps 240 200 160 120 80 40 α = 1 packet β = 3 packets 0.5 1.0 1.5 2.0 2.5 3.0 3.5 4.0 4.5 5.0 5.5 6.0 6.5 7.0 7.5 8.0 T ime (seconds) Proactive Congestion Control (1988-1995) 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
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
Outline What s TCP Veno? TCP Briefing TCP Veno Common Issues Concerned Ongoing Work 1/30/2004 7
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
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
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/2004 10
TCP Evolution Snapshot in Real Network Veno 80% Over Reno Random loss rate 0.01 Reno 1/30/2004 11
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/2004 12
Cont d Veno No Random loss 40% congestion loss is reduced Reno 1/30/2004 13
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/2004 14
More Details 1/30/2004 15
Outline What s TCP Veno? TCP Briefing TCP Veno Common Issues Concerned Ongoing Work 1/30/2004 16
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/2004 17
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/2004 18
Throughput 1/30/2004 19
Compatibility & Throughput Four Reno connections Two Reno connections Two Veno connections No random loss in this situation Fairness/Compatible? 1/30/2004 20
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/2004 21
Cont d 960 840 720 No Random Loss Reno Veno Throughput(kBytes/s) 600 480 360 240 120 0-1 0 1 2 3 4 5 6 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/2004 22
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 2002. 1/30/2004 23
Deployability? One side modification? Two sides modification? Need support from Intermediate node? Any more? Which do you prefer? 1/30/2004 24
Deployability Client PC Wireless (802.11) Client PC Client PC ADSL Wired Proxy Internet Server 1/30/2004 25
Cont d App Client Host kernel sockets proxy Server Host kernel sockets Server TCP/IP stack TCP/IP stack network interface 1/30/2004 26
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/2004 27
Outline What s TCP Veno? TCP Briefing TCP Veno Common Issues Concerned Ongoing Work 1/30/2004 28
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/2004 29
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/2004 30
THANK YOU! Q&A 1/30/2004 31