quantifying path exploration in the internet

Post on 13-Jan-2016

28 Views

Category:

Documents

1 Downloads

Preview:

Click to see full reader

DESCRIPTION

Quantifying Path Exploration in the Internet. Ricardo Oliveira, Rafit Izhak-Ratzin, Lixia Zhang, UCLA Beichuan Zhang, UArizona Dan Pei, AT&T Labs -- Research IMC’06, Rio de Janeiro. Motivation. There has been extensive work measuring BGP convergence , however most work: - PowerPoint PPT Presentation

TRANSCRIPT

1

Quantifying Path Exploration in the

Internet

Ricardo Oliveira, Rafit Izhak-Ratzin, Lixia Zhang, UCLA

Beichuan Zhang, UArizonaDan Pei, AT&T Labs -- Research

IMC’06, Rio de Janeiro

2

Motivation

• There has been extensive work measuring BGP convergence, however most work: – was done in controlled simulation environments, e.g. [Labovitz’00]

– using a small number of beacon-like prefixes, e.g.[Labovitz’00, Labovitz’01, Mao’03]

• We did a systematic measurement of path exploration in the operational Internet

3

Talk Outline

1. Background on BGP convergence

2. Measurement methodology

3. Event characterization

4. Impact of policy and topology in observed convergence

4

BGP Background and Monitoring

Collector

e.g. UCLAX=AS52 announcing prefix 131.179/16

X

Y

Z

131.179/16 : [Y X]

131.179/16 : [Z Y X]

131.179/16 : [Y X]

131.179/16: [X]

Monitor

Monitor

• BGP is a path-vector protocol• Collectors gather BGP routing tables + BGP updates

5

F

A B

C D

E

3

1

2

G

Peer Peer

Provider Customer

Q: What happens if link F-G fails?

A: Node E explores 2 paths before declaring G unreachable…

What is path exploration?

X

Q: Why is this a problem?• Delays and loss of data pkts• Extra router processing

3 W

Relative convergence time

2

time

6

Talk Outline

1. Background on BGP convergence

2. Measurement methodology

3. Event characterization

4. Impact of policy and topology in observed convergence

7

Methodology

• Preprocessing: removed session resets; cleaned beacons using anchor prefixes

• Event Identification: grouped updates for same (monitor,prefix) across time using relative timeout T

• Event Classification: classify events according to explored paths and output of path rank heuristic

Preprocessing

Raw BGPfeed

EventIdentification

EventClassification

Timeout T Path Rank Heuristic

• Data Set: 50 monitors of RV+RIPE and 1 month of data (Jan’06)

BGP Beacons were used to calibrate our event identification scheme and evaluated different path rank heuristics

8

BGP Beacons• Periodic BGP announcements and withdraws that are artificially injected in the network [Mao’03, RIPE]

time

2h

WA

Beacon Announcement

Beacon Withdraw

A

2h

• Used as calibration points:• clean signals: no noise caused by sporadic events• beacon event times are known

9

Event Identification• A single event can trigger multiple updates

• Need to cluster BGP updates along time dimension for each (monitor, prefix) pair

• Q: what relative timeout T should we use?

A: T=240s (4min)

10

Event Classification

time

Initial path:p0

p1 p2 p3 p4 p5

Final path:p5

1 event

p0p5 p0=…=p5p0=p5

p0= p5= p5>p0 p0>p5

11

Classifying Tlong and Tshort events: the problem of path

comparisionp1

time

p2 p3Initial path p0 Final path p3

1 event

• This event is classified as:•Tshort: if pref(p3) > pref(p0) •Tlong: if pref(p3) < pref(p0)

•Because of policy routing, the shorter path is not always the preferred path…

•Q: Which path the router prefers: p0 or p3?

12

Evaluating Path Rank Heuristics

Heuristic Description

Length Shorter paths are preferred

Policy Preference: customer > peer > provider routes

Policy + Length Same as policy w/ path length tie-break

Usage Time Total time a path is in routing table; more used paths are preferred

Calibration list

pref(p1) < pref(p4)

pref(p2) < pref(p4)

pref(p3) < pref(p4)

pref(p5) < pref(p4)

pref(p6) < pref(p4)

13

Evaluating Path Rank Heuristics

• Extending this method to all prefixes, the accuracy of each heuristic is:

Policy: 17%Length: 65%Policy+ Length: 73%Usage time: 95%

Usage time is most accurate heuristic to determine path preference

Beacons’ Tdown

Accuracy =c _ right

c _ right + c _wrong• c_right: # of matches with calibration list• c_wrong: # of mismatches

14

Talk Outline

1. Background on BGP convergence

2. Measurement methodology

3. Event characterization

4. Impact of policy and topology in observed convergence

15

Characterizing Events

Events

(x106)

Duration (s)

Paths

Tup 3.39 45.26 1.77

Tdown 3.35 116.34 2.04

Tshort 7.39 33.26 1.34

Tlong 7.90 68.76 1.70

Tpdist 18.32 148.39 2.45

Tspath 20.44 43.47 1

Tshort < Tspath ~ Tup < Tlong << Tdown < Tpdist

Tdown convergence time is significantly higher than Tlong convergence time, contrasting with worst case analysis of [Labovitz’01]

16

Talk Outline

1. Background on BGP convergence

2. Measurement methodology

3. Event characterization

4. Impact of policy and topology in observed convergence

17

The impact of policy and topology in observed

convergence

• What about MRAI timer?

• BGP RFC specifies that the MRAI should have a base of 30s + jitter between 0.75 and 1

• Not all ISPs follow RFC . . .

• How is the convergence process perceived by monitors in different locations in the Internet?

MRAI

Non-MRAI

18

Impact of monitor location on observed

convergence• Set of MRAI monitors : 4 core(tier-1), 15 middle(transit) and 3 edge (stub)

Convergence time by monitor location : core < middle < edge

19

Impact of monitor location on observed

convergence

• Monitors at lower tiers have more paths to explore

1 2

3 4

5 6

7

Peer Peer

Provider Customer

Core

Middle

Edge

20

Further breaking down events by originmonitor

pairTdown duration (s)

corecore 54

middlecore 60

edgecore 61

middlemiddle 83

edgeedge 85

edgemiddle 87

Worst case: edge {edge, middle}

21

The Impact of Tdown Convergence

A

B C

131.179/16 131.179.100/24Q: What happens when the /24 prefix is withdrawn?

A: Routers will experience Tdown convergence, even though the destination is still reachable via the /16 prefix…

•According to recent measurements, about 1/3 of prefixes in routing table are in the same scenario as the /24 in this example

In a Tdown the destination becomes unreachable, therefore we don’t care about routing convergence time …… or do we?

22

Origin of Tdown events

Core Middle EdgeNo. Events 3,011 34,514 78,149No. prefixes originated

14,367 81,988 122,877

No. Events per prefix

0.21 0.42 0.63

Networks in the core are the most stable; edge networks the most unstable (proportion 1:2:3)

23

Conclusions• Usage time: new path ranking heuristic which provides +95% accuracy in determining routers’ path preference

• Tdown convergence is by far the longest, even when compared with Tlong

• Core-to-core convergence is the fastest case; edge-to-{edge,middle} the slowest

• Core networks are three times more stable than edge networks

24

Thanks!

Questions?

rveloso@cs.ucla.edu

top related