The Internet Cache Protocol was developed as a fundamental part of the Harvest project. ICP's role is to provide a quick and efficient method of intercache communication, offering a mechanism for establishing complex cache hierarchies. ICP allows one cache to ask another if it has a valid copy of a named object, thereby improving its chances of selecting a neighbor cache that will return a cache hit. In addition, ICP allows requests to flow among child caches.
Harvest and Squid also utilize ICP to provide an indication of network conditions. Failure to receive an ICP reply likely means the path is severely congested, severed, or the peer host is down. In any case, we would not want to forward a request to that peer, if possible. Similarly, the order in which ICP replies are received can indicate which ones are ``closer'' and/or less loaded, and therefore likely to give better performance.
ICP messages are transmitted as UDP packets. One advantage to UDP is that the code becomes easier to implement because each cache needs to maintain only a single UDP socket. Also, as alluded to above, we normally want ICP messages to be dropped in the face of congestion. One disadvantage is that ICP becomes useless on highly congested links, perhaps exactly where caching is needed most.
Another disadvantage is that ICP adds some delay to the processing of a request. The extra delay is almost exclusively due to the transmission time of the UDP packet. In other words, a request will be delayed by the maximum round-trip time to your neighbour caches. Because of this delay, ICP is not appropriate for all situations.
ICP can also function as a conveyor of cache access policies. Rather than forward a HTTP request, only to have the peer deny it, ICP will give us advance warning that the HTTP request would be denied. In that case, we certainly would not forward the request to that peer. However, this does not mean that we should query all peers for all requests and let the access controls decide which will be allowed. The cache administrators should communicate their terms-of-use to each other. Squid will complain both when it sends too many ICP_DENIED replies to a neighbour, and when it receives too many ICP_DENIED replies from a neighbour.
The ICP messages are generally very small. They consist of a 20-octet binary header followed by a URL string. The median ICP message size seen by the NLANR caches is 66 bytes. In a cache hierarchy, there will usually be many more ICP messages than HTTP requests. Depending on the type of relationship (parent or sibling) the ratio of ICP to HTTP may be anywhere from 2 to 10.
As of this writing two Internet Draft documents on ICP are going
through the final stages of becoming Informational RFCs. The
draft documents are named draft-wessels-icp-v2-03.txt
and draft-wessels-icp-v2-appl-03.txt.