October 1996 - Test - lists.nanog.org

Re: Ungodly packet loss rates
by John Curran 23 Oct '96

23 Oct '96

At 20:38 10/22/96, Gordon Cook wrote: >John, you say there is no benefit to be gained by large providers using >anything other than private inter-connects. may i refine that question >slightly and ask: benefit **to whom?** to the large provider? If the >question of benefit is limited in this manner, i'd guess that your >statement is quite correct. Gordon, It's not a question of large or small; it's a question of traffic volume. Creating multi-provider interconnects makes sense, right up until the aggregation pushes the technology into a higher-cost or higher-risk category. It's hard enough getting stable high-speed equipment; intentionally bringing multiple high-speed traffic flows together when you can easily do a mesh of private interconnects makes little sense. >When you get big enough, you to can connect to the internet at the very >apex as demarcated by major naps in the us and soon in asia and europe. > >*BUT* here is my question. Don't private interconnects essentially >provide a new apex for the internet? One that pushes interconnects at the >major exchange points down a level. >... >now you may say that from a competitive point of view this makes no >difference. perhaps. But what if the big four no longer see the need to >upgrade their bandwidth INTO and OUT OF exchange points? For relatively small traffic volumes, the shared interconnects work fine. Upgrading the bandwidth INTO and OUT of these points is definitely happening, but there's often a higher payoff in taking a major flow off the public interconnects into a private interconnect. Providers do have good reason to upgrade their public interconnects but principally after this phase of major traffic migration to private interconnects has been completed. /John

1 0

Re: Cisco Memory.
by Greg Ketell 23 Oct '96

23 Oct '96

Actually it is not on CCO due to potential legal issues (we list unapproved as well as approved and that made our lawyers squeamish). However, you can call the TAC and give them your info (router model, existing RAM) and they can then look up the info on the internal TAC webserver and give you the appropriate authorized list. Before I was made painfully aware of the legal issues I posted the list to inet-access if anyone wants to dig through the archives (it was only about 2 months ago). GK At 07:22 AM 10/22/96 -0400, you wrote: >At 09:17 PM 10/21/96 -0700, Craig A. Huegen wrote: > >> >>There is a list of third-party RAM that Cisco approves, and this list is >>available on CCO *somewhere*. I don't remember where, though; Paul >>Ferguson is really good at remembering where this stuff is, though. >> > >I poked around for a few minutes without finding the 'approved alternate >vendor list', but I recall that its there *somewhere*. > >- paul > > >

1 0

Re: AADS outage
by Jeffrey S. Curtis 22 Oct '96

22 Oct '96

Joseph Klein writes: }The AADS outage started (for some) about 23:30 GMT and ended about }02:45 GMT. For us, it started at 2140Z, and as you indicate, everything came back up around 0245Z. I still have one BGP session down, though... ... and as I typed that, I got a call from AADS. Everything looked clean through the NAP, so odds are that this last remaining problem is on the other provider's end. } Did the outage at AADS have a major impact on the other }meet points? I know we dumped a bunch of traffic on MAE-East }and MAE-West. The graphs from the AADS Web page (http://nap.aads.net/~nap-stat) show that the switch tends to average about 100Mbps aggregate load over hourly sampling intervals, if that gives you any insight. Jeff -- Jeffrey S. Curtis | Internetwork Manager Argonne National Laboratory | Email: curtis(a)anl.gov 9700 South Cass Avenue, ECT-221 | Voice: 630/252-1789 Argonne, IL 60439 | Fax: 630/252-9689

1 0

Re: Ungodly packet loss rates
by Sean Donelan 22 Oct '96

22 Oct '96

>While there is no difference from a technology perspective, >there's also no benefit to be gained by interconnecting large >networks at a public (as opposed to private) interconnects. The benefit is about the same as aggregating traffic through a backbone circuit versus having separate circuits connecting each traffic source and destination. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

AADS outage
by Joseph T. Klein 22 Oct '96

22 Oct '96

The AADS outage started (for some) about 23:30 GMT and ended about 02:45 GMT. Did the outage at AADS have a major impact on the other meet points? I know we dumped a bunch of traffic on MAE-East and MAE-West. -- /*Joseph T. Klein * Keep Cool, but Don't Freeze * NAP.NET, LLC * * phone +1 414 747-8747 * - Hellman's Mayonnaise * http://www.nap.net */

1 0

RE: The Curse (was Re: Ungodly packet loss rates)
by Chris A. Icide 22 Oct '96

22 Oct '96

---------- Further proof that the NANOG mailing list is cursed. All this talk about whether it's better to have one big NAP or lots of little NAPs, and just to prove the point, the AADS NAP in Chicago has to blow up. Well, I'm all for one BIG MONSTER NAP so that when it dies, then all of my competitors all die too. :) Oh, BTW, at least the NAP didn't take the long trip while everyone was on their way to NANOG. Oh, and anyone know anything about ATM Signalling? I was playing with my chicago border switch, and truned on signalling toward Ameritech, and I got some cool stuff back and then nothing <evil grin> Chris

1 0

The Curse (was Re: Ungodly packet loss rates)
by Jeffrey S. Curtis 22 Oct '96

22 Oct '96

Further proof that the NANOG mailing list is cursed. All this talk about whether it's better to have one big NAP or lots of little NAPs, and just to prove the point, the AADS NAP in Chicago has to blow up. (We're currently at an hour and a half since all of my BGP sessions reset; Ameritech tells me they're closing in on the problem with the switch and should be back up Real Soon Now (tm)...) Jeff -- Jeffrey S. Curtis | Internetwork Manager Argonne National Laboratory | Email: curtis(a)anl.gov 9700 South Cass Avenue, ECT-221 | Voice: 630/252-1789 Argonne, IL 60439 | Fax: 630/252-9689

1 0

RE: Ungodly packet loss rates
by Chris A. Icide 22 Oct '96

22 Oct '96

>> While there is no difference from a technology perspective, >> there's also no benefit to be gained by interconnecting large >> networks at a public (as opposed to private) interconnects. > >Sure there is. Running one larger interconnect has the potential to >be much less expensive and easier to run than many smaller ones. >Economy of scale... unless, you happen to be one of the major networks, and there are a hundred people each feeding you say, 5M, and all of the sudden you have to deal with 500M over one link/fddi port. Also, just to play devil's advocate, just what exactly is the definition of "peer"? Who is a peer to who? Is network A (with 200 routes) a peer to Network B (with 15,000 routes)? Chris

1 0

Re: Ungodly packet loss rates
by Tony Li 22 Oct '96

22 Oct '96

JBash, In my experience, the primary technical factors that are hurting Internet reliability at this time are roughly (in no particular order): 1) Poorly performing routers. I would estimate that 50% of the packet loss in the Internet today is wholly unnecessary and results soley from defective gear. The route cache paradigm (and subsequent cache thrashing) in current cisco product, the lack of memd, missing high performance interfaces, and the lack of backplane bandwidth are all grave problems. I will certainly accept some personal culpability here, but cisco has had far too long to get its act together and has not responded. I refer you to Mr. Bilger for further progress. 2) Lack of bandwidth. There are frequently cases where the bandwidth simply does not exist. This may be due to lack of planning, lack of will, greed, or whatever. Only economics will drive this forward. 3) Poor engineering. The number of ISP's who have no idea what they're doing is still quite high. I refer you to Greg, Ravi, et. al. for war stories on what really happens. 4) Lack of routing scalability. You expressed amazement that the BGP mesh still holds together. My amazement exceeds yours. A new generation of protocol is needed which, if nothing else, is much easier to manage, and can scale to larger domains. You know some of the kludgery that was done to aid this scaling. It's time for a new generation which incorporates this as the base. Unfortunately, this isn't useful without #1. Given this _technical_ environment where literally no one _CAN_ succeed in delivering volume quality Internet connectivity, I'm not surprised that you've gotten evasive, defensive, and non-sensical replies. I wholeheartedly agree that the service level of the Internet as a whole is pathetic, but given the above situation, your efforts are better spent internally at cisco rather than trying to perform external social engineering. Once the technical situation improves, the market will eliminate those who (for whatever reason) are unable to deliver. If the technical situation does not improve shortly, the market will simply eliminate the Internet. ;-( Regards, Tony

3 4

Re: Ungodly packet loss rates
by Tony Li 22 Oct '96

22 Oct '96

> While there is no difference from a technology perspective, > there's also no benefit to be gained by interconnecting large > networks at a public (as opposed to private) interconnects. Sure there is. Running one larger interconnect has the potential to be much less expensive and easier to run than many smaller ones. Economy of scale... That's simply a fallacy. One larger interconnect assumes that the cost of aggregate bandwidth scales linearly, when it fact it's clearly super-linear and may well be exponential. This becomes worse as supporting the aggregate bandwidth exceeds commodity media technology. Tony

1 0