ChecklistWe recommend that you
|
A top-level cache server should cache everything it can (unlike low-level cache servers which normally avoid caching local domains). This will give both national/ISP users and neighbors/siblings in other domains the best possible result.
Always ask the administrator before you set a Web cache as your parent or neighbor. Do not regard open access to a Web cache server as a carte blanche to do whatever you want. Open access may be a misconfiguration or intentional, ask the adminstrator.
Laws on privacy differ from one country to another. Make sure that the caching system does not violate the privacy of users. Be very careful with your logs. Avoid giving out information about your individual users and remember that usage patterns may be sensitive information.
Restricting access to Web pages through the cache must happen at the lowest possible level, close to users. An upper level cache will normally have a few restrictions on access, unless there is a need to impose access restricitons at a high level, as is done in Singapore where legislation places restrictions at the ISP level for the entire country. Censorship should be carefully aimed at the target group of users, if you put restrictions on upper level caches these may not be aimed as accuratly.
Do not offer access to your Web cache for the world outside your organization unless you know what you are doing. Sudden heavy load may take down your server (this has been experienced: the Norwegian branch of a major international company suddenly pointed all Web access through a small Web cache server set up to serve a user population of 14, which caused trouble until the company was shut out by reconfiguration of the server)
Register your server at NLANR or at a national registration service [NLANR]. This will help you get the best possible overview on how many are using Web caching systems in your part of the network.
Aggregated statistics are useful to both your users and other Web cache managers in your mesh. Make such statistics available.
Do not configure your server to be wide open unless your general routing agreements allow you to route traffic from third parties. Web traffic should not break general routing agreements, since Web caching is application level routing.
ISPs should run Web caching systems that their customers can join. Typically, ISPs should provide an end-user Web cache (for dial-up users) as well as upper-level caches to parent for first-level Web caches. Proxy configuration scripts and sensible configuration of Web clients should be provided to network administrators and end users.
ISPs normally have established peering with other ISPs at a national and international level. Make sure that you do not violate agreements on routing. Remember that Web caching heavily influences the flow of Web traffic. (That is why you want to do it!)
ISPs may benefit from having agreements with other ISPs on Web caching. These may follow established agreements on peering and traffic exchange.
To have good relations with other caches
A good child cache always asks permission of its parents before using them, and it chooses its neighbors and parents carefully to make sure that they are optimally placed in the network topology. A long chain of parents is not a good idea. Limit the hierarchy to a maximum of 3 levels (preferably two).
Choose you neigbors and parents carefully, make sure that they are placed in the line of information streaming into your Web cache. If you look at yourself as sitting by a stream of information, choose your parents upstream. Make sure that you use parents that are actually upstream of you, AND downstream of the information you want. A first level Web cache for an UNINETT institution should use as its parent an upper level Web cache to get documents from outside Norway only if it knows that the upper level cache actually does provide access to documents outside Norway. It makes no sense for a Web cache located close to Oslo to use a Web cache in Tromsų as its parent for documents outside Norway when the International connection is in Oslo (and Tromsų is far away, even in networked terms).
Always ask for permission from your parents before you use them.
Beware that time to live for documents at your parent influences your cache. It might be a good idea to agree on a standard configuration within a group of cooperating Web cache servers.
Do not configure your server to be wide open unless you know you can take the load this may lead to.
Publish your policy on who you are willing to be neighbor to (remember that this is the Internet and you get to choose your neighbors).
Beware that time to live for documents at your neighbors influences your cache.
Publish your policy on who you are willing to be parent for (remember that this is the Internet and you get to choose your children).
Long chains of parents is not a good idea, try to limit the hierarchy to 3 levels. Publish your neighbor/sibling and parent configuration.
Do not configure your server to be wide open unless your general routing agreements allow you to route traffic from third parties. Web traffic should not break general routing agreements. One of the consequenses of this is that the UNINETT top-level cache may not act as a parent for non-Norwegian pages without UNINETT breaking the contract with NORDUnet (provider of international connections).
Web caching is application level routing, and as Web traffic forms a considerable part of the total traffic (mesurements in UNINETT indicate that 50% of traffic flowing into the network is Web traffic, mesurements in UK JANET indicates 75-90% Web traffic on international links) may influence the traffic pattern.
| cache-desire@uninett.no | 2002-10-29 |