multicast ICP query.  Caches should ignore ICP messages from
   addresses not specifically configured as neighbors.  Otherwise, one
   could easily pollute a cache mesh by running an illegitimate cache
   and having it join a group, return ICP_OP_HIT for all requests, and
   then deliver bogus content.

   When sending to multicast groups, cache administrators must be
   careful to use the minimum multicast TTL required to reach all group
   members.  Joining a multicast group requires no special privileges
   and there is no way to prevent anyone from joining "your" group.  Two
   groups of caches utilizing the same multicast address could overlap,
   which would cause a cache to receive ICP replies from unknown
   neighbors.  The unknown neighbors would not be used to retrieve the
   object data, but the cache would constantly receive ICP replies that
   it must always ignore.

   To prevent an overlapping cache mesh, caches should thus limit the
   scope of their ICP queries with appropriate TTLs; an application such
   as mtrace[6] can determine appropriate multicast TTLs.

   As mentioned in section 5.1.3, we need to estimate the number of
   expected replies for an ICP_OP_QUERY message.  For unicast we expect
   one reply for each query if the peer is up.  However, for multicast
   we generally expect more than one reply, but have no way of knowing
   exactly how many replies to expect.  Squid regularly (every 15
   minutes) sends out test ICP_OP_QUERY messages to only the multicast
   group peers.  As with a real ICP query, a timeout event is installed
   and the replies are counted until the timeout occurs.  We have found
   that the received count varies considerably.  Therefore, the number
   of replies to expect is calculated as a moving average, rounded down
   to the nearest integer.












 
RFC 2187                          ICP                     September 1997


8.  Lessons Learned

8.1.  Differences Between ICP and HTTP

   ICP is notably different from HTTP.  HTTP supports a rich and
   sophisticated set of features.  In contrast, ICP was designed to be
   simple, small, and efficient.  HTTP request and reply headers consist
   of lines of ASCII text delimited by a CRLF pair, whereas ICP uses a
   fixed size header and represents numbers in binary.  The only thing
   ICP and HTTP have in common is the URL.

   Note that the ICP message does not even include the HTTP request
   method.  The original implementation assumed that only GET requests
   would be cachable and there would be no need to locate non-GET
   requests in neighbor caches.  Thus, the current version of ICP does
   not accommodate non-GET requests, although the next version of this
   protocol will likely include a field for the request method.

   HTTP defines features that are important for caching but not
   expressible with the current ICP protocol.  Among these are Pragma:
   no-cache, If-Modified-Since, and all of the Cache-Control features of
   HTTP/1.1.  An ICP_OP_HIT_OBJ message may deliver an object which may
   not obey all of the request header constraints.  These differences
   between ICP and HTTP are the reason we discourage the use of the
   ICP_OP_HIT_OBJ feature.

8.2.  Parents, Siblings, Hits and Misses

   Note that the ICP message does not have a field to indicate the
   intent of the querying cache.  That is, nowhere in the ICP request or
   reply does it say that the two caches have a sibling or parent
   relationship.  A sibling cache can only respond with HIT or MISS, not
   "you can retrieve this from me" or "you can not retrieve this from
   me."  The querying cache must apply the HIT or MISS reply to its
   local configuration to prevent it from resolving misses through a
   sibling cache.  This constraint is awkward, because this aspect of
   the relationship can be configured only in the cache originating the
   requests, and indirectly via the access controls configured in the
   queried cache as described earlier in section 4.2.