Some Observations of Internet Stream Lifetimes CAIDA/WIDE, Los - - PowerPoint PPT Presentation

Some Observations of Internet Stream Lifetimes

CAIDA/WIDE, Los Angeles, 12 Mar 05

Nevil Brownlee

CAIDA and The University of Auckland

Internet Stream Lifetimes, CAIDA/WUDE 05 – p.1/20

Overview

Introduction, traffic flows Streams, stream density plots (packets and bytes) NeTraMet: implementation, performance Streams and packets at Auckland Usage metering, strategies to reduce meter overhead Effect of ignoring small streams Conclusion

Internet Stream Lifetimes, CAIDA/WUDE 05 – p.2/20

Introduction

A traffic flow is an abstraction representing the set of packets involved in some network activity There are two main classes of flows CPB (unidirectional, 5-tuple, fixed timeout). Also known as microflows RTFM (bidirectional, general, fixed timeout). User writes a ruleset to specify flows using values for a large set of attributes, and specifying direction Streams are subsets of RTFM flows (bidirectional, 5-tuple, dynamic timeout) more details later . . .

Internet Stream Lifetimes, CAIDA/WUDE 05 – p.3/20

Traffic rate plots

Count bytes in five flows for different kinds of traffic Match packets on protocol and port number:

SSL = TCP 443, web = TCP 80, nw TCP = other TCP ports UDP = all UDP , other = all other protocols

50 100 150 200 250 300 350 400 450 500 550 600 650 700 750 800 18:00 12/05 21:00 12/05 00:00 12/06 03:00 12/06 06:00 12/06 09:00 12/06 12:00 12/06 15:00 12/06 18:00 12/06 BB2 ’to’ bytes by kind, stacked bar plots, 5-6 Dec 03 (PST) Mb/s local time SSL web nw TCP UDP

• ther

Ca Backbone, 6 Dec 03 (PST)

5 10 15 20 00:00 10/01 06:00 10/01 12:00 10/01 18:00 10/01 00:00 10/02 06:00 10/02 12:00 10/02 18:00 10/02 00:00 10/03 Auckland inbound bytes by kind, stacked bar plots, 1-2 Oct 04 NZST) Mb/s local time SSL web nw TCP UDP

• ther

U Auckland, 1-2 Oct 04 (NZST)

Internet Stream Lifetimes, CAIDA/WUDE 05 – p.4/20

Streams – why are they useful?

Streams allow NeTraMet to compute metrics for components of flows, e.g. RTTs and IATs NeTraMet can return distributions of those metrics as attributes for such flows For the stream-distribution attributes ..

lifetimes <= 15m are counted directly longer streams are treated as fl

• ws; we sum their data each

interval to produce distributions with lifetimes up to 30,000s (≈ 8h)

The five different kinds are summed to produce ‘total traffic’ distributions at 10m intervals

Internet Stream Lifetimes, CAIDA/WUDE 05 – p.5/20

Stream & byte density vs lifetime plots

10 20 30 40 50 60 70 80 90 100 0.01 0.1 1 10 100 1000 10000 Cumulative distributions, totals vs stream lifetime at PAIX, Fri 12 Dec 03 (PST) % stream lifetime (s)

• utbound streams total
• utbound bytes total

Ca Backbone, 6 Dec 03 (PST)

10 20 30 40 50 60 70 80 90 100 0.01 0.1 1 10 100 1000 10000 Cumulative distributions, totals vs stream lifetime at Auckland, 1-2 Oct 04 (NZST) % stream lifetime (s) inbound streams total inbound bytes total

U Auckland, 1-2 Oct 04 (NZST)

At both sites, 95% of streams last ≤ 10s At U Auckland, up to 65% of the bytes are in streams ≤ 10s On the Ca backbone, only 20% of the bytes are in streams ≤ 10s, and about 60% of the bytes are in streams ≤ 1000s!

Internet Stream Lifetimes, CAIDA/WUDE 05 – p.6/20

NeTraMet implementation details

NeTraMet is an RTFM meter – user must write ruleset(s) that specify: which flows to count which end-point is the source how much detail is to be reported Uses stream caching: does flow matching for first packet of stream, saves flow number(s) uses cached flow number(s) for later packets can’t cache for rulesets that use non-5-tuple attributes usually gets ≈90% cache hit rate

Internet Stream Lifetimes, CAIDA/WUDE 05 – p.7/20

NeTraMet performance

1 Gb/s testbed, 1-processor meter, 1 DAG card 1500B frames, 1000Mb/s traffic NeTraMet sees 164 kp/s, reports 996.6 Mb/s 128B frames, 130 Mb/s of traffic NeTraMet sees 219 kp/s, reports 123.2 Mb/s Higher frames rate cause meter to ignore packets if they’re sustained for more than a second or two OC48 backbone, 2-processor meter, 2 DAG cards 600 Mb/s traffic NeTraMet sees 215 kp/s, no lost packets Tests performed in 2003 and 2004. Working on further speed improvements

Internet Stream Lifetimes, CAIDA/WUDE 05 – p.8/20

Streams vs time at Auckland

100 1000 10000 100000 04:00 10/01 08:00 10/01 12:00 10/01 16:00 10/01 20:00 10/01 00:00 10/02 04:00 10/02 Packets and Active Streams each second at Auckland, Fri 1 - Sat 2 Oct 04 (NZST) count local time packet/s active streams

⋆ Stream numbers follow the packet rate ⋆ High spikes about every 3 hours ⋆ Peak around midnight, 2 Oct, was not part

• f the diurnal pattern – it didn’t recur

Internet Stream Lifetimes, CAIDA/WUDE 05 – p.9/20

Details of Auckland stream spikes

1000 10000 100000 16:26 16:28 16:30 16:32 16:34 16:36 16:38 16:40 16:42 16:44 Packets and Active Streams each second at Auckland, on Fri 1 Oct 04 (NZST) count local time packet/s active streams 1000 10000 100000 21:16 21:18 21:20 21:22 21:24 21:26 21:28 21:30 21:32 21:34 count local time packet/s active streams

⋆ Note that increase in streams ≫ increase in packet rate!

Internet Stream Lifetimes, CAIDA/WUDE 05 – p.10/20

Usage metering at Auckland

High peaks in stream numbers load the meter, especially if many of them map to new flows Such peaks load the meter reader (data collection system) too We want to understand the peaks so that we can summarise them as special kinds of flow To start with, what is the effect of ignoring streams

≤ K packets in size?

What % of bytes are ignored for various K values?

Internet Stream Lifetimes, CAIDA/WUDE 05 – p.11/20

Auckland byte density vs stream packets

10 20 30 40 50 60 70 80 90 100 5 10 15 20 25 30 35 40 Cumulative % bytes vs Stream Size (packets), Auckland, Fri 1 Oct 04 (NZST) % packets

• utbound bytes v pkts

inbound bytes v pkts

⋆ Three hours of data, 10-minute intervals ⋆ Seems safe to ignore streams ≤ 6 packets ⋆ But one interval looks different !?

Internet Stream Lifetimes, CAIDA/WUDE 05 – p.12/20

Intervals with high small-stream %

Inbound rate UDP non-web web SSL

• ther

2110 0.15 2.91 8.85 0.51 0.03 2120 1.66 2.23 10.15 0.52 0.04 2130 0.21 1.37 9.86 0.50 1.09 Outbound rate UDP nonweb web SSL

• ther

2110 0.10 1.47 3.31 0.73 0.03 2120 0.10 0.92 3.34 0.850 0.03 2130 0.10 3.71 3.54 0.859 0.07

Tables show Mb/s rate for each traffi c kind Seldom saw low outbound non-web TCP ,

• ften saw high inbound UDP

High inbound UDP rate most small streams don’t generate a response those that do dominate outbound traffi c

Internet Stream Lifetimes, CAIDA/WUDE 05 – p.13/20

Auckland in+out byte density

10 20 30 40 50 60 70 80 90 100 5 10 15 20 25 30 35 40 Cumulative % bytes vs Stream Size (packets), Auckland, 1-2 Oct 04 (NZST) % packets in+out bytes v pkts

⋆ Two days of data, 10-minute intervals ⋆ ‘Outlier’ traces similar to previous plot ⋆ Need to understand the small streams ⋆ Can’t just focus on the elephants

Internet Stream Lifetimes, CAIDA/WUDE 05 – p.14/20

What happens if we ignore small streams?

100 1000 10000 100000 16:00 10/07 20:00 10/07 00:00 10/08 04:00 10/08 08:00 10/08 12:00 10/08 Packets and Active Streams each second at Auckland, Thu 7 - Fri 8 Oct 04 (NZDT) count local time packet/s active flows active streams

⋆ Similar to earlier plot ⋆ Here we show number of fl

• ws too

⋆ Flows track streams, no spikes ⋆ Confi rms that spikes come from short streams

Internet Stream Lifetimes, CAIDA/WUDE 05 – p.15/20

Ignoring small streams – detail plot

100 1000 10000 100000 22:00 10/07 22:30 10/07 23:00 10/07 23:30 10/07 00:00 10/08 00:30 10/08 01:00 10/08 Packets and Active Streams each second at Auckland, Thu 7 - Fri 8 Oct 04 (NZDT) count local time packet/s active flows active streams

⋆ Flows build up during interval, then drop when meter is read ⋆ Average number of fl

• ws remains stable

even during stream spikes

Internet Stream Lifetimes, CAIDA/WUDE 05 – p.16/20

Counting the ignored packets

We modified the NeTraMet meter to count bytes from ignored streams Counts are in LtMinStreamPDUs and LtMinStreamOctets distributions, held in a special LtMin flow We plotted the sum of these distributions for two days of 10-minute intervals . . .

Internet Stream Lifetimes, CAIDA/WUDE 05 – p.17/20

Packets & bytes ignored in small streams

30 10 3 1 0.3 00:00 12/15 04:00 12/15 08:00 12/15 12:00 12/15 16:00 12/15 20:00 12/15 00:00 12/16 % packets and bytes ignored at Auckland, Mon 14 - Tue 15 Dec 04 (NZDT) % local time ignored byte % ignored packet %

⋆ Ignored bytes below 2% except during spikes ⋆ Ignored packets stays below 10% similarly ⋆ Less than 7% of intervals (about 1 in 15) are spikes

Internet Stream Lifetimes, CAIDA/WUDE 05 – p.18/20

Summary

‘Ignore short streams’ strategy is simple and effective Our approach is not sampling – we don’t completely ignore short streams we count them in the LtMin distributions We’re continuing to look at plague of dragonflies behaviour, so we can count them as special cases. LtMin distributions are only our first attempt at this Sampling, using adaptive parameter setting (Moore et al., [7]) is an alternative technique, especially at very high line rates It would be interesting to compare the two techniques

Internet Stream Lifetimes, CAIDA/WUDE 05 – p.19/20

Conclusion

Operators and researchers need to understand traffic patterns so as to recognise special cases Adaptive sampling will probably work well in all cases But we can’t do that if we want a complete record for investigating security incidents Different tools provide different views of the network Operators need to run several different tools so as to build up an ongoing collection of traffic data for long-term traffic engineering and planning for post-mortem analysis of network events Thanks to my colleagues at CAIDA and Auckland !

Internet Stream Lifetimes, CAIDA/WUDE 05 – p.20/20