- Test - lists.nanog.org

small vent
by Brian Wallingford 01 Jul '98

01 Jul '98

Why is it that open relays are so common in European/Asian networks? Granted, we still have a long way to go in the US, but at the current rate, I'll likely be blocking all of RIPE and especially APNIC by September. How long does it take to absorb a clue? Just curious. Cheers, Brian -- --=Please direct technical support questions to support(a)meganet.net =-- ======================================================================= Brian Wallingford voice: 508.646.0030 Network Operations Manager email: brian(a)meganet.net MEGANET COMMUNICATIONS, TCIX, Inc. http://www.meganet.net =======================================================================

17 28

Re: Digex transparent proxying
by Chris A. Icide 01 Jul '98

01 Jul '98

[NANOG WARNING: This document contains neither directions on contacting the operational support group for any entity, nor the configuration code for any network hardware] Against my better judgement, I've decided to add my tiny bit of content to this thread. If there is anyone to thank for getting me into it, Mr. Porter has done so with his excellent review of the thread. Without it, I might not have seen the humor in it. However, there is something that I just can't understand. It's amazing to me that with the number of examples in history, people are able to make grand statements like many have in this thread. Please allow me to point out a few historical statements that I feel are very similar to some of the grand statements made in this thread: 1. The world is flat and rests on the back of a giant turtle. 2. Man will never be able to fly faster than the speed of sound. 3. The Dow Jones Industrial Average will never break 4000 Grandiose statements can be generally risky, and almost always the more grand the statement, the more likely it will be wrong to some degree. So if you think some technology is just a short term hack, and is doomed to be forgotten, sure, tell us, and then tell us why you believe it. Just the grand statement alone really is worthless. On to the topic: As far as I can tell there are three major subjects to this thread. The ethical nature of using a transparent cache. The technical and operational problems and solutions associated with the implementation of a transparent cache. And finally, the customer support and management process involved with the implementation of the transparent cache. I'll address these in reverse order. Customer Support and process management seems to be the Achilles' heel of the Internet industry. This industry has seemed to build up a terrible reputation for poor customer support. Coming from the Nuclear industry, I am truly jaded when it comes to process management, but the Internet industry seems to have taken a track as far as possible on the other side. It amazes me the lack of process management in many (not all) of the organizations involved in this industry. Procedures seem to be a dirty word, and tend to result in the exodus of technical talent when imposed upon an organization. In many cases, you can find people in the industry jokingly referring to their facilities and really neat toys. Compared to the multiple interactions in the Internet, a nuclear power plant is simple. And yet, there are very few people if any who could singly determine what one particular action would have upon the operation of the plant as a whole. Obviously, the consequences of something bad happening is far worse, but in many cases, bad means the plant is shut down for some time period, and the company loses cash at an astonishing rate. However, the use of the Internet as a tool for many companies revenue stream continues to grow, and the resulting problems generated by poor process management is beginning to have much wider financial effect. It's apparent that we on the operational side are truly more at fault than anyone else. It's our duty to provide this service to our customers as best we can. If there is any area in which the customer could claim negligence or seek damages, this is one place that they may find a good chance. I'm not pointing fingers here, I've been in organizations that were party to this myself. I'm merely making a general observation. Many organizations have made good headway here. Events such as the infamous 7007 event, the widespread connectivity problems concurrent with filter implementations, down to local effects of such as those resulting in this thread will continue to occur as long as we continue to take a lax view as to the results of our actions. There apparently have been several organizations developed recently that claim to be attempting to address this problem. However, I have not seen an industry-wide affect by the operations of these organizations. As far as the technical and operational problems associated with the implementation of current transparent caching technology, it appears to me that the people on this list who have the most background in cache technology seem to have come to an agreement that technological answers to the problems experienced in this event exist. I can't, nor won't feign any significant technical knowledge in the caching field. I have a general knowledge level at best. >From a general level, this industries technological growth rate is phenomenal and the resulting technological implementation problems can be significant. However, there are organizations that are going to continue to develop and implement these new technologies. The successful ones will be financially rewarded in our capitalistic society, and the unsuccessful ones will fare less well. Sooner or later those implementing the new technology will have a significant advantage over those who don't. To avoid the challenge of new technology can be extremely damaging to the viability of a company in the Internet industry. Yes, I admit that the possibility that any current implementation of a new technology such as caching may actually end up being a temporary fix. However, I would be amazed to find that the effort put into development and operational testing of such a technology did not result in some advancement in that field. From caching, we may find interesting advancements in distributed technology for example. Finally, the ethical question comes around. Is it, or is it not ethical for someone to use a transparent cache? IMHO, the arguments on this portion of the thread have been nothing but sensationalist. It reeks of paranoia. Perhaps the X-Files can (or have they already) done a show on this. THEY are stealing your packets without your knowledge! THEY are monitoring your every transmission and receipt! THEY know your innermost secrets! Bah! Does transparent (or any caching technology, for that matter) give someone additional tools to pry into the data flow? Yes. Does the technology specifically do this and provide this information? No. It's a tool that could be mismanaged and used for something other than its original purpose, and perhaps even intrusive actions. However, it requires someone who wants to do such a thing, and the tools exist already to do similar things if someone so chooses. Attempting to limit the growth of a technology because it could result in the technology being used wrongly is pure folly. In the case of transparent caching, it's my belief that as long as an end user receives content as provided by the content provider in the format specified by the content provider (yes, this includes dynamic information), both the content provider and the end user could care less what physical, electromagnetic, or optical transformations take place from end to end. If the end to end transit is truly transparent, then the goal is accomplished. However, the expectation that this goal could be accomplished while content providers, transit providers, and client/server software providers work independently of each other, is ludicrous. These entities must work together to achieve this. The pointing of fingers and blaming of the other parties does nothing more than delay the maturation process of this industry. This is a complex and extremely interactive system, and must be dealt with as a whole for an optimal solution to arise. Perhaps it's the place here for a Grand Statement concerning the likelihood of this occurring. :) -Against my better judgement, Chris

2 1

Re: Host for NANOG 14 & modified NANOG Business Model (fwd)
by Michael R. Wayne 01 Jul '98

01 Jul '98

Possiblities: 1) Since hotels are notorious for overcharging for food, skip the food entirely and print up flyers listing several nearby eating establishments. Note that many hotels WILL actually let you supply your own pop and munchies if you do not expect them to serve it and do not charge. 2) Use second or third tier hotels. The smaller hotels will not nickel-and-dime you for everything and can be negotiated with on expenses (I assume everyone knows betther than to pay what the hotel first asks for?) We didn't use that much function space so many of the smaller hotels are an option. /\/\ \/\/

1 0

echo echo
by hhui＠arcfour.com 01 Jul '98

01 Jul '98

I'm getting duplicate messages -- anyone else? % grep "NANOG WARNING" * #2943:[NANOG WARNING: This document contains neither directions on contacting #2953:[NANOG WARNING: This document contains neither directions on contacting % grep "If there is enough interest" * #2954: If there is enough interest in revisting what PIER has done or might #2955: If there is enough interest in revisting what PIER has done or might #2956: If there is enough interest in revisting what PIER has done or might (not to single Chris' or bill's messages out or anything) --- Tung-Hui Hu (HH26) 415.840.0631 http://arcfour.com

2 1

really dead.
by bill manning 01 Jul '98

01 Jul '98

Hi, It seems that the IETF has caught up with us and has formally shut down the PIER wg. I am aware that there were a couple of unfinished items and there have recently been some questions on renumbering documents that did not quite make it out of the pipeline before we were closed down. Also, there is apparently a move to view renumbering as a migration stratagy for IPv6. If there is enough interest in revisting what PIER has done or might do, esp. wrt. IPv6 migration and/or compliance w/ addressing registry or provider delegation policies, I'd appreciate hearing from you. --bill

1 0

really dead.
by bill manning 01 Jul '98

01 Jul '98

Hi, It seems that the IETF has caught up with us and has formally shut down the PIER wg. I am aware that there were a couple of unfinished items and there have recently been some questions on renumbering documents that did not quite make it out of the pipeline before we were closed down. Also, there is apparently a move to view renumbering as a migration stratagy for IPv6. If there is enough interest in revisting what PIER has done or might do, esp. wrt. IPv6 migration and/or compliance w/ addressing registry or provider delegation policies, I'd appreciate hearing from you. --bill

1 0

Re: backbone transparent proxy / connection hijacking
by Joe Provo - Network Architect 01 Jul '98

01 Jul '98

[snip] > I would like to "form" a developer group which forms htcp > into squid allowing "more people" to use a new scheme for that, instead > of using icp for the neighbor queries. I started to look at the code > and will be ready to start in about 1-2 weeks. I would hope you're looking at the 1.2 beta code, with htcp hooks, etc in place (just nothing operational). Anyone else interested should get involved in the apropos squid mailing lists. (squid-dev@nlanr, squid-users@ircache, etc). Joe -- Joe Provo, Network Architect 508.229.8400 x3006 Commercial Internet Services Group Fax 508.229.2375 UltraNet Communications, Inc., an RCN Company <jprovo(a)ultra.net>

1 0

Host for NANOG 14 & modified NANOG Business Model (fwd)
by jamie＠dilbert.ais.net 30 Jun '98

30 Jun '98

Speaking for myself, nobody else: >From: "William B. Norton" <wbn(a)merit.edu> >We expect the new registration fee will increase from $150 (which covers >the percentages of the 3 NANOG staff) to between $250 and $300 which will >cover all catering and A/V costs. This will reduce the local host's >financial burden substantially and return the local host role to that of >providing local logistics support, the terminal room, and Internet >connectivity. Uhm. My aunt runs a catering business. *Good* weddings are $40 a plate. Two days, $80. Average three snickers bars ($1 each) and 6 cans of pop ($2) and you have a per-person food cost of $85. Shirt $15, youre at $100. This would mean, at 500 participants @ $250, the A/V cost is roughly $125,000.00 for two days? Is ARIN running the A/V dept now? *hides* (Kim we love ya) >We have also been fortunate enough to have companies loan us technology for >the event. For example, Bay has loaned routers and hubs and Cabletron has >loaned wireless equipment that folks liked so well. Many others have >contributed too. The point is, we expect this type of support to continue, >so the load on the local host will similarly be reduced by these generous >community contributions. Registration costs just went from $100 to $150, now they're going to $250? With a 250% increase in costs over less than a year, I'd like to see where this money goes.. or even better, costs of previous NANOGs. Not that I don't believe it, I just wonder. -- jamie rishaw (dal/efnet:gavroche) American Information Systems, Inc. Tel:312.425.7140, FAX:312.425.7240 "Could you only justify a Pepsi, but took a Coke anyway?" --> -cjw(a)corp.home.net to kimh(a)arin.net, after kimh took the last Coke at NANOG 13

4 6

[ops] ASN10856
by Rob M VanHooren 30 Jun '98

30 Jun '98

Well, got the /19 for ASN10856 today. I feel special. <groan/grin> -R. ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-.._..-*~ Rob M. VanHooren - Chief Plumber, +1 519 679-1155 x33 Packet Pusher, and Resident Mad Scientist(tm) Alarms to 646-4724 Network Engineering Services 171 Queens Avenue, Suite 320 Linkdata Communications Inc. London, CANADA

1 0

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

30 Jun '98

> I do think that it's utterly unacceptable for a backbone provider to > force their customers to use their cache. I do, however, wish that > more backbone providers would provide caching services to those people > what want the service. Most backbone providers run Squid in their datacenters and/or POPs and offer to do ICP with any customer who wants it. I don't like ICP -- see http://www.vix.com/ietf/htcp.txt for the protocol I proposed to replace it. But the model is sound, and I would like to see more backbone providers doing this. > So, If someone is using site exec, etc in their code, and their > provider/webmaster/mother didn't set up Progma: nocache, they're > effectively screwed...erm...cached, right? No. > Fantastic. So, lets say I'm Joe Banner Advertizer. Company X has paid me > present their banner. They wanted to limit the amount of money they spent > so, they had me code my servers to only display their banner X times per > day since I bill them on impressions. Backbone provider Z installs one of > your boxes. By default, no matter how many connections on the limited.. > ..erm.. client side of the box are initiated to retrieve a "fresh" > banner from our banner-farm, you send them Company X until the cache > times out. No. For now, use freshness lifetimes (including pre-expiry for banners) and correctly behaving caches will at worst do a GET/If-Modified-Since whenever they are considering reusing the element -- so your origin server can count the hits and can control when the object can no longer be reused. The HTTP standard already supports this. It costs a TCP transaction per reuse, but it avoids the actual transmission of the banner ad whenever reuse is correct. In the near future, we'll see a different reuse model, based on RFC 2227: rfc2227.txt -- Simple Hit-Metering and Usage-Limiting for HTTP. J. Mogul, P. Leach. October 1997. (Format: TXT=85127 bytes) (Status: PROPOSED STANDARD) And again, the advertisers will be in full control, the standards will get followed, and the backbone will have more bits free for Internet Telephony. -- 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