November 1997 - NANOG - lists.nanog.org

Re: Traffic Engineering (fwd)
by Sean M. Doran 19 Dec '97

19 Dec '97

Eric Germann <ekgermann(a)cctec.com> writes: > At 04:31 PM 9/18/97 -0400, Sean M. Doran wrote: > > > >Perhaps you could explain to me how you can find the > >shortest path between A and B using ping times, traceroute > >hop counts, and AS_PATHS observed at C, assuming that > >traffic between A and B is not exchanged through C? > > > > You're not trying to find it between A and B. A connects to B, but B has > every intention of redirecting to C1, C2, or C3, etc. The originally proposed idea was that search engines would present a list of hits sorted by the proximity to the client that made the query. What you are doing is rehashing the IBM scheme. Unfortunately the IBM scheme requires * an initial connection to a server * each server must know the location of its replicated data * each server must be able to determine the proximity of its replicated data to the client in reasonable time and without placing too much additional load on the server, the client, or the replicating sites Point (1) means that for short transactions, preserving locality is a net loss. If it is more work to redirect than to serve directly, there is no point in not serving directly. Point (2) means that copies of the data that may be nearer the client may not be known about. This is also a scaling problem. Point (3) is a difficult engineering challenge, not least because determining proximity (assuming proximity is a function of bandwidth, delay, and infrastructure) without inducing traffic load is hard. What is really needed is a scheme such that * the client learns the identity of the datum desired, and the ultimate, authoritative source of the datum, through user interaction (typing in a URL) or through a search database * the client or its proxy asks increasingly distant infrastructure if replicas are available; Van Jacobson suggests this is a good application for multicast and I'm inclined to agree somewhat * the client or its proxy retreives the found replicated datum if a replica exists and is found within a reasonable time or scope of multicast search or the client or its proxy turns to the ultimate source for a copy * should the client or its proxy hear a query for this same datum, it will offer it up for retrieval to other clients that is, everything in your client or proxy's local cache may be served up to nearby clients Note that the squid caching system emulates this scheme to a large degree. The difficulty is now reduced to constructing a spanning tree for all multicast queries and determining whether something found by the client or its proxy to be topologically nearby is a good choice for serving up the data. These problems seem much more tractable than the ones the IBM scheme needs to solve, and a great deal of theoretical work has gone into this sort of model already. > Anyone know of some reasonably available methods for > measuring end to end "performance" which are almost > universally implemented? No. See the CAIDA or IPPM efforts for why not. Sean. P.S.: Curtis Villamizar had another interesting approach which involved pushing content far afield to machines with the same transport-layer (IP) addresses, relying upon closest-exit routing to connect one to the topologically-closest replication machine. Unfortunately, while this could be really cool for NSPs to offload stuff towards peering points (public or private), it also has some poor scaling properties and is uncomfortably reliant upon the stability of routing. If he's done any more thinking about the idea, I'd love to hear about it though.

4 4

Re: Traffic Engineering
by James R Grinter 17 Dec '97

17 Dec '97

freedman(a)netaxs.com (Avi Freedman) writes: > smd(a)clock.org (Sean Doran) writes: > > P.S.: Curtis Villamizar had another interesting approach > > which involved pushing content far afield to > > machines with the same transport-layer (IP) > > addresses, relying upon closest-exit routing to > > connect one to the topologically-closest replication > > machine. Unfortunately, while this could be really (this is something we've done a little of at work: we do have it in production use, and it's not so effective when there's asymmetric routing - which we have quite a bit for some European networks, eg two peerings with Ebone. Duplicating IP addresses definitely has its place, eg internal to a network for directing a bunch of RASs to a local version of a 'service' address.) > And Alec Peterson (now of Erols) has figured out an even > arguably slicker way to do it. This is a problem I've been musing over lately. The best way that I can see is to return suitable DNS answers to people. This avoids the route instability problems that Sean comments on, above: Client gets TCP session established. Routes change, their inbound route now reaches a different system which clearly doesn't know about the connection and *boom* goes the TCP session. Routes return to their previous situation but by this time it's too late. (Even worse is when the client connects *during* the route instability.) but with DNS you've still got to return a suitable answer. (You could route to your DNS server, but that doesn't address the asymmetry problems.) If the bulk of your data is from you to the client (web, euuw), then it's ok because you are in a position to decide what the best route back across your network is and pick the nearest/most appropriate server. Requests usually come from the client's nearest recursing/resolving DNS server and so that's just a SMOP to decide the best way back. Where you get really screwed up is having to support large numbers of IP addresses - good ol' HTTP/1.0 requests (it's that damn web, again). Using (n x number of "sites") isn't practical. Maybe the real operational issue is working out when we stop having to assign all these zillions of IP addresses for web servers. The marketting people don't want to make the change whilst their competitors aren't. James.

4 4

Problems with specific routing policies for each exchange point
by mark＠exodus.net 05 Dec '97

05 Dec '97

I ran in to a little problem yesterday with my peering sessions wih the various route servers around the country. The problem was that I was not receiving routes from particular ASNs anymore. With a little help from Jake at Merit we were able to pinpoint the problem in my rs-in configuration. It seems that I was importing two different AS macros that each referenced the other (AS-GENUITY and AS-NAPNET). This created a loop in the macro parser on the route server which in turn nullified my routing policy. I was wondering if anyone else had come across this little phenomenon. Mark Tripod Senior Backbone Engineer Exodus Communications

9 16

Horrible Service Agreements
by Forrest W. Christian 03 Dec '97

03 Dec '97

Over the last few months, I've been trying (without success) to find a provider for our second T1 to the net. Basically, all we want is a full-bandwidth T1 w/bgp4, to an upstream I am comortable with the quality of service of, and who can provide this to us (in montana) at a reasonable monthly rate. Finding a suitable provider hasn't been too hard, but the difficulty comes in when it's time to sign a contract. So far, we have accepted a proposal pending contract approval for TWO different potential upstreams. Both quoted a price of around 2500 per month including local loop. However, the contract terms include what I'm terming an anti-spam clause which generally states that if us or any of our clients or their clients decide to "prevent others from enjoying the internet" (paraphrasing) they can terminate us immediately and make us pay for the remainder of the year term. Each (or maybe better said one or more) of the contracts also included other terms which I felt were totally unreasonable. Such as not being able to mention the name of your upstream. Makes it kinda hard to tell potential clients who you are connected to. Another required us to upgrade our equipment based on whatever specifications they felt was necessary at that point. And there were more. Now, I understand the need to be able to terminate spam havens. I also understand the need to require your customers to use compatible and reliable equipment. Let me explain my problem -- Lets assume that customer "a" decides to purchase an account on our system to send out spam. We don't know he's planning to do this, but he does succeed in sending out 10,000 messages before we find out. Under both agreements, we can be immediately terminated without notice and be required to pay for the remaining time on the 12 month agreement. Regardless if we terminate the offending user as soon as we find out or not. Another example. Lets assume that someone in our upstream decided that we MUST have a $250,000 router to connect to their system. If we can't provide such a beast, we are immediately terminated and required to pay for the remaining year term. Both of the potential upstreams have been wholly unwilling to negotiate a contract in good faith to resolve these issues. I know that nanog is probably not the best forum for this, but I figured it might be a good place to start to look for a provider which can: a) Sell us a T1 line, with BGP4, with local loop to NPA NXX 406 443 for about $2500/month, on a year term or less. b) Not have such rediculous contract language. I'd also like to hear what types of contracts are actually signed by providers and if they are actually read before they are signed. You can reply to me directly, instead of on the list, if you'd like. -forrestc(a)imach.com

13 17

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: Eugene Kashpureff's Defense Fund
by Bob Allisat 01 Dec '97

01 Dec '97

>1. Is this an organization for Domain Names for registering them >and maintaining them , and developing global policy ?? CORE is just a private company attempting to market five domain names. .WEB and .ART do not belong to CORE because other companies have developed registries for these Top Level Domains. However CORE is trying in the process to independantly establish Global regulations over the namespace and this is highly unacceptable to most reasonable observers. They've as much right to register .FIRM, .STORE and the others as Internic has to do the same for .COM, .ORG and .NET and Alternic to act as a registry for .XXX, .ZOO, .WEB and so on. None of them have the right to govern the Internet. >2. If this Person has breached federal telecommunication regulations ? >if so. then must pay for the crimes as set down in the countries law.!!!! Mr. Kashpureff is innocent until proven otherwise. And by all appearances the charges are all politically motivated and not very well grounded in legalities. No-one actually owns the domain names. So what the fellow did is not illegal in the strict sense of the word. And it really didn't inconvenience anyone except for those who wish to claim ownership over a universal resource. >3. Defense Fund , if people want to help this person , this should not >be connected in anyway to this organization or this may be seen around >the world as an incorrect organization policy !!!!!!! I think it would be wonderful if CORE were to donate some of it's money to the Eugene Kashpureff's Defense Fund! I also think it would be great if they officially endorsed the Eugene Kashpureff's Defense Fund. Unfortunately CORE is itself trying to steal Internic's monopoly and install one of it's own. And CORE will in all probablility be the next target of protest actions. >4. I am confused over the role of the CORE know because of this discussion >on a issue that doesn't concern the domain registration or GLTD policy >development. This whole debate is central to the debate. Internic holds a monopoly over Domain Names. No-one else can participate at any level. Now CORE wants to take over as the Monopoly. Leaving everyone else out in the cold. And by everyone else I mean individuals, small companies, non- profit organizatrions and most nations in the so-called "third" world. The price tag for a new domain name registry is a half million US dollars (US$500,000). Not only that CORE is a private organization run without any public oversight under Swiss law. It is, furthermore, *not* supported or sanctioned by any member State of the United Nations nor by the UN itself. CORE is a rogue DNS elephant like Internic was in the past. We may have no alternative but to stop it in any way we can. And Eugene points the way very clearly. Will CORE stop and reverse it's course? That remains to be seen. If not expect more of the same protest actions like Kashpureff's. We will have no other choice. TeleVirtually Yours, Bob Allisat Director, World TeleVirtual Network http://www.wtv.net PO Box 191 St E Toronto Canada M6H 4E2 tor(a)wtv.net (416) 534-1999 http://www.wtv.net/portfolio.html

7 8

Re: Horrible Service Agreements
by Sean Donelan 30 Nov '97

30 Nov '97

Yet another person who wasn't going to say anything, but.... If you prefer not to read this, here is a cisco configuration which will fix it config t no ip routing For the clue-impaired, it is not advised you follow any of preceeding or succeeding advice without consultation with a competent advisor. >As for the equipment issue, I feel little sympathy. I have had to go in >and clean up swamp pits of archaic hardware and software. I am not saying >that's what you are, but I am saying that the service providers are quite >reasonable in setting minimum hardware standards for BGP customers. Remember I think the concern isn't over the service provider setting minimum standards for BGP customers, but the open-ended nature of the service provider unilaterally change their standards. Normally a material change to the service by the provider allows the customer to decide if they want to continue with the revised service, remain with the existing service, or end the service without penalty. >And finally. Life's too short to obsess about these kinds of issue. The time to worry about contracts is before there is a problem. Although there are a lot of badly written contacts, and I would walk away from them rather than trying to 'educate' the provider. In practice most of the terms exist to cover a problem that happened in the past. Telco affiliated ISP's use the boilerplate prohibiting you from using their name due to the number of long-distance telephone resellers that used to call people at dinner time and say they where calling on behalf of AT&T, but were actually a boiler room operation in Nevada whose only connection to AT&T was the logo on the telephone equipment they were using. Useful boilerplate language exists, see your lawyer: "The customer may advise end users that certain services are provided by the Company in connection with the service the customer furnishes to end users; however, the customer shall not represent that the Company jointly participates in the customer's services." Similar boilerplate exists for most of the things Forrest Christian is worried about. But dealing with lawyers at billion dollar companies is often an exercise in futility. Unfortunately most NSP contracts cover all the reasons why the NSP can terminate service without notice, but don't actually bind the NSP to providing an adequate level of service or any service in some cases. I would worry about ISPs with 'simple' contracts as much as ISPs with 'complex' contracts. Simple contracts are harder to write well. Most Acceptable Use Policies actually read like unacceptable use policies. The NSF AUP listed eight acceptable uses and only two unacceptable uses. >If you run your ISP right, these won't be a problem. If you don't run >your ISP right, these won't be your real problem. In the time you have >been upset about this, you could have a well written AUP with procedures >in place that would make any transit provider happy. You are making a big assumption. If it would have made the transit provider happy, why didn't the transit provider contract list this as an acceptable option? Even if the salesperson says its ok, six months later after the salesperson is long gone, and there is a problem will there be any record the transit provider found the ISP's AUP or ISP's procedures acceptable. Or will they apply the one strike and you are out rule, and terminate service without notice. Unless it is included within the four corners of the contract, I would not make any assumptions about what would or would not keep any transit provider happy over the lifespan of the contract. Although, if the transit provider is unhappy, I suspect they will find some reason to terminate the service irregardless. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Cat5500/Core6000/?
by Brian Horvitz 30 Nov '97

30 Nov '97

Anybody have real comparison experience between the Catalyst 5000/5500 series switches and the 3Com CoreBuilder 6000? Seems to me that the core builder is going to be able to push around a lot more packets. I'm just really looking for likes and dislikes on either or, if anybody just hates them both and has anything else they like. Brian Horvitz

1 0

wait before you flame
by Nicholas Bastin 30 Nov '97

30 Nov '97

I did not intend that last message to start a whole gigantic thread about ipv6/ipv8, I just want to know if anyone has drafted anything about ipv8... Just to head off the onslaught. Nick

4 4

ipv8
by Nicholas Bastin 30 Nov '97

30 Nov '97

This may or may not be the place to ask, but...Can anybody point me at some technical documentation/proposals on ipv8? Nick

1 0