Content Distribution Architecture using Network Layer ... - CiteSeerX

Content Distribution Architecture using Network Layer Anycast Gaurav Agarwal, Rahul Shah and Jean Walrand Department of Electrical Engineering and Computer Sciences University of California, Berkeley {gaurav,rcshah,wlr}@eecs.berkeley.edu Abstract Server replication is a common technique for distributing content efficiently and in a scalable manner to many clients. Directing clients to the “best” of these content-equivalent servers is a non-trivial problem. As a solution, we propose a Content Distribution Architecture using Anycast (CDAA) that uses replicated servers and leverages the idea of anycast, supported at the network layer, to direct clients. CDAA assigns the same anycast address to content-equivalent servers and tracks the load on each of them. This information is used to direct clients in the network to the “best” server, improving user satisfaction by reducing the response time seen by the clients. CDAA is scalable, incrementally deployable and transparent to existing network applications and protocols. These objectives are achieved with minimal bandwidth overhead and computing requirements. Though DNS and client software require some modifications, routers and servers remain unchanged. We also present simulation results that demonstrate the efficacy of our architecture.

1. Introduction The rapid growth in demand for content in the Internet requires efficient and scalable content distribution solutions. Architectures for these have evolved from single server schemes to multiple servers placed at geographically distributed locations. The key idea behind this evolution is to bring the servers closer to clients. This results in improved performance seen by the clients, reduced network load and better fault tolerance. Some solutions that have been considered include caching [1,2,3], replication [4,5,6] and multicasting [7,8]. In this paper, we propose an architecture using network layer redirection. This leverages the idea of anycast [10] to determine a lightly loaded local server. We also propose a protocol for anycast routing at the

network layer. Anycast is a mode of communication wherein the same anycast address is assigned to more than one interface (typically, nodes with different IP addresses) and a packet sent to this address is routed to the “nearest” interface, where “nearest” is defined by the routing protocol. The measure of “nearest” could be the number of hops, the load of the server, the roundtrip time (RTT) to this server, the available bandwidth for the connection or any other measure which gives “best” possible service. The proposed architecture, Content Distribution Architecture using Anycast (CDAA) supported at the network layer, uses the total response time (TRT) seen by a client, measured from the time the IP request is sent to the time the complete response is received, as a metric for “nearest”. The justification for using TRT is that it is central to the user’s perception of QoS. Also, it captures both the server load and the network path characteristics. CDAA requires replicated servers that are placed at geographically different locations. These servers have different IP addresses but the same anycast address. CDAA also necessitates the introduction of new network components at edges of the network, called Smart Boxes (SB), which have modest processing and memory requirements, easily met by the Personal Computers of today. All anycast requests are directed to the local SB which uses past statistics to estimate the total response time for various servers for that anycast address. The SB chooses a server and redirects the client to it. When the session ends, the client sends a packet to the SB containing the connection statistics, which is used to redirect subsequent requests. CDAA is a scalable, incrementally deployable and low overhead architecture that reduces the response time seen by the clients while balancing the load among the servers. These objectives are achieved with minimal bandwidth overhead and computing requirements. It is also compatible with the existing network applications and protocols, requires absolutely no changes at the routers and servers, and only minor modifications to the DNS and client software.

Clients Server Router Server Smart Box

Network

Router Server

Figure 1. CDAA Architecture

The paper is divided into eight sections. Section 2 gives an overview of the CDAA architecture. Section 3 and 4 detail the client side and SB operation of CDAA respectively. Section 5 presents a justification for the server-choice function. Simulation methodology and results are described in Section 6. We present a comparison with related works like SPAND [9] and ALAS [11,12] in Section 7, finally concluding in Section 8.

2. CDAA Architecture The CDAA architecture is illustrated in Figure 1. It consists of replicated servers and Smart Boxes (SB) in the network. The SBs are placed at the edge of the network, typically serving a few routers. The clients direct anycast requests to the router, just like ordinary IP requests. The router forwards these requests transparently to the local SB. Based on information in its database, the SB calculates the response time for different servers that have the same anycast address. It then redirects the client to the IP address of the chosen server, where the probability of a server being chosen is inversely proportional to its response time. All further communication between the server and the client is carried on using this IP address in the normal unicast mode of communication. At the end of the transfer, the client sends a packet to the SB containing the statistics of the connection, which the SB uses to update its records. CDAA has a strong notion of locality with the premise that only locally gathered information is useful for redirection. Thus, SBs do not exchange information among themselves. Also, this explains our decision to keep SBs closer to the clients rather than within the core routers. This ensures that the SB will redirect the client to a server that is performing well as seen from

that locality. Moreover, the clients set a small value for the time -to-live field in the anycast request packet, preventing distant SBs from receiving it. Thus, the clients that see a particular router as their default will also have the associated SB as the default. This SB will be responsible for all requests sent by these clients. By this choice, we expect that the number of clients associated with each SB would be such that the SB will have accurate and up-to-date information about most servers. Since anycast addresses are part of the IP address space 1 , the SB advertises itself as the next hop for the anycast address space. The router simply forwards all client anycast requests to it without requiring any knowledge of anycast, removing the need for any changes in the router. The DNS servers, on the other hand, need some modifications. They should introduce a new class called “anycast” in the Type field of the DNS resource records [14]. Resource records would store both the anycast and IP addresses for a domain name with the Type fields set to “anycast” or “IP address” respectively. Anycast-enabled clients will request an anycast address and an IP address in their query. If the DNS is anycast aware, it will send the anycast address (if it exists) and an IP address to the client. If the DNS does not have the anycast address or if it is not anycast aware, it simply sends an “error” for the anycast request, but still returns the IP address. In either situation, the client gets at least the IP address of the server that it can use for the connection. This ensures that CDAA is incrementally deployable. 1

In IPv6, anycast is an accepted addressing mechanism, with provisions for it in the addressing space [13]. Even in IPv4, a block of addresses from the addressing space of either unicast or multicast can be reserved [10], though unicast space is preferred.

CDAA also requires certain modifications to the clients to make them anycast-enabled that will be detailed in the next section. The servers, on the other hand, need not be anycast aware. Even though a clientbased approach is more difficult to implement than a server-based2 approach, it has several advantages. Firstly, a client-based approach results in smaller response times as the request does not have to travel through the network to a server before being redirected. Secondly, this approach is robust to network-partitions and single-point failure dependency. As long as any content bearing server is in the user’s partition, it can be accessed. Lastly, a client-based approach can make better use of the locally gathered information as opposed to the server.

3. CDAA – Client-side Operation This section gives a step-by-step description of the client-side operations of CDAA and also lists the changes required in the client software.

3.1. Protocol 1.

The client sends a domain name resolution query to the DNS. If the DNS is anycast enabled and the requested name has an anycast address, it returns the anycast address as well as an IP address. Assuming the client is anycast-enabled, it sends a request using the anycast address towards its default router. The IP address returned by the DNS is also sent in the request. Since the SB is the next hop for all anycast addresses, the router forwards this request to the local SB. The time-to-live field of this request has a small value, so that a distant SB does not receive it. The SB receives the anycast request and does a table lookup to find the associated IP addresses. Then the SB finds the “best” IP address for this request (the procedure for doing this is discussed in the next section), and returns this IP address to the client. All further communication between the server and the client is carried on using this IP address in the normal unicast mode of communication. When the communication ends, the client prepares a stat-packet and sends it to the SB which contains: a. Smoothed round trip time (SRTT) [15] b. Total response time (TRT) c. Data received in bytes (S)

2.

3.

4.

5.

6.

2

Akamai is an example for a server-based approach.

In case the client is not anycast-enabled, it will use the IP address sent by the DNS. Similarly, if no SB exists in the client’s vicinity, or the SB has failed, the client times out after a while and then uses the IP address. If the SB does not have the requested anycast address in its database, it sends a failure message to the client who then uses the IP address. The client still sends a statpacket to the SB, hence initiating an entry for this anycast address in the database. If the connection between the server and the client breaks down prematurely, the client will not send a stat-packet to the SB.

3.2. Anycast-Enabling a Client The changes required for anycast-enabling a client can be listed as follows: 1. Request for an anycast address by setting the QType field to “anycast” in the DNS query and also request an IP address in the same query. 2. Use the anycast address (if present) for the connection. 3. Calculate the total response time (TRT), measured from the time the IP request is sent to the time the complete response is received. 4. Measure the size of the data received (S) in bytes. 5. Measure the smoothed round trip time (SRTT) for the connection. 6. Finally, send a stat-packet to the SB (if the SB is alive), regardless of whether the SB was able to provide the “best” IP address or not.

4. CDAA – Smart Box Operation SBs are entrusted with the task of maintaining a database of the servers in the form of a table. When requested for an anycast-to-IP resolution, SBs do a table lookup and redirect the client to the “best” server. On receiving a stat-packet, the SBs update the entry corresponding to that anycast and IP address in their table. Hence, they can be referred to as the “brains” of CDAA. Although we have considered SBs to be independent network components, they can easily be incorporated in the routers. All SBs are part of a multicast group. This multicast group address is used by the SBs for infrequent exchanges between themselves. It is also used when a new SB is introduced in the network. The database maintained by SBs is structured as shown in Table 1. AAi represents an anycast address that is used to index the entry. Si,avg is the average request size for that anycast address whereas IPij are the various IP addresses associated to the anycast address.

Table 1. Smart Box database structure Anycast Address

Savg

AAi

Si,avg

Corresponding IP addresses IPi1 IPi2 … IPin

# of hops

RTT

BW

Local

…

An exponential moving average3 of the round trip time is maintained in the RTT field and the BW field contains the last estimated bandwidth to the server from any client. Local field indicates whether the IP address is local to this SB. We keep both the Savg and BW information in the table as opposed to the last measured TRT values. Request sizes vary widely, thus the TRT values alone are not true estimates of the effective bandwidth. All IP addresses within “n” hops from the SB can be part of the table. Currently, an ad-hoc value for “n” may be used, though future experience may suggest an optimal value. Each anycast entry in the table has at least one associated IP address. If an IP address has not been updated for a while, it is timed-out from the table. If all IP addresses corresponding to an anycast address have been timed-out, the anycast address is removed from the table. This allows removal of rarely used (and thus unimportant) anycast addresses from the database. For each request that arrives at the SB, the total response time (TRT) for each of the IP addresses serving the requested anycast address is estimated. The TRT comprises of the connection setup phase, data transfer phase and the connection teardown phase [16]. The connection setup and teardown phases together last for three round trip times since they involve a threeway handshake. Considering a request size of S bytes and an average bottleneck bandwidth BW, the data transfer time can be estimated by S/BW. This bottleneck can be either at the server or the network. So, the TRT can be calculated as: S TRT = 3 * RTT + (1) BW

the final stat-packet. When a request packet arrives, the SB does the following: 1. Look up the requested anycast address in its table. 2. If the requested anycast address does not exist: i. Send a failure message to the client ii. Make an entry for this anycast in the table iii. Add the IP provided by the DNS to this entry iv. Wait for SB updates to get more IPs for this anycast 3. If the requested anycast address exists in the table, the SB calculates the TRTs for all the IP addresses associated with this anycast using (1). 4. The probability that an IP address is chosen as the “best” is inversely proportional to its calculated TRT. The function used to calculate this probability is referred to as the “server selection” function of the SB. This randomization breaks the synchronization effects in the SBs. It also ensures that the SBs redirect requests to all servers in its table with a non-zero probablility. This helps in maintaining recent information (updates) about most of the IPs associated with a frequently requested anycast address. The justification for the server selection function is presented in the next section. 5. After choosing the “best” IP, the SB sends a redirection packet to the client with the chosen IP.

4.1. Protocol

When an update arrives, the SB uses the stat-packet contents (Sstat , TRT stat and SRTTstat) to update the table as follows: 1. Update the average request size (Savg) using a low-pass filter: S avg, new = α S avg, old + (1 − α ) S stat ( 2)

For every anycast connection, the SB receives two packets from the client, the initial request packet and

2.

3 An exponential moving average gives a lower bound on the performance. In CDAA, we find that such an approach gives sufficiently good results. Other higher order statistical approaches may give better results.

where α is the filter gain constant, 0 < α < 1 with a suggested value of 0.875. The RTT field for the IP address used is updated by the SRTT value in the stat-packet.

3. The BW field is updated by the estimated bandwidth using the stat-packet contents as: S stat BW new = (3) TRT stat − 3 * SRTT stat

4.2. Adding New Components A new SB in the network needs to build its database so that it can serve anycast requests. To do this, the new SB sends a scope-controlled multicast request on the SB multicast group. All SBs that receive this message send a reply. The new SB initializes its database to that of the first SB that responds. New servers for an existing anycast address are configured to send a scope-controlled message on the SB multicast group, so that only a few SBs receive it. All these SBs add this new server (IP address) in their tables and set the Local field in the corresponding entry making them the local SBs for that IP address. These SBs will never time out the local servers and are responsible for keeping track of their status. Even if no requests are directed to a server for a sufficiently long time, the server would not be lost from the set of all SBs. Other SBs will know of the existence of the new server through the infrequent SB updates. Introduction of servers for a new anycast address is analogous to addition of a new server for an existing anycast address. All local SBs will create entries for this anycast address and associate the IP address of the server with this anycast.

4.3. Smart Box Updates The SBs send out periodic but infrequent (e.g. once a day) scope-controlled update messages on the multicast group. The purpose of these updates is to share address and number of hop information with the other SBs. The statistics maintained for the anycast and IP addresses are not shared. The updates are scope-controlled in order to avoid unnecessary propagation of updates through the multicast group. The intuition behind this choice is that a SB will not be interested in the address table of distant SBs. The update packet has the anycast address and the associated IP addresses with the number of hops. Based on the number of hop information, a SB may decide to include IP addresses from the updates into its table.

5. Justification for the server selection function Ephremides et. al. [17] consider a single client, two server system. They show that if the work left in the

server queues (ω 1 (t ) and ω 2 (t ) ) is known at each time t , sending a new job to the shortest queue minimizes the expected total time for the completion of service on all jobs. In other words, the collective user satisfaction is maximized. This assumes that lower response time increases the user satisfaction. Similarly, considering the simple but representative case of a single SB and two anycast servers in the network, the optimal distribution of client requests to the servers is achieved when the SB directs a new request to the smaller queue (i.e. smaller of ω 1 (t ) and

ω 2 (t ) ). This result assumes that the SB knows the load at the servers instantaneously and accurately. However, it takes a certain time delay (which is itself a function of the load at the server) for this information to reach the SB. Hence, the SB’s perception of server loads might not be completely accurate and thus, redirecting requests every time to the least loaded server (as perceived by the SB) does not work in practice. Efforts to incorporate this time delay in the network model leads to complications. Rather than trying to reach an optimal solution, we use a sub-optimal but “good” method to redirect requests. We thus use weighted randomization, where the probability of a server being chosen is inversely proportional to its load. This gives better performance than choosing randomly among a set of “good” servers as in [12], especially in cases of highly dynamic network conditions. Various functions for weighting were tried which approximate the optimal function derived in [17], such as inverse of the load and its powers, inverse exponential of the load and its powers, however, the results are fairly similar and for simplicity, we decided to use the inverse function as given by: 1 ω i (t ) P( server i is chosen ) = ( 4) 1 ω j ( t)

∑ j

Note that in the above discussion, we have used the term “load at the server” which is a direct measure of the total response time, the quantity measured by the SB in practice.

6. Simulations To evaluate the CDAA architecture, we perform simulations using the UCB/LBNL network simulator, ns [18], which is a discrete event network simulator. The simulations are designed to evaluate the SB operations of the architecture. The SBs in the

topologies are an aggregate of the clients at each SB alongwith the SB itself. Anycast requests arrive at the SB as Poisson processes. The SB then distributes these requests among the servers. The request sizes are exponentially distributed with a mean size of 40kB while the service rate at the servers is a constant. The service rate is chosen such that the total load is ~80% of the server capacity. The request rate is 5 million hits per day. Congestion and packet loss in the network are lumped together with the server load for simplicity, since we finally measure the end-to-end response time. In some simulations, extraneous Internet traffic (not controlled by the SB) is placed on one or more servers. This may be thought as the unicast traffic in the Internet. We consider two topologies that demonstrate the advantages of the CDAA architecture.

6.1. Topology 1 This topology is designed to test the efficacy of CDAA in distributing the load intelligently among the servers, resulting in optimum performance seen by the clients. It clearly shows that if there is extraneous traffic that loads a particular server, CDAA avoids using that server. This simulation also demonstrates that the SB is able to quickly adapt to changes in the server load, i.e. the passively gathered estimates of the server load track the actual load accurately with minimal time lag. The topology is shown in Fig. 2. Each of the three servers (S1 ,S2 and S3 ) have extraneous Internet traffic switched on and off at random times as shown in the first graph in Fig. 4. The second graph of Fig. 4 shows

the load curves at the three servers while the third graph depicts the distribution of client requests. Each dot in the third graph indicates the arrival of a request at that server at that instance. The third graph shows that CDAA sends fewer requests to a server that is more loaded. We also observe that CDAA responds quickly to changes in the network load conditions. A few points of interest are: • Around 6 seconds, Internet traffic at S2 switches off while that at S3 is turned on. In the following couple of seconds, the SB shifts most of its traffic from S3 to S2 , thus going to the less loaded server. • Around 30-32 seconds, all three servers are loaded by Internet traffic; CDAA automatically selects the least loaded server, S1 , and sends requests there. • In the interval between 36 to 72 seconds, the Internet traffic at S3 is off resulting in the SB sending most of the requests to it.

6.2. Topology 2 The second topology, as shown in Fig. 3, is more complex than the first one, with three servers and six SBs. Each SB handles similar load and the total load handled by the six SBs is about 80% of the total server capacity. The purpose of this topology is to observe the behavior of multiple SBs in a network. It also examines the tracking of a server load by a SB in the presence of other SBs redirecting client requests to the server. Apart from the CDAA architecture, we also simulate other redirection and SB updation mechanisms. The first is “Instantaneous Updates” in

Internet traffic

SB1 S1 S1

SB2

SB3

S2

SB4

SB

S2

S3

S3 SB6

Internet traffic

Internet traffic

Figure 2. Topology 1

SB5

Figure 3. Topology 2

Figure 4. Simulation results for topology 1

Figure 5: Topology 2 – Load at server S1

which a SB immediately updates other SBs of any server load changes that it observes. The SBs redirect the clients to the server with the smallest estimated TRT, unlike the weighted randomization in CDAA. Another scheme used is “Periodic Updates” in which the SBs send periodic updates containing the server loads (the periodic interval is randomized around 5 seconds in the simulation). Again, the SBs redirect clients to the least loaded server. All three of these schemes are compared to unicasting, where the clients use the closest server. SB1 , SB2 and SB3 redirect requests to server S1 , SB4 redirects to S3 while SB5 and SB6 redirect to S2 . Fig. 5 shows the load at server S1 for all the abovementioned strategies. The load curves for S2 and S3 are similar in nature and can be obtained from [19]. In the unicast case, load on S1 is more than its capacity, thus, as expected, the waiting time increases almost linearly.

Both instantaneous and periodic updates perform poorly due to the synchronization of all SBs when the updates occur. From the graph, it is seen that CDAA performs in an excellent fashion, not allowing the load on the server to increase (hugs the x-axis). The distribution of requests from the SBs to server S1 is shown in Fig. 6 for all the above cases. Similar curves for S2 and S3 can be obtained from [19]. Each dot represents the arrival of a request from the particular SB to the server. The synchronization among the SBs in case of instantaneous and periodic updates is clearly seen in this figure where none of the SBs send requests in certain intervals of time. On the other hand, CDAA avoids such synchronization by using weighted randomization. We also note that all SBs send requests to S1 fairly often and thus have a reasonably accurate idea of its load at all times. Simulation traces also show

Figure 6. Topology 2 – SB request distribution at server S1

Figure 7: Topology 2 – Tracking of load at server S1 by SB 6

that server S1 was used more by SB1 , SB2 and SB3 than the other SBs, emphasizing the locality argument. This, unfortunately, does not come up in these graphs. Fig. 7 illustrates the tracking of the server load by a SB. Out of the eighteen choices, we chose server S1 and SB6 for demonstrating the responsiveness of an SB to fluctuations in the load at a distant server. Also noteworthy is the fact that SB6 tracks the load on S1 based only on the client requests it redirects to S1 , without requiring any other update mechanism. As can be seen in Fig. 7, SB6 closely tracks the progress of the load at S1 .This reinforces our view that there is no need for either the servers to send out load reports, or the SBs to share load information with other SBs.

7. Related Work The exponential growth in the number of hosts and users on the Internet has fueled the development of content distribution networks (CDN) [5]. CDNs have evolved from single-server architectures to multiple content-equivalent servers placed at geographically distributed locations with the intention of bringing the servers closer to the users. This has introduced a new facet to the resource (server) finding problem, namely, that of finding the “best” server containing the required resource. Dykes, Jeffery and Robbins evaluate a number of algorithms for optimal server selection and conclude that dynamic server selection techniques outperform statistical ones [20]. Partridge, Mendez and Milliken [10] proposed an elegant solution to the server selection problem by introducing the idea of anycasting at the network layer. Their work established the semantics of anycasting service within the Internet without going into implementation details. SPAND [9] proposed sharing performance information between clients to find an optimal server. However, they relied on the use of unicast addresses. This meant that each client had to know the unicast addresses of all replicated servers. Also the choice of server was left to the clients, who would typically go to the best one causing overload and synchronization effects. Also, performance information for unused servers may never be updated (unless actively probed) and potentially good servers would be lost! Another similar work is by Fei et. al. [11,12] in which the authors propose to implement anycasting at the application layer as opposed to the network layer. They take a generalized view of anycasting as a communication paradigm, using anycast domain names (ADN) instead of anycast IP addresses. We take the view that providing network layer support for anycast is preferable since all applications can take advantage

of this support. To this end, our work tries to address most of the issues raised in [11] against network layer support. The metric collection scheme in [12] is a combination of server push (the servers regularly publish their load information on a multicast group of all anycast resolvers) and client probe (anycast resolvers probe periodically to obtain server and network metrics). This leads to a tradeoff between metric accuracy and network overhead. In order to maintain accurate metrics, frequent pushes and probes are required, thus this scheme does not remain scalable as the number of servers increase. On the other hand, CDAA requires only one statistics packet to be sent over the local network for each anycast request, without compromising the accuracy of metrics of frequently requested anycast addresses. [12] maintains a pruned list of servers for an ADN and randomly selects one of them for redirection. This scheme fails to take full advantage of the response time estimates, namely, the server with the least response time is considered as good as one with the largest response time in the pruned list. However, CDAA incorporates this by using a weighted randomization scheme for server selection. The randomization ensures that recent updates are available for most serverss. Also, it prevents the system from oscillations due to positive feedback loops.

8. Conclusion and future work In this paper, we have proposed a scalable, incrementally deployable architecture, CDAA, which provides a network layer support for anycast to solve the problem of selecting the “best” server among several replicated servers. This problem assumes significance in content distribution networks where content-equivalent servers are distributed in the network. CDAA uses the response time as a metric for “best” since this is coupled with the user’s perception of QoS. The “brains” of CDAA are the Smart Boxes introduced in the network layer close to the clients, which redirect client requests based on a database of past user experience. These boxes have fairly modest processing and memory requirements. We have considered SBs to be independent network components, though they can easily be incorporated in the routers. CDAA requires only one statistics packet to be sent over the local network for each anycast request, resulting in low network overhead. It does not require any changes at the routers and servers, though some modifications must be made to the DNS and client software. Most importantly, the operations of CDAA

are transparent to unmodified clients, enabling incremental deployment. Simulations show that CDAA balances the load on servers while reducing response time seen by the clients. SBs are responsive to server and network load changes even in the presence of extraneous Internet traffic and other SB requests. An issue that still needs to be addressed is the presence of clients having different access link bandwidths at the same SB. Low bandwidth subscribers will report poor performance for their connection despite the bottleneck existing at the client rather than at the server or the network. This would bias the SB against the server even though it may not be loaded at all. Hence the SB will avoid redirecting subsequent requests to that server, potentially neglecting an unloaded server. In summary, CDAA provides an efficient framework for solving the server selection problem in content distribution networks, though some details need more attention.

Acknowledgments The authors would like to thank Rajarshi Gupta and Prof. Anthony Joseph for their critical comments on the CDAA architecture. Thanks are also due to Linhai He for his helpful suggestions.

9. References [1] P. Rodriguez, C. Spanner, and E.W. Biersack, "Web caching architectures: hierarchical and distributed caching," in Proceedings of the 4th International Caching Workshop, San Diego, California, April 1999. [2] L. Zhang, S. Floyd, and V. Jacobson, “Adaptive web caching,” in Proceedings of the 2nd web cache workshop, June 1999. [3] P. Danzig, R. Hall, and M. Schwartz, “A case for caching file objects inside internetworks,” in Proceedings of SIGCOMM ’93, pp. 239-248, 1993. [4] J. Kangasharju, K. W. Ross, and J. W. Roberts, “Performance evaluation of redirection schemes in content distribution networks,” in Proceedings of 5th Web Caching Workshop, Lisbon, Portugal, May 22 - 24, 2000.

[5] P. B. Danzig, D. Delucia, and K. Obraczka, “Massively replicating services in wide-area internetworks,” Tech. Report, University of Southern California, Jan. 1994. [6] Akamai Technologies, Inc. . [7] P.Rodriguez, and E.W.Biersack, "Continuous multicast distribution of web documents over the internet," IEEE Network Magazine, March-April, 1998. [8] R. Clark, and M. Ammar, “Providing scalable web service using multicast delivery,” in Proceedings of 2nd IEEE Workshop on Services in Distributed and Networked Environments, pp. 19-26, 1995. [9] M. Stemm, S. Seshan, and R. H. Katz, "SPAND: Shared Passive Network Performance Discovery", USENIX Symposium on Internet Technologies and Systems, Monterey, CA, December 1997. [10] C. Partridge, T. Mendez, and W. Milliken, “ Host anycasting service,” RFC 1546, Nov. 1993. [11] S. Bhattacharjee, M. Ammar, E. W. Zegura, V. Shah, and Z. Fei, “Application-layer anycasting,” in Proceedings of IEEE INFOCOM '97. [12] Z. Fei, S. Bhattacharjee, E. W. Zegura, and M. Ammar, “A novel server selection technique for improving the response time of a replicated service,” in Proceedings of IEEE INFOCOM '98. [13] D. Johnson, and S. Deering, “Reserved IPv6 subnet anycast addresse,” RFC 2526, March 1999. [14] P. Mockapetris, “Domain names - implementation and specification,” RFC 1035, Nov. 1997. [15] V. Jacobson, “Congestion avoidance and control,” in Proceedings of SIGCOMM '88, pp. 314-329, Aug. 1988. [16] Larry L. Peterson, and Bruce S. Davie, “Computer networks: A systems approach,” 1st Edition, Morgan Kaufmann, 1996. [17] A. Ephremides, P. Varaiya, and J. Walrand, “A simple dynamic routing problem,” IEEE Transactions on Automatic Control, vol. AC-25, no. 4, pp. 690-693, Aug. 1980. [18] K. Fall, and K. Varadhan, “ns notes and documentation,” The VINT project, UC Berkeley, LBL, USC/ISI and Xerox PARC, , Nov. 1997. [19] G. Agarwal, and R. Shah, “Automatic load balancing using anycast,” Project Report, CS268, UC Berkeley, Spring 2000. . [20] S. G. Dykes, C. L. Jeffery, and K. A. Robbins, “An empirical evaluation of client-side server selection algorithms,” in Proceedings of IEEE INFOCOM ’00.