"ld" == Lincoln Dale <ltd@interlink.com.au> writes: caches exist for multiple reasons -- [1] to make things faster [2] to save bandwidth [3] to achieve more "goodput" in network transactions. [4] to operate at layers-8 and 9 (filtering) [...] in many cases, people significantly underestimate the effect of #3 - and it isn't easily measured. it is the effect of a "good" tcp stack cutting down end-to-end tcp retransmissions when the "last mile" hop is congested.
Not just when it is congested... whenever the proxy (I'm deliberately not talking about "caches"---even a cacheless proxy would have this effect) has RTTs to the origin server and the browser which are both lower than the "e2e" server<->browser RTT, then the TCP control loop will react faster to changing network conditions. This includes faster "ramping up" to available bandwidth, and higher achievable throughput if the same window size is used. Note also that proxies can affect goodput adversely, for example when both the origin server and browser host support larger TCP window sizes than the proxy. This artificially limits throughput when there's little or no congestion over paths with high RTT. I think this is quite common because it is easier for browser hosts than for proxies to support larger TCP windows---proxies have to support high numbers of concurrent TCP connections, and using large windows may incur very significant kernel memory overhead unless OS developers do clever memory-allocation things. -- Simon.
At 04:24 PM 20/10/2000 +0200, Simon Leinen wrote:
caches exist for multiple reasons -- .. [3] to achieve more "goodput" in network transactions. [...] in many cases, people significantly underestimate the effect of #3 - and it isn't easily measured. it is the effect of a "good" tcp stack cutting down end-to-end tcp retransmissions when the "last mile" hop is congested. ... Note also that proxies can affect goodput adversely, for example when both the origin server and browser host support larger TCP window sizes than the proxy. This artificially limits throughput when there's little or no congestion over paths with high RTT.
perhaps, but evidence speaks to the contrary. i think that most people agree that Microsoft has had a pretty ordinary tcp stack with regard to tcp-over-satellite and rfc1323-type tcp TCP enhancements. perhaps that has changed with windows2k, but i somehow doubt it. microsoft making policy decisions such as "dial-up connections are faster using an MTU of 576" goes against the philosophy of them knowing what they're doing.
I think this is quite common because it is easier for browser hosts than for proxies to support larger TCP windows---proxies have to support high numbers of concurrent TCP connections, and using large windows may incur very significant kernel memory overhead unless OS developers do clever memory-allocation things.
you would think it would be easier for browser-hosts to do these things, but alas, they typically don't. i agree that managing tcp buffers is a significant function of a cache/proxy. caching vendors who have their own OS or the ability to hook into an OS to manage buffers in this manner have a distinct advantage over those who cannot. of course, i might be somewhat biased in that comment given i've worked on such a system. :-) cheers, lincoln.
participants (2)
-
Lincoln Dale -
Simon Leinen