- NANOG - lists.nanog.org

Re: Peering with a big web farm (was Re: BBN Peering Issues)
by Sean M. Doran 13 Aug '98

13 Aug '98

| If BBN wants to sell connectivity to a big web farm provider, how does | BBN's forcing all hits through a cache help BBN? The data all still | crosses BBN's backbone, and the the web farm provider won't need as big a | pipe. Maybe I'm missing something, but if BBN starts charging former | peers, I'd think caching at these edges would be a bad thing for BBN. Again, keeping this in the realm strictly of "how to build this", rather than "is this a good idea, is this moral bla bla bla", what one wants is a hierarchy of caches with the one cache you're thinking of at the apex, and the others scattered throughout the backbone. Alternatively, one might have a few duplicate caches, with content distributed by, for example, reliable multicast, or some other technique with the explicit goal of sending no more than one copy of the content per link. The thing that you are forcing traffic through is, indeed, an intercepting device, which lives directly in front of the peering line. It could do one of a number of strategies, for example, accepting the first hit and redirecting all subsequent transfers to one of it's hierarchical children or distributed copies. It could also intercept and rewrite all the DNS queries that happened to arrive at it bound for the peer in question, and answer back giving the addresses of the appropriate more-local child/copy caches, avoiding taking the first TCP connection in the first place. A neat project would be to think about the application layer "non-"gateways one would want beyond WWW. FTP comes to mind, of course, as does NNTP. Real Video etc. are of course other likely targets. Basically, I suppose the thought is that one could soundly engineer and operate a peering with a "content-hosting ISP" (big web farm/ ftp archive) which reduces the bandwidth requirement to one copy per new piece of static content, plus whatever level of properly dynamic content there might be, at the cost of some disk space per peering (the interceptor border device and the distributed child/copy caches can be shared among multiple peering connections). Again, issues of morality, how one could do a contract to do this, and the like are more appropriate to com-priv. Anyone who has actually experimented with things vaguely like this (Ed? Curtis?) and who has operational advice is on-topic for NANOG, however. Sean.

1 0

Network Value
by Leo Bicknell 13 Aug '98

13 Aug '98

The BGP peering issues that have recently come up really come directly from a disagreement about what constitutes network value. I think by now we all realize that peering is a sort of quid pro quo, where both parties get some value from the deal. Traditionally, this was an easy thing to assess. Large backbone providers tend to have a a nice mix of dial-up users, content providers, and everything in between. Measuring the "value" they bring to the table could easily be qualified by a traffic study. In the brave new world this isn't the case. One can easily argue that a dial-up only provider and a content hoster should peer. Each brings value to the relationship, but the traffic distribution will be highly asymmetrical. In this situation what metrics do you use to assess the value of the peering arrangement? Is there a good metric like number of users, or number of flows that you can use to measure value? Does value have to be something that only a human can determine with lots of subjective measures? Has anyone tried to qualify the value of a network for such purposes? I'd be interested to know the details about that process. If you are able to find a value, can you then move to a "price / performance" ratio by determining the cost of the peering session? I suspect this is more difficult to determine than the wealth of the network, at least over shared peering points where the direct cost for a single peer is not a line item. Possibly the most difficult question of all, is there any value to everyone using the same metrics? Ignore the problems with creating a suitable metric, but if one existed that ranked all providers from say, 1-10, do you think it would have a positive or negative effect on peering arrangements? I welcome public and private discussion, but hope to avoid any current issues (for fear of a flame war). :-) -- Leo Bicknell - bicknell(a)dimension.net Network Engineer (CCIE #3440) - Dimension Enterprises 1-703-709-7500, fax, 1-703-709-7699

3 2

ntp code for cisco
by SHELLEY, MIKE 13 Aug '98

13 Aug '98

Did you ever find a cisco router config for running a gps over the aux port? I am trying to do this. Thanks

1 0

RE: BBN Peering issues
by Mike Gaddis 12 Aug '98

12 Aug '98

Large access oriented companies like BBN, MCI and others have been keen to point out the problem with the so called web-farms. In the early days it clearly was a problem because the costs associated with carrying bandwidth were not evenly matched between a large distributed (and costly) access network and a MAE attached data center. It created an economic disparity that could not be sustained. Let's recognize the validity of that argument. Many of us (in the Brokered Private Peering initiative) have been looking for ways to solve that disparity and to create a fair value proposition between both types of networks. The best mechanism we have found is for the web-centric companies to have regionally distributed connect points and substantial backbone capacity to perform best-ingress or cold potato (from web to access point of view) routing. In our view, this model reverses the negative value proposition into highly favorable terms for the access company. After all, their customers want access to these Web sites and the service is now dropped off regionally, saving considerable backbone expense for the access company. That Exodus is doing cold potato and BBN does not find this sufficient to consider Exodus a true peer causes me some concern. It makes one wonder if there is a solution to this peering problem after all. I don't want to see the government intercede without at least trying to find peering balance. I believe Exodus has shown great willingness to "do the right thing here." This can develop into a backbone civil war and I think BBN will not fair well if that occurs. (There are major web sites being cut off if this break in peering happens. Believe me, BBN customers will care a great deal.) I don't see the upside in this decision. I truly hope that cooler heads prevail, and soon, or major parts of the network may black out for many thousands of Internet users. This will cause major harm to the Internet market and the perception of any-to-any connectivity. This will likely demand government intervention. Not good. Mike Gaddis CTO Savvis Communications -----Original Message----- From: alex(a)nac.net [SMTP:alex@nac.net] Sent: Wednesday, August 12, 1998 4:39 PM To: Robert Bowman Cc: dg(a)root.com; michaels(a)sun.aracnet.com; asr(a)millburn.net; nanog(a)merit.edu; alex(a)nt.nac.net Subject: Re: BBN Peering issues On Wed, 12 Aug 1998, Robert Bowman wrote: > I've tried to stay away from posting here, but a small clarification... > > Exodus is currently dealing with the asymmetry of traffic by assuming > a large chunk of the burden by doing best-exit, at BBN's request, based > upon BBN's MEDs. So let's not make it into the argument that the "evil" > web hosters are just dumping recklessly via shortest-path out. Exodus > has assumed the cost of all long haul delivery coast-to-coast of the > data that BBN's users are requesting. Heh, that makes it look even worse for BBN now and potentially in the future, depending on what Exodus chooses to do. It's amazing that they shot thierselves in the foot like this.

1 0

CO failures (was Re: Today's Outage)
by Sean Donelan 12 Aug '98

12 Aug '98

>[CO down..] > >All the more reason hospitals, etc. should shun Centrex, imho. >It's putting all your eggs in one basket... Ameritech wiped out a CO a few weeks ago while working on the SS7 link at 2pm in the afternoon. One of the hospitals affected is pretty peeved about that. I've gotten used to techs trashing my data circuits at peak times, but I thought they knew better than to mess with a SS7 datalink in the middle of the day. Many electrical outages went unnoticed by the public, until the introduction of digital clocks. After that, the public started to notice the outages everytime their clocks started blinking 12:00. I suspect the Internet is starting to do the same thing for the telephone system. The phone system had many mini-outages which the public rarely noticed unless they happened to be using the phone at the exact moment. Now computers and the Internet are serving the same function as the blinking 12:00 on digital clocks. Any blip in the phone system is magnified by the other connected systems. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Re: BBN Peering issues
by Sean M. Doran 12 Aug '98

12 Aug '98

Thanks to Dave Rand for trying to reduce the amount of traffic that this thread might otherwise generate. Please, direct all public comments on GTE's (or anyone else's) peering *policies* to com-priv. Sean.

2 1

Re: Today's Outage
by Sean Donelan 12 Aug '98

12 Aug '98

>> Well, today's outage is a small one. Southwestern Bell lost power >> to their central office in Ladue, Missouri (just outside of St. Louis). >> This affects all local telephone service in Ladue and several >> surrounding communities. No big deal, except our Network Operations >> Center happens to receive its local dial tone from the Ladue central > >No big deal for yourselves maybe, but we had several hundred ISDN >customers hammer or NOC at that time, since all BRI's in SE MO are served >out of that CO. The preliminary report says 66,000 phone customers lost phone service for about two hours. The CO outage also affected 9-1-1, hospital and other emergency services for 5 cities and surrounding areas. I'm assuming this is only counting POTS service because we saw some ISDN and data circuits out-of-service for 10-12 hours. Unfortunately due to Southwestern Bell corporate policies, I can't conduct the usual 'due diligence' I do with our CLEC providers. Finally around 5am, Southwestern Bell started accepting trouble tickets again. They wouldn't accept them earlier until their techs gave the 'all clear.' >I did talk to someone about the problem, but unfortunatly, SWBT has moved >their NOC to KC and they were clueless to the problem, and their battery >ran dry, and the generator failed to start. Cluelessness is not an attribute restricted to ISPs. Southwestern Bell's official spokesperson was quoted: "Cordless phones won't work during power outages because they need electricity to operate. As a safety precaution, he recommended keeping a spare corded phone." Oops, I think he picked up the wrong script. He needed the Central office failure script, not the Cordless phone failure script. When I was growing up, my next door neighbor was the president of Southwestern Bell Telephone and we got phone service out of this same Central Office. I guess things have declined a bit since the current president moved the corporate offices to San Antonio, Texas. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

2 1

Re: He's baaaaaaack...
by J.D. Falk 12 Aug '98

12 Aug '98

Honestly, even as an abuse guy, I really can't see what Sanford Wallace's current activities have to do with anything. He is no longer spamming. He is not abusing the net in any new and interesting (or even old and boring) manner. Why should we even care that he's alive? -- J.D. Falk <jdfalk(a)cp.net> http://support.cp.net/AUP/ Special Agent In Charge (Abuse Issues) Critical Path, Inc.

1 0

How much will the cpu load increase when I apply CAR at C7513?
by Woohyun Chang 12 Aug '98

12 Aug '98

some WAN interfaces R1 R2 some WAN interfaces -----------C7513 C7513------------ | | |fe |fe ======switch======= R2: C7513 RSP2 no VIP card cpu load: 18% FastEthernet: outbound: 6Mbps inbound: 22Mbps Cisco IOS 11.1.18CC RED is not available because 11.1.18CC does not provide RED without VIP card. The input queue at the FastEthernet of R2 is insufficent because there are many inbound packet more than outbound packet into some WAN interfaces at R2. Therefore, packet drops happens at Fastethernet of R2. I tried to increase the input queue of the FastEthernet of R2, and I found that that is useless. So I'll try to apply CAR(committed access rate). I have two questions. 1. If I apply CAR at FastEthernet of R2 for inbound traffic, how much will cpu load of R2 increase? I hope that the cpu load does not increase very high. The condition for the classification of IP traffic will be very simple. 2. Is it possible that my work applying CAR will fix the packet drops at FastEthernet? Will my work make queue available faster than before? Regards, /woohyun chang whchang(a)bora.net BORANet Services DACOM Corporation Seoul, Korea TEL+82-2-220-5209

1 0

Today's Outage
by Sean Donelan 12 Aug '98

12 Aug '98

Well, today's outage is a small one. Southwestern Bell lost power to their central office in Ladue, Missouri (just outside of St. Louis). This affects all local telephone service in Ladue and several surrounding communities. No big deal, except our Network Operations Center happens to receive its local dial tone from the Ladue central office. I guess that's one reason we have backup operations staff in Monterey California. Competition is also nice. We have a couple of other facility based carriers built into our building. Besides local dial tone, all the Internet services failed over to other carriers without incident. It did take a few minutes as people tried to isolate which phone numbers worked (e.g. long distance) but not other phone numbers (e.g. local, outbound 1-800, 9-1-1, etc). Time on hold to reach a human at Southwestern Bell repair service about 20 minutes. How many NOCs have contingency plans for reaching their local phone company when their local phone service is not working. I reallly, really, really hate companies which have only 1-800 numbers for their customer service centers. Any alternative carriers care to schedule an appointment for a presentation on your facilities based alternate local service offerings? People just reselling unbundled network elements from Southwestern Bell are in the same boat as SWBT. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

2 1