TCP HACK: TCP Header Checksum Option to improve Performance over Lossy Links R. K. Balan, B. P. Lee, K. R. R. Kumar, L. Jacob, W. K. G. Seah,, A. L. Ananda Centre for Internet Research School of Computing National University of Singapore
Problem Lossy / wireless links are common TCP performs poorly when corruption occurs No distinction between corruption and congestion Reduces sending rate, timeouts and slow start Wrong behaviour!! Correct behaviour Send multiple copies of packet Keep sending rate the same Infocom 21 (24/4/1) TCP HACK (rajesh@cs.cmu.edu) 2
Key Observation Data portion usually much larger than header portion ÖCorruptions far more likely in data portion Packets with corrupted headers unlikely to reach destination +HDGHU 3RUWLRQ X Data Portion X Infocom 21 (24/4/1) TCP HACK (rajesh@cs.cmu.edu) 3
Our Solution Corrupted packets may still contain valid headers We recover that information Better than throwing the packet away after it has done so much work!! Header information used to generate special ACKs Performs much better than SACK!! Orthogonal to other methods Infocom 21 (24/4/1) TCP HACK (rajesh@cs.cmu.edu) 4
Outline of Talk Algorithm Experimental Setup / Error Model Experimental Results Other Issues Conclusion Infocom 21 (24/4/1) TCP HACK (rajesh@cs.cmu.edu) 5
Algorithm Add an extra option to every TCP packet Contains checksum for just the header On detecting a corrupted packet Checks if header checksum is okay If it is, send a special ACK to sender containing sequence number of corrupted packet On receiving a special ACK Retransmit corrupted packet Do not half congestion window Infocom 21 (24/4/1) TCP HACK (rajesh@cs.cmu.edu) 6
TCP Sender Data segment to be sent Header checksum option enabled? No Continue as per normal Yes 1) Calculate header checksum of segment 2) Continue as per normal Modifications to the TCP sender Infocom 21 (24/4/1) TCP HACK (rajesh@cs.cmu.edu) 7
TCP Receiver Data segment received TCP segment corrupted? Yes Header portion corrupted? No Yes Continue as per normal Discard Packet No 1) Recover sequence number of corrupted segment from header. 2) Generate special ACK containing the sequence number of the corrupted segment. Modifications to the TCP receiver Infocom 21 (24/4/1) TCP HACK (rajesh@cs.cmu.edu) 8
ACK Processing ACK segment received Is this a special ACK? No Continue as per normal Yes 1) Extract sequence number of corrupted segment 2) Selectively retransmit the segment 3) ACK is discarded without further processing Modification to the ACK processing Infocom 21 (24/4/1) TCP HACK (rajesh@cs.cmu.edu) 9
Experimental Setup Linux 2.2.1 kernel Test bed was set up comprising of 3 machines All experiments were run at 1 Mb/s Iperf was used to generate TCP bulk traffic Infocom 21 (24/4/1) TCP HACK (rajesh@cs.cmu.edu) 1
Experimental Test bed Client Error / Delay Box Server Client and server were running TCP HACK Error / delay box used to simulate latencies and lossy links using modified rshaper kernel module Infocom 21 (24/4/1) TCP HACK (rajesh@cs.cmu.edu) 11
Error Model Packet corruption percentages of 2%, 5% and 1% Single packet corruption Burst corruption with burst lengths of 2, 5 and 1 packets We corrupted the data packets in 2 different ways In the 1 st way, 95% of the headers were corrupted In the 2 nd way, % of the headers were corrupted True header corruption probability is somewhere in between Infocom 21 (24/4/1) TCP HACK (rajesh@cs.cmu.edu) 12
Testing Methodology TCP HACK compared with TCP NewReno and TCP SACK 2 different latencies Short (1ms) Long (3ms) Send/receive windows set large enough Infocom 21 (24/4/1) TCP HACK (rajesh@cs.cmu.edu) 13
Experiment Sets Random Errors Burst Errors Header Corruption % Error Type (long and short latencies) (long latency) % Next few slides Next few slides 95 % Results in Paper Two Results, Rest in Paper Infocom 21 (24/4/1) TCP HACK (rajesh@cs.cmu.edu) 14
Random Errors (% of headers) T hroughput (Kbytes/s) 1 9 8 7 6 5 4 3 2 1 1 4 5 best case hack hack+sack sack N ewreno 5 1 15 Percentage Packet Loss (%) 2 3 1 2 3 4 5 Long Latency (3ms) with 256KB of data transferred Infocom 21 (24/4/1) TCP HACK (rajesh@cs.cmu.edu) 15
Burst Errors (% of headers) Throughput (KBytes/s) 14 12 1 8 6 4 2 hack hack+sack sack 2 4 6 8 1 12 Length of Burst Error (packets) ~ 2-7% packet corruption Infocom 21 (24/4/1) TCP HACK (rajesh@cs.cmu.edu) 16
Burst Errors (95% of headers) Throughput (KB/s ) 6 5 4 3 2 1 2 5 1 Length of Burst Error (packets) hac k+s ac k hac k s ac k 1.6532.7886 ~ 2-7% packet corruption Infocom 21 (24/4/1) TCP HACK (rajesh@cs.cmu.edu) 17
Why does SACK fare so badly? HACK is here!!! xxx x x x x 6 mins xxx x x x x x x x x x x x x x 17 mins xxx x xxx x x xxx x x 4 mins - Too many timeouts!!!! - They are very long as well! Infocom 21 (24/4/1) TCP HACK (rajesh@cs.cmu.edu) 18
HACK does much better! 3 sec xxx x x x 1 sec xxx x x x x x x x x x x x 1 sec xxx x 4sec xxx x x x x - Still some timeouts - They are much shorter!!!! ( 1 times less) - Adding SACK helps a bit Infocom 21 (24/4/1) TCP HACK (rajesh@cs.cmu.edu) 19
Time Taken (% of headers) T im e (s) 6 5 4 3 2 hack+sack hack s ac k 29 1 15 25 HACK is 115x better than SACK!!! Infocom 21 (24/4/1) TCP HACK (rajesh@cs.cmu.edu) 2
Time Taken (95% of headers) 6 29 5 4 hack+sack hack sack 4 T im e (s) 3 2 2 1 HACK is still 6x times better than SACK! Infocom 21 (24/4/1) TCP HACK (rajesh@cs.cmu.edu) 21
Experiment Summary Random Errors Burst Errors Header Corruption % Error Type (long and short latencies) (long latency) % 5-1x better than SACK 1x better than SACK 95 % Equal to SACK 6x better than SACK Infocom 21 (24/4/1) TCP HACK (rajesh@cs.cmu.edu) 22
Does SACK help? Yes and No Fills in holes in the senders window Inefficiencies due to implementation SACK may reduce cwnd as well SACK can co-exist very nicely with HACK orthogonal in nature Infocom 21 (24/4/1) TCP HACK (rajesh@cs.cmu.edu) 23
Other Issues End-2-end protocol Suitable for Ad-Hoc environment No base station support required Sending corrupted packets to TCP is hard Link layer protocols can be efficient But,, they give no information to TCP Spurious timeouts may occur as a result RTT estimates can fluctuate as well Infocom 21 (24/4/1) TCP HACK (rajesh@cs.cmu.edu) 24
Future Work Test TCP HACK over a real lossy link satellite link experiments are planned Compare TCP HACK with Snoop, ECN etc. Implement and test hybrid mechanism TCP Hack with Snoop etc. TCP Hack with link layer protocols etc. Determine the % of corrupted packets with intact headers on real lossy links Infocom 21 (24/4/1) TCP HACK (rajesh@cs.cmu.edu) 25
Conclusion Recovering header information can help TCP HACK does better than SACK under various error conditions Up to a factor of 1 reduction in time taken to complete transfer!!! HACK is particularly useful under burst error conditions Recovering even a small % of the headers helps dramatically Infocom 21 (24/4/1) TCP HACK (rajesh@cs.cmu.edu) 26
Thank You! Infocom 21 (24/4/1) TCP HACK (rajesh@cs.cmu.edu) 27
Header Corruption % Tested using old 2 Mbit Lucent Wavelan Cards Direct sequenced Approximately 9-95% 95% of the corrupted packets had intact headers under reasonable error rates UDP lite (Larzon, Degermark,, Pink) reports that about.8% of normal UDP fail the checksum at the receiver Infocom 21 (24/4/1) TCP HACK (rajesh@cs.cmu.edu) 28
Effect of Window Size Effect of different window sizes investigated 16KB and 64KB windows were used Results were similar Infocom 21 (24/4/1) TCP HACK (rajesh@cs.cmu.edu) 29
Throughput (KB/s) 6 5 4 3 2 1 2 5 1 Length of Burst Error (packets) hack+sack hack s ac k 1.6532.7886 Infocom 21 (24/4/1) TCP HACK (rajesh@cs.cmu.edu) 3
Throughput (KBytes/s) 14 12 1 8 6 4 2 hack hack+sack sack 2 4 6 8 1 12 Length of Burst Error (packets) Infocom 21 (24/4/1) TCP HACK (rajesh@cs.cmu.edu) 31
Burst Errors (%) 9 25 Throughput (KBytes/s) 8 7 6 5 4 3 2 1 hack hack+sack sack Throughput (KBytes/s) 2 15 1 5 hack hack+sack sack 2 4 6 8 1 12 2 4 6 8 1 12 Length of Burst Error (packets) Length of Burst Error (packets) Throughput for 2% burst error for various burst lengths Throughput for 5% burst error for various burst lengths Infocom 21 (24/4/1) TCP HACK (rajesh@cs.cmu.edu) 32
Burst Errors (%) (2) 12 1 4 T hroughput (KBytes/s) 1 8 6 4 2 h ack h ack+ sack sack T hroughput (KBytes/s) 1 2 1 8 6 4 2 h ack h ack+sack sack 2 4 6 8 1 12 2 4 6 8 1 1 2 Length of Burst Error (packets) Length of Burst Error (packets) Throughput for 1% burst error for various burst lengths Throughput for 15% burst error for various burst lengths Infocom 21 (24/4/1) TCP HACK (rajesh@cs.cmu.edu) 33
Low Latency Links (95%) 8 Throughput (KBytes/s 7 6 5 4 3 1 2 3 4 s ac k hack+sack hack new reno 2 2 1 4 3 1 1 2 3 4 5 6 7 8 9 1 11 12 13 14 15 16 Percentage Packet Loss (%) Throughput versus percentage packet loss for short latency (1 ms) link with random single packet errors Infocom 21 (24/4/1) TCP HACK (rajesh@cs.cmu.edu) 34
High Latency Links (95%) 3 25 Throughput (KBytes/s) 2 15 1 3 1 1 2 3 4 s ac k hac k+s ac k hac k new reno 5 4 2 1 2 3 4 5 6 7 8 9 1 11 12 13 14 15 16 Pe rce ntage Packet Loss (%) Throughput versus percentage packet loss for long latency (3 ms) link with random single packet errors Infocom 21 (24/4/1) TCP HACK (rajesh@cs.cmu.edu) 35
Number of Slow Starts (95%) 7 A v e r age Number of Slo 6 5 4 3 2 1 n e w r e no sa c k h a c k h a c k + sa c k 3 6 9 12 Percentage Packet Loss (%) Fig. 7: Average number of slow-starts for long latency link with random single packet errors Infocom 21 (24/4/1) TCP HACK (rajesh@cs.cmu.edu) 36
Burst Errors (95%) Throughput (KB/s) 25 2 15 1 5 2.838 19.759 5 19.9486 16.436 hack+sack hack s ac k 12.9 88 4.6428 15.59 58 2 5 1 Length of Burst Error (packets) 3.546.542 Throughput (KB/s) 12 1 8 6 4 2 11.6934 8.568 7.6964 hack+sack hack s ac k 11. 16 2 5.9582.7454 8.531 1.422.2112 2 5 1 Length of Burst Error (packets) Throughput for 2% burst error for various burst lengths Throughput for 5% burst error for various burst lengths Infocom 21 (24/4/1) TCP HACK (rajesh@cs.cmu.edu) 37
Burst Errors (95%) (2) Throughput (KB/s) 1 8 6 4 2 7.19 38 4.442 2.9494 5.9922 2.9316 2.7724 1.422.142.36 2 5 1 Length of Burst Error (packets) hack+sack hack s ac k Throughput (KB/s) 6 5 4 3 2 1 4.8 5 44 3.1518 1.71 2.112 2.194.35 2 5 1 Length of Burst Error (packets) hack+sack hack s ac k 1.6532.7 8 86 Throughput for 1% burst error for various burst lengths Throughput for 15% burst error for various burst lengths Infocom 21 (24/4/1) TCP HACK (rajesh@cs.cmu.edu) 38
Time Sequence Graphs (95%) Time Sequence Graph for SACK (5% packet error rate with burst length of 5) Infocom 21 (24/4/1) TCP HACK (rajesh@cs.cmu.edu) 39
Time Sequence Graphs (95%) (2) Time Sequence Graph for HACK (5% packet error rate with burst length of 5) Time Sequence Graph for HACK+SACK (5% packet error rate with burst length of 5) Infocom 21 (24/4/1) TCP HACK (rajesh@cs.cmu.edu) 4
Throughput Versus Time (95%) Throughput (Kb/s) 5 4 3 2 1 hac k+s ack hac k s ac k 4 8 12 16 2 24 28 Tim e (s) Throughput versus Time graph for various TCP implementations (5% packet error rate with burst length of 5) Infocom 21 (24/4/1) TCP HACK (rajesh@cs.cmu.edu) 41