4 Location

[DESIRE] [DESIRE Web cache] [Web cache Architecture]

Contents

• 4.1 First level Web caches
• 4.2 Upper level Web caches

Checklist Your location We recommend that you always place Web caches close to where the traffic flows place caches on your side of network bottlenecks First level cache We recommend that you place your first-level Web cache as close as possible to your external Internet connection close to users if you have several first-level: where networks come together Upper-level Web cache We recommend that you place your upper-level Web caches where networks join on or close to a national Internet exchange point on or close to an international Internet exchange point

Location of Web caches should be a function of network topology and traffic flow.

Criteria for location of Web cache servers

1. Place Web cache servers on the users side of a bottleneck
2. Place Web cache servers close to the flow of traffic
3. Place a local Web cache server close to your Internet connection
4. Place Web cache servers where more networks join together

Web Cache servers should be placed as closely to the actual flow of webtraffic as possible, at the edges of the network using the cache. This means that the natural place for a national top-level cache neighborhood is at the international connection (particularly since data locality in national networks is low), preferably at the same place as the national Internet exchange point. Webtraffic flows from server to client, so the first-level cache should be placed close to the client and upperlevel caches should be placed upstream. The top-level cache for a specific server should be placed as far upstream as possible.

First level caches are typically placed on campus, close to the institution's Internet connection. Next-level caches are placed at the regional level. Each level of caching adds latency in case of a cache miss, and more than 3 level of caches should be avoided.

More caches may cooperate to spread load and increase hit levels as well as redundancy. The most obvious problem currently annoying the users of the World-Wide Web is that of network congestion [Baen96]. Models of cooperation is largely expanded in HTTP/1.1 with support for multilevel caching, with a number of new caching headers coming into use. Parts of HTTP/1.1 are implemented in caches today. Origin Web servers are not expected to upgrade their HTTP version until summer 1997 at the earliest.

4.1 First level Web caches

The location rules of the first level caching server (the institution caching server) are the same as for the top-level caching servers. There should be no differences except for the fact that for the top level caching server there is a problem with multiple Internet service provides (ISP) that arises form the fact that a Web caching mesh spanning more than on autonomous system may violate routing policies.

Place a first level Web cache close to your users, on the same LAN if possible. If you are running one first level cache, place it as close to your Internet connection as possible. You know that Web traffic flows through your Internet connection on its way to you users.

Firewall solutions are not discussed here. If you have a firewall you need to take care of security aspects that are outside the scope of this document. Placing the Web cache server outside your firewall may be a solution if you serve documents from your domain to external costumers. If you want Web caching primarily for your employees and students you may want to place the cache server on or inside your firewall.

4.2 Upper-level Web caches

Web caches should be placed where several networks join together [Bekker96], on campus or at an access point or Internet exchange point.

If there is a national Internet exchange point, this is a good location for Web caching. Administrators should either agree on running a common Web cache, as has been successfully done in New Zealand [Neal96], or have agreements between Web caches placed close to the exchange point. A significant amount of traffic enters and leaves a network at Internet exchange points, and since you want to place your Web caches close to the traffic flow, this is a good place. Another factor that makes an Internet exchange point a good place for upper level Web caches, is that traffic exchange agreements are already in place and you may not need to draft another agreement on Web traffic exchange. These arguments also hold true for international Internet exchange points. Several Web caches around an Internet exchange point will normally be set up as neighbors, unless one wants to route traffic through another network, which will normally not be the case.

As long as a Web cache serves only local users at one location, network topology is not an issue. When you start to build meshes and hierarchies, topology comes into play. If you locate the servers of your meshes without consideration for the topology, you may end up generating more network traffic than without Web caching. Some links are critical. One prime example is inter-continental links, another is international links. One reason for this is the price; such links are normally very expensive, and international bandwith is not plentiful.

Scaling is one more issue where topology knowledge is needed in order to build services and meshes of servers. An ISP is likely to know both what links will be upgraded and where bottlenecks are going to persist - and ISPs might be able to influence link upgrades.

Within an area where one language is used, it is important to be aware of the end users' need to have easy access to Web documents in their own language and how this influences the traffic pattern (traffic in Norway between Norwegian ISPs are increasing, and 15% of the traffic in UNINETT is over the national Internet exchange point, only 30% is internal to UNINETT).

Ingrid Melve