September 1997 - Test - lists.nanog.org

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

18 Sep '97

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. If B can communicate with some measurement tool on Cx, they can all report back on their "connectivity" to A. B can then redirect A to the "best" Cx node. If the results are inconclusive, round robin it. If B had knowledge of BGP and AS's, maybe it wouldn't have to decide on distance but instead search for a Cx which was nearest to B in the AS_PATH. The premise being it may be better to pick a Cx nearest me in my upstream, as opposed to driving it through some overloaded exchange point. Granted, ping tends to get dropped on the floor at overloaded points, and traceroute probably isn't a) too much better b) probably blocked in some (most) cases, but are there any better alternatives? Anyone know of some reasonably available methods for measuring end to end "performance" which are almost universally implemented? Kind of making do with what we have. #Included junk >From Network World Olympic effort could be much more ------------------------------------------------------------------------ By Marc Myers 07/29/96 If you, like me, are among the six million people that have succumbed to the temptation of visiting IBM's Olympics Web site (http://www. atlanta.olympic.org) don't feel bad for having wasted company time. Just tell your boss that you are reviewing one of the most phenomenal technological feats of the decade: a worldwide network constructed in just 15 months. The project - though it has run into some technical snags during the early going - demonstrates how much can be accomplished when an immutable deadline is accompanied by a virtually unlimited budget. IBM provided a $40 million sponsorship, but the company's actual expenses probably exceeded $1 billion. The Internet setup utilizes two primary RS/6000 SP2 multiprocessing servers, one of which hums away on 52 processors in Southbury, Conn., while its buddy chugs along on 16 processors in Hawthorne, N.Y. Mirror servers run in Asia, Europe and the U.S. IBM developed new load-balancing software as part of its Web Object Manager that optimizes traffic, automatically finding and tapping the most available servers. Other aspects of the system - including the Global Shared Data Center - are so secret that we don't even know where they operate from. For surfers who are into the Olympics, the services offered are superlative: You can get game results almost as fast as the major networks, download images and flicks of the world's greatest athletes and shop for official Olympic products. But what I find most appealing about this system is that it was built so quickly and with such creativity. What if IBM decided that this was something that could be done more than once? [snip ...] ============================================================================ ==== 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

2 1

Re: need contact info -Forwarded
by CRL Information 18 Sep '97

18 Sep '97

You may wish to email info(a)crl.com, sales(a)crl.com, accounting(a)crl.com, admin@crl.com,support@crl.com. What is the nature of your request ? > Sender: owner-nanog(a)merit.edu > From: Naiming Shen <nshen(a)mci.net> > To: nanog(a)merit.edu > Cc: nshen(a)mci.net > Subject: need contact info > Any one has good contact info for crl.net? I tried noc(a)crl.net, > peering(a)crl.net, routing(a)crl.net, all failed. > ------------------------------------------------------------------- > - Naiming Shen MCI > - MCI Internet Engineering 2100 Reston Parkway > - +1 703-715-7056 fax: 703-715-7066 v272-7056 Reston, VA 20191 > >

1 0

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

18 Sep '97

<osborne(a)terra.net> writes: > AS_PATH was the first idea - other such tools could include ping times and > traceroute hop counts. It's been pointed out to me that IBM supposedly did > something like this for the '96 Olympics. 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? > True - having a search engine look at its own BGP table is not the best > indicator of distance, especially if the search client is "distant" (many > AS's away) from the engine. However, given the prevalence of things like > the Merit tools that show the BGP exchanges at major NAPs, it's conceivable > that a search engine could grabe these tables on a regular basis, and from > there it becomes pretty much an SPF tree through AS's. An AS_PATH does not describe a connectivity graph. It is attached to reachability information to avoid looping NLRI propagation; in essence, it is an audit trail of who has already seen the route and passed it on. That is, when you look at an AS path like 1239 1800 1755 19999 you are trying to discover who has already apparently seen the announcement, and therefore, who should not see it again from you. Any modern use or understanding of the AS path beyond this is an overloading of the attribute and is probably a bad idea. (I expect some disagreement over this, particularly as a BGP-talking router is expected to tell the truth about which path it actually is using.) Unfortunately, a popular modern use is in using the length of the AS_PATH to influence routing policy by guessing what other ASes will do with the AS_PATH length in the route selection process. This leads to the belief that the AS_PATH can be used as a primitive metric, but this is unreliable, and depends on the prevalence of a particular selection process which hopefully someday will be dead, as has been talked about for more than a year. (Hi Paul, hi Ravi, where's the code?) Also unfortunately, a popular modern misunderstanding of the AS_PATH is that it describes the current best (or even ANY) path from somewhere back to the origin. While as-path prepending and the like has side effects on a certain path-selection scheme, it also has a more interesting side effect in the sense that you may scope an advertisement by enumerating ASes that should not hear the announcement. That is, if I stuffed 9999 into the AS_PATH of an announcement I generated or learned from elsewhere, AS 9999 would never hear the announcement from anyone who heard it only from me. The presence of 9999 in the AS_PATH does not indicate connectivity between the surrounding ASes in this case. There are two simple things to observe: * an editable AS_PATH guarantees that the AS_PATH cannot reliably be used to determine which ASes will carry traffic towards the advertised prefix nor that any two adjacent ASes in the path are directly connected with one able and willing to send traffic directly to the other for that prefix * the reason one wants to edit an AS_PATH is almost always to make up for the fact that the AS_PATH length is commonly used as a primitive sort of metric, and without breaking the loop-prevention scheme, one cannot usually DECREASE the length of the AS_PATH except by playing icky games with AS_SETs. To calm fears about the first point, anyone who advertises a prefix to you declares that the prefix is reachable through that neighbour. (Although you should worry about whether what you reach is a _local_ version of that prefix that is routed to Null0 and the like, but that's a social problem regarding trust, which of course is the scary detail of using BGP for global dynamic routing). The primary reason sed(1) was never implemented in OFRV's code for a long time was that the AS_PATH was understood to be an audit trail primarily to prevent announcement loops, and that the formation of an announcement loop was the obvious Bad Thing sed(1) could lead to. > I do concur, though, that ping and traceroute are probably more sensible > metrics to use. Why? ping and traceroute are poor predictors of locality and available bandwidth between the originator and target of those tools. Sean. (who had a long dinner break in the middle of this and probably left many loose ends. sorry.)

3 4

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