Re: Delay pools

> Is it that squid delays the rate at which a user can receive it's data? Or
> the rate at which squid will receive data? or a combination of both with
> some meaningful guestimate algorithm behind it all?

It delays the rate at which the user can receive data, but it will
not allow itself to read more than a configurable amount ahead of the
user, plus any additional amount implied by the TCP window size.
 
> When reading some posting where administrators are concerned that squid is
> taking considerable bandwidth, it seems that perhaps slowing the rate of
> squid's own download to match that of the enduser would be meaningful. That

This happens when fast abort is not enabled and the user disconnects.
There is no longer any throttle on the transfer and squid reads the
rest of the page to the cache at full speed. The solution is to have
fast abort enabled and set to an aggressive value that aborts all, or
nearly all transfers as soon as the user goes away. (Not fast
aborting can be advantageous on slow sites when the user has to pay
for phone calls - they connect, disconnect and come back a few hours
later to pull the file from the cache.)

> Something along the lines of
> If squid receives ICMP source quenches from it's client, it's therefore
> sending too fast for the client. Squid then inturn sends source quench to
> it's target host.

Nothing should be sending source quenches these days and certainly
not clients. If the client cannot cope with the data rate, the
receive window will fall to zero. At that point squid will store
some of the backlog and when the limit on this is reached will stop
reading, which will cause the TCP window to close on the server side.

TCP flow control is not based on ICMP, it is part of the basic
protocol.

-- 
David Woolley - Office: David Woolley <djw@bts.co.uk>
BTS             Home: <david@djwhome.demon.co.uk>
Wallington      TQ 2887 6421
England         51  21' 44" N,  00  09' 01" W (WGS 84)