1. Quantifying the Causes of Path Inflation Neil Spring, Ratul Mahajan, and Thomas Anderson Presented by Luv Kohli COMP290-088 November 24, 2003

2. Outline Problem and motivationProblem and motivation Causes of path inflationCauses of path inflation MethodologyMethodology Results and conclusionsResults and conclusions

3. Problem and motivation What is path inflation?What is path inflation? Why are Internet paths sometimes absurdly long?Why are Internet paths sometimes absurdly long? Quantifying the causes may help understand factors that shape Internet routesQuantifying the causes may help understand factors that shape Internet routes

4. Causes of path inflation Six possible causes identified: topology and routing policy at 3 layersSix possible causes identified: topology and routing policy at 3 layers –Intra-domain –ISP peering –Inter-domain

6. Findings Intra-domain traffic engineering is commonplace but has only minimal impact on path inflationIntra-domain traffic engineering is commonplace but has only minimal impact on path inflation Significant cooperation between adjacent ISPsSignificant cooperation between adjacent ISPs Many paths that use early-exit are inflated to an optimal exit policyMany paths that use early-exit are inflated to an optimal exit policy Topology-insensitive load balancing can cause significant path inflationTopology-insensitive load balancing can cause significant path inflation

7. Methodology Collected 19 million traces from 42 measurement sources over 3 days to discover 52000 router IP addresses in 65 ISPs chosenCollected 19 million traces from 42 measurement sources over 3 days to discover 52000 router IP addresses in 65 ISPs chosen

8. Data collection Traceroute data collected from 42 diverse PlanetLab vantage points from around the worldTraceroute data collected from 42 diverse PlanetLab vantage points from around the world Traced to all 125000 prefixes in the BGP routing tables of RouteViews which peers with sixty large ISPsTraced to all 125000 prefixes in the BGP routing tables of RouteViews which peers with sixty large ISPs

9. Choosing ISPs to study Three criteriaThree criteria –ISP should be large enough to have interesting intra-domain and inter- domain choices to make –ISP should carry enough diverse traffic so its topology and routing policy are observable –Set of ISPs should be diverse in size and geographic presence

13. Extracting topology Determine which routers belong to each ISP using BGP and DNSDetermine which routers belong to each ISP using BGP and DNS Use BGP tables to distinguish IP address space of different ISPs and verify that the DNS name of the router matches the ISP’s naming conventionUse BGP tables to distinguish IP address space of different ISPs and verify that the DNS name of the router matches the ISP’s naming convention Map routers to geographical location by inference from DNS namesMap routers to geographical location by inference from DNS names Reduce each router-level trace to city-level pathReduce each router-level trace to city-level path

14. Intra-domain factors Intra-domain topology’s impact on path inflationIntra-domain topology’s impact on path inflation Inferring intra-domain policyInferring intra-domain policy Policy’s impact on path inflationPolicy’s impact on path inflation

15. Intra-domain topology Measure path inflation along shortest- latency path through the networkMeasure path inflation along shortest- latency path through the network Compare this path to hypothetical direct “as the crow flies” linkCompare this path to hypothetical direct “as the crow flies” link

17. Inferring intra-domain policy Assumed that routing is weighted shortest pathAssumed that routing is weighted shortest path Use a constraint-based approach to determine weightsUse a constraint-based approach to determine weights Weight of observed path must be ≤ weight of alternate pathsWeight of observed path must be ≤ weight of alternate paths If ABC is observed between A and C and ADEC is an alternate path, thenIf ABC is observed between A and C and ADEC is an alternate path, then Also include error termsAlso include error terms

19. Peering factors Peering topology – union of all peering points between two ISPsPeering topology – union of all peering points between two ISPs Peering policy – selection of which peering link to use to reach a destinationPeering policy – selection of which peering link to use to reach a destination

20. Impact of peering topology Compare paths that traverse two ISPs to those that stay within the same ISPCompare paths that traverse two ISPs to those that stay within the same ISP Select optimal paths that cross two ISPs – the intra-domain portions use least- weight paths from beforeSelect optimal paths that cross two ISPs – the intra-domain portions use least- weight paths from before Peering link chosen to minimize overall path latencyPeering link chosen to minimize overall path latency

22. Peering policy Common policies include early-exit and late-exitCommon policies include early-exit and late-exit Load-balancing also existsLoad-balancing also exists Need to determine what peerings show “engineering,” assuming early-exit to be the defaultNeed to determine what peerings show “engineering,” assuming early-exit to be the default

23. Peering policy Three classesThree classes –Late exit, often – pattern of late exit for most paths –Late exit, sometimes – selective pattern of late exit for a minority of paths –Engineering, but not late – pattern where downstream ISP carries traffic over longer paths, perhaps using “load-balancing”

26. Peering policy Early- and late-exit policies both seemed commonEarly- and late-exit policies both seemed common Peering policies vary widely, even between neighbors of the same ISPPeering policies vary widely, even between neighbors of the same ISP

27. Impact of peering policies (early- vs. late-exit)

28. Impact of peering policies (early- vs. optimal-exit)

29. Impact of peering policies (more peering points vs. optimal-exit)

30. Inter-domain factors Construct an abstract graph where nodes represent points of presence and edges represent early-exit paths between ISPs and least-weight paths between points of presence in the same ISPConstruct an abstract graph where nodes represent points of presence and edges represent early-exit paths between ISPs and least-weight paths between points of presence in the same ISP Compute shortest paths over this graph, first minimizing latency to show effects of topology, then minimizing AS- hops to compare policiesCompute shortest paths over this graph, first minimizing latency to show effects of topology, then minimizing AS- hops to compare policies

32. Impact of inter-domain routing policy Fundamental policies used by ISPsFundamental policies used by ISPs –No-valley – peers and customers do not generally provide transit. –Prefer-customer – paths through customers are preferred to those through peers, which are preferred to those via providers These rules might create path inflationThese rules might create path inflation

34. Impact of inter-domain factors Routing appears to have a significant impact on path inflationRouting appears to have a significant impact on path inflation Policies arising out of commercial concerns do not seem to be a contributing factorPolicies arising out of commercial concerns do not seem to be a contributing factor

35. Cumulative impact

36. Conclusions Two biggest factors are inter-domain and peering policyTwo biggest factors are inter-domain and peering policy Observed inflation due to these policies does not appear to be the result of desired routing patterns, but a lack of good tools for ISPs to find better pathsObserved inflation due to these policies does not appear to be the result of desired routing patterns, but a lack of good tools for ISPs to find better paths There is an absence of mechanisms in BGP to enable better path selectionThere is an absence of mechanisms in BGP to enable better path selection

37. References N. Spring, R. Mahajan, T. Anderson, Quantifying the Causes of Path Inflation. ACM SIGCOMM, August, 2003.N. Spring, R. Mahajan, T. Anderson, Quantifying the Causes of Path Inflation. ACM SIGCOMM, August, 2003.