This is the scheme proposed by us. Here, DNS tries to send address of geographically nearest cluster to client if that server is not overloaded. In our scheme, record of clients generating heavy requests (much more than average) is kept, so that these clients do not get IP address of server that is already loaded heavily. So if the request from client comes for the first time or it is not high request rate generating client, DNS gives address of geographically nearest server with enough free capacity to serve requests. This geographical proximity is estimated using IP addresses of cluster and client, for better estimates, local snapshot of whois database may be also queried. In our emulation, we have used high order IP address bits to compare nearness of clients and servers. For giving better performance, we have made policy adaptive. If client generates heavy request rate, its request rate is reported by clusters and we pro-actively request few possibly nearest clusters, having free enough capacity to serve the requests generated from clients, to measure round trip time between them and client. RTT is definitely better but costlier metric to get but this overhead is very small (less than 1% of traffic increase if ping is done to all clients, as reported by Crovella et al [14] in their study). Thus DNS gets better and much more accurate proximity information between clusters and client. Since DNS gives IP address of clusters having enough free capacity, if there is no sudden variation in request pattern of clients, no server should be overloaded in spite of load skew. RTT information is refreshed after refresh time interval. Pseudo code for the algorithm is given in section 3.6.1.
Average response times reported by Webstone is plotted in Figure 5.4. As seen in plot, once again variation is very small but average response time is much better than the other three policies.
