1 / 41

TCP HACK: TCP Header Checksum Option to improve Performance over Lossy Links

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

nardo
Download Presentation

TCP HACK: TCP Header Checksum Option to improve Performance over Lossy Links

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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

  2. 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 TCP HACK (rajesh@cs.cmu.edu)

  3. Header Portion X X Data Portion 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 TCP HACK (rajesh@cs.cmu.edu)

  4. 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 TCP HACK (rajesh@cs.cmu.edu)

  5. Outline of Talk • Algorithm • Experimental Setup / Error Model • Experimental Results • Potential Deficiencies • Conclusion TCP HACK (rajesh@cs.cmu.edu)

  6. 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 TCP HACK (rajesh@cs.cmu.edu)

  7. Data segment to be sent No Header checksum option enabled? Yes • ) Calculate header checksum of segment • ) Continue as per normal Modifications to the TCP sender Continue as per normal TCP Sender TCP HACK (rajesh@cs.cmu.edu)

  8. Data segment received No TCP segment corrupted? Continue as per normal Yes Yes Header portion corrupted? Discard Packet No • ) Recover sequence number of corrupted segment from header. • ) Generate ‘special’ ACK containing the sequence number of the corrupted segment. Modifications to the TCP receiver TCP Receiver TCP HACK (rajesh@cs.cmu.edu)

  9. ACK segment received No Is this a special ACK? Yes 1) Extract sequence number of corrupted segment • ) Selectively retransmit the segment • ) ACK is discarded without further processing Modification to the ACK processing Continue as per normal ACK Processing TCP HACK (rajesh@cs.cmu.edu)

  10. Experimental Setup • Linux 2.2.10 kernel • Test bed was set up comprising of 3 machines • All experiments were run at 10 Mb/s • Iperf was used to generate TCP bulk traffic TCP HACK (rajesh@cs.cmu.edu)

  11. Error / Delay Box Client Server Experimental Test bed • Client and server were running TCP HACK • Error / delay box used to simulate latencies and lossy links using modified rshaper kernel module TCP HACK (rajesh@cs.cmu.edu)

  12. Error Model • Packet corruption percentages of 2%, 5% and 10% • Single packet corruption • Burst corruption with burst lengths of 2, 5 and 10 packets • We corrupted the data packets in 2 different ways • In the 1st way,  95% of the headers were corrupted • In the 2nd way, 0% of the headers were corrupted • True header corruption probability is somewhere in between TCP HACK (rajesh@cs.cmu.edu)

  13. Testing Methodology • TCP HACK compared with TCP NewReno and TCP SACK • 2 different latencies • Short (10ms) • Long (300ms) • Send/receive windows set large enough TCP HACK (rajesh@cs.cmu.edu)

  14. Experiment Sets TCP HACK (rajesh@cs.cmu.edu)

  15. 1 1 2 3 4 2 5 3 4 5 Random Errors (0% of headers) Long Latency (300ms) with 256KB of data transferred TCP HACK (rajesh@cs.cmu.edu)

  16. Burst Errors (0% of headers) ~ 20 - 70% packet corruption TCP HACK (rajesh@cs.cmu.edu)

  17. Burst Errors (95% of headers) ~ 20 - 70% packet corruption TCP HACK (rajesh@cs.cmu.edu)

  18. HACK is here!!! x x x x 17 mins x x x x  6 mins x x x x x  4 mins x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x - Too many timeouts!!!! - They are very long as well! Why does SACK fare so badly? TCP HACK (rajesh@cs.cmu.edu)

  19.  3 sec x x x x  4sec  1 sec x x x x x x x x  10 sec x x x x x x x x x x x x x x x x x x x x x x x x x - Still some timeouts - They are much shorter!!!! (100 times less) HACK does much better! - Adding SACK helps a bit TCP HACK (rajesh@cs.cmu.edu)

  20. Time Taken (0% of headers) HACK is 115x better than SACK!!! TCP HACK (rajesh@cs.cmu.edu)

  21. Time Taken (95% of headers) HACK is still 6x times better than SACK! TCP HACK (rajesh@cs.cmu.edu)

  22. Experiment Summary TCP HACK (rajesh@cs.cmu.edu)

  23. 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 TCP HACK (rajesh@cs.cmu.edu)

  24. 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 TCP HACK (rajesh@cs.cmu.edu)

  25. 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 TCP HACK (rajesh@cs.cmu.edu)

  26. Conclusion • Recovering header information can help • TCP HACK does better than SACK under various error conditions • Up to a factor of 100 reduction in time taken to complete transfer!!! • HACK is particularly useful under burst error conditions • Recovering even a small % of the headers helps dramatically TCP HACK (rajesh@cs.cmu.edu)

  27. Thank You! TCP HACK (rajesh@cs.cmu.edu)

  28. Header Corruption % • Tested using old 2 Mbit Lucent Wavelan Cards • Direct sequenced • Approximately 90-95% of the corrupted packets had intact headers under reasonable error rates • UDP lite (Larzon, Degermark, Pink) reports that about 0.8% of normal UDP fail the checksum at the receiver TCP HACK (rajesh@cs.cmu.edu)

  29. Effect of Window Size • Effect of different window sizes investigated • 16KB and 64KB windows were used • Results were similar TCP HACK (rajesh@cs.cmu.edu)

  30. TCP HACK (rajesh@cs.cmu.edu)

  31. TCP HACK (rajesh@cs.cmu.edu)

  32. Burst Errors (0%) Throughput for 2% burst error for various burst lengths Throughput for 5% burst error for various burst lengths TCP HACK (rajesh@cs.cmu.edu)

  33. Burst Errors (0%) (2) Throughput for 15% burst error for various burst lengths Throughput for 10% burst error for various burst lengths TCP HACK (rajesh@cs.cmu.edu)

  34. 1 2 3 4 Throughput versus percentage packet loss for short latency (10 ms) link with random single packet errors 2 1 3 4 Low Latency Links (95%) TCP HACK (rajesh@cs.cmu.edu)

  35. Throughput versus percentage packet loss for long latency (300 ms) link with random single packet errors 1 2 3 4 3 1 4 2 High Latency Links (95%) TCP HACK (rajesh@cs.cmu.edu)

  36. Fig. 7: Average number of slow-starts for long latency link with random single packet errors Number of Slow Starts (95%) TCP HACK (rajesh@cs.cmu.edu)

  37. Burst Errors (95%) Throughput for 2% burst error for various burst lengths Throughput for 5% burst error for various burst lengths TCP HACK (rajesh@cs.cmu.edu)

  38. Burst Errors (95%) (2) Throughput for 10% burst error for various burst lengths Throughput for 15% burst error for various burst lengths TCP HACK (rajesh@cs.cmu.edu)

  39. Time Sequence Graph for SACK (5% packet error rate with burst length of 5) Time Sequence Graphs (95%) TCP HACK (rajesh@cs.cmu.edu)

  40. 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) Time Sequence Graphs (95%) (2) TCP HACK (rajesh@cs.cmu.edu)

  41. Throughput versus Time graph for various TCP implementations (5% packet error rate with burst length of 5) Throughput Versus Time (95%) TCP HACK (rajesh@cs.cmu.edu)

More Related