Re: Squid 2.2.STABLE2 & choice of parent [patch]

Henrik Nordstrom writes:

>Ok.
>
>Any thoughts on the other two ICP timeout related patches from this
>discussion?
>
>squid-2.2.STABLE2.icp_timeout_select_rtt_parent-2.patch: Select a parent
>based on statistical RTT when ICP times out (TIMEOUT_FIRST_PARENT_MISS)

I feel like this complicates the algorithm more than it already is.
Is it really necessary?

Presumably the ICP query timed-out for a reason (i.e. congestion).
Otherwise, the parent with the best RTT would already be selected
as FIRST_PARENT_MISS. If we add this patch in, then we sort of
weaken Squid's ability to recover (by going direct) in the face
of network congestion or failure.

>squid-2.2.STABLE2.icp_timeout_selection-2.patch: Calculate dynamic ICP
>timeout based on only parents estimated RTT (or siblings if there is no
>alive parents).

I like what this tries to fix (when your siblings are much closer than
your parents), except it seems like we're losing some valuable
information in the averaging. I believe that an average of four data
points is better (in terms of stability and accuracy) than an average
of two data points.

What happens if the opposite situation exists? close parents
and far siblings? Doesn't it add some unnecessary delays?

I wonder if things would stabalize if we weighted based on the percent
of requests forwarded to each neighbor. Presumably we'd have more
requests forwarded to parents than siblings, so they should
automatically receive a higher weight. Under some threshold we could
use hard-coded weights to make sure the first few timeouts are long
enough so we get some parent replies. It could be computationally
expensive, I suppose, to do ~100 of these calculations per second.

Duane W.
Received on Tue Jul 29 2003 - 13:15:58 MDT