- NANOG - lists.nanog.org

Re: BBN/GTEI
by dlr＠bungi.com 22 Aug '98

22 Aug '98

[In the message entitled "Re: BBN/GTEI" on Aug 21, 16:33, Michael Dillon writes:] > > Here's the complex part. The value is not expressed in bits and it depends > on the destination within the peer's network. I am assuming that we can > map the IPv4 address space by city and that we can set some value to each > intercity link. This means that a stream of bits entering a peers network > in San Jose with a final destination in San Jose would be free. But if the > stream of bits was destined for Santa Cruz there would be a small cost. > And if it was destined for Sacramento there would be a somewhat larger > cost because Sacramento is further. Have you made long distance calls lately in the US? A call from San Jose to San Francisco costs significantly more than one to New York. A call to New York costs exactly the same as one to Denver, or to Seattle. All of which cost 1/4th as much as a 40 mile call to Gilroy from San Jose, which costs *more* than a 60 mile call from San Jose to San Francisco. And don't even get me started about Thousand Oaks. Unless, of course, you are using your Pacific Bell GSM phone, in which case it is free. Calling anywhere *else* in the USA (and canada, for that matter) on the GSM system is $0.15/minute. Unless, of course, you have a Sprint phone, and are using their 'toll free' option, in which case it doesn't cost anything, unless you are calling Canada, in which case it is $0.60/minute. Down this path lies madness. I hope that the Internet will not go here. On-net facilities have made distance-sensitive pricing in most metro areas a thing of the past. Sub $0.04 per DS0-mile long-haul rates have made long haul circuits very affordable. High speed WDM dark fiber routes will make long haul very, very cheap in the next 2 years. Trans-atlantic fiber availability means that STM-1's are now close to the same pricing as cross USA OC3's today. Asia is still coughing up $1M/month for DS3's, though. International traffic is a problem, no matter how you cut it. Simple "distance between points" will not, however, hold water. -- Dave Rand dlr(a)bungi.com http://www.bungi.com

1 0

BBN/GTEI
by Richard Irving 22 Aug '98

22 Aug '98

Oops, intended for Nanog as well....

1 0

RE: BBN/GTEI
by owen＠DeLong.SJ.CA.US 21 Aug '98

21 Aug '98

> > Both companies get payed for providing a > > service. Where is the problem? Why should BBN get a cut of what Exodus's > > cutomers pay? BBN is trying to get payed to provide something it needs to > > from Exodus. If BBN needs it, why would Exodus pay for it? Isn't BBN trying > > to get payed twice? > > You are asking about specifics and I have no idea what the answers are. > Unless somebody speaks to both Exodus and BBN and gets around the NDAs > that they have signed, I don't think anyone can know. > True. > However, there is a more general issue here. If a company primarily hosts > websites, then their traffic will be asymmetric with many more bytes going > out than coming in. They must engineer their network to handle this > asymmetry and any transit providers they have must also do so. > Traditionally, peering only occurred between providers with a national > network with at least 4 points of contact, spread out geographically. This > requirement is so that each provider carries a roughly equal load of the > traffic across expensive national longhaul circuits. It is this balanced > transit load that makes them peers. > Public Information: Exodus has a LARGE national backbone Exodus connects at: MAE East MAE West Ames MAE West MFS AADS NAP PB NAP MAE LA SPRINT NAP PAIX Exodus has private exchanges in place with a number of providers. > In the case of a web hosting company, the bulk of the traffic is outgoing > and if they do the standard shortest-exit routing with their peers, then > the peer will be carrying a much larger transit load than the webhosting > company. Of course, this could be solved by both parties doing > longest-exit which places the largest transit load on the webhosting > provider. But there is more. > OK, so we're agreed on that issue. > When the webhosting network touches down at only a few exchange points to > peer with a provider who has an extensive network you will have a > situation in which the peer is providing regional transit for free and > must engineer their regional networks to deal with an asymmetric traffic > pattern. For instance, if a webhosting provider touches down at San Jose, > Chicago, DC and Dallas then they appear to meet the eligibility > requirements for peering. But these peers end up providing full transit > from Boston to DC, LA to San Jose, Denver to Dallas, and St. Louis to > Chicago. This arises because one provider hosts lots of equipment close to > an exchange point and the other provider interconnects many POPs in many > cities. > Exodus has facilities in Boston, New Jersey, Herndon (DC), Chicago, Irvine, Santa Clara, and Seattle. OK, we don't cover Denver, Dallas, or St. Louis, but I have strong reason to believe that represents a very small fraction of the traffic. Further, when a provider sells access service to a customer in Dallas, Denver, etc., it is not likely that any significant portion of their traffic can be delivered to or accepted from an exchange point in those places. Therefore, any sane provider would expect to be transiting a significant portion of the traffic supplied by/requested by that customer from a city with a major exchange point or handoffs to multiple providers. As such, I would think that transit would simply be part of their customer pricing model. > Somehow we need a way to quantify and measure the traffic and establish > what peering is in terms of measurable quantities. A certain amount of > asymmetry should be allowable but it can get out of hand. One way to deal > with great asymmetry is to deny peering. Another way is to accept peering > but measure the asymmetry and have a pricing structure for regional > transit that applies after a certain point. Note that this is *NOT* the > same as demanding that the webhosting peer become a transit customer. > Since they are only using regional transit I would expect that the prices > on the transit portion would be less than on a pure transit arrangement. > An interesting thought, but you are still shifting the burden of cost from the requestor of the data to the provider of the data. Why, for example, should University of California pay the cost of a customer in Dallas getting a copy of Sendmail off of ftp.cs.berkeley.edu from say Irvine to Dallas? It's actually pretty nice of them, in my opinion, to pay for it getting to Irvine. Is it unreasonable to ask the requestor to pay the freight for the rest of the trip? > However, for this to happen we would need some way to measure and quantify > this regional transit. To date I don't think anyone has attempted to do > anything like this except some Australian ISPs who have mapped the IPv4 > address space geographically so that they can manage their routing > according to the cost of various intercontinental links without relying on > somebody else's BGP announcements. I'm sure that we could use some sort of > similar geographical mapping of IPv4 addresses to quantify how much > regional transit a peer uses and thus establish a sliding scale between > a pure transit customer and a pure peer. > Only if you assume that the person sending the packet is responsible for the costs of it arriving. I don't think that's a proper economic model for the internet, as the larger packet is almost always the response to the requestor. > -- > Michael Dillon - Internet & ISP Consulting > Memra Communications Inc. - E-mail: michael(a)memra.com > Check the website for my Internet World articles - http://www.memra.com > > > Owen

1 0

Re: BBN/GTEI
by Paul Vixie 21 Aug '98

21 Aug '98

web(a)typo.org (Wayne Bouchard) writes: > IMO, asymetry is not a valid requirement for a private > interconnect. NOT having the interconnect hurts both companies. it hurts them asymmetrically though. or, that's the bet at any rate. regardless of whatever we all charge or pay that's measured in bits per second per month or whatever, the costs are all in terms of bit- miles. ultimately this means you can only peer with someone whose costs are similar to yours, almost regardless of the benefit they receive from peering with you. -- 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)

1 0

The Cidr Report
by Tony Bates 21 Aug '98

21 Aug '98

This is an auto-generated mail on Fri Aug 21 12:00:02 PDT 1998 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 21Aug98 0) General Status Table History ------------- Date Prefixes 130898 52878 150898 52681 160898 52695 170898 52882 180898 54822 190898 52846 200898 52926 210898 52842 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- AS Summary ---------- Number of ASes in routing system: 3903 Number of ASes announcing only one prefix: 1880 (974 cidr, 906 classful) Largest number of cidr routes: 351 announced by AS3561 Largest number of classful routes: 1189 announced by AS701 1) Gains by aggregating at the origin AS level --- 21Aug98 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS701 1189 955 234 19.7% Alternet AS3602 552 321 231 41.8% Sprint Canada Inc. AS271 337 146 191 56.7% BCnet Backbone AS4293 435 248 187 43.0% IMCI AS2493 387 229 158 40.8% iSTAR Internet, Inc. AS3749 224 67 157 70.1% TECNET AS174 717 583 134 18.7% Performance Systems International AS4200 195 100 95 48.7% AGIS (Apex Global Information Ser AS5668 130 44 86 66.2% Century Telephone Inc. AS2685 240 157 83 34.6% IBM Global Network - US AS4755 121 46 75 62.0% Videsh Sanchar Nigam Ltd. India AS4740 408 337 71 17.4% Ozemail Pty Ltd (ASN-OZEMAIL) AS3221 112 42 70 62.5% EENet Autonomous System AS7046 228 164 64 28.1% UUNET-CUSTOMER AS3804 214 156 58 27.1% Bell Solutions AS549 199 145 54 27.1% ONet Backbone AS3403 181 127 54 29.8% TIAC AS8517 124 72 52 41.9% ULAKNET-ASN AS10928 100 48 52 52.0% UNKNOWN AS719 462 413 49 10.6% LANLINK autonomous system AS6335 69 20 49 71.0% NTRNET AS72 87 39 48 55.2% Schlumberger Information Network AS1239 527 479 48 9.1% SprintLink Backbone AS4539 71 24 47 66.2% NETROPOLIS AS803 78 34 44 56.4% SaskNet Backbone AS1785 301 258 43 14.3% NYSERNet Backbone AS852 157 117 40 25.5% AGT Advance Communication AS6181 66 26 40 60.6% FUSE-NET AS7122 120 82 38 31.7% MTS ADVANCED Network Policy AS226 108 72 36 33.3% USC/Information Sciences Institut For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0

Re: BBN/GTEI
by Michael Dillon 21 Aug '98

21 Aug '98

On Fri, 21 Aug 1998, Brian Wallingford wrote: > If you don't peer with or buy > transit from GTEI, sit back, shut up, and watch and learn (seriously - > WATCH and LEARN). This is seriously good advice. A lot of people have compared this to the UUNet peering flap but the two incidents couldn't be more different. In UUNet's case you had John Sidgemore, an economist, attempting to throw his weight around and push towards a paid peering scenario with a cartel at the core, all of this based solely on an economics viewpoint. But with BBN, there is a network engineering problem at the core of the issue, that of assymmetric traffic patterns. And BBN realizes that this sort of assymmetry will become more and more common in the future and that the industry needs to find some sort of hybrid peering/settlement mechanism that will work for both parties in an asymmetric arrangement. They are looking at things like what kind of methodology can be used to measure the traffic, what constitutes free balanced peering, how to charge for regional transit on traffic that exceeds the limits of balanced peering, and similar difficult issues. I believe that the reason we are not hearing many details is that there are NDAs in place about the specifics of the Exodus, AboveNet and CRL peering contracts. But sooner or later those companies will come to some sort of agreement and BBN will explain the rationale behind their thinking. We may not totally agree with that rationale, but I think we can all see that establishing peering between two specialty providers has to be handled a bit differently than between two full-service providers. And if BBN's ideas can be refined and accepted by the industry, then we will be in a better position because there will be an established methodology and pricing structure for an ISP to transition from full transit to full peering. I know from my experience with Priori that a lot of peering negotiations happen like an old-boys club cartel and if you ain't a member of the club, you can't get in. We need to change this so that there is an open process by which anyone can transition to being a peer based on an open and accepted methodology and pricing structure. -- Michael Dillon - Internet & ISP Consulting Memra Communications Inc. - E-mail: michael(a)memra.com Check the website for my Internet World articles - http://www.memra.com

1 0

Re: intranet
by Hank Nussbacher 21 Aug '98

21 Aug '98

At 07:44 AM 8/20/98 PDT, Vince Fuller wrote: You might want to check out: Enabling Enterprise Multihoming with Cisco IOS Network Address Translation (NAT) http://www.cisco.com/warp/public/732/net_foundation/emios_wp.htm as well as: http://www.academ.com/nanog/feb1998/nat/index.html -Hank >> At 05:43 PM 8/18/98 +0800, william(a)pacific.net.ph wrote: >... >> >Proposed Solution: >> > >> >The 7010 router will be connected to the 2 ISPs. The 7010 will be upgraded >> >to an IOS that supports NAT; all IP address behind the 7010 will be treated >> >as internal IP addresses (to reduce reconfiguration). IP address subnets >> >from both ISPs will be NAT-mapped to internal IP addresses over the 7010, >> >including the DNS server and the mail server. >> > >> >The DNS will be configured to use their DNS as the primary name server. >> >The 2 ISPs' name servers will be used as secondary name servers. >> > >> >The mail server will be configured to have 2 IP address, one actual and one >> >virtual IP address using the network card. The DNS will have an MX 10 and >> >an MX 20, each pointing to one IP addresses for the network card. >> > >> > >> >Is this solution possible? Will it work? Did I forget anything? Any tips? >> >> That is one way to do it .. another and I think a BETTER way would be to >> only use 1 set of ip's ( a set that is "portable" ) and talk bgp with both >> providers. This way you can move the traffic in the most efficient way . If >> you take routes from both of em you may get a better path to site X from >> provider a and a better path to site Y from provider B . >> >> This way if provider a goes down the BGP will move trafic of the link that >> is still "GOOD" > >The NAT approach has the obvious advantage of being more "CIDR-friendly" >to the "global Internet". It is probably somewhat more complicated, but if >implemented correctly, it should provide reasonable redundancy and load- >sharing just like a "portable" address space solution. > > --Vince > >

1 0

MAE-East - Operational question
by Alex Bligh 21 Aug '98

21 Aug '98

Guys, Does anyone care about trying to get packet loss over MAE-East reduced any more? Some peers have quite heavy packet loss to them from where I'm sitting, and have done for a good while. It seems to me it's not a problem with my port, and I don't think I have head of line blocking problems, which means it's either a Gigaswitch problem, or their ports are simply full. Does anyone still hassle Worldcom and peers about this or have we lost hope of ever getting it fixed (i.e. people peer privately or hope other exchange points or a replacement will come along). -- Alex Bligh GX Networks (formerly Xara Networks)

3 2

Has anyone else besides me noticed lots of duplicated messages?
by Steven J. Sobol 20 Aug '98

20 Aug '98

A lot of mail messages sent from the NANOG list seem like they're being duplicated. Also, I'm getting several messages in my inbox. My procmailrc is supposed to throw anything marked "Sender: owner-nanog(a)merit.edu" into my nanog folder... Wondering if anyone else has seen this happening... -- Steve Sobol, Cartel Member #1489 (tinc) Quote of the year: "If Bill [Gates] were tan, buffed and weighed 240 pounds, I bet people would dig IS." - Michael Cohn, COMPUTERWORLD Magazine, 8/3/98.

2 1

Re: MAE-East - Operational question
by Richard Irving 20 Aug '98

20 Aug '98

Communism, *NOT* marxism. Lets see: router> conf t router> int nanog 0 router> no ip directed-communism router> access-group 66 IN router>^z router> router> access-list 66 deny MARXISM router> access-list 66 deny _POLITICS_ router> access-list 66 deny POLITICAL_PARTIES router> access-list 66 permit PHILOSOPHY router> access-list 66 permit IDEAOLOGY router> And now I leave the remainder of this discussion to OFF NANOG. (and your local Poli-SCI PHD) This config doesn't seem to be helping my routing much.... But, in your defense, I am actually saying the opposite of what you *think*. (I am saying it *doesn't* work , but making a distinction between the ideology, and "supposed" implementations going by that name, that *fine grained* distinction *is* the point :( The depths of greed that *some* of humanity exhibit, being the fatal flaw for both plans. (FDDI&COMMUNISM) .) (Darn lasers!) foo wrote: > > Richard Irving wrote: > > *Pure* communism was a great ideaology! However, > > its failure, for the most part, was cited > > as "not accounting for human nature" > > as if. > > that's the most often heard, and most false statement > one can make about communism. > > try actually reading communist literature, and see if > you think marxism is such a great idealogy. > > -foo

1 0