North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: decreased caching efficiency?

  • From: Lincoln Dale
  • Date: Fri Oct 20 23:19:40 2000

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.