1

TCP Traffic Analysis in cooperation with

Motorola

Todd DeSantis and David Loose

Advisor: Professor Mark ClaypoolCo-Advisor: Professor Robert KinickiMQP 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 files30 minute trace files1 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?