CS 739 Reviews - Fall 2014

Summary:
- The paper presents and simulates a decentralized implementation of caching for faster performance of the World Wide Web (WWW).
- Consistent hashing coupled with Doman Name System (DNS) is used to find the cache that contains data, which increases cache hit rate and WWW performance.
- The technical contribution of the Cache Resolver Mode performs significantly better than the current Common Mode in terms of cache miss rate and Request Latency.
- Extensions such as spreading hot pages and decentralization were used to boost reliability and fault tolerance.
Problem:
- Congest networks and swamped servers causes delay in the WWW.
- On cache misses, using servers or second level caches is also slow due to slow/extra communications.
- Second level cache hits require network bandwidth to copy data, and will evict other pages and cause higher cache miss rates.
- Using Second level cache causes data redundancy, leading to many caches having copies of some data while no caches having copies of other data.
Contributions:
- The paper contributed using hashing to quickly determine whether the data was cached and, if so, obtain the data. Besides just having at most 1 cache miss and no redundancy, hashing data locations led to other applications such as cache associativity used in processor caches today. Like hashing, cache associativity informs the processor of where to search if the data were to exist in cache.
- The paper presents hash table using DNS. The DNS is readily available by a nearby DNS resolver and can store mappings of thousands of keys (IP addresses) to values (names), which is ideal in hash tables.
- The paper also solves the problem of adding new machines to the hash function by using consistent hashing so that new caches will only change a few URLs. Furthermore, consistent hashing is an optimization between balance, load, and spread. The farther implications of using consistent hashing makes distributed systems easily scalable (since new caches can easily be added), load balanced, and fault tolerant (due to multiple copies of the cache throughout the network).
Discussion:
- The validity of the results shown in Figure 2 is questionable. The setup is done using a total database of 34 Mb while the cache sizes is varied between 9 to 36 Mb. The cache size is greater than the total database size at 36 Mb, which should only cause compulsory/cold cache misses since no data ever has to be evicted. If anything, since the paper’s contribution of Cache Resolver likes to make multiple copies of data to support hot pages and increase fault tolerance, I will expect the cache miss rate to be lower for Common Mode than Cache Resolver when the cache size is greater than the total database. This is not to say that there is anything wrong/bad with the paper’s contribution of Cache Resolver, because rarely do we every have cache sizes greater than the database.
- The paper’s contribution of adding new cache is also questionable. As shown in figure 1, when cache C is added, then half of cache A’s workload is transferred over to cache C. This means that adding new caches is poorly utilized as they will only get a near equal fraction of another caches’ workload as oppose to an equal fraction of the entire system workload. For example, imagine having 2 caches storing 52% and 48% of the system workload. Adding a new cache will split the workload to 48%, 26%, and 26%, which is unbalanced.
- The paper’s implementation for supporting hot pages to spread virtual names mapped to a hot server to all caches is a bit overaggressive, especially other data will be evicted and cause higher cache miss rates. Furthermore, tracking the virtual names is difficult and requires extra communication if there are multiple copies of data in the distributed cache system.

SUMMARY: In this seminal work, Karger et al discuss the related problems of optimal data placement in caches and request routing. They propose a system design based on consistent hashing, which simultaneously achieves the objectives of maximizing cache hit rate, balancing load between the cache servers, allowing scalable (elastic) growth to ease hot spots, as well as dealing gracefully with node failures and other faults.

CONTRIBUTIONS:
* Prior work on cooperating caches (using primary and secondary caches) suffers from high latency in serving clients, and high bandwidth utilization for communication between servers. The Cache Resolver design proposed in this paper
- reduces latency by only hitting one cache server
- avoids inter-cache communication
- provides better cache hit ratio, since each item is likely to be replicated at only a few cache servers.
* While hashing-based solutions can, in general, avoid some of the costs of cooperating caches, they are difficult to scale because the addition or deletion (possibly due to faults) of a node leads to a lot of data movement/churn in the caches. Consistent hashing minimizes cache churn by ensuring that very few other caches are affected by such a change in the cache server set, viz. ones with neighboring cache points in the unit circle.
* The authors explicitly deal with the asynchronous nature of information propagation on the Internet, whereby different clients may have different "views" of cache server availability.
- Theoretical and experimental analysis showed that consistent hashing only leads to a small amount of additional replication in this scenario, improving overall cache utilization.
- They also show that consistent hashing only permits a small load variance between cache servers.
* An additional contribution is the Cache Resolver system design, which breaks consistent hashing into browser-side URL hashing (to virtual cache names) and DNS-side consistent hashing (from virtual caches to physical ones). They also proposed designs which would do away with custom DNS servers, if browsers are suitably modified.
* The DNS servers can be used to provide geographical locality, where client requests are directed to the nearest cache.
* The virtual-to-physical redirection in DNS also allows graceful handling of node failures and partitions transparently to the clients, simply through changing this mapping.
* They also propose a way to dynamically adapt cache replication factor for items in order to deal with hot items and changing content popularity.
* The proposed design has no single point of failure. In particular, the DNS, while potentially a SPOF, was a pre-existing one.

SHORTCOMINGS:
* I don't see how the DNS-side consistent hashing technique can scale to a large number of applications. Different web applications may use different hash functions, mapping to different servers. Either each DNS server must maintain many such hash functions and apply the appropriate one given the virtual cache address, or every application must maintain its own DNS servers. Both approaches are a difficult to scale to thousands or millions of applications.

IMPACT:
* Consistent hashing has been hugely influential in the design of CDNs, particularly Akamai's. This was key to scaling web growth over the years.
* It is also used in the design of distributed hash tables, which are used in Key-Value stores like Cassandra, as well as peer-to-peer systems like BitTorrent.

SUMMARY: In this seminal work, Karger et al discuss the related problems of optimal data placement in caches and request routing. They propose a system design based on consistent hashing, which simultaneously achieves the objectives of maximizing cache hit rate, balancing load between the cache servers, allowing scalable (elastic) growth to ease hot spots, as well as dealing gracefully with node failures and other faults.

CONTRIBUTIONS:
* Prior work on cooperating caches (using primary and secondary caches) suffers from high latency in serving clients, and high bandwidth utilization for communication between servers. The Cache Resolver design proposed in this paper
- reduces latency by only hitting one cache server
- avoids inter-cache communication
- provides better cache hit ratio, since each item is likely to be replicated at only a few cache servers.
* While hashing-based solutions can, in general, avoid some of the costs of cooperating caches, they are difficult to scale because the addition or deletion (possibly due to faults) of a node leads to a lot of data movement/churn in the caches. Consistent hashing minimizes cache churn by ensuring that very few other caches are affected by such a change in the cache server set, viz. ones with neighboring cache points in the unit circle.
* The authors explicitly deal with the asynchronous nature of information propagation on the Internet, whereby different clients may have different "views" of cache server availability.
- Theoretical and experimental analysis showed that consistent hashing only leads to a small amount of additional replication in this scenario, improving overall cache utilization.
- They also show that consistent hashing only permits a small load variance between cache servers.
* An additional contribution is the Cache Resolver system design, which breaks consistent hashing into browser-side URL hashing (to virtual cache names) and DNS-side consistent hashing (from virtual caches to physical ones). They also proposed designs which would do away with custom DNS servers, if browsers are suitably modified.
* The DNS servers can be used to provide geographical locality, where client requests are directed to the nearest cache.
* The virtual-to-physical redirection in DNS also allows graceful handling of node failures and partitions transparently to the clients, simply through changing this mapping.
* They also propose a way to dynamically adapt cache replication factor for items in order to deal with hot items and changing content popularity.
* The proposed design has no single point of failure. In particular, the DNS, while potentially a SPOF, was a pre-existing one.

SHORTCOMINGS:
* I don't see how the DNS-side consistent hashing technique can scale to a large number of applications. Different web applications may use different hash functions, mapping to different servers. Either each DNS server must maintain many such hash functions and apply the appropriate one given the virtual cache address, or every application must maintain its own DNS servers. Both approaches are a difficult to scale to thousands or millions of applications.

IMPACT:
* Consistent hashing has been hugely influential in the design of CDNs, particularly Akamai's. This was key to scaling web growth over the years.
* It is also used in the design of distributed hash tables, which are used in Key-Value stores like Cassandra, as well as peer-to-peer systems like BitTorrent.

Summary
This paper introduces try to solve problem of designing a scalable, fault tolerant web caching system. They attempt to do so by introducing consistent hashing, a hashing method that prevents large scale change in the mapping of keys to slots in the event of caches addition or deletion.
Problem
Caching web pages is one of the most efficient way in reducing latency. Haivng a single caching machine to serve a group of users introduces a single point of failure in addition to not being scalable. The alternative distributed caching scheme has its own problem of high inter cache communication and duplication of data. The authors came up with the idea of consistent hashing to provide a distributed caching scheme without any of the above problems.
Main contributions
The main contribution of the paper is consistent hashing. The authors mention that this paper covers only implementation details of the scheme. In consistent hashing, if we have K keys stored in a hash table of N slots, then addition or deletion of a slot would result in the remapping of only K/N keys on average.
Consistent hashing efficiently provide smoothness that is adding or deleting cache doesnot require us to remap all the URLs, balance that is all the caches are uniformly responsble for the number of the URLs.
In addition to the above it ensures that each item is present in some cache under some view. So for an effecient caching, the scheme should ensure that no node being unresonably large number of cached items over all views of which it is part. Also the scheme would ensure that cached items has to be in only small number of nodes even though it has to be under every view.
They provided clever hacks for their implementation by including havign DNS to map hashes to actual IPs when they realized that current browsers donot have capability to support their idea.
In addition to that tried to provide simple extension for their scheme to ensure locality (by having clients being served by only caching servers in their proximity),load balancing(by having more hot pages to map to more cache servers), fault tolerance (by having DNS remap if any cache server fails).
Flaws
One thing I noticed is that their guarantees are mainly based on the fact that hashing function is ideal which is generally not the case. It is n to see if consistent hashing implementation with real hash functions provide the ideal load balancing when the number of URLs and number of cache servers are huge. It would have been nice to see how the implementation works in real world.
Another thing that is not adequately addressed is the extension is the load balancing. It assumes that web page hotness increases but doesnot decrease.It introduces the same problem of unncessary duplication of data which it was trying to solve. In addition to that finds the optimized number of servers the page by bounded search which is not efficient if the number of servers are huge.
In addition to that they assume that all the caches are of same capacity.
Relevance
The paper provide implementation details for the consistent hashing. It introduces consistent hashing which became basis for DHT which is widely used in P2P systems. In addition to that the idea of using consistent hashing for the caching the content is used in present day distributed databases like DynamoDB.

The authors of this paper propose a web caching strategy that can potentially improve the latency issues significantly. This web caching strategy is based on consistent hashing and is proven to perform better than other alternatives such as the multicast and directory schemes.

Contributions:
• The paper most importantly presents the need and the benefits of web caching - it uses the simple concept that accessing nearer things are faster and that holds true for the biggest of the networks too.
• It is nice to see how they evolve from studying the good and bad of the cooperating caches technique. While this technique provides latency benefits because of the primary and secondary caches, it is bottlenecked by the intercommunication between the caches and also the duplication of the messages.
• I think it is a novel idea that they designed the Cache Resolver wherein the task of decision making (to access the appropriate cache) is offloaded to the browser itself.
• It is also interesting how the consistent-hashing inherently provides the load-balancing feature because it distributes its inputs randomly among the possible locations.
• It was a nice work around to make use of the DNS when they realized that the browsers would not support the original implementation. It’s also great idea how they split the DNS to 2 levels so that the user can actually access the server closer geographically since it would be much faster.
• The authors also solved a major issue – some of the pages are accessed much more than other pages (especially with popular websites) in which case the caches can be overloaded, but the authors solve it by mapping the virtual names of such pages to a list of IP addresses instead of one.

Applicability:
The internet usage today is overwhelmingly higher than when the paper was written, yet the idea of web caching is applicable and companies such as Google cache a lot of their contents, sometimes even predicatively. Especially it is interesting to note that this paper envisioned and solved the issues of high usage of popular pages which is exactly the case today.

Problem:
- the main problem is to cache the web traffic to avoid delay because of busy servers and slow networks.
- the specific problem that this paper was concerned with was distributing the requests between the cache servers in a way that is balance and doesn't cause any additional over load for the system.

Solution:
- they use a consistent hash scheme.
- "consistent" refer to the fact that changing the number of cache servers doesn't dramatically change the pages associated with other cache servers.
- they use a hash to map the addresses to 0-1 and map cache servers to 0-1 and give addresses to nearest cache server.
- by associating cache servers to multiple positions (they use different names that maps to the same server) they ensure a more uniform distribution of requests (if a server is dead or it isn't in the "view" of a client, it only add a little overload to other servers).
- they use DNS to handle the hashing (it decides what address goes to what cache server)
- they return a list of possible cache servers, so if the browser doesn't update its list it wouldn't get stuck with a dead cache server and would have other choices.

Evaluation:
- they compared the number of misses and average latency between their model to other models that either don't coordinate the cache servers or use other methods to do that.
- they used another software to simulate the network traffic.
- they tested different configurations of the cache servers (size of the memory)
- they showed that their model perform better or as good as other methods and has less over load for the system.
- one interesting point was that even when the cache size was as big as the data base, their system would have fewer misses (because in their system request for one address can be a miss in only one cache server, but in other systems one address can be a miss in all the cache servers).

Other points:
- they mentioned that because they are using uniform distribution (because of hashing), more frequently visited pages can increase the traffic of the cache server that they are associated with. they proposed to re-distribute the traffic of the hot servers to other cache servers in region.
- I think this isn't a very good solution: one selling point of their method was that it doesn't need additional computation. if we want to do additional computation to find the over loaded servers and then override the hashing, why not use a load aware distribution (like LARD)?

- the original setting (caching the pages for speed up) doesn't exist any more. but the problem of distributing requests between servers (e.g. the facebook example mentioned in the class) still exist. and it looks like a good solution for the problem.

- the performance of the system is dependent on the uniform distribution of requests using the hashing, and they showed that the standard deviation of requests associated with each cache server is small. but I still feel that a load aware distribution would be a better choice (probably because I don't trust the uniform random distribution of the hashing)

- this isn't a technical point: I'm not sure but it seems like the cache system is transparent to the users (specially if redirecting happens in dns). users should have a way of knowing about the cache and opting out (I guess they can manually change their dns address).

- another unrelated point: the y-axis of the plots don't start at zero. I think that over-emphasize the difference in performance (specifically in latency plots for higher cache sizes the difference is very small)

Summary:
This paper discusses the use of consistent hashing to create a better web caching server in terms of cache locality, balancing load, and fault tolerance. In the authors’ discussion, they give an overview of the consistent hashing algorithm, a description of their working implementation using DNS, and a comparison to other caching systems such as using a primary cache or a directory based approach.
Problems:
As we saw in the locality-aware request distribution paper, caches for distributed systems have two dimensions of optimization: locality and load distribution. This paper introduces a third, fault tolerance, which is often a problem for a single frontend load balancer system design. This is solved by decentralizing the load balancing and removing the single point of failure that is the frontend server in LARD, but more on that later. Another problem that is solved is the cache misappropriation by means of RAM and disk waste due to unnecessary cache replication and management of state for sibling caches. Also saved was network bandwidth by doing away with multicast and unicast broadcasts for inter-caches communication for their state.
Contributions:
A new web caching strategy was introduced by means of consistent hashing using the DNS server to hash URLs to cache server IP addresses. The unique feature consistent hashing provides, as opposed to modular hashing, is the ability to add and remove caching servers from the cluster without having to regenerate the entire hash. A good illustration was viewing the hash as a unit circle where each caching server took an arc segment of the circle. When a new caching server comes online it absorbs a segment of the circle from other nearby caches on the circle, instead of all the servers having to change which URLs they can cache. Another contribution was the decentralizing of the load balancing by having the web browser request directly from the cache as given by the DNS system. I question the security of such a design because it might be easily attacked with a denial of service (DoS). If specific URLs were prepended with their cache information in the domain name, a similar URL with a different proxy domain name would yield an uncached request for that URL. Done enough, it could bring the system to a crawl where every malicious request is reading from disk. Another issue with this system is its reliance on DNS. DNS itself is cached, so I imagine any immediate changes to the consistent hash could take hours or days to propagate the entire DNS system depending if TTLs are honored or not. Another attempt at running such a system using modern browser based javascript would probably work as it is now a first-class language and robust enough to handle a consistent hashing algorithm. One significant finding with this consistent hashing strategy was that it had cache miss rates on par with system wide cache miss rates of other systems. This means the locality for this strategy was as efficient as a giant monolithic caching system without the overhead of inter-cache communication and replication.
Applicability:
Having interned on the Simple Storage Service (S3) team at Amazon Web Services (AWS) I know this method of consistent hashing for load distribution is very applicable. S3 is running a custom software load balancer that uses consistent hashing to distribute requests to the first level caches in the system. Of course, instead of using DNS to hash the name lookups to IP addresses, the services use many frontend load-balancing hosts to consistently hash requests to the specific caches sharing the state of the hash via Paxos.

Summary
This paper proposes a consistent hashing strategy for Web caching system to relieve delay and failure in current World Wide Web. Besides, they also extend basic system to provide Locality, Load Balancing and Fault Tolerance properties.

Problem Description
The current computer network is somewhat best-effort delivery rather than providing quality of service. Besides, the behavior of the network is usually unpredictable, and sometime changes dramatically. With the growth of the Internet, the network becomes congested and severs are swamped. Thus, an adaptive scheme is needed to deal with such situations. Although Web caching can reduce core network traffic, current strategies like “Cooperating Caches” suffers from high delay, single point of failure or duplication data.

Contribution
1. They propose an approach using consistent hashing, which gets rid of inter-cache communication, can let clients decide which caches should communicate with. This implementation can achieve an even shared requested pages, and deal with information propagation asynchronously when clients come and go over time.
2. The second contribution comes from solving autoconfiguration function is limited to common browsers, so they decide to implement consistent hashing strategy in DSN.
3. Also, they use two-layer hierarchy DSN to provide locality to user, which is also very important for performance improvement.
4. In order to deal with hot pages, which may causes load imbalance, they first spread virtual names mapped to the hot server to all caches, and lowly reduce the size of mapping.

Drawbacks
1. One of underline assumption in the paper is all servers have same capacity and performance. But in reality, some servers may outperform than others. Therefore, it is better to use CPU/memory/disk utilization or network bandwidth as load metric.
2. When several servers cached a certain hot pages and hot pages is modified at the source server side, due to information propagation is asynchronous, some user maybe still get the old version of hot pages.

Applicability
This paper is very practical and important for Content Delivery Network, which helps alleviate network congestion, swamped servers and delay problems. In fact, a famous network service provider Akamai uses this strategy for their system and achieves a big success.

Summary:
This paper introduces a web caching solution that use multiple cache servers which work cooperatively. Like other web cache solution, the system can release the request handling pressure on the original web server and reduce the network traffic by relay the content from original server to multiple clients. As an example of cooperating caches, consistent hashing can achieve higher reliability than single cache, and has several advantages over other cooperating caches.

Problem:
Problem of data delivery system: The eventual problems that web caching tries to solve is the content access delay and failures. Root causes of such kind of problems are network congestion and server swamping. By moving data close to the clients and serve them with the cache server, the pressure on the original server will be released, and network transmission is more efficient because multiple clients can share the same copy of the content in the cache server instead of accessing the original server seperately.

Problem of single web caching approach:
1. Not reliable, because the single cache server is a point of failure.
2. Can’t be close to all the clients.

Problem of traditional cooperating caching approach:
Hierarchy cache with directories: Not reliable
Hierarchy cache with multicast or broadcast: Not efficent becase it waste bandwidth
And they waste storage space because of the duplicated content in the cache servers.

Problem of traditional hash caching:
1. Hard to add new cache server or remove old cache server
2. Can’t handle the multiple view problem properly

Contributions:
Compared to other cooperating caches, consistent hashing is:
1 More efficient because different cache servers don’t need to communicate with each other, and no much duplicated contents need to stored in the cache servers.
2 More reliable because no centralized control.
3 More scalable because it’s easy to add new cache servers.
4 Can supports multiple view from the client
The implementation of consistent hashing on DNS is a good choice.

Discussion:
Though the name of the algorithm is “consistent” hashing, I feel it just add one level of “indirection” in hashing.
I have concern about the convergence speed of the algorithm to handle “hot pages”, and how well it can handle the variation in hotness. In addition, this paper doesn’t discuss much detail about how to invalidate the content in cache server by the original web server.
The web caching solution is widely used now. Akamai is the company that publicly provide such service to web sites, and the architecture of Akamai’s web caching system is very similar to the one described in this paper. The idea of consistent hashing is used in other field as well, e.g. P2P, distributed data base, etc.

Summary:
The authors apply consistent hashing technique at client-side to ensure requests for URLs are well distributed among caches but also distributed very consistently in the event of caches going up or down.

Problem:
Caching is vital for the demands of the web. Techniques of the time included multi-level "cache systems" wherein a client contacts some cache for an object, and on a miss that cache performs a task to try to find the object in another cooperating cache before going to the source server.
- Multiple misses take time. How long does it take to see no cache contains item?
- Multiple misses take bandwidth. Extra queries between caches congest the network.
- These models result in undue replication, as many caches are queried for the same object. Aggregate cache size decreases.
- Some have single points of failure, like the directory server in CRISP. If it goes down, all caches become fully independent (no secondary lookup).

Solution:
Idea is to let the client figure out exactly the cache to request an object from. Then only one cache (or a few for "hot pages") should be contacted for a given item.
At this time, consistent hashing is not truly performed by the client. Client browsers use a normal hash of the URL to produce a small number of virtual names to contact. DNS servers are provided with mappings from these names to cache addresses periodically (the mappings are produced using consistent hashing to distribute well and handle cache availability).

Evaluation:
The authors evaluate cache miss rate and latency on a small setup of 7 machines, 3 being caches. In this I think they probably gained some bias towards their technique. If they had 10 or 100 caches, then the 1000 virtual names would be less likely to distribute well across the physical caches. Perhaps number of virtual names can increase with caches, but it was not clear what the cost of adding more virtual names would be (for the DNS servers, for the browser javascript code).

Overall, they saw between 25% and 50% decrease in latency compared with other cache configurations (more benefit when caches are small compared to working set size), which is quite significant.

Contributions:
+ Offloading some of the work of locating data to clients is a huge contribution. The amount of work for one request is small at the client, but handling many of these decisions in servers compounds the pains, creating bottlenecks and failure points.
+ Unique application of consistent hashing to distributed systems, as normal hashing would suffice if not for the partial failures or simple growth of distributed systems.
+ Virtual names. Interesting use of DNS, valuable properties to an abstraction like this, as outlined by the authors, and seen in virtual memory, etc. etc.
+ Not sure if new here, but using DNS to also direct to geo-local servers.

Today:
Still highly relevant today (technique itself still used today). I think if it hasn't been done that there would be room for improvement in the technique they used for handling hot pages, namely in identifying them.

Summary:
The rate at which the internet users increases is much greater than the web servers installed during those time. This paper proposes web caching as solution to this problem and implement it using consistent hashing.
Caching helps the performance of web severs by preventing all the requests to overload a single server as well as reducing disk reads to service a request. The current implementations in those times used cooperative caching where the miss in the first level of cache will broadcast request to other caches to find if any one of them has a copy or else contacts the server which has the source. The other idea is directory based where, the request will go to a directory which resolves the cache address, but here there is a single point of failure in that model.
Consistent hashing eliminates inter cache communication by making the clients themselves decide on which cache to contact for the content. if a simple hashing model is used, as the cache servers scales up and down, hash function will have to be changed which will provide a lot of inconsistency in assigning cache servers to URL. In order to overcome the problem consistent hashing is used. In this, if the cache servers and url are hashed and mapped onto a unit circle, the url hashes near to a cache point are associated. In this case, even if a new cache point is introduced only the url hashes near to that get modified and not the every other cache point. The randomness of distribution can also be increased by introducing copies of cache points. Thus consistent hashing solves the problem of simple hashing such as scalability and cache misses.

Contribution:

1. Consistent hashing improves the performance of web caching in terms of scalability and lowering cache misses.
2. It doesn't introduces a new layer in the client to cache server flow, but uses a DNS server to convert the mapping of virtual host name to cache server address.
3. It also can make use of locality by introducing 2 layers of DNS resolve, where first layer resolves DNS server based on location, and the second layer resolves the actual cache server to request for the page.
4. It also supports load balancing for hot pages by a method in which all the virtual names are automatically
5. It proposes a fault tolerant model by introducing indirections in resolving the URLS to virtual names and from virtual names to IP address.

Drawbacks:
1. To find the hot pages, DNS server is used to find the load to a virtual name, which is not a correct measure since it can be masked.

Summary: In this paper, the author implements a web caching system based on consistent hashing and presents experiments to verify its performance advantage.

Problem: Different kinds of cooperating cache strategy has been proposed to achieve fault tolerance, scalability and aggregation of large numbers of requests. But they all have problems: hierarchical approach need the primary cache to request other caches when missing hit, which uses too much bandwitdh and the waiting increase latency. Directory based schemas is not robust because of the new point of failure, and when rehashing, a lot browsers' content need to be recomputed.
Both hierarchical and directory based schemas have too much duplication of data among caches.

Contribution:
The author presents a new cache system based on consistent hashing.
(1) The hash does consistent partition of URL in caches. Therefore, only local computation is needed to decide the cache of a given object thus inter-cache communication is eleminated and performance is improved.

(2) Unlike ordinary hash, consistent hashing schema has to move only a small amount of cache entries when new caches are added.

(3) It is unrealistic to assume the power of browsers to compute the hash function. Therefore, the system designs a intermidiate DNS servers to do the assignment of URL to caches. The design also exploits geographical locality by using two-layer DNS hierarchy and users will be served by caches in their region.

(4) The use of virtual names for hot pages (pages which visits concentrate on) makes the each hot page be served by multiple caches, thus it is load balancing.
Also, the virtual names makes no single failure problem, thus it is fault tolerance.

Applicability:
The idea of consistent hash cache systems is simple, useful and still very popular today, such as Amazon's Dynamo. Its scalability and fault tolerance seems to be better than LARD, for in LARD, the front end can become bottleneck and single point of failure. Consistent hashing strategy is more robust. The idea of modifying clients' browsers will cause security problems.

Summary
This paper tries to solve the problem of delivering faster web content to users by incorporating a web caching scheme where the number of web pages is equally distributed across multiple caching machines .

Problem
The paper tries to tackle multiple problems , primarily how to improve user experience by reducing latency of web page requests . Caching on single server is an option that might partially work but its also the single point of failure , the bottleneck for all web traffic ( overloaded system ) and does not take locality ( geographic area) into consideration . Distributed web pages across multiple caching machines sounds like the solution to the previous problem but since there is no real mapping of requests to actual location of web pages , the clients usually sends multicast messages into the network thereby worsening the problem

Contributions
The paper proposes using consistent hashing to map requests to a set of caches thereby fulf. This algorithm ensures an equal random distribution of web pages across caches and allows minimum shuffling of web pages ( amongst caches ) for a set of caches that is dynamically changing ( increasing when the system scales up and reduces during failure ) . URLs are mapped to virtual caches using a standard hash and a DNS server is used to map virtual caches to real caches(IP Addresses) using consistent hashing . Geographical information is incorporated into the JavaScript function in the browser that generates the virtual cache URL thereby reducing latency . The hot pages problem was solved by mapping a "hot" virtual name to multiple IPs . But the author mentions that the DNS Server is used to track which pages are currently hot by counting the mapping requests . These mappings might be cached in the client side so might not give the true picture and this trick might be too slow in recognizing a Slashdot effect like situation

Applicability
As network traffic keeps on increasing along with more web/media content in the future , I see the ideas presented in the paper as useful solutions to tackle such problems .GlusterFS , a distributed file system uses consistent hashing to calculate the location of a file on a fileserver thereby eliminating the need of a central metadata server .CDN Service providers such as Akamai Technologies use a system very similar to the one described in the paper to cache media and web files on behalf of media companies

Summary:
This paper discusses the problem of improving web caching and hence web response time using a novel caching scheme based on consistent hashing.

Problem:
In the multi/broadcast approach, the primary cache sends requests to other caches on a miss. This scheme uses excessive bandwidth and moreover the primary cache has to wait for all other caches to respond which can increase the latency. Directory based schemes also consume excessive bandwidth. Centralized directory schemes bring in new points of failure. In both these approaches it is possible for the caches to contain the same duplicate data - which means less effective cache utilization. Both these approaches do not scale well.

The authors design and develop a new caching system (Cache Resolver) which uses the idea of consistent hashing. This technique avoids all inter-cache communication. This new scheme has the following attractive properties:
1. Less communication overhead since caches are not communicating with one another.
2. No single point of failure like directory schemes.
3. No intermediate cache - The client decides which cache it has to go to => better response times.
4. There are no redundant copies of a page across caches.

This scheme is based on consistent hashing. The URLs and the caches are all hashed to a Unit circle. A URL is assigned to the clockwise successor cache in the Unit circle. When a new cache is added/removed, only a small subset of the URLs have to be remapped to a different cache. Consistent hashing also ensures good uniform distribution of URLs to caches. Even with multiple inconsistent client views, each URL is mapped onto a smaller number of caches => It is not possible for a particular URL to be present in all the caches.

Implementation: The client script produces a virtual cache name using a standard hash. This is given to the DNS server which does the consistent hashing and returns a IP address to the client.

Contributions:
1. The idea of using consistent hashing to do web caching.
2. One level indirection mechanism using the virtual cache names between the client and the DNS. (Really neat)
3. Extensions like geographic location of a client and the cache, identifying hot pages, fault tolerance.

Discussion:
The idea of using DNS(or any other existing component) to do the hash computation seems bit hacky but still seems intelligent given the indirection it provides. The authors cleverly delegate the single-point-of-failure problem to DNS which anyways was already a single-point-of-failure.

Relevance:
The problem of reducing WWW latency through caching is highly relevant today. There are lot of systems like Amazon's Dynamo DB, Vuze DHT, cassandra that use consistent hashing to partition/load balance/locate data. More key-value stores and document storage systems have taken inspiration from consistent hashing. Moreover, CDNs use similar approach to redirect requests (at DNS servers) to caches based on URLs.

Summary:
Consistent hashing is an improvement over other schemes such as Harvest & CARP that were prevalent at the time. Consistent hashing provides excellent and simple scaling, fault tolerance, high cache hit rates, and requires minimal customization to effectively handle hotspots.

Problem:
Speed is the KPI with which we judge the performance of the world wide web. We need to improve the speed at which content is delivered to users, and we need to do this in spite of extremely massive and unpredictable usage spikes.

Contributions:
It's critical for the system to hash consistently. Regardless of multiple, changing views of the system, each item only gets mapped to a small number of machines. The cache resolver is a practical solution that combines caching backend machines, the user's browser, and DNS servers. Their testing demonstrated that consistent hashing provides the following benefits:

1-Simplified elasticity / scaling
It's relatively easy to add / remove server nodes (without disrupting the entire cluster) since only the closet impacted data ever shifts between servers.

2-Fault Tolerance / no single point (or other new points) of failure
If a node goes down, data then just goes to the next nearest server which it hashes to. Although the cache resolver needs to run on the DNS servers to determine which servers virtual names should map to, this doesn't represent a new point of failure either because DNS was already a point of failure anyway.

3-Reduced bandwidth usage
Consistent hashing requires no inter-cache communication. Other systems (e.g. multicast) had the additional penalty of inter-cache communication during a miss, which consumed disk space and ram while the data was transferred, and also added latency & congestion to the network by increasing bandwidth usage (reducing available bandwidth for other uses)

4-Load Balancing

5-handling hot pages:
Hot virtual names can be mapped to a large list of IP addresses instead of just one and BIND DNS does round robin through the IPs thus balancing the load. The list could then be reduced in size as long as the load to the original server wasn't increased (i.e. until an optimal balance was achieved).

Applicability:
The browser aspect of their solution uses JavaScript to map client input URLs to 1,000 virtual cache names. This is probably the only facet of their solution that isn't in widespread use today (although the idea of pushing some of the computing load client-side is still very relevant).

Consistent hashing applications led to:
1-The formation of the Akamai CDN
2-it continues to help us scale the world wide web
3-it provided a theoretical basis that allowed the development of numerous distributed systems such as peer-to-peer file sharing and databases such as Amazon Dynamo, Hadoop, Cassandra, Riak and others.

Summary: Paper presents an implementation of consistent hashing as applied to web caching. It uses a modified DNS server along with browsers to help lower cache miss rates, inter-cache control traffic, and less duplicated entries in caches. Their implementation shows marked benefits over other cache implementations such as CRISP and Harvest System test.

Problem: It is highly advantageous for there to be some sort of web caching on the internet. It brings faster response times to queries because users do not have to travel to a central and potentially overloaded server and it decreases overall congestion because requests can be served on a more local manner. However, some caching solutions have problems. Back then, current solutions had problems such as an increased amount of cache control traffic where a primary cache server would, on a miss, query all secondary caches for a copy of the requested data. The original request could not be served until all secondary caches responded. Secondly, web cache solutions often, on a miss, would grab put the miss in its working set and thus there was a lot of duplication of data among caches; effectively lowering the amount of web data that can take advantage of web caching.

Contribution: The main contributions of this paper is the application of consistent hashing to the problem of getting clients to connect to caches that have a high probability of having the content that they desire. The authors create a system that realizes the already known theoretical benefits of consistent hashing and they discuss the problems that come with the actual implementation of a system.

Consistent hashing is a way to basically guarantee that keys are evenly distributed among some set of entities. Therefore, in this system, caches would occupy different points in the target space. The keys, URLs, would map into the space and be assigned to the nearest cache that is “clockwise” from it if you were to imagine the target space laid out in a circle. This system is easily scalable because, when you add another cache, it would only sap entries from one cache that is further in the circle and only those entries that map before the newly added cache. It has provable qualities such as logn look-up time and logn addition.

Another contribution is they gave a good argument as to why the DNS service can and should have cache resolution as part of its domain. This realization came about when they realized that browsers wouldn't be able to easily support cases where caches are added, removed, or are down.

Finally, they showed that their system has lower cache miss rate and faster response time to a variety of systems that existed at the time.

Applicability: Consistent hashing is obviously a very useful tool in use in many systems to this day and likely well into the future. However, it does not seem like this particular system would be that applicable to the modern world. First off, it doesn't seem that this system was tested as well as it should have been; especially compared to the paper on Tuesday (LARD). Furthermore, while adding functionality to DNS is a nice idea, it seems that it really hampers applicability because it requires a change to a fundamental system as well as tying everyone to one kind of caching system. Who is running the caches/who is paying for it? How do you implement policy where companies agree to cache certain websites? By virtue of consistent hashing, such control would be hard to implement and would be necessary if we wanted their system to become a reality. CDNs have gotten around this issue by having the site owners give DNS control over to the CDN. That seems to be the proper workaround and middleground.

Summary: Caching is a good solution to the problem of overloaded servers, and this paper introduces a new cache system. It uses consistent hashing on client side to direct a connection to the appropriate cache, greatly reducing load on the servers.

Problem: As the usage of the internet was growing, there was an intense need to deal with congested networks and failed connections, the latter due to overloaded servers. In addition, the nature of the internet means that traffic spikes can be both sudden and monstrous; indicating that pre-planning for such events was not necessarily useful, and could be wasteful.
Caching had been used to reduce load. It was effective at reducing connections to an overloaded server or the source server in addition to merely serving pages faster. There are, however, some limitations to the caching design done at the time. Since caches sat between source and frontend, they could fail completely or be a bottleneck to the overall system. Single caches could also have a false miss on repeated requests, and also suffer from the problem that though they are limited in connections, more connections would mean more cache hits.

Contributions: The major contribution of this paper is an implementation of consistent hashing to direct a request to the appropriate cache. Because of issues of implementing the hashing on the browser, they actually implemented the hashing in a DNS server. When a client resolves the page using DNS, it is actually resolving a virtual cache, which is a standard hash of the URL. This virtual cache name is then hashed using consistent hashing in the DNS, which maps it to a real cache.

Flaws: One obvious flaw, in my opinion, is the use of DNS. Considering they need a custom DNS configuration to run this, then they need a new DNS server entirely, which means it's not that different from having a front-end in their cluster that does this hashing for them. Either way, it's pushing computation out of their cluster and into the DNS, which someone will have to pay for. It may be more possible now to do this sort of hashing on the client, perhaps using browser extensions, which can constantly connect to a server, meaning they can be updated at will.
Another interesting problem is the idea that client-side can cache some DNS entries. If this is the case, the system will have to time-out if the request fails or takes too long, since it will forego contacting the DNS server. Another question comes up as to how often the list of caches will need to be changed, considering that updates propagate to DNS servers rather slowly - it takes several hours for a new URL to be totally propagated.

Discussion: It seems that these ideas are definitely interesting, mainly the idea that the client can self-direct to the cache that they need, reducing load on the server-side. To that end, consistent hashing is a perfect match for this type of system. The downside does seem to be the reliance on DNS. It also seems reasonable that they compare this type of system to one that uses a front-end to hash to a certain cache. This one could be updated as needed, but would be subject to different concerns, of course.

Summary:
The paper talks about the Cache Resolver, a distributed web caching system that implements Consistent Hashing to improve performance of the web and reduce latency in serving data to the clients. The system handles locality, shows good load balancing among caches and is fault tolerant.

Problem:
Information distribution through web is prone to delays and failures due to network congestion and overloaded servers. Web caching can make it more efficient and reliable. Single, shared caching system becomes point of failure and also limits the number of users. Distributed caching system can lift the load on the content server and reduce latency.
Existing ideas of using cooperative caches (accessing secondary cache though multicasts) are prone to excess bandwidth consumption, large wait time to contact content server in case of miss or (in case of centralized directories) new points of failure. Also these systems suffered from the problem of duplication of data in caches, leading to lesser number of pages in the cache and lesser cache hits.
The authors implement the idea of Consistent hashing to decide which cache has the required data eliminating any intermediate cache communication.

Contributions:
1. Consistent Hashing requires remapping of only a few resources as a cache is added or deleted from the system and handles the problem of multiple views pretty well.
2. Consistent hashing allows clients to directly contact cache for required data leading to decreased latency (in comparison to sibling, hierachical or directory based caching system).
3. Use of DNS when client browsers didnt support consistent hashing was a clever workaround.
4. Locality: 2-layer hierachy in DNS system to split caches based on geographical regions and serve users based from caches in their region.
5. Load balancing: Map virtual names corresponding to hot pages to a list of IP addresses and round robin between them.
6. Fault tolerance: No single point of failure. Even if one caching server fails, virtual name resolves to alternate IP addresses.

Discussion:
All the tests have been carried with equal capacities of cache. Consistent hashing technique would need to be modified to assign resources for different capacities of cache. One way could be consider two instances of a cache with double capacity on the unit circle to equally distribute load.
In comparison to LARD, Cache resolver is not load aware. Also the front-end in LARD is a single point of failure while the current system is free of single point of failure. Also, I find Cache Resolver more scalable than LARD as LARD strategy is limited by no. of backend servers a front end can handle. Here, clients directly hash to cache servers.

Applicability:
The concept has been widely used in Openstack's Swift and databases like Dynamo and Apache Cassandra and by Akamai.

Summary :

This paper proposes a web caching system that makes effective use of the concept of consistent hashing and aims at reducing the client response time. They provide an insight into how the major desirable properties of fault tolerance and load balance are achieved in this system.

Contributions :

1. Eliminates the use of primary and co-operating caches that involve intercache communication and incur high network bandwidth on a cache miss.
2. Using hashing for caching the web documents is a good idea as it gets rid of all the communication involved in finding out which cache consists of the data required. The client can directly contact the cache that holds the data. However, a basic hash function does not help as it would require re-mapping of the caches each time a caching machine is added and does not serve the purpose.
3. Consistent hashing maps the URL’s to the caches such that the mapping changes only marginally on addition of a new cache. This uses a standard base function that maps both URL’s and caches to a unit circle. A URL is mapped to the first cache whose point is encountered moving clockwise. This balances data well inspite of multiple user views.
4. They also try to achieve uniform distribution of URL's to caches by mapping copies of the cache points to random points on the unit circle.
5. DNS was modified to perform consistent hashing and support the resolution of cache names to IP addresses due to limitations of using the autoconfiguration script on browsers.
6. The tests results got by comparing the performance of the common mode and cache resolver mode indicate far lower miss rates and reduced latency for the cache resolver mode.
7. Locality is ensured by geographically proximity of cache servers to the clients. To handle hot servers by mapping to multiple caches and then reduce mapping adaptive to the load.
8. Fault tolerance : The system functions if the DNS machines function and does not have any single point of failure unlike centralized directory.

Relevance :
This concept has been put to use by Akamai for caching pictures and embedded files which contribute to the major load. So, the mechanism is quite relevant to the WWW. However, their implementation tries to minimize the DNS lookups. Also, the application of consistent hashing has been widely used in the data partitioning components of Amazon Dynamo storage system and Apache Cassandra.

Summary:
This paper addresses the issue of providing a useful caching infrastructure for the web. The authors introduce consistent hashing as a form of distributed caching to avoid traditional issues with distributed caches such as ‘hot-spots’, inter-cache communication, and cache reshuffling upon a server failing or coming online.

Problems:
-Traditional cache schemes an event such as a server failing or coming online causes the hash function to change. This effectively means whenever an event happens the entire distributed cache ‘disappears’. This creates an enormous amount of network traffic as the cache has to re-converge. (fault tolerance)
-Cache misses in hierarchical schemes create inter-cache communication over the network which leads to additional latency for the client. The network can also become the bottleneck if this inter-cache communication scales with the system. (scale)
-Different clients will have differing knowledge about the state of the cache system. In the extreme this can cause all caches to try and hold all information which negates the benefits of a distributed infrastructure. The system needs to function consistently in heterogeneous environment. (consistency)

Contributions:
-The main (and simple) contribution is borrowing the idea of consistent hashing to address the above problems. A simple technique that handles the consistency issue, the scaling issue, and the fault tolerance issue.
-Mapping each actual node to multiple locations on the unit square creating a more even spread of keys being stored and a more even distribution of the keys a node is responsible for when it fails.
-Implementing the hashing functionality at the client node in the browser avoiding the need for clients to have a primary cache they contact for all requests.
-The concept of using virtual names and the DNS system to keep server failure transparent to the client.

Applications to Real Systems:
The consistent hashing web cache system has a great deal of applicability to real world system. Essentially the authors described the basis of a CDN which have seen an explosive amount of growth in use over the last decade (since about 2001) and is now integrated into systems like memcached. The algorithms and techniques have also been adopted as the foundation for other systems such as Chord, which builds upon these concepts to create a distributed hash table.

Summary

With the advent of the World Wide Web there, there was an increasing need for efficient and reliable mechanisms for web traffic. In this paper the authors have implemented the theoretical concept of “Consistent Hashing” in a system to demonstrate its superiority over simple caching as an efferent way to delivering web traffic improving locality, fault tolerance and reducing cache misses. They have done a great job in explaining the theoretical concept of consistent hashing and substantiated their claim with experimental results.

Problem

                At that time single caching was employed to improve the efficiency and reliability of data delivery over the internet. Many users were provided with a single shared caching machine. But if the cache failed the service to these users were interrupted. A single cache could easily get overwhelmed and become a bottleneck. Also the amount of storage was limited and caches could suffer “false misses”. Cooperating cached where proposed to achieve fault tolerance, scalability and aggregation of larger number of requests to improve hit rates. If the primary cache misses, instead of going directly to the contact server it tries to locate the requested resources from other cooperating caches by either sending a multicast or UDP broadcasts or by using directories. These methods consumed excess bandwidth, slowed down performance, introduced a new point of failure and data was duplicated among caches. Another problem was this architecture lacked the elasticity to include or remove new cache/servers or to accommodate hot pages.

Contributions

·         Implementing consistent hashing was simple yet very powerful.

o   Consistent hashing avoided disproportionally loaded caches by its random distribution nature.  No one cache was responsible for a disproportional amount of pages.

o   Expensive inter-cache communication/broadcasting was no longer need as the client could themselves know which cache had the required data.

o   Adding new caches had a minimal effect; i.e. only a few urls changes, most of the cache items persist as hits in the modified system.

o   Locality was improved since consistent hashing (on the DNS server) ensured users are always served by the caches in their physically local regions.

o   Hot pages were effectively handled since virtual names mapped to hot servers were spread (then slowly removed) from all the caches in the region till a measurable balance was achieved.

o   Fault tolerance was effectively established since the physical IP addresses are abstracted from the user through virtual names.

·         The ideas of implementing the consistent hashing on the DNS server was a novel, simple and effective idea since DNS is still an important part of web traffic routing.

Applicability

                Consistent hashing is utilized in many key-value stores and distributed database architectures. Systems like Cassandra, Amazon’s Dynamo, Akami still are currently using concepts introduced in this paper. Hence the ideas introduced in this paper are very application in modern distributed systems and internet.

Summary: This paper evaluated using consistent hashing in web caching. Consistent hashing is a hashing method which can support dynamically adding or removing cache servers. Experiments showed the new caching method can achieve great performance improvements.

Problem:
(1) Using a single centralized cache server has two major drawbacks. First, the single cache server could potentially become a single node failure or bottleneck. Second, since all requests were forward to one cache server, whose storage was pretty limited, the cache efficiency was poor.
(2) Prior to this paper a distributed caching mechanism was proposed using a two level caching. There was a primary cache server to which every browser would try to connect first. When it reported a miss, the browser would then try a bunch of secondary cache servers. The browser would not try the back-end server until all secondary server reported cache miss. This would incur high latency. Also this approach would consume a lot of bandwidth for cache server communications.

Contributions:
(1) Improved the locality of contents by using hashing. The idea of hashing web urls made similar contents aggregated to the same cache server (or a few cache servers).
(2) Consistent hashing made the addition of new cache servers or (the loss of existing cache servers) rather cheap. Without consistent hashing, when a new server is added, every mapping from url to cache server would have changed, consequently every cache server would need to serve all web pages, which made them very inefficient. With consistent hashing, only a small fraction of mappings would change.

Applicability:
In order to make this method applicable, two issues need to be addressed.
(1) Handling hot pages. Since each page is mapped to a single cache server, hot pages could overwhelm its cache servers. In the end of the paper the authors proposed to associate a set of cache servers to hot pages, but it was too complicated needed more research.
(2) The proposed cache mechanism required support from browsers. This was not generally good because how the website handled cache should be hidden from users.

Summary:
This paper provides a new Web caching strategy based on consistent hashing as well as some experiments to verify the performance of this strategy.

Problem:
The important issue in many caching systems is how to decide what is cached where at any given time. Some different kinds of web caches are proposed. But they all have some deficiencies. The cooperating caches have a slow turn around time when there is a miss in the primary cache. Also broadcasting would consume excess bandwidth with bandwidth queries. Centralized directory cache system would become the bottleneck of the whole system. Duplicate cache data are another problem that these kinds of cache system.

Contributions:
The author provide a new cache system based on consistent hashing. This system uses consistent hash to partition the URL and cache, which also eliminates the inter-cache communication on a cache miss. The clients, specifically the user browsers, are designed to be responsible for choosing the cache node to communicate. The choosing job is locally computational so is fast. Also, it reduces the cache miss rate since one page only suffers only one cache miss.
The consistent hashing also ensures that all clients would have the same view of partition information and only a small amount of cache entries would be migrate when new nodes are added.
The client browser is not powerful enough to support embedding automatically using consistent hashing. Thus, the author moves this part of job to an intermediate DNS server. The client browser map the URL to 1000 virtual names and the DNS server then map these 1000 names to the existing back-end cache nodes.

Applicability
I think, consistent hashing is still widely used in many distributed system today and especially useful for loading balancing, like in MemcacheD, NoSQL database and so on. 2-level DNS server performs like the data pipeline technology today that the first level dispatches request to each region and the second one chooses the target in that region.

Limitation:
First, it doesn’t consider the cache hit rate as the LARD algorithm does. For most static web sites and dynamic web sites, the cache hit rate is still very important. Second, one advantage of the consistent hashing is each client would have a consistent view of the partition. So the author should give some experiments to show when cache nodes are added and removed frequently fromt the cache system, what is the performance of the whole system. Third, in the extension section, the author proposes one way to determine which pages are hot. This could determine the initial size of node pool for each page, but has no effect if the access pattern varies greatly later in the future. In the end, I really don’t think it is a good idea to integrate the consistent hashing into the users’ browsers. This part should be more transparent to the user. Forcing user downloading external script might cause security issues e.g. malicious user might tamper with this script, control user the machine and attack the back-end servers via this victim.

Summary
With the size of the internet growing, there is a need to introduce caching closer to clients to prevent a large volume of traffic crossing the network and swamping source servers that serve content. By introducing caching, both efficiency and reliability of the web goes up. Having understood that monolithic caching is impractical due to bottlenecks and single point of failure created, the challenge was getting a distributed caching architecture that does not have too much network overhead, that is flexible to change in caching sites and also one that scales well. Enter consistent hashing.

Challenges

• Dealing with scale : The system must scale as the number of caching sites increases.
• Tolerance to failure : Caching nodes can fail, the system should deal with failure, without affecting all components of it, i.e. failure should be isolated as much as possible.
• Flexibility for growth : Adding caching sites should be as easy as caching sites dropping out, and must take on current load without affecting the rest of the system in a big way.
• Robust to differing views : Clients could see differing views of the caching system, due to network latencies as well as sites getting dropped/added. Caching should account for this and prevent clients from spreading out requests so much that all sites cache the same content effectively bringing down the overall effective cache size.
• Do all of this without overhead : Limit the amount of meta information that needs to be sent over the network to keep this distribution state consistent and known.

Contributions

• Consistent hashing provides the ability to achieve these three properties:-
  • Balance : The server hash buckets would each consume the pages that hash ahead of it on the circle. With a good hash function, this would imply that there would be a good distribution of URLs amongst caching sites. This is further assisted by the fact that they add copies of the caching sites to the circle to limit the possibility of unfair distribution by the hash on the original sites (this is pretty simple, yet awesome in its implication).
  • Load : As the choice of pages that map onto caching points is through a pseudo random hash function, this would imply that the load would not be concentrated on any one caching site. This load distribution is also aided by the fact that ‘hot’ pages will be replicated across caching sites helping balance out the load even more by rotating requests through the sites.
  • Spread : Different clients having different views of the system will not cause an infinite spread of a particular URL across all caching sites. The effects of this spread will be limited to the view that is farthest along in the circle, and will not affect the rest of the system, thereby confining this spread to only the ‘close’ nodes.

• Flexibility to addition or removal/failure of caching sites, and their confined impact is also a pretty nice feature to have. Addition impacts only the site being added with load being taken off the next site on the circle. Failure would cause the distribution of the load across the sites.


• Indirection through virtual names provides flexibility for distribution or re-distribution of a group or URLs that hash onto a virtual name.

Flaws
Choice of DNS as a measure of hotness is incorrect. Cached DNS records, using which several requests get fired could make a page hot without the DNS ever being aware that something like this is happening. DNS would only be able to identify hotness created across clients, but not within clients that have cached entries.

Discussion
Given how nicely DNS fits into locating the consistent hashing system, I don’t quite understand why the authors initially were considering the browser as a choice for locating the system. They indicate that there are certain technical limitations in using the browser, but even architecturally I don’t understand why that would be a primary choice of consideration to the authors.

Summary
This paper borrows from the theory world the concept of consistent hashing and uses it to do efficient and reliable caching of web content. This technique results in reducing the number of cache misses and avoids inter-cache communication which results in reducing response time.

Problem
Other systems implementing web caching use a technique called “cooperating caches” to improve fault tolerance, scalability and aggregation of large number of requests. If there is a cache miss in one of these, they either multicast or UDP broadcast. This causes problems like more network traffic and also higher waiting time to hear from all the servers. The authors of this paper wanted to solve this problem by eliminating inter-cache communication.
Another problem that the authors were trying to solve was the duplication of data among caches which would waste network bandwidth and also waste time in copying data to another cache.

Contributions
1. The major contribution of the paper was that with a simple technique of consistent hashing, the authors solved all the above problems and a lot of other requirements. Consistent hashing also ensures good load balancing and ensures that there is data locality on cached servers which results in a high cache hit rate.
2. I liked the idea of implementing this on the DNS because that’s the most reasonable solution when compared to implementing this on the browsers. The authors also pointed out the reasons as to why implementing on the browser would be bad.
3. I also liked the idea of using virtual cache names for the actual cached-servers because this maintains consistency of the list of cache servers on the client’s side. The technique also made the system very scalable without the problems that a normal hashing technique would have resulted in.
4. The technique of ensuring uniform distribution of URLs to caches by mapping several copies of each cache to random points was a very nice trick. Although not mentioned, this can be easily extended to something like using a heterogenous cache system where one cache is more powerful and we want to send more requests to it, it’s enough to just make multiple copies of it! Simple, yet efficient!

Limitation
Although the system was brilliant, I think there is one limitation in how they handled hot content. Maybe this was not relevant back when the system was designed though. The system measured hot content by the number of requests the DNS server was receiving, which is not a good measure. This is because, when a request to a web server is made for the first time, its ip address is cached in the browser and so the request might not actually reach the DNS server from then on. So, they caches might still be receiving a lot of load without the DNS realizing it. It would probably be better for the caches to directly measure load.

Applicability
This method is very applicable to current systems for good load balancing. In fact, systems like Cassandra, Dynamo etc make use of consistent hashing for high performance. Which directly translates to key-value stores highly benefiting from this technique. It can also be applied for efficient web caching, reducing cache miss rates and network traffic which will eventually improve the performance of the web.

Summary:
The authors have proposed a web caching scheme based on the idea of consistent hashing in order to improve the content delivery performance in a dynamic environment.

Problem:
Overloaded servers and congested networks play key roles in delaying the delivery of data.Caching is required in order to minimize latency and increase reliability. Current caching solutions have the following drawbacks :

Hierarchical cache configuration scheme:
* Involves an additional hop (client->primary cache->sec cache) which contributes to latency.
* Primary cache misses lead to broadcast towards secondary caches which could lead to more congestion.
*Detecting a cache miss is delayed since the primary cache waits for all the secondary caches to respond before responding to the client.
Directory based schemes :
*Not reliable since it creates new points of failure in the system.
*Standard hashing strategies:
*Rehashing is a problem, lot of content in the browsers needs to be recomputed again and hence flushed from the browsers.
* Does not adapt well to dynamically changing set of caches.
Content duplication could be higher.

Contributions:
* Consistent hashing methodology is employed to map the cache to the URLs. Its key advantage being the number of entries to be rehashed is less when the hash table size changes.
* This is very suitable for the dynamically changing system of caches.
* The consistent hashing was implemented in DNS rather than the browsers thus aiding in flexibility.
* Hit rates were still preserved since when a new cache is added/removed from the system, only a few URLs change.
* Randomization [use of hash function] of the cache and URL distribution aided in good distribution of the resources among the caches.
* Failures are transparent to the users since browsers are aware of only the virtual names of the caches and not the physical names.
* There is no single point of failure in the system.

Shortcoming:
The logic to use DNS to detect a “hot” page might not work well in all scenarios. For example if clients A,B and C request a page X from within the same network, A’s request might lead to the page getting cached, and hence B and C might not even be counted as separate requests.

Applicability:
Today’s internet is constantly changing. A caching methodology which works well in a dynamic environment will go a long way in improving the performance of content delivery methods.

Summary:

The authors demonstrate how consistent hashing can be used to implement scalable caching for the world wide web. This method limits the penalty associated with cache migration, improves load balancing, reliability and reduces inter-cache server traffic.

Problem:

The current method for determining where particular content is cached involves the cache servers communicating with each other (multicast), and directory based schemes. This approach does not scale with the number of servers since it involves increased communication and deteriorates network performance, apart from introducing latency in client requests.

Contributions:

- Consistent hashing lowers the penalty associated with set of cache servers changing.
- Consistent hashing allows clients with slightly differing cache views to perform fairly well.
- Transferring some of the cache location work to clients lowers the work on the server.
- Resilient to cache server failures using the DNS abstraction that maps to multiple servers.
- Dynamic load balancing for hot pages.

Limitations:

- Using DNS virtual name hit metrics might not be an accurate measure of load because DNS might be cached.
- Requires users to choose their Geographic region. A hassle to do this across browsers and while travelling.
- A browser is not the only way to access the web. It will require modifications to all clients to perform effectively.
- Security issue: If a browser generates a virtual name that is a real DNS name, then the user will be redirected to another page.

Applications:

- We see some of the concepts discussed in the paper in DDNS and DNS Round robin
- Consistent hashing has been applied to domains other than web page traffic.
- Elasticity in cloud computing has basic ideas from varying the set of IP addresses in response to virtual name for hot pages.

Summary: by using Consistent Hashing, this systems distributes
resources randomly on caches, and lets the client find the correct
caches using a hash function. Consistent Hashing allows new caches to be
added without having to remap all the resources.:

Problem: many requests are made to servers which may become
overloaded or fail. A solution is to use caches, which raises the
problems: where do you you store what data; how do you know what data is
stored where; what do you do if there's a cache miss? Furthermore, how do
include the client in the design of the system without modifying all the
existing clients?

Contributions:
- Compared to a similar existing scheme, this could do a lookup in
constant time.
- Fault tolerance: DNS hides the underlying servers so that they can
easily be swapped out. In addition, there is no single point of
failure since all the caches provide the same function.
- The boundary of the system is moved out and into the clients: clients
are responsible for resolving the location the cache.
- Shows how an existing system, DNS, can be harnessed to provide a
resolution function for this application.

Applicability:
Unlike other caching systems, this one relies on the clients having a
certain knowledge of the caches. Conveniently, JS blurs the distinction
between system and client, which allows the system to implement resource
resolution in the client. This system is not transparent in the sense
that the client has to be modified to use the caches. Of course, it
would also be possible to put a front-end between the caches and the
client.
The tests look promising, even though the datasets they used
(theory.lcs.mit.edu) may not apply to other production environments.
They came up with a solution to a systems problem essentially using a
hashing function with some special properties -- a neat result!

Web Caching with Consistent Hashing

Summary:
The paper provides an excellent way of using the consistent hashing technique in solving the problems that were faced in web caching. It also shows how their implementation has advantages like locality, load balancing and fault tolerance.

Problems:
The problem the authors were trying to solve are the following:
1. To get rid of inter cache communication between primary cache and the coordinating caches as it was causing poor performance in fetching a particular content. One of the problem for example, is that the primary cache should wait for all coordinating caches to respond before it can contact the content server.
2. To eliminate the dupication of data among multiple caches as any cache could be queried for any data which it would keep it in it's cache once the request is served.
3. To remove the drawback of standard hashing when it was applied to caching systems. For example, when a new cache is added, the entire content needed to be rehashed.
4. To minimize the effect of inconsistency between each system's "view" (the set of caches that a machine is aware about)

Solution:
The solution proposed for the problems stated was to make the user's browser to directly contact the one cache that should contain the content requested by the user. They used consistent hashing to help the browsers to maintain a hash function to map the URLs to the caches where the content was stored.

Contributions:
1. The use of consistent hashing for solving the problem of elasticity(adding or removing caches) that standard hash functions previously had in Web Caching. This was a very important contribution as it solved the problem of flushing all the caches whenever a new cache was added or removed and instead changing only a few URLs. This also made sure that even though there were many caches, only a few were responsible for any one item.
2. The way of making the browser(with the help of DNS) to decide which cache to contact helped in removing the single point of failure of using a frontend (as was the case with LARD).
3. The DNS based design to resolve the virtual cache names generated by the Javascript in the user's browser to the actual IP addresses of the caches.
4. The reduction in network traffic by having only one cache to serve a particular content. This also reduced the cache miss rate to one URL per page.
5. Splitting the DNS into a two-layer hierarchy to make sure that the users are served by caches that are geographically close to them. Also providing load balancing in case of hotspots using a "set of caches" and fault tolerance by avoiding the single points of failure are also good contributions of their work.

Relevance:
1. This paper should have created a great impact since the concepts discussed are the backbone of Content Delivery Networks (CDN) infrastructure. If a company wants to scale their websites to multiple users, they can use the services of comapnies like Akamai, which is basically a CDN service provider. Then users from various parts of the world can access an Akamai server to get the content that they were trying to get from the company.
2. The paper's effect can also be seen in the most widely used peer-to-peer protocols like bit torrents which makes use of the resources distributed across the internet to achive some useful tasks.
3. This paper's influence could also be seen in the area of distributed databases.

summary
Consistent hashing maps urls and caches to points on a unit circle. It needs minimal change even if the range of the function changes. The authors have used this technique to make distributed web caching system. They implemented this content based caching system in the followin manner -- the javascript sent with the web-page will hash the url and form a new virtual url which the dns will resolve and redirect to the correct cache. The JavaScript can also modify the url based on the location to get benefit from the locality. Hot spots are served by adding set of servers to a single point on the unit circle.

Problem
Increasing web traffic forces the use of web caching to improve service of web content. But simple caching suffers severly from multiple view of users about the world wide web resulting in duplicate entries in the most of the caches and the system is subject to too many changes against any minor change in the caching node addition or remove. The authors try to address this issue of existing caching mechanism using consistent hashing.

Contribution

• Use of consistent hashing makes the addition and deletion of node in the cluster elastic with minimal changes in the cache entries of the other nodes.
• This system deals with issues like hot-spot (by adding new nodes) or fault tolerance (no single point of failure) very easily.
• Even it can exploit geographical locality of the cahces in servince content for globally distributed clients.
• use of virtual caches and mapping a single cache to 1000 random points on the circle to normalize the expected load is a smart idea

Issues
As every cache is entitled to serve any url that is asked for, a crooked client can keep asking every server for every url and force a lot of cahce misses. Also this arises because DNS routes the request directly to the caches instead of a front end.

Applicability
Their design of web-caching using consistent hashing is used extensively even in recent times. Apache Cassandra, Riak, Skylable, Amazon's storage system Dynamo and many more uses this architecture (more or less).

Summary:
In this paper, authors introduce Cache Resolver System which implements a new low-overhead caching technique called consistent hashing. The aim of this web caching system is to eliminate inter-server communication on cache miss, balance load among cache servers, easily adapt to change in set of available servers, improve reliability by removing single-point failures, and increase cache hit rate.

Problem:
With the consistent hashing approach, authors have provided solution to the problems with then available state-of-the-art distributed caching systems which were either hierarchical or directory based. These systems has one or many of these problems:
- Required flooding of messages to other server in case of miss, resulting in network congestion.
- Increased latency as these waited for N-Acks in case of second level cache miss.
- Multiple copy of data, increased capacity misses.
- Directory based system had single point of failure.

Besides providing solution to the above, authors have tried to come up with a system which is easily scalable by requiring very minimal re-distribution of data across cache servers when a server is added or removed.

Contributions:
The major contribution of the paper is adoption of "Consistent Hashing" approach for distributed web caching. With consistent hashing approach, it enables distribution of equal share of content on cache servers, leading to good load balancing and higher cache hit rate. Besides this, it provide several other advantages:
- No multicast of messages among cache servers, so no network congestion.
- There is only one miss per URL page, so no latency increase due to waiting for ACKs from other cache servers.
- No directory consultation/invalidation, so no maintenance overhead and no single point of failure.
- Uniform mapping of pages to caching and one page gets mapped to only few caches.
- And most important advantage is how it handles change in the number of cache servers gracefully. In contrast to normal mod based hash function which changes mapping completely, consistent hashing require remapping of only very small set of pages.

Another major contribution is eliminating inter-cache communication on a miss by letting clients decide for themselves which cache has required data. Authors have proposed idea of having the client browsers decide the cache servers by using hash functions, but due to lack of capability in browsers they are using DNS approach for cache server resolution which I think is a better approach.

Limitations:
I think the idea of adding capability to browsers to choose cache server is bad because if selection logic is at the client side, malicious clients can overwhelm a particular cache server and bring it down. Authors went with DNS approach, which I think is a good decision.

Another issue I think is scalability of the system to heterogeneous caches where each cache can handle different load. Approaches for load balancing in this scenario must be evaluated.

Applicability:
The idea's in this paper is still applicable to today's proxy caching scenario. Web caching is being done by proxy servers (and CDNs). Also I think the approach for using DNS to resolve cache servers is being used by current age content distribution networks to redirect request geographically to nearest servers.

Summary:
This paper discussed the use of consistent hashing to effectively utilize the cache in cache servers.

Description:
Traditional caching mechanisms such as single shared caching and cooperative caching have several drawbacks. For eg., single cache becomes single point of bottleneck and failure. In Cooperative caching, when a cache miss occur by primary cache, it send it to all the other secondary caches and wait for their response. This cause unnecessary usage of network bandwidth and the use of cache space in all the system of that particular request.

Cache Resolver uses consistent hashing in which each url and caches are hashed and mapped to a circular ring. Then a url is assigned to a cache which is close to it on that ring in clockwise direction. This way, even when caches are added or removed from the system, only few of the urls have to be remapped rather than mapping all of them as was the case with normal hashing. This scheme also perform well for multiple views which is required for scalability where we want more than one server to cache hot pages. Moreover, each client can directly compute the location of a url by hashing it and contact that cache. This reduces latency and eliminate wastage of network bandwidth in inter cache communication.

Contribution
- The idea of using consistent hashing for web caching is a very nice technique which solve many issues related to scalability, fault tolerance and load balancing. It makes it easier to handle cache server in a constantly changing environment.
- Also, the clients directly compute the location of caches which help in reducing the load on cache servers by delegating it to individual client machines. This techniques is very common in today’s web servers where they delegate resource location scripts to the client machines. However, the designer couldn’t implement in client browser. But I think today’s web browser can handle these complexities.
- Using DNS for consistent hashing was a nice technique to overcome client browser limitation. However now DNS is a single point of failure for this whole setup.

Applicability:
Consistent hashing is being widely used in today’s distributed system and I think it is still applicable in caching mechanism. Large websites wants data to be as close to user machine as possible so that it doesn’t take much time. Caching and replication are the two major strategies for reducing latency by placing them close to user. And I believe consistent hashing is being used to uniformly place them in the system.

Summary:

The paper presents the basic concepts and implementation of Consistent Hashing, a technique used to determine which particular cache(among a set of cooperative Web caches) should the user send request to in order to have least latency in receiving the required data. This request either gets a direct hit on the chosen cache or will have to be served by the content server directly(without the cache having to interact with the other cooperative caches).

Problem:

Existing solutions for efficient cache coordination have the following problems:

• Broadcast/Multicast query based schemes: High bandwidth utilization and excessive delay to determine if no cache has the requested file.
• Directory based schemes: Centralized directory results in a single point of failure and shared directory generates huge inter-cache messages.

Consistent Hashing addresses these drawbacks and is aimed at:

• Eliminating inter-cache communication even while having cache cooperation and making the caching fault-tolerant.
• Having a good balance of load among the caches even though clients may have different views of the caches(due to cache proximity, addition/removal).
• Avoiding having copies of the content on all the caches.

Contributions:

Following are the steps involved in consistent hashing:

• Compute a base hash function(choose a function which provides proper random distribution) which maps URL's and caches to a number range - in turn they are mapped to a unit circle. Use multiple copies of the caches to ensure even distribution.
• Assign each URL to the first cache clockwise cache mapped after the URL.
• On cache addition/removal, re-assign only the portion of the URL's to new cache.
• Even with multiple views of users, each cached file is stored by only a subset of caches, because files are stored only on caches with close proximity on the unit circle.

Cache resolver implementation:

• Components include: a user side JavaScript, specialized DNS resolvers and the caches(whose mapping values are stored in a binary tree for lookup).
• Client javascript component maps the request URL string to a range of 1000 virtual cache names.
• The virtual cache names are then resolved by a DNS server which returns a list of resolved cache IP addresses.
• The paper also proposes few interesting extensions like consideration of geographical proximity, popularity of requests which make the system achieve a better load balance and fault tolerance.

Applicability:

Consistent Hashing is a widely researched technique and is currently being implemented by many cloud services including Amazon's Dynamo key-value store, OpenStack Swift. Subsequent research work like Chord provide more insight about the efficiency of Consistent Hashing using other data structures like random trees, finger table, successor and predecessor lists. Although I know about applications in other areas, I do not know of any direct applications in Web Caching.

Summary
- Implementation and corroboration of a distributed web caching system which improves the usage of Caches.
- This implementation would improve the efficiency and reliability of the data transfer over the internet.

Problem to solve
- Reduction of effect on data delivery due to network congestion and server swamping. Leads to rejecting a certain request or processing it very slowly.
- Improve the Cache hit rate and reduce requests to source server. Cooperating caches was explored to achieve this but it leads to duplication of data among caches, increased bandwidth usage and has increased cache misses.
- In the implementation addition or removal of a certain cache remaps the URL’s to a different caches. This would increase the cache misses as the data isn't in the new cache. Also this would cause a load imbalance bringing forth the need for a consistent hash in a way that each machine gets a similar load.
- Implementation of browsers level consistent hashing. First try was usage of auto configuration but it is limited because a change in number of caches could lead to an incorrect mapping.

Contributions
- The proposed distributed Web caching system named Cache Resolver removes communication among caches reducing bandwidth usage. This system has the client decide which cache to access among a dynamically changing set. Thus decreasing the network usage. Reduction in miss rate is seen as redundant copies are avoided.
- A hash function which is consistent even among dynamically changing views equalizing loads among machines. This is done by representing Caches and URL’s on a unit circle. From each URL move clockwise and assign the first Cache it encounters. And with several copies of a cache randomly placed on the circle provides with a more uniform distribution of the URLS’s.
- In order to overcome the issues of auto configuration DNS with consistent hashing support was used.
- The proposed system Cache Resolver was compared with other existing web caching systems to corroborate its efficiency and reliability over the latter.
- Provides with a high level of fault tolerance. The system does not have any one system which to perform a critical tasks thus safe guarding it from breaking unlike the mentioned CRISP system.

Overall the implementation utilizes caches efficiently, improves performance and reliability.

Summary
- Implementation and corroboration of a distributed web caching system which improves the usage of Caches.
- This implementation would improve the efficiency and reliability of the data transfer over the internet.

Problem to solve
- Reduction of effect on data delivery due to network congestion and server swamping. Leads to rejecting a certain request or processing it very slowly.
- Improve the Cache hit rate and reduce requests to source server. Cooperating caches was explored to achieve this but it leads to duplication of data among caches, increased bandwidth usage and has increased cache misses.
- In the implementation addition or removal of a certain cache remaps the URL’s to a different caches. This would increase the cache misses as the data isn't in the new cache. Also this would cause a load imbalance bringing forth the need for a consistent hash in a way that each machine gets a similar load.
- Implementation of browsers level consistent hashing. First try was usage of auto configuration but it is limited because a change in number of caches could lead to an incorrect mapping.

Contributions
- The proposed distributed Web caching system named Cache Resolver removes communication among caches reducing bandwidth usage. This system has the client decide which cache to access among a dynamically changing set. Thus decreasing the network usage. Reduction in miss rate is seen as redundant copies are avoided.
- A hash function which is consistent even among dynamically changing views equalizing loads among machines. This is done by representing Caches and URL’s on a unit circle. From each URL move clockwise and assign the first Cache it encounters. And with several copies of a cache randomly placed on the circle provides with a more uniform distribution of the URLS’s.
- In order to overcome the issues of auto configuration DNS with consistent hashing support was used.
- The proposed system Cache Resolver was compared with other existing web caching systems to corroborate its efficiency and reliability over the latter.
- Provides with a high level of fault tolerance. The system does not have any one system which to perform a critical tasks thus safe guarding it from breaking unlike the mentioned CRISP system.

Overall the implementation utilizes caches efficiently, improves performance and reliability.

Summary
- Implementation and corroboration of a distributed web caching system which improves the usage of Caches.
- This implementation would improve the efficiency and reliability of the data transfer over the internet.

Problem to solve
- Reduction of effect on data delivery due to network congestion and server swamping. Leads to rejecting a certain request or processing it very slowly.
- Improve the Cache hit rate and reduce requests to source server. Cooperating caches was explored to achieve this but it leads to duplication of data among caches, increased bandwidth usage and has increased cache misses.
- In the implementation addition or removal of a certain cache remaps the URL’s to a different caches. This would increase the cache misses as the data isn't in the new cache. Also this would cause a load imbalance bringing forth the need for a consistent hash in a way that each machine gets a similar load.
- Implementation of browsers level consistent hashing. First try was usage of auto configuration but it is limited because a change in number of caches could lead to an incorrect mapping.

Contributions
- The proposed distributed Web caching system named Cache Resolver removes communication among caches reducing bandwidth usage. This system has the client decide which cache to access among a dynamically changing set. Thus decreasing the network usage. Reduction in miss rate is seen as redundant copies are avoided.
- A hash function which is consistent even among dynamically changing views equalizing loads among machines. This is done by representing Caches and URL’s on a unit circle. From each URL move clockwise and assign the first Cache it encounters. And with several copies of a cache randomly placed on the circle provides with a more uniform distribution of the URLS’s.
- In order to overcome the issues of auto configuration DNS with consistent hashing support was used.
- The proposed system Cache Resolver was compared with other existing web caching systems to corroborate its efficiency and reliability over the latter.
- Provides with a high level of fault tolerance. The system does not have any one system which to perform a critical tasks thus safe guarding it from breaking unlike the mentioned CRISP system.

Overall the implementation utilizes caches efficiently, improves performance and reliability.

Summary: This paper proposes a new web caching strategy based on consistent hashing as an alternative to multicast and directory schemes, with additional advantages in load balancing and fault tolerance.

Problem: Systems of several cooperating caches have been proposed to achieve fault tolerance, scalability and aggregation of large numbers of requests. The request will first go to primary caches, then cooperating caches if primary cache misses, then content server if cooperating caches misses. Different strategies can be used to locate data in the case of a primary cache miss. Strategies such as multicast and directory will cause inter-cache communication, new points of failure and data duplication.

Contribution: This paper proposes Cache Resolver, a distributed web caching system using consistent hashing with no inter-cache communication on a miss.
(1) A machine can locally compute exactly which cache should contain a given object. Thus large amount of network usage and communication can be reduced.
(2) Consistent hashing can map items consistently. Consistent hashing map each URL and every cache to a point on a unit circle. Each URL is assigned to the first cache whose point it encounters moving clockwise. Most of the cached items persist as hits in a modified system. It has good properties including balance, load and spread.
(3) The system uses the DNS to solve the flexiblity problem of current browsers. The consistent hashing in DNS can be propagated to browsers during name resolution.
(4) The system ensures that users are served by the caches physically close by using a two-layer hierarchy.
(5) Resolving hot pages. The system will slowly substract IP address mapped to virtual name and reach a balance.
(6) Fault tolerance.

Application: The idea of this paper is very simple, but smart and practical. But spreading all the virtual names mapped to a hot server to all of the caches in the region may not be a good idea.The subtracting process can take long time to converge and large amount of resources will be assumed. Can we borrow the idea from "locality-aware request distribution in cluster-based network servers", make the dns server record connection numbers of every ip address and use it as a metric for load balancing?

Paper Summary:
This paper introduces consistent hashing and implements a system (Cache Resolver) to make web caching faster and more reliable.
Problem:
Web caching is important since it reduces network traffic and the load on the original content servers. It thus allows for more scalability while also reducing latency. Existing techniques for caching however, were based on co-operative caches and were inefficient. The clients typically had a primary cache which would get the request initially and the primary cache would further multicast the request to secondary caches upon a miss. This consumed bandwidth and also the primary cache would have to wait for responses from all the other caches before determining to contact the content server in case of a miss everywhere. Another approach was to use directories which along with consuming bandwidth added a new point of failure to the system.
Proposed solution:
The key idea is to use consistent hashing to let the users (browsers) determine themselves which cache to use for any given URL. The way this works is that the hash function maps a given URL into a point on a unit circle. The caches themselves are mapped as points on the unit circle. The browser determines which cache to use by finding the closest cache on the circle in clockwise direction. Note that this technique increases the effective cache size of the whole system.
They perform several optimizations such as mapping several copies of each cache onto the circle at random points to obtain a more uniform distribution of URLs to caches. Also, adding a new cache to the system will only ‘steal’ a few URLs from just one another cache and since the URLs are random on the circle, only a few will be stolen effectively. Thus, it also addresses the issue of multiple views which was prevalent in the co-operative cache based systems. The system also provides fault tolerance, method for dealing with hot pages and taking advantage of geographical location of caches etc. which I do not cover in this review for brevity.
Implementation:
Due to browser limitations, the system uses DNS to perform consistent hashing. A javascript performs a standard hash of the input URL to output virtual cache names. These virtual cache names are then mapped to actual cache IP addresses by consistent hashing at the DNS servers and sent back to the users. The evaluation shows that the Cache Resolver systems has much better performance in terms of hit rate than the other methods. However, the evaluation could have been more involved and shown how this system affects latency and network load and they should have also included the effects of other components of the system such as DNS.
Finally, consistent hashing is a key idea that is in wide use today, e.g. Swift object store (OpenStack) and many others. The authors have proposed an elegant way of using consistent hashing to provide a better web caching system that is faster, more reliable and reduces network load as well.