Download - Quantifying Path Exploration in the Internet
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