The future of ICP_OP_HIT_OBJ

Hi all,

I'd like to get an idea of to what extent people think the ICP HIT_OBJ
feature is a good idea to continue supporting. Briefly, HIT_OBJ means
that we include the actual object data inside an ICP HIT reply
message. HIT_OBJ has caused problems with Squid-1.1 because ICP is
treated differently than HTTP, namely ICP does not have certain request
headers such as Cache-Control and Authorization. See
http://squid.nlanr.net/Squid/FAQ/FAQ-10.html#ss10.12 for more details.

There are a number of factors to consider in deciding if HIT_OBJ
is a good thing. For example:

        - ICP is sent over UDP. UDP does NOT have flow-control
          and could cause congestion.

        - Fragmentation of UDP is considered harmful. If a single
          fragment is lost, the entire datagram is lost.

        - Many Web objects are small. According to yesterday's log for
          sv.cache, 50% of HTTP "200" replies are 3715 bytes or less.
          25% are 1475 bytes or less. If we consider ALL replies,
          including "304 Not Modified", then 50% of replies are 2006
          bytes or less. Larger ICP message are probably more likely
          to suffer fragmentation and/or packet loss, but the actual
          chances will depend on path congestion between neighbor
          caches.

        - HTTP/1.1 should eliminate concerns over TCP slow start.
          Neighbor caches should utilize numerous, persistent
          connections.

        - An ICP HIT_OBJ message will take longer to generate, if the
          object data must be read from disk. A regular ICP HIT
          can be returned immediately.
        
Given these points, should we keep HIT_OBJ around, or rather just let
HTTP/1.1 handle it?

Duane W.
Received on Tue Nov 18 1997 - 15:43:48 MST