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
1
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
2
Project Goals

Characterize traffic patterns in traces

Identify possible optimizations


Hardware
Software
3
Capture File Summary

Packet sniffer at cable ISP head-end


Packet traces generated by tcpdump




Captures traffic from upstream & downstream links
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
4
Tools

libpcap



tcptrace



Used to interpret tcpdump files
Facilitated writing of custom programs to analyze
data
Attempt to recreate the TCP flow
Gathers many useful statistics about the flow
Ethereal


GUI front-end for tcpdump
Allowed visualization of data
5
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%
6
Results (Application Protocols)
7
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
8
Results (TCP-SACK)

Prevalence among SYNsending hosts


Enabled on 30,377 hosts
out of 33,542
Enabled on 97% of
downstream hosts
9
Results (TCP-SACK)
10
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
11
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
12
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
13
Results (Non-Responsive Traffic)
14
Results (Non-Responsive Traffic)
15
Results (Non-Responsive Traffic)

Problems

Finding suitable samples

Difficult to find periods during which nonresponsive traffic at peak
16
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
17
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
18
Conclusions

Internet traffic is changing


Cable modems can be optimized



KaZaa is the biggest bandwidth user (traditionally
WWW)
PEPs can help relieve ACK-compression
Additional upstream bandwidth
TCP can be optimized

Further deployment of SACK & ECN
19
Questions?
20