Quantifying the Causes of Path Inflation Neil Spring, Ratul Mahajan, and Thomas Anderson

Quantifying the Causes Quantifying the Causes of Path Inflationof Path Inflation

Neil Spring, Ratul Mahajan, and Thomas AndersonNeil Spring, Ratul Mahajan, and Thomas Anderson

Presented byPresented byLuv KohliLuv Kohli

COMP290-088COMP290-088November 24, 2003November 24, 2003

OutlineOutline

• Problem and motivationProblem and motivation• Causes of path inflationCauses of path inflation• MethodologyMethodology• Results and conclusionsResults and conclusions

Problem and motivationProblem and motivation

• What is path inflation?What is path inflation?• Why are Internet paths sometimes Why are Internet paths sometimes

absurdly long?absurdly long?• Quantifying the causes may help Quantifying the causes may help

understand factors that shape Internet understand factors that shape Internet routesroutes

Causes of path inflationCauses of path inflation

• Six possible causes identified: topology Six possible causes identified: topology and routing policy at 3 layersand routing policy at 3 layers– Intra-domainIntra-domain– ISP peeringISP peering– Inter-domainInter-domain

FindingsFindings

• Intra-domain traffic engineering is Intra-domain traffic engineering is commonplace but has only minimal commonplace but has only minimal impact on path inflationimpact on path inflation

• Significant cooperation between Significant cooperation between adjacent ISPsadjacent ISPs

• Many paths that use early-exit are Many paths that use early-exit are inflated to an optimal exit policyinflated to an optimal exit policy

• Topology-insensitive load balancing can Topology-insensitive load balancing can cause significant path inflationcause significant path inflation

MethodologyMethodology

• Collected 19 million traces from 42 Collected 19 million traces from 42 measurement sources over 3 days to measurement sources over 3 days to discover 52000 router IP addresses in discover 52000 router IP addresses in 65 ISPs chosen65 ISPs chosen

Data collectionData collection

• Traceroute data collected from 42 Traceroute data collected from 42 diverse PlanetLab vantage points from diverse PlanetLab vantage points from around the worldaround the world

• Traced to all 125000 prefixes in the BGP Traced to all 125000 prefixes in the BGP routing tables of RouteViews which routing tables of RouteViews which peers with sixty large ISPspeers with sixty large ISPs

Choosing ISPs to studyChoosing ISPs to study

• Three criteriaThree criteria– ISP should be large enough to have ISP should be large enough to have

interesting intra-domain and inter-interesting intra-domain and inter-domain choices to makedomain choices to make

– ISP should carry enough diverse ISP should carry enough diverse traffic so its topology and routing traffic so its topology and routing policy are observablepolicy are observable

– Set of ISPs should be diverse in size Set of ISPs should be diverse in size and geographic presenceand geographic presence

Extracting topologyExtracting topology

• Determine which routers belong to each ISP Determine which routers belong to each ISP using BGP and DNSusing BGP and DNS

• Use BGP tables to distinguish IP address space Use BGP tables to distinguish IP address space of different ISPs and verify that the DNS name of different ISPs and verify that the DNS name of the router matches the ISP’s naming of the router matches the ISP’s naming conventionconvention

• Map routers to geographical location by Map routers to geographical location by inference from DNS namesinference from DNS names

• Reduce each router-level trace to city-level Reduce each router-level trace to city-level pathpath

Intra-domain factorsIntra-domain factors

• Intra-domain topology’s impact on path Intra-domain topology’s impact on path inflationinflation

• Inferring intra-domain policyInferring intra-domain policy• Policy’s impact on path inflationPolicy’s impact on path inflation

Intra-domain topologyIntra-domain topology

• Measure path inflation along shortest-Measure path inflation along shortest-latency path through the networklatency path through the network

• Compare this path to hypothetical direct Compare this path to hypothetical direct “as the crow flies” link“as the crow flies” link

Inferring intra-domain policyInferring 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 If ABC is observed between A and C and ADEC is an alternate

path, thenpath, then

• Also include error termsAlso include error terms

ECDEADBCAB wwwww

Peering factorsPeering factors

• Peering topology – union of all peering Peering topology – union of all peering points between two ISPspoints between two ISPs

• Peering policy – selection of which Peering policy – selection of which peering link to use to reach a peering link to use to reach a destinationdestination

Impact of peering topologyImpact of peering topology

• Compare paths that traverse two ISPs to Compare paths that traverse two ISPs to those that stay within the same ISPthose that stay within the same ISP

• Select optimal paths that cross two ISPs Select optimal paths that cross two ISPs – the intra-domain portions use least-– the intra-domain portions use least-weight paths from beforeweight paths from before

• Peering link chosen to minimize overall Peering link chosen to minimize overall path latencypath latency

Peering policyPeering policy

• Common policies include early-exit and Common policies include early-exit and late-exitlate-exit

• Load-balancing also existsLoad-balancing also exists• Need to determine what peerings show Need to determine what peerings show

“engineering,” assuming early-exit to “engineering,” assuming early-exit to be the defaultbe the default

Peering policyPeering policy

• Three classesThree classes– Late exit, often – pattern of late exit for Late exit, often – pattern of late exit for

most pathsmost paths– Late exit, sometimes – selective pattern of Late exit, sometimes – selective pattern of

late exit for a minority of pathslate exit for a minority of paths– Engineering, but not late – pattern where Engineering, but not late – pattern where

downstream ISP carries traffic over longer downstream ISP carries traffic over longer paths, perhaps using “load-balancing”paths, perhaps using “load-balancing”

Peering policyPeering policy

• Early- and late-exit policies both Early- and late-exit policies both seemed commonseemed common

• Peering policies vary widely, even Peering policies vary widely, even between neighbors of the same ISPbetween neighbors of the same ISP

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

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

Impact of peering policies Impact of peering policies (more peering points vs. (more peering points vs.

optimal-exit)optimal-exit)

Inter-domain factorsInter-domain factors

• Construct an abstract graph where Construct an abstract graph where nodes represent points of presence and nodes represent points of presence and edges represent early-exit paths edges represent early-exit paths between ISPs and least-weight paths between ISPs and least-weight paths between points of presence in the same between points of presence in the same ISPISP

• Compute shortest paths over this graph, Compute shortest paths over this graph, first minimizing latency to show effects first minimizing latency to show effects of topology, then minimizing AS-hops to of topology, then minimizing AS-hops to compare policiescompare policies

Impact of inter-domain Impact of inter-domain routing policyrouting policy

• Fundamental policies used by ISPsFundamental policies used by ISPs– No-valley – peers and customers do No-valley – peers and customers do

not generally provide transit.not generally provide transit.– Prefer-customer – paths through Prefer-customer – paths through

customers are preferred to those customers are preferred to those through peers, which are preferred to through peers, which are preferred to those via providersthose via providers

• These rules might create path inflationThese rules might create path inflation

Impact of inter-domain Impact of inter-domain factorsfactors

• Routing appears to have a significant Routing appears to have a significant impact on path inflationimpact on path inflation

• Policies arising out of commercial Policies arising out of commercial concerns do not seem to be a concerns do not seem to be a contributing factorcontributing factor

Cumulative impactCumulative impact

ConclusionsConclusions

• Two biggest factors are inter-domain Two biggest factors are inter-domain and peering policyand peering policy

• Observed inflation due to these policies Observed inflation due to these policies does not appear to be the result of does not appear to be the result of desired routing patterns, but a lack of desired routing patterns, but a lack of good tools for ISPs to find better pathsgood tools for ISPs to find better paths

• There is an absence of mechanisms in There is an absence of mechanisms in BGP to enable better path selectionBGP to enable better path selection

ReferencesReferences

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