North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: decreased caching efficiency?
At 04:24 PM 20/10/2000 +0200, Simon Leinen wrote:
> caches exist for multiple reasons --
>  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.
perhaps, but evidence speaks to the contrary.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 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.
you would think it would be easier for browser-hosts to do these things, but alas, they typically don't.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.
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. :-)