- NANOG - lists.nanog.org

Re: BBN Peering issues (fwd)
by Sean Donelan 18 Aug '98

18 Aug '98

>It is in content-owners' interests to encourage the trend >also, as ultimately their brand is the one that is hurt >by unreliability. Yes, it might hurt carrier X's business >when carrier X cannot get to Popular Content Site, but some >fraction of carrier X's customers will go away thinking, >"performance to Popular Content Site sucks! Popular Company sucks!" It is interesting to see how things are sorting out. Yes, content owners are concerned about this, but the solution may not be good for the diversified carriers. I suspect you are going to see more deals like AOL's TeraPOP project. Networks with large content owners are connecting directly with networks with large users bypassing the usual backbones in the process. The diversified carriers are being relegated to managing the banks of modem pools. One thing which will really kill your stock price is if investors get the idea your portion of the market is about to turn into a commidity. The term 'disintermediation' is often used to describe how commerce will develope on the Internet. Diversified backbone providers serve a useful purpose while the market is fragmented. But the very centralization which makes the 'synergy' referenced in many of the mergers also sows the seeds of bypass. On one side you have the large access concentrators such as AOL, Earthlink, Mindspring; on the other side large content concentrators such as GlobalCenter, Exodus. What purpose does the carrier in the middle serve? >Moreover, as the capacity market distortions are sorted >out in many places, it almost certainly will be cheaper >for content owners to spread the work of distribution around, >so that the traffic stays as local as possible. Yes and no. There is a tension or balance between distribution and centralization. I don't think it is possible to make a blanket statement one style or another will be cheaper. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Re: BBN Peering issues (fwd)
by Sean M. Doran 18 Aug '98

18 Aug '98

Owen and company - Forgive me this indulgence of my more immature side, but I will not reply to you. Should someone else ask these questions or make these observations, I will be happy to provide a careful response. Sean.

1 0

Re: BBN Peering issues (fwd)
by owen＠DeLong.SJ.CA.US 18 Aug '98

18 Aug '98

> ftp.gatekeeper.com, like all content hosting sites, attracts > users to one location, when it could instead attract users to > the same content in multiple locations. > Please explain why you believe this to be universally true of content hosting sites. Especially when you consider that Exodus has been a leader in promoting distributed fault tolerant services to its customers. > This is inefficient. > Agreed. However, assertion 1 being false, the corollary seems less relevant. > Many archive sites direct people to mirrors topologically closer > to them, and as more actual content owners purchase duplicate sites > in places like Europe (http://www.europe.cnn.com, > http://www.yahoo.{se, .co.uk, .ca}) both for the technical gains > and also as a means of strengthening one's brand globally. > And many content providers use various products for redirecting requests to the topologically closest mirror. The result is actually better in many cases, as no manual intervention is required by the user, and the system usually measures topological closeness instead of making geographical recommendations. > This is much more efficient. > > This should be carried on. > Agreed. > It is in carriers' interests to encourage the trend too, > and it is probably a good idea to work out means of hosting > content more locally than data centres in California, > as a means of increasing network efficiency. > Also agreed. What makes you think Exodus, for example, only has datacenters in California? We currently have customers live in Seattle, Santa Clara, Irvine, Waltham, Jersey City, Herndon, and London. > It is in content-owners' interests to encourage the trend > also, as ultimately their brand is the one that is hurt > by unreliability. Yes, it might hurt carrier X's business > when carrier X cannot get to Popular Content Site, but some > fraction of carrier X's customers will go away thinking, > "performance to Popular Content Site sucks! Popular Company sucks!" > True. However, a good percentage of them will call carrier X or Popular Company, or Popular Company's ISP first. > Moreover, as the capacity market distortions are sorted > out in many places, it almost certainly will be cheaper > for content owners to spread the work of distribution around, > so that the traffic stays as local as possible. > Yep. At least three hosting companies I know of are trying to lead the way on technologies and business models to encourage this. Given that, I simply cannot see your statement that the hosting companies prevent this as being anything but specious. > Sean. > Owen

1 0

BBN Peering issues
by cheops POP 18 Aug '98

18 Aug '98

If your traffic is largely based on "client" side applications then guess what, your gonna have a lot of in-bound traffic. This is like AT&T whining about MCI clients calling their moms who have AT&T long distance and not collecting on that usage! If your business model doesn't account for such asymetrical behaviour what are ya gonna do?, ask mom for a charge on her incoming calls?) It looks to me like someone ought to be looking at what is good for the customer and what makes good business sense even though the two hardly ever merge.=) -pete Peter E. Giza Black Pearl Software & Consulting Inc. www.blackpearl.net 603.883.9774

1 0

Re: BBN Peering issues
by Dean Robb 18 Aug '98

18 Aug '98

At 14:20 8/13/98 -0500, you wrote: >That is one thing I don't understand about the aversion to peering. We >peer with anyone who will either pay the line costs or connect to us over >Bell FR, where the costs are negligible. Granted, we are small potatoes in >the ISP field, but to my way of thinking both parties benefit. There is >a customer here communicating with a customer there. Both ISPs are getting >money from their customer to get connectivity to the other ISP's customer. >Dropping the peering connection degrades connectivity for both ISPs' >customers. On the macro, non-technical side of things...this move also degrades the very cooperative nature of the Internet (which is getting less cooperative by the day). It used to be "we're all one big family...c'mon in!" but now it's "you must not only pay your own way, but pay part of our way as well or you can't come in!". Pay per play, all the way. Wanna be on the Internet? Bring your Platinum card. The next step will be "you must pay a hefty price for every packet transitting our pipes", directing transitting (packets only going through specified routes) and strong-arm tactics on the smaller players to sign up with one specific network. Then you'll see regulation akin to what telcos have, with the concommitant expense. Sorry, Pandora...the box is open and Woe is on the loose. Wabbit season!..duck season!..wabbit season!..duck season!..SPAMMER SEASON! Dean Robb PC-EASY computer services (757) 495-EASY [3279]

3 2

intranet
by william＠pacific.net.ph 18 Aug '98

18 Aug '98

Hi all! Just wondering if the following is possible: Situation: Corporate intranet is currently connected to 2 separate ISPs using 2 different set of IP addresses. When one is down, the network has to be reconfigured for access via the 2nd ISP. Required Result: Corporate intranet connects to 2 ISPs. When one is down or unavailable, traffic will automatically shift to the other connection. DNS server and mail server remains inside the intranet. The DNS and mail servers should not be reconfigured during any problems and should keep on working. 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? William

1 0

Re: BBN Peering issues (fwd)
by owen＠DeLong.SJ.CA.US 18 Aug '98

18 Aug '98

> howland(a)Priss.com (Curt Howland) writes: > > > The 'Net gives some measure of universal connectivity because it > > was driven at its root by engineering. Who on NANOG, with any real > > world experience in networking, denies that maximum open peering > > benefits everyone? > > Well, I dunno if I'm qualified by that measure. At the time I built > networks, I'd built at least one of the largest anywhere. But they > were all small compared to today's second tiers, and I'm not building > networks any more. > :-) > But I deny your assertion. Maximum open peering benefits some people > more than others -- specifically the ones who get to charge the most > money yet who pay the least in infrastructure upkeep. A web hosting > company doing shortest-exit (no matter how many peering points they > were at or how much private peering they had) would be an example. > There are two key points to be made here in the general case, and one of a more specific nature. 1. As you stated, benefits some more than others. That statement alone agrees with Curt's assertion that it benefits everyone. You merely state that said benefit is not equally distributed. I'll give you that, to some extent, but not completely. 2. A hosting company doing shortest-exit doesn't necessarily receive more benefit from that peering that the people they peer with. Afterall, the majority of the traffic a web hosting company delivers to any other provider is traffic that other providers customers requested from the web hosting company. As such, it really should be, in most cases, up to the requestor to pay the freight, don't you think? Afterall, when you order something over the phone, they don't usually give you free shipping, and if they do, guaranteed, it's part of the price of the product one way or the other. Same basic scenario here. The more specific point: What about a hosting provider that is willing to honor all MEDs provided by the other provider? That changes the model pretty substantially, doesn't it? If the other provider puts out good MEDs, and the hosting provider honors them, then the other provider is arguably getting the greatest benefit out of the relationship. However, in general, most of the credible hosting companies I have talked to are willing to honor MEDs in peering relationships and are willing to peer at the least on an East+West basis, and often, more geographically specific than that. > Remember as you puzzle your way through this issue that peering is > only mutually beneficial if the number of bits (not packets) sent by > each side is in the same order of magnitude. If the O(mag)'s differ > then the costs/benefits are one-sided, and the side who is underwriting > wide area transportation costs for people who aren't paying it money > is going to get bent about it. > Again, I disagree. If provider A's customers want data from provider B's customers' servers, then peering is mutually beneficial. Maybe not equally beneficial, but definitely mutually beneficial. The assumption in that statement above is that the transmitter should always shoulder the cost. That's not, necessarily, IMHO, the correct model. I think that the requestor should shoulder some portion, and the transmitter should shoulder some cost. I'm not completely sure what those ratios are. However, if you change the view to one more like mail-order goods, then provider A is collecting money from his customers to cover the freight for whatever goods they request from the customers of provider B and any others. If provider Bs customers feel that they want to subsidise provider A's customers reaching their content, then that's a different issue. Let's face it, there's lots of different ways to look at the costing model on this one and who should shoulder the cost is not really clear to me. > Anyone with a strong enough constitution to check the archives on this > matter will find that Sean and I had a raging battle here about this > very topic back in 1993 or so. What interests me on this particular > night is my memory of asking Vince "so what about gatekeeper.dec.com? > why should i have to pay to transmit the FTP archives?" Vince didn't > answer because the obvious answer ("gatekeeper should be charging money > so it can cover its costs and the costs of the folks who carry those > bits") was one I was not at that time ready to hear or understand. Although that may be the obvious answer to you, Paul, I'm not sure it is the correct answer. Afterall, the people downloading from gatekeeper could similarly cover the same transit costs if gatekeeper was left out of the situation, and instead, the providers with which they already have a business relationship were simply to bill a more appropriate amount for the service they provided to those same customers. Admittedly, it may be easier to convince the gatekeepers of the world than the bulk of the customers on the net, but the same people end up paying one way or the other. It's just a question of how complicated you want to make the accounting in between and how many bills they have to pay from how many sources. > -- > 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) > Owen

1 0

Re: DNS Headaches.
by Paul Vixie 18 Aug '98

18 Aug '98

> > . 2D IN NS PANIC.WEBTEAM.NET. > > . 2D IN NS TORGO.WEBTEAM.NET. > > PANIC.WEBTEAM.NET. 2D IN A 207.67.50.8 > > TORGO.WEBTEAM.NET. 2D IN A 207.67.50.7 > > How did this happen anyway? InterNIC? Postel? M.I.B.H., no doubt. > Doesn't this error imply that a percentage of the > Internet was unresolvable by the entire planet? Luckily not. Those servers are running with recursion enabled. So they sent back a lot of nonauthoritative answers, which were treated as server failures but forwarded anyway. At least BIND would have done that. Had the above servers been configured with recursion disabled, then the above delegation (coming as it did as an authoritative answer from a bootstrap source -- A.ROOT-SERVERS.NET) would have pretty much rocked the e-commerce market. Thus do we see that the least secure part of DNS are the procedures and people, not the protocols or implementation. That's not a slam on the InterNIC, but it could be correctly taken as a hint that the new IANA has some serious procedural work to do regarding change control and publication. I'm not sure what non-BIND servers did, of course. (They aren't common yet.) > Maybe we can get bilateral peering with BBN since we have a root server, That's what worked for me :-). Except that I'm perfectly willing to say in public that I get transit connectivity from BBN (and others) and it's great. -- 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

Re: BBN Peering issues (fwd)
by Paul Vixie 18 Aug '98

18 Aug '98

howland(a)Priss.com (Curt Howland) writes: > The 'Net gives some measure of universal connectivity because it > was driven at its root by engineering. Who on NANOG, with any real > world experience in networking, denies that maximum open peering > benefits everyone? Well, I dunno if I'm qualified by that measure. At the time I built networks, I'd built at least one of the largest anywhere. But they were all small compared to today's second tiers, and I'm not building networks any more. But I deny your assertion. Maximum open peering benefits some people more than others -- specifically the ones who get to charge the most money yet who pay the least in infrastructure upkeep. A web hosting company doing shortest-exit (no matter how many peering points they were at or how much private peering they had) would be an example. Remember as you puzzle your way through this issue that peering is only mutually beneficial if the number of bits (not packets) sent by each side is in the same order of magnitude. If the O(mag)'s differ then the costs/benefits are one-sided, and the side who is underwriting wide area transportation costs for people who aren't paying it money is going to get bent about it. Anyone with a strong enough constitution to check the archives on this matter will find that Sean and I had a raging battle here about this very topic back in 1993 or so. What interests me on this particular night is my memory of asking Vince "so what about gatekeeper.dec.com? why should i have to pay to transmit the FTP archives?" Vince didn't answer because the obvious answer ("gatekeeper should be charging money so it can cover its costs and the costs of the folks who carry those bits") was one I was not at that time ready to hear or understand. -- 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

Re: The Cidr Report
by Tony Li 18 Aug '98

18 Aug '98

> > | AS762 118 81 37 31.4% WELLFLEET-AS > > Oddly enough, they are announcing the aggregate *and* the specifics: > > > brd1>sho ip bgp reg _762_ > *> 192.32.0.0/16 207.106.96.5 0 4969 6461 1673 > *> 192.32.2.0 207.106.96.5 0 4969 6461 1673 > *> 192.32.3.0 207.106.96.5 0 4969 6461 1673 > *> 192.32.4.0 207.106.96.5 0 4969 6461 1673 > *> 192.32.6.0 207.106.96.5 0 4969 6461 1673 If one were paranoid, one might imagine that they are doing so intentionally to see how many Cisco routers they can tank through prefix overload. The problem with this is that a) they aren't also announcing the /17's, /18's, ... /25's and b) overloading a Cisco seems to mean that someone buys a bigger Cisco, thereby enhancing Cisco's revenue stream. One is then left with the theory that they are advertising more specifics for optimality, but haven't discovered communities yet. Exercise for the reader: If prefixes of length F and longer are filtered, and a domain has a prefix of length N, how many prefixes can they propagate into the backbone? How many before people start proxy aggregating them? Tony

1 0