Re: Digex transparent proxying
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. 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. 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. 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. 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. 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. - -- Sean Doran Copenhagen, Denmark
On Sat, Jun 27, 1998 at 09:05:30AM -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.
Excuse me?
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.
And how do advertisers measure this? By eyeballs (or eardrums, for audio media) reached. Deal with reality Sean, not your fantasies.
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.
You're in dreamland Sean, not that this is unusual. Again, you are missing the point, which is what is ACTUALLY done, not your fantasy-land of how you'd like to see people measure effectiveness (and set pricing).
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.
So I can see why you are so pissed off.
Considering that MCSNet doesn't at present sell (nor has it ever sold) a single bandwidth-sensitive service (ie: no burstable rate circuits with a variable cost component, no traffic-sensitive web hosting, etc) you're once again full of shit. If there is an ISP out there which would find financial advantage to this paradigm of operation ("transparent" caching), its MCSNet. That I would find doing so financially rewarding does NOT justify hijacking a customer's packet traffic and passing it through a "filter" of my own design and without that customer's consent. The difference is that I have ethics and deliver what this company sells, not some jiggered version that we claim to be "functionally equivalent" but really isn't.
Sean.
| Oh, I forgot - being stupid and twisting people's words is now considered | a protected class in the United States.
- -- Sean Doran Copenhagen, Denmark
You STILL need to take that Lithium pill Sean. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV | NEW! Corporate ISDN Prices dropped by up to 50%! Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost
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@mhsc.com>mailto:rmeyer@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)-------
On Sun, 28 Jun 1998, Roeland M.J. Meyer wrote:
How, pray tell, are they maximizing their distro and 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.
Hmmm - you're wrong... the only traffic that would be diverted to this cache is port 80 - if they are using an alteon switch then the alteon makes a decision to redirect port 80 traffic ONLY to the port that the cache is connected to.
FYI, 80 to 90 percent of our served traffic is SSH encrypted, or SSL with nil TTLs.
Differnt port...
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.
Not effected... -- I am nothing if not net-Q! - ras@poppa.clubrich.tiac.net
At 08:16 AM 6/28/98 -0400, Rich Sena wrote:
On Sun, 28 Jun 1998, Roeland M.J. Meyer wrote:
How, pray tell, are they maximizing their distro and 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.
Hmmm - you're wrong... the only traffic that would be diverted to this cache is port 80 - if they are using an alteon switch then the alteon makes a decision to redirect port 80 traffic ONLY to the port that the cache is connected to.
Thank you. So if I provide my links on a different port then I by-pass the proxy, cute. However, many of my customers have some ferocious firewalls that only allow port 80. Of course those machines are running their apache somewhere else. But, I use port 80 to run an SSH tunnel to them.
FYI, 80 to 90 percent of our served traffic is SSH encrypted, or SSL with nil TTLs.
Differnt port...
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.
Not effected...
-- I am nothing if not net-Q! - ras@poppa.clubrich.tiac.net
___________________________________________________ Roeland M.J. Meyer, ISOC (InterNIC RM993) e-mail: <mailto:rmeyer@mhsc.com>rmeyer@mhsc.com Internet phone: hawk.mhsc.com Personal web pages: <http://www.mhsc.com/~rmeyer>www.mhsc.com/~rmeyer Company web-site: <http://www.mhsc.com/>www.mhsc.com/ ___________________________________________ SecureMail from MHSC.NET is coming soon!
participants (4)
-
Karl Denninger -
Rich Sena -
Roeland M.J. Meyer -
Sean M. Doran