In message <199806280426.EAA22758@ice.genuity.net>, Danny McPherson writes:
Jeremy Porter wrote:
Cisco policy routing can use source IP address for deciding to pass traffic to the cache engine. The cache engine, normaly can be configured to exempt destination. I believe that this fixes both issues.
Except that it's an extremely manual process to define these "exemption" policies on an "it's broken, please fix" basis, and something that will likely be duplicated hundreds or thousands of times. Perhaps a more friendly deployment that allows customers to register for this "big incentive" individually would make the most sense, rather than just throwing it out there and seeing what breaks. With this model it's true that all the benefits of caching wouldn't be immediately apparent, but the customer will likely be less annoyed when something does break, and less inclined to select a new provider.
There is no techincal reason why it has to be a arduous manual process. Incentives don't seem to work well with existing customers. (And new customers are happy to manaully configure when you explain that this will on average improve performance.) Existing customers by and large, do not pay attention to the email, letters, etc, when sent out. Only when they break, to they bother to check, and then usually only after calling the 800 number. While there is little lost in offering the incentive to change over, it isn't typically going to get the return on investment that just switching people over will. Of course I can't see any reason why to not have a autoconfigure exemption, problem reporting page, and notice, in addition to profiling traffic that can be expected to break, other than these might seem "hard" as is making the cache work right, apparently.
Of course, this thread wouldn't have started had caching vendors (or better, their customers) agreed on what transparent actually means. I seem to recall one of it's definitions to be "free of deceit. (that's period)", not "free of deceit .. unless IP-based filtering, or the like (anything else that happens to break), is deployed". Only one implementation seems to have got it right at this point, which seems utterly amazing.
Or class of service. I'm sure when can expect the Karl's of the net to be outraged as soon as people like MCI start offering preimum services that don't drop packets, because their packets will implictly still be subject to loss, and it is obviously unethical and unlawful to implement new methods of delivery of DATA. For those of us that have been dealing with router vendors and software vendors on the Internet long enough, it is not at all amazing that only one vendor does it right. That's one better than usual.
Expecting the customer to be able to have a clue to go to a www page is a bit much, tho. Some customers have setup IP based authentication on their NT server, but can't figure out how to configure SLL which wouldn't be cached, and would be more secure. The burden of making this work is on the cache operator. Also it turns out that the sites with the most problems with the cache are the ones paying the least money for service. Its hard to feel very sorry for a $20/month dialup customer, who is connecting to his coporate site with a broken NT server.
I'd think that a $20 dialup customer deserves the same level of service as any other customer, else they're obviously in the wrong market. ...and I certainly wouldn't say that a server, or entire corporation, is in the wrong for deploying properly working IP based authentication as a first level of security.
I would be really supprised if you think that a company that is paying you 10 or 100 times as much deserves the same level service as a $20/month dialup customer. Remind me not to buy and DS-3s or T-1s from your company. I don't want my dollars paying for 24x7 engineer level support for dialup customers. Customers that pay for a dialup account cannot expect to be able to run the same applications as customers that run high speed leased line customer is. There are numerous BCP and security recommendations that VERY CLEARLY indicate that IP based authentication is not a sound authentication. If you are using SSL, you won't be proxied, and won't break. Security through obscurity is NO security. IP source authentication is not ANY better than cleartext token based authentication, if anything its worse as it promotes a false level of security. More importantly it doesn't even give you that from random assigned dialup IP addresses.
-danny (speaking only for myself)
--- Jeremy Porter, Freeside Communications, Inc. jerry@fc.net PO BOX 80315 Austin, Tx 78708 | 512-458-9810 http://www.fc.net