|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
To: Lincoln Dale <ltd@interlink.com.au> Cc: Christian Kuhtz <ck@arch.bellsouth.net>, nanog@merit.edu From: Simon Leinen <simon@limmat.switch.ch> In-Reply-To: Lincoln Dale's message of "Fri, 20 Oct 2000 06:45:05 +1100" Date: 20 Oct 2000 16:24:33 +0200 Message-ID: <aabswfegke.fsf@limmat.switch.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Errors-To: owner-nanog-outgoing@merit.edu >>>>> "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.
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |