>> It would have been better if the squid manipulated its receiver window
>> to manage the downloading rate.
>
> This is in effect what happens, but it has to fill up first.
>
> If you look at a packet trace of a delayed response via Squid you will see
>
> 1. Starts out at the default window size (OS controlled)
>
> 2. When the delay pool kicks in the window size rapidly shrinks, and only
> the configured bytes per second is forwarded.
Yes, you are right. But, because of this TCP sender sends packets till the
window size shrinks to zero and therefore the downloading speed (the speed
at which TCP packets are received) is not in control. It particular, it is
never equal to the limit that we configure using the squid delay parameters.
Only the average downloading speed will be equal to the limit that we want;
not the bytes that are send per second.
>
>> That way it need receive only the required amount of bytes per second (as
>> specified by the delay pool parameters.) This also will put a bound on
>> delay.
>
> Delay pools deliver a specific rate per second, with a optional initial
> window where no limit is applied.
No. I have done a tcpdump on the squid server to see find that the squid delay
pool does not deliver a specific rate per second. It can deliver only a specific
average rate, i.e, average rate of the transfer.
- Dinil
Received on Sat Feb 26 2005 - 21:31:07 MST
This archive was generated by hypermail pre-2.1.9 : Tue Mar 01 2005 - 12:00:02 MST