Can WWW caches help save the Internet?

by Duane Wessels

Have you ever experienced unbearable slowness while surfing the Web? Current estimates are that the Web accounts for 40-50% of all Internet traffic. Exponential growth continues, both in the number of users and the amount of traffic. With trends like these, it is almost certain to get worse before it gets much better.

A number of different factors can make Web browsing slow. Internet circuits in many places are running at full capacity and often suffer from congestion. Since a typical Web transaction involves a handful of service providers, any congested link along the way can cause the entire connection to be slow. It might be your local provider, a backbone operator, or the remote server's provider. Or it may be that the remote server machine is just too busy. When Web sites suddenly become popular, the server systems are often unprepared to handle the load. It is also somewhat appropriate to blame the HyperText Transfer Protocol (HTTP) because the current version transfers only one request per connection.

What can be done to speed things up? Certainly one option is to increase bandwidth in congested spots. In some cases the congestion may be outside your area of influence. Also it might simply be too expensive to buy more capacity. If server load is the problem, a solution is to buy bigger and faster hardware. However, this can only be taken so far, then multiple machines will be required (as in the case of Netscape).

Daily Dilbert

Before the next solution is presented, let us look further at why the Web is consuming so much bandwidth. The standard Internet client-server model is that each client (browser) connects directly to each server, makes some request and reads the reply. It is easy to see how wasteful this is when you think about how many times the daily Dilbert cartoon is transmitted to browsers at NCAR, or the University of Colorado, or even worse, overseas to the United Kingdom. Doesn't it seem absurd that the exact same file gets sent on the same wires tens or hundreds or thousands of times per day? It would make more sense if the Dilbert cartoon was downloaded only once to your site and then all users could somehow share the local copy.

What's it all about, Alfie?

This is what replication and caching are all about.

Replication, also known as mirroring, usually involves copying an entire archive or subdirectory to a specific mirror site. The big problem with replication is that users must be made aware of the available sites and then choose one. Also, some files may be copied to the mirror site but then never accessed. Caching, on the other hand, is entirely driven by client demand. A Web cache keeps copies of objects which have been downloaded through it. If a future request can be found in the cache, there will be no need to connect to the source server again.

The goals of Web caching are to improve response time for users, and to reduce wide-area Internet bandwidth usage. In general, the overall throughput of an Internet connection is related to the number of hops on the path. More hops usually means a slower connection. By locating a cache close to the clients (e.g. on a campus LAN), the throughput will be much higher for requests served from the cache (``hits''). In places where Internet usage is billed as a flat-rate fee, there is often little concern for reducing wide-area traffic. However, in countries where bandwidth is very expensive, or billed on a per-byte basis, the incentive is very high.

Fortunately, Web caching has been easy to implement because the designers of HTTP recognized the need to support proxy requests. A proxy is an application which listens for requests coming from clients and then forwards those requests to the servers. This provides an ideal way to implement caching. Since the proxy application is already relaying requests and replies between clients and servers, it might just as well save copies of the objects that go by. Browsers must be configured (often manually) to use a cache or proxy instead of making direct connections. Not all objects can be saved by the cache. Usually query results, or any URLs containing ``cgi-bin'' do not get saved.

Cache this!

Caching offers a number of advantages, two of which have already been mentioned: improved response time and reduced traffic. Another benefit is that it reduces the load on remote servers since the server gets fewer accesses. A cache also provides some level of robustness in the event of external network failures.

There are also some disadvantages to caching. Since caching reduces the number of requests made to the origin server, the server can not log a truly accurate access count. This seems to be a sore spot with quite a few information providers--so much that they make an effort to thwart caching.

Another disadvantage is that the use of a cache may not be transparent to the users. Different error messages may appear than would otherwise. One of the hardest problems is maintaining cache consistency. This means trying to make sure that users always receive up-to-date versions of the pages they visit. Because HTTP servers very rarely provide time-to-live information in the replies, the cache most often selects a TTL for each object. This means there is going to be a finite possibility that users will see some stale data.

One other disadvantage is that the cache may be a single point-of-failure. This is really only a problem with older Web browsers; the newer versions can deal with proxy failures.

Reeeealy effective

It is fairly obvious that caching can achieve the goals of faster response time and lower bandwidth usage. But in order for caching to be really effective, there must be a sufficient number of users accessing the cache. Significant benefits will only be realized when there are many users so there is some overlap in the Web pages which get visited. Roughly speaking, 50 users should result in a cache hit rate of approximately 25%. The maximum hit rates observed in practice are around the 50-60% range.

Another measure of effectiveness is in terms of cost. Do the reductions in bandwidth justify the cost of installing and operating a local cache? Here in the U.S., probably not. The use of caches by U.S. sites is relatively rare, unless a proxy is needed anyway for firewall security. Outside the U.S., however caching is essentially required. In fact, many foreign providers block direct access to HTTP servers (port 80) and force all traffic through Web caches.

Mesh, you caches!

One of the most exciting features of Web caches is the ability to arrange them in a hierarchy or mesh. Here, the overall goal is to have a cache installed at each provider interconnect point. For example, the customers of the regional provider Westnet would each have their own cache. Each of these caches would forward requests up to a Westnet-wide parent cache. Similarly, backbone providers such as Sprint and MCI could install caches for each of their customers. The higher up in the hierarchy, the bigger a cache needs to be in order to accommodate the wide range of requests coming from the caches below it.

We don't yet have that level of involvement in the U.S. What we do have is a testbed of six large caches installed at the supercomputer center sites, and at FIX-West in San Francisco Bay area. These caches have been operating for six months now. They handle requests from other caches, both in the U.S. and internationally. One of the nice things about this is the ability to direct Web traffic over paths that might not normally be taken. For example, if a foreign country has two connections to the U.S., it can use these ``Web routing'' techniques to force much of its traffic over one of the connections if it happens to be less congested.

Internet decongestant?

In the not-too-distant future, a sophisticated Web routing architecture will exist which mimics the type of routing currently used to forward IP packets between Internet routers. If the Internet remains in this congested state, more and more sites will require the use of caches, for both outgoing and incoming requests. The use of caches is not going to solve the problem of congestion, but hopefully it will make using the Web more bearable.