dress of a DNS query reflects the browser's network lo- old, it returns nameservers for L1. LO.nyucd. net. For cation. This assumption holds to varying degrees, but is clients closer than the level-2 threshold, it returns name- good enough that Akamai [12], Digital Island [6], and servers for domain L2 L1 L0 nyucd. net. Because Mirror Image [21] have all successfully deployed com- DNS resolvers query the servers for the most specific mercial CDNS based on DNS redirection. The locality known domain, this scheme allows closer dnssrv instances problem therefore is reduced to returning proxies that are to override the results of more distant ones near the source of a DNS request. In order to achieve lo- Unfortunately, although resolvers can tolerate a frac- cality, dnssrv measures its round-trip-time to the resolver tion of unavailable DNS servers, browsers do not han- and categorizes it by level For a 3-level hierarchy the re- dle bad Http servers gracefully. (this is one reason for solver will correspond to a level 2, level 1, or level 0 client, returning CoralProxy addresses with short TTL fields. pending on how its RTT compares to Corals cluster- As an added precaution, dnssrv only returns CoralProxy level thresholds addresses which it has recently verified first-hand. This When asked for the address of a hostname ending sometimes means synchronously checking a proxy's sta httpL2.ll.l0.nyUcd.netdnssr'sreplycontus(viaaUdpRpc)priorreplyingtoadnsqueryWe tains two sections of interest: A set of addresses for the note further that people who wish to contribute only up- name--answers to the query-and a set of nameservers stream bandwidth can flag their proxy as"non-recursive for that name's domain-known as the authority section in which case dnssrv will only return that proxy to clients of a DNS reply. dnssrv returns addresses of CoralProx- on local networks ies in the cluster whose level corresponds to the client level categorization In other words if the Rtt between 3.2 The Coral Http proxy the dns client and dnssry is below the level-i threshold (for the best i), dnssrv will only return addresses of Coral The Coral Http proxy Coralproxy, satisfies Http re- nodes in its level-i cluster dnssry obtains a list of such quests for Coralized URLS. It seeks to provide reasonable nodes with the nodes function. Note that dns srv always re- request latency and high system throughput, even while turns CoralProxy addresses with short time-to-live fields serving data from origin servers behind comparatively slow network links such as home broadband connections To achieve better locality, dnssrv also specifies the This design space requires particular care in minimiz- clients IP address as a target argument to nodes. This ing load on origin servers compared to traditional cdNs, causes Coral to probe the addresses of the last five net- for two reasons. First, many of Coral's origin servers work hops to the client and use the results to look for are likely to have slower network connections than typ- clustering hints in the DSHTs. To avoid significantly de- ical customers of commercial CDNS. Second,commer- laying clients, Coral maps these network hops using a fast, cial CDNs often collocate a number of machines at each built-in traceroute-like mechanism that combines concur- deployment site and then select proxies based in part on rent probes and aggressive time-outs to minimize latency. the URL requested-eftectively distributing URLs across The entire mapping process generally requires around 2 proxies. Coral, in contrast, selects proxies only based on RTTs and 350 bytes of bandwidth. A Coral node caches client locality. Thus, in CoralCDN, it is much easier for results to avoid repeatedly probing the same client. every single proxy to end up fetching a particular URL The closer dnssryv is to a client the better its selection of To aggressively minimize load on origin servers, CoralProxy addresses will likely be for the client. dnssrv CoralProxy must fetch web pages from other proxies therefore exploits the authority section of DNS replies to whenever possible. Each proxy keeps a local cache from lock a DNS client into a good cluster whenever it happens which it can immediately fulfill requests. When a client upon a nearby dnssrv. As with the answer section, dnssrv requests a non-resident URL, CoralProxy first attempts selects the nameservers it returns from the appropriate to locate a cached copy of the referenced resource using cluster level and uses the target argument to exploit mea- Coral (a get ), with the resource indexed by a SHA-I hash surement and network hints. Unlike addresses in the an- of its URL [22]. If CoralProxy discovers that one or more section, however, it gives nameservers in the author- other proxies have the data, it attempts to fetch the data section a long TTL(one hour). a nearby dnssrv must from the proxy to which it first connects. If Coral provides therefore override any inferior nameservers a dNS client no referrals or if no referrals return the data, CoralProxy may be caching from previous queries. dnssrv does so by must fetch the resource directly from the origin manipulating the domain for which returned nameservers While CoralProxy is fetching a web object-either servers. To clients more distant than the level-1 timing from the origin or from another CoralProxy-it inserts a reshold, dnssrv claims to return nameservers for domain reference to itself in its DSHTs with a time-to-live of 20 LO. nyucd. net. For clients closer than that thresh- seconds. (It will renew this short-lived reference until it completes the download. )Thus, if a flash crowd suddenlydress of a DNS query reflects the browser’s network lo￾cation. This assumption holds to varying degrees, but is good enough that Akamai [12], Digital Island [6], and Mirror Image [21] have all successfully deployed com￾mercial CDNs based on DNS redirection. The locality problem therefore is reduced to returning proxies that are near the source of a DNS request. In order to achieve lo￾cality, dnssrv measures its round-trip-time to the resolver and categorizes it by level. For a 3-level hierarchy, the re￾solver will correspond to a level 2, level 1, or level 0 client, depending on how its RTT compares to Coral’s cluster￾level thresholds. When asked for the address of a hostname ending http.L2.L1.L0.nyucd.net, dnssrv’s reply con￾tains two sections of interest: A set of addresses for the name—answers to the query—and a set of nameservers for that name’s domain—known as the authority section of a DNS reply. dnssrv returns addresses of CoralProx￾ies in the cluster whose level corresponds to the client’s level categorization. In other words, if the RTT between the DNS client and dnssrv is below the level-i threshold (for the best i), dnssrv will only return addresses of Coral nodes in its level-i cluster. dnssrv obtains a list of such nodes with the nodesfunction. Note that dnssrv alwaysre￾turns CoralProxy addresses with short time-to-live fields (30 seconds for levels 0 and 1, 60 for level 2). To achieve better locality, dnssrv also specifies the client’s IP address as a target argument to nodes. This causes Coral to probe the addresses of the last five net￾work hops to the client and use the results to look for clustering hints in the DSHTs. To avoid significantly de￾laying clients, Coral mapsthese network hops using a fast, built-in traceroute-like mechanism that combines concur￾rent probes and aggressive time-outs to minimize latency. The entire mapping process generally requires around 2 RTTs and 350 bytes of bandwidth. A Coral node caches results to avoid repeatedly probing the same client. The closer dnssrv is to a client, the better its selection of CoralProxy addresses will likely be for the client. dnssrv therefore exploits the authority section of DNS replies to lock a DNS client into a good cluster whenever it happens upon a nearby dnssrv. As with the answer section, dnssrv selects the nameservers it returns from the appropriate cluster level and uses the target argument to exploit mea￾surement and network hints. Unlike addresses in the an￾swer section, however, it gives nameservers in the author￾ity section a long TTL (one hour). A nearby dnssrv must therefore override any inferior nameservers a DNS client may be caching from previous queries. dnssrv does so by manipulating the domain for which returned nameservers are servers. To clients more distant than the level-1 timing threshold, dnssrv claims to return nameserversfor domain L0.nyucd.net. For clients closer than that thresh￾old, it returns nameserversfor L1.L0.nyucd.net. For clients closer than the level-2 threshold, it returns name￾servers for domain L2.L1.L0.nyucd.net. Because DNS resolvers query the servers for the most specific known domain, this scheme allows closer dnssrv instances to override the results of more distant ones. Unfortunately, although resolvers can tolerate a frac￾tion of unavailable DNS servers, browsers do not han￾dle bad HTTP servers gracefully. (This is one reason for returning CoralProxy addresses with short TTL fields.) As an added precaution, dnssrv only returns CoralProxy addresses which it has recently verified first-hand. This sometimes means synchronously checking a proxy’s sta￾tus (via a UDP RPC) prior replying to a DNS query. We note further that people who wish to contribute only up￾stream bandwidth can flag their proxy as “non-recursive,” in which case dnssrv will only return that proxy to clients on local networks. 3.2 The Coral HTTP proxy The Coral HTTP proxy, CoralProxy, satisfies HTTP re￾quests for Coralized URLs. It seeks to provide reasonable request latency and high system throughput, even while serving data from origin servers behind comparatively slow network links such as home broadband connections. This design space requires particular care in minimiz￾ing load on origin servers compared to traditional CDNs, for two reasons. First, many of Coral’s origin servers are likely to have slower network connections than typ￾ical customers of commercial CDNs. Second, commer￾cial CDNs often collocate a number of machines at each deployment site and then select proxies based in part on the URL requested—effectively distributing URLs across proxies. Coral, in contrast, selects proxies only based on client locality. Thus, in CoralCDN, it is much easier for every single proxy to end up fetching a particular URL. To aggressively minimize load on origin servers, a CoralProxy must fetch web pages from other proxies whenever possible. Each proxy keeps a local cache from which it can immediately fulfill requests. When a client requests a non-resident URL, CoralProxy first attempts to locate a cached copy of the referenced resource using Coral (a get), with the resource indexed by a SHA-1 hash of its URL [22]. If CoralProxy discovers that one or more other proxies have the data, it attempts to fetch the data from the proxy to which it first connects. If Coral provides no referrals or if no referrals return the data, CoralProxy must fetch the resource directly from the origin. While CoralProxy is fetching a web object—either from the origin or from another CoralProxy—it inserts a reference to itself in its DSHTs with a time-to-live of 20 seconds. (It will renew this short-lived reference until it completes the download.) Thus, if a flash crowd suddenly 4