North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: Digex transparent proxying
- From: Paul Vixie
- Date: Mon Jun 29 13:08:34 1998
> >(performance for the FIRST fetch through a proxy is SLOWER - it HAS TO BE,
> >since the proxy must first get the data before it can pass it on).
> It doesn't have to -- think cut-thru switching. I've no idea if
> any/enough of the proxies do this.
Yes, some do.
And I wanted to give one thing Sean said more air time so folks won't just
gloss over it:
> An intercepting proxy which runs a modern TCP stack and which
> avoids the "herds of mice" problem by aggregating multiple
> parallel connections into single ones, and which is well-located
> to avoid frequent fifo tail-drop at the last hop, has a benefit
> to the ISP that outweighs the cache hit:miss ratio.
> That is, a cache which imposes decent long-haul TCP behaviour
> reduces the number of packets which are delivered all the way
> from the web server to the terminal server but tail-dropped there
> rather than being delivered to the end user.
This is rather important, both because the stacks used in last-mile devices
(such as the Microsoft Program Loader) are not very modern, and because HTTP
persistent connections end up not being very helpful until they are aggregated
across multiple last-mile devices.
And in these senses (cut through with segment reblocking; reasonable/modern
TCP handling; more use of persistent HTTP), someone with tcpdump actually
would be able to tell that my particular transparent caching box was in use.
I'll leave the challenge to Karl open, though, since I meant specifically
"be able to tell from the client or server end" not "be able to tell using
tcpdump on a LAN wire upstream of the caching box".
La Honda, CA "Many NANOG members have been around
<firstname.lastname@example.org> longer than most." --Jim Fleming
pacbell!vixie!paul (An H.323 GateKeeper for the IPv8 Network)