TCP Traffic Analysis in cooperation with Motorola

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 - 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 gt5 of traffic during selected period
• low lt1 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?