When you use multicast ICP, Squid doesn't know in advance how many multicast-capable neighbors are listening for its messages. Squid determines this by sending periodic probes to the multicast group and counting the number of replies. Squid uses this count when waiting for replies to real multicast queries.

The mcast_icp_query_timeout directive specifies how long Squid should wait when counting replies to its fake probe queries. Why not just use this timeout when sending real multicast ICP queries? The reason is that Squid might be sending queries to both multicast and unicast neighbors.

The mcast_icp_query_timeout directive essentially controls how long Squid waits for replies to real multicast queries. Let's say you have an ICP multicast group with 10 neighbor caches, and that it typically takes 3000 msec for all 10 replies to arrive but only takes 1000 msec to receive 5 replies. If you set mcast_icp_query_timeout to 1000 msec, Squid's periodic probes will count 5 neighbors. Then, for a real multicast ICP query, Squid waits for only 5 replies from multicast responders. On average, this should take only 1000 milliseconds.

Another nice feature of this algorithm is that Squid does the right thing if, for some reason, all your multicast neighbors stop responding. In that case, Squid counts zero neighbors and doesn't wait for any replies from multicast responders.

Squid doesn't send multicast HTCP queries.


mcast_icp_query_timeout milliseconds


mcast_icp_query_timeout 2000


mcast_icp_query_timeout 750


icp_port, icp_query_timeout

    Appendix A. Config File Reference