- Test - lists.nanog.org

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

proxying: legal -> com-priv, etc.
by Sean M. Doran 28 Jun '98

28 Jun '98

hi - comments about legal and contractual issues involving transparent proxies belong in com-priv, please. "i will sue them!" "they are breaking the law!" "they are ripping me off!" do not belong here. comments about "intercepting http breaks end2endian internet" belong in end2end-interest, please. comments about "how do i configure this?" and "this broke something, how do i fix it?" belong, respectively, here and at noc(a)digex.net, although a summary of problems and experiences on a technical level might be ok here. this, of course, is totally unrealistic to hope for. maybe someone will invent transparent redirection of email to the right addressees... Sean.

3 2

Favor..
by Derek Elder 27 Jun '98

27 Jun '98

Does anyone have colo space available at any of these locations in NYC: 245 Park Avenue 20 Broad St. 67 Broad St. 55 East 52nd Street I'd need space for a rack and 20 amps of power for 6+ months and I need it ASAP. Any help is much appreciated. Derek Derek Elder US Web / Gray Peak Technologies Network Engineering 212-548-7468 Pager - 888-232-5028 delder(a)graypeak.com http://www.usweb.com A Strategic Partner for the Information Age.

1 0

Re: Digex transparent proxying
by shields＠crosslink.net 27 Jun '98

27 Jun '98

In article <35935600.FF54EBFE(a)infowest.com>, "Aaron D. Gifford" <agifford(a)infowest.com> wrote: > It might also be time for content providers of time-sensitive data on the web > to redirect requests coming from Digex' proxy harvest machines to a web page > that says something along the lines of "Digex has intercepted your web request > and directed it through their web caching system. This impacts the > time-sensitive data at this site. Hence you cannot access this site in this > manner. Any content provider savvy enough to put that up could just as easily put in the proper headers to tag their content as cacheable or uncacheable or cacheable until time X, and that would be better for *everyone* involved. -- Shields, CrossLink.

6 11

Re: Digex transparent proxying
by Chris Fournier 27 Jun '98

27 Jun '98

> > Not to mention those to derive advertising revenue from "views", and have no > > way to measure them in a cached environment. If I was doing that, I would > > also deny service to proxy servers and display a nice message telling the > > user to remove the proxy or bitch about its forced use. > > Karl that is silly - in the a lot less time and effort that you would put > in setting up your redirect - you could have just used a correct Expires > header and has your content (or at least just the suff that you want to > remain dynamic) avoid the cache. It serves you as the designer as much as > it serves the enduser (speedier loads). If your page comes up quickly > chances are the person will venture around a bit londer and click more > links in the 20 minutes that they have before their date picks them up > etc... It's common sense. I Believe what Karl is trying to point out, is that alot of sites pay for unique views. If you look at software like NetTracker or most other web site tracking software define a unique view as a view from a unique host. By forcing the use of a BACKBONE Proxy you are going beyond the normal provider level and grouping a large number of providers and regions together into a few hostnames. What they are doing is turning 10,000+ unique hosts into a few unique hosts in the name of saving money. -Chris alpha(a)meganet.net

1 0

Re: transparent caching....
by Paul Vixie 27 Jun '98

27 Jun '98

mo(a)UU.NET (Mike O'Dell) writes: > I've been talking myself blue in the face for some time now > trying to convince the never-ending parade of would-be > cache builders that busting a gut to be "completely > transparent" was simply not worth the effort because i was > convinced it would turn out to be a bug and not a feature, > especially when people had to troubleshoot problems. I have come to agree with this, in the large. But it was and remains an interesting technical problem, and I feel strongly and proudly that our box was the only one that got it *right*. -- 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)

2 1

Re: Digex transparent proxying
by Paul Vixie 27 Jun '98

27 Jun '98

> Any content provider savvy enough to put that up could just as easily > put in the proper headers to tag their content as cacheable or > uncacheable or cacheable until time X, and that would be better for > *everyone* involved. yes, but they don't, and they won't, not ever. expecting other people to do the right thing is just not a hallmark of good operational practice, nor is it a NANOG tradition. > > dialup users, corporate customers and downstream ISPs who > > utilize those links. Cached content is delivered accurately > > Accurately is a bone of contention. We've all seen what caching can do to > time sensitive web-sites. "go ahead, make my day." as the principal architect of a caching product which served up yesterday's newspaper when today's newspaper was wanted, for pretty much all of 1997, to about two dozen hardy "early adopters" (you can tell who they are by the flaming arrows sticking out of their backs), i'm now perfectly willing to challenge you to find any content, no matter how broken or mangled or missing its headers are, that a Web Gateway Interceptor can't serve correctly. and that's without any central registry of "bad content" such as that described by in the post here from inktomi earlier in the day. i'm not saying this out of a desire to use NANOG for product advertising; my last caching product pretty much served its purpose by showing that this kind of caching doesn't win back enough bandwidth if correctness is the goal, and the product has no distribution channel at all. i can't make money by arguing about transparent caching on NANOG -- trust me. so really i'm just flaming. correctness *can* be maintained. content creators will *not* do the right thing. anybody who says otherwise is welcome to tell me a URL they think my WGI can't serve and also show me mail from a content creator saying "thanks for telling me that i was doing the wrong thing, i'll fix my Expires: headers immediately!" -- 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

"RelayFinder" Anyone else seen this? (erols, fnord, oneill may be interested)
by Ryan K. Brooks 27 Jun '98

27 Jun '98

Had a new box on the net for all of two hours, and this pops up on in my maillog: Jun 22 22:18:41 x sendmail[509]: WAA00509: SYSERR: putoutmsg (autumn.news.erols.com) error on output channel sending "250 <relayfinder(a)fnord.net>... Sender ok": Broken pipe Jun 22 22:18:41 x sendmail[509]: WAA00509: SYSERR: putoutmsg (autumn.news.erols.com) error on output channel sending "250 <relayfinder(a)fnord.net>... Recipient ok": Broken pipe Jun 22 22:18:41 x sendmail[509]: WAA00509: SYSERR: putoutmsg (autumn.news.erols.com) error on output channel sending "354 Enter mail, end with "." on a line by itself": Broken pipe Jun 22 22:18:41 x sendmail[509]: WAA00509: from=<relayfinder(a)fnord.net>, size=81, class=0, pri=30081, nrcpts=1, msgid=<199806230318.WAA00509@<MY FQDN WAS HERE>>, proto=SMTP, relay=autumn.news.erols.com [207.172.3.57] Jun 22 22:18:41 x sendmail[509]: NOQUEUE: SYSERR: putoutmsg (autumn.news.erols.com) error on output channel sending "250 WAA00509 Message accepted for delivery": Broken pipe Jun 22 22:18:41 x sendmail[508]: NOQUEUE: SYSERR: putoutmsg (autumn.news.erols.com) error on output channel sending "503 Need MAIL before RCPT": Broken pipe Jun 22 22:18:41 x sendmail[508]: NOQUEUE: SYSERR: putoutmsg (autumn.news.erols.com) error on output channel sending "503 Need MAIL command": Broken pipe Jun 22 22:18:41 x sendmail[508]: NOQUEUE: SYSERR: putoutmsg (autumn.news.erols.com) error on output channel sending "500 Command unrecognized: "X-Scan-Time: 898571908"": Broken pipe Jun 22 22:18:41 x sendmail[508]: NOQUEUE: SYSERR: putoutmsg (autumn.news.erols.com) error on output channel sending "500 Command unrecognized: "X-CIDR-Block: <MY /16 WAS HERE>"": Broken pipe Jun 22 22:18:41 x sendmail[508]: NOQUEUE: SYSERR: putoutmsg (autumn.news.erols.com) error on output channel sending "500 Command unrecognized: "X-Relay-Address: <MY IP ADDR WAS HERE>"": Broken pipe Jun 22 22:18:41 x sendmail[508]: NOQUEUE: SYSERR: putoutmsg (autumn.news.erols.com) error on output channel sending "500 Command unrecognized: "."": Broken pipe Jun 22 22:19:57 x sendmail[511]: WAA00509: to=<relayfinder(a)fnord.net>, delay=00:01:16, xdelay=00:01:16, mailer=esmtp, relay=luser.oneill.net. [207.96.89.34], stat=Deferred: Operation timed out with luser.oneill.net. It looks to me like someone on the host at erols tried to relay through me, and then mail the potential results to themselves at fnord.net (relayed via oneill.net) Is someone attempting to perform a community service here and scan the entire Internet for relays, or are they collecting relays for evil purposes? I can see it now; buy "10 million relay sites on a cdrom for $9.99". Ryan Brooks ryan(a)inc.net

7 6