|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
Message-Id: <4.3.2.7.2.20001020202810.02eb3cd8@203.103.99.66> Date: Fri, 20 Oct 2000 21:10:17 +1100 To: Simon Leinen <simon@limmat.switch.ch> From: Lincoln Dale <ltd@interlink.com.au> Cc: Christian Kuhtz <ck@arch.bellsouth.net>, nanog@merit.edu In-Reply-To: <aabswfegke.fsf@limmat.switch.ch> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Errors-To: owner-nanog-outgoing@merit.edu 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.
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |