- Test - lists.nanog.org

caching at windmills (i mean exchange points)
by k claffy 03 Dec '97

03 Dec '97

to: ISP's at mae-west we submit for your valued consideration a proposition http://www.nlanr.net/Caida/maewest.cache.html (first few paragraphs of web page included below) k and dw nlanr/caida (under we-run-commodity-infrastructure supervision from steve feldman (maewest), bill woodcock (zocalo), and david meyer (UO) ) -------------------------------------------------------- web caching as a viable Exchange Point Service proposed business-compatible model of web caching as a service provided at a NAP background NLANR has been operating a national public web caching system for about two years, as part of a research proposal sponsored by the National Science Foundation to architect and deploy prototype Internet information provisioning infrastructure. While the project has been an enormously successful `proof-of-concept' to the Internet community, especially internationally where it was received subjected to far higher and faster accelerating demand than we intended, participation in a cooperative global web caching mesh has for a variety of reasons been slower to catch on in the United States. A significant barrier to the use of caching by ISPs in the United States is the lack of a discernable pricing and business model to support caching as a commericial Internet service, either independently, packaged with a backbone service, or packaged with exchange point connectivity service. NLANR's project has allowed the development and deployment of a strong research code platform, as well as a prototype infrastructure that has recevied international recognition for its operationally pivotal role in the Internet. However, partly because of the tremendous success and resulting expectations of this `prototype' infrastructure, NLANR has not had the budget or cycles to pursue penetration of the U.S. commercial Internet market, partially expecting it to catch on from its own momentum. In 1997, NSF approved a follow-on award to use the by then globally-entrenched NLANR caching infrastructure for extended architectural investigation and experimentation. We maintain a project plan timeline, status reports, and cache status page including information on upgrades, major configuration changes, and outages. More importantly, we are now in a position to move forward with architectural models of caching that are more compatible with commerically-provisioned commodity intrastructure, and in which ISPs themselves will have an incentive to participate. On 1 December 1997, we are deploying a prototype web cache service at MAE-West, specifically designed to demonstrate the viability of a commercial model for providing web caching service. purpose The principal purpose of this peering-point-colocated Squid cache is to provide an easily accessible (no-AUP, low hop-count, low latency) alternative to the current vBNS-hosted root caches. The secondary purpose of this cache is as a demonstration of the feasibility of introducing self-supporting caches into the main stream of the Internet's core. Having a web cache at popular Internet exchange point provides ISPs an opportunity to leverage their presence at this strategic position in the Internet topology. Because the exchange point is a likely component of the paths of many web pages travelling across the Internet, storing web pages on a web cache at this point offers ISPs a potentially significant savings in bandwidth and end user latency by allowing them to retrieve pages there rather than having to go on to the original source.

4 4

Re: The Year of the Backhoe Continues...
by Sean Donelan 03 Dec '97

03 Dec '97

>The relative severity has gone up though for two reasons. First, there >is more fiber than ever in the ground and that which is in the ground >is carrying more traffic than it used to. So a single cut can cause >lots of people problems. Also, because of the increase in internet >use, the visibility of such cuts has gone way up. Doesn't any one else get a chuckle when they hear a *single* cut can cause lots of people problems when referring to the Internet, given the mythological history of the Internet's design goals? Looking over logs for the last few years, the same causes why the application user has problems show up over and over again. Here they are in order.... 1. Congestion 2. Operator/Software error 3. Telcom facility outage (fiber/cable cut or telco 'virtual' service frame/atm/smds/etc failure) 4. Power failure 5. Hardware failure Its difficult to distinguish between operator errors and software errors, since most cases of operator/software failure often involve a failure by both. Also it is sometimes difficult to tell what the true cause of an outage was. It may be more convient to blame the usual suspects, than to admit your own mistakes. I've noticed some 'fiber cuts' have later turned out to be switch or DACS programming errors. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

IBGP problem concerning more specific routes
by Pascal Petit - SYNET 03 Dec '97

03 Dec '97

Here is an amusing BGP problem : Wild Wolrd-----------R1--------------R2------Our Networks There is an IBGP sesion running between R1 and R2. R2 advertises route 194.214.0.0/16 to R1. In our block there is a class C used by one of our customer which is not directly connected to our network. This customer advertises its class C to the Wild World via its own ISP. R1 receives the 194.214.253.0/24 advertisement from the Wild World, it stores it in its routing table; however R2 never takes it into account : its routing table only mentions 194.214.0.0/16 , it doesn't mention the more specific routing entry 194.214.253.0/24. Our Networks cannot get to 194.214.253.0/24. Is it a feature of IBGP ?? Thanks for any help, Pascal ------------------------------------------------------------------------ Pascal Petit SYNET tel: 33 1 4696 0040 74, rue Roque de Fillol fax: 33 1 4696 0041 92800 Puteaux email: ppetit(a)synet.fr FRANCE http://www.synet.fr

2 1

Re: caching at windmills (i mean exchange points)
by Duane Wessels 03 Dec '97

03 Dec '97

Ton Verschuren writes: >I know. Still, for a cache to fill it has to fetch docs and thus act as >a parent. If the NLANR cache acts as a parent for all MW connected >ISP's than *all* misses from those ISP's get routed through the NLANR >cache and for the transatlantic traffic the lines of NLANR's ISP will >fill up. No? In order for the cache to fill, yes some MW customers will need to call the cache a parent. Some could call the cache a sibling. However, it isn't so black-and-white as that. Squid can be configured to measure RTTs to origin servers. Squid's ICP replies will include the RTT estimations, and the child cache can compare these values to its own measurements, or those made by other (parent) caches. Additionally, for the MW cache, we have modified Squid to return an ICP_MISS_NOFETCH reply for requests origin servers which appear to be unreachable (presumably due to incomplete routing info). Upon receiving this reply, the child cache will not forward the request to us. Thus, a child cache can use our MW cache as a parent only for origin servers which are reachable by us, and which our cache is "closer" to. If the child cache is closer, then it will forward the request directly. A potential problem is that the RTT measurement feature is not compiled in by default. It requires building Squid with a macro defined, and installing the ICMP sending/receiving program with root privs. A few more details can be found at http://squid.nlanr.net/Squid/FAQ/FAQ-7.html#ss7.6 Duane W. -- wessels(a)nlanr.net Think Globally, Cache Locally.

2 1

Re: Horrible Service Agreements
by Adrian Chadd 02 Dec '97

02 Dec '97

On Tue, 2 Dec 1997, Vadim Antonov wrote: > Adrian Chadd <adrian(a)ourworld.net> wrote: > > > Erm, say you put your address on a webpage. > > Or post it to USENET. Better yet, write your home telephone, > address and social security number so every bozo can visit you > or steal your credit. [snip] I hope you realise I meant email address here. :-) This isn't relevant to NANOG I agree, so I'll be brief. Then I'll shut up :) Why should I waste my time having to implement anti-spam measures when it isn't fully effective anyway? Not everyone does it, so its not completely worth it. People have a habit of finding holes and back doors in protocols, programs, and I'm pretty sure any system brought in to effectively kill spam would either be so restrictive it becomes a pain in the butt to use, or its just 'broken' and people find a way to spam through it. Makes it all worthless. Although there ARE loophools in legalese, these are generally harder to find, and the penalties involved would deter most people from spamming. So IMHO, its really a question of which one BEST solves the problem QUICKEST. if you can get everyone to fix their mailer agents to do the anti-spam thing, or rush in a new mail protocol, hell.. feel free. I certainly don't have the time on my hands to keep rooting around upgrading mail agents to support new protocols, or anti spam stuff, etc, etc... Adrian (who really shouldn't be posting to email lists as much as he has been lately.. :-)

1 0

Re: Horrible Service Agreements
by Brian Horakh 02 Dec '97

02 Dec '97

First off I think this topic should be moved to another list.. it isn't appropriate for NANOG... but since i'm writing this message i'll put in my two cents. >Cryptography can be used to produce non-transferrable keys >allowing some party to send message to a particular recipient. >Messages can include "right to respond" keys. That is a cute idea, you can only email somebody who has emailed you first, unless of course (for example) you both like to go ostrich hunting then you can email any fellow ostrich hunters. Of course if it doesn't actually solve the problem, just makes it really inconvenient to get a list of all the other ostrich hunters out there so I can sell ostrich hunting supplies. All I have to do is find a message board about ostrich hunting and send 'em all some good ole' spam. Perhaps the legal approach of holding an ISP responsible is a more appropriate (and much more easily accepted method). Let me ask you... Which one is a easier measure, creating legal teeth which ISP's can use against spamming or getting every vendor who produces a SMTP mail product to upgrade to some new Secure-SMTP protocol? Keep in mind it would take the IETF at least 2 or 3 years before they could even agree on a standard (and that's if Microsoft Exchange div. didn't have their goons on the committee). So by the year 2001 we have a Secure-SMTP mail product that is an IETF standard, now the conversion process... lets be optimistic 1-2 years.. The year is now 2003 ... What sane company would stop receiving non-secure SMTP mail from potential customers? Do you honestly think that all the ISP's in the country are going to stop delivering non-authenticated mail? I can just picture tech support "i'm sorry Granny, you can't receive email from little Johnny who's gone off to colleg! e anymore because he's not considered trustworthy." .. The Internet doesn't move quick enough to get changes like that implemented within the system, its grown to large, to fast, and is much to rigid. If you don't believe me just look at UUCP (which I think can officially be declared dead? How many sendmail.cf's still allow user!domain(a)smtp.relay.com) If the government takes the time to give ISP's tools to stop the people/companies it will stop 99.9% of the people out there, you will still get the occasional person who will not remove you from a list, or snag addresses from mechanisms such as Usenet and the www. However that .1% won't even be enough to get mentioned on a list such as NANOG. Laws that have harsh punishments, and require financial restitution, combined with the ability to trace back to a specific USER and/or company will almost 99.9% spam free net. It is the ISP's responsibility to respond quickly to user feedback (even from foreign systems), and to properly configure their mailers to be used to relay non-returnable messages. Companies like hotmail, and rocketmail must take measures to make sure their customers are not performing these types of actions (possibly making it more difficult to get accounts, and getting restraining orders on regular offenders). I'm sure as the problem continues to escalate at the phenomenal rate it has lately this problem will solve itself as the companies who COULD stop the problematic users, will begin to find their staff time being consumed, and reputations being sullied. Just my two cents, -Brian Horakh Network Systems Engineer City of Escondido, CA. !

1 0

Re: The Year of the Backhoe Continues...
by Randy Bush 02 Dec '97

02 Dec '97

do people really think that the relative fiber cut rate is any higher than in the past? there's a bit more fiber, hence the term 'relative'. but i suspect that the predominant factor is that new victims have a better means of broadcasting their displeasure. randy

4 3

Router problems between 'psp.sk.canet.ca' and 'regional1.sk.canet.ca'
by James Philpott 01 Dec '97

01 Dec '97

See attached trace route for clarity. This is taken from my IP address of 204.29.28.142 while trying to reach 207.195.95.27. As of hop 11 all goes well and then a game of packet Ping-Pong ensues between psp.sk.canet.ca [192.68.63.1] and regional1.sk.canet.ca [192.68.63.101]. Any assistance would be appreciated. This message was already forwarded to 'canet-eng(a)canet.ca'. Regards, James Philpott <><!><=><!><=><!><=><!><=><!><=><!><=><!><=><!><=><!><> James Philpott jamesp(a)metainfo.com MetaInfo (206)674-3746 http://www.metainfo.com/support/onlineresources.htm <><=><!><=><!><=><!><=><!><=><!><=><!><=><!><=><!><=><> Sending 48 data bytes to ? [207.195.95.27] 1:Received echo from ? [204.29.28.253] in 0 msec. 2:Received echo from ? [204.29.28.254] in 10 msec. 3:Received echo from milo-s7.wa.com [198.202.20.5] in 10 msec. 4:Received echo from dilbert-fe4-0.wa.com [192.135.191.254] in 170 msec. 5:Received echo from dogbert.nwnexus.com [206.63.0.254] in 20 msec. No data received from intermediate hop. 7:Received echo from core2-fddi-1.Seattle.mci.net [204.70.203.65] in 40 msec. No data received from intermediate hop. 9:Received echo from canet.Seattle.mci.net [166.48.217.254] in 50 msec. 10:Received echo from psp2.bc.canet.ca [205.207.238.133] in 20 msec. 11:Received echo from psp.sk.canet.ca [205.207.238.26] in 50 msec. 12:Received echo from regional1.sk.canet.ca [192.68.63.101] in 70 msec. 13:Received echo from psp.sk.canet.ca [192.68.63.1] in 61 msec. 14:Received echo from regional1.sk.canet.ca [192.68.63.101] in 60 msec. 15:Received echo from psp.sk.canet.ca [192.68.63.1] in 60 msec. 16:Received echo from regional1.sk.canet.ca [192.68.63.101] in 60 msec. 17:Received echo from psp.sk.canet.ca [192.68.63.1] in 70 msec. 18:Received echo from regional1.sk.canet.ca [192.68.63.101] in 80 msec. 19:Received echo from psp.sk.canet.ca [192.68.63.1] in 70 msec. 20:Received echo from regional1.sk.canet.ca [192.68.63.101] in 81 msec. 21:Received echo from psp.sk.canet.ca [192.68.63.1] in 70 msec. 22:Received echo from regional1.sk.canet.ca [192.68.63.101] in 70 msec. 23:Received echo from psp.sk.canet.ca [192.68.63.1] in 80 msec. 24:Received echo from regional1.sk.canet.ca [192.68.63.101] in 70 msec. 25:Received echo from psp.sk.canet.ca [192.68.63.1] in 90 msec. 26:Received echo from regional1.sk.canet.ca [192.68.63.101] in 80 msec. 27:Received echo from psp.sk.canet.ca [192.68.63.1] in 81 msec. 28:Received echo from regional1.sk.canet.ca [192.68.63.101] in 90 msec. 29:Received echo from psp.sk.canet.ca [192.68.63.1] in 80 msec. 30:Received echo from regional1.sk.canet.ca [192.68.63.101] in 90 msec. 31:Received echo from psp.sk.canet.ca [192.68.63.1] in 130 msec. TraceRoute Statistics for 207.195.95.27 31 packets transmitted, 28 packets received, 9% packet loss round-trip (ms) min/avg/max = 0/65/170

1 0

Router problems between 'psp.sk.canet.ca' and 'regional1.sk.canet.ca'
by James Philpott 01 Dec '97

01 Dec '97

See attached trace route for clarity. This is taken from my IP address of 204.29.28.142 while trying to reach 207.195.95.27. As of hop 11 all goes well and then a game of packet Ping-Pong ensues between psp.sk.canet.ca [192.68.63.1] and regional1.sk.canet.ca [192.68.63.101]. Any assistance would be appreciated. Regards, James Philpott <><!><=><!><=><!><=><!><=><!><=><!><=><!><=><!><=><!><> James Philpott jamesp(a)metainfo.com MetaInfo (206)674-3746 http://www.metainfo.com/support/onlineresources.htm <><=><!><=><!><=><!><=><!><=><!><=><!><=><!><=><!><=><> Sending 48 data bytes to ? [207.195.95.27] 1:Received echo from ? [204.29.28.253] in 0 msec. 2:Received echo from ? [204.29.28.254] in 10 msec. 3:Received echo from milo-s7.wa.com [198.202.20.5] in 10 msec. 4:Received echo from dilbert-fe4-0.wa.com [192.135.191.254] in 170 msec. 5:Received echo from dogbert.nwnexus.com [206.63.0.254] in 20 msec. No data received from intermediate hop. 7:Received echo from core2-fddi-1.Seattle.mci.net [204.70.203.65] in 40 msec. No data received from intermediate hop. 9:Received echo from canet.Seattle.mci.net [166.48.217.254] in 50 msec. 10:Received echo from psp2.bc.canet.ca [205.207.238.133] in 20 msec. 11:Received echo from psp.sk.canet.ca [205.207.238.26] in 50 msec. 12:Received echo from regional1.sk.canet.ca [192.68.63.101] in 70 msec. 13:Received echo from psp.sk.canet.ca [192.68.63.1] in 61 msec. 14:Received echo from regional1.sk.canet.ca [192.68.63.101] in 60 msec. 15:Received echo from psp.sk.canet.ca [192.68.63.1] in 60 msec. 16:Received echo from regional1.sk.canet.ca [192.68.63.101] in 60 msec. 17:Received echo from psp.sk.canet.ca [192.68.63.1] in 70 msec. 18:Received echo from regional1.sk.canet.ca [192.68.63.101] in 80 msec. 19:Received echo from psp.sk.canet.ca [192.68.63.1] in 70 msec. 20:Received echo from regional1.sk.canet.ca [192.68.63.101] in 81 msec. 21:Received echo from psp.sk.canet.ca [192.68.63.1] in 70 msec. 22:Received echo from regional1.sk.canet.ca [192.68.63.101] in 70 msec. 23:Received echo from psp.sk.canet.ca [192.68.63.1] in 80 msec. 24:Received echo from regional1.sk.canet.ca [192.68.63.101] in 70 msec. 25:Received echo from psp.sk.canet.ca [192.68.63.1] in 90 msec. 26:Received echo from regional1.sk.canet.ca [192.68.63.101] in 80 msec. 27:Received echo from psp.sk.canet.ca [192.68.63.1] in 81 msec. 28:Received echo from regional1.sk.canet.ca [192.68.63.101] in 90 msec. 29:Received echo from psp.sk.canet.ca [192.68.63.1] in 80 msec. 30:Received echo from regional1.sk.canet.ca [192.68.63.101] in 90 msec. 31:Received echo from psp.sk.canet.ca [192.68.63.1] in 130 msec. TraceRoute Statistics for 207.195.95.27 31 packets transmitted, 28 packets received, 9% packet loss round-trip (ms) min/avg/max = 0/65/170

1 0

Re: Horrible Service Agreements
by Brian Horakh 01 Dec '97

01 Dec '97

>Cryptography can be used to produce non-transferrable keys >allowing some party to send message to a particular recipient. >Messages can include "right to respond" keys. That is a cute idea, you can only email somebody who has emailed you first, unless of course you both like to go ostrich hunting then you can email any fellow ostrich hunters. Of course if i'm a good ole spamming sportin goods store, this is a really convenient way to get a list of all the other ostrich hunters out there so I can sell ostrich hunting supplies. All I have to do is find a message board about ostrich hunting and send 'em all some good ole' spam. Perhaps the legal approach of holding an ISP responsible is a more appropriate (and much more easily accepted method). Let me ask you... Which one is a easier measure, creating legal teeth which ISP's can use against spamming or getting every vendor who produces a SMTP mail product to upgrade to some new Secure-SMTP protocol? Keep in mind it would take the IETF 2 or 3 years before they could even agree on a standard (and that's if Microsoft Exchange div. didn't have their goons on the committee). So by the year 2001 we have a Secure-SMTP mail product that is an IETF standard, now the conversion process... lets be optimistic 1-2 years.. The year is now 2003 ... What sane company would stop receiving non-secure SMTP mail from potential customers? Do you honestly think that all the ISP's in the country are going to stop delivering non-authenticated mail? I can just picture tech support "i'm sorry Granny, you can't receive email from little Johnny who's gone off to college anymore! ! ! because he's not considered trustworthy." .. The Internet doesn't move quick enough to get changes like that implemented within the system, its grown to large, to fast, and is much to rigid. If you don't believe me just look at UUCP (which I think can officially be declared dead? How many sendmail.cf's still allow user!domain(a)smtp.relay.com) If the government takes the time to give ISP's tools to stop the people/companies it will stop 99.9% of the people out there, you will still get the occasional person who will not remove you from a list, or snag addresses from mechanisms such as Usenet and the www. However that .1% won't even be enough to get mentioned on a list such as NANOG. Laws that have harsh punishments, and require financial restitution, combined with the ability to trace back to a specific USER and/or company will almost 99.9% spam free net. It is the ISP's responsibility to respond quickly to user feedback (even from foreign systems), and to properly configure their mailers to be used to relay non-returnable messages. Companies like hotmail, and rocketmail must take measures to make sure their customers are not performing these types of actions (possibly making it more difficult to get accounts, and getting restraining orders on regular offenders). I'm sure as the problem continues to escalate at the phenomenal rate it has lately this problem will solve itself as the companies who COULD stop the problematic users, will begin to find their staff time being consumed, and reputations being sullied. Just my two cents, -Brian Horakh Network Systems Engineer City of Escondido, CA. ! ! !

1 0