Digex transparent proxying

Roeland M.J. Meyer rmeyer at mhsc.com
Sun Jun 28 16:37:40 UTC 1998


At 09:05 AM 6/27/98 -0700, Sean M. Doran wrote:
>So Karl, you don't like the fact that your customers are maximising
>distribution of their visual advertising while minimizing their costs
>(by not paying you for some audience reached through caches), I guess.

How, pray tell, are they maximizing their distro and for what? They way I
understand it, they proxy-cache digex has set up optimizes for html, but
screws everything else. Please tell me if I'm wrong. 

FYI, 80 to 90 percent of our served traffic is SSH encrypted, or SSL with
nil TTLs.

>Brand management people generally only care that a vast number of
>people associate their brand with some appropriate set of feelings,
>and that this in turn leads to sales.

So what does branding have to do with this?

>The cost effectiveness of this approach does not have to be measured
>directly (by thorough counting or extrapolating from a sample) when
>other means of testing the effectiveness of a PR/marketing campaign
>are available.

Pah, what does this have to do with the fact that digex has an unannounced
filter on their *paying* customers traffic? Customers whom, contractually,
are expecting a raw feed? If digex wants to optimize luser traffic then
they should split their data-stream into "raw" and "filtered". Otherwise,
they're in breach of contract and should check that their legal retainers
are paid up, they're going to need their attorney's services soon.

>Your analyses of cache effectiveness is also flawed because
>it is looking at merely the question of ratio of cache hits
>to misses, and supposing that misses are inherently inefficient.

Caching is fine for non-transient data. I have yet to see either an SSL or
SSH stream meet these requirements. With privacy issues coming to the
fore-front, a transient domain is much more likely to encounter these types
of streams.

>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.
>
>Where content's effectiveness can be measured by means
>other than direct counting of "views", _or_ where an intercepting
>cache reduces the number of retransmissions, or both, this sort of
>caching is *great* for your customers, because it means they
>can pay you less, because you ship fewer bits.

Got news for you, we don't charge, nor are we charged, per volume. Both
ends buy a fixed size pipe, at flat-rate. It is the only way we'll do
business. Our CEO said so.

>So I can see why you are so pissed off.
>
>	Sean.
>
>| Oh, I forgot - being stupid and twisting people's words is now considered
>| a protected class in the United States.

They way your talking, you must only know how to server HTML. I suppose
that you also think that WinNTserver is the only operating system? Got news
for you, traffic analysis around here says otherwise. HTML isn't even a
large minority and 100% of our server-to-server connections are between
Unix-class boxen. Only workstations run WinNT and some of them are *nix
stations as well. Yes, we allow X traffic through our pipes, but wrapped in
SSH session traffic. 

So you see, your traffic characterization model is flawed. So, apparently
is digex's.

_________________________________________________ 
Morgan Hill Software Company, Inc. 
Roeland M.J. Meyer, ISOC 
(RM993) 
President and CEO. 
e-mail:        <mailto:rmeyer at mhsc.com>mailto:rmeyer at mhsc.com 
Web-pages:    <http://www.mhsc.com/~rmeyer>http://www.mhsc.com/~rmeyer 
Web-site:        <http://www.mhsc.com>http://www.mhsc.com 
Colorado Springs, CO - Livermore, CA - Morgan Hill, CA 
-----------------------------------------(legal notice)-------- 
Note: Statements made in this message do not 
         necessarily reflect the  position of MHSC. All 
         forcasts and projections are to be considered 
         as forward-looking and presume conditions which 
         may not be referenced herein. 
-----------------------------------------(/legal notice)------- 




More information about the NANOG mailing list