- NANOG - lists.nanog.org

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

23 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 23 Oct '96

23 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 23 Oct '96

23 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

More hardware design (was Re: GigaRouter)
by Alexis Rosen 22 Oct '96

22 Oct '96

[Figured it was about time to change the subject line...] Speaking of hardware design, I've got a few misc. questions and comments. These are geared towards building servers for remote use that are *not* routers, but rather light- to medium-load webservers and the like. Does anyone know of a *small* rackmount case for PCs? By this I mean one that doesn't chew up quite so much vertical room as the usual boxes. Does anyone know where to get a CPU card with integrated SCSI and video? Alternatively, integrated SCSI and ethernet. I know about the PEAK 520S. TJLS claims that it's got serious problems, and even if it does work, it uses the SIS chipset, and thus loses big on memory access. I want something that can boot NetBSD or BSDI. One of the annoying problems using an intel box instead of a sun is that there's no real console. If it dies, the only way to kick it remotely is with a remote-control power switch. These are expensive and unwieldy, not mounting nicely in racks. In lieu of a real remote console like the one I described in a recent message, Thor and I cooked up the notion of a user-mode demon that tickles a watchdog timer every few seconds. (This is better than putting it in the kernel or init, for a whole lot of reasons.) This will at least deal with the need to reset a box when it dies. But I don't know where to get ISA cards that are just watchdog timers (many CPU cards do come with timers built in). I'll be doing some research today but if anyone knows where to get them, or has any experience using them, I'd love to hear about it. BTW, Thor's already gotten such a demon running under SCO. Doing it on NetBSD and other Unixes looks to be trivial. Lastly, I've seen this really neat rackmount chassis from Multitech. It's got 22 ISA slots, severable into up to 9 parts, and enough drive bays to actually run 9 separate servers. If you're looking for maximal density it seems like a good bet. The only problem I can see is that you'll need CPUs with both SCSI and viseo on board (thus my first question) unless you're willing to run on IDE drives. I figure that for light or medium-use servers, ethernet over ISA should be fine. To really make this thing smooth, you'd want a box that can switch a floppy cable nine different ways, since there's only room for one floppy in the case. This doesn't seem very hard, conceptually, but I don't know of anyone who makes such a device. I wonder if any existing switch could be adapted to the purpose? I don't remember how many pins are actually used by one floppy, but I suspect less than 25. If so, there are true 25-line switches available that might do the job. (Black Box has 6-to-1 25-pin switches for $90, and I'm sure they could do a 9-1 if you asked, though at a typically high price. I don't know if the floppies could stand the noise caused by all the cable changes. And you'd need DB-25 to floppy adaptor cables.) MultiTech's working on a PCI model, too, but I don't know anything about it. All other things being equal, this would allow you to use a CPU card with enet and video, since running SCSI over PCI isn't the lose that it is over ISA. /a

7 13

Re: Trouble ticket referral
by William Allen Simpson 22 Oct '96

22 Oct '96

> From: Sean Donelan <SEAN(a)SDG.DRA.COM> > >Agreed. End users should never be calling outside their ISP; > >it is NOT their place to solve problems for their ISP, for > >multiple reasons, one of which is that if any of our > >customers worked directly with MCI, for example, to solve > >a problem they saw that we were not yet aware of, and > >they and MCI solved the issue without involving us, we'd > >have no realization that a problem had been developing. > > Unfortunately there is no good trouble ticket referral system > between providers. I've had MCI (acting as my provider) close > MCI tickets and tell me to call the other provider directly > because "it was not a MCI problem." Since MCI wasn't going to > handle the trouble referral for me, I didn't have a choice but > bypass MCI and contact the other ISP directly. > I will second this. My Ann Arbor ISP (Merit/MichNet) has no customer 24x7 trouble reporting service. So, I've made them give me the numbers of their NOC. I have an unusual contract, and they seem to trust me to have done my homework. Most of their customers do not have that information. On numerous occaisions, the Merit NOC has verified that it is not a MichNet problem, and passed me to the MCI NOC. And on at least 2 occaisions, the MCI NOC has determined it is not their problem, and passed me to the Sprint and PSI NOCs (respectively). Other times, MCI has handled the problem under their own trouble ticket system, even when it was at another NSP, and called me back when the problem was resolved. I reported here (this list) sometime last year how pleased I was with the MCI NOC when it was handled by BBN.... I am sorry to hear that they are backsliding a bit, but I assume they are having growth problems like everyone else. WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson(a)MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

1 0

Hold my mail?
by Joanie Wexler 22 Oct '96

22 Oct '96

Is it possible for you to hold my mail until November 11? I'm getting nearly 100 messages a day and will not be logging on before then after today. Thank you. Joanie Wexler

1 0