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
