- Test - lists.nanog.org

Re: Traffic Engineering (fwd)
by Sean M. Doran 18 Sep '97

18 Sep '97

"John G. Scudder" <jgs(a)ieng.com> writes: > Whether 9999 chooses to do this or not is, as the saying > goes, "purely a local matter." Figures. As with essentially everything in BGP. > Some BGP implementations, gated for one, may be configured to accept > routes with the router's own AS number in the path. Loop suppression > is still provided by limiting the number of times it may appear. > (Hi, Dennis.) Oh yeah, the AS healing wars. I didn't realize gated ever implemented this; I do remember the first time AS path prepending met gated, though, and a certain Russian and a certain Swede plotting to build Sprintlink's backbone on top of ANS's using AS healing. --:) > This is actually useful in some circumstances. Oh certainly. I can think of three applications right now, actually, where that would be the easiest (but probably also the most dangerous) approach to solving routing awkwardnesses. I take it this feature is documented in the usual place? Sean.

1 0

Re: Traffic Engineering (fwd)
by Sean M. Doran 18 Sep '97

18 Sep '97

osborne(a)terra.net writes: > So perhaps what we need is a way for search engines to determine what's > "close" - geographically, politically, or speed-wise. This isn't particularly > easy to do, but if it was implemented and only worked, say, 15% of the time, > it'd still make things look that much faster. How do you plan to accumulate a priori knowledge of distant topology and connectivity using current routing protocols and the current transport addressing scheme? > Idea: what about a search engine that understands a BGP > table? Whose BGP table? Remember that you want to determine what is most local to the client or its proxies. > 1) perform the query. > 2) if your query returns multiple places to get the same page > a) look at the AS_PATH for the querying IP address > b) look at the AS_PATHs for the found pages > c) Determine and return the "closest" one - perhaps the one > whose AS_PATH is most like that of the querying host. (c) is full of landmines thanks to such nifty things as aggregation, the single-view propagation feature, deliberately non-unique addresses and change and instability of intermediate topology from moment to moment. > Anybody out there have any spare venture capital? :) Since you are trying to get it to work correctly with an addressing scheme which only very weakly encodes topological information, the lossy DV approach to propagating routing information (as opposed to a map-exchanging scheme), three huge churny databases (the mapping of information to URL, the mapping of hostname to IP address and the mapping of IP addresses to paths) and attempting to come up with a non existant database or workable heuristics (the mapping of n observed paths to a graph of connectivity among m endpoints), I would say that you need the level of funding you could only raise from such lucrative business as the Psychic Friends Network. Meanwhile, I suggest you look at Dave Clark's distributed database work (I think I remember Van Jacobson commenting in more detail than his "How to Kill the Internet" viewgraphs on how to apply this to the WWW) and consider a scheme where rather than a database which centralizes searches for a weak data architechture, a better architecture and a scheme which treats every reference into it as a search for the most local copy would be a better development direction. Note that since this seems to be possible through feature accretion upon the current practice of aggressive interception of WWW queries, you probably want to think about whether time-to-market issues lead you into developing on that type of platform. (Several people reading this message are heavily into researching that sort of thing already, btw.) Sean.

3 3

Re: Routing without source information and Traffic self-similarity
by Nathan Boyd 18 Sep '97

18 Sep '97

> Okay... I'll bite... Thanks! ;> > Maybe I am just naive but if the IP header did not contain a source > address, how would TCP acknowledgement, windowing, or re-transmission take > place? > > How would a request for data be serviced? Would responses always be in > the form of a all-nets/all-hosts broadcast? How else would the response > get back to the originating host? The point is that the source address is not explicitly *required* in the *header*. Thus, a source and destination could "setup" an IP session by negotiating a "session ID" or something - the first packet from source to destination would include the source's address in the *payload* along with information to start the negotiation process. I am describing, in other words, something like an ATM transport layer that would live below IP. > [snip] > > Routing Protocols.... we need source addressing so we know, at the IP > layer, who our sources of information are, and then, who can we accept > information from and who we should refuse information from. In addition, > access-lists, route-filters, and other types of security would be > non-functional without source addresses. Now you're addressing (so to speak ;) the kind of issues that I am concerned with: without mandating source information in the header, how can the destination make decisions about rejecting/accepting traffic? alternatively, how can middle agents (e.g., routers) do filtering, etc.? how can we possibly prevent spoofing? > Lastly, how would you accomplish a traceroute on a network with no source > addressing? Where would the ICMP ttl expired messages be directed if > there was no source address in the packet? I don't know! You tell me! Do we make each intermediate router "aware" of the negotiated session ID? Doesn't sound tractable to me. I hope this clarifies this - I don't think it is so strivial as my initial email led you to believe. Cheers, Nate

2 1

Re: Traffic Engineering
by Sean M. Doran 18 Sep '97

18 Sep '97

"Jay R. Ashworth" <jra(a)scfn.thpl.lib.fl.us> writes: > Are there any major potholes in this theory that I'm missing? Well, you have two technical problems to solve: firstly, the same numbering problem that anyone else has, viz. addresses will change. Secondly, you have a traffic attraction/traffic dispersion problem for non-local connectivity. You also have to provide better value-for-money than the classical hierarchy-of-providers model your competitors will be using. The "classical" approach is to renumber to solve the first case and do the oh-so-fun BGP tricks Dennis Ferguson described here a couple of incarnations ago. A better approach to both problems is to use NAT to deal with the renumbering issue, and large-scale NAT to deal with your border problem (you not only want to reduce the number of prefixes you advertise outbound, and use the DNS to offer back different topolical locators (i.e., IP addresses) for the things connected to you, but you also want to reduce the amount of information you take in from the outside world). To deal with connectivity failures outside the NATs themselves you build tunnels through working inside or outside infrastructure between your NATs. This is straightforward and is what is done now. Dealing with the failures of the NATs themselves requires synchronized or deterministic address mappings, NAT-friendly higher-layer protocols, and a simple IGP. With some performance-affecting trade-offs you can deal with many NAT-unfriendly higher-layer protocols in various ways too, mostly by sharing state information among your border NATs. Sean.

2 1

Re: Traffic Engineering (fwd)
by Eric Germann 18 Sep '97

18 Sep '97

I believe IBM did something similar during the 96 Olympics. My foggy memory serves me as You hit the front door page. Each mirror did a performance measurement to you (traceroute, ping time, etc) By the time you were 2 - 3 pages into the site, you were redirected to the "best" mirror, based on the above. Kind of cool, especially if IBM thought of it :) Eric At 10:16 AM 9/18/97 -0400, osborne(a)terra.net wrote: >> See, the really neat thing about the 'net is it *removes* the geographical >> locality as a barrier. >> >> People have interests, very specific interests. The number of people >> interested in following alt.barney.die.die.die are geographically >> dispersed, but the Internet brings them together in a virtual community. >> >> Search engines, as primitive as they are now, make it much easier to find >> whatever specific item you're looking for, and odds are overwhelming that >> it's not on your neighbors server. > >So perhaps what we need is a way for search engines to determine what's >"close" - geographically, politically, or speed-wise. This isn't particularly >easy to do, but if it was implemented and only worked, say, 15% of the time, >it'd still make things look that much faster. > > >Idea: what about a search engine that understands a BGP table? I'm thinking >that something like Hotbot, which returns search results with several places >to find the same page, goes through a process like this: > > >1) perform the query. >2) if your query returns multiple places to get the same page > a) look at the AS_PATH for the querying IP address > b) look at the AS_PATHs for the found pages > c) Determine and return the "closest" one - perhaps the one > whose AS_PATH is most like that of the querying host. > >This is a bit rough (off the top of my head, first thing in the morning), but >you could do a bunch with it. Search engines, for example, that optimize for >search speed vs. retrieval speed, come to mind. > >Anybody out there have any spare venture capital? :) > > > >eric > >> >> --- David Miller > > ============================================================================ ==== Eric Germann Computer and Communications Technologies ekgermann(a)cctec.com Van Wert, OH 45891 Phone: 419 968 2640 http://www.cctec.com Fax: 419 968 2641 Network Design, Connectivity & System Integration Services A Microsoft Solution Provider

1 0

Re: Traffic Engineering (fwd)
by osborne＠terra.net 18 Sep '97

18 Sep '97

> See, the really neat thing about the 'net is it *removes* the geographical > locality as a barrier. > > People have interests, very specific interests. The number of people > interested in following alt.barney.die.die.die are geographically > dispersed, but the Internet brings them together in a virtual community. > > Search engines, as primitive as they are now, make it much easier to find > whatever specific item you're looking for, and odds are overwhelming that > it's not on your neighbors server. So perhaps what we need is a way for search engines to determine what's "close" - geographically, politically, or speed-wise. This isn't particularly easy to do, but if it was implemented and only worked, say, 15% of the time, it'd still make things look that much faster. Idea: what about a search engine that understands a BGP table? I'm thinking that something like Hotbot, which returns search results with several places to find the same page, goes through a process like this: 1) perform the query. 2) if your query returns multiple places to get the same page a) look at the AS_PATH for the querying IP address b) look at the AS_PATHs for the found pages c) Determine and return the "closest" one - perhaps the one whose AS_PATH is most like that of the querying host. This is a bit rough (off the top of my head, first thing in the morning), but you could do a bunch with it. Search engines, for example, that optimize for search speed vs. retrieval speed, come to mind. Anybody out there have any spare venture capital? :) eric > > --- David Miller

2 2

NOOP: FYI on gTLDs
by Rick H. Wesson 18 Sep '97

18 Sep '97

Sorry for my non-operational post... I wanted you folks to know that the new gTLDs that the IAHC outlined in their final draft will be operational by Feb 7th, 1997. There was a meeting in New York, NY elier this month where many of the aproved registrars worked on issues surrounding the CORE database system. A draft RFP for the development of CORE is available at http://www.core.gtld-mou.org/ I thought you folks would want to start tracking the situation with gTLDs. You will have to decide on a Registrar to work with. You won't be able to get deligations in the new gTLDs from the Internic, and the forms and interactions will be slightly different. For more info please see the following URLs http://www.gtld-mou.org/ http://www.core.gtld-mou.org/ http://www.pab.gtld-mou.org/ Please don't continue this thread on NANOG as they hate me enough already. If you have questions read the web pages or mail me directly <rick(a)ar.com> =================================================================== Rick H. Wesson Internet Business Services rick(a)ar.com

5 5

Re: need contact info
by Sean Donelan 17 Sep '97

17 Sep '97

>Of course, he neglected to mention, "Good luck getting a straight answer >about anything from MCI. You're better off calling your psychic if you >have a network problem involving MCI." Actually InternetMCI has improved a lot since I started dealing with their employees in early 1995. They still have several annoying habits though. But MCI is not unique. Keeping up-to-date contact information is a problem for lots of providers. Unfortunately, you don't realize the contact information doesn't work until you need to use it. Only then do you discover the provider only has a 1-800 number which isn't callable from your area, you can't send them e-mail because the network isn't working, and the contact page on their web server doesn't load. So once again, I ask all providers to please check your own contact information in the WHOIS database (I know it ain't much, but often its all we have) for an up-to-date e-mail address and internationally diallable telephone number. If you don't want to list your NOC, please list a contact that knows what a NOC is, and can reach your NOC. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Re[2]: Traffic Engineering
by pkavi＠pcmail.casc.com 17 Sep '97

17 Sep '97

Good point re the changing patterns over time. Traffic engineering is not a one time activity, but something you should expect to do once a quarter. Measurement, trendline analysis, projections, and verifying the accuracy of the projections, and determining the reasons for inaccurate projections are all important parts of the process. In this way, traffic engineering is akin to writing a company's business plan--a dynamically changing document that helps you make decisions, rather than set in stone and oblivious to the outside world. Prabhu ______________________________ Reply Separator _________________________________ Subject: Re: Traffic Engineering Author: "Kent W. England" <kwe(a)geo.net> at smtplink Date: 9/17/97 10:19 AM At 09:59 AM 9/17/97 -0500, pkavi(a)pcmail.casc.com wrote: > > As a former network design guy who's done traffic engineering and > design (and redesign) on many networks (Internet and otherwise), I > disagree that traffic engineering doesn't work for the Internet. > Prabhu; Thanks for the treatise on network engineering. I agree that network engineering is useful and that there should be traffic engineers. However, the engineering managers must not forget to see the forest for the trees and must heavily discount the traffic engineering studies, when faced with out-of-the-box data. Here are some examples: > 2. Identify which % of traffic, if any, has regional locality. > For pure Internet traffic, the probability that the source and > destinatino of traffic are within the same metropolitan area > tends to be low (10% or lower for metros within the US). This is true only so long as the density of the Internet is low. This is so because so long as the density is low, few of your neighbors will be on the Internet and therefore local issues are irrelevant. However, at some point, the density of the Internet gets to a critical point, say 30% to 40%. At that point a pizza parlor owner says to himself "two out of every five of my customers are on the Internet. Perhaps I need a web page." And, suddenly, pizza on the Net makes a lot of sense and the traffic patterns shift. As the density grows to 90%, local traffic becomes dominant over distant traffic. Another example is distributed web hosting. When distributed web hosting takes off, your backbone will be heavily discounted and your peripheral interconnect bandwidth will be woefully short. Web traffic will zoom as performance dramatically improves, but your backbone bandwidth will drop. That breaks your traffic model. So, by all means, do your traffic studies, but be prepared to throw them out or re-write them when the environment changes. Then throw bandwidth where it will do the most good. :-) --Kent

1 0

Route Flaps at NAP's
by ramesh＠cs.ucf.edu 17 Sep '97

17 Sep '97

I have couple of questions on Route Flaps at NAP's. 1)How often do they happen? (per hour, per day etc) 2)When route flaps occur, on an average how many routes are flapped? Any pointers indicating the above statistics will be helpful. Thanks, -Ramesh

7 7