June 1998 - Test - lists.nanog.org

Re: Digex transparent proxying
by Sean M. Doran 29 Jun '98

29 Jun '98

| some of the content providers in the US would turn over in their graves if | they knew what people who pay heaps more $$$ for traffic are doing to | their web sites :). Let them turn. The easy fix for them is to duplicate their content elsewhere in the world, so they can control it themselves, and reduce the need for caching by operators like you. Sean.

1 0

Greener grass on the other side of the fence
by Sean Donelan 29 Jun '98

29 Jun '98

>As an aside, it always amazes me that the Internet even works (particularly >for an infrastructure that the unwashed masses seems to think will replace >the existing telephone network), but I guess the same could be said of any >chaotic (in the non-linear sense) system... I'm not sure the telephone network is really that robust. Think about the SS7 network and a world with 50,000 CLEC's. Like most things, you don't want to really know what's in the sausage. Some systems are designed with a high degree of control, so everything works correctly. But they often have the property of catastrophic failure when any part fails to work perfectly, such as the cascading failures of the western power grid last year. Central, hierarchial control is alluring. But there are still trade-offs. It used to take a week (or more) to add/change/update network routes in the prdb (and its predecessors). Perhaps acceptable when the central control was working, but it also took that long to fix things when the central database was screwed up. If you were really lucky, you might be able to convince someone to do an 'emergency' change in a day or two. We (myself included) often express amazament how the network manages to continue functioning. However, the system might not be as out-of-control as some people think. It is definitely chaotic. On the other hand, it has shown itself remarkably resiliant to the many evil things people and nature have done. I'll note I'm writing this note while watching white scan lines roll over my highly reliable TCI cable service, NOT! -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

3 2

Digex transparent proxying
by Jon Lewis 29 Jun '98

29 Jun '98

I went searching through my email (since Digex support claimed customers had been notified of Digex's intent to start transparent proxying) and found that I did get "a message" that I'd missed while out of town for Linux Expo. Here's the message: --- Date: Fri, 29 May 1998 19:37:03 -0400 From: DIGEX Customer Support <support(a)digex.net> To: DIGEX Customer Support <support(a)digex.net> Subject: DIGEX Service Enhancement Notification: 06/02/1998 0400 - 0800 EDT Service Enhancement: 06/02/1998 0400-0800 EDT Location: DCA1 POP, Washington, DC During a configuration window between 4am and 8am on 06/02/1998, DIGEX will be upgrading the dca1-cpe router to which your leased line is connected. These upgrades will increase the speed at which you retrieve web pages, as well as improve your web surfing experience. The downtime will be minimal, 15 minutes at the most. We apologize for any inconvenience this scheduled maintenance will cause, and trust the changes to be made will improve your Internet connectivity. Please feel free to contact the DIGEX Customer Service Team with any questions concerning this maintenance, referencing trouble ticket TT-LL0025428. --- That's pretty darn cryptic. "We'll be upgrading the router you connect to...to increase the spead at which you retrieve pages and surf". What does that mean? More memory for the router? A faster CPU module? Why didn't they just come out and say "We'll be reconfiguring the router to which you connect to do policy based routing so we can hijack all your web traffic and run it through a web cache...we'd rather blow our $ on marketing than continue to invest in the infrastructure required to support our leased line sales." Digex is seriously missing the point that not all customers are an office of drones surfing the web all day. We (FDT) use Digex for transit. Several ISPs use FDT for their internet connectivity. By forcing all our traffic through a web cache, they've seriously impacted the service we provide to our customers and the service our customers provide to their customers. Many hours have been wasted at FDT and by FDT's customers debugging problems that I'd originally written off as "user BS" as the description of the problem was just too off the wall to believe. I think we have at least one customer interested in the possibility of legal action against Digex. ------------------------------------------------------------------ Jon Lewis <jlewis(a)fdt.net> | Spammers will be winnuked or Network Administrator | drawn and quartered...whichever Florida Digital Turnpike | is more convenient. ______http://inorganic5.fdt.net/~jlewis/pgp for PGP public key____

4 3

backbone transparent proxy / connection hijacking
by Jon Lewis 29 Jun '98

29 Jun '98

Has anyone else noticed Digex playing with transparent proxying on their backbone? We have one of our T1's through them, and found that all web traffic going out our Digex connection goes through a proxy. We've got customers with web sites that are broken now because they can't communicate with things like Cybercash, because their outgoing http requests are hijacked and sent through a Digex web cache. Digex wants us to register each web server out on the rest of the internet that hosts from our network need to talk directly to. This looks like the beginning of a big PITA. I wouldn't have a problem with Digex setting up some web caches and encouraging customers to setup their own caches and have them talk to the Digex ones via ICP...but caching everything without our knowledge/consent stinks. ------------------------------------------------------------------ Jon Lewis <jlewis(a)fdt.net> | Spammers will be winnuked or Network Administrator | drawn and quartered...whichever Florida Digital Turnpike | is more convenient. ______http://inorganic5.fdt.net/~jlewis/pgp for PGP public key____

15 17

Re: Digex transparent proxying
by Sean M. Doran 29 Jun '98

29 Jun '98

Patrick Gilmore writes: | Which is why I've asked | them to give me some input. Lots of people here have thought about this a | lot more than I have, perhaps they would care to share their thoughts about | this issue? It's nice that you want to learn, but you have the habit of arguing every little point vigorously more often than asking questions like this one, and frankly, that tends to lead people to be disinclined to try to help you come to your own conclusions, much as was the case with Tim Bass, who behaved similarly. Sean.

2 1

Re: Digex transparent proxying
by Sean M. Doran 29 Jun '98

29 Jun '98

Patrick Gilmore wrote: > I find it repugnant that one of my peers has done so. On an operational note, it seems that Priori has just indicated that it wishes to terminate its peering with Digex. I don't suppose anyone knows which way the packets between those two networks will flow once this principled demonstration of revulsion has been implemented? Sean. (prepared to be told by Randy Bush to contact the DIGEX NOC since Ebone is a customer of Digex's in cooperation with ACONET; not that it matters, since the ASes behind Priori are probably not very crucial)

2 1

Re: Digex transparent proxying
by Sean M. Doran 29 Jun '98

29 Jun '98

Cool, Karl. Then you would be denying your customer access to a market -- a potentially large market -- without telling them. Even only indirectly countable "views" are good for brand managers and marketers, hence the popularity of such things as outdoor advertising. Ironic. Where can they sue? Sean.

8 11

Re: Digex transparent proxying
by Sean M. Doran 28 Jun '98

28 Jun '98

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

4 4

Re: backbone transparent proxy / connection hijacking
by Danny McPherson 28 Jun '98

28 Jun '98

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. 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. > 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. -danny (speaking only for myself)

2 1

Re: backbone transparent proxy / connection hijacking
by Paul Vixie 28 Jun '98

28 Jun '98

Uh, watch out, there are packet flow descriptions here. I'm sorry to post something non-legal-related and non-inflammatory. If there's a better list for technical issues, someone please point me at it :-)... > As far as the asmetric routing issue, the traffic INSIDE the ISP isn't > asmetric, and shouldn't need to be cached. I don't really see the > problem here. (But it could be me.) That's true but only depending on how you look at it. If the client and server are in the same IGP there is probably no benefit to be had from transparent caching -- though replication and optimal redirection would still have a place, at least in the larger IGP's. But if one end of the connection is outside the IGP (and it doesn't matter whether this end is the client or the server), and if the IGP has multiple border gateways, then hot potato routing really screws you since the two connections inside the TCP stream can potentially take different paths. If a stream is going to be intercepted, it must be by a device which sits in the path of both connections, since the sequence numbers of a connection are used in the ACK fields of the other connection. If you can do your interception in your customer's "tail" (the part of the customer's data path where all ingress and egress still uses the same links/routers) you're OK. But if you're sending a customer's segments out one path, which is intercepted by one device, and the ACKs or other inbound segments come in via some other path, which is not intercepted or is intercepted by some different device, then you are pretty much screwed.(*) This is one reason out of several why transparent caching is an access side issue, and why the server side caching has to be done with something more robust like replication and redirection. [ (*) yes I know the two devices can synch their sequence numbers with a back channel, or use predictable ones, but that slope is so slippery that it may as well be paved with vaseline -- let's just not go there, OK? ] -- Paul Vixie La Honda, CA "Many NANOG members have been around <paul(a)vix.com> longer than most." --Jim Fleming pacbell!vixie!paul (An H.323 GateKeeper for the IPv8 Network)

1 0