Observation about icp_query_timeout in Squid 2

There seems to be something wrong with the way Squid 2 calculates the
"optimal ICP query timeout value", when icp_query_timeout is not set.

We run two busy University caches (platform is Alpha, Digital Unix
4.0D). Previously they were running version 1.NOVM.22, with
neighbor_timeout defaulting to 2s. At the time, direct fetches
consituted around 30% of all external fetches, as reported by
Calamaris. The remainder are fetched from each other as siblings, or
from parent RNO caches. All of these peers are in the same machine
room and responses have fast round-trip-times.

When they were upgraded to 2.0.RELEASE (later 2.0.PATCH2), I opted not
to set icp_query_timeout and to let Squid set the timeouts
automatically. But the proportion of direct fetches jumped to nearly
60%. A large proportion of misses were being logged as TIMEOUT_DIRECT
fetches.

Putting squid into debug mode revealed that ICP queries were being
given very low timeouts, often well under 100ms. Thus squid was all too
often giving up on its peers and going direct. This of course resulted
in missing out on alot of potential peer hits.

When I set icp_query_timeout to 1000 (ms), the TIMEOUT_DIRECT fetches
virtually disappeared and the direct fetches dropped back to around 30%
(In fact a value of 250ms gave much the same result.)

It seems to me that something must be wrong with the automatic timeout
calculation for it to consistently underestimate so badly.

--
Chris Teakle
Prentice Centre, University of Qld, Australia