1 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

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 % 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 2 nd common packet size – 1514 bytes Average packet size – 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?