1 / 20

TCP Traffic Analysis in cooperation with Motorola

TCP Traffic Analysis in cooperation with Motorola. Todd DeSantis and David Loose. Advisor: Professor Mark Claypool Co-Advisor: Professor Robert Kinicki MQP Presentation February 11,2004. Project Motivation. Increase in broadband use Motorola is seeking more efficient hardware

harristimothy
Download Presentation

TCP Traffic Analysis in cooperation with Motorola

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 Traffic Analysis in cooperation withMotorola Todd DeSantis and David Loose Advisor: Professor Mark Claypool Co-Advisor: Professor Robert Kinicki MQP Presentation February 11,2004

  2. Project Motivation • Increase in broadband use • Motorola is seeking more efficient hardware • Changing Internet traffic • Emergence of P2P applications • Streaming media • Captured TCP packets show trends • Can draw conclusions based on data

  3. Project Goals • Characterize traffic patterns in traces • Identify possible optimizations • Hardware • Software

  4. Capture File Summary • Packet sniffer at cable ISP head-end • Captures traffic from upstream & downstream links • Packet traces generated by tcpdump • Uses libpcap capture file format • Common format used by many Open Source tools • Traces include all headers up to Transport layer • Packets anonymized • Each IP address mapped to unique, anonymous address • Port numbers preserved

  5. Tools • libpcap • Used to interpret tcpdump files • Facilitated writing of custom programs to analyze data • tcptrace • Attempt to recreate the TCP flow • Gathers many useful statistics about the flow • Ethereal • GUI front-end for tcpdump • Allowed visualization of data

  6. Results (Transport Protocols) • TCP - 98.14% total bytes transmitted • UDP – 1.74% total bytes transmitted • ICMP, GRE, ESP and OSPFIGP combine for the final 0.12%

  7. Results (Application Protocols)

  8. Results (Packet Sizes) • We graphed the cumulative distribution function (CDF) of packet sizes. • Most common packet size - 54 bytes • 2nd common packet size – 1514 bytes • Average packet size – 619.9 bytes • Largest size encountered – 2062 bytes

  9. Results (TCP-SACK) • Prevalence among SYN-sending hosts • Enabled on 30,377 hosts out of 33,542 • Enabled on 97% of downstream hosts

  10. Results (TCP-SACK)

  11. Results (ECN) • Nearly non-existent use of ECN • Only 7 out of the 38,572 unique hosts were ECN capable • Negligible performance implications with this low level of deployment

  12. Results (Non-Responsive Traffic) • What is non-responsive traffic? • TCP accounts for 98.12% of traffic on average • UDP accounts for most non-TCP traffic • For our purposes, we assume all non-TCP traffic is non-responsive

  13. Results (Non-Responsive Traffic) • Methodology • Set “high” and “low” as percentage of total traffic • “high” = >5% of traffic during selected period • “low” = <1% of traffic during selected period • 3 30-second samples for high and low • Performance metrics: RTT, Retransmission Rate

  14. Results (Non-Responsive Traffic)

  15. Results (Non-Responsive Traffic)

  16. Results (Non-Responsive Traffic) • Problems • Finding suitable samples • Difficult to find periods during which non-responsive traffic at peak

  17. Results (Sample Sizes) • We split trace files into 15 minute subunits • SACK loss rates were computed: 15 minute trace files 30 minute trace files 1 hour trace files

  18. Results (Sample Sizes cont.) • These tests show a significant difference between the 15 and 30 min. samples and a much smaller difference between the 30 and 60 min samples • Based on these results, we were able to determine that a 30 minute sample is sufficient for SACK analysis

  19. Conclusions • Internet traffic is changing • KaZaa is the biggest bandwidth user (traditionally WWW) • Cable modems can be optimized • PEPs can help relieve ACK-compression • Additional upstream bandwidth • TCP can be optimized • Further deployment of SACK & ECN

  20. Questions?

More Related