1. 1 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

2. 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. 3 Talk Outline 1.Background on BGP convergence 2.Measurement methodology 3.Event characterization 4.Impact of policy and topology in observed convergence

4. 4 BGP Background and Monitoring Collector e.g. UCLA X=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 BGP is a path-vector protocol Collectors gather BGP routing tables + BGP updates

5. 5 F AB CD E 3 1 2 G Peer ProviderCustomer 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. 6 Talk Outline 1.Background on BGP convergence 2.Measurement methodology 3.Event characterization 4.Impact of policy and topology in observed convergence

7. 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 BGP feed Event Identification Event Classification Timeout TPath 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. 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. 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. 10 Event Classification time Initial path:p 0 p1p1 p2p2 p3p3 p4p4 p5p5 Final path:p 5 1 event p0p5p0p5 p 0 =…=p 5 p 0 =p 5 p0=p0= p5=p5= p 5 >p 0 p 0 >p 5

11. 11 Classifying T long and T short events: the problem of path comparision p1 time p2p3 Initial path p0Final 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. 12 Evaluating Path Rank Heuristics HeuristicDescription LengthShorter paths are preferred PolicyPreference: customer > peer > provider routes Policy + LengthSame as policy w/ path length tie-break Usage TimeTotal 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. 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 c_right: # of matches with calibration list c_wrong: # of mismatches

14. 14 Talk Outline 1.Background on BGP convergence 2.Measurement methodology 3.Event characterization 4.Impact of policy and topology in observed convergence

15. 15 Characterizing Events Events (x10 6 ) Duration (s) Paths Tup3.3945.261.77 Tdown3.35116.342.04 Tshort7.3933.261.34 Tlong7.9068.761.70 Tpdist18.32148.392.45 Tspath20.4443.471 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. 16 Talk Outline 1.Background on BGP convergence 2.Measurement methodology 3.Event characterization 4.Impact of policy and topology in observed convergence

17. 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. 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. 19 Impact of monitor location on observed convergence Monitors at lower tiers have more paths to explore 12 34 56 7 Peer Provider Customer Core Middle Edge

20. 20 Further breaking down events by origin  monitor pair Tdown duration (s) core  core 54 middle  core 60 edge  core 61 middle  middle 83 edge  edge 85 edge  middle 87 Worst case: edge  {edge, middle}

21. 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. 22 Origin of Tdown events CoreMiddleEdge No. Events 3,01134,51478,149 No. prefixes originated 14,36781,988122,877 No. Events per prefix 0.210.420.63 Networks in the core are the most stable; edge networks the most unstable (proportion 1:2:3)

23. 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. 24 Thanks! Questions? rveloso@cs.ucla.edu