towards topology-aware network services
DESCRIPTION
Towards Topology-aware Network Services. Jia Wang AT&T Labs – Research http://www.research.att.com/~jiawang/ October 5, 2014. Topology-aware network services. Internet. Server. User. Outline. Popular services Network-aware clustering Methodology Statistical model of clusters - PowerPoint PPT PresentationTRANSCRIPT
1
Towards Topology-aware Network Services
Jia WangAT&T Labs – Research
http://www.research.att.com/~jiawang/April 20, 2023
2
Topology-aware network services
Internet
User
Server
3
Outline
Popular servicesNetwork-aware clustering Methodology Statistical model of clusters
Applications Traffic engineering - route popularity vs
stability Topology modeling - cluster graph CDN - proximity routing P2P
4
Peer-to-peer (P2P) networks
P2P systems (e.g. Napster, Gnutella, Freenet, KaZaA) New model of content distribution
End-hosts self-organize and share content among each other
Files are replicated among the application layer overlay network on demand
Significant traffic contribution P2P file sharing is #1 source of traffic
Large and growing user base 100+ Million downloads of KaZaA client
5
Opportunity and challengeScale well in terms of the hardware, bandwidth… For a wide deployment of P2P applications Need to understand P2P traffic Need a scalable content location and routing
scheme in the application layer Implications for Security
6
Popular P2P systems
Proprietary: e.g. FastTrack Closed/encrypted protocol
Open Source: e.g. Gnutella Heterogeneous implementation Specification not well defined Legacy feature support
7
Overview: P2P System
Search Network
A B
8
Overview: P2P System
Search Network
A B
Search: “Starwars.divx”
9
Overview: P2P System
Search Network
A BResponse: ”B has Starwars.divx”
10
Overview: P2P System
Search Network
A B
Get: “Starwars.divx”
11
Overview: P2P System
Search Network
A B
Resp: “Starwars.divx”
12
FastTrack vs. Gnutella
FastTrackProprietary ProtocolHomogeneous Network“2+ Million” Users“2+ PB” of dataSupernode Search Network
GnutellaOpen ProtocolHeterogeneous Network~150 Thousand(?)~500+GBPartial Ultrapeer Search Network
13
Gnutella Overview
A B
X
14
Gnutella Overview
A B
Search: “Starwars.divx”
X
15
Gnutella Overview
A B
Search: “Starwars.divx”
X
16
Gnutella Overview
A B
Search: “Starwars.divx”
X
17
Gnutella Overview
A B
Search: “Starwars.divx”
X
18
Gnutella Overview
A B
Resp: B has “Starwars.divx”
X
19
Gnutella Overview
A B
Resp: B has “Starwars.divx”
X
20
Gnutella Overview
A B
Resp: B has “Starwars.divx”
X
21
Gnutella Overview
A B
Resp: B has “Starwars.divx”
X
22
Gnutella Overview
A B
Get: “Starwars.divx”
X
23
Gnutella Overview
A B
Resp: “Starwars.divx”
X
24
Popularity of Gnutella Implementations
25
P2P traffic analysis
Data Flow level records from IGRs at a large ISP
[SIGCOMM-IMW2002-A] Both signaling traffic and actual data downloading Comparable to Web traffic volume
Gnutella traces: signaling traffic [SIGCOMM-IMW2001]
26
P2P traffic across large networkMethodology challenges Decentralized system Transient peer membership Some popular close proprietary protocols
Large-scale passive measurement Flow-level data from routers across a large tier-1 ISP
backbone Analyze both signaling and data fetching traffic 3 levels of granularity: IP, Prefix, AS
P2P protocols FastTrack:1214 (including Morpheus) Gnutella:6346/6347 DirectConnect:411/412
27
Methodology Discussion
Advantages Requires minimal knowledge of P2P protocols: port
number Large scale non-intrusive measurement More complete view of P2P traffic Allows localized analysis
Limitations Flow-level data: no application-level details Incomplete traffic flows
Other issues DHCP, NAT, proxy Host IP Asymmetric IP routing
28
Measurements
Characterization Overlay network topology Traffic distribution Dynamic behavior
Metrics Host distribution Host connectivity Traffic volume Mean bandwidth usage Traffic pattern over time Connection duration and on-time
29
Data cleaning
Invalid IPs 10.0.0.0-10.255.255.255 172.16.0.0-172.31.255.255.255 192.168.0.0-192.168.255.255
No matched prefixes in routing tablesInvalid AS numbers > 64512
Removed 4% flows
30
Overview of P2P traffic
Total 800 million flow recordsFastTrack is the most popular one
Date (2001) 9/10-9/15 10/9-10/13 12/10-12/16
# flows 111M 184M 341M
# IPs 3.4M 4.5M 5.9M
# IPs / day 1M 1.5M 1.9M
Total traffic (GB/day)
773 1153 1776
Traffic per IP (MB/day)
1.6 1.6 1.8
31
Host distribution
32
Host connectivity
Connectivity is very small for most hosts, very high for few hosts
Distribution is less skewed at prefix and AS levels
FastTrack (9/14/2001)
33
Traffic volume distribution
Significant skews in traffic volume across granularities
Few entities source most of the traffic Few entities receive most of the traffic
FastTrack (9/14/2001)
34
Mean bandwidth usage
Upstream usage < downstream usage. Possible causes are
Asymmetric available BW, e.g., DSL, cable Users/ISPs rate-limiting upstream data transfers
FastTrack (9/14/2001)
35
Time of day effect
Traffic volume exhibits very strong time-of-day effect Milder time-of-day variation for # hosts in the system
FastTrack (9/14/2001 GMT)
36
Host connection duration & on-time
Substantial transience: most hosts stay in the system for a short time
Distribution less skewed at the prefix and AS levels
Using per-cluster or per-AS indexing/caching nodes may help
FastTrack (9/14/2001) thd=30min
37
Traffic characterization
The power law May not be a suitable model for P2P traffic
Relationship between metrics Traffic volume Number of IPs On-time Mean bandwidth usage
38
Traffic volume vs. on-time
1. Volume heavy hitters tend to have long on-times2. Hosts with short on-times contribute small traffic volumes
FastTrack (9/14/2001): top 1% hosts (73% volume)
1
2
39
Connectivity vs. on-time
FastTrack (9/14/2001): top 1% hosts (73% volume)
1. Hosts with high connectivity have long on-times
2. Hosts with short on-times communicate with few other hosts
1
2
40
P2P vs Web
Observations 97% of prefixes contributing P2P traffic also
contribute Web traffic Heavy hitter prefixes for P2P traffic tend to be
heavy hitters for Web traffic
Prefix stability – the daily traffic volume (in %) from the prefix does not change over daysExperiments: 0.01%, 0.1%, 1%, 10% heavy hitters => 10%, 30%, 50%, 90% of the traffic volume
41
Traffic stabilityMarch 2002
Top 0.01% prefixes Top 1% prefixes
P2P traffic contributed by the top heavy hitter prefixesis more stable than either Web or total traffic
42
P2P traffic classification
Graph transformation AS relationship Flow size
43
Background
Inter-AS relationship Provider-customer: customer pays provider Peer-peer: mutually benefit by exchanging
traffic between respective customersBGP export rules An AS can export its routes and routes to its
customers to its provides/peers, but can not export routes learnt from other providers/peers.
An AS can exports its routes, routes of its customers and routes learnt from other providers/peers to its customers.
44
Methodology
AS paths AS categories ISP ISP-CUST ISP-PEER ISP-CUST-CUST* ISP-PEER-CUST* ISP-MH-CUST* UNKNOWN
customerprovider
customer
customer
customer
provider provider
provider
customerprovider
customer
customer
customer
provider provider
provider
peer
peer
45
Traffic classification
P2P traces Netflow
P2P traffic flows
Graph representation
Connected Components
Signaling trafficData traffic
Traffic classification
Threshold
AS relationship BGP configuration
ISP-CUST-CUST*ISP-PEER-CUST*ISP-MH-CUST*
ISPISP-PEERISP-CUST
46
Traffic data
P2P applications: DirectConnent, FastTrack, GnutellaFlow records from routers across a large IP network Control traffic: flow size <= threshold Data traffic: flow size > threshold Threshold = 4KB
Experiments: 3 weeks, each 5-7 days, 800 million flows in total from AT&T IP backbone
47
Classification results
Gnutella heaviest connected component 99% IPs, 99% bytes Signaling traffic: 90% IPs, 95% flows, 0.4%
bytes Data traffic: 50% IPs, 5% flows, 99.6% bytes
Signaling traffic is much less skewed than data traffic Signaling: top 1% IPs, 25% bytes Data: top 0.1% IPs, 30% bytes
48
Traffic direction
Type Signaling Data
Direction Src (%)
Dst (%)
Src (%)
Dst (%)
ATT 1.00 3.77 0.72 3.08
ATT-CUST 18.46 62.05 20.85 60.75
ATT-PEER 10.58 6.54 9.29 6.86
ATT-CUST-CUST* 0.00 0.00 0.00 0.00
ATT-PEER-CUST* 59.38 12.05 59.18 14.73
ATT-MH-CUST* 4.99 8.22 5.65 7.13
5% of the traffic are intra-AT&T (ATT and ATT-CUST).
49
Why topology-aware?
Better traffic engineering Load balancing Fault tolerant
Enhance service Workload
Flash crowds Denial of Service (DoS) attack
Proximity routing Lower latency More bandwidth
Ad tagging
Challenge: An IP address does not inherently contains an indication of location!Solution: network-aware clustering
50
Network-aware clustering
Goal: grouping IP addresses based on their location on the InternetNetwork-aware cluster [SIGCOMM2000] Non-overlap Topologically close Under common administrative control
Clustering requires knowledge that is not available to anyone outside the administrative entities.
51
Simple approaches to clustering
Autonomous Systems (ASes) are too coarse-grainedTwo approaches Use traditional class A, class B, and class C networks
Assume prefix length is always 24 (netmask 255.255.255.0)
Beginning bits
netmask # IP
Class A
0* 255.0.0.0 224
Class B
10* 255.255.0.0 216
Class C
110* 255.255.255.0
28
52
Simple approaches are not accurate
IP address Name Prefix/netmask
151.198.194.17 client-151-198-194-17.bellatlantic.net
151.198.194.16/28
151.198.194.34 mailsrv1.wakefern.com 151.198.194.32/28
151.198.194.50 firewall.commonhealthusa.com
151.198.194.48/28
53
More accurate approaches?
Tools Nslookup Dig -x Traceroute
More accurate, but not feasible
54
Network-aware approach
Use BGP routing and forwarding table snapshotsRouting table entries -> clustersExample snapshot of BGP routing tables
Prefix Prefix description Next hop AS path Peer
AS description
6.0.0.0/8 Army Information System Center
cs.ny-nap.vbns.net
7170 1455 (IGP)
AT&T Government Markets
12.0.48.0/20 Harvard University cs.cht.vbns.net 1742 (IGP) Harvard University
18.0.0.0/8 Massachusetts Institute of Technology
cs.cht.vbns.net 3 (IGP) Massachusetts Institute of Technology
55
Clustering in a nut shell
Obtain BGP tables from many places via a script and unify them into one big prefix tableExtract the IP addresses from Web logsPerform longest prefix matching on each IP addressClassify all the IP addresses which have the same longest matched prefix into a cluster (identified by the shared prefix)
56
Aut
omat
ed p
roce
ssClustering process
IP address extraction
IP addresses
Prefix extraction, unification, merging
Prefix table
Client cluster identification
Raw client clusters
Validation (optional)
Examining impact of network dynamics
Source of IP addresses BGP routing tables
Client clusters
Self-correction and adaptation
57
BGP tables
BGP tables AADS, MAE-EAST, MAE-WEST, PACBELL, PAIX,
ARIN, AT&T-Forw, AT&T-BGP, CANET, CERFNET, NLANR, OREGON, SINGAREN, Telstra, and VBNS.
Prefix format unification and merging Three formats
a.b.c.d/w.x.y.z a.b.c.d/m a.b.c.0
Assembled 450K entries by 8/23/2001
58
Example: cluster distributionNagano log (2/13/98): 11M requests, 60K IPs, 10K clusters
59
Example: cluster distribution
Highly skewed data: 700 busy clustersDetect suspect proxies and spiders
Nagano log (2/13/98): 11M requests, 60K IPs, 10K clusters
60
Detect proxy/spider
Histogram of the requests in Sun server log
0
0.002
0.004
0.006
0.008
0.01
0.012
0.014
1 25 49 73 97 121 145 169 193 217
Time (in hours)
Pe
rce
nta
ge
of
req
ue
sts
A client cluster containing a spider
0500
1000150020002500300035004000
1 25 49 73 97 121 145 169 193
Time (in hours)
Num
ber o
f req
uest
s iss
ued
A client cluster containing a proxy
0
2000
4000
6000
8000
10000
12000
14000
1 25 49 73 97 121 145 169 193
Time (in hours)
Nu
mb
er o
f r
eq
uests i
ssu
ed
61
Validation
Clusters may be mis-identified by being too large or too smallValidation: 1 IP “wrong”, entire cluster marked as “incorrect” Nslookup Dig –x Traceroute
Experiments on wide range of Web logs Apache, AltaVista, EW3, Nagano, Sun, Dig-lib, IRL,
Larmancom
Results > 99% clients can be grouped into clusters ~ 90% sampled clusters passed our validation tests ~ 50% accuracy for simple approaches
62
Modeling cluster sizes [KWF2001]
Cluster size # of request # of unique IP
Interesting clusters Busy clusters: # of requests > treq
Big clusters: # of IPs > tip
Zipf’s law: sr = c * r –a, sr is cluster size of rank r, c is constant and a is the exponent of the power law straight line in log-log scales c indicates the size of the cluster: larger c, larger the size
of a cluster is a indicates the slope of the straight line: larger |a|, faster
the size of a cluster decreases
63
Power law observations
The size of clusters does not obey power law on an entire Web logPower law holds on the size of the busy clusters and the size of big clustersThe exponent a is remarkably stable: 0.75-0.85 across Web logsThe power law holds over time with stable exponent aApplications: workload prediction, flash crowds and Denial of Service (DoS) attack detection
64
Topology-aware applications
Traffic engineering [SIGCOMM-IMW2002-C]Topology modeling [SIGCOMM-IMW2001-A]Web caching [SIGCOMM2000, BFKW2000, XWF2001]Content Distribution Networks (CDNs) [USENIX2002, XWF2001]Peer-to-peer (P2P) networks [SIGCOMM-IMW2001-B, SIGCOMM-IMW2002-A, SIGCOMM-IMW2002-B]
65
P2P architectures
Recent designs Distributed indexing scheme using hash
functions CAN, Chord, Tapestry
CAP: a Cluster-based Architecture for P2P systems [SIGCOMM-IMW2001] An additional level in hierarchy Less dynamism More scalability
66
CAP architecture
Three entities Clustering
server Delegate Client
Two operations Node joining
and leaving Query lookup
client delegate
Clustering server
67
Inter-cluster querying
Each query has a maximum search depthEach delegate keeps a neighbor list Assigned randomly when the delegate joins
the P2P network Updated gradually based on application
requirements
Depth-first search among neighbors
68
CAP evaluation
Trace-driven simulation Use Gnutella trace to generate “join”,
“leave”, “search” Assume the query distribution follows the
file distributions Performance metrics
Hit ratio Overhead Search latency
69
Gnutella traces
A modified open source Gnutella client (gnut) to passively monitor and log all the Gnutella messages
Location
Trace length
Number of IP addresses
CMU 10 hours
799,386
ATT 14 hours
302,262
ACIRI 6 hours 185,905
Location
Trace length
Number of IP addresses
CMU 89 hours 301,025
ATT 139 hours
261,094
UKY96 hours 409,084
75 hours 292,759
WPI 10 hours 69,285Traces with unlimited connectionsTraces with limited connections
70
Cluster distribution
CMU: 5/24/2001 – 5/25/2001, 799,386 IP addresses, 45,129 clustersClustering helps reduce query latency by caching repeated queries
71
Client and cluster dynamism
Network-aware clustering helps reduce dynamism in the P2P network
72
Hit Ratio
CMU trace1,000 node stationary network311 clusters4,615 search messages3,793 unique files
73
Overhead
Gnutella: overhead grows exponentially CAP: overhead grows linearly
74
Search path length
CAP search path is shortIncreasing number of neighbors will increase the percentage of successful queries, but it won’t reduce the search latency
75
Internet Topology graphs
Understand Internet topology Traffic patterns Protocol design Performance evaluation
Two levels of granularity Inter-domain level – AS graphs
Construction: AS-path, traceroute, synthetic graph Pros and cons: coarse-grained, easy to generate,
incomplete, connectivity reachability Router level – router graphs
Construction: traceroute + interface collapsing algorithm
Pros and cons: fine-grained, expensive
76
Cluster graphs
Intermediate-level of granularityUndirected graph Node: cluster of routers and hosts Edge: inter-cluster connection
Construction [SIGCOMM-IMW2001] Hierarchical graphs Traceroute-based graphs Synthetic graphs
•Extend AS graph by modeling the size/weight of AS•Use cluster-AS mapping extracted from BGP tables
•Traceroute to sampled IPs in interesting clusters•Construct a cluster path for each sampled IP•Merge cluster paths into a cluster graph
•Based on some observed characteristics, e.g., power laws
77
Super-clustering
Group clusters into super-clusters based on their originating ASBGP tables: May 2001Web log: a large portal site in March 2001 # of requests: 104M # of unique IPs: 7.6M # of clusters: 15,789 # of busy clusters (70% of the total): 3,000 # of super-clusters: 1,250 # of super-clusters with size >1: 436 Avg size of super-clusters: 2.4
78
Busy clusters in super-cluster
Cluster prefix Common name suffix
139.130.0.0/16 wnise.com
139.134.0.0/16 tmns.net.au
192.148.160.0/24 telstra.com.au
203.32.0.0/14 ocs.com.au
203.36.0.0/16 tricksoft.com.au
203.38.0.0/16 panorama.net.au
203.0.0.0/10 geelong.netlink.com.au
203.0.0.0/12 iaccess.com.au
ASes are too coarse-grained!
AS 1221
79
Constructing cluster graph
Top 99 busy clusters # unique IPs: 1.2M Sample 99 IPs (1 from each cluster)
Traceroute to 99 sampled IPs Ignore probes returning ‘*’: 17% Ignore unreachable probes(!N, !H, !P, !X): 0.3%
80
Cluster path
81
Cluster graph vs. AS graph
Observations Cluster graph has 34% more nodes and 15%
more edges than AS graph. The average node degree in cluster graph is
15% less than that in AS graph. Correlation between cluster hop counts and
end-to-end hop counts is stronger than that of AS hop counts. Similar observation holds for end-to-end latencies.
82
Cluster graph vs router graph
Observations Constructing cluster graph needs much less
traceroutes than router graph (99 vs thousands).
More traceroutes show that cluster graph is more stable than router graph.
83
Comparison of three models
Model AS graph Cluster graph
Router graph
Granularity Coarse Intermediate Fine
Construction
Stableness
Accuracy
84
Conclusion
Network-aware clustering Possible to learn network proximity from outside in
an automatic fashion Error rate: 90% (50% for the simple approaches) Power law model of cluster size
Topology-aware Applications BGP route (in)stability Cluster graph Proximity routing in CDNs P2P traffic analysis and classification CAP
85
Acknowledgements/collaborators
[SIGCOMM2000] On Network-Aware Clustering of Web Clients, B. Krishnamurthy and J. Wang, ACM SIGCOMM, 2000.[SIGCOMM-IMW2001-A] Topology Modeling via Cluster Graphs, B. Krishnamurthy and J. Wang, ACM SIGCOMM Internet Measurement Workshop, 2001.[SIGCOMM-IMW2001-B] Early Measurements of a Cluster-based Architecture for P2P Systems, B. Krishnamurthy, J. Wang, and Y. Xie, ACM SIGCOMM Internet Measurement Workshop, 2001.[USENIX2002] A Precise and Efficient Evaluation of the Proximity between Web Clients and Their Local DNS Servers, Z. M. Mao, C. D. Cranor, F. Douglis, M. Rabinovich, O. Spatscheck, and J. Wang, USENIX Annual Technical Conference, 2002.
86
Acknowledgements/collaborators (cont.)
[SIGCOMM-IMW2002-A] Analyzing Peer-to-peer Traffic Across Large Networks, S. Sen and J. Wang, ACM SIGCOMM Internet Measurement Workshop, 2002.[SIGCOMM-IMW2002-B] Automated traffic characterization for application-specific peering, B. Krishnamurthy and J. Wang, ACM SIGCOMM Internet Measurement Workshop, 2002.[SIGCOMM-IMW2002-C] BGP Routing Stability of Popular Destinations, J. Rexford, J. Wang, Z. Xiao, and Y. Zhang, ACM SIGCOMM Internet Measurement Workshop, 2002.
87
Acknowledgements/collaborators (cont.)
[BFKW2000] Fast Network-Aware Clustering by Faster Prefix Matching, A. L. Buchsbaum, G. S. Fowler, B. Krishnamurthy, and J. Wang, AT&T Labs - Research Technical Memorandum, 2000.[KWF2001] On the Use of Discrete Gaussian Exponential Distribution to Model Network-aware Cluster Sizes, B. Krishnamurthy, J. Wang, and C. Faloutsos, AT&T Labs - Research Technical Memorandum, 2001.[XWF2001] Constructing Effective Overlay Networks for Content Delivery, Z. Xiao, J. Wang, and C. Fetzer, AT&T Labs - Research Technical Memorandum, 2001.[GGRW2002] ENCORE: Enabling Configuration of Routing Elements, J. Gottlieb, A. Greenberg, J. Rexford, J. Wang, J. Borkenhagen, B. Freeman, R. Kwapniewski, and H. Nguyen, AT&T Labs - Research Technical Memorandum, 2002
88
BGP routing (in)stability
Border Gateway Protocol (BGP) Interdomain routing protocol Route updates at prefix level No activity in “steady state”
But, large # of BGP updates Failures, policy changes, redundant messages, …
Implications Router overhead Transient delay and loss Poor predictability of traffic flow
89
BGP routing and traffic popularity
A possible saving grace… Most BGP updates due to few prefixes … and, most traffic due to few prefixes ... but, hopefully not the same prefixes
Popularity vs. BGP stability Do popular prefixes have stable routes?
Yes, for ~ 10 days at a stretch! Does most traffic travel on stable routes?
A resounding yes! Direct correlation of popularity and stability?
Well, no, not exactly…
90
BGP Updates
BGP updates for March 2002 AT&T route reflector RouteViews and RIPE-NCC
Data preprocessing Filter duplicate BGP updates Filter resets of monitor sessions Removes 7-30% of updates
Grouping updates into “events” Updates for the same prefix Close together in time (45 sec) Reduces sensitivity to timing
Confirmed: few prefixes responsible for most events
91
Two Views of Prefix Popularity
AT&T traffic data Netflow data on peering links Aggregated to the prefix level Outbound from AT&T customers Inbound to AT&T customers
NetRatings Web sites NetRatings top-25 list Convert to site names DNS to get IP addresses Clustered into 33 prefixes
Amazon
www.amazon.com
207.171.182.16
207.171.176.0/20
Internet
AT&T
in out
92
Traffic Volume vs. BGP Events (CDF)
0
20
40
60
80
100
0 10 20 30 40 50 60 70 80 90 100
Traf
fic v
olum
e (%
)
BGP events (%)
InboundOutbound
50% of events1.4% of traffic
(4.5% of prefixes)
50% of traffic0.1% of events(0.3% of prefixes)
93
Update Events/Day (CCDF, log-log plot)
0.01
0.1
1
10
100
0.1 1 10
Per
cent
age
(%)
#Events/Day
AllInbound
OutboundNetrating 1% had
> 5 events per day
No “popular” prefix had > 3 events per
dayMost “popular” prefixes had <
0.2 events/day and just 1 update/event
94
An Interpretation of the Results
Popular stable Well-managed Few failures and fast recovery Single-update events to alternate routes
Unstable unpopular Persistent flaps: hard to reach Frequent flaps: poorly-managed sites
Unpopular does not imply unstable Most prefixes are quite stable Well-managed, simple configurations Managed by upstream provider
BGP instability does not affect most traffic
95
Proximity routing in CDNs
DNS (Domain Name System) based request redirection Assume the clients are close to their LDNS Redirect requests based on LDNS location
Evaluate the proximity between Web clients and their LDNS [USENIX2002] AS Network cluster Traceroute divergence Roundtrip time correlation
CDNs may use other additional metrics in requests redirection such as server load
96
Data gathering
1-3 commercial, 4-19 educational25M HTTP requests, 3M clients, 158K LDNS Use URL rewriting => Client-LDNS: 4,253,157
Site Type # of hits Duration
1 att.com 20,816,927
2 months
2,3 Personal pages (commercial domain)
1,743 3 months
4 Research lab 212,814 3 months
5-7 University sites 4,367,076 3 months
8-19 Personal pages (university domain)
26,563 3 months
97
AS and network clusters
Clients visiting educational sites have better proximity to their LDNSProximity between clients and LDNS can be improved substantially by changing LDNS configuration
Metrics Client IPs HTTP requests
AS Network
cluster
AS Network
cluster
Educational
70% 28% 83% 44%
Commercial
63% 16% 68% 23%
Combined 64% 16% 69% 24%
Improved 88% 66% 92% 70%
98
More proximity evaluation
Traceroute divergence Sampled 48,908 client-LDNS pairs Four probing sites: 2 in NJ, 1 in OH, 1 in CA Mean: 5.8-6.2 hops Median: 4 hops 1 hop: 14% >= 8 hop: 30% 78% have longer common path than disjoint path
A large fraction of clients are topologically close to their LDNS by hop countHowever, correlation between name server latency and client latency to a random probe site is quite low
99
DNS-based redirection in commercial CDNs
CDN X Y
Clients with CDN server in same AS
1.3M
0.5M
“Misdirected” clients
60% 82%
ASes occupied 92% 94%
Misdirected clients with LDNS not in the same AS
55% 60%
CDN X Y
Clients with CDN server in same network cluster
221K
90K
“Misdirected” clients
68% 96%
Network clusters occupied
77% 93%
Misdirected clients with LDNS not in the same network cluster
94% 97%
Q: How does client-LDNS proximity affect CDN server selection?
100
Observations on commercial CDNs
There are a large number of misdirected clientsThe misdirected clients are spread across ASes and network clustersThe misdirection is mainly due to the fact that client and its LDNS are not proximal AS is too coarse grained: in most cases, the closest CDN
server is not in the same AS as the client The strong correlation between misdirection and LDNS
being in a different cluster indicate the fact that LDNS and client do not belong to the same cluster limits the accuracy of server selection
Traceroute divergence: over 70% of the clients are directed to a CDN server that is more distant than another available CDN server
101
More observations
DNS based redirection is good enough for coarse-grained server selection, but not for finer-grained server selectionClient-LDNS association are fairly stable => build up a database to infer the topological location of clients to improve server selectionOngoing work: proximity routing table construction