Public DNS System and Global Traffic Management

Transcription

1 . This paper was presented as part of the main tehnial program at I INFOCOM 211 Publi DNS System and Global Traffi Management Cheng Huang Mirosoft Researh David A. Maltz Mirosoft Researh Albert Greenberg Mirosoft Researh Jin Li Mirosoft Researh Abstrat---Cloud servie providers operate data enters around the world, and they depend on Global Traffi Management systems to diret requests from lients to the most appropriate data enter to serve the requests. While GTM systems have been in-use for years, they are attrating re-newed interests due to the rapid expansion of loud servie providers' networks, the introdution of publi DNS systems, as well as new proposals to alter how they should work and what information loal DNS servers (LDNS) should make available to drive the GTM systems. This paper uses large-sale measurements onduted from more than 5M lients to establish properties of the urrent Internet that affet the design of the GTM systems, suh as the streth between a lient's atual position and its LDNS from GTM's perspetive, the impat of publi DNS systems, and the granularity at whih GTM deisions should be made. The results an inform the debate over how GTM systems should be designed. I. IN TRODCTION Cloud servie providers, suh as Amazon, Google, Mirosoft and Yahoo, operate data enters around the world, and they depend on Global Traffi Management systems to diret requests from end-users to the most appropriate data enter to serve them. Many studies have shown that the end-users are extremely sensitive to response lateny and revenue an be signifiantly impated beause of that [8]. For example, an extra 1 ms delay an derease revenue by 1% [21]. Hene, direting a request to a sub-optimal data enter is undesirable. Today, the most ommonly used mehanism to implement Global Traffi Management leverages the Domain Name System. When a lient looks up a FQDN, suh as the lient's host will ontat its loal domain name server (LDNS) and request the resolution of the FQDN into an IP address. The LDNS will then send a resolution request to the authoritative name server for example. om. The authoritative name server uses information available to it - typially just the IP address of the LDNS server - to determine whih data enter it would like to serve the request. It returns the IP address of the seleted data enter to the LDNS, whih ahes the address for the length of time suggested by the authoritative name server. The LDNS thn returns the IP address to the lient, whih finally sends Its request to that IP address. The basi problem to be solved in building a GTM system is oming up with a map M(lient group) --+ data enter, where M maps eah group of lients to a data enter that will serve the lients' requests. I For DNS-based GTM systems, as desribed above, the only possible method of grouping lients I In this paper, we assume all data enters are equally apable of serving any lient's request, whih is typially the ommon ase. today is by their LDNSes - sine the only information the authoritative name server has about the lients is the IP address of their LDNS servers, the authoritative name server must assign all the lients behind a partiular LDNS to the same data enter. In a world where LDNS servers are assigned to lients by the lients' ISPs and the LDNSes are topologially lose, this might be a reasonable approximation.. However, there are now multiple Publi DNS systems bemg offered by ompanies like Google, Leve13 and OpenDNS [5], [17]. Clients an bypass their ISP-assigned LDNSes and use the Publi DNS servers instead, whih might be far away from the lients, ause onfusion to GTM systems and result in the lients being direted to sub-optimal data enters. To ounterat this problem, there are reent proposals that LDNS servers should expose a portion of the lients' IP address to the authoritative name server. In this paper, we ondut an extensive measurement study to quantify the negative impat on the end-users when using the Publi DNS systems as ompared to the ISP-assigned LDNS servers, and we evaluate the effetiveness of modifying LDNSes by making lient information available to GTM systems. Speifially, we address the following questions:. --+ How well do the ISP-assigned LDNS servers approximate the loation of the lients from the perspetive of GTM systems? --+ How large are the geographi presene of the Publi DNS systems, and how do they ompare with the LDNS servers deployed by ISPs? How well do the Publi DNS servers approximate the lients? --+ If LDNS servers are to expose a portion of the lients' IP address, what granularity of subnet is most appropriate? Our key findings are: ISP-assigned LDNS servers are reasonable approximation for most lients - up to 8% of the lients are within 428 km of their LDNSes. From 17 prodution data enters distributed over 4 ontinents, the best data enter seleted based on the lients' LDNS is only 14 ms further away (from the lients) than the ground-truth optimal, at the 8-perentile. The Publi DNS systems do not have extensive geographi presene. The Google DNS servers are only deployed in 12 loations world wide, while Leve13 and OpenDNS in 11 and 1 loations, respetively. The Publi DNS systems are signifiantly further away from the lients than the ISP-assigned LDNSes. As a result, the Publi DNS systems degrade lient-pereived performane. At the 95-perentile, while the best data /11/$ I 2615

2 enter - hosen for those lients using ISP-assigned LDNSes - is already 84 ms further away (from the lients) than the ground-truth optimal, the sub-optimality further degrades to 193 ms, 129 ms and 156 ms, respetively, for those using Google, Level3 and OpenDNS. Modifying LDNS servers to pass lient information to the authoritative name server an alleviate the adverse impat of the Publi DNS systems. Grouping by 124 prefix appears to be a reasonable trade-off between performane improvement and overhead. being downloaded. The 1ient-IP address is the most identifying information, and this same address is available to the servie the user made the request of, so our flight does not reveal additional identifying information. Over 8 weeks, the flight experiment was exeuted by over 5M unique IP addresses in over 2M unique 124 subnets. The median exeution ompleted probing 5 data enters before the user liked away from the page. B. DNS Beaon II. M THODOLOGY Our analysis is based on data olleted through two main mehanisms: a Javasript flight and ping studies. The servies with whih we work are IPv4-based, so our study does not inlude IPv6. Our study measures the HTTP GT response time and ICMP ping RTT between lients and 17 prodution data enters distributed over North Ameria (7), urope (6), Asia (3), and Australia (1). A. Flight xperiment To measure the response time from lients to data enters around the world, we onduted a flight experiment [11] in whih Javasript ode is inserted at end of a ommonly aessed ommerial webpage for between I and 5 perent of visitors. The users reeiving the Javasript were seleted in an unbiased fashion from among all visitors to the site, whih inludes signifiant representation from all areas of the world. We verified that users seleted to run our Javasript had the same behavior as other users, so our experiment did not affet their behavior (our Javasript was designed to be ompletely unobtrusive). The Javasript begins exeuting 5 ms after the page load finishes, and this delay is intended to avoid interfering with other objets downloading from the main page. While exeuting, the Javasript selets the IP address of a data enter from a list of 17 IP addresses arried in the Javasript, and then downloads a 1KB image from that data enter. The Javasript measures the time to download the image and posts this information bak to a logging server along with a GID reated for this exeution of the Javasript. The logging server reords the GID, the data enter from whih the image was fethed, and the IP address of the lient. The Javasript exeutes until the users liks away from the page or it has probed all 17 data enters. A timeout of 4 seonds was used on eah download attempt, and the probing starts at a randomly hosen data enters on eah invoation. We hose a 1KB image to download as the data annot be ompressed further, and many important web pages and objets in our organization are roughly this size. There is no per-user ookie or token used - a NAT or proxy with many users behind it will appear in our logs as a single lient IP address assoiated with many GIDs (Le., invoations of the Javasript). No information is available or reorded at to what user ation or RL led to the Javasript 3 W: Beaon Web Server O : Authoritative DNS Server of example.om Q / ONS-A?example.om. Q CD RI Forward CD 1gs.G...lQ & IP of LONS : end-user HTTP - http!!example om?gid LONS: loal \.: W logs & IP of DNS resolver Fig. I. DNS Beaon To disover whih lients use whih LDNS servers, we developed a novel tehnique alled DNS beaon. It works as illustrated in Figure 1. The lient generates a unique DNS beaon - a hostname with a unique GID in a domain under our ontrol (say <GID>. example. om). The lient sends the hostname to its LDNS for resolution, whih then forwards the DNS query to the authoritative name server for example. om. The authoritative server reords the hostname (thus the GID) and the LDNS IP. In addition, the lient submits the GID to a web server also under our ontrol in the same domain. The web server reords the GID and the lient IP. By joining the logs from both servers on the GID, the assoiation between lient and LDNS is revealed. The DNS beaon is implemented in Javasript inorporated in the flight experiment, and it runs for 5% of the Javasript invoations. Our DNS beaon found 112, LDNS servers, and 3.9M (Client IP address, LDNS) pairs. C. Diret Ping Measurement To establish the ground truth of lateny, we also deploy ative probing agents in eah of the data enters. For eah olleted lient IP and LDNS address, the probing agent will send 3 ative ICMP Ping requests. For those that do respond, 3 RTT measurements are obtained and the minimum value is used in later analysis. 43% of the lient IP addresses were pingable. 2616

3 GO o authoritative name server of example.om Fig. 2. Illustration of How Publi DNS Works. A Publi DNS announes the same anyast address from all its servers; a lient sends a DNS query to the anyast address; the Publi DNS server that reeives the DNS query uses a unique address when ontating the authoritative name server to omplete the query (shown in green). The proess would fa il if the server were to use the anyast address to omplete the query (shown in red). III. PBLIC DNS SYSTMS Nonnally, ISPs deploy LDNS servers to provide name resolution servie for their lients. The servie is typially exlusive, meaning the servers are inaessible to lients outside of the ISPs. Publi DNS providers, on the other hand, deploy publily aessible DNS servers to provide name resolution servie for any lients that hoose to use them. Publi DNS systems have set up by ontent providers, ISPs, or third party ompanies that build a business around the name resolution servie. The leading representatives of Publi DNS providers of eah type are Google, Level3 and OpenDNS [5], [17], respetively. From perspetive of a DNS-based GTM system, when a lient hooses to use a Publi DNS, it is represented by the orresponding Publi DNS servers. The quality of GTM, and hene the lient's pereived perfonnane, hinges on the geographi presene of the Publi DNS. In this setion, we first ondut a measurement study to unover how many LDNS servers eah of the representative Publi DNS deploys and where the LDNS servers are loated. Given the presene of eah Publi DNS, we then analyze the 1ient-LDNS assoiation data set extrated from the flight experiment and quantify the popularity of the Publi DNS systems; the extent of lient LDNS mismath; and the lateny perfonnane degradation aused by suh mismath. A. How does Publi DNS Work? We briefly explain the operation of a Publi DNS system, using Google Publi DNS as an example. As illustrated in Figure 2, Google deploys multiple DNS servers in different ities around the world. All the DNS servers announe the same anyast IP address Say a lient from Australia uses Google Publi DNS and issues a DNS query to resolve The DNS query is sent by the lient in a DP paket towards BGP and the Internet will route the paket to the anyast-1osest Google DNS server, for example, the one in Singapore. The Singapore server then forwards the DNS query to the authoritative name server of domain example. om, whih we will assume to be in S. The authoritative name server responds to the query and sends the answer to the soure address of the query. Note that the soure address annot be the anyast address Otherwise, due to any ast routing, the response will be routed to another Google DNS server in S, rather than bak to the Singapore server. Therefore, in order to orretly reeive query response, eah Google server needs a separate unique IP address. In short, all the Google servers announe the same anyast address to reeive DNS queries from lients; eah Google server uses a unique address to omplete the queries on behalf of the lients. Level3 Publi DNS and OpenDNS systems work similarly. B. novering Publi DNS Footprint Google -- Level3!! OpenDNS a tl ' (j) z -' Fig # of Vantage Points Publi DNS Servers Observed vs. Vantage Points To unover the geographi presene of the Publi DNS systems, we leverage our DNS beaon tehnique (Setion II-B). We use PlanetLab nodes as lients and onfigure them to bypass their LDNSes and issue DNS beaon queries diretly toward the anyast addresses of eah Publi DNS system. In this way, our DNS beaon server is able to observe and reord the unique IP addresses of the Publi DNS servers. By running the experiment from a large number of geographially distributed PlanetLab nodes, we an map the Publi DNS systems. Figure 3 shows that as the number of vantage points inrease, the number of disovered Publi DNS servers also inrease. However, the rate at whih new Publi LDNS servers are disovered dereases with the number of vantage points, and there are no more servers disovered beyond 18 vantage points. Table I summarizes the number of IP addresses, subnets, ities and ontinents of the Publi DNS systems. We make the following observations: 1) The urrent geographi presene of the Publi DNS systems (1-12 ities) are signifiantly smaller, ompared to that of ontent distribution networks and large ontent providers whih rely on GTM systems. For instane, Akamai deploys ahing servers in hundreds of loations worldwide [1]; Limelight has 24 regional distribution enters [14]; Google CDN and Mirosoft dge Network are both deployed in a few tens of loations [4]. ven in North Ameria, where the most Publi DNS servers are loated, none of the Publi DNS system is as widely deployed as the CDNs or the ontent providers. 2) Level3 2617

4 and OpenDNS might not be targeting their DNS servie at the lients outside of North Ameria and urope, as they do not have presene beyond these two two ontinents. On the ontrary, Google does have servers deployed in Asia and South Ameria. 3) Google DNS shows one single IP address in eah loation. The address is likely a virtual IP (VIP), whih serves multiple physial servers behind a load balaner. Level3 and OpenDNS are different, as both have more than one IP address in eah loation. OpenDNS probably deploys one physial server for every IP address, while Level3 appears to be reyling addresses within the same 124 prefix among the servers in eah loation. Google Level3 OpenDNS Anyast IP LDNS IP Prefix (/24) IO City 12 II IO Continent N. Ameria urope S. Ameria 1 Asia 2 TABL I GOGRAPHIC PRSNC OF PBLIC DNS C. How Popular are Publi DNS Systems? 1,---- u o %' ': Q..1 Google Level3 OpenDNS Others 1 L ==========J : : / 7 I _ lienl LONS dislane 1 O L--==== o Fig. 5. Client LONS Oislane (km) Client-LDNS Distane (global) IV. PROBLM OF CLiNT-LDNS MiS MAT CH DNS-based GTMs use LDNS as an approximation of its assoiated lients. The quality of the GTMs and, in tum, the performane pereived by the lients are affeted by the proximity of the lients with their LDNS. arlier studies onluded that lient-ldns mismath is a severe problem. For instane, Shaikh et al. [2] showed that the Internet paths to lients and their LDNS servers were typially disjoint and ould differ 8 hops or more. Mao et al. [15] showed that only 64% of the lients shared the same AS-luster with their LDNSes, and the ratio dropped to 16% in network-aware lustering. A key question left unanswered by those studies is how suh lient-ldns mismath translates into performane degradation when the lients aess loud servies with globally distributed data enters. In addition, over the deade sine those studies were ompleted, major trends are signifiantly re-shaping the Internet arhiteture. One of the most notable ones is that large ontent distribution networks and ontent providers are aggressively building their own bakbone infrastruture to largely bypass ISP networks and reah endusers diretly. In the following setions, we will re-visit the lient-ldns mismath problem under the urrent Internet environment. Moreover, we will answer the ultimate question how the mismath affets the auray of a GTM solution. Fig. 4. Popularity of Publi DNS A. How Far are Clients from LDNSes? One the addresses of the individual Publi LDNS servers are disovered, it is straightforward to evaluate the popularity of the Publi DNS systems. We make the assumption that the population of lients drawn by the web pages arrying our Javasript flight is suffiiently broad that whether a lient uses a Publi DNS is independent of whether they visit our pages. We an then use the 1ient-LDNS pairs olleted from the flight experiment to ompute Figure 4, whih shows the perentage of lients using Publi DNS versus those that do not. In total, about 2.5% of lients are using Publi DNS. In Internet sale, this is a quite signifiant number. Google Publi DNS is the least popular one (about half of the other two). But, onsidering the fat that it was released only 6 months ago (from the time of our experiments), the popularity is quite impressive. sing the 1ient-LDNS pairs olleted from the flight experiment, we first examine the geographi distane between the lients and their LDNSes. The Quova IP GeoLoation database is used for this purpose. 1) A Global View: Figure 5 shows the umulative distribution of the geographial distane between eah 1ient-LDNS pair. We observe that most lients are in fat not far from their LDNSes. It is lear that the 1ient-LDNS distane is within 27 km for 6% of the lients and less than 428 km for 8%. When mapped to network lateny, suh distanes orrespond to small values. This explains why almost all GTM solutions used in urrent prodution systems are DNS-based [1], [13]. On the other hand, a non-trivial perentage of lients are signifiantly distant from their LDNSes - the lient-ldns distane is more than 3,393 km for 5% of the lients. 2618

5 1 9 8.Q 7.. ;:: 6 1 is 5 > Distan e between Clients and the Center of urope (km) Fig. 6. DlstnbutIon of distane between uropean lients and the geographi enter of urope..q.. ;:: 1 is > Fig Google -- Level3 -- OpenDNS -- Others Client-LDNS Distane (km) Client-LDNS Distane (N. Ameria) Fig e: 8 7 :g. 6 is 5. 4 iii Clienl-LDNS Dislane (km) Distane between uropean lients and their LDNS servers :s. 6 5 is. 4 iii Fig Client-LDNS Distane (km) Client-LDNS Distane (S. Ameria) Figure 5 shows the results for all the lient-ldns pairs. Next, we separate out the lients not using Publi DNS and ompare them to those that do. Also, as the Publi DNS systems do not have presene on every ontinent, the omparison is more meaningful and informative if the results are broken down by ontinent. 2) Breakdown View - urope: We first analyze the lients loated in urope. One might wonder whether there is inherent bias due to the lient population itself. For instane, a lient swithes from its ISP-assigned LDNS to Publi DNS only when the ISP-assigned LDNS is far away (and thus ausing poor performane). As a simple sanity hek, we take the geographi enter of urope as a referene point and alulate the distane from eah lient to the enter. Figure 6 plots the umulative distribution of distane for eah DNS system. From the distributions, there appears to be no bias among the lient population - use of Google, Level3, or OpenDNS is independent of loation. Comparing Figure 7 with Figure 5, we observe the lient LDNS distane is muh smaller in urope than over the entire world. In addition, we observe that the differene between ISP-assigned LDNS and Publi DNS is remarkable. At the 8-perentile, the 1ient-LDNS distane is 253 km, while the lient-publi DNS distane is 1,464 km, 1,228 km and 1,358 km for Google, Level3 and OpenDNS, respetively. Interestingly, despite being deployed in more loations (4 vs. 2), the Google Publi DNS appears to be further away from the lients than Level3 and OpenDNS. 3) Breakdown View - North Ameria: Next, we examine the lients loated in North Ameria. Figure 8 shows that, ompared to urope, the lient-ldns distane is signifiantly larger on this ontinent. At the 8-perentile, the distane is 616 km for the lients using ISP-assigned LDNS, while it is 2,26 km, 2,59 km, 1,54 km for those using Google, Level3 and OpenDNS, respetively. The fat that Google Publi DNS is deployed in fewer loations in North Ameria (5 vs. 9 and 8, respetively) likely auses those lients using Google to be be even further away from their DNS servers than those using Level3 and OpenDNS. 4) Breakdown View - South Ameria: South Ameria is interesting to examine as it is one of the ontinents where Google Publi DNS has presene, while Level3 and OpenDNS do not. Figure 9 shows that the lients using Google are far loser to their LDNSes than those using Level3 and OpenDNS. To further examine the benefit of having presene on the ontinent, Figure 1 plots, for all the lients in South Ameria ' the perentage of their LDNSes on different ontinents. We observe that, for those South Amerian lients using Fig ; 7..;:: 6 t;; V> z google.level3.opendns others afria asia europe north oeania south ameria ameria Perentage of LDNSes on eah ontinent (S. Amerian lients). 2619

6 3-25 e u it: 2 '15 OJ b.o ' 1: 1.. Q; 5 r- - r- r- - r- f- - f- r- - r- - I British Teleom ' 6 g:, ' 4 u Q;.. 2 o At&T I nternet Servies Index of LDNS (by /24 prefix) Index of LDNS (by /24 prefix) Fig. II. LDNS used by British Teleom lients Fig. 12. LDNS used by AT&T lients British Tel AT&T Inet Total Clients Total LDNS Total Sub nets (/24) TABL II LDNS SD BY CLINTS FROM NATIONAL ISPs Leve13 and OpenDNS, their assoiated DNS servers are mostly in North Ameria. This is understantable, as Leve13 and OpenDNS do not have presene in South Ameria. On the other hand, more than 56% of the lients using Google are assoiated with DNS servers on the same ontinent. Clearly, these lients are muh loser to their DNS servers. For the rest (about 44%) lients, they are still assoiate with DNS servers in North Ameria. The fat, that anyast routes the DNS queries from those lients to North Ameria, suggests that the peering relationship between Google and South Ameria ISPs has a lot of room to improve. Again, we observe that ISP-assigned LDNS servers are muh loser and more than 97% loate on the same ontinent as the lients. B. ISP-assigned LDNS vs. Publi DNS The evidene so far has learly shown that the lient-ldns distane is smaller when the lients use LDNS provided by their ISPs, rather than by the Publi DNS systems. This is intuitive for regional ISPs. However, for national ISPs, the lient-ldns distane depends on how many LDNS servers and where they are deployed by eah ISP. Knowing the assoiation of LDNS to ISP allows us to ompare the footprint of ISP-assigned LDNS against that of Publi DNS. This is important to GTM, as the smaller footprint will be the dominating fator in determining GTM performane. So far, we have been using the term ISP-assigned LDNS loosely. In fat, all LDNSes are not assigned by ISPs. For example, an organization an run its own DNS server and the lients in the organization an use the server as their LDNS. Obviously, this LDNS is no longer assigned by the lient's ISP. Here, we are interested in disovering the LDNSes that are truly deployed by the ISPs. Therefore, a straightforward approah, whih simply ounts all the LDNS servers belonging to the ISPs' netbloks, does not work. As illustrated in Table II, we examine British Teleom and AT&T Internet Servies, two top ISPs from urope and North Ameria. There are hundreds British Tel. AT&T Inet. LDNS IP Prefix 4 17 # of Cities 3 17 TABL III LDNS TRLY DPLOYD BY ISPs of LDNS servers used by the lients from the two ISPs. ven ounting subnets, the quantity is still very large. It is unlikely that all the hundreds of DNS servers are deployed by the two ISPs. To distinguish truly ISP-assigned LDNS, we remark that LDNSes operated by organizations are like to serve only a small number of lients and remain unpopular. On the ontrary, LDNS servers deployed by ISPs will serve many more lients. To validate this intuition, we group the LDNS servers by 124 prefix and rank the groups by their popularity. As shown in Figures 11 and 12, there is a lear separation between popular and unpopular LDNS subnets. Hene, this method allows us to determine that British Teleom deploys LDNSes in 4 subnets while AT&T Internet Servies in 17 subnets. sing the GeoLoation database, we disover that BT's LDNS servers are in 3 ities and AT&T's are in 17 ities (Table III). Compared to the Publi DNS systems, the geographi presene of major ISPs are muh bigger. This explains why the lients are loser to their ISP-assigned LDNSes than to the Publi DNS systems. V. LATN CY PR F ORMANC In this setion, we investigate how lient-ldns mismath affets lient pereived lateny performane. A. LDNS as an Approximation Reall that for every lient and LDNS address olleted through the flight experiment, the diret probing agent running in eah data enter sent Ping probes to it. For those responded to Ping, the minimum value of three RTT measurements is taken as the ground truth lateny. The data enter with the shortest lateny an then be determined for eah lient (alled lient-best), and the lateny between the lient and the lientbest data enter is the best lateny performane the lient an ahieve. Sine DNS-based GTMs use the lient's LDNS to make the deision, they will hoose the data enter with 262

7 1 8 :.2. 6 Q).2: ro Best by Ctient -- Best by LDNS Fig. 13. Client Lateny to Best DC (ms) LDNS as an Approximation the shortest lateny to the LDNS (alled LDNS-best). The lateny between the lient the LDNS-best data enter is what is ahieved by GTMs. The lateny degradation is the gap between the lient-best and LDNS-best distributions, as shown in Figure 13. We an make the following observations: 1) the two distributions are fairly lose, whih means that for a large perentage of lients, the differene between between lientbest and LDNS-best is quite small. This again onfirms that LDNS is a reasonable approximation of lient; 2) at high perentile, however, the distane between the two distributions is non-negligible. For instane, at the 95 perentile, the lientbest lateny is 157 ms, while the LDNS-best lateny is 197 ms. One amplified through appliations, 4 ms differene per round trip does indeed degrade lient pereived performane. B. Impat of Publi DNS Systems - an Overview N: Planet Lab Node Date Center R: Refletor C: Colletor (ONS Server) (ONS Server) Fig. 14. L: Level3 DNS Server Determine LDNS-best for Leve13 For the lients using Publi DNS, to find their orresponding LDNS-best data enters, we need to know lateny from eah data enter to all the Publi DNS servers. The DNS servers of Google and OpenDNS respond to Ping, so it is straightforward to obtain lateny. Level3 DNS servers, however, do not respond to Ping and we need another way to measure lateny. To this end, we leverage a previously developed tehnique - DNS refletion - to obtain suh measurement. On a high level, a DNS query of a speial hostname is sent to a Level3 DNS server. The hostname belongs to a domain whose authoritative name server loates in a target data enter. The authoritative name server responds to the DNS query in suh a way that the Level3 DNS server is triggered to immediately send another DNS query to a seondary DNS server in the same data enter. As illustrated in Figure 14, by examining the time differene between reeiving the first and the seond DNS query at the data enter, the lateny between the data enter and the Level3 DNS server an be readily determined. For details, please refer to [9]. 1 ;;R 8 : u; Q) > ' Lateny Differene (Best by LDNS Best by Client) (ms) Fig. 15. Impat of PubDNS Now, we an determine the LDNS-best data enters for the lients using Google, Leve13 and OpenDNS. Figure 15 shows the breakdown distributions of the lateny differene between the lient-best and the LDNS-best data enter. We observe that the lateny differene is very small for a large perentage of the lients. For instane, at the 9 perentile, the differene is 31 ms for the lients using ISP-assigned LDNS, ompared to 81 ms using Google, 58 ms using Level3 and 78 ms using OpenDNS. However, at the 95 perentile, the differene quikly inreases to 84 ms for the lients using ISP-assigned LDNS, ompared to 193 ms using Google, 129 ms using Level3 and 156 ms using OpenDNS. Hene, the performane degradation due to Publi DNS is substantial for a non-trivial perentage of the lients. C. Impat of Publi DNS - a Detailed Comparison While the lateny differene omparison in the previous setion is informative, it is not an apple-to-apple omparison, as the lient populations are not exatly the same aross all the distributions. A more fair omparison is to analyze the lateny performane for exatly the same lients. To this end, we group the lients by their 124 prefix. For a large number of prefixes, we observe that there are a few lients using the Publi DNS systems, while most others use ISP-assigned LDNS. For the lients using Publi DNS, we reord their assoiated DNS servers. We assume these DNS servers will be used by the other lients in the same prefix, if they were to swith from ISP-assigned LDNS to Publi DNS. Beause suh grouping resulted in differene prefixes for different Publi DNS, we present the omparison separately for eah Publi DNS, as shown in Figure 16. sing Google as an example (Level3 and OpenDNS are similar), Figure 16(a) shows the distributions of lateny differene between lient-best and DNS-best, when the lients 2621

8 = C 1.. ; is 4 > > 2 - LDNSBest - Googte Best Lateny Differene (Best DC by DNS - Best by Client) (ms) (a) Google C ; is LDNSBest - Levet3 Best Lateny Differene (Best DC by DNS - Best by Client) (rns) ( b ) Level3 Fig. 16. Impat of PubDNS (breakdown) :====7=l O L_ == 15 - LDNSBest - OpenDNS Best 2 25 Lateny Differene (Best DC by DNS - Best by Client) (ms) () OpenDNS use ISP-assigned LDNS or Publi DNS, respetively. The differene between lient-best and DNS-best is the performane degradation aused by lient-ldns mismath. If a GTM solution were able to determine the lient-best data enter for a lient, then it an eliminate suh performane degradati on. It appears that Google, as an loud servie provider, exatly ahieves this goal by offering its own Publi DNS servie. When lients swithing from ISP-assigned LDNS to Google Publi DNS, their performane aessing Google servies will improve, as Google's GTM an now observe the lients' IP and selet data enters that are lient-best, rather than DNSbest. However, when the lients aess any other loud servies, their performane will inevitably degrade. The best data enter determined by the GTMs of those servies, an only be DNS-best with respet to Google DNS servers. Beause the Google DNS servers are further away from the lients than ISP-assigned LDNS, the performane pereived by the lients will be worse than before swithing to the Publi DNS system. 2 VI. GRANLARITY OF CLIN T IP BASD MAPS Partly in response to ritiism that publi DNS systems redue the performane of lients that use them, at least when the lients aess servies other than those operated by the publi DNS provider, the ITF is onsidering a proposal [2] to hange LDNS servers to pass to the authoritative some information about the lient IP address along with the FQDN to be resolved, an idea also explored by Shaikh et al. [2] bak in 2 I. This, in tum, raises the question of how many bits of the lient IP address should be forwarded. That is, if lient IP addresses will be grouped by subnet, what netmask length should be used? The urrent proposal suggests passing on the top 24-bits (i.e., the 124 subnet), but either more or fewer are possible. Sine the LDNS will ahe answers from the authoritative name server for eah subnet, as netmask length inreases there will be more subnets, more ahe misses, and the LDNS will make more requests to the authoritative name server. Owners of authoritative name servers have raised the onern their servers might not be able to handle this additional load. On the other hand, if the netmask is too short, the GTM solution 2f ourse, the performane will be even more sub-optimal than from a I ient -best data enter ;; Q J!l 11 ' 15 ; Netmask Length Fig. 17. Width, as measured by IQD, of the response time distributions falls as netmask length inreases. Diminishing returns set in at a 24-bit sub net. will suffer and again users will see worse latenies than they should. A. valuation Metri One approah would be to luster users into the maximally sized subnets that all have the same best data enter, and have the authoritative name server return the netmask length of this subnet along with the IP address in response to a resolution request. Here, we start with the approah of finding the best subnet size aross all users, and the impat of using larger or smaller subnets. We take the response time data from the Javasript flight and group it into subnets of with netmask length k by the lient IP address. For eah lient subnet, we then ompute the response time distribution to eah data enter. We then ompute the width of eah distribution using inter-quartile distane (IQD) of the distribution (i.e., the 75th perentile minus the 25th perentile). This produes for eah netmask length k a distribution of IQDs - the intuition behind the methodology is that as lients that are topographially dispersed are grouped together in the same subnet, the width of the response time distribution to eah data enter will inrease. B. Impat of Netmask Length Figure 17 shows the median of the distribution of interquartile distanes as the netmask length used by LDNS servers inreases from 16-bits to 28-bits. As expeted, the widths of the response time distributions fall as the netmask gets longer, 2622

9 sine lients with IP addresses loser together are more likely to be topologially loser to eah other and hene have similar response times to eah data enter. Diminishing returns appear to set in at 24-bits, so the quality of the GTM solution will not be improved if LDNS servers pass on more than 24-bits of the lient IP address to the authoritative name servers. If load on the name servers is an issue, the load ould be ut by 16x by dereasing the netmask length from 24 to 2 bits, at a ost of inreasing the median width of the response time distributions by 15 ms. VII. RLATD WORK This paper updates the work of Shaikh et al. in 21 [2] and Mao et al. in 22 [15] to measure the proxmity of web lients and LDNS servers. In those earlier studies, proximity is quantified using an extensive set of metris, inluding AS, network-aware luster, Internet path hop ount, et. However, there was one important question left unanswered, that is, how the proximity ultimately affets lient pereived performane when servie is delivered from many geographially distribued data enters. In this paper, we not only examine new issues that did not exist at that time, suh as the effet of publi DNS systems on the lient-ldns relationship, but also answer the ultimate question how lient-ldns mismath impats global traffi management and affets lient response time distribution. We also look at additional issues, suh as the granularity of lient IP subnets, and we introdue new tehniques for assoiating lients with their LDNS and disovering LDNS deployed by national ISPs. Many alternative systems for Global Traffi Management have been proposed, inluding light-weight probing, anyast, ombinations of anyast with probing, and entirely new, non DNS based systems that use new ode running on the lients to resolve a servie name to an IP address [1], [3], [7]. DNS-based GTM remains extremely popular among major servie providers, so our work fouses on DNS-based systems. Note although DNS-based GTMs are subjet to lient-ldns mismath, they an be enhaned through RL-rewriting [12], whih is a late-binding proess beyond the DNS resolution stage. Suh tehnique redirets subsequent lient requests to desirable data enter hoies, even if the initial one based on LDNS is not optimal. A signifiant body of prior work looks at mapping the loation of lients using geographi or virtual oordinate systems, often using probing or data mining of user provided information to reate the maps (a few of the early efforts among these many papers are [16], [18]). Our work differs in that we work diretly with measurements of lateny distribution, without onverting to an intermediate oordinate system, and we evaluate the impliations for DNS-based GTM systems. The DNS refletion tehnique used to measure the lateny between Leve13 DNS servers and the data enters bears similarity to the widely adopted King tehnique [6]. The gist of both approahes is to use modified DNS query and response traffi to measure Internet lateny. VIII. SMMARY In summary, through a large-sale measurement study, we observe that using ISPs' LDNS servers to approximate the loation of the lients behind them results in a reasonable data enter seletion for a large number of lients. When a lient bypasses its ISP's LDNS and uses a publi DNS system, GTM systems are more likely to rediret the lient to a sub-optimal data enter. This effet has been reported anedotally in blogs [19], and we have onfirmed it quantitatively. sing our measurement study, we also evaluate reent proposals on altering how DNS systems work and what information loal DNS resolvers should make available to drive the GTM systems. We hope the results will shed light on the debate over how GTM systems should be designed. ACKN OWLDGMN T We thank Nik Holt, Zee Xu, Gregory Vandenbrouk, ri Shurman, Allen Callaway and Jean-Franois Peyroux at Mirosoft Corporation for their help with our experiments. RFRN CS [1] R. 1. Carter and M.. Crovella. Server Seletion using Dynami Path Charaterization in Wide-Area Networks. In INFOCOM, [2] C. Contavalli, W. van der Gaast, S. Leah, and D. Rodden. Client ip information in DNS requests. IT F Internet Draft draft-vandergaastedns-lient-ip-oo.txt, Jan 21. [3] M. J. Freedman, K. Lakshminarayanan, and D. Mazieres. Oasis: Anyast for any servie. In NSDI, 26. [4] Google Data Center FAQ. 7 Igoogle-data -enter -faq/. [5] Google Publi DNS. [6] K. P. Gummadi, S. Saroiu and S. D. Gribble. King: stimating Lateny between Arbitrary Internet nd Hosts. In IMW, 22. [7] J. Guyton and M. Shwartz. Loating nearby opies of repliated Internet servers. In SIGCOMM, [8] J. Hamilton. The ost of lateny. 29/1/31/TheCostOfLateny.aspx, Otober 29. [9] C. Huang, N. Holt, Y. A. Wang, A. Greenberg, J. Li, and K. W. Ross. A DNS Refletion Method fo r Global Traffi Management. In SNIX ATC,21. [1] C. Huang, Y. A. Wang, J. Li, and K. W. Ross. Measuring and valuating Large-Sale CDNs. In Mirosoft Researh Tehnial Report, 28. [II] R. Kohavi et al. Pratial Guide to Controlled xperiments on the Web: Listen to Your Customers not to the HiPPO. KDD, 27. [12] B. Krishnamurthy, C. Wills, and Y. Zhang. On the se and Performane of Content Distribution Networks. In IMW, 21. [13] R. Krishnan, H. V. Madhyastha, S. Srinivasan, S. Jain, A. Krishnamurthy, T. Anderson, and J. Gao. Moving Beyond nd-to-nd Path Information to Optimize CDN Performane. In IMC, 29. [14] Limelight Global Network. [15] Z. M. Mao, C. Cranor, F. Douglis, M. Rabinovih, O. Spatshek, and J. Wang. A preise and effiient evaluation of the proximity between web lients and their loal dns servers. In SNIX, June 22. [16] T. S.. Ng and H. Zhang. Prediting internet network distane with oordinates-based approahes. In INFOCOM, 22. [17] OpenDNS. [18] V. N. Padmanabhan and 1. Subramanian. An investigation of geographi mapping tehniques for internet hosts. In SIGCOMM, 21. [19] D. Rayburn. Google's New DNS Servie Has One Major Flaw, Poor Performane. [2] A. Shaikh, R. Tewari, and M. Agrawal. On the ffetiveness of DNSbased Server Seletion. In INFOCOM, 21. [21] S. Souder. High performane web sites: 14 rules for faster loading pages. - Statisti attributed to Greg Linden., June